[HN Gopher] Firefox 87 trims HTTP Referrers by default to protec...
___________________________________________________________________
Firefox 87 trims HTTP Referrers by default to protect user privacy
Author : twapi
Score : 848 points
Date : 2021-03-22 12:07 UTC (10 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| nofinator wrote:
| This made me wonder how to do it now, in Firefox 86. I found this
| helpful page: https://askubuntu.com/questions/797135/how-to-
| disable-http-r...
|
| TL;DR about:config --> Network.http.sendRefererHeader --> change
| value from 2 to 0
| jefftk wrote:
| That fully removes the header, instead of stripping it down to
| just the origin as they're going to be doing.
| floatboth wrote:
| network.http.referer.defaultPolicy is the correct one
| [deleted]
| tomaszs wrote:
| I don't understand what Mozilla does to Firefox anymore. What
| does it mean a page "can" leak private data?
|
| Is there any story about anyone affected by the issue? Does this
| issue even exist?
|
| It is just breaking another piece of the open web.
|
| It just seems like Mozilla not only surrendered in gaining
| browser market but also actively acts against open web.
|
| I thought website creators and website users should be in charge
| of what they want to do. But it seems no. Now Mozilla decides
| what web standards can be broken.
|
| I'd maybe applaud changes by Mozilla, but with all of these
| efforts it is not aimed in gaining more users. Firefox does not
| gain users with such actions. It does not make any sense what is
| the aim of Mozilla anymore with Firefox.
| Ayesh wrote:
| > Is there any story about anyone affected by the issue? Does
| this issue even exist
|
| Yes. Yes it does.
|
| Imagine, a web site that has a query parameter with a secret
| (password reset pages, email unsubscribe, custom feeds, etc).
| Any images or other assets used in the page will receive the
| full URL as the referrer, so they can see those secrets.
|
| GitHub fixed this very issue a few years ago. They have a
| feature to get custom RSS feeds for user activity. There is a
| secret worry parameter in the URL, and any third party images
| were receiving that full URL.
|
| Referrer-Policy header is already supported in many browsers.
| fvv wrote:
| If it's a page that contain or receive secret should be using
| https where referrer is already stripped off
| jefftk wrote:
| Firefox was using no-referrer-when-downgrade, which only
| strips refers when navigating from HTTPS to HTTP.
|
| They are switching to strict-origin-when-cross-origin,
| which cuts the referrer down to just the origin when
| navigating to a different origin.
| tomaszs wrote:
| So where is a real life example?
| iso1631 wrote:
| RFC-1945: Because the source of a link may be private
| information or may reveal an otherwise private information
| source, it is strongly recommended that the user be able to
| select whether or not the Referer field is sent. For example, a
| browser client could have a toggle switch for browsing
| openly/anonymously, which would respectively enable/disable the
| sending of Referer and From information.
|
| So not sending referrer has always been fine, and I suspect
| that firefox will have an option to enable the sending
| somewhere in it.
| pjmlp wrote:
| Normal people are going to switch browser instead of trying
| to find the said option, because Firefox is "broken".
| Mordisquitos wrote:
| Normal websites are going to be unaffected in terms of
| user-facing functionality, regardless of whether they use
| the data gathered from HTTP Referer internally. On the
| other hand, badly designed websites that do depend on the
| HTTP Referer to provide functional user experience are
| going to lose their users in favour of normal websites,
| because _they_ are "broken"--and always have been.
| wccrawford wrote:
| I would say that most "normal people" don't even know the
| browser sends a referrer header, and it doesn't actually do
| anything for them.
|
| This is useful for site owners, and they have little
| control over what browser their users use.
|
| And as someone else already pointed out, the other big
| browser (Chrome) has already done this.
| fogihujy wrote:
| Why would this break anything? Which sites would break just
| because the referrer policy default setting changed? And
| why wouldn't sites have fixed that before, since Chrome
| pushed the same change last year?
| RHSeeger wrote:
| Switch to what, exactly? Chrome already does this,
| according to another poster.
| darkwater wrote:
| According to Wikipedia [1] the "Referer" (sic) HTTP header is
| an _optional_ one so I don 't see how they are breaking the
| open web by sending less data in it under some circumstances.
|
| [1] https://en.wikipedia.org/wiki/HTTP_referer
| selykg wrote:
| If the referrer header contains the full URL from which the
| user came from it could contain something the user deems
| private.
|
| Imagine that the URL contains a search string that contains
| something the user might deem private, or the article is about
| something a state may deem to be illegal, etc.
|
| This may not be PII but it could be deemed private by the user.
| The user should be in control of what information could be
| given to a website. Imagine a scenario where a person is a
| member of a group that is looking for equal rights in a country
| that is very much opposed to this. The group uses a tool that
| happens to make it clear who this group is. The group then
| links to an article about their cause or similar. Now that
| country could potentially link things together and demand
| information about everyone in that group.
|
| It's amazing how little bits of information about you can get
| you in hot water.
|
| This is a good move imo, and I'm glad that Mozilla is trying to
| plug these types of things. It's better for everyone.
|
| As an aside, moving to a privacy oriented browser could very
| well get Firefox more users. Just like Apple's play to being a
| private and secure mobile OS is getting them users.
| tomaszs wrote:
| So where is the example?
| selykg wrote:
| I think you've been given plenty.
|
| You should try to come into these conversations with a lot
| less attitude. Perhaps I'm reading your tone wrong, and if
| I am I'm sorry about that.
|
| I always come into these discussions assuming I'm not the
| smartest person in the room because that means I have more
| to learn. Maybe give that a try?
| [deleted]
| jakub_g wrote:
| As a user I love stricter privacy. As a developer working for a
| platform company whose content (video) is embedded by thousands
| of websites, I hate this particular change:
|
| - more difficult to analyze weird / fraudulent embedders
|
| - more difficult to debug issues ("what's the sample URL to
| repro? no sample URL in logs, only top-level of the domain, but I
| don't find our embed anywhere -\\_(tsu)_/-")
|
| Funny thing: you can't just tell your embedding partners to
| change the embed code and use `referrerpolicy=...` on the iframe,
| to expose the full URL, because it's not GDPR-compliant
| apparently. So you need user's consent first. But how do you
| obtain user's consent before you render HTML on the server? :)
| ("GDPR wall" is not compliant either)
|
| Life sucks, I guess. But it's for greater good, and I guess the
| companies will somehow survive.
| [deleted]
| Black101 wrote:
| It's about time...
| gianfrid wrote:
| Nice, I'm using SmartReferer (https://addons.mozilla.org/en-
| US/firefox/addon/smart-referer...), I'm always happy to drop an
| extension when Mozilla natively implements the same feature
| ChrisGranger wrote:
| Smart Referer is even stricter than this new policy if you
| don't use the recommended 'Lax' setting. It will block referers
| even on the same domain but to different subdomains, if you
| want it to.
| bitmapbrother wrote:
| Kind of amusing that Chrome did it first (and the Firefox
| implementation was likely copied), yet Firefox gets the fanfare.
| Just an observation.
| codegeek wrote:
| So if someone does want to use http referrer for any reason (e.g.
| only load a certain asset if coming from internal URL/specific
| referrer), what needs to be done ?
| jefftk wrote:
| Checking for a specific internal URL will still work: they're
| changing the default cross-origin behavior.
| surajs wrote:
| your privacy will become the joke
| AdmiralAsshat wrote:
| Will Firefox trim their own header additions when searching?
|
| e.g. here's the page that Firefox generates when I try to search
| "Dragon Quest XI" in a Private Window on Amazon via the address
| bar:
|
| https://www.amazon.com/s?k=dragon+quest+xi&link_code=qs&sour...
|
| Note the 'mozilla-20' tag at the end.
| inigoesdr wrote:
| That's not the same as the referrer header; it's mostly
| invisible to the end user without inspecting the raw request
| data.
| SquareWheel wrote:
| That's an affiliate link. It seems then Mozilla is injecting
| affiliate codes on Amazon searches.
| idclip wrote:
| Wish i was able enough to help Web servers cull http and be https
| per default rather than offer complex alternatives that are often
| hard and multi step to implement.
| ing33k wrote:
| any chance that a few CORS implementations will break due to this
| ?
| capableweb wrote:
| No.... ? Not as far as I could gather. Why would CORS break
| because of this change? AFAIK, CORS has nothing with the
| referrer header.
| gruez wrote:
| he's probably talking about referrer checks which are used as
| a mitigation against csrf
| gruez wrote:
| It only trims path and query information so it should be fine
| unless the site is overzealous and checks those.
| e12e wrote:
| I think there'd be a bit less panic in the comments if the
| title/headline reflected that the change (as I understand it)
| applies cross-origin and cross-scheme (http > tls). So if you're
| preventing hot-linking of assets, this should not affect you (or;
| you have some control over it via policy):
|
| > this new stricter referrer policy will not only trim
| information for requests going from HTTPS to HTTP, but will also
| trim path and query information for all cross-origin requests.
|
| Seems like a fairly balanced way to protect privacy along with
| preserving utility?
| NelsonMinar wrote:
| And so the dream of bidirectional hyperlinks finally dies. Turns
| out not only do we not need them, in most cases you really don't
| want them.
| superkuh wrote:
| Yes. This makes surfing the web harder and will result in more
| centralization within proprietary walled gardens instead of
| federation via protocol mechanisms.
| myfonj wrote:
| Oh, I'll really miss occasionally peeking at AWStats and
| discovering weird pages pointing at my weird pages :(
|
| This subtle aspect of web had been always strangely appealing for
| me: people leaving trails in access logs and building real
| "footpaths" network of synapses between HTML _documents_ , across
| origins. Sad to watch it dying, however beneficial and
| understandable it is.
|
| I feel it didn't have to be this way: maybe if GET wasn't so
| widely misused recently and generally everybody knew what to
| _not_ put in URL and acted accordingly, we could have preserved
| such nice things.
| stevenicr wrote:
| Similar here, and as I have written recently:
| https://news.ycombinator.com/item?id=26532433
|
| I feel that this could easily be a user toggle-able option near
| the url bar - and that people could choose to send referrer and
| search parameters to sites they like - and I could understand
| certain medical terms and what-not maybe people wanting to keep
| more hidden.
|
| I'm all for the browser taking control of this and giving the
| users options - love to be able to have the web site detect
| this and add a box saying 'hey would you mind sharing referral
| and or search term with us"
|
| It really helps when trying to figure out if you should be
| adding more content for 'term-mainly-X-demo' might be searching
| or for sure should be adding more content for other terms
| people are definitely searching for.
|
| I would imagine that many people would like to hide referrer
| for fbook, most of my sites I would think people would be
| willing to help with providing such info.
|
| as far as webmastering and stats to try to help visitors - it
| appears google is keeping more and more data to themselves, and
| now firefox is making it less transparent too.
|
| I see there is a link to the referrer policy for your site, but
| nothing about begging the user to include the info when
| visiting - oh well.
|
| awstats and similar have helped troubleshoot and helped expand
| many sites for many years and now another nudge to install
| third party slow-ware google-stats.. I just, sigh.
| behnamoh wrote:
| > I feel that this could easily be a user toggle-able option
| near the url bar...
|
| No ordinary user wants to deal with that much complexity.
| skinkestek wrote:
| But why have we decided lately to fall for the tyranny of
| what "ordinary users" want?
|
| Why can't we have a full featured Firefox hidden behind a
| setting, so this mythical "ordinary user" can have a dumbed
| down interface and the rest of us can have a real browser?
| antonvs wrote:
| > But why have we decided lately to fall for the tyranny
| of what "ordinary users" want?
|
| For the same reason bank robbers rob banks. That's where
| the money is. The source of the funding that pays for
| development of these tools is driving this.
|
| I'm not defending that situation, that's just the way it
| is. "Hackers" working on what they find technically
| elegant and useful are not driving these sorts of
| changes.
| [deleted]
| behnamoh wrote:
| "mythical" ordinary user? Have you been living in the
| world recently?
| stjohnswarts wrote:
| It's not really important enough to be a visible element on
| the bar. It would be a good compromise to bury an opt-in
| somewhere in settings though. Firefox is doing the right
| thing here by making it default and uncomplicated.
| simias wrote:
| You'll still get the source domain name, you just won't be able
| to see the full path. Of course how useful it is will depend on
| the source website, if it's "news.ycombinator.com" it won't be
| too difficult to find the post, if it's "facebook.com" it'll be
| a tad more complicated.
| leephillips wrote:
| Totally agree. As almost no one uses anything like webmentions,
| this was the way to discover who was linking to your site. (And
| because the Google link tool didn't seem to return much actual
| information.)
| myfonj wrote:
| From a glance at MDN [1] and specs [3] it seems at least we
| can still opt-in our sites to suggest visitors user agent to
| pass full referrer address along outgoing links; there seems
| to be three ways to do so: # 1. Apache conf
| Header set Referrer-Policy "no-referrer-when-downgrade"
| <!-- 2. meta HTML head with same effect [2] --> <meta
| name="referrer" content="no-referrer-when-downgrade">
| <!-- 3. HTML anchor attribute --> <a
| href="https://..." referrerpolicy="no-referrer-when-
| downgrade">
|
| This will pass full path and query when navigating between
| HTTPS to foreign origin. I guess it will be lost in http: to
| https: redirects. `unsafe-url` value would do it even for
| HTTP.
|
| (Funny all three have different spelling, and that in effect
| they direct value of a single HTTP header with inherently
| erroneous spelling.)
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Re... [2] my guess using `<meta
| http-equiv="Referrer-Policy" content="no-referrer-when-
| downgrade">` should do the same, but is not explicitly
| mentioned anywhere. [3] https://w3c.github.io/webappsec-
| referrer-policy/
| simias wrote:
| Note that it only works if it's set on the _source_ page,
| for obvious reasons. So if you set these headers on your
| page the browser will send the referrer when browsing away
| from your page, but not when your page is the target.
| nerdponx wrote:
| Bring it back! https://news.ycombinator.com/item?id=26401955
| ehsankia wrote:
| Absolutely, I loved seeing spikes in my traffic and going to
| the reddit/HN thread that caused it. I guess you still can
| manually figure it out using a search engine maybe, but like
| you said the smaller weird ones will go under the cover
| probably.
| kevincox wrote:
| Exactly. I am torn on this feature. On one hand this is the
| correct default for privacy, there are a number of websites
| with somewhat sensitive information in the URL. But relying
| on a search engine or webmaster tools to crawl the entire web
| to see where your traffic is coming from is a real shame.
| Especially because it will have an inevitable delay.
| stjohnswarts wrote:
| It is a fun feature, but privacy generally trumps such
| things since they are constantly being used by various
| entities for bad purposes.
| gscott wrote:
| The next step is not knowing where your visitors are coming
| from and having to only buy google ads rather then creating
| affiliate relationships. It is too bad FireFox is playing
| into this, it is not helping anyone's privacy. It only
| lines Google's pockets.
| Dylan16807 wrote:
| Using and needing the exact url to form an affiliate
| relationship sounds like a very rare situation.
|
| And I don't know how you can say it doesn't help privacy
| with a straight face.
| fragileone wrote:
| Affiliates can still use things like personalised
| discount codes, script-based tracking, etc. There's still
| numerous ways for affiliates to exist.
| TheRealPomax wrote:
| Why? What happened here is a change to the default value when
| https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re...
| value if it's left unspecified. Set it to what you want, and
| this change doesn't affect you?
| zerocrates wrote:
| It's the policies of the external sites that matter to the
| parent poster, not their own.
| TriNetra wrote:
| yes, for content-only sites it makes perfect sense. For sites
| hosting private data requiring login, (especially if there's
| some sensitive information in the URL) it poses a risk.
| forgotmypw17 wrote:
| Yeah, the big sites will still get to see the data though, so
| if you just become an employee, you can probably still get it.
| collsni wrote:
| I have sending the referrer header for years in firefox, if a
| site doesn't accept it I just go somewhere else.
| qertoip wrote:
| Good.
| dbg31415 wrote:
| Does Firefox 87 still make my MBP a toaster when I turn on a Zoom
| call through Firefox?
|
| Power usage for same streaming video call on Safari vs. Firefox.
|
| https://i.imgur.com/I7T19d0.png
| hu3 wrote:
| Does that still apply for M1?
| dbg31415 wrote:
| No, Intel-based.
| hu3 wrote:
| I know. I meant to ask if Firefox on M1 has the same
| behavior.
|
| I guess I'll ask a colleague at work.
| hn_throwaway_99 wrote:
| And just a reminder that it's always a good idea to set Referrer-
| Policy regardless on sites you own.
| arbuge wrote:
| It's good advice, but bizarrely some browsers ignore Referrer-
| Policy, even when it requests "no-referrer", which basically
| _increases_ the privacy level to the maximum possible - beyond
| for example the origin-only settings which the browser defaults
| are now tending towards (such as with this Firefox update).
|
| In my testing, all recent versions of Safari on iOS were the
| worst offenders here. I talked more about this here:
| https://twitter.com/arbuge/status/1354805900268105743
|
| You would think that Safari would jump at the chance to show no
| referrer, given Apple's attempts to position themselves as
| champions of user privacy, but for some reason the opposite is
| in fact true.
| jwilk wrote:
| What does ITP stand for?
| arbuge wrote:
| Intelligent Tracking Prevention.
| 1vuio0pswjnm7 wrote:
| I never send a referer header. This has zero effect on my "user
| experience".
| aimor wrote:
| I'm surprised it took this long, and it's still not completely
| gone. I've never understood the history of why http referer
| exists (original intent) or why the user would benefit from
| sharing it.
| jameshart wrote:
| The original HTTP specification really didn't think of the web
| as an adversarial environment. The RFC that specified the
| 'referer' header [1] described it as having the following
| purpose: [Referer]... allows the client to
| specify, for the server's benefit, the address (URI) of
| the resource from which the Request-URI was obtained.
| This allows a server to generate lists of back-links to
| resources for interest, logging, optimized caching,
| etc. It also allows obsolete or mistyped links to be traced for
| maintenance.
|
| The idea of how a user benefits from sharing it was that it
| would help the webmasters upon whom they were reliant to do a
| better job of curating their websites. It clearly expects a
| benevolent relationship between the owner of the linked site,
| the host of the link, and the user. Idealistic, sure, but
| understandable in a collaborative, academic context.
|
| [1] https://tools.ietf.org/html/rfc1945#section-10.13
| Scoundreller wrote:
| Google largely killed this when they moved to https by default,
| but I missed reviewing what search terms visitors used to visit
| my site and then creating content to answer their actual
| questions, instead of guessing.
|
| But the web was a much smaller place/time back then.
|
| Oh, and seeing people search for my uncommon name...
| edent wrote:
| Here's a practical reason for doing this.
|
| https://shkspr.mobi/blog/2018/01/mailchimp-leaks-your-email-...
|
| A few years ago, I discovered that referrers from MailChimp let
| you unsubscribe people from lists, and see their email addresses.
| avsteele wrote:
| Doesn't this just push people to more tracking cookies? How are
| sites supposed to know what sources are driving their traffic?
| Whether visitors are coming via email campaigns, google, etc?
| contravariant wrote:
| A popular approach seems to be to use customized URLs. Which is
| of course always an option, though ClearURLs takes care of a
| few common options.
|
| Besides it's up to a user whether they want to tell you where
| they came from, you aren't _supposed_ to know anything, you are
| _allowed_ to.
| jbverschoor wrote:
| Back in the days, there'd be a jsessionid in the url :-)
| andrewaylett wrote:
| Thanks for the pointer -- not come across Clear URLs before.
|
| https://addons.mozilla.org/en-GB/firefox/addon/clearurls/ in
| case anyone else has also not seen it.
| nkrisc wrote:
| As a visitor to your web site: not my problem and you've no
| right to know anyway what I visited before coming to your site.
| That fact that you can still see the referring domain is still
| too much, in my opinion.
| gxnxcxcx wrote:
| In Firefox, "network.http.referer.spoofSource = true" takes
| care of that last bit. The only thing it breaks for me is
| codepen.io, which fortunately I don't use.
| viraptor wrote:
| UTM tags mostly https://www.intownwebdesign.com/google/google-
| analytics-utm-...
| gspr wrote:
| > How are sites supposed to know what sources are driving their
| traffic? Whether visitors are coming via email campaigns,
| google, etc?
|
| Kindly, and non-intrusively, ask them? You know, just like in
| other aspects of life?
| Symbiote wrote:
| Why should they know this? I am keen that they _don 't_ know
| this.
|
| If I walk into a shop, the shopkeeper doesn't know if something
| in the window caught my eye, if my friend recommended the
| helpful staff, if I saw the advert they placed on a billboard,
| or if I just came in because it's raining.
| pbhjpbhj wrote:
| We run a micro-business and we ask people how they heard of
| us (and use offer codes, but that was mentioned).
|
| People are usually happy to tell us; but then we only use
| that information to run our business better, we don't sell
| it.
|
| Another technique is referral bonus, "recommend a friend"
| type offers.
| slater wrote:
| "the shopkeeper doesn't know if something in the window
| caught my eye"
|
| Except that's already here, or in the making, i.e. with those
| advertising eye-tracking stories that make the rounds every 6
| months or so.
| reaperducer wrote:
| _If I walk into a shop, the shopkeeper doesn 't know if
| something in the window caught my eye, if my friend
| recommended the helpful staff, if I saw the advert they
| placed on a billboard, or if I just came in because it's
| raining._
|
| But the shopkeeper knows if you came in through the street
| entrance (maybe saw the window display), through the mall
| entrance (maybe saw the sandwich board), or through the
| communicating door to the next shop (maybe saw the
| merchandise).
| antonvs wrote:
| Only true for a small shop where the shopkeeper can see all
| entrances and is able to pay attention to that enough of
| the time.
|
| Otherwise you need video cameras and AI... or perhaps spray
| every incoming customer with a source-identifying powder or
| smell - hmm, maybe that explains Abercrombie & Fitch!
| nickjj wrote:
| > If I walk into a shop, the shopkeeper doesn't know if
| something in the window caught my eye, if my friend
| recommended the helpful staff, if I saw the advert they
| placed on a billboard, or if I just came in because it's
| raining.
|
| A lot of places will attach unique discount codes to
| advertisements to get an idea on where you came from.
|
| For example, on a TV commercial it might say use promo code
| COOL123 to save 10% or if you saw that billboard it might say
| to use NICE123 instead. Then there's radio, newspapers and so
| on each with their own unique code that offer the same 10%
| discount.
|
| And since a discount is applied chances are you'll use it
| because not too many folks would purposely avoid the discount
| to hide where you discovered the shopkeeper from.
|
| You often see this being done online too, but there's also
| things like UTM tags or unique URLs that let you do the same
| thing without discount codes. It's not to make more money as
| a shopkeeper (avoiding the discount), it's just easier to set
| up. Using a UTM tag is a matter of creating a link with a few
| query parameters. Creating a specific discount code or a
| unique URL for a specific promotion takes a bit of extra leg
| work.
|
| I'm not sure where I stand on the movement to remove all
| forms of referral tracking. Both referral headers and UTM
| tags can be spoofed or removed through extensions so using
| them as any type of source of truth was a bad idea anyways.
|
| However, as someone who sells digital products I like knowing
| which specific video or blog post helped someone discover
| some of my paid content. But at the same time, the end game
| is really "is the needle moving forward?" so the specifics
| kind of don't matter. But in the short term while you're
| figuring things out, the extra info does help you focus on
| where to spend your time. Not just for more profit, but to
| provide better and more free content because it's what folks
| want.
| zentiggr wrote:
| As a user with a certain combination of medical and other
| life issues, I'm neutral on the use of varied discount
| codes, as it's not personally identifying, just gives you
| the seller an idea of which media is a good buy. Ok, no
| worries.
|
| Bur given the unique personal searches/browsing I could
| have just been doing, I sure the heck don't want my recent
| activity advertised to the next site I go to. Happy as a
| clam to shut down all the Referrer uses, even whatever
| login flows that might have to re-engineer themselves.
| Deukhoofd wrote:
| You can still see what site the referrer came from, just not
| the path + query string behind it.
| puszczyk wrote:
| How does this work in real life? How does say Tesco can find
| out if I'm shopping there because of a billboard ad, or because
| it's conveniently located on my commute? How do they measure
| their ad campaign effectiveness?
| TeMPOraL wrote:
| Facial recognition in stores, your credit card, or your
| loyalty card tie your purchase to an ID, which then can be
| back-tied to all the Internet surveillance in your browser
| and on your phone, to attribute purchases to ads viewed on-
| line. It's a bit tougher with attributing real-life billboard
| ads.
| kevincox wrote:
| I think the major problem here is that this information was
| sent *by default* and many websites didn't realize that
| outbound links where sharing the source URL. This could result
| in an exploitable security issue.
|
| Now the website has to do something explicit to share
| information (beyond the hostname) to outbound cross-origin
| outbound links. It is much more likely that the website will
| pay attention to what information they are sharing in this
| case.
| ldjb wrote:
| Firefox still sends the origin (the domain name and subdomain)
| of the referring page, so you can still see the website the
| user is coming from.
|
| Google has had a dereferral process in place for many years
| anyway, which prevents you from seeing the specific search
| engine results page the user is coming from. So this really
| doesn't change anything for those websites such as Google that
| already had these security features in place.
| Andrew_nenakhov wrote:
| > Google has had a dereferral process in place for many years
| anyway, which prevents you from seeing the specific search
| engine results page the user is coming from.
|
| Is this really a security feature though? Or is it Google
| keeping the important information for themselves?
| SXX wrote:
| It's certainly has nothing to do with security. It's
| Google's way to force you to use Google Analytics if you
| want to track said informarion.
| tannhaeuser wrote:
| Also, it prevents you from exfiltrating Google's ML model
| for search and build up your own.
| lmkg wrote:
| Google Analytics does _not_ give you additional keyword
| information.
|
| If you want keyword information from Google search
| results, the best way to get it is actually buying ads
| for those keywords. And in fact some marketers allocate
| ad budget to keywords they already rank for, specifically
| for that purpose.
| shostack wrote:
| But to the grandparent's point, GA used to give you a ton
| more organic info at the keyword level. It is part of
| what drove the seo industry. The only way to get an
| abstract view of that keyword volume now, including on
| your brand terms, is to buy ads and run the organic
| reports.
| sneak wrote:
| I hope they do User-Agent next.
| oneeyedpigeon wrote:
| At least that might stop Twitter refusing to serve User-Agents
| it doesn't recognise.
| sneak wrote:
| How long until we see a CFAA prosecution based solely on
| providing a UA in the request that you're not "supposed" to
| use?
| floatboth wrote:
| There was a brief period of time last year when Twitch
| streams broke for me, turns out because my UA includes
| "FreeBSD" instead of an OS they know about. Eventually this
| was fixed.
| omoikane wrote:
| Coincidentally, Mozilla's site is one that consistently blocks
| my user-agent (Lynx).
| jefftk wrote:
| They've indicated they may:
| https://github.com/mozilla/standards-positions/issues/202#is...
|
| Commenting in support of Chrome's proposal to freeze the user
| agent and provide UACH instead.
| sneak wrote:
| UACH is worse than a header.
|
| The server shouldn't get information about the client.
|
| Unsurprisingly, UACH is spearheaded by an ad tracking company
| that benefits from a moat caused by minimally viable/workable
| browsers costing millions of dollars and dozens of developers
| to implement.
| SquareWheel wrote:
| > UACH is worse than a header.
|
| It's not. The header gives up all information by default.
| UA-CH works by request-only, and allows the browser to
| determine how much to send. This is easily controlled via
| native settings or browser extensions.
|
| The API also requires a secure connection, and specifically
| forces the server to admit to any fingerprinting (or
| legitimate use-case of data otherwise).
| deepstack wrote:
| Good for firefox. although I can see how this may break vimeo
| kind of service that only allow embedding video from certain web
| site.
| simias wrote:
| They still send the domain name on cross-origin requests, so
| the type of filtering Vimeo does will be unaffected as far as I
| can tell.
|
| It's only when the target website needs the full source URL
| (with path and GET parameters) that you may encounter issues.
| eitland wrote:
| For anyone who wonders how http referer could ever be a good idea
| consider the following:
|
| I remember when my dad studied to become a teacher. As one of
| their assignments they had to create a webside. As someone who
| had recently given up farming I think he wrote about farm animals
| and linked to some other pages about small scale poultry and
| similar topics.
|
| One day he got a mail from the "webmaster" of one of the sites he
| linked to that he would have to update his links soon. I remember
| being really surprised that someone knew my dad had linked to
| them.
|
| Being only 16 or 17 or something I only knew simple html, basic
| and vb but I knew that html links were one way.
|
| I don't think I realized until later what had really happened:
| this person had looked at their server logs to see where their
| customers came from, looked up the page and found the email
| address.
|
| Of course this also highlights why the referer is so problematic.
| jacques_chester wrote:
| > _One day he got a mail from the "webmaster" of one of the
| sites he linked to that he would have to update his links soon.
| I remember being really surprised that someone knew my dad had
| linked to them._
|
| These days 100% of such emails I receive are from spammers
| trying to steal some google juice.
| antonvs wrote:
| You'll still be able to see which site visitors came from, just
| not the specific page.
| ape4 wrote:
| I've noticed recently the <Back button is sometimes disabled in
| Firefox. Related?
| chrisjc wrote:
| Not sure if it's related, but the
|
| > Back button is sometimes disabled in Firefox
|
| for me when I click on a Medium (or similar) link. However I
| think this is related to containers. It's really annoying, but
| I'd rather just avoid Medium that abandon Firefox.
| bouncycastle wrote:
| The HTTP referer (a misspelling of referrer) was broken for a
| while, ever since spammers figured out they can abuse it.
| hannob wrote:
| Just a FYI because some people are complaining that Mozilla is
| doing something evil or will break all of the web or something.
| Chrome made the same change a while back:
|
| https://developers.google.com/web/updates/2020/07/referrer-p...
|
| So if this breaks something people probably already noticed. And
| Mozilla is merely aligning with the browser with the largest
| market share on this. (Also everyone who wants something
| different for their sites, it's configurable:
| https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re... )
| smileybarry wrote:
| Ah, that explains why the old "come from Google" trick for
| bypassing paywalls stopped working a while ago.
| ehsankia wrote:
| Your FYI is also useful for the contrapositive of that feeling,
| which we often see on HN: "Look how Firefox is leading privacy
| improvements and how much more privacy forward it is than
| Chrome".
| michaelt wrote:
| You see, when Firefox improves privacy it's for the good of
| users, but when Chrome improves privacy it's because Google
| can track you just fine despite the change and they want to
| give competing ad networks a kicking.
|
| /s ?
| ViViDboarder wrote:
| I mean, that can be true, no? Google does have many ways of
| tracking you and blocking others from doing it while still
| doing it themselves certainly helps them maintain their
| moat.
| Groxx wrote:
| AMP is a pretty good example of this. Good for Google,
| reduces tracking (by anyone but Google), bad for everyone
| else.
| tasogare wrote:
| Both browsers are funded mainly by the same source, so in
| the end changes in any of them is Google's move anyway.
| [deleted]
| GeekyBear wrote:
| >You see, when Firefox improves privacy it's for the good
| of users, but when Chrome improves privacy it's because
| Google can track you just fine despite the change and they
| want to give competing ad networks a kicking.
|
| /s ?
|
| Given that Firefox improving privacy generally doesn't draw
| antitrust scrutiny, where is the problem with that
| statement?
|
| >The questions from Justice Department investigators have
| touched on how Chrome policies, including those related to
| cookies, affect the ad and news industries, four people
| said.
|
| Investigators are asking whether Google is using Chrome,
| which has 60% global market share, to reduce competition by
| preventing rival ad companies from tracking users through
| cookies while leaving loopholes for it to gather data with
| cookies, analytics tools and other sources, the sources
| added.
|
| https://www.reuters.com/article/us-tech-antitrust-google-
| exc...
|
| If Google were truly improving privacy, one would expect
| their changes to decrease their own ability to track users,
| not just their competitors.
| jonas21 wrote:
| It's also useful for recognizing how preconceived notions and
| biases influence upvoting behavior and by extension what
| gains visibility on the front page, further reinforcing those
| biases.
|
| At the time I'm writing this, there are 740 upvotes and 187
| comments on this story vs. 12 upvotes and 0 comments for the
| top submission when Chrome made the same change [1]. Without
| the FYI, I would have assumed this was Firefox leading the
| way in privacy because I was simply unaware that Chrome had
| done it.
|
| [1] https://news.ycombinator.com/item?id=24008516
| lucideer wrote:
| True, but this case contains a little more complexity.
| Namely:
|
| 1. Chrome, as the dominant browser, drives developer
| behaviour (devs need to change their websites when Chrome
| breaks compat). Firefox doesn't have this luxury, so some
| features like this must necessarily be lead by Chrome in the
| monopolistic browser world we live in.
|
| 2. Referers allow _websites_ to individually track users
| better, which is bad for user privacy if you are concerned
| about entities such as Facebook, etc. tracking you. However,
| those entities are Google 's competitors; for Google, Chrome
| does the tracking, so they have no need of the Referer.
|
| Removing it is "good" for user privacy w.r.t. Google's
| competitors, and simultaneously good for Google
| (disadvantaging such competitors).
| behnamoh wrote:
| Your answer takes Google's POV into account (the "why"),
| but the GP was mentioning the end result of firms'
| intentions (the "what"). In other words, it doesn't matter
| why google needs to or wants to implement some features.
| What matters is that those features are implemented in
| Chrome and yet they don't get praised on HN. But if Mozilla
| adds the same features, HN folks go crazy about it.
|
| I'm a happy Firefox user too, but I don't want to believe
| that Firefox is the only browser that cares about user
| privacy.
| lucideer wrote:
| > _I don 't want to believe that Firefox is the only
| browser that cares about user privacy._
|
| I don't either, but I don't believe HN users praising
| Chrome is going to help with that situation...
| ysavir wrote:
| I think the parent comment's point is that Firefox is
| worth celebrating because they're making this (and other
| changes) with no ulterior motive other than championing
| user privacy. But with Chrome, the user privacy
| improvement is a biproduct of Google making profit-
| oriented decisions, and not the focal point of their
| change.
|
| I'll happily celebrate Google making a privacy-oriented
| change that's actually intended and not a bi-product, but
| this isn't such a case.
| pkaye wrote:
| > Removing it is "good" for user privacy w.r.t. Google's
| competitors, and simultaneously good for Google
| (disadvantaging such competitors).
|
| And how does Mozilla make money?
| wizzwizz4 wrote:
| Google paying it.
|
| Out of Chrome and Firefox, one is one big level of
| indirection further away from Google's influence than the
| other.
| derefr wrote:
| No. Mozilla Corp is a separate entity from the Mozilla
| Foundation, and Google pays Mozilla Corp. (The
| arrangement with Google is exactly _why_ Mozilla Corp is
| a distinct thing from the Mozilla Foundation: it means
| profits to Mozilla Corp can 't influence the Mozilla
| Foundation.)
|
| Mozilla Foundation is purely a donation-fed nonprofit,
| and most things you associate with "Mozilla" are made by
| the Mozilla Foundation. In fact, even Firefox itself --
| the open source project -- is made by the Mozilla
| Foundation.
|
| Mozilla Corp is just a company that employs engineers to
| work on Firefox. (I.e. their job is to be ordinary FOSS
| contributors to the project.) Those engineers might have
| a profit motive to do things Mozilla Corp
| investors/shareholders like, but that's fine, because
| those engineers mostly aren't part of the Firefox
| steering committee. The Firefox steering committee (along
| with all other Mozilla projects) is composed of people
| who are employed by the nonprofit Mozilla Foundation;
| and/or FOSS people external to Mozilla as a whole.
|
| (ETA: fixed the names. I originally called Mozilla Corp
| "Firefox Corp" -- and it really basically is, as Mozilla
| Corp doesn't employ people to work on anything other than
| Firefox. IMHO "Firefox Corp" would be a strictly-better
| name for it.)
| sm4rk0 wrote:
| You're close, but there's no "Firefox Corp".
|
| From Wikipedia: "Mozilla [...] is a free software
| community founded in 1998 by members of Netscape. [...]
| The community is supported institutionally by the not-
| for-profit Mozilla Foundation and its tax-paying
| subsidiary, the Mozilla Corporation."
| stonogo wrote:
| A distinction without a difference, since the same people
| lead both organizations.
| godelski wrote:
| Through royalties and donations[0]. You say this like
| something nefarious is going on. But also consider that
| Mozilla has a net income of 90 million/yr[1]. The income
| levels between these two companies are extremely
| different and thus they can operate in different ways and
| under different conditions and saying "how does x make
| money" and not taking this into account is just a bad
| question. Their goal isn't to be Google and to be a
| trillion dollar company.
|
| [0] https://www.investopedia.com/articles/investing/04131
| 5/how-m...
|
| [1] https://en.wikipedia.org/wiki/Mozilla_Corporation
| 3grdlurker wrote:
| It seems that the solution to the "complex" scenario you're
| describing is simple: use Firefox instead of Chrome.
| toxik wrote:
| It's only simple in the sense that it takes few words to
| say, but then world peace is also simple: just stop
| having wars.
| ehsankia wrote:
| > for Google, Chrome does the tracking, so they have no
| need of the Referer.
|
| Source?
| [deleted]
| [deleted]
| IAmNotAFix wrote:
| Google consistenly tries to make it harder for their
| competitors to grab user data.
| m463 wrote:
| But doesn't chrome have baked-in identification?
|
| (not that firefox doesn't have lots of phone-home behavior
| you can't turn off like
| firefox.settings.services.mozilla.com)
| behnamoh wrote:
| Exactly. In FF, one of the first things I always do is turn
| off "Firefox Data Collection and Use" in the Settings.
| Ajedi32 wrote:
| Yeah, I was gonna say; isn't this part of the spec? Seems like
| it is; at least in the latest editor's draft:
| https://w3c.github.io/webappsec-referrer-policy/#default-ref...
| xPaw wrote:
| That doesn't appear to be accurate in Chrome, in 89 I am
| getting no-referrer-when-downgrade.
|
| For example, I clicked a link on old reddit and saw the full
| referer being sent to another origin.
| merb wrote:
| why tf should removing Referer break sites? who uses Referer?!
| the only thing that Referer brought were privacy leaks.
| Isthatablackgsd wrote:
| Some sites use referrer as their "cookie session". One site
| use Cloudflare Anti-DDOS referrer as their cookie. Removing
| that referrer will cause the browser to infinity loop in CF
| Anti-DDOS because the site is expecting that referrer before
| entering the site.
|
| I hate sharing Amazon shopping links because Amazon packs
| much referrer as possible in the link. Amazon uses the
| referrer to track who am I sharing to and use it for data for
| them to sells.
| lupire wrote:
| Are you conflating Referer with URL parameters? (Amazon
| calls them "ref tags" (referrer tags) but that's not HTTP
| Referer. It's not even possible to do what you are
| imagining with HTTP Referer, since Referer is only inside a
| browser session, not across from you to your friend.
| Isthatablackgsd wrote:
| Dang it, I didn't realize it was specific to HTTP. Thank
| you for pointing it out, all I see referrers (I somehow
| blank on HTTP) and I thought it was about the referrer
| tags.
| asveikau wrote:
| Isn't it also sort of useful information for site owners even
| if they are not maliciously slurping your private
| information?
|
| For example you might not know that important site X linked
| to you and is driving Y% of your audience. You are not
| necessarily interested in the individuals following the links
| when you discover that.
| antonvs wrote:
| This change only trims the referrer string, it doesn't
| remove the origin domain info. You can still tell that
| "important site X linked to you and is driving Y% of your
| audience." You just wouldn't be able to get any more
| granular than that.
| hk1337 wrote:
| The first thing I thought of was when you go to a URL but it
| requires a login so it redirects you to the login page but
| then redirects you back to your original page after you
| login. Pretty sure it's easily remedied without referer but
| that was the first thing I thought about.
| bdcravens wrote:
| If the login is on the same site, this change won't affect
| that, as this change only applies to cross-original
| requests.
| merb wrote:
| that is a security issue on it's own. you should never have
| an openredirect bug, that's why openid servers need to
| store redirect uris somewhere and validate them.
| lgeorget wrote:
| We use them to prevent other websites to hotlink our dynamic
| map tiles. Not a big protection of course but useful anyway.
| smt88 wrote:
| Referer is an important way to maintain the security of an
| OAuth flow.
|
| I don't know how commonly it would break that flow, but it
| certainly could depending on implementation details that are
| not narrowly prescribed by the OAuth2 spec.
| merb wrote:
| no referer is an important way to screw your security in an
| oauth2 flow. with oauth2 a correct configuration would be
| Referrer-Policy: no-referrer and enforcing a secure state
| param and csrf.
| amaccuish wrote:
| Loads of cashback systems use it. You get directed to
| Lieferando or whatever and the "click" is registered using
| the referrer.
| reaperducer wrote:
| _who uses Referer?!_
|
| How can you tell it's Monday morning on HN?
|
| Someone starts pontificating, "I don't use this, so there is
| no conceivable reason that anyone else on the planet should
| ever need this ever!"
|
| See also: Half of StackOverflow questions.
| merb wrote:
| well you can turn the header off pretty easily and you
| won't see many sites are breaking (alexa top 100), of
| course some wierd sites think it's important to use it, but
| because of the madness of referer there are so many things
| that will leak your privacy extremly, it came to the point
| that it's necessary to have extensions to remove the header
| or at least inject noreferer into a tags.
| nicbou wrote:
| Well, who does?
| RinTohsaka wrote:
| pcpartpicker does
| yellowapple wrote:
| And likewise, the _other_ sign it 's Monday morning is when
| someone starts pontificating "this exists for some reason,
| so there must be someone using it for non-malicious
| purposes".
|
| Which very well might be true, but that was exactly the
| question: who?
| npteljes wrote:
| I recently had to enable it for some login to work,
| unfortunately can't remember which website.
| roywiggins wrote:
| I've had to enable it for Atlassian's login to work.
| prussian wrote:
| I turned it off once and the most common breakages were
| usually authentication that involves some kind of OpenID
| delegation.
| hirsin wrote:
| Yeah, we (Azure AD) got a couple of "login is broken"
| escalations when Chrome made this change. A couple vendors
| use it to validate a request is coming from the upstream
| IDP, to block drive by attacks I assume.
| simias wrote:
| Some websites would whitelist referrers to prevent hotlinking
| resources from other websites (incurring potentially high
| bandwidth costs).
|
| But overall I'm all for getting rid of it. It's a remnant of
| the early web that doesn't make a lot of sense these days,
| and creates more problems than it solves.
|
| EDIT: Although I just realized that strict-origin-when-cross-
| origin (the new policy) would still let the hotlinking
| detection use case work, since you typically only need domain
| information for that. I initially thought that they would use
| same-origin or something like that. It'll teach me to comment
| before I read the linked story.
| calvinmorrison wrote:
| VictorOps uses referrers as a "security measure" on login.
| So I just have a separate profile of firefox without my
| antireferrer addon
| ignoramous wrote:
| > _VictorOps uses referrers as a "security measure" on
| login._
|
| Using the referrer header as a security and privacy
| measure is prevalent among service providers. Vimeo even
| hilariously charges for this feature which is trivially
| bypassed; and I'd reckon their paying customers aren't
| even aware of it: https://vimeo.zendesk.com/hc/en-
| us/articles/224819527-Changi...
|
| Talk about smoke and mirrors.
| judge2020 wrote:
| Maybe they advertise it as a security feature but it's
| still a good way to prevent unauthorized hotlinking that
| burns your vimeo bandwidth, costing you money (assuming
| it does indeed prevent random websites from embedding
| your videos).
| monkeybutton wrote:
| This reminds me of some vague memories of a time long ago
| where some websites had a secure login page that asks for
| a username&pw but every other page after just checked the
| referall header. It wasn't a very secure system and
| people shared the header values needed to bypass logging
| in.
| antonvs wrote:
| That's basically a degenerate form of capability-based
| security. Sharing the referrer header is delegating
| access rights. Of course, that's not actually a property
| you want in this case.
| fluidcruft wrote:
| I've started to see quite a bit of that on websites
| dealing with transfer of medical data. I figured it was
| probably some sort of an effort to handicap MITM
| potential of impostor websites that were trying to steal
| credentials. My theory is that it might be some sort of a
| tripwire for the website to detect fishiness and lock the
| account.
| guywhocodes wrote:
| Twitter does this and more
| spicybright wrote:
| I can't think of a single use case where a user would
| want a target site to know where they came from. Put that
| in the URL or something less nefarious if you want to
| communicate state.
| Jenk wrote:
| Twitter have started doing this via their embed
| widgets/scripts.
| kbelder wrote:
| I want some news sites to think I came from Google,
| because they will give up whole articles that are
| otherwise paywall-blocked. It's a dark SEO trick.
| jakub_g wrote:
| Some ad networks use(d to use) referers for brand safety when
| resource serving an ad is embedded iframe. For example if the
| parent URL contains "osama-bin-laden-killed", don't display
| ad about nice family moments together (or anything else,
| likely)
| ttt0 wrote:
| Or keep track of your internet history to have a more
| accurate profile of you. This is not a good thing and it's
| precisely why it's a privacy leak.
| mauvehaus wrote:
| I believe jwz rather famously does. Let's see:
|
| https://www.jwz.org/blog/2021/03/cursed-keyboard-image/
| Macha wrote:
| His use only needs the domain, so should be unaffected?
| That said, something from my browser, probably ETP strict
| mode, appears to be stripping out the referrer entirely
| already anyway.
| pbhjpbhj wrote:
| I'm not following that on the assumption is he the guy that
| shows HN users the goatse image?
|
| If so then please mark your link up as NSFW/NSFL.
| mauvehaus wrote:
| Not goatse, and I wouldn't consider it to be NSFW, but
| some folks might. Apologies for not marking it; I've
| missed the edit window.
| monocasa wrote:
| It's not goatse, but it is NSFW.
| smcl wrote:
| jwz has got a rather ... interesting use case for it relating
| to HN
| bartvk wrote:
| And slashdot before that.
| smcl wrote:
| Ah jwz did this for /. too? If he did then it seems like
| he has switched it off, because I cannot reproduce it
| bartvk wrote:
| I just tried to find references to it, but couldn't. I'm
| wondering if my memory is broken. Slashdot is _old_
| though, we used to get worked up about bugs in X11
| screensavers, and GNAA trollers.
| eli wrote:
| It was a somewhat common "security" feature to check referer,
| especially in the days before you could rely on CSP.
| superkuh wrote:
| This doesn't change my opinion. This is like saying, "The
| soviet union gulags their people too and did it first. It's
| fine."
|
| Whataboutism re: corporate control of web standards.
| unnouinceput wrote:
| That's probably because if you run Chrome, you're already
| Google's executable on your system. I mean they can track you
| using gazillion of other, more precise meanings and this is
| something they shut it to keep the pie for themselves. I do not
| use Chrome anymore, switched to Firefox a year and a half ago -
| best decision ever.
| ethbr0 wrote:
| Good for both Firefox and Chrome.
|
| Does this mean Gmail can stop rewriting links in emails
| (ostensibly to derefer)?
| [deleted]
| kevincox wrote:
| I'm pretty sure they could have done this years ago as most
| browsers supported setting the policy explicitly for years.
| This only changes the default policy.
|
| The only reason I can see Google still doing rewriting is to
| protect very old browsers and laziness.
| Larrikin wrote:
| Are there any extensions that can rewrite these in the
| meantime?
| smichel17 wrote:
| Not using gmail works
| lupire wrote:
| Presumably no because they also probably use it for analytics
| and/or security (blocking malware URLs)
| Arnavion wrote:
| Indeed. If not sending referer was the only reason, gmail
| would never have needed to rewrite the link since it
| could've just used `rel=noreferrer` on the original anchor
| tags instead.
| glsdfgkjsklfj wrote:
| Heh. chrome undone this change at least 3 times in the past,
| that I counted. Remember that cross-domain referrer is
| essential to Google business (getting money from sending people
| from search ads)
|
| There used to be a user visible option in the very early days
| that allowed to not send, not send cross-domain or send only
| origin for cross domain. A google domain username removed it
| when "moving some items into advanced menu". Then someone added
| it as a hidden setting in chromium. Another google domain
| username removed it again in an urelated change. Then someone
| added it back to the command line, and I know because i tested
| it. A few years later, no more command line setting. I still
| could build chrome with a flag that enabled it. but building
| chrome is a full time job. meh.
|
| So funny that now they are "trendsetters" of adding this option
| back.
| jrochkind1 wrote:
| I didn't realize this, thanks for pointing it out.
|
| I thought, wait, but how is this feature in my own app still
| working with chrome then! Aha, Chrome only trims referrer for
| cross-origin requests.
|
| Is FF the same?
|
| Looks like... yes! "...will also trim path and query
| information for all cross-origin requests."
| beagle3 wrote:
| That reminds me that in 1999, looking through the referrer logs,
| I realized that if the link came in from an Outlook email,
| Outlook+IE would report the subject of the referring email as the
| referrer (iirc with user name, something like
| "mailbox://user@site/subject-of-the-email").
|
| So we started looking for those more seriously in my company, and
| got quite a bit of interesting Intel from potential investors,
| competitors we knew about, and some we weren't even aware of.
|
| It was just the subject and user, but was often surprisingly
| informative.
| pbhjpbhj wrote:
| Do you, or anyone, have [links to] more information about
| exactly what Outlook does when requesting a tracking pixel to
| display in an email.
|
| I can't sniff it (Wireshark) as I don't have that sort of
| access to a network with Outlook on. I've googled but didn't
| find anything useful.
| beagle3 wrote:
| It was surely fixed in Outlook 2007, perhaps even 2003 and
| maybe even 2000.
| professor_v wrote:
| I just realized the 'Referer' header is actually a misspelling in
| the http protocol.
| SilasX wrote:
| And I made up the HTTP status code "397 Tolerating" so that if
| you spell it "Referrer", browsers can correct you while still
| giving you the response you wanted :-p (see section 3 example):
|
| https://pastebin.com/TPj9RwuZ
| themoose8 wrote:
| Yup, here's an article you may enjoy
| https://httptoolkit.tech/blog/http-wtf/ and related HN
| discussion https://news.ycombinator.com/item?id=26343577
| TriNetra wrote:
| We chose not to add referrer to ASPSecurityKit main site [0].
| It's a static content site and I think it'd be useful to let
| other sites know which page (docs/guides/blog) on our site got
| them a visitor because the content is public anyway. We've
| applied it on the dashboard though, this same origin-when-cross-
| origin policy.
|
| 0: https://ASPSecurityKit.net
| tannhaeuser wrote:
| That's going to break lots of older sites using Referrer for navi
| state. These will now either have to use query params, cookies,
| or JS instead. Not to mention easy affiliation links.
| Mauricebranagh wrote:
| Isn't this going to break campaign tracking for Adwords etc.
|
| Not exactly what the actual risk is to privacy here does seem
| there is a lot of bandwagon jumping going on - a bit like "Elf &
| Safety" or the Data protection act is trotted out when an
| organisation wants an excuse not to do something.
| ratww wrote:
| Referrers can leak information about which pages the user was
| navigating before, which linked websites have no business of
| knowing.
|
| If you want to do tracking and have control over both pages,
| just use a different URL, a query string, or something like
| that.
| ExcavateGrandMa wrote:
| curiously it always protected user privacy through ages :D
|
| but which end of the use :D
___________________________________________________________________
(page generated 2021-03-22 23:00 UTC)