Re: Limiting the scope of user permissions

You can tackle bits of this problem by assigning different subdomains
either per-permission set or per-client.

AFAIU, the settings should be stored independently.

With more and more permissions coming to the web, the numbers of
combinations might grow exponentially though.

On 27.04.2015 12:50, Andy Earnshaw wrote:
> I work for an adserving company, where many third-party creatives are
> served from the same CDN domain.  One of the things we're starting to
> see now is more use of APIs that require permissions, such as
> Geolocation and, since the recent Chrome 42 release, Push Notifications.
> 
> These APIs are great, though I'm particularly a fan of the idea of ads
> trying to "re-engage with users" (the words of one of our clients
> wanting to use these APIs) via push notifications, it's a bit of a scary
> thought.  A user's acceptance or disallowing of permissions presents a
> new problem for us, though.  One third-party creative might be
> uninteresting enough to a specific user such that the user immediately
> chooses to disallow permissions for a specific API, resulting in that
> user never being prompted for those permissions again even if another
> creative they see interests them enough that they would otherwise allow
> them.  Conversely, a user might give their permissions for one creative,
> unwittingly giving the same permissions to all third-party creatives
> from that point on.
> 
> A specific example:
> 
> 1. User visits a website with an ad placement served from our CDN.
> 2. User interacts with the ad, which wants to show him offers from local
> businesses close to him, asking to locate him via the Geolocation API.
> 3. User disallows access to Geolocation API and stops interacting with
> the ad.
> 4. Later, user visits another website with a different ad placement
> served from the same CDN.
> 5. User interacts with the ad, which shows him a map with all the
> advertiser's retail stores as markers on the map.
> 6. User repeatedly clicks the "locator" button on the map with
> frustration, but it has no effect because he already denied permissions
> to the Geolocation API earlier.
> 
> I hope this serves as an appropriate example for the problem.  Similar
> cases could occur with, for example, sites like CodePen or JSFiddle,
> where demonstrations cannot rely on user prompting to actually work. 
> Basically, we need a way of protecting advertisers from each other,
> perhaps by scoping permissions to an origin and path instead of just the
> origin.  I'm not sure how this would work, the best idea I can come up
> with is using a custom HTTP header, for example:
> 
> X-Permissions-Scope: path | host
> 
> I realise that this is outside the scope of the specification and that
> the spec only goes as far as making a recommendation[1] to use the
> origin of the document or worker when making security decisions, but
> this seemed like the best place to start a discussion about it.
> 
> [1]:https://w3c.github.io/permissions/#h-status-of-a-permission

Received on Monday, 27 April 2015 11:05:47 UTC