[gorgoiler]

Part of the uphill struggle for these forks is convincing people their brand is trustworthy.

I’m not sure exactly how, for example with LibreWolf’s lead contributor @ohfp, they are supposed to do this but having a much more fleshed (!) out set of biographies for the core team would help? Everyone’s real name, day job, background — the full curriculum vitae if you will. That would be a really good way of building trust with me, and I’m certainly someone in the market for switching to one of these forks.

I’m not saying that this kind of auto-doxing is a requirement and if it were I would be the first to decry it as an obnoxious entrance fee for the bazaar of free and open source software. We’re talking about a browser though — something as crucial as a text editor, kernel, file system, or programming runtime — and to that end it would be nice to have as much real-name trust built with users as Vim, Linux, Ext4, or Python. By way of analogy, everyone is entitled to a private life etc., but if you’re running for office then you should consider sharing as much not as little as possible.

Sorry if I sound entitled. I don’t mean to be. I’m just realistic about how terrifying it would be to find a supply chain attack in my browser.

[63stack]

Another uphill struggle is cloudflare. Get ready for sites being unavailable because of CF, and endless captchas that make you wonder if they even work.

[jasonjayr]

This would be an excellent opportunity for CF to assert a commitment to a secure and private web by propping up one of the FF forks, even a little bit, and simply make sure it's not auto-killed by their managed policies.

Obviously if a customer wants to manually kill it, it's on them, but CF has a lot of power in choosing defaults.

[tdeck]

As someone who cares about privacy, knowing that the company that MITMs a massive chunk of my TLS traffic to websites also controls my browser's funding would make me feel uneasy.

[nbf_1995]

I've been using LibreWolf for about a year, and I have not experienced endless / non-functional captchas.

As far I know this is because LibreWolf pretends to be Firefox. Looking in the devtools confirms that Librewolf is sending a firefox UA.

[63stack]

My experience is that anything that tries to tamper with the UA will send CF into a frenzy.

My regular firefox instance is pretty much okay. Unfortunately there is a bunch of super popular crapware shit like Teams and Slack that refuses to properly work on Firefox, unless you tweak the UA. The last time I had to do this was about half a year ago, but Slack refused to let me "huddle", unless I changed my UA. Same with Teams, it straight up said I need to install chrome if I want video chat.

Any time I forgot to change back my UA, CF would not let me in anywhere. I got the captcha, clicked on it, it said "all good", reloaded the page, and I got redirected back to the captcha. Endless loop.

[hipsterstal1n]

Just curious, what kind of changes or tweaks do you typically make to your UA and why?

[63stack]

I just gave two examples above.

[wtallis]

You gave examples of when you change your UA, but didn't actually say what change you make. Are you changing it to match a Google Chrome UA, or what?

[II2II]

> Part of the uphill struggle for these forks is convincing people their brand is trustworthy.

Agreed. I recently installed one of the forks, appreciate how it defaults to the privacy related features that need to be manually enabled in Firefox, but won't use it for anything where privacy and security is important. Which kind of defeats the point.

As for how to build trust: I don't have a clue. Things like real names, day jobs, and backgrounds don't really mean much to me. First of all, verification would be an issue. Second, it isn't really an expectation that I hold any other project or organization to. I suppose being in the main repository of a distribution that I trust would help.

(It's also worth noting that trust is more than trust in motivation. There is also trust in the competence of the individuals involved and in the project's decision making process. One can build trust under a handle. True names are not required.)

[gorgoiler]

This is a helpful contribution. Thank you. My counterpoint is only on real names: LKML and Debian Developers are two examples of projects I trust and I think part of that is real names. Another part is the publicly known application process: namely that you can’t join unless vouched for by other members, and a degree of vetting is in place.

Elevating a browser to the same standard as (or even higher than!) an OS is completely reasonable.

[II2II]

I can definitely understand the need for real names from the perspective of people managing a project, along with someone vouching for those people. But managing a project is different from using the product of that projects. I very much doubt that many users have the ability or desire to do the vetting themselves so I am perfectly fine with maintaining the privacy of developers.

Also agreed that browsers should be held to the same high standard as operating systems. Many people access confidential data with their browsers, may it be their own data or data about other people. (Going back to the notion of trust, I worked for a bank in the early days of the public Internet. The bank I worked for only allowed clients to use the bank's own software. In retrospect, a big part of the reason was the human angle rather than the technical angle. Sure, web browsers may have used the same level of encryption. Yet that is meaningless when the browser itself may serve as a man-in-the-middle.)