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

I agree with Nick that there is a serious problem with drive-by script using
the query method.

I also see the point of fatiguing the user through bombarding them with
unnecessary prompts.

I wonder if mandatory expiry could help here. I mean that a
PermissionDescriptor MUST have an expires or maxAge property, which has to
be reported in the prompt UI.

In the case of PermissionState=="granted"  the query could return (resolve a
Promise with)  a "granted" status if the original expiry was small, say less
than 24 hours, otherwise it would return "prompt".

Also the request method could only be extant for an expiry period, so after
that no event would be queued for a change of state to "granted". Maybe
there should be 2 periods defined, the first to say how long an unrequited
request can last, the second for how long a granted permission can last.


Mike




-----Original Message-----
From: Nick Doty [mailto:npdoty@w3.org] 
Sent: 27 October 2015 06:05
To: public-webappsec@w3.org
Cc: public-privacy@w3.org
Subject: [permissions] privacy concern with Permissions API/granted status
and events

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 Thursday, 29 October 2015 09:52:36 UTC