This is their privacy policy: https://h5hosting-dra.dbankcdn.com/cch5/petalsearch/global/agreement/privacy-statement.htm?language=en-us
It includes detailed fingerprinting metrics like mouse behavior and font information.
I should probably link it, thanks for the feedback.
I said that about Petal because readers likely hadn't heard of it and didn't have any expectations. l assume readers already knew Bing, Google, and Yandex were bad for privacy.
Not at all; there are tons of newish engines out there, the best of which are trying to carve out a niche for themselves in an area that Google and Bing ignore. I listed 44 English engines with their own indexes, along with some for other languages which I'm unfortunately unable to review because I don't speak the langs required.
On these engines, you won't get far if you use natural language queries or expect the engine to make inferences. Use broad terms and keywords instead. I recommend giving Mojeek, Marginalia, Teclis, Petal (bad privacy, but usable through Searx), Kagi, and Alexandria a try.
The reality is more nuanced than this. Wrote up my thoughts on my blog: A layered approach to content blocking.
Strictly speaking about content filtering: declarativeNetRequest is honestly a good thing for like 80% of websites. But there's that 20% that'll need privileged extensions. Content blocking should use a layered approach that lets users selectively enable a more privileged layer. Chromium will instead be axing the APIs required for that privileged layer; Firefox's permission system is too coarse to support a layered approach.
I wrote about both issues, and why Matrix isn't a perfect solution, previously: part 1, part 2. Starring WhatsApp, Firefox, Signal, XMPP, Email, and Matrix.
Also discussed on Lemmy: part 1, part 2.
Signal's problem is being a closed platform; Matrix suffers primarily from complexity. Both enable dependence on a single small group, and therefore enable user domestication. That being said, Matrix is considerably less bad than Signal.
For large public rooms, IRC continues to be the best option. All its issues are client-side; IRCv3 supports history, multiple devices, authentication without NickServ, and even typing notifications. All these features are supported on Oragono. For small, private E2EE rooms, all existing solutions have major trade-offs.
I wrote an article in a similar vein a month ago: Becoming physically immune to brute-force attacks.
Stuffing the planet into a 100%-efficient furnace isn't enough to crack a 256-bit key.
I'm building off those ideas in what will be a little collection of programs that measures and generates passwords given physical constraints of a brute-force attacker (energy, power, mass, etc). The collection isn't really a collection yet; it currently contains almost one complete program: https://sr.ht/~seirdy/MOAC
Edit: URL typo
Unfortunately, Gitea (the forge software that powers Codeberg) has major accessibility issues. It's not usable from most assistive technologies (e.g. screen readers). GitLab isn't much better.
Sourcehut is pretty much the only GitHub alternative with good accessibility I know of.