Re: [permissions] privacy concern with Permissions API/granted status and events

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.)
>