- From: Kristijan Burnik <burnik@google.com>
- Date: Wed, 27 May 2015 16:27:26 +0200
- To: Jochen Eisinger <eisinger@google.com>
- Cc: public-webappsec@w3.org
- Message-ID: <CANJwyhW+-_7EFrKaS1aoSb-_Cb=-j1yGMkjLzDqAP73xEt_73A@mail.gmail.com>
Thanks! I'm now fairly convinced that should be the case. Especially since other resources behave as you describe and XHR/Fetch fail to do so (Chrome 42). I have updated the test suite to reflect this failure. https://github.com/kristijanburnik/web-platform-tests/commit/09f74211bb3d880521af9a9283253c9ac129f2d3 Also added Chromium issue: http://crbug.com/492615 On Wed, May 27, 2015 at 11:45 AM, Jochen Eisinger <eisinger@google.com> wrote: > I think the referrer value should always become less and less detailed > during a network request. > > From that point of view, the behavior with fetch, i.e. that the referrer > value goes from origin to full during the redirect, is wrong. > > On Tue, May 26, 2015 at 2:10 PM Kristijan Burnik <burnik@google.com> > wrote: > >> Greetings to all, >> >> Currently there is an open PR updating the referrer policy test suite >> with tests to support asserting 301 redirections : >> https://github.com/w3c/web-platform-tests/pull/1856 >> >> However there is an open question: >> >> Should the final destination of a sub-resource get the same referrer as >> the content (img, link, script) and background requests (XHR, Fetch)? >> >> *We have the following scenario:* >> >> Referrer Policy: >> Origin when Cross Origin >> >> Protocol transition: >> http to http >> >> A priori sub-resource URL: >> cross-origin >> >> Final destination of resource: >> same origin as browsing context >> >> Redirection: >> Start with a cross-origin request for a sub resource which redirects back >> to the same origin of the browsing context. I call it a >> "swap-origin-redirect". >> >> -- >> >> What is interesting is that Chrome 42 exhibits the following behavior: >> >> *Image:* >> a.com/index.html ==> b.com/img.py?with_redirect --> >> a.com/img.py?final_dest >> final_dest gets the *origin only URL* (http://a.com/) >> >> See the test >> <https://github.com/kristijanburnik/web-platform-tests/blob/9e6d3021dbed5e2ada8d6912c15ec1d5fc42ca73/referrer-policy/origin-when-cross-origin/http-csp/cross-origin/http-http/img-tag/cross-origin.swap-origin-redirect.http.html> for >> img >> >> *Fetch:* >> a.com/index.html ==> b.com/xhr.py?with_redirect --> >> a.com/xhr.py?final_dest >> final_dest gets the *stripped referrer URL* (http://a.com/index.html) >> >> See the test >> <https://github.com/kristijanburnik/web-platform-tests/blob/9e6d3021dbed5e2ada8d6912c15ec1d5fc42ca73/referrer-policy/origin-when-cross-origin/http-csp/cross-origin/http-http/fetch-request/cross-origin.swap-origin-redirect.http.html> for >> fetch >> >> -- >> >> This only occurs when *origin-when-cross-origin* referrer policy is >> applied. >> >> My question is: >> >> Should we differentiate between types of resources (content vs bg >> requests) when we have swap-origin redirects which start of as a >> cross-origin sub-resource request? >> >> Wow, such a mouthful... Drawing diagrams helps... :-) >> Also, see the tests linked above. >> >> Please provide some feedback or suggestions. >> >> -- >> >> *Kristijan Burnik* >> >> Software Engineering Intern >> >> burnik@google.com >> >> Google Germany GmbH >> >> Dienerstraße 12 >> >> 80331 München >> >> Geschäftsführer: Graham Law, Christine Elizabeth Flores >> >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> Sitz der Gesellschaft: Hamburg >> >> >> -- *Kristijan Burnik* Software Engineering Intern burnik@google.com Google Germany GmbH Dienerstraße 12 80331 München Geschäftsführer: Graham Law, Christine Elizabeth Flores Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Received on Wednesday, 27 May 2015 14:28:30 UTC