- From: Christine Runnegar <runnegar@isoc.org>
- Date: Wed, 10 Feb 2016 06:04:17 +0000
- To: Nick Doty <npdoty@ischool.berkeley.edu>
- CC: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Thanks for following this up Nick. Christine > On 4 Feb 2016, at 2:52 AM, Nick Doty <npdoty@ischool.berkeley.edu> wrote: > > I believe this concern has subsequently been resolved, based in part on a text suggestion like the one mentioned previously. > > https://github.com/w3c/beacon/pull/26 > > Updated language in the draft: > >> The delivered data might contain potentially sensitive information, for example, data about a user's activity on a web page, to a server. While this can have privacy implications for the user, 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 can 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. >> >> [...] >> >> As such, from the security perspective, the Beacon API is subject to all the same security policies as the current methods in use by developers. Similarly, from the privacy perspective, the resulting requests are initiated immediately when the API is called, or upon a page visibility change, which restricts the exposed information (e.g. user's IP address) to existing lifecycle events accessible to the developers. However, user agents might consider alternative methods to surface such requests to provide transparency to users. > https://w3c.github.io/beacon/#privacy > > Thanks, > Nick > >> On Jan 25, 2016, at 8:29 AM, Christine Runnegar <runnegar@isoc.org> wrote: >> >> Nick, >> >> Thank you for taking the initiative. Re [3] I do think it would be helpful to call this out in the privacy considerations section. If others have different views, please share them on the list by Friday. >> >> Christine >> >>> On 22 Jan 2016, at 2:16 AM, Nick Doty <npdoty@ischool.berkeley.edu> wrote: >>> >>> Hi PING, >>> >>> A quick update. Since our review back in 2014 [1], and repeated discussion at TPAC 2015, the Web Perf group has made substantial changes to the Beacon spec. I believe these changes simplify and clarify the spec [2] and also mitigate the distinct privacy and security concerns we raised. Good work all around. >>> >>> One open issue [3]: I've suggested that the spec explicitly note the privacy implication that Beacon can be used to send telemetry/analytics data back to the server (data which might be privacy sensitive or not expected by the user) and that since the data might be sent just after the page is closed, the activity will be less visible to the user. Given that current methods accomplish the same data transfer but at the cost of slowing navigations by blocking unload, I think the argument that this trade-off is good for the user makes a lot of sense, I've just suggested that it be explicitly noted. >>> >>> If PING feels differently from me on that, please do speak up, I don't want to misrepresent you. It would also be useful to have a general guideline for when certain kinds of trade-offs make sense, or what levels of privacy consideration should be documented in a spec. >>> >>> Cheers, >>> Nick >>> >>> >>> [1] https://lists.w3.org/Archives/Public/public-web-perf/2014Jul/0109.html >>> [2] https://w3c.github.io/beacon/ >>> [3] https://github.com/w3c/beacon/issues/17 >> >> >
Received on Wednesday, 10 February 2016 06:05:01 UTC