Send feature policy in sub-resource request headers about webappsec-permissions-policy HOT 11 CLOSED

From the resolution of #7, and commits ed93b0c and bc67bf9, it looks like the resolution is actually that requests never include the policy; it's a response header only.

from webappsec-permissions-policy.

I think we probably want some way to send these in request headers, but I'm concerned that if it's the default it will be a lot of wasted bytes on every network request.

from webappsec-permissions-policy.

tl;dr: I think we can revert those changes; we should advertise the active policy.

A brief history...

Originally, the thought was that we should advertise the active policy and have the server reflect back ("ack") the policy in the response; absence of such reflected policy would then block the response. This was modeled after the embedded-csp proposal. Then, after discussing it some more, we realized that the "ack" is hard to implement for many + basically unnecesasry: we don't need to block the resource, we enforce the policy by restricting access to APIs. Given that, we dropped the header because it seemed unnecessary.

Later (through various conversations at BlinkOn) we identified that advertising the policy is, in fact, very useful after all, as it provides a signal to the embedee for what policies will be enforced on its content. So, I think we revert the earlier commits and drop the 'reflect' bits..

I think we probably want some way to send these in request headers, but I'm concerned that if it's the default it will be a lot of wasted bytes on every network request.

The FP request header would only be present on pages that specify a Feature-Policy; it's an opt-in header. I think this fine.

from webappsec-permissions-policy.

I think we probably want some way to send these in request headers, but I'm concerned that if it's the default it will be a lot of wasted bytes on every network request.

The FP request header would only be present on pages that specify a Feature-Policy; it's an opt-in header. I think this fine.

Imagine a future world in which almost every page is using FP. Now it's not fine anymore. This isn't theoretical, this might actually happen.

Could we start with just exposing the active policy to the main HTML resource of each frame and to JS? Then pages can do what they want for subresources (e.g. put in a cookie, append as query parameters to URLs, etc).

from webappsec-permissions-policy.

Then pages can do what they want for subresources (e.g. put in a cookie, append as query parameters to URLs, etc).

In which case they're worse off, since headers would be compressed via HPACK (h2), whereas their cookies and query string params would only make the problem worse... shrug

I'm not against this, but it feels like we're micro-optimizing.

from webappsec-permissions-policy.

Cookies are in the header, and should probably compress slightly better than the FP header, which isn't in the static header field list. The problem with them is that you shouldn't be able to set cookies for third-party content, so you have to fall back to URLs anyway.

from webappsec-permissions-policy.

Imagine a future world in which almost every page is using FP. Now it's not fine anymore. This isn't theoretical, this might actually happen.

Origin-Policy looks like a promising solution to address this: https://mikewest.github.io/origin-policy/

from webappsec-permissions-policy.

As I'm working on this, ran across an interesting case. Consider this...

Feature-Policy: {"disable":["webrtc"], "target":["https://example.com"]},
        {"enable":["vibrate"], "target":
          ["https://foo.com", "https://bar.com"]}

 <iframe src="https://foo.com/thing"></iframe>

• Disable is always propagated down - e.g. if parent disables webrtc on example.com, then foo.com embedee automatically inherits same policy.
• Should enable policy be propagated down as well?
  • Embedder delegates access to Vibrate API to foo.com
  • Embedder delegates access to Vibrate API to bar.com

Does the above mean that embedder enabled self -> foo.com -> bar.com? OR, does the enable policy only apply for the context that sets it and bar.com does not automagically propagate down to foo.com. In other words, can embedder delegate permission on behalf of the embedee? As currently written in 3e3acb6 this is allowed. Should it be?

/cc @raymeskhoury @noncombatant

from webappsec-permissions-policy.

Based on a VC chat today: the initial take is that enable should not propagate down. So, in above example foo.com would have to explicitly (re)enable bar.com if it wants to delegate permission to it.

from webappsec-permissions-policy.

For v1 (see #43) we're targeting a small set of ~permissions features, which don't (strictly) need this advertisement. For v2+, once we tackle features that are default on and don't have a permissions prompt.. we'll need to (a) provide some JS mechanism to query status and (b) send the request header policy.

from webappsec-permissions-policy.

Closing this as this is tackled by newer issues around sandboxing.

from webappsec-permissions-policy.