Re: [REFERRER] 3 of 4 policy states are worst than the default

On 15 Aug 2015, at 00:04, Francois Marier <francois@mozilla.com> wrote:
> - I couldn't think of a use for an author limiting same-origin referrers
> to origin, so I didn't include the existing "origin-only" policy.




If hosting multiple micro sites, where one does not trust the other, but still wants to see that the request came from the same domain?

https://www.example.com/drive/

https://www.example.com/analytics/


I think they should probably be looking at sub-domains anyway, but realise that there has been some work on a suborigin idea:

https://www.chromium.org/developers/design-documents/per-page-suborigins



On 15 Aug 2015, at 00:04, Francois Marier <francois@mozilla.com> wrote:
> Which means that if we wanted to let authors control this fully, we
> would allow them to do something like:
> 
>  referrer="same-origin=full cross-origin=origin downgrade=none"



I do like the flexibility this full header would provide, and I think I would find this easier to read (as a human, not parsing as a computer).

But as an aside, this is why I'd appreciate a list of examples to demonstrate what each policy does:

https://github.com/w3c/webappsec/issues/414









On 15 Aug 2015, at 00:04, Francois Marier <francois@mozilla.com> wrote:

> On 05/08/15 12:50 AM, Mike West wrote:
>> This behavior is to a large extent the entire point of Referrer Policy.
>> If we don't give sites a way around the default behavior or dropping the
>> referrer on downgrade, they'll do it themselves via insecure redirects
>> (e.g. 't.co <http://t.co>').
> 
> Good point, I hadn't considered that. You (and Brad) are right.
> 
>> Perhaps we could offer something like what you want as an addition
>> (though I'm not sure I understand the use case (nor do I have a good
>> naming suggestion)).
> 
> I looked into this more carefully and identified three different kinds
> of relationships between a page and one of its resources/links:
> 
> 1. same-origin: e.g. https://example.com/index.html ->
>   https://example.com/other.html
> 
> 2. cross-origin: e.g. https://example.com/index.html ->
>   https://example.net/index.html
> 
> 3. downgrade: e.g. https://example.com/index.html ->
>   http://example.net/index.html
> 
> Then we have three "levels" of referrer we can send:
> 
> - full: e.g. https://example.com/index.html
> - origin-only: e.g. https://example.com
> - none
> 
> Which means that if we wanted to let authors control this fully, we
> would allow them to do something like:
> 
>  referrer="same-origin=full cross-origin=origin downgrade=none"
> 
> I'm not suggesting that we allow authors to use every possible
> combination however. I think we can simplify this and only offer the
> combinations that make sense:
> 
> 1. same-origin=none cross-origin=none downgrade=none ("no-referrer")
> 2. same-origin=full cross-origin=none downgrade=none
> 3. same-origin=full cross-origin=origin downgrade=none
> 4. same-origin=full cross-origin=full downgrade=none
> ("no-referrer-when-downgrade")
> 5. same-origin=full cross-origin=origin downgrade=origin
> ("origin-when-cross-origin")
> 6. same-origin=full cross-origin=full downgrade=origin
> 7. same-origin=full cross-origin=full downgrade=full ("unsafe-url")
> 
> Notes:
> 
> - I couldn't think of a use for an author limiting same-origin referrers
> to origin, so I didn't include the existing "origin-only" policy.
> 
> - Combinations 1 to 4 are all at least as safe as the default one.
> 
> - Combinations 2, 3 and 6 are not currently in the spec.
> 
> - I'm not sure whether or not we need #6.
> 
> - I would personally use #2 or #3 on my sites.
> 
> Francois
>

Received on Monday, 17 August 2015 09:32:16 UTC