Hacker News new | comments | show | ask | jobs | submit login

Disclaimer: I'm the Firefox engineer who wrote the patch and the post.

We did a user research study measuring website breakage under various privacy protections:

https://blog.mozilla.org/data/2018/01/26/improving-privacy-w...

tl;dr - strict-origin-when-cross-origin was one of the protections with the lowest amount of breakage. Entering Private Browsing is a clear, strong signal that the user wants more privacy, so we started by implementing this protection in Private Browsing.

However, note that some advertisers demand that AdTech vendors must not serve their ads on certain kinds of pages. (e.g., https://support.google.com/adsense/answer/1348688?hl=en&topi...) Many of those agreements require full referrers to be able to audit the ad inventory.

So there are some concerns and trade-offs to make in this space.




In all seriousness: why should we care what ad companies want? Mozilla makes a browser, not an ad platform. Advertisers may have to adapt, but that's their problem.


In my opinion Mozilla should be actively hostile to ad companies, and go out of their way to ruin metrics


I don't think that's a good tactic. Google and other ad companies have plenty of money to spread disinformation against Mozilla, if they wanted to.

If Mozilla's users are saying “yes, this is good; please do more”, Mozilla can use that as a defence against any resistance from advertisers.


Then it would be better if Mozilla remains closer to neutral but leaves maximum space to the user for custom configurations, maybe using extensions.


Many of the ad serving SDKs slurp up all this data anyways and send it down using a request body, query string, or something that isn't the "Referer" HTTP header. I'm not sure how ad verification providers get this data, but if anything it's just going to mean less information leaking out from systems like DFP to the smaller ad tech firms. But firms like Google will still be able to figure out what path you were on.


Why don't websites just remove ad code from pages they don't want ads to appear on, instead of telling the ad server to not display it on such pages by using the referrer information? Seems like a convoluted way to solve the problem.


https://lists.w3.org/Archives/Public/public-webappsec/2014De... is a good run-down of referrer uses from the AdSense perspective.


No, the advertiser doesn’t want their ad to appear on a certain publisher’s web page (e.g. banks often can get in trouble if their ads are associated with certain kinds of content).


Ah ok. But why then doesn't the ad's embed code just contain the URL of the page it's on in the query string / POST data? The (website that shows the ad's) server knows what page it is providing.


I suspect it does? But that's spoofable by the ad aggregator in a way that the Referer header isn't. So much of ad design is (for better or occasionally for worse) defending against bad actors.


Thank you for your efforts. Features such as this are appreciated by, I'm sure, many of your users. It's a shame that the slating Mozilla has had recently hasn't been met by praise for work like this.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: