- From: Nick Doty <npdoty@w3.org>
- Date: Tue, 27 Oct 2015 15:05:14 +0900
- To: public-webappsec@w3.org
- Cc: public-privacy@w3.org
- Message-Id: <2BDB2307-912C-4E57-90D1-23C65CC69CCA@w3.org>
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:05:39 UTC