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
Firefox 59 to strip path information from referrer values for 3rd parties
81–90 of 236 posts
Re: Firefox 59 to strip path information from referrer values for 3rd parties
#82https://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 falseRe: Firefox 59 to strip path information from referrer values for 3rd parties
#83Earlier 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.
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
#84As 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)
Re: Firefox 59 to strip path information from referrer values for 3rd parties
#85Flagged 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.
Re: Firefox 59 to strip path information from referrer values for 3rd parties
#86Earlier 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.
Re: Firefox 59 to strip path information from referrer values for 3rd parties
#87As 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.
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
#88Earlier 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.
Re: Firefox 59 to strip path information from referrer values for 3rd parties
#89Earlier 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 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
#90As 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.…