Live data from Hacker News

Firefox 59 to strip path information from referrer values for 3rd parties

blog.mozilla.org

81–90 of 236 posts

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#81

Earlier quoted context omitted.

Two questions: 1. What does it matter if the creators of a website are aware that a user is using private browsing to view the site? In other words, what would they do with this information? 2. As it's possible to strip out referral information using other means, assuming there's a practical use for this "private browser user" information, what could the site creators do to guard against false positives?

There are some news websites that blocks private browsing[1]. Private browsing is a method of bypass the paywall, so they they make a private-browsing-wall. 1: https://imgur.com/a/gXEtl

What is the current mechanism for them to know that you are in private browsing mode?

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#82
For those who are curious, here's some more detail on the various options.

https://feeding.cloud.geek.nz/posts/tweaking-referrer-for-pr...

Basically, set the following:

  network.http.referer.(XOriginPolicy|XOriginTrimmingPolicy|trimmingPolicy) to 2
  network.http.referer.spoofSource to true
  network.http.sendRefererHeader to 0
  network.sendSecureXSiteReferrer to false

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#83
post #32
post #16

Earlier quoted context omitted.

That would continue to work fine with a default same origin allowance. A separate domain would require a referral policy.

Origin policy is a client thing. Referrer is accessible to the server. It's like using robots.txt vs. HTTP Auth to protect your content.

Referrer is also a client thing. Referrer based hotlink protection implicitly trusts the visitors' UAs. Same for Origin; it just offloads the actual check to the visitor. No big difference.

HTTP Auth, on the other hand, is actual password protection which cannot be spoofed by a malicious client. Very different from robots.txt.

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#84
post #65

As someone that digs in this data for a living, personally strongly believe this should be on by default for all browsing. The example they give is an insanely bad design for healthcare.gov and I would absolutely not want to find that type of data in my analytics telemetry. It is very useful to know where your traffic is coming from, but that’s usually viewed at a higher level than the querystring params being shown.…

As a user I don't want you to know that information. I wish there was a way to click on links with the referer field removed entirely from the request(maybe via context menu)

I use RefControl in Firefox. I've set the default to be the root of the destination site. That is, for example, clicking a link to https://foo.com sends https://foo.com as the referrer.

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#85

Flagged this as the headline here and the headline on the blog post do not match, and the one here is not accurate and misrepresents the post.

Also it should tell that this behavior is only expected in "Private Browsing".

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#86
post #61
post #56

Earlier quoted context omitted.

It might break websites that provide features based on the referrer (eg. a central authentication that redirects back to the original page)

I can't recall ever encountering a referer-based authorization scheme that included the path or querystring in its logic--although it seems likely some goofus has implemented it, somewhere.

Considering that referer is trivially spoofable, not a great idea to rely on it for anything really.

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#87
post #53

As someone that digs in this data for a living, personally strongly believe this should be on by default for all browsing. The example they give is an insanely bad design for healthcare.gov and I would absolutely not want to find that type of data in my analytics telemetry. It is very useful to know where your traffic is coming from, but that’s usually viewed at a higher level than the querystring params being shown.…

I was somewhat shocked that healthcare.gov would have any ads on it. I missed that scandal I guess. https://www.eff.org/deeplinks/2015/01/healthcare.gov-sends-p... Anyone know if this is still the case? I looked at a couple of pages and only saw tiqcdn.com being blocked by uBlock.

That domain belongs to Tealium IQ, an alternative to Google Tag Manager.

Tag managers allow you to encapsulate third party tags (and really, any JavaScript you want) and have them dynamically injected without having to hard code anything else on the page.

Since that was blocked, you never even saw the other tags that would have attempted being ran.

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#88
post #86
post #61

Earlier quoted context omitted.

I can't recall ever encountering a referer-based authorization scheme that included the path or querystring in its logic--although it seems likely some goofus has implemented it, somewhere.

Considering that referer is trivially spoofable, not a great idea to rely on it for anything really.

So are cookies, but you wouldn't say that it's a bad idea to rely on them. Spoofing is only useful if you know the value you need to spoof.

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#89
post #50

Earlier quoted context omitted.

I don't think you can ever describe a person's name as spelled correctly or incorrectly. It's spelled how they spell it. It's their name, not a dictionary's. Variations in spelling are perfectly natural and for names in particular are incredibly common

I'm not "attacking" their parents who chose the name or anything like that, and any spelling is fine for a name, but there is a clear etymology to the name "Philip" that comes from "philos" and "hippos", someone who loves horses, and an indisputably historically correct way to spell it. That a misspelling has become particularly common (or like for my own name, much more common than the historically correct spelling)…

I think it's being argued that describing a name variation as a "misspelling" -- as in, a mistake -- is incorrect. What does the etymology or historical popularity of "Philip" have to do with it? We don't know that he has that name because he truly loves horses or because his parents attempted to honor a king of Macedonia.

I know this is treading into the classic prescriptive vs. descriptive linguistic debate, but the reason why we can call "referer" a misspelling -- rather than a creative decision - is because the original authors seem to admit that it was unintentional. Fewer folks would be calling it a misspelling if the authors had meant to do it, e.g. to avoid a name collision with some other attribute named "referrer" or to honor a colleague named "Referer".

Re: Firefox 59 to strip path information from referrer values for 3rd parties

#90

As someone that digs in this data for a living, personally strongly believe this should be on by default for all browsing. The example they give is an insanely bad design for healthcare.gov and I would absolutely not want to find that type of data in my analytics telemetry. It is very useful to know where your traffic is coming from, but that’s usually viewed at a higher level than the querystring params being shown.…

Yes it's great from a marketer's point of view. From a consumer's point of view, I don't want you to know where I came from. I don't really care if it's useful to you. It's the difference between pleasing marketers vs pleasing users. Firefox chose wisely
Post reply on HN