- From: Brad Hill <hillbrad@gmail.com>
- Date: Tue, 27 Oct 2015 06:23:39 +0000
- To: Nick Doty <npdoty@w3.org>, public-webappsec@w3.org
- Cc: public-privacy@w3.org
- Message-ID: <CAEeYn8gjV+UbKjjKXYRTHhmC5SKrARLZb52Cj2CTg7azD9WifA@mail.gmail.com>
Opened https://github.com/w3c/permissions/issues/52 to track this. Thanks, Nick! On Tue, Oct 27, 2015 at 3:07 PM Nick Doty <npdoty@w3.org> wrote: > Hi WebAppSec/Permissions folks, (CC Privacy Interest Group for their > awareness and in case they have feedback) > > I remain concerned about the privacy implications of this API in terms of > checking for granted status. As I see it, the ability to confirm ahead of > time that a request for user information won't provide a visible prompt to > the user is likely to dramatically increase the frequency with which user > information (for example, precise current geolocation) is requested without > the user's awareness. We should have a good explanation for how to mitigate > this issue before suggesting changes to widely-deployed implementations > like Geolocation. > > A reminder of the threat: a third-party script embedded into a page would > like to know the user's precise geolocation, for example, for advertising > or surveillance purposes, without the cooperation of the site owner. > However, if the script calls navigator.geolocation.getCurrentPosition(), > users of that site may be prompted, at which point the site owner is likely > to be notified and the script is detected, altered or removed. For user > agents that implement the Permissions API, an embedded script can query the > permission status and only make the call if the status is granted; > alternatively, it can register for notifications of any permission change, > so that if the user ever does grant geolocation permission to that page > (perhaps to see nearby info on a map), it can then access the user's > geolocation. The user is not aware that location is being accessed by > multiple scripts; the site owner is unlikely to be informed that an > embedded script is accessing location. > > This isn't a hypothetical situation. Last year when an advertising script > on a prominent newspaper website was changed to request geolocation (and > pass on lat/lon to the advertising provider), as a casual visitor I was > able to see the change immediately, report it to the site owners and the > change was rolled back within minutes. > > Subscription to notifications of permission changes also has the potential > for decreasing the effectiveness of ambient notices for detecting > unexpected information access. If a user sees a compass or crosshair icon > appear in their browser or OS at a time when not using a site's map > interface, they might be surprised and inspect or revoke previously > provided permissions. If embedded scripts can subscribe to notifications > and only request location information at the exact moment that the site > itself has requested geolocation information, an ambient notice won't > indicate unusual activity to the user. This would be advantageous for an > attacker injecting a surveillance script into a page, for example, who > wants to evade detection by the user. > > Providing access to "denied" permission status doesn't seem to incur this > problem and could help developers who want to provide a more detailed > explanation when a user has denied a permission. That would also be more > useful for the case of revoking permission, which is an action that sites > currently don't have any insight into. To remember when a permission has > already been granted or to remember the different presentations to the user > explaining the use of permissions, developers can use cookies or > localStorage, as they do now to remember other preferences. > > Thanks, > Nick > > (Apologies for repeating a point raised several times at TPAC 2014 and > otherwise, but the WD of this document doesn't seem to have any mitigation > of this concern and I didn't see anything in the GitHub issues list.) >
Received on Tuesday, 27 October 2015 06:24:25 UTC