Re: Referrer Policy: Same-origin URIs

Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
> For better or worse, we live in a world with ads and analytics
> everywhere. You could argue that this should be done at the
> server-side but analytics and ad conversion trackers are often purely
> client-side and one of the things that is exciting about this group is
> how we are trying to improve security with the acknowledgement that
> such mashups are the reality.

I agree. But, aren't analytics and ad conversion trackers usually
third-party services, such that they wouldn't be covered by your
proposal, which is restricted to same-origin?

> The reality is that origins (for SEO etc) are too coarse grained
> (heck, that's why we are working on sub-origins). Even for same-origin
> referer flows, it would be nice to be able to control the URL: a user
> clicking on a buy link on /some/internal/path/with/mildly/private/data
> ends up on /buy; the document.referer value there doesn't need nor
> should it have the full referer value.

I agree.

> Additionally, I just don't think adding a URI value in the policy
> directive is that much addition in complexity. It is just adding a
> "host-source" in the ABNF for "referer" directive.

That syntax is more than you need, and more error-prone than you need.
Given a restriction to same origin, specifying the scheme and hostname
is redundant at best and a source of security issues at worst.

Consider a document at https://example.com/a/b/c/d/?wut. Which of the
following are you proposing to be valid values for the Referer from
this document under your what you are proposing?:

https:
https://
https://example.com/ (equivalent to 'origin')
https://example.com/a
https://example.com/a/
https://example.com/a/b/
https://example.com/a/b/c/
https://example.com/a/b/c/d
https://example.com/a/b/c/d/
https://example.com/a/b/c/d/?
https://example.com/a/b/c/d/?w
https://example.com/a/b/c/d/?wut
https://subdomain.example.com/
https://total-lie.example.com/made-up?tricking-you

Would the allowed values differ for same-origin navigation vs.
non-same-origin navigation? My guess is that you are proposing only
these would be valid, and only for same-origin navigation:

https://example.com/ (equivalent to 'origin')
https://example.com/a/
https://example.com/a/b/
https://example.com/a/b/c/
https://example.com/a/b/c/d/

Cheers,
Brian

Received on Sunday, 9 November 2014 02:30:29 UTC