#538: Referrer handling - default policy and capping

Visit on Github.

Opened Jul 21, 2020

Saluton TAG!

I'm requesting a TAG review of current and proposed handling of referrers across various browsers, as being discussed on privacycg/proposals#13.

As summarized by @englehardt on the PrivacyCG thread, referrers leak users' browsing activity cross-site. Browsers have either already shipped, or are experimenting with a combination of:

  • Applying a default policy of strict-origin-when-cross-origin - spec update in w3c/webappsec-referrer-policy#142
  • Capping the referrer to either strict-origin-when-cross-origin or eTLD+1 (Firefox and Safari selectively apply capping to classified/tracker domains).

Does the TAG have an opinion on the present disparity among browsers, and appropriate long term handling of referrers?

As @englehardt asks:

At the very least it seems like we can align on defaulting to strict-origin-when-cross-origin (see also: w3c/webappsec-referrer-policy#125). But even this default can still be overwritten by motivated adversaries. This leads to the question of why only change the default, and not permanently trim cross-site referrers with no way to override?

CC: @domfarolino @johnwilander @erik-anderson @pes10k

Discussions

Comment by @pes10k Jul 21, 2020 (See Github)

Thank you @krgovind for sharing this. Just to re-surface what I mentioned in the original discussion. Brave currently does what @englehardt is suggesting, specifically

why only change the default, and not permanently trim cross-site referrers with no way to override?

Brave does the above and have found it a useful privacy improvement and have not encountered web-compat issues

Discussed Aug 1, 2020 (See Github)

Ran out of time before we got to this.

Discussed Aug 1, 2020 (See Github)

Dan: 9 days ago they said it's going to ship.. our window of useful feedback is slipping...

Tess: off hand I think t's fine... I'd like to have more time to look at it.

Comment by @krgovind Aug 10, 2020 (See Github)

@hadleybeeman Pinging to check if this review happened last week.

If it helps expedite the review, the Chrome team would like to start by requesting a review of the first part. We are preparing to ship this change in Chrome, and would like to hear the TAG's opinion:

Comment by @domfarolino Aug 24, 2020 (See Github)

Ping TAG. Chrome is planning on shipping this, especially because we have full cross-browser consensus on changing the default referrer policy. There is still discussion on whether or not we should let sites apply a looser policy, but as the editor of the Referrer Policy spec, I don't think that should block this.

Discussed Sep 1, 2020 (See Github)

Tess: it seems like a good thing to write down... Everyone is doing this to some extent. However it's specified should allow browsers to be more aggresive than the baseline. Brave unconditionally does this to all sites (for example) and people uses Brave because they expect it to err on the side of privacy even when compat is impact - and they haven't seen any compat impact so far.

... One of the things I think is relevant : simplicity and consistency are both important for developer expecation and understanding. So I'm sympathetic to the argument by Pete Snyder and Steven Englehart - why make the weaker change and just permenantly change referrers everywhere. The brave data suggests that there is no compat impact.

... we could say "We're glad everyone is trying to mitigate this concern. It would be good if it could be more consistent for developers."

Dan: Is that the kind of feedback they are looking for?

Tess: Yeah. They want to hear the TAG's opinion.. Suggest it should be "that sounds like a good change but in addition... " the simpler mdoel.

[agreed Tess to write the feedback and we will mark as "proposed close" and close at the plenary

Comment by @torgo Sep 2, 2020 (See Github)

Hi @domfarolino - thanks for heads up - we haven't had t a chance to really put this on the table for TAG discussion yet unfortunately. I'm going to put it on our agenda for w/o 14th Sept - I hope we can still provide useful feedback at that point.

Discussed Oct 1, 2020 (See Github)

Rossen: main question - does the TAG have an opinion on present day disparity between browsers... moreso than the actual proposal.... I don't think we've discussed that particular part....

Dan: having disparity between browsers is bad.

Rossen: yes especially when it comes to privacy. Expectations from users ...

Rossen: current handling in Safari and Firefox...

Hadley: they've broken it down by browser in their issue 13. ... what they are toying with doing is standardizing removing the referrer in an HTTP call? In certain contexts - like crossing origins. If that's correct than 1st thought is it's an IETF spec. I think they're right that this would impact the ad ecosystem.

... feels like to me the first thing, looking at their issue 13 - privacy cg

... personally I understand and agree with their concern that referers leak browser activity - but it would be helpful to lay out use cases... Where people are using it now. Feels like we should ask them for the use cases... Without the use cases this feels like the kind of thing that could be well intentioned but could screw up usefu stuff.

Rossen: An ask from the edge engineering team to chime in - we experimented in the dev channel - comment from April 30th.

Rossen: ripple effect - in making such changes often difficult to detect. Tips the balance between privacy & functionality?

Dan: are the perceived losses in functionality from an end user persctive or from a publisher or advertiser perspective?

Rossen: not being able to process a payment - is a pretty fundamental thing. I don't know how much of the tail end of the web this effects. 1st example is the one that gives me the most heartburn. How much in the tail end will break because of something like this? Will impact users, publishers and advertisers.

Hadley: I'm not necessarily against breaking things. But... in /TR space we have normative references - in CSP 2 ... CSP violation reports...

Rossen: HTML refers to it a lot - document.referrer.

Dan: one thing thay comes to mind - Brave docunmented their more restrictive approach here - but it's not clear to me that their approach is the same as what you're talking about, Rossen – would the.... Is there any consensus about what change in policy would be positive privacy but not break stuff....?

Hadley: I think what we have at the top of our issue - "At the very least it seems like we can align on defaulting to strict-origin-when-cross-origin"... But "But even this default can still be overwritten by motivated adversaries. This leads to the question of why only change the default, and not permanently trim cross-site referrers with no way to override?" which they go on to say that Brave has done and not encountered web compat issues.

... they go on to say - chrome is planning on shipping. as there is cross-browser consensus on chaning default referer policy. If that's the case.

Dan: we could say "That sounds good to us . we think more strictions (permanently trim cross-site referrers) would be good as well. More work needs to be done to explore where this would potentially break existing content - especially in the long tail."

Hadley: seems ok - ...

Comment by @torgo Oct 12, 2020 (See Github)

We've discussed today in the TAG breakout - That sounds good to us ("align[ing] on defaulting to strict-origin-when-cross-origin"). We think more restrictions ("permanently trim cross-site referrers") – aligned across browsers – would be good as well. It looks like more work needs to be done to explore where this would potentially break existing content - especially in the long tail.

Discussed May 1, 2021 (See Github)

This has been marked propose close since October. Let's try to close it in the rollups.

Discussed Jun 1, 2021 (See Github)

Both: Think this can be closed during plenary

Comment by @torgo Jun 23, 2021 (See Github)

This slipped off our radar to actually close the issue although we had agreed to close it so we are closing it now. ✨