privacy considerations about beacon HOT 13 CLOSED

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

from beacon.

There is a privacy considerations section now (thanks!) but I don't think it addresses most of the questions we asked or have repeatedly discussed -- reopening.

• I believe it's not true that there are no new privacy considerations (as a note, lots of security/privacy people get extra suspicious when we see a sentence of this form, given the experience with security considerations at IETF).
• Beacon allows requests, including requests with side effects, after a tab has been closed, and potentially much later. What measures for transparency or control are recommended to mitigate this change from how users have come to expect the Web to behave?
• This notes that sending a Beacon later may have the privacy implication of revealing the user's IP address/activity at a later date. Should UAs send a beacon after the IP address has changed (for example, from work to home)? What about if the user was then or is now in a private browsing mode?
• I think you're starting to get at this, but it would make sense to be explicit here. Beacon may be used to send data that is privacy-sensitive, like a user's activity on a single page; however, there are already widespread alternative mechanisms for sending this collected data back to a server, Beacon does not add new functionality here, but does decrease the performance cost of doing so and may reduce the ability for the user to inspect these communications.
• Can the user choose to disable or limit Beacon requests? (Cf. related discussion in error reporting.)

from beacon.

Beacon allows requests, including requests with side effects, after a tab has been closed, and potentially much later.

What's the potentially much later? I don't believe that's the case. We explicitly say that beacon requests are flushed whenever visibilityState transitions to hidden.

What measures for transparency or control are recommended to mitigate this change from how users have come to expect the Web to behave?

They can disable JavaScript. In absence of sendBeacon applications simply block browser from proceeding with processing the click/unload/etc.

This notes that sending a Beacon later may have the privacy implication of revealing the user's IP address/activity at a later date. Should UAs send a beacon after the IP address has changed (for example, from work to home)? What about if the user was then or is now in a private browsing mode?

To clarify, we advise that the UA not delay dispatch of the request beyond lifetime of the page, for reasons stated above. Changing IP addresses while the page is open is already observable, there is no reason to special case sendBeacon here.

Can the user choose to disable or limit Beacon requests?

No. But they can disable Javascript, which will disable sendBeacon, XHR, fetch, and other mechanisms that can trigger network fetch.

from beacon.

/me nudges @npdoty :)

from beacon.

@npdoty We need to get this issue fully resolved. Could you please let us know your feedback on Ilya's comments?

from beacon.

I believe #23 should address all the points in the original post.

from beacon.

• Beacon allows requests, including requests with side effects, after a tab has been closed, and potentially much later. What measures for transparency or control are recommended to mitigate this change from how users have come to expect the Web to behave?
• This notes that sending a Beacon later may have the privacy implication of revealing the user's IP address/activity at a later date. Should UAs send a beacon after the IP address has changed (for example, from work to home)? What about if the user was then or is now in a private browsing mode?

These two comments are largely resolved by the change that requires that Beacons be flushed upon change of visibility, since it's no longer a likely scenario that a request happens after a tab has closed and, for example, the network has changed. It's still possible that network activity will happen immediately after a tab has closed that the user might not expect, but it seems like a smaller privacy concern at that point.

• I think you're starting to get at this, but it would make sense to be explicit here. Beacon may be used to send data that is privacy-sensitive, like a user's activity on a single page; however, there are already widespread alternative mechanisms for sending this collected data back to a server, Beacon does not add new functionality here, but does decrease the performance cost of doing so and may reduce the ability for the user to inspect these communications.

I would suggest explicitly noting this in the privacy and security considerations section. Currently, you're noting that the security model is the same as existing other methods and the exact conditions why (yay! thanks for doing that); I think you could note that there are privacy implications in sending analytics data back to the server, but that the conditions are the same as they are today using other mechanisms, except that data transfers may happen after the page is closed. That distinction be a small trade-off when it comes to transparency, especially since the amount of time later is now minimal, but it's still a consideration.

from beacon.

From: http://w3c.github.io/beacon/#privacy

Existing methods, such as scripted form-submit, image beacons, and XHR/fetch requests provide similar capabilities, but come with various and costly performance tradeoffs: the requests may be aborted by the user agent unless the developer blocks the user agent from processing other events (e.g. by invoking a synchronous request, or spinning in an empty loop), and the user agent is unable to prioritize and coalesce such requests to optimize use of system resources.

@ndoty I think that should already address the above suggestion, no?

from beacon.

@igrigorik i think you meant to tag @npdoty. Although it is very interesting there is another Nick Doty in the world.

from beacon.

@ndoty woops, apologies! Paging @npdoty.. :-)

from beacon.

@igrigorik I guess I hadn't read that paragraph as being focused on privacy, as it seemed like setup for the CORS discussion. Here would be one way to make privacy trade-off more explicit.

Beacon might be used to transmit potentially sensitive information, for example, data about a user's activity on a web page, to a server. While this may have privacy implications for the user, existing methods, such as scripted form submission, image beacons and XHR requests, provide similar capabilities but come with various and costly performance trade-offs: the requests may be aborted by the user agent unless the developer blocks the user agent from processing other events (e.g. by invoking a synchronous request, or spinning in an empty loop), and the user agent is unable to prioritize and coalesce such requests to optimize use of system resources.

Because Beacon requests may occur after a page is hidden, user agents might consider alternative methods to provide transparency to users. However, because Beacon requests are flushed upon hiding a tab, these requests are unlikely to reveal, for example, a user's IP address on a network the user subsequently connects to.

This is just a suggestion, obviously.

(Thanks other Nick Doty on Github!)

from beacon.

@npdoty thanks! Took a run at integrating your suggestions in #26.

from beacon.

Resolved via #26.

from beacon.