Re: [REFERRER] Where does "Determine request’s Referrer" get its URL from?

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