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

On Thu, 24 Jul 2014, Mike West wrote:
> On Wed, Jul 23, 2014 at 10:14 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> > In "6.2 Determine request’s Referrer.", the algorithm carefully 
> > navigates itself to a JavaScript global environment record, and then 
> > says:
> >
> >   let referrerURL be the URL of environment
> >
> > What is that URL? The JavaScript spec doesn't mention anything about 
> > global environment records having URLs.
> 
> Yes, this was sloppy. I've pushed 
> https://github.com/w3c/webappsec/commit/765321dbf1bcc5adfc5d3e517fa64628719faa6c 
> in the hopes of cleaning it up. Does the new 
> https://w3c.github.io/webappsec/specs/referrer-policy/#determine-requests-referrer 
> make more sense?

I think fundamentally we shouldn't be using a JS global environment as 
input to this algorithm.

Other than that, this seems much closer. One remaining nit is that the API 
referrer source isn't always a Document, sometimes it's a URL.

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".)


> > In fact I'm rather confused about why we're doing anything with 
> > JavaScript global environment records here.
> 
> 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?) IMHO in environments that are script-based, we 
should start from the script settings object. In fact, in the HTML spec, 
anywhere that invokes "fetch" from a script environment always sets the 
override referrer source to the API referrer source specified by the 
incumbent settings object or the entry settings object, depending on the 
case. For example, document.load():

# Fetch url from the origin of document, using the API referrer source 
# specified by the entry settings object, with the synchronous flag set 
# and the force same-origin flag set.

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


> > There's also other logic from those steps that seem to be missing 
> > entirely now. For example, where are about:blank and data:* URLs 
> > dropped?
> 
> 'about:', 'data:', and other non-relative schemes are dropped in step 1 
> of "6.3 Strip url for use as a referrer", which steps 5 and 6 of the 
> "determine" algorithm invoke.

Ah, cool, I missed that.


> > Where is the logic that drops Referers entirely when the origin is a 
> > unique tuple?
> 
> Hrm. I didn't realize this was a requirement. Chrome doesn't adhere to 
> this rule, but Firefox does. Filed https://crbug.com/397011 and added 
> https://github.com/w3c/webappsec/commit/51bc0fb4213621ece844c9f7d67eb87b24d44786 
> to bring the spec into line.

I don't really know if it's a requirement per se (I don't know if 
there's a compat need for it). To be honest, the current spec text is 
mostly arbitrary, I'm not sure if it's the best. If we're going to change 
it, though, we should make sure we do it deliberately, not just because 
of transcriptions errors. ;-)

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 

 - 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'