Make policy scope clear and address tracking risks in the privacy section

[johnwilander]

I may be missing something but the spec doesn't make it clear that the policy is ephemeral and only applies to the document rendered from the HTTP response where the policy header was found.

If that's not the case, this is a storage mechanism similar to HSTS and can be used as a super cookie for cross-site tracking purposes. In addition to this, the spec needs to make it clear that policies loaded in an unpartitioned/first-party context do not apply to partitioned/third-party contexts on other webpages, and vice versa. Otherwise this feature breaks storage partitioning.

I would even explicitly say that user agents must not cache a policy.

The spec's privacy section should contain intra-doc references to these things and why they matter for privacy.

[clelland]

That is the intention, that the policy is completely ephemeral -- a Permissions-Policy header can have an effect on an embedded frame, by blocking delegation of some feature to that frame, but nothing about that effect should outlive the affected document.

[johnwilander]

That is the intention, that the policy is completely ephemeral -- a Permissions-Policy header can have an effect on an embedded frame, by blocking delegation of some feature to that frame, but nothing about that effect should outlive the affected document.

Thanks! I understand that the top frame's policy will affect child frames. What I'm sayin is that a policy for SiteA in Tab1 should not affect SiteA embedded under SiteB in Tab2.

[johnwilander]

(I should have mentioned that I'm from Apple WebKit and I'm member of WebAppSec. 🙂)

[clelland]

Thanks! I understand that the top frame's policy will affect child frames. What I'm sayin is that a policy for SiteA in Tab1 should not affect SiteA embedded under SiteB in Tab2.

Agreed, there should be no interference between policies of different document objects, even those from identical URLs. Each document only gets the policy header that was actually sent with that response. I'll see if I can make that clear in the privacy section.

Re: Caching policies -- I don't know if we could go that far, as the policy should be cached alongside the document, so a back-navigation or Service Worker fetch should include the originally cached header from that document. I suspect that the Permissions-Policy header should be subject to the same caching rules as other HTTP headers (but I'm happy to find out why I'm mistaken about that)

[annevk]

I'm not sure we need to state anything here. The way web standards work is that unless something is explicitly stated, it's not allowed. And as there is no cache defined for this header, it works the same as other such headers. We should have no more or less language than, say, Referrer-Policy.