W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2014

Re: Network Information API

From: Nicholas Doty <npdoty@w3.org>
Date: Sat, 11 Jan 2014 16:38:15 -0800
Cc: Josh Soref <jsoref@blackberry.com>, "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>, DAP <public-device-apis@w3.org>
Message-Id: <791442BD-BCE4-464B-9875-C21656062A66@w3.org>
To: "SULLIVAN, BRYAN L" <bs3131@att.com>
Hi Bryan,

On January 9, 2014, at 9:36 PM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:

> (Nick wrote)
>> I think there's a privacy concern in using the pattern of fired events, too. If we expect background access to these events (because your podcast web app needs to know whether it should stop downloading into localStorage or not), simultaneously firing an event across frames/tabs/windows allows for potentially unexpected correlation across different browsing contexts.
> 
> <bryan> Background (meaning any browser/window/tab not in the foreground) access to the events is desired. Many always-on app use cases will depend upon background operation, and these are many of the same (e.g. feed readers, email, SocNet) that would benefit from network-event-driven sync. But I don't know what you mean/imply by "simultaneously firing an event across frames/tabs/windows allows for potentially unexpected correlation across different browsing contexts". Can you explain this further, and associate it so some real/prevalent privacy attack? Such info would be good to capture on the wiki, if it ends up influencing the design of the API. 

I believe the concern is that the user may not expect that, for example, an iframe embedded in multiple different windows, can determine that it's the same user in those different browsing/application contexts. If I'm logged in to my social media accounts in one browser window and simultaneously have a private browsing window open which I'm using to research a medical issue, I would be unpleasantly surprised if my social media account is associated with my private browsing because my network adapter changed.

Other contexts where this issue has come up:
* Mozilla's implementation of an Idle API: https://wiki.mozilla.org/WebAPI/IdleAPI
* DAP and proximity/light events: http://lists.w3.org/Archives/Public/public-privacy/2013AprJun/0025.html

I believe the mitigations in those cases have been either to require that only a foreground browsing context receive the triggered events or to allow non-simultaneous firing of events (a fuzzing factor) in different contexts.

Hope this helps,
Nick

Received on Sunday, 12 January 2014 00:38:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:03 UTC