Re: Referrer Policy: Same-origin URIs

Forgive my bad example, but lets not get distracted by secrets in GET
URLs (I share Michal's views from the last email on the theory and the
practical reality ;)

Michal said:
> Thinking a bit more about this: it's probably more reasonable if
> you're hoping to safeguard tokens from ending up in various Referer
> analytics reports for unrelated parts of the site (the access to which
> may be delegated to people who have no interest in seeing the URLs).

That's exactly the use case I was thinking of. And this doesn't have
to be a "secret" in the cryptographic sense, but it can be data that
is private.

For example, referers of the form en.wikipedia.org/wiki/Hello are bad,
since when linked with user name and over enough time, they are
particularly sensitive. On the other hand, for most analytics, what
matters is that "this was from the en.wikipedia.org/wiki/". Similarly,
the particularly user-id from which I clicked on an ad on a social
network is not important (and user expects that to remain private),
but it is useful to know that it was socialnetwork.com/users and so
on.

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 still feel that if we're adding so much complexity to the directive,
> we should probably just bite the bullet and allow people to specify

I think that your comment is orthogonal to this proposal.
Your complaint is more about how "origin-if-cross-origin" is too
coarse grained. My complaint is more about how "origin, full-url,
nothing" are not the only options we should provide.

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.

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.

cheers
Dev

On 8 November 2014 15:45, Michal Zalewski <lcamtuf@coredump.cx> wrote:
> Well, theoretically, yes. In practice, usability sometimes trumps that
> due to user demand. "Anyone with a link" is a sharing model used by
> quite a few services, since the alternative (forcing all participants
> of a chat or all collaborators on a document) to register with a
> particular website, log in, and have explicit ACLs created... well,
> often isn't all that great.
>
> /mz
>
> On Sat, Nov 8, 2014 at 3:22 PM, Jim Manico <jim.manico@owasp.org> wrote:
>> Please forgive my (continued) ignorance, but isn't keeping secrets out
>> of GET requests the law of the land for secure web application
>> development?
>>
>> Aloha,
>> --
>> Jim Manico
>> @Manicode
>> (808) 652-3805
>>
>>> On Nov 9, 2014, at 6:48 AM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>>>
>>> Thinking a bit more about this: it's probably more reasonable if
>>> you're hoping to safeguard tokens from ending up in various Referer
>>> analytics reports for unrelated parts of the site (the access to which
>>> may be delegated to people who have no interest in seeing the URLs).
>>>
>>> I still feel that if we're adding so much complexity to the directive,
>>> we should probably just bite the bullet and allow people to specify
>>> policies for domains in a CSP fashion, i.e., detailed referrer goes to
>>> *.google.com, *.google.com.pl, *.facebook.com/foo, origin referrer
>>> goes to *, etc. It would let people use analytics across multi-domain
>>> properties while reaping the benefits of a safe default for the rest
>>> of the Internet.
>>>
>>> /mz
>>>

Received on Sunday, 9 November 2014 01:46:49 UTC