- From: Mike West <mkwst@google.com>
- Date: Fri, 25 Jul 2014 11:47:39 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: Jochen Eisinger <eisinger@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Anne van Kesteren <annevk@annevk.nl>
On Thu, Jul 24, 2014 at 9:26 PM, Ian Hickson <ian@hixie.ch> wrote: > Other than [the fundamental objection to JS environment], this seems much closer. One remaining nit is that the API > referrer source isn't always a Document, sometimes it's a URL. Hrm. When does this happen? https://github.com/w3c/webappsec/commit/68317e6c6df9e81a1f4570bc8bf984660abd4bf0 hopefully addresses it. > Another small nit I just noticed is that the Referrer Policy spec returns > "none" (with quotes) while Fetch expects /none/ (the term "none", no > quotes, not a string). I think we should make sure we clearly distinguish > the cases where the return value is a URL from the cases where the return > value is the internal conceptual "none" state. (In particular, naive > implementations could easily end up confusing "none", with quotes, with > the non-absolute URL consisting of just the string "none".) Good catch: https://github.com/w3c/webappsec/commit/25b309e0452e2870ecc647675ddea853985d4625 >> The goal was to cover requests both from documents and workers (Service >> Workers in particular). I was looking around for a better term, and this >> seemed like the right concept to grab. See the top of >> http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0006.html >> for a bit of the discussion. > > We don't need JS global environments to do this. (What about non-JS > workers in the future?) Is there a proposal for such a thing? > If we consistently specify the referrer anytime we call fetch, we don't > need fetch itself to ever worry about this case. If we want to define some > default, then we could do it by having the referrer defaulted as follows: > > - If there is a specific override referrer source > The override referrer source. > - When navigating > The active document of the source browsing context. > - When fetching resources for an element > The element's Document. > - When there is an incumbent script settings object: > The API referrer source I think this makes sense. I'd like Anne to weigh in from the perspective of Fetch, but I'm happy to do less work in this spec if at all possible. > The HTML spec right now, IIRC, has these notable behaviours: > > - documents with a unique origin, e.g. <iframe src="" sandbox>, but that > are not srcdoc documents, get no Referer, even if they have a URL. This > seems relatively important, since The referrer spec now has this behavior as well. Thanks again for pointing it out. > - notwithstanding that, srcdoc documents always defer to their > parent, even if they're in an isolated origin, for the purposes of > Referer. This could be a security issue maybe. Might be worth only > making this happen if they're not explicitly sandboxed without > allow-same-origin. That's easily done: just check for srcdoc after > you've checked for a non-tuple origin. Makes sense: https://github.com/w3c/webappsec/commit/7c8f64ee1e26c234f40dd56411bbdfa3b66ca5ea -- Mike West <mkwst@google.com> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Friday, 25 July 2014 09:48:27 UTC