Closed domfarolino closed 2 years ago
OK I dug into this a bit more today and I have some more critiques and thoughts. It is a bit confusing to track how Document Polices combine/coalesce throughout various levels of the subframe hierarchy, for a few reasons:
Bugs
In terms of bugs I've spotted in the spec, there are at least a few:
Required-Document-Policy
response header, like we do for the Document-Policy
header here. This is particularly bad, because it means that we never actually store the value of a document's Required-Document-Policy
anywhere in any member, which means we never actually delegate it down to subframes for future enforcement, which is certainly the intention of the spec 😞document policy
member or not. The spec mentions a concrete declared document policy member, but unfortunately it is only ever read and never written to. I guess a loose reading of the spec could indicate that it is written to by algorithms like process response policy which "returns a declared document policy", but it is not clear what returning a declared document policy even means, since a declared document policy is a specific member of a Document object/instance, which we never explicitly set. The spec has several mentions of "document’s document policy" but that doesn't really mean anything. For example, see step 7 of this monkeypatched algorithm. This doesn't really work, because there is not a document policy member on the Document object -- do we instead mean declared document policy? reported document policy? a new member altogether? My read is that the spec always means declared document policy, in which case I'd prefer renaming this to document policy since that's what we're using in more cases than not.Confusing/duplicate members
My read of the spec is the following (and please read the ->
syntax as if it were C++ pointer syntax):
Document-Policy
response header. This policy only influences the Document that this is a member on.
document->document_policy
betterRequired-Document-Policy
response header value. It has no influence over the Document that this document policy is a member on. It is solely used to produce a minimum document policy that all subframes (nested under this Document) must adhere to (via their Document-Policy
response header)
Now we get to the members stored on the browsing context concept
Document-Policy
response header on the document that loads in said browsing context, to make sure the Document-Policy
sent with the document is indeed strict enough. That means by the time a nested browsing context navigates, it must already have this member set on it, so that when the nav finishes, we can compare the response header against it. That means it must be the strictest union of the following three policies:
Required-Document-Policy
response header might have sent)It is (2) + (3) that I think the spec's concept of the nested context required document policy meant to represent. In other words, when a document loads we know it had to at least meet the bar set by its browsing context's required document policy, but if that document was sent with additional restrictions in the form of the Required-Document-Policy
response header that should begin to take effect for subframes rooted at this document, then we need to make sure the nested browsing context of any subframes we have, has a required document policy of at least our bc's required document policy plus the restrictions in the form of our R-D-P
header! We should fix this!
//cc @domenic
Thanks for the very thorough review, @domfarolino! The spec is in pretty sad shape, but I think I have some time to take care of the most egregious issues now.
To the specific points:
Require-Document-Policy
does need to be read, at the same time as Document-Policy.Document-Policy
response header, and that is necessarily the policy in effect (If there were stricter requirements, then the document would not have loaded). The HTML integration section should actually set that somewhere.I've updated the spec to fix most of these issues, I think. Take a look and see what's still outstanding:
Create a required policy for a browsing context appears to be the algorithm where we acatually create the Document Policy that contains a union of all document policies (for duplicates, we take the strictest) from the following two sources:
policy
attribute of the iframe loading the document we're attempting to initializeOnly nested context required document policy never appears to be set anywhere, so I can't imagine the "Create a required policy for a browsing context" ever does the correct thing, right?