W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2015

Re: Referrer value for resources fetched from CSS

From: Jochen Eisinger <eisinger@google.com>
Date: Wed, 30 Sep 2015 15:21:08 +0000
Message-ID: <CALjhuic6g+oZ1QbkJS3rN5tabHnaSv7bXdsyjkC9zSEgKuBCeA@mail.gmail.com>
To: Tanvi Vyas <tanvi@mozilla.com>, Mike West <mkwst@google.com>, Yoav Weiss <yoav@yoav.ws>, Boris Zbarsky <bzbarsky@mit.edu>, "annevk@annevk.nl" <annevk@annevk.nl>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Tanvi, what referrer policy does Firefox use for cross origin css docs? I
think in Blink, I use the CSS doc as referrer URL, and the referrer policy
from the document that imported this CSS doc (which actually seems kinda
odd).

Maybe it was more consistent to use the default referrer policy in that
case?

On Tue, Sep 29, 2015 at 8:54 AM Jochen Eisinger <eisinger@google.com> wrote:

> On Mon, Sep 28, 2015 at 8:03 PM Tanvi Vyas <tanvi@mozilla.com> wrote:
>
>> Hi Jochen,
>>
>> Have you updated the spec?
>>
>
> Not yet, no.
>
>
>>
>> In Firefox we have a concept of a "triggering principal" and a "loading
>> principal"[1].  The triggering principal is like the referrer and points to
>> the context that triggered the load.  While the "loading principal" should
>> be the principal for the context in which the resource is loaded.  Does
>> Chrome have a similar distinction?
>>
>
> No, Chrome doesn't have such a clear distinction. We have a FetchContext
> which I guess corresponds to the loading principal, but a resource can
> ignore the referrer and origin from the FetchContext which is what e.g.
> CSSImageValue does.
>
>
>>
>> In your font example, the stylesheet was the one who triggered the font
>> load into the main document.  So the stylesheet is the trigger/referrer and
>> the main document is the loading context.
>>
>> Thanks!
>>
>> ~Tanvi
>>
>> [1]
>> https://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsILoadInfo.idl#130
>>
>>
>> On 9/8/15 4:59 AM, Jochen Eisinger wrote:
>>
>> Chrome uses the CSS file as referrer since quite a while. I agree that
>> the spec should reflect that.
>>
>> On Tue, Sep 8, 2015 at 1:19 PM Mike West < <mkwst@google.com>
>> mkwst@google.com> wrote:
>>
>>> +jochen, bz
>>>
>>> I remember talking with Boris about this, but I can't find the thread at
>>> the moment. My vague recollection was that Chrome used the URL of the
>>> document that loaded the CSS file, and Firefox used the CSS file. It sounds
>>> like that might have changed in the relatively recent past.
>>>
>>> If that's the case, we should update the spec. And by "we", I mean
>>> Jochen. :)
>>>
>>> -mike
>>>
>>> --
>>> Mike West <mkwst@google.com>, @mikewest
>>>
>>> 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.)
>>>
>>> On Tue, Sep 8, 2015 at 1:01 PM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>
>>>> Hi,
>>>>
>>>> When going through the definitions and values of the Referer header in
>>>> the referrer policy
>>>> <https://w3c.github.io/webappsec/specs/referrer-policy/> spec, I see
>>>> that the "No referrer when downgrade" policy (which is the default) is
>>>> defined as "sends a full URL", but it's not clear to me what that URL
>>>> should be. My default assumption would be that it is the URL of the
>>>> settings object/main document.
>>>>
>>>> However, when looking at font resources fetched cross-origin that were
>>>> defined by an external stylesheet, I see that the "referer" value is that
>>>> of the stylesheet, rather than that of the main document, in both Firefox
>>>> and Chrome.
>>>>
>>>> So, I guess my questions are:
>>>> * Are I missing something regarding the definitions? Is an external
>>>> stylesheet defined as a settings object of its own?
>>>> * When the referrer policy is defined as "origin", what should the
>>>> referer on such a font resource be?
>>>>
>>>> Cheers :)
>>>> Yoav
>>>>
>>>>
>>>
>>
Received on Wednesday, 30 September 2015 15:21:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:15 UTC