W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Limiting the scope of user permissions

From: Andy Earnshaw <andyearnshaw@gmail.com>
Date: Mon, 27 Apr 2015 11:50:17 +0100
Message-ID: <CAOrM_WO6pWrdOMGczRgCiiMMHDy2TvKVxKpTutjzeS1wuptoMw@mail.gmail.com>
To: public-webapps@w3.org
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 10:50:45 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC