CSP: Change the scope of the Permissions API

[andyearnshaw]

I work for a large-scale adserving company who hosts third-party creatives on our CDN. One of the challenges we have at the moment is controlling the scope of the Permissions API. Consider the following case:

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, and this applied to the entire CDN domain.

Given that, I'd like to suggest that a new directive could be implemented to change the scope of permissions from applying to an entire origin, to origin + path. For example, given the URL http://cdn.mydomain.com/1234567/12345/index.html, a relative or absolute path could be supplied. The following would be synonymous:

Content-Security-Policy: permissions-scope ../
Content-Security-Policy: permissions-scope /1234567/

Obviously an absolute URL would need to match the current origin and be part of the current path's tree. For our use case, this would scope the permissions to a specific campaign, so other campaigns would need to request permissions for themselves.

This could also be useful for other sites hosting third-party content, such as JSFiddle, CodePen, or eBay listings. Is this something that could be considered for the specification?

[hillbrad]

I think we could have a CSP directive that disabled the permission (even if
previously enabled on the origin), and the ability to ask for it, on a
resource-by-resource basis. I'm in the exact same situation as you and
would love to be able to do that.

But placing a resource in a permission jail is different than trying to
achieve a finer-grained permission API. Because the Same Origin Policy
doesn't place security barriers between resources at the same origin, a
path that is denied can always compel a path that is allowed to act as its
deputy. So you can selectively deny, but you can't selectively grant.

On Mon, Apr 27, 2015 at 1:37 PM Andy Earnshaw [email protected]
wrote:

I work for a large-scale adserving company who hosts third-party creatives
on our CDN. One of the challenges we have at the moment is controlling the
scope of the Permissions API. Consider the following case:

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, and this applied to the entire CDN domain.

Given that, I'd like to suggest that a new directive could be implemented
to change the scope of permissions from applying to an entire origin, to
origin + path. For example, given the URL
http://cdn.mydomain.com/1234567/12345/index.html, a relative or absolute
path could be supplied. The following would be synonymous:

Content-Security-Policy: permissions-scope ../
Content-Security-Policy: permissions-scope /1234567/

Obviously an absolute URL would need to match the current origin and be
part of the current path's tree. For our use case, this would scope the
permissions to a specific campaign, so other campaigns would need to
request permissions for themselves.

This could also be useful for other sites hosting third-party content,
such as JSFiddle, CodePen, or eBay listings. Is this something that could
be considered for the specification?

—
Reply to this email directly or view it on GitHub
#312.

[andyearnshaw]

I hadn't thought of that, I guess a resource could just frame another resource on the site and use its permissions. Selectively denying permissions might be something that we do, or force a prompt each time a resource is loaded, if those were possible.

Ideally, we don't want to cut clients off completely from these APIs, we just want to sandbox them. So how about a directive to sandbox a resource entirely, for not just the permissions API, but to treat a tree as a completely separate origin to another tree? This would apply to permissions, canvas tainting, XHR and everything else that would otherwise be managed by the same origin policy.

[hillbrad]

You mean this? http://www.w3.org/TR/CSP2/#directive-sandbox

It is very unfortunate that the sandbox attribute was designed to be
deny-by-default with flags to re-enable things, as this makes it very
difficult to add new restrictions (like restricting the ability to ask for
permissions) without potentially breaking existing deployed systems. But
this may be a reasonable thing to add to the HTML sandbox directive.

On Tue, Apr 28, 2015 at 12:48 AM Andy Earnshaw [email protected]
wrote:

I hadn't thought of that, I guess a resource could just frame another
resource on the site and use its permissions. Selectively denying
permissions might be something that we do, or force a prompt each time a
resource is loaded, if those were possible.

Ideally, we don't want to cut clients off completely from these APIs, we
just want to sandbox them. So how about a directive to sandbox a resource
entirely, for not just the permissions API, but to treat a tree as a
completely separate origin to another tree? This would apply to
permissions, canvas tainting, XHR and everything else that would otherwise
be managed by the same origin policy.

—
Reply to this email directly or view it on GitHub
#312 (comment).

[andyearnshaw]

Yeah, adding it to the sandbox directive sounds like it might be a good idea. What's the process for new proposals like this?