Privacy section is misguided about beacon HOT 8 CLOSED

There's a discussion on this over at public-webappsec https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0009.html

from beacon.

We're offering sendBeacon() to sites to give them an alternative to waiting for a synchronous XHR, but those can fail too. The beacon should not be guaranteed to make it, it's "best effort".

sendBeacon is the carrot. The stick could be a transient overlay on pages doing lengthy onunload processing ("waiting for foo.com to finish") so the user knows who to blame for bad perf.

from beacon.

FWIW, Beacon does not guarantee delivery: "The User Agent should transmit data at the earliest available opportunity, but may prioritize the transmission of data lower compared to other network traffic. The User Agent should make a best effort attempt to eventually transmit the data."

The intent here was to allow to the UA to coalesce requests: the request is not user-critical and we ignore the response, hence we want to give the UA the option to wait for next radio wake-up to avoid burning the battery. The 'eventually' part was put in place as a guard that UA shouldn't defer this indefinitely.. granted, we could have worded that better.

With respect to offline: none of the existing implementations do anything special here (as in, if user is offline the sendBeacon fails), and I think we want to keep it this way. If you want to buffer beacons while offline, use ServiceWorker + all the provided mechanism (sync event, etc).

Concretely, I'm proposing:

• We clarify that sendBeacon is a low-priority / non-interactive / non-blocking request, and that the UA is allowed to defer and coalesce such requests. However, such requests should not be held indefinitely:
  • they should be periodically flushed while the page is active.
  • they should be flushed when the page is being unloaded and should not block the unload sequence.
  • they are best effort, and they do not do anything special for offline, etc.

I believe that would address the above concerns? The delivery is restricted to the existing lifecycle of the page (active and unload). Also, it's consistent with existing implementations.

/cc @toddreifsteck @plehegar

from beacon.

I think that would be good, but I still think you want to point out why user agents should not attempt to persist them any longer, due to the risk of that leaking information about the whereabouts of the user.

from beacon.

Note also that if you process them during unload and they go through the service worker (which I think is what we ended up agreeing on) that the service worker will likely stay open past the lifetime of the tab which would also be escaping the currently assumed browser sandbox.

I don't think the implications of that have been sufficiently thought through or discussed.

from beacon.

I believe this was addressed via #19, closing. Please feel free to reopen if otherwise.

from beacon.

The title of this issue is confusing, but I'm not sure the original comment (removing beacons after the network has changed) has been addressed. (I noted this in #17 as well.) I don't get the impression that that webappsec thread had much consensus for allowing delayed execution requests on different networks, for example, revealing the user's work+home connections.

from beacon.

The title of this issue is confusing, but I'm not sure the original comment (removing beacons after the network has changed) has been addressed.

I believe we have, in the sense that we clarified that beacon request(s) will be initiated before page is fully unloaded, which means that we do not expose anything beyond what the page could have already reported to any server... e.g. if I keep the page open and while its open switch networks, then the page can already observe this (periodic pings, etc), beacon does not expose anything new here.

from beacon.