#538: Referrer handling - default policy and capping
Discussions
2020-08-31
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.
2020-09-14
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
2020-10-12
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 - ...
2021-05-Arakeen
This has been marked propose close
since October. Let's try to close it in the rollups.
OpenedJul 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:
strict-origin-when-cross-origin
- spec update in w3c/webappsec-referrer-policy#142strict-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:
CC: @domfarolino @johnwilander @erik-anderson @pes10k