Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.mozilla.org

Post reply on HN
Print view View original

51–60 of 236 posts

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

#51

Post by robocat »

djsumdog wrote: post #35
franciscop wrote: post #12

Earlier quoted context omitted.

Just curious, did it break any popular website?

I breaks a lot of things that do hotlink checks. Maybe only allow a referrer from the same site policy?

> [It] breaks a lot of things that do hotlink checks.

The majority of hotlink checking is to disable cross-domain hotlinking, which is not affected by this change.

This change could only negatively affect hotlinking that is permitted.

A site that wishes to hotlink to another may need to set a Referrer-Policy sso that the referer is passed through for images at all times.

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

#52

Post by LukeShu »

x775 wrote: post #6

In about:config, setting 'network.http.sendRefererHeader' to 0 (default is 2) will stop the referer header from being sent, and the document.referrer from being set. See http://kb.mozillazine.org/Network.http.sendRefererHeader for more information.

That page is quite outdated (2007), a better reference for about:config referrer options is https://wiki.mozilla.org/Security/Referrer (which is linked to at the bottom of the blog post about FF59 being discussed).

It seems that Firefox 59 will effectively force about:config's network.http.referer.XOriginTrimmingPolicy to 2 (default is 0) when in private browsing.

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

#53

Post by ams6110 »

sologoub wrote: post #34

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.

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

#54

Post by Momquist »

yborg wrote: post #24
x775 wrote: post #6

In about:config, setting 'network.http.sendRefererHeader' to 0 (default is 2) will stop the referer header from being sent, and the document.referrer from being set. See http://kb.mozillazine.org/Network.http.sendRefererHeader for more information.

https://github.com/meh/smart-referer Configurable referer behavior, including whitelist.

uMatrix also has a similar feature, among many others (request blocking by type, cookie and cache management, etc...)

https://github.com/gorhill/uMatrix

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

#55

Post by will4274 »

godelski wrote: post #43
sologoub wrote: post #34

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 someone that doesn't dig into this data for a living, why would you not want this on non-private sessions (first question I had when reading this)? I'm curious why Mozilla wouldn't want to protect this data leaking in even a normal session.

> why would you not want this on non-private sessions

Information leaks. You click a link from your email to a news article. The URL for the news article has your email in it. Then you click an ad on the news article. The ad just got your email address.

Worse still - instead of an email address, it's a token that auto signs you in to your account with the news site.

Sites are pretty bad at sanitizing their outgoing referers.

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

#56

Post by progval »

godelski wrote: post #43
sologoub wrote: post #34

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 someone that doesn't dig into this data for a living, why would you not want this on non-private sessions (first question I had when reading this)? I'm curious why Mozilla wouldn't want to protect this data leaking in even a normal session.

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

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

#57

Post by yeukhon »

godelski wrote: post #43
sologoub wrote: post #34

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 someone that doesn't dig into this data for a living, why would you not want this on non-private sessions (first question I had when reading this)? I'm curious why Mozilla wouldn't want to protect this data leaking in even a normal session.

My speculation is that this is a compromise in some sense. The change here aligns with what private session is supposed to be.

Private browsing will(1) start out with no sessions (none from normal browsing mode), (2) provides automatic tracker protection, and (3) will clear sessions (cookies and history) on exit leaving no trace. Private browsing is great for a number of use cases such as debug/test web app with a new session, visit NSFW, or hide the fact you watch cat videos on your puppy-lover friend's computer.

So it makes sense to hide the referrer in private sessions opt-in automatically. As for the normal browsing, you can disable referrer. See [1].

I would like to see more privacy and security options to be shown in the preferences UI. about:config is "okay" but it feels like Windows registry, not good for user experience, even by developer standard when one just want to toggle on/off privacy and security settings.

[1]: https://askubuntu.com/questions/797135/how-to-disable-http-r...

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

#59

Post by tetromino_ »

makecheck wrote: post #28

E-commerce checkout codes, etc. are the only reasonable form of referral. In other words, if I give you something voluntarily that tells you where I came from, fine; otherwise, why do we have so much auto-leaking built into protocols?

To stop hotlinking from DOSing cheaply-hosted websites. Few niche hobbyist forums can afford big pipes and Cloudflare.

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

#60

Post by eitland »

makecheck wrote: post #28

E-commerce checkout codes, etc. are the only reasonable form of referral. In other words, if I give you something voluntarily that tells you where I came from, fine; otherwise, why do we have so much auto-leaking built into protocols?

Was very handy to find other people linking to your site, often people with similar sites to yours.

Also I remember someone I know got an email that a page ge was linking to was about to move. I guess this was only possible because of the referer header.

Post reply on HN