Have been using Firefox for a long time, no issues, though long ago when I had little memory, Chrome was using less of it. Firefox also has HTTPS-only mode, encrypted DNS without fallbacks, supports SOCKS and Encrypted Client Hello (although almost no website support it). However, it is better to just buy more memory (unless you are lucky to use Apple products).
Regarding analytics, I believe browsers should take user's side and do not cooperate with marketing companies; even better, they should implement measures to make user tracking and fingerprinting more difficult. There is no need to track user's browsing history; just make a product better than competitors (so that it gets first place in reviews and comparisons) and buy ads from influencers.
It would be great if browsers made fingerprinting more difficult, i.e.: not allowed to read canvas data, not allowed to read GPU name, enumerate audio cards, probe for installed extensions etc. Every new web API should guarantee that it doesn't provide more fingerprinting data or hides the data behind a permission.
Regarding 3rd party cookies: instead of shady lists like RWS browsers should just add a button that allows 3rd party cookies as an exception on a legacy website relying on them (which is probably not very secure). Although, there is a risk that newspaper websites, blog websites and question-answers websites will force users to press the button to see the content.
> Regarding analytics, I believe browsers should take user's side and do not cooperate with marketing companies
Browsers were supposed to act as agents working for the user. User-agents. These days it's getting harder and harder to find a browser that doesn't work for an ad company at the expense of the user.
Chrome's entire reason for existing is data collection. Firefox can, for now at least, be hardened to work for the user (and prevent a lot of fingerprinting), but Mozilla is an ad-tech company too now. They've made their lack of respect for Firefox users clear by making Firefox spy on users by default so that Mozilla can sell that data to marketers.
> Every new web API should guarantee that it doesn't provide more fingerprinting data or hides the data behind a permission.
FWIW, it's practically impossible to provide that guarantee because the API necessarily provides at least the data point of, "Did they select an option in the permission notification?" ("If yes, what option was selected?" etc.)
It's often said that the only solution to this is regulation and there seems to be a good case for that perspective.
> Regarding analytics, I believe browsers should take user's side and do not cooperate with marketing companies; even better, they should implement measures to make user tracking and fingerprinting more difficult.
Kinda hard to enact when the leading browser is developed by an ad company. Worse, the same company is contributing to the firefox foundation and drives web "standards." Its all collusion and the simple fact that browsers are more complex than the OS they run on is deliberate in ensuring no scrappy team can disrupt them.
My curmudgeonly solution is to avoid as much of the web as possible and focus on human scale computing.
>It would be great if browsers made fingerprinting more difficult, i.e.: not allowed to read canvas data, not allowed to read GPU name, enumerate audio cards, probe for installed extensions etc. Every new web API should guarantee that it doesn't provide more fingerprinting data or hides the data behind a permission.
This should be what browser maker's #1 focus! Preventing fingerprinting of user's browser.
Seems all this cookies talk the news and for policy makers are just limited hangouts.
BTW I don't understand the anti-tracking absolutism. I don't care about being profiled as long as the profile lands me in a group of thousands of people like me. Yes, I live in ${CITY}, identify as ${GEDNER}, am approximately ${AGE_RANGE} years old, run ${BROWSER} under set to ${LOCALE}. This does not allow to easily harm me. If it allows ad networks to target their ads, so be it, uBlock Origin still works well.
> Have been using Firefox for a long time, no issues, though long ago when I had little memory, Chrome was using less of it.
I'd say the only area where I still see Chrome leading a bit is for web development: when I run super-heavy JavaScript in dev mode, Chrome is faster than Firefox at executing all the JavaScript nonsense. Seen that there's no ecosystem with more turds, bloatedness and slowness than that horror that JavaScript-the-piece-of-crap is, having a browser a bit quicker at running JavaScript helps.
Long story short: for Web development, I use Chromium (it ships with Debian). For the rest I use Firefox.
> Firefox also has HTTPS-only mode...
In doubt port 80 is blocked by the firewall too.
> encrypted DNS without fallbacks,
And Firefox has a relatively easy "corporate" setting too where you can force also DNS "in the clear" over port 53 UDP (well, it's 99.9999% of the time going to be UDP so you can even firewall port 53 TCP and things shall keep working: believe me I know: theory vs practice and all that)
It's convenient if you run your own DNS resolver (which, itself, can then be forced to only use encrypted DNS).
> supports SOCKS
I confirm: a SOCKS5 proxy over ssh is always sweet.
That seems the obvious result of this sort of thing.
> Related Website Sets (RWS) is a way for a company to declare relationships among sites, so that browsers allow limited third-party cookie access for specific purposes.
So the website itself gets to declare other "blessed" domains that can bypass third party cookie blocks? Big websites are constantly looking for ways to abuse users by bypassing their attempts at protecting themselves. How would anyone think these sites can be trusted not to abuse this?
Yes, this can, and will, be abused for tracking users across domains that they don't expect to be related.
But there are also legitimate use cases for this.
For example, consider the stackexchange family of sites. They are clearly related, have a unified branding, etc. but are on separate domains. On Firefox, which blocks third party cookies, I have to log in to each of those domains separately. I can't log in to stackoverflow.com, then go to superuser.com and already be logged in. That is a problem that First party sets would solve.
You can argue that it would be better for those sites to be subdomains of a single unified domain, but when the sites were created there wasn't any compelling reason to need to do that, because third party cookies were still very much alive and kicking. And I can say from experience that migrating an app to a different domain without breaking things for users is a royal pain, and can be very expensive.
I'm not saying that First Party Sets should be accepted as is, but it is attempting to solve real problems. And I think a solution that simultaneously protects users' privacy and maintains a good experience for sites that are legitimately related will be difficult to find, or maybe impossible.
> I can't log in to stackoverflow.com, then go to superuser.com and already be logged in.
I would expect a popup like “This site wants to share cookies with stackexchange.com, press Allow to sign in, press Reject to reject forever or press Ignore to decide later”. Takes a single click to enjoy the benefits of both worlds. The mechanism should make sure that every website has a single “first-party domain” shared across all subsites and that first-party domain must not share cookies with any other site than itself to minimize confusion.
> You can argue that it would be better for those sites to be subdomains of a single unified domain, but when the sites were created there wasn't any compelling reason to need to do that
I can also argue that Safari and Firefox have been blocking third party cookies for years now. So stack overflow has had plenty of time to adapt and migrate to the "right" organisation.
To me it look like either they care about allowing unified sign in on their various domaines, and they should have migrated to a subdomain model a long time ago, because users of Firefox, Safari etc have been negatively impacted for a long time. Or they do not care that much (which is fine), but then chrome blocking third-party cookies and the discussion around first party sets should not concern them too much.
Stack overflow was founded in 2008. Netscape added a block third party cookie button in 1997 (and the web has mostly worked fine with that feature turned on ever since).
This reminds me how google conveniently made the switch to manifest v3 when there were legitimate use cases like adblockers. Sure, technically speaking v3 is more secure and that may be better for users but your comment just made me think the opposite is in motion here.
> For example, consider the stackexchange family of sites. They are clearly related, have a unified branding, etc. but are on separate domains. On Firefox, which blocks third party cookies, I have to log in to each of those domains separately. I can't log in to stackoverflow.com, then go to superuser.com and already be logged in. That is a problem that First party sets would solve.
Other sites seem to handle this fine with redirects and cross-origin headers. Sure, at some point you land on "signin.foo.com", but from the user experience you were authenticated without having to sign in again.
OIDC seems like it can reasonably help in a fair number of these cases, maybe? it's iffy because (a) the major providers, are, well, Google and their ilk, (b) SSO solutions trend toward reducing user confusion at the cost of choice--im still out on whether the common "enter your email/account identifier so we can select which IDP we use" login flow is something of an anti-pattern or not
i generally like having the option for "sign in with github" as opposed to the all-encompassing "sign in with google" (ignoring that github is a microsoft account but not quite at this point)
smaller-scope IDPs for a particular field ("ey, you work on code stuff? you probably have either a github or gitlab account to log into our code-adjacent service" or "ey, you use stackoverflow? you can use that same login on superuser") is maybe a decent middle ground, where shared authentication is more explicit than third-party cookies were
Stack Exchange sites have a horrible authentication system so using them as an example is a bad start.
However they could solve this "problem" in a number of ways, the most straightforward being to use subdomains instead of individual domains.
I put "problem" in quotes as it's not even a problem; it's browsers working as intended. When you visit different domain names, you should expect that your browser won't be aware of data (cookies) stored by other domains.
First Party Sets are legitimately terrifying to me, it gives a commercial party (Google) complete control over who is and isn't allowed to set cookies in a third-party context. It's Google using their absolutely dominating market share to force even more control.
> On Firefox, which blocks third party cookies, I have to log in to each of those domains separately. I can't log in to stackoverflow.com, then go to superuser.com and already be logged in. That is a problem that First party sets would solve.
Brave is a Chromium derivative, not Chrome. Can't imagine why any of this would imply they would need to stop deriving Chromium: they can develop and deploy whatever cookie policies and defaults they want.
They have software engineers, I’m sure they plan on just turning off that portion of the code and moving on with life like they do with so much of chrome engine
I know this isn't quite the right place, but can anyone point to some research or writeups on the Chrome ad topics stuff? How does that impact user privacy? What is shared with third parties? I know next to nothing about it at the moment.
I am the main author of 2 papers evaluating the Topics API from Google: [1] and [2] and working on more research in that space.
I have also started compiling different papers and analyses on projects like the Privacy Sandbox initiative from Google (https://privacysandstorm.com/proposals/) as well as releasing other resources (datasets, tools, etc.), contributions welcome if you are interested!
I've tried brave and Firefox on mobile (android) and I've tried Safari on MacOs. I still just prefer Chrome, it's just a bit better. So I use it with third-party cookies turned off, which is easily (and transparently) done using the settings menu. I can also turn off this "related websites" thing.
So what exactly is the problem? All major browsers have allowed users to turn off 3P cookies for years.
brave a lot more shady and just wont say anything or let you opt out. many examples in the past. imagine if they were anywhere near a quarter of googles size it wouldnt be pretty imo.
[+] [-] codedokode|1 year ago|reply
Regarding analytics, I believe browsers should take user's side and do not cooperate with marketing companies; even better, they should implement measures to make user tracking and fingerprinting more difficult. There is no need to track user's browsing history; just make a product better than competitors (so that it gets first place in reviews and comparisons) and buy ads from influencers.
It would be great if browsers made fingerprinting more difficult, i.e.: not allowed to read canvas data, not allowed to read GPU name, enumerate audio cards, probe for installed extensions etc. Every new web API should guarantee that it doesn't provide more fingerprinting data or hides the data behind a permission.
Regarding 3rd party cookies: instead of shady lists like RWS browsers should just add a button that allows 3rd party cookies as an exception on a legacy website relying on them (which is probably not very secure). Although, there is a risk that newspaper websites, blog websites and question-answers websites will force users to press the button to see the content.
[+] [-] autoexec|1 year ago|reply
Browsers were supposed to act as agents working for the user. User-agents. These days it's getting harder and harder to find a browser that doesn't work for an ad company at the expense of the user.
Chrome's entire reason for existing is data collection. Firefox can, for now at least, be hardened to work for the user (and prevent a lot of fingerprinting), but Mozilla is an ad-tech company too now. They've made their lack of respect for Firefox users clear by making Firefox spy on users by default so that Mozilla can sell that data to marketers.
Currently, you can disable that spying in about:config by setting dom.private-attribution.submission.enabled to false (see https://news.ycombinator.com/item?id=41311479 and also https://web.archive.org/web/20240827185708/https://make-fire...). No idea how long that will continue to be an option or how often you'll have to go back and reset that back to false following updates though.
We really need a new browser that actually works in the interest of the users.
[+] [-] lcnPylGDnU4H9OF|1 year ago|reply
FWIW, it's practically impossible to provide that guarantee because the API necessarily provides at least the data point of, "Did they select an option in the permission notification?" ("If yes, what option was selected?" etc.)
It's often said that the only solution to this is regulation and there seems to be a good case for that perspective.
[+] [-] pndy|1 year ago|reply
https://news.ycombinator.com/item?id=40703546 - from 2 months ago
[+] [-] MisterTea|1 year ago|reply
Kinda hard to enact when the leading browser is developed by an ad company. Worse, the same company is contributing to the firefox foundation and drives web "standards." Its all collusion and the simple fact that browsers are more complex than the OS they run on is deliberate in ensuring no scrappy team can disrupt them.
My curmudgeonly solution is to avoid as much of the web as possible and focus on human scale computing.
[+] [-] factormeta|1 year ago|reply
This should be what browser maker's #1 focus! Preventing fingerprinting of user's browser.
Seems all this cookies talk the news and for policy makers are just limited hangouts.
[+] [-] nine_k|1 year ago|reply
But anything more precise would be uncomfortable.
[+] [-] TacticalCoder|1 year ago|reply
I'd say the only area where I still see Chrome leading a bit is for web development: when I run super-heavy JavaScript in dev mode, Chrome is faster than Firefox at executing all the JavaScript nonsense. Seen that there's no ecosystem with more turds, bloatedness and slowness than that horror that JavaScript-the-piece-of-crap is, having a browser a bit quicker at running JavaScript helps.
Long story short: for Web development, I use Chromium (it ships with Debian). For the rest I use Firefox.
> Firefox also has HTTPS-only mode...
In doubt port 80 is blocked by the firewall too.
> encrypted DNS without fallbacks,
And Firefox has a relatively easy "corporate" setting too where you can force also DNS "in the clear" over port 53 UDP (well, it's 99.9999% of the time going to be UDP so you can even firewall port 53 TCP and things shall keep working: believe me I know: theory vs practice and all that)
It's convenient if you run your own DNS resolver (which, itself, can then be forced to only use encrypted DNS).
> supports SOCKS
I confirm: a SOCKS5 proxy over ssh is always sweet.
Firefox just works.
[+] [-] morjom|1 year ago|reply
https://privacytests.org/
(Scroll down to Misc tests)
[+] [-] netdevnet|1 year ago|reply
[+] [-] threeseed|1 year ago|reply
It allows long lived first party cookies so isn't that much better.
Only Safari clears them after 7 days to prevent tracking.
[+] [-] JohnFen|1 year ago|reply
> Related Website Sets (RWS) is a way for a company to declare relationships among sites, so that browsers allow limited third-party cookie access for specific purposes.
So the website itself gets to declare other "blessed" domains that can bypass third party cookie blocks? Big websites are constantly looking for ways to abuse users by bypassing their attempts at protecting themselves. How would anyone think these sites can be trusted not to abuse this?
[+] [-] thayne|1 year ago|reply
Yes, this can, and will, be abused for tracking users across domains that they don't expect to be related.
But there are also legitimate use cases for this.
For example, consider the stackexchange family of sites. They are clearly related, have a unified branding, etc. but are on separate domains. On Firefox, which blocks third party cookies, I have to log in to each of those domains separately. I can't log in to stackoverflow.com, then go to superuser.com and already be logged in. That is a problem that First party sets would solve.
You can argue that it would be better for those sites to be subdomains of a single unified domain, but when the sites were created there wasn't any compelling reason to need to do that, because third party cookies were still very much alive and kicking. And I can say from experience that migrating an app to a different domain without breaking things for users is a royal pain, and can be very expensive.
I'm not saying that First Party Sets should be accepted as is, but it is attempting to solve real problems. And I think a solution that simultaneously protects users' privacy and maintains a good experience for sites that are legitimately related will be difficult to find, or maybe impossible.
[+] [-] renonce|1 year ago|reply
I would expect a popup like “This site wants to share cookies with stackexchange.com, press Allow to sign in, press Reject to reject forever or press Ignore to decide later”. Takes a single click to enjoy the benefits of both worlds. The mechanism should make sure that every website has a single “first-party domain” shared across all subsites and that first-party domain must not share cookies with any other site than itself to minimize confusion.
[+] [-] IMTDb|1 year ago|reply
I can also argue that Safari and Firefox have been blocking third party cookies for years now. So stack overflow has had plenty of time to adapt and migrate to the "right" organisation.
To me it look like either they care about allowing unified sign in on their various domaines, and they should have migrated to a subdomain model a long time ago, because users of Firefox, Safari etc have been negatively impacted for a long time. Or they do not care that much (which is fine), but then chrome blocking third-party cookies and the discussion around first party sets should not concern them too much.
[+] [-] hedora|1 year ago|reply
[+] [-] muratsu|1 year ago|reply
[+] [-] ddtaylor|1 year ago|reply
Other sites seem to handle this fine with redirects and cross-origin headers. Sure, at some point you land on "signin.foo.com", but from the user experience you were authenticated without having to sign in again.
[+] [-] fivre|1 year ago|reply
i generally like having the option for "sign in with github" as opposed to the all-encompassing "sign in with google" (ignoring that github is a microsoft account but not quite at this point)
smaller-scope IDPs for a particular field ("ey, you work on code stuff? you probably have either a github or gitlab account to log into our code-adjacent service" or "ey, you use stackoverflow? you can use that same login on superuser") is maybe a decent middle ground, where shared authentication is more explicit than third-party cookies were
[+] [-] wackget|1 year ago|reply
However they could solve this "problem" in a number of ways, the most straightforward being to use subdomains instead of individual domains.
I put "problem" in quotes as it's not even a problem; it's browsers working as intended. When you visit different domain names, you should expect that your browser won't be aware of data (cookies) stored by other domains.
[+] [-] jonkoops|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] lupusreal|1 year ago|reply
The cure is worse than the disease.
[+] [-] styfle|1 year ago|reply
Or are developers supposed to submit their related domains to each browser and they all have their own list to maintain?
This sounds like HSTS.
[0]: https://github.com/GoogleChrome/related-website-sets/blob/ma...
[+] [-] tomComb|1 year ago|reply
[+] [-] callmeal|1 year ago|reply
[+] [-] namdnay|1 year ago|reply
apparently this was written a few weeks ago :)
[+] [-] pimlottc|1 year ago|reply
[+] [-] knallfrosch|1 year ago|reply
[+] [-] acheron|1 year ago|reply
[+] [-] topspin|1 year ago|reply
[+] [-] EasyMark|1 year ago|reply
[+] [-] aftbit|1 year ago|reply
[+] [-] yohhaan|1 year ago|reply
I am the main author of 2 papers evaluating the Topics API from Google: [1] and [2] and working on more research in that space.
I have also started compiling different papers and analyses on projects like the Privacy Sandbox initiative from Google (https://privacysandstorm.com/proposals/) as well as releasing other resources (datasets, tools, etc.), contributions welcome if you are interested!
Best,
Yohan (https://yohan.beugin.org/)
[1] Interest-disclosing Mechanisms for Advertising are Privacy-Exposing (not Preserving) https://petsymposium.org/popets/2024/popets-2024-0004.php
[2] A Public and Reproducible Assessment of the Topics API on Real Data - https://arxiv.org/abs/2403.19577
[+] [-] afavour|1 year ago|reply
https://arxiv.org/html/2403.19577v1
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] enhancer|1 year ago|reply
[+] [-] ssss11|1 year ago|reply
[+] [-] martinald|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] doo_daa|1 year ago|reply
[+] [-] bugtodiffer|1 year ago|reply
Is that enough rationale to add this to the list?
[+] [-] hashtag-til|1 year ago|reply
[+] [-] nashashmi|1 year ago|reply
[+] [-] mrwww|1 year ago|reply
[+] [-] cabbageicefruit|1 year ago|reply
[+] [-] morkalork|1 year ago|reply
[+] [-] JonChesterfield|1 year ago|reply
[+] [-] pennybanks|1 year ago|reply
brave a lot more shady and just wont say anything or let you opt out. many examples in the past. imagine if they were anywhere near a quarter of googles size it wouldnt be pretty imo.
[+] [-] unknown|1 year ago|reply
[deleted]