PP header inheritance for local schemes

[AlbertoFDR]

Currently, local schemes (such as about:srcdoc) do not inherit the PP header of their parents. This poses an issue if we have an origin A with a PP header of microphone=(self) which includes a about:srcdoc. If this local scheme iframe includes a cross-origin iframe (<iframe allow='microphone' src='https://malicious/'>), this last iframe (https://malicious) can request access for the permission. Instead, if the https://malicious iframe gets included directly on origin A, it can't request access because of the PP header. The example is the following one:

• Origin A: PP header: microphone=(self)
  • iframe src=”https://malicious” allow=”microphone” --> Not allowed to prompt
  • about:srcdoc
    • iframe src=”https://malicious” allow=”microphone” --> Allowed to prompt

With local schemes not inheriting the PP header, every website with an HTML injection and allowing self (which is necessary to allow anything at the moment: #480) could be exploited.

The attack is almost identical to the <iframe srcdoc="<script>alert(1);</script>"></iframe> case in CSP that was mitigated by deciding to inherit the header (https://w3c.github.io/webappsec-csp/#security-inherit-csp). The general discussions on inheritances also seemed to conclude that local schemes should inherit: w3ctag/design-principles#111

The idea was also suggested here: #513 (comment)

[clelland]

That's a really good point - we've talked about the idea of headerless documents automatically inheriting the feature state from their parent, and we should make it explicit in the algorithms.This should apply at least to about:blank, <iframe srcdoc> and data: urls

#515 also discusses headerless docs, but specifically for the default:none case of unload. We should make sure that it applies to the whole header policy.

[annevk]

This should build on policy containers.