Privacy section is misguided

[annevk]

As @jakearchibald pointed out elsewhere, the fact that navigator.sendBeacon() can in theory happen after a tab has been closed or a browser has restarted means that it can reveal your new location.

E.g., I visit evil.com, it uses navigator.sendBeacon(), I close the tab and then close my laptop, travel for twenty hours, open my laptop, the browser transmits the beacon, evil.com knows where I am. This is bad.

The privacy considerations need to say that if I switch networks (to the level of cell towers I suspect or some kind of language that works for that) the beacons are removed.

[jakearchibald]

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

[dveditz]

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.

[igrigorik]

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

[annevk]

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.

[annevk]

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.

[igrigorik]

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

[npdoty]

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.

[igrigorik]

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.