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.
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.
The recent events related to FF are not that much of a shift, considering that Google pays $20B per annum to its (technically non-ad tech) partners, then 85% of Mozilla's total revenue comes from its partnership with Google. That ship had sailed long time ago.
https://untested.sonnet.io/Defaults+Matter%2C+Don't+Assume+C...
What they haven't done before is spend a fortune buying up an ad-tech start up. They barely even bother to maintain a pretense that they care about Firefox users. They basically came right out and said "We know that users don't want this, we can't convince them to, so we were right to force it on them by default and just hope most people don't notice and start complaining" (https://cdn.adtidy.org/blog/new/2wffyscreen_mozilla.png?mw=1...)
https://spyware.neocities.org/articles/firefox
Mozilla only has their Google billion$ in mind, not you. https://digdeeper.neocities.org/articles/mozilla
Add this to /etc/hosts
0.0.0.0 www.google-analytics.com
0.0.0.0 google-analytics.com
0.0.0.0 ssl.google-analytics.comGoogle, of course, has rammed chrome into it's primary place.
I'm sorry, this seems egregious. I agree that it should've been off by default but I challenge anyone to read how the implementation works (not just the blog post and the FUD responses to it) before calling it a giveaway to the ad industry: https://github.com/mozilla/explainers/tree/main/ppa-experime...
FF is currently a key tool in the fight to avoid a Google-top-to-bottom future, and before we start the meme that it's gone to shit we should be really really sure that's actually true.
It gives no benefits to end users. Ad companies will not stop using old methods, they will just add one more method.
I hope responsible Linux distributions will patch this out and disable by default.
A fair model would be if this feature was opt-in and if Mozilla paid to the users who enabled it.
> The purpose of this API is to provide a privacy-first design for advertising companies to be able to measure how advertising drives conversions. That is, answering the question of whether advertising effectively achieves its goals, such as increased sales.
Not my problem. I don't earn anything from their sales.
Firefox is rock solid, open-source, backed by a great organization (which has recently reinvested additional resources in it) and a joy to use imo. Also, the levels of vitriol that even the slightest bit of anonymous telemetry incurs is unhelpful and I encourage people who hold that viewpoint to really interrogate it.
Right now is actually Safari that prevents it, like it or not. Especially iOS one where users have to use it. Firefox is rounding error in this fight.
The implementation is just FLoC/Topics API all over again and it's still not compelling. The first kick in the teeth comes right at the start where the entire thing is predicated on data gathered from having an ad shoved in your face.
> At impression time, information about an advertisement is saved by the browser in a write-only store. This includes an identifier for the ad and whether this was an ad view or an ad click.
I do not want ads. Ever. Like many (likely most) firefox users, I go to some lengths to prevent them from showing up in any form. Now that firefox is going to be profiting directly off of firefox users seeing and clicking on ads they will certainly degrade our ability to prevent them.
It then involves sending my data to third parties so that it can be aggregated. Then my browsing has to be monitored to identify conversion events. None of this is acceptable.
Here's what their Cookie Monster paper says:
> User perspective. Ann browses various publisher sites that provide content she is interested in, such as nytimes.com and facebook.com. Ann does not mind seeing relevant advertising, understanding that it funds the free content she enjoys.
I am not Ann. I very much mind seeing advertising, relevant or not. I do not understand that if funds "free content" I enjoy. If I need to be exploited to pay for something, that thing it isn't "free" and if it's infested with ads I do not enjoy it. The entire thing is based on a fantasy where users find this acceptable. We don't and it isn't. If we did, we'd probably all just be using chrome.
> FF is currently a key tool in the fight to avoid a Google-top-to-bottom future
Why should we care if Firefox isn't Google if both are just going to exploit us?
That still isn’t a great reason to then keep using the even worse option, being Chrome, instead.
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.
Wrong. The status of permissions should not be visible to the page in most cases. Instead, fake data should be returned from them. That would be practical.
Assuming that's true, it seems to waste everyone's time and bits to fake it instead of just not answering or a minimal denial.
If a bird app (or, heck, pancake recipe site) asked for WebRTC or GPU access I would be rightfully suspicious. It's a shame these things don't happen.
There is a risk that it ends up like cookie banners, and the adtech industry manages to brainwash the world into thinking that the government is the bad guy and they just want some harmless data to share with their 1,345 best friends and they are “forced” to show these. Despite there being no requirement at all to track data, and they break the law with it anyway so why bother.
If 99% of users will have permission disabled then it has little value, and only those who enabled it can be tracked. I don't give permissions to sites so this will not apply to me.
Also, the status of permission (1 bit) provides less information than API it protects (for example, list of installed fonts or GPU name) so it is a win.
https://news.ycombinator.com/item?id=40703546 - from 2 months ago
In light of that acquisition, this also seems related. Firefox is the best choice but Mozilla is the biggest reason why people aren't using it and shit like this doesn't help.
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.
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.
But anything more precise would be uncomfortable.
The tracking is a constant assault, and I'm no longer willing to put up any of it, even if the data being tracked is relatively minor. Screw the bastards, they've burned one too many bridges.
- $120-140k, hetero, white, 190-220 lb, broadly Christian.
- $137,500/y, prefers tall redhead females, Irishman originally from Cork, 197 lb, observant Catholic.
The first one is too unspecific, while the second could suffice to identify a particular person in a neighborhood.
What makes a butter knife safe is not that it's completely devoid of an edge, but that its edge is sufficiently blunt.
Also the data about you can be used to charge you a higher price. For example, if a company knows that the user is reading HN, and we know that people using HN (expect for me of course) all are mostly filthy rich Californian software engineers or enterpreneurs so they should have no problem with paying a little more.
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.
(Scroll down to Misc tests)
This seems to be a not very good comparison, and it looks like it cherry-picks convenient for a certain browser points and ignores others. Look at "fingerprint protection", for example, and see that it does not include features that provide most fingerprinting data:
- preventing reading GPU name via WebGL debugging extension (does Brave block this?)
- preventing reading back canvas data which is used to fingerprint browser and OS code responsible for rendering graphics and text
- enumerating audio devices
And if you read the issues in Brave github [1], then you'll notice that Brave developers refuse to block features providing important fingerprinting information under compatibility" reasons (including GPU vendor and model), although these features could be made blocked only in high security mode.
So regarding fingerprinting, the comparison you refer to is pretty much worthless: it doesn't mention many important fingerprinting APIs.
FWIW the about section says this: "Each privacy test examines whether the browser, on default settings, protects against a specific kind of data leak."
The maintainer is a Brave employee and this is a project they were already doing before joining Brave. I'm hoping that they aren't manipulating it in favor of Brave.
I sent those three options as a feature request. Do you think the site is still useful in some capacity?
It allows long lived first party cookies so isn't that much better.
Only Safari clears them after 7 days to prevent tracking.
I assume it's because of situations where websites include JavaScript from a third party, and then that JS uses first party cookies as a state-keeping workaround while synchronizing tracking information in some other way.
> 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?
But as the article details, the contents of that preliminary list is already disconcerting. The whole “Google as the arbiter of all things ads” concept is a bust.
But the alternative isn’t great either - today’s system of third party cookies allows for far worse. We need some better ideas.
How is that not the website declaring it? Approval processes are meaningless.
> today’s system of third party cookies allows for far worse.
That's why I want zero third party cookies.
Submitting your website to a list controlled by some arbitrary website on the Internet is very much different from serving some kind of metadata to visitors that their browsers interpret.
Also the approval process existing does matter. Under a normal situation when you serve some kind of metadata (like what sites you are "related" to) there is no "approval" process to who gets to serve this kind of metadata and who doesn't.
The tools to do this the right way exist in so many different ways.
Wtf, seriously? I skimmed the post and honestly didn’t think RWS was so bad, assuming that obviously it would be decentralized. A centralized list that Google (or some shell consortium) controls is the biggest no-no. Decades of erosion of web principles have clearly made us complacent.
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 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.
Also, there is no way to know which related site the user is logged in to, so they would have to prompt for every one of their sites.
This is not how it works. The mechanism is about allowing a cluster of websites to choose a single first party domain and have all of them share cookies together, not sharing arbitrary cookie from arbitrary domain, otherwise it would create loopholes in connected components that bring back the downsides of third-party cookies. What you mentioned should be done using SSO.
After thinking about it a bit more, I have a clearer picture of how it should work in my mind:
* All cookies are double-keyed: the primary key is the origin of the top-level page and the secondary key is the origin of the page that sets the cookie, just like how partitioned cookies work right now.
* stackoverflow.com uses a header, meta tag or script to request changing its primary key domain to “stackexchange.com”
* The browser makes a request to https://stackexchange.com/domains.txt and make sure that “stackoverflow.com” is in the list, authorising this first-party domain change
* When the user agrees to the change, the page is reloaded with stackexchange.com as the primary key, thus stackoverflow.com can obtain login details from stackexchange.com via CORS or cross site cookies.
* A side effect is that all cookies and state are lost when switching the first-party domain. Should stackoverflow.com be acquired by a new owner, say x.com and changes its first-party domain to x.com, all cookies on stackoverflow.com are lost and the user will have to login on x.com again, maybe using credentials from stackexchange.com. It’s unfortunate but it works around the issues mentioned in the post in a clean way, avoiding loopholes that transfer cookies by switching the first-party domain frequently.
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.
Replace "Chrome" with "Internet Explorer" and we're back to 1999.
In IT, big tech never wastes opportunity to introduce a dark design behind a useful feature.
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.
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
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.
The cure is worse than the disease.
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...
apparently this was written a few weeks ago :)
[0] https://news.ycombinator.com/item?id=41038586
[1] https://www.theverge.com/2024/7/22/24203893/google-cookie-tr...
Though regardless of that, Related web sites (or whatever that set is currently called) does present a hole in that logic. It was originally meant to allow sites with different domains to share cookies/storage (like google.com and google.co.uk). From what it sounds like, bad actors are using it in the expected ways. There were supposed to be mechanisms to prevent this, but it seems like they failed in this case.
The list is in a public repository however, so Brave could have filled issues and a pull request to address the issue. Instead they decided to stage a meaningless survey and declare Chrome a threat to people everywhere.
If my favorite websites stop working with Firefox, they won't be my favorite websites anymore. I'll just stop using them instead.
Easily said, until it's your bank, or a government entity, or the electric company, or any of the thousands of other entities that have started blocking Firefox.
Firefox should really camouflage its user agent, or make it trivial to do so.
"If Google limited 3rd party cookies, we'd go out of business!", said the companies who have literally 0 Safari users.
Maybe I missed the memo that we stopped hating monopolies? Every browser worth considering, except Firefox and Safari, is based on Chromium. Firefox and Safari make up about 20% global market share, meaning Chromium in about 80% [0]. A bug in Chromium is a bug in all of them. A backdoor in Chromium is a backdoor in all of them. A feature of Chromium, good or __bad__, is a feature in all of them. It baffles me that this isn't a bigger concern to more people.
Most people were never worried, and probably will never be worried, with the points you're listing there. That's not to say they've stopped hating browser monopolies, just maybe not your definition of what a browser monopoly is or why they're problematic.
In general (not just browsers) most people treat "popularity" and "monopoly" as completely orthogonal concepts. I.e. something unpopular can still be a monopoly, something with 99% usage can still not be a monopoly. There is typically just a tendency for extremely popular things to also happen to be a monopoly.
I'd like Firefox to stick around, but as far as I'm concerned, if Safari goes away, I couldn't care less.
I've been using Brave as primary for years. At this point I'd pay for a license if it were necessary. Frankly that would be an improvement: if it's free, you're the product. Brave just monetizes you differently.
I no longer argue with the legion of Brave haters. I've decided they're a benefit: the more people that don't use Brave the less likely Google et al. will be compelled to destroy it.
Maintaining a very diverged fork can take even more work than building your own browser. I think they don't want to stop receiving upstream updates when the upstream is one of the biggest software projects in the world.
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
at the end of the day it seems like 90% of people using google products dont even care. while some even prefer the convivence of some features that directly save your info. not sure what percentage that is compared to the people that practice a lot privacy.
but shown by the chrome market share google really doesnt have to care about this section of users. the fact theyre willing to try things is a good sign imo. either way in 2024 to be complianing about google is funny to me. literally dont have to interact or use a google product, they already have your information and so does the internet better to not let them occupy any of your mind as well
Is that enough rationale to add this to the list?
They will have this as proposal, its status will be "not on any standards track", it will be shipped in Chrome, and enabled by default.
Firefox and Safari have both said "no, we're not doing that". And then chrome decided to move forward with it, regardless of whether it gets standardized.
I don't know what it might take for people to migrate away from Chrome en masse, but the alternative is there.
No issues with Google services like Youtube (I'm an addict)
I keep Chrome installed just in case, and Edge due to being on Windows.
* side tabs, I would say, the tab is a horizontal extension of the page, so they're horizontal tabs, right?
Mozilla is a husk of what it could have been, and that's hurt Firefox.
I think Mozilla is poorly managed and feature may have been slow or "lagging behind". But for me the lack of those shiny new things might as well be a feature than a bug.
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.
All settings in Brave with an impact on user privacy are opt-in. They even inform you of their product metrics, when you first start it, despite having a paper on how they anonymize that data. Versus Firefox, which never bothered. Firefox, which also added metrics for ads, similar with Privacy Sandbox, without informing users.
I've never seen a browser with such a strong focus on privacy, the only contender it has being LibreWolf.
The hate against Brave on this forum is completely unjustified and based on falsehoods, as if the issue isn't about Brave itself.
These are the primary issues I hear about regarding Brave on this forum.
It's also founded by Brendan Eich who was forced out of Mozilla for his strong and vocal opposition of same-sex marriage. I tend to be a bit idealistic, but this is a strong reason for me to avoid Brave, especially when they are injecting content into pages.
Way more than just two chromium browsers in existence.
> In our study, the large majority of users (~73%) made at least one incorrect determination of whether two sites were related to each other, and almost half (~42%) of the determinations made during the study (i.e., all determinations from all users) were incorrect. Most concerning, of the cases where both sites were related (according to the RWS feature), users guessed that the sites were unrelated ~37% of the time, meaning that users would have thought Chrome was protecting them when it was not.
> ... We conclude from this that the premise underlying RWS is fundamentally incorrect; Web users are (understandably, predictably) not able to accurately determine whether two sites are owned by the same organization. And as a result, RWS is reintroducing exactly the kinds of privacy harms that third-party cookies cause.
> Lest anyone judge the study participants for being uninformed, or not taking the study seriously, consider for yourself: which of the following pairs of sites are related?
1. hindustantimes.com and healthshots.com
2. vwo.com and wingify.com
3. economictimes.com and cricbuzz.com
4. indiatoday.in and timesofindia.com
> (For the above quiz, if you chose “4”, then, unfortunately that is incorrect. That is in fact the only pair of the four that isn’t considered “related” to each other.)
Reminds me of the research that shows that 87% of people in the US can be uniquely identified with only three pieces of information: date of birth, gender, and zip code [1].
[1]: https://dataprivacylab.org/projects/identifiability/paper1.p...
ZIP codes contain maybe 40K residents [0] (many contain fewer) and there have been around 25K days in the last 70 years. Sure births are not evenly distributed, but still...
[0] https://www.unitedstateszipcodes.org/images/comparison-of-po...
To clarify: your date of birth includes the year. It’s more specific than your birthday, which we usually think of as just day & month.
timesofindia.com also redirected me on tabbing out to a "you won a free Samsung phone". Shady.
Google earned billions of dollars with their contextual ads long before pervasive tracking was a thing.
Nobody forgets that, and the issue (at least for me) isn't the ads, it's the spying. It's entirely possible to have a financially healthy ad ecosystem without the spying. It used to be the norm, even.
