[HN Gopher] Firefox rolls out Total Cookie Protection by default...
___________________________________________________________________
Firefox rolls out Total Cookie Protection by default to more users
Author : elashri
Score : 159 points
Date : 2023-04-12 19:54 UTC (3 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| dandongus wrote:
| Why is there any concept of "some users worldwide" with respect
| to default cookie settings in a browser application?
| wnevets wrote:
| to avoid breaking changes for every single user?
| clumsysmurf wrote:
| A couple of days ago there was a story on HN about fingerprinting
|
| https://news.ycombinator.com/item?id=35243355
|
| The take-away I got from this article is that, companies found a
| way to uniquely identify you anyhow, without cookies.
|
| Is this too little too late?
| teh_boulder wrote:
| The same article mentions that you can prevent fingerprinting
| in Firefox with privacy.resistFingerprinting = true
|
| https://www.bitestring.com/posts/2023-03-19-web-fingerprinti...
|
| But you are right, it's likely that there are other ways other
| than cookies and fingerprinting that companies can track you.
| jszymborski wrote:
| Resist is a better word than prevent here.
|
| Also, there are some major drawbacks, like your browser
| setting UTC as the default timezone. That one has caused some
| mix ups when filling out Doodles.
| clairity wrote:
| this one really annoys me because proton mail uses the
| "spoofed" utc timezone to show when i sent/received emails,
| as if i live in the uk or west africa. they also refuse to
| add timezone as an app setting to correct this issue.
| red_trumpet wrote:
| > t's likely that there are other ways other than cookies and
| fingerprinting that companies can track you.
|
| Any idea how they would do that?
| mishu2 wrote:
| Using something like this, which I would personally make
| illegal: https://fingerprint.com/
|
| I also tried setting privacy.resistFingerprinting = true in
| Firefox, but it's sad to see that most websites become
| unusable (most sites using canvas just render a
| green/purple mess), zooming in Google Maps is basically
| broken (skips several levels at a time), and like others
| have mentioned dark mode and time zones also stop working.
|
| What a mess the (somewhat private) web is nowadays. The
| more I think about it, the more I am convinced legislating
| privacy is the only way out of this arms race we seem to be
| losing.
|
| EDIT: Sorry, the parent post already included
| fingerprinting, missed that. Rant still stands though :)
| josephd79 wrote:
| Device ID tracking should be illegal period.
| thebrain wrote:
| I tried enabling this recently and I immediately noticed that
| websites started appearing in light mode instead of copying
| my system settings and displaying in dark mode. It seems like
| in it's efforts to make my fingerprint the same as everyone
| else's Firefox stops telling websites about my display
| settings. The issue immediately went away when I changed the
| setting back to privacy.resistFingerprinting = false.
| pdonis wrote:
| Why does the browser need to tell the _website_ about local
| display settings? In my case, with
| privacy.resistFingerprinting = true, the Zoom level resets
| to 100% every time I navigate to another page on a site.
| Why can 't the browser just remember my zoom level locally
| and re-apply it? Why does it have to tell the website?
| imran-iq wrote:
| To add on to this, why can't the browser just lie to the
| website but retain my local settings as is
| Spivak wrote:
| It doesn't have to but if you want websites to follow
| your system settings for light/dark mode then the browser
| has to tell the website which one you want at this
| moment.
| mixmastamyk wrote:
| Dark mode is generally decided at the client via choosing
| which block of css to use. Are these sites sending
| different css instead?
| renewiltord wrote:
| That's how it works. The most common fingerprinting
| techniques use display settings, e.g. viewport size and
| this dark mode stuff
| LikesPwsh wrote:
| That's intentional.
|
| Uncommon settings being exposed to websites makes
| fingerprinting much more reliable.
| seanw444 wrote:
| My primary issue is that it limits the refresh rate. It
| immediately gets choppier when scrolling, which is suuuuper
| annoying.
| Riverheart wrote:
| Yes. Cookieless tracking is a thing.
| focusedone wrote:
| Firefox user but relatively ignorant on how tracking works.
|
| FF does some good things to work around fingerprinting,
| although simply using FF puts us in a pretty small (marketable)
| group in the first place.
| OkayPhysicist wrote:
| Frankly, Firefox should take the nuclear option, and just
| start emulating Chrome with regard to website identifiable
| information.
|
| In particular, User-Agent strings are now a net-negative.
| I've never run into a website that doesn't work on Firefox. I
| do occasionally run into websites that claim to not work on
| Firefox. We software developers have shown that we can't be
| trusted with information pertaining to what browser someone
| is using, and as such should have the privilege taken away.
| If you're reading this, and you have access to a codebase
| that reads User-Agent strings for anything more than idle
| curiosity, just delete it and push to master.
| INeedMoreRam wrote:
| [dead]
| Animats wrote:
| Are they blocking Google Tag Manager?
| flangola7 wrote:
| What does tag manager even do?
| cj wrote:
| 1) Developer installs Google Tag Manager at the request of
| someone in marketing
|
| 2) Marketing department has free reign (via Google Tag
| Manager) to add arbitrary javascript on any page with Google
| Tag Manager installed. Namely tracking scripts, adwords
| conversions, retargeting pixels, or really any arbitrary
| javascript without limitation.
|
| Edit: Google Tag Manager can also be used to inject scripts
| that aren't inherently bad, like a 3rd party support/chat
| widget (Zendesk, Intercom, etc)
| Animats wrote:
| It's worse than that. Attackers can add arbitrary
| Javascript to your pages. It takes another vulnerability to
| use this as a large scale exploit, but it's been done.
| [1][2]
|
| Blocking "googletagmanager.com" does break a few sites, but
| not enough that it matters.
|
| [1]
| https://support.google.com/tagmanager/answer/6328489?hl=en
|
| [2] https://www.akamai.com/blog/security/magecart-attack-
| disguis...
| TheNewsIsHere wrote:
| What I hate is that because it can be used for shady and
| benign purposes, you can never tell what will break without
| it. I'd love to wholesale block or at the edge or host but
| sometimes you need it.
| nashashmi wrote:
| I have it blocked all the time. Now I understand why some
| websites don't work until I put it on.
|
| This is nefarious.
| arealaccount wrote:
| Its basically a tool that lets you manage all of the js
| tracking scripts (tags) that advertisers, affiliates, etc
| have you paste into a website.
|
| So instead of having a million js snippets on your page, you
| have one google tag manager snippet and then your marketing
| team can inject 400mb of javascript into the site without
| bothering dev.
| billiam wrote:
| This is nice to see, but it worth pointing out that it is years
| overdue. Mozilla dragged its feet for years about Tracking
| Protection and cookies in general, coming up with halfway
| measures while continuing to serve the needs of advertisers that
| had a lot of influence on the company. The end state of Total
| Cookie Protection was clear from the beginning. It is of course
| not easy to change the advertising based model, but it's not like
| Firefox is really more than an influencer of Google and Apple,
| its market share has all but disappeared. No, the motivation to
| take seven years to get to TCP was all about money, including big
| salaries and bonuses for Mozilla executives.
| Tagbert wrote:
| So when did Chrome start doing this?
| the_pwner224 wrote:
| Has Chrome already been doing this for a while? (I'm not sure,
| but I think I've heard that it has).
|
| Disclaimer: I'm a FF user, not trying to say FF is bad, I just
| want to know how much of this is actually new cutting edge
| privacy protection vs. marketing fluff.
| privacyonsec wrote:
| no but brave browser does
| the_pwner224 wrote:
| Thanks.
| xuhu wrote:
| Will bitbucket.org sending me to oauth.atlassian.com fail with
| Total Cookie Protection enabled ?
|
| Will someonlineshop.com redirecting me to payments.mybank.com
| fail with Total Cookie Protection enabled because the payments
| site uses cookies to store the return url for the online shop ?
| dizhn wrote:
| I believe they maintain a whitelist for the big guys.
| Spivak wrote:
| With oauth probably not since the state doesn't transfer with
| cookies. You send the user to the IdP with a postback in the
| URL then when the user logs it it sends them back to the
| original site with some data that depends on the flow you
| chose.
|
| Your login cookie as far as the IdP is concerned lives on
| oauth.thirdparty.net and on a successful login the app issues
| you your own session token that lives on myapp.com.
| choeger wrote:
| In what sense is TCP tomorrow different from disallowing 3rd
| party cookies today?
|
| On a side note: Isn't it odd, how the composition of different
| technologies (here HTTP and DNS) make it unintuitively complex to
| implement a so intuitively natural policy as "every website gets
| to read only its own cookies"?
| renewiltord wrote:
| It appears 3rd party cookies will still be placed but they will
| be partitioned by 1st party domain. That's interesting.
| red_trumpet wrote:
| > every website gets to read only its own cookies
|
| That's already the case, isn't it? It's just that embedded
| parts by a 3rd party can set their own cookies, which can be
| read by the 3rd party whenever it is embedded in any other
| page.
| aidenn0 wrote:
| It's not already the case, but it is expected to be the case
| in all major browsers sometime next-year[1]
|
| 1: https://en.wikipedia.org/wiki/HTTP_cookie#Third-
| party_cookie
| cortesoft wrote:
| You aren't disagreeing with the person you are responding
| to, you just have slightly different ideas what it means
| when someone says "website"
|
| You are calling all of the assets loaded, no matter from
| where, as one "website". The person you are replying to
| considers each domain for each asset on the single page as
| being different "websites"
| TylerE wrote:
| Then they should say server/domain/subdomain and not
| "website".
| taeric wrote:
| Of course... knowing that this is all by well behaving browsers
| is a bit of a troubling point. Such that I find it equally odd
| that we have placed so much power and general trust into
| software that we keep expanding the capabilities of. It is a
| small step to "managed devices" that we don't even trust users
| to keep up to date being required for access.
| arthuredelstein wrote:
| Total Cookie Protection partitions all cookie-like data
| ("state") between the websites you visit, not just cookies. For
| a technical discussion, see https://developer.mozilla.org/en-
| US/docs/Web/Privacy/State_P...
|
| You can see which browsers partition state (and which don't) in
| the State Partitioning section of https://privacytests.org.
| Firefox passes nearly all of those tests because Total Cookie
| Protection is enabled by default.
| Nextgrid wrote:
| For a company that screams "privacy" at every possible
| opportunity (even though the default configuration is anything
| but private, and in blatant breach of the GDPR), why wasn't this
| on by default to begin with?
| sevg wrote:
| Because no software is perfect from the first release :)
|
| This is what software developers do, iterate to improve
| software.
| dmix wrote:
| There were plenty of legitimate use cases for 3rd party
| cookies. The negative ones just started to trump the legitimate
| ones over time and browsers lag behind these trends (or have
| different incentives).
| kevin_thibedeau wrote:
| > allowing those [third party] cookies to fulfill their less
| invasive use cases (e.g. to provide accurate analytics
|
| Separate cookie jars don't prevent data brokers from correlating
| cookies from a common IP + user agent pair. The only solution is
| to block third parties altogether.
| the_pwner224 wrote:
| The long term workaround for data brokers is to become a first
| party... have the main website serve your 3rd party JS from
| their own server under their own domain. That makes it much
| harder to block.
|
| For your IP+UA hypothetical, the easy fix is to make everyone
| look the same. IP should be the only personally identifiable
| factor. Tor and desktop Firefox w/ privacy.resistFingerprinting
| turned on both do this. Open window not-maximized at 1000x1000
| size, use the same UA regardless of what platform & browser
| version you're actually on, and a bunch of other stuff. That
| said, I don't know how effective it actually is against modern
| comprehensive fingerprinting libraries.
| seizethegdgap wrote:
| Obviously doesn't help when using an app, but what about an
| extension that changes your user agent every single time you
| send a request to a website? Does such an extension even work,
| or exist?
| Nextgrid wrote:
| Even if it did, it will be useless because fingerprinting (of
| various kinds - whether TCP or TLS stack, doesn't even have
| to be JS-based) will still tell which browser you're running
| on.
|
| Worse, it may actually make you _more_ identifiable because a
| Chrome on Linux user agent with the TCP fingerprint of
| Windows and TLS fingerprint of Firefox is going to stick out
| like a sore thumb, even more than a rare-but-at-least-
| consistent fingerprint with no trickery.
| jhoechtl wrote:
| What if I browse using tor?
| benmmurphy wrote:
| I'm not sure TCP fingerprints are very reliable because a
| lot of ISPs and Mobile Carriers are doing proxying at the
| application level for HTTP/HTTPS ports so even if you are
| on an iPhone you might end up having a linux TCP
| fingerprint. This site allows you test your TCP
| fingerprint: http://witch.valdikss.org.ru
| OkayPhysicist wrote:
| User-Agent strings are now net-negative in the web world. Their
| uses are slim, and their abuses are plentiful. They should
| probably be removed altogether, but in the meantime non-Chrome
| browsers should universally adopt Chrome's UA.
| MrRadar wrote:
| User-Agent strings are still useful for identifying non-
| browser user agents but I agree that given the privacy issues
| they present all browsers should adopt a single standard UA
| string (one each for desktop and mobile). (Did you know that
| Chrome on Android puts your device model in the UA string?
| One of the many reasons to use Firefox for Android...)
| _V_ wrote:
| I don't want to be a killjoy here. Don't get me wrong, this is
| certainly a good thing but to me it seems like most major
| trackers are moving/has already moved to things like canvas
| fingerprinting, WebAssembly fingerprinting etc.
|
| This seems to be like a typical cat-and-mouse game. And browsers
| will not get more privacy friendly as long as there will be a
| trend that moves applications and basically every aspect of our
| lives into the browser thus making it unbelieveably complex.
|
| I suspect that we will soon have to choose to either live as a
| "digital hermit" (links/neomutt and other lightweight apps that
| do only the one thing) or give up and join everyone with
| Youtube/Facebook/Twitter.
| zx8080 wrote:
| > to me it seems like most major trackers are moving/has
| already moved to things like canvas fingerprinting, WebAssembly
| fingerprinting etc.
|
| Also the upcoming WebGPU enabling by default in chrome will
| probably make it very simple to fingerprint almost anyone.
___________________________________________________________________
(page generated 2023-04-12 23:01 UTC)