[kwlug-disc] Firefox blasphemy: time to switch to Blink rendering engine?

[Doug Moen]

The Ars Technica article is biased. It article ends with this misleading quote from Brave:

> "This brings about a total shift in the Web's default behavior," the privacy team members wrote. "To date, browsers have assumed users want every site to remember them unless the user takes some explicit step against that remembering."

Actually, this isn't true of Firefox or Safari, because they added protections against Bounce Tracking in 2020 (Mozilla calls it Redirect Tracking). So Firefox will already detect and delete these cookies automatically. A more balanced article would compare Brave's "unlinkable bouncing" to Firefox's Enhanced Tracking Protection 2.0. The Brave tech will delete the tracking cookies earlier than Firefox, but only for domains in a blacklist.

https://blog.mozilla.org/security/2020/08/04/firefox-79-includes-protections-against-redirect-tracking/

In the comments section of the Ars Technica article, people discuss the fact that the purpose of Brave is to push the BAT cryptocurrency on people, because that's how Brave makes money. There is this comment:

> I feel very conflicted about Brave. I liked the browser experience, but I really *HATED* the constant crypto spam. So much that I stopped using it.

Doug Moen.

On Wed, Mar 9, 2022, at 9:48 PM, CrankyOldBugger wrote:
> It seems that Ars Technica has been following our mail.. they just published a writeup on the Brave browser:
> 
> https://arstechnica.com/information-technology/2022/03/brave-has-a-plan-to-stymie-websites-that-override-your-privacy-settings/
> 
> 
> 
> On Tue, Mar 8, 2022 at 9:38 PM Ronald Barnes <ron at ronaldbarnes.ca> wrote:
>> Doug Moen wrote on 2022-03-08 06:18:
>> 
>> > The 3 major organizations that determine the web standards are
>> > Mozilla, Apple and Google. I have been observing this process
>> > closely, since I am following the evolution of the WebGPU standard
>> > for a few years now. I am on the mailing list and read all the
>> > meeting minutes. It is Mozilla, Apple and Google employees who do all
>> > the heavy lifting in defining this standard. And they are equal
>> > partners in defining the standard. There is no sense in which one of
>> > these orgs is dominating the design, or in which one is only a junior
>> > partner. The WebGPU project's goal is to ship WebGPU 1.0
>> > simultaneously in all 3 browsers when the standard drops, which means
>> > Mozilla, Apple and Google all have a veto on design decisions they
>> > are opposed to.
>> 
>> I would want Mozilla to remain on that steering committee, no matter what.
>> 
>> And this WebGPU sounds interesting.
>> 
>> 
>> >> The early advantage of the Linux kernel was that we had one smart
>> >> guy at the helm that most people trusted.
>> >> 
>> >> Google is not that guy.  Neither is Mozilla.  We don't have that
>> >> guy in the browser space.
>> > For me, Mozilla is that guy in the browser space. Mozilla's mission
>> > is to create a free and convivial internet, one that puts users, not
>> > multinational corporations and advertising companies, first. Here is
>> > their mission statement: 
>> > https://www.mozilla.org/en-US/about/manifesto/
>> 
>> Again, is this a function of rendering engine, or how it's implemented?
>> 
>> 
>> 
>> > For me, it would be catastrophic for Mozilla to drop their role of
>> > defining web standards, leaving it to Apple and Google to define what
>> > the web is.
>> 
>> Agree, I think.  I want them on the committee, but if Mozilla has access 
>> to the open-sourced rendering engine, I'm not sure about what 
>> detrimental direction Google & Apple could take us in.  Perhaps a 
>> failure of imagination on my part.
>> 
>> 
>> 
>> >>> Who would be hurt by a modern day web rendering engine
>> >>> mono-culture?
>> >> Anybody who does not think certain browser extensions are a good
>> >> idea. If Mozilla loses the browser engine then it loses its seat at
>> >> the table when it comes to web standards.
>> > Right now, there's a big fight between Google and Mozilla about
>> > replacing cookies with an even more effective surveillance mechanism
>> > for delivering eyeballs to advertisers. I am on Mozilla's side in
>> > this fight, and I don't want Mozilla to drop out of the web standards
>> > process and let Google win. 
>> > https://blog.mozilla.org/en/mozilla/privacy-analysis-of-floc/
>> Implementing FLOC, or not, would be left to the Mozillas & Vivaldis & 
>> Edges and would still be the competition we need in browser space.
>> 
>> Floc isn't parted of Blink, as I understand it.
>> 
>> 
>> So Google can implement Floc in Chrome, but Microsoft can leave it out 
>> of Edge, Mozilla can not implement it,...  And still, a majority of web 
>> users will have floc in their browsers because Chrome has the market share.
>> 
>> As for extensions, I can see Mozilla having to change extension 
>> sub-system API / whatever *again* could deal it a fatal blow.
>> 
>> But extension writers could write once and be supported on all browsers, 
>> saving them effort in the long term.
>> 
>> 
>> I guess I'm assuming that Mozilla's Blink implementation would allow 
>> extensions to operate similar to status quo and Google's attempts to 
>> block things would be easier to work around than maintaining an entire 
>> rendering engine themselves.
>> 
>> 
>> I don't know, I've just been frustrated by some web dev recently and 
>> we're in a much different place now than we were in the '90s, so I'm not 
>> as concerned about the issue as I was back then.
>> 
>> Plus, the way things are going, we may have to anticipate a world 
>> without Firefox someday anyway.  And I say this with sadness as a 
>> dedicated Firefox user.
>> 
>> 
>> 
>> rb
>> 
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org
>> https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20220310/cd392feb/attachment.htm>