Question about referrer of descendant module fetch

[Hiroki Nakagawa]

Hi module-dev,

I'm now writing referrer policy tests for Worklets (crbug) and came across questions about the referrer handling in ES6 Modules.

Imagine the following scenario (See also the attached photo​​. Sorry for dirty handwriting!!)

​

1) There is a document in ORIGIN-A whose referrer policy is "same-origin".

2) The document static-imports a top-level script from ORIGIN-B. This is cross-origin resource fetch, so the referrer should be empty.

3) The top-level script in ORIGIN-B static-imports a child script from ORIGIN-C. This is cross-origin resource fetch, so the referrer should be empty.

4) The child script in ORIGIN-C static-imports a grandchild script from ORIGIN-C.

QUESTION: What's the referrer of the fetch at 4)? From the Document's POV, ORIGIN-C is a different origin, so the referrer should be empty. On the other hand, from the child script's POV, the grandchild script is hosted in the same origin, so the referrer should be "child script".

Thanks!

[Domenic Denicola]

Time to play my favorite game, spec-detective.

• The fetch here is made by fetch a single module script, with the following request properties:
• referrer = "https://c.example.com/child-script.mjs"
• referrer policy = empty string (default)
• origin = "client" (default)
• client = fetch client settings object = document's relevant settings object in origin A
• Fetch step 1.2 sets the origin to the client's origin, i.e. to (https, a.example.com, 443).
• Main fetch step 2.5 sees that the referrer policy is the empty string and thus sets the referrer policy to the client's referrer policy. Thus, the referrer policy is "same-origin".
• Main fetch step 2.7 invokes determine request's referrer.
• We end up in step 6's "same-origin" case.
• Is the request a same-origin request?
• Request's current URL is https://c.example.com/grandchild-script.js, with an origin of (https, c.example.com, 443)
• Request's origin is (https, a.example.com, 443).
• So they are not same-origin
• So we return "no referrer"
• HTTP-network-or-cache fetch step 2.9 decides to append no referrer header at all to the outgoing HTTP request.

I hope this turns into a nice web platform test!

This also helped me discover that I forgot the referrerpolicy="" attribute on <link rel=modulepreload>, for what it's worth. I'll try to fix that soon; I made a note to myself in the meantime.

On Thu, Nov 9, 2017 at 12:13 AM Hiroki Nakagawa <nhi...@chromium.org> wrote:

Hi module-dev,

I'm now writing referrer policy tests for Worklets (crbug) and came across questions about the referrer handling in ES6 Modules.

Imagine the following scenario (See also the attached photo​​. Sorry for dirty handwriting!!)

​

[Takeshi Yoshino]

Hi Domenic,

Thanks for the game log :)

I see that the referrer policy provided by the server for the document is really controlling privacy leakage. But it also looks a bit weird that a document on origin A ('s referrer policy header) is controlling leakage of a referrer string "https://c.example.com/...".

I'd like to understand more your idea behind letting "fetch the descendants of a module script" use "module script's base URL" for the referrer argument.

This lets browsers report the parent module's URL as the referrer. It's kinda treating each module as the subject of the fetching in terms of referrer generation. It still follows the original idea behind referrer, but leaves a question why we shouldn't use the document's URL.

Hiroki suggested that comparing this with how importScripts() works might give us some insight.

[Domenic Denicola]

The discussion was at https://github.com/whatwg/html/issues/1150, although it was pretty short. I think matching CSS is a fairly compelling reason though.

Note though that I guess we should also be respecting Referrer-Policy headers from each script, since apparently that's how CSS is supposed to work. I.e., it uses the Referrer-Policy header if possible, and falls back to the document's referrer policy if there isn't one. Hmm...

I filed https://github.com/w3c/webappsec-referrer-policy/issues/111 to confirm, but that seems like a reasonable path, albeit a bit more complexity...

[Takeshi Yoshino]

Thanks for the pointer. OK, I see. I didn't come up with the CSS case in the discussion.

I agree that less leak is the direction we have as Anne said. It's aligned with the principle. Maybe unless there's any real problem, we could wait and see if developers find this problematic.

Interesting that CSS has the fallback mechanism. Given the parent script is exposing it's URL, it makes sense that we give the script's server a chance to have control over the referrer generation.

[Hiroki Nakagawa]

domenic@: Thank you for your investigation! I'll make tests based on it and update them when the HTML spec gets aligned with CSS regarding the referrer policy.

tyoshino@: Thank you for your inputs! I also didn't know CSS has the interesting fallback mechanism :)