Srcdoc referrer policies don't interact well with <meta referrer> about webappsec-referrer-policy

[estark37]

I think this is desired behavior and was resolved in whatwg/html#1205, is that correct? (@domenic)

[domenic]

Right, I think we concluded that, with some of the extra formalization performed in whatwg/html#1205, the behavior described here is the desired one.

[bzbarsky]

Why is that the desired behavior? The referrer is dynamically grabbed from the container document, but the referrer policy is snapshotted? Seems to me they should both be snapshots or both be dynamic.

[domenic]

Hmm, where is the referrer grabbed dynamically from the container document?

The document's referrer is a string (representing a URL) that can be set when the Document is created.

• https://html.spec.whatwg.org/#initialise-the-document-object set them together (steps 7 and 9)
• https://html.spec.whatwg.org/#creating-a-new-browsing-context set them together (steps 9 and 10)

[bzbarsky]

https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer step 3 substep 3 subsubsteps 2 and 3.

[bzbarsky]

And note that https://html.spec.whatwg.org/#initialise-the-document-object does not set the referrer for srcdoc documents, because in step 9 the "If resource is a request" precondition is false: a srcdoc has a response but not a request. See https://html.spec.whatwg.org/#process-the-iframe-attributes

So for srcdoc documents the "document's referrer" is never set right now per spec, as far as I can tell. Luckily, https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer never tries to use it for a srcdoc document.

[domenic]

I see, you were talking about the referrer/referrer policy at fetching time, not document creation time. So about the referrer of requests initiated inside that document, not about document.referrer.

After thinking about this a bit more, I appreciate the asymmetry you are referring to. Roughly, when performing a request from "inside" an iframe srcdoc document:

• We determine the referrer by saying "oh, the URL is meaningless (it's about:srcdoc); let's look up to the parent".
• We should determinine the referrer policy by saying "oh, the referrer policy is unset; let's look up to the parent".

https://w3c.github.io/webappsec-referrer-policy/#determine-requests-referrer step 3 substep 3 subsubsteps 2 and 3.

Hmm. These just seem wrong. For example it doesn't recursively climb. Yes it does, I missed the "while"

I'll send a couple of PRs here to straighten this out.

[domenic]

I gave this a shot but without #40 straightened out it's pretty hard.

The essential asymmetry is that referrer is computed "lazily" by using the value "client" by default; then "Determine request's referrer" takes over and gets a chance to climb iframe srcdocs and such. Whereas, referrer policy does not have this model: the request has a referrer policy, and if it's the default of "", then we don't know if that's because the request initiated from an iframe srcdoc document, or because it came from a normal document with no referrer policy set.

I'm not sure how to best to deal with this.

[domenic]

Oh, wait. Fetch already does this kind of lazy climbing for us, kind of:

If request's referrer policy is the empty string and request's client is non-null, then set request's referrer policy to request's client's associated referrer policy. [REFERRER]

We just need to make sure that works correctly for iframe srcdoc documents. Got it, HTML PR incoming.

[bzbarsky]

So about the referrer of requests initiated inside that document, not about document.referrer

Yes! Sorry for the confusion there.

[estark37]

I believe this is fixed by whatwg/html@5d7c532 (@domenic please correct me if Im wrong!)