Seems a bit overkill to recompile to get "no third party cookies by default" when you can just open the settings and disable it when you first install the browser. The setting is kept between updates (in Firefox at least) and if you are paranoid you can always check with Dev tools or a dumping proxy that 3rd party cookies are still disabled after an update
This undervalues convenience. The convenience of not having to worry about privacy-hostile default settings. Also, this will not work where the user is running applications from read-only media, or using something like "Guest mode" on a Chromebook where changes to settings are either not possible or ephemeral.
This sort of argument in defense of so-called "tech" company "default settings" shenanigans has been called out in recent litigation. Courts are becoming aware of the power and significance of "default settings".
It's this idea of "overkill", or other simialr rationales, that I am referring to in the original comment. Just enough "friction" to stop people from changing things. Not worth the trouble, people may think. And this works year after year. Amazing. Browser vendors were not the first in the computer industry to utilise this type of tactic, but it's a fine example.
Not sure who "you" refers to in the parent comment: me or a hypothetical person. If it's the former, I use a text-only browser that neither auto-load resources nor runs Javascript, along a localhost-bound proxy that strips or adds cookies. This is perfect for me. Both software I can change and quickly re-compile at any time. If it's the later, and "you" refers to a hypothetical person, then I cannot comment on behalf of such persons.
What I do know is that most users do not change default settings.
> Some popular browsers are supposedly "open source" yet it appears no browser user longing for saner times has ever tried reversed this change and recompiling the browser for their own use. No third party cookies by default.
And my response was simply it's way easier for the vast majority of people to change a setting once, than compiling the source (and remember to stay up to date with new releases)
> What I do know is that most users do not change default settings.
And they don't install alternative privacy respecting browsers either.
The "vast majority of people" will neither find nor change settings. Ever.
They are not interested in computers and they certainly do not read and comment on HN.
When I use the term "browser user" in the quoted comment it can be assumed I am referring to browser users who can write/edit and compile source code. If I wanted to address or comment about a larger audience, including people who are not interested in computers, who do not read HN, i.e., "the vast majority of people", then I would not be commenting here.
I think most will agree that we should focus on making browsers by default limit the amount of private and identifying information sent to anywhere that didn't explicitly get authorized for it.
TBH, with today's web the only way I have found to limit the information sent is to either not use a browser to make HTTP requests (e.g., use TCP client instead) or use a browser that (a) does not auto-load resources, e.g., images, Javascript files, etc, and (b) does not run Javascript inside <script> tags. Of course no other silly stuff like automatic "DNS prefetch" either. This way I know that the only information I am sending is the information I the web user actually sent, i.e., the HTTP request. Otherwise, there is no way to know what other HTTP requests will be made to accomplish auto-loading images, fonts, etc. or what other HTTP requests will be made by auto-loaded or inlined JS when the browser automatically runs it.
When the user types or clicks on https://hostx.com/1.htm, the user knows she has sent a request for filepath "/1.htm" at hostx.com. That's straightforward and easy to understand. Her intent is clear. She wants the file named "1.htm" from hostx.com.
However, what if she uses a browser that auto-loads remote files and auto-runs JS, and, e.g., the file 1.htm instricts the browser to auto-load the file "1.js", the browser automatically runs 1.js without any input from the user, and then 1.js makes more HTTP requests. Has the user "authorised" that information to be sent. Imagine she does not know the contents of file 1.js. How can she authorise sending information, i.e., an HTTP request, if she does not know what is the information, i.e., the request, and where it is being sent.
