Privacy-Respecting Software
github.com
github.com
I went through a mad phase where I had loads of extensions installed in my main browser. Then all these stories came out about addon authors getting contacted by shady actors who wanted to buy the addon so they could add malicious code that siphons off personal data. Now I just have uBlock Origin and that's it! I trust it NOT to be taken over by bad actors.
Addons also have exploitable bugs in them, and also having multiple 'privacy addons' can mean some overlap in functionality where the tracking protection is redundant since it's covered by another addon. Like who really needs Privacy Badger, DuckDuckGo privacy essentials, and then uBlock running all together?
And with browsers shipping with fingerprinting mitigation, and having the option to surf strictly HTTPS sites, some addons are becoming redundant, like HTTPS Everywhere & 'useragent spoofing' addons which can actually make you stand out (privacy.resistFingerprinting:true in Firefox FTW). The trick is to blend in with a useragent, not stand out.
> I went through a mad phase where I had loads of extensions installed in my main browser. Then all these stories came out about addon authors getting contacted by shady actors who wanted to buy the addon so they could add malicious code that siphons off personal data. Now I just have uBlock Origin and that's it! I trust it NOT to be taken over by bad actors.
Addons increase the number of parties you trust and also can make your browser more vulnerable. As we say in our openening paragraph https://www.privacyguides.org/browsers/
These are our current web browser recommendations and settings. We recommend keeping extensions to a minimum: they have privileged access within your browser, require you to trust the developer, can make you stand out, and weaken site isolation.
- https://en.wikipedia.org/wiki/Device_fingerprint#Browser_fin...
- https://groups.google.com/a/chromium.org/g/chromium-extensio...
> Addons also have exploitable bugs in them, and also having multiple 'privacy addons' can mean some overlap in functionality where the tracking protection is redundant since it's covered by another addon. Like who really needs Privacy Badger, DuckDuckGo privacy essentials, and then uBlock running all together?
Which is why common methodology now is very conservative. If you look at the research Arkenfox has done https://github.com/arkenfox/user.js/wiki/4.1-Extensions they recommend very few extensions.
> And with browsers shipping with fingerprinting mitigation, and having the option to surf strictly HTTPS sites, some addons are becoming redundant, like HTTPS Everywhere & 'useragent spoofing' addons which can actually make you stand out (privacy.resistFingerprinting:true in Firefox FTW). The trick is to blend in with a useragent, not stand out.
RFP does more than just adjust the user agent. User agent spoofing does *not* work.
As soon as you allow javascript there are dozens of metrics that can be used to profile you and to determine exactly what browser you have.
DuckDuckGo doesn't track you individually, or at least, they don't filter-bubble and advertise to you individually, but they do collect data on what users click on. Privacy-respecting? I think that's debatable.
The 1.1.1.1 app is a privacy tool insofar as it allows you to hide DNS requests from anyone in the middle of your connections, but it also means sending your DNS requests (or everything, if you use the VPN) to Cloudflare. According to exodus it contains 2 tracking scripts. Is the end result "privacy-respecting"? Might depend on your opinion of Cloudflare and/or your use case.
Should I Remove it [dot] com? Has some information about potentially unwanted programs, but it's also just some proprietary source of information and contains Google Ads and tracking scripts on its pages.
And so on and so forth.
> Without using a secure, privacy-centric DNS all your web requests can be seen in the clear. You should configure your DNS queries to be managed by a service that respects privacy and supports DNS-over-TLS, DNS-over-HTTPS or DNSCrypt.
These things do very little for privacy as we painstakingly write about in this article https://www.privacyguides.org/technology/dns/
> "Be careful when installing unfamiliar browser add-ons, since some can compromise your security and privacy."
I like these little interjections to explain things for beginners.
In this case though, I wonder what code auditing/verification is in place to support such a statement:
> "At the time of writing, the above list were all open source, verified and 'safe'"
It doesn't seem very up-to-date even if the last update was only three hours ago. It still describes Element as 'Matrix + Riot client' even though this changed in 2020. [0]
> I like these little interjections to explain things for beginners.
These are nice, however a proper criteria would be even nicer. Currently it is just a list of vaguely private and open source software.
Something which is clearly alpha-state isn't usable to regular users shouldn't have a "recommendation". Then you get sub optimal recommendations, listing some projects which are unmaintained etc.
With the cleanup at https://privacyguides.org, (since we split from PTIO) we've removed a lot of things, and gone down the part of actually providing guidance rather than "use this software to make you magically more private".
I think it's important to think privately, modify behavior rather than rely on technology to do it all for you.
Looking at this particular list there are some bad choices:
- LessPass: We explicitly removed deterministic password managers https://github.com/privacyguides/privacyguides.org/pull/323, https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...
- AndOTP: Uses PBKDF2 and a heap of rounds that is unbelievably slow when you have a number of OTPs. Aegis uses Argon, which doesn't have this problem, and we think it's code is developed by someone who is security conscientious.
- Qwant: https://github.com/privacyguides/privacyguides.org/pull/342#..., we removed due to "due to bad privacy policies data is collected and shared with third parties"
- Silence: Unmaintained, uses SS7 network, should never be recommended.
- Off-The-Record: Doesn't cover group chats or other side channels, such as status updates, VOIP. In general XMPP isn't particularly "privacy friendly" https://web.archive.org/web/20211215132539/https://infosec-h...
- PGP: NO. It has no forward secrecy, it's a terrible way to encrypt real time communication.
- Matrix + Riot client: Seriously, it's been "Element" for ages now, makes me think the author really isn't up to date with current events.
- Ricochet: Unmaintained, (2016) domain dead, Only supported .onion HSv2
- Tox + qTox: Developed wrong. They developed the software then decided to write the spec afterwards. There's also https://github.com/TokTok/c-toxcore/issues/426
- Mailfence: Last email I sent to them they don't use any kind of disk encryption
- CriptText, these things really don't help, they are walled, in that everyone has to be on a centralized service to get the benefit. E2EE that comes with web-apps can often be dangerous as it can change, have vulnerabilities introduced after an audit etc.
- TorBirdy: Unmaintained
- Mumble: Not really private
- Linphone: Not really private
- Rocket Chat: Experimental E2EE
- Browser Extensions: NO JUST NO. https://blog.privacyguides.org/2021/12/01/firefox-privacy-20... https://github.com/arkenfox/user.js/wiki/4.1-Extensions
- Video Platforms: These are not private
- RSS Clients: There are better options
- Mobile Operating Systems: Options without Verified Boot. NO. https://source.android.com/security/verifiedboot
- Linux recommendations: Those are also awful and don't have any threat model in mind.
I'm going to stop now, it's basically every bad thing that was ever on PTIO, that we removed. Basically there are terrible recommendations with a few good ones sprinkled in.
This list is *not* maintained!
Could you elaborate? My friends and I self-host mumble. I never really thought about it, but I kind of just assumed that this is as private as it gets. I didn't read through the mumble source code, but I just assumed it wouldn't be sending data anywhere else.
Edit: Their privacy page describes what data is sent where/when and it reads very privacy friendly to me: https://www.mumble.info/privacy/
[1]: https://github.com/privacyguides/privacyguides.org/pull/192
Unless your self hosting, it's not really private, as it doesn't use E2EE. If you're self hosting and restricting access, then any software could fit into the "private" category. Does that mean every self-hostable piece of software should be classified as "private"?
> As long as everyone involved trusts the server operator
This is the key point that is never mentioned. The software is mentioned but nothing about who is running it.
On a side note something we're looking very forward to is:
[WIP] MSC3401: Native Group VoIP Signalling #3401 https://github.com/matrix-org/matrix-spec-proposals/pull/340...
Which seems to be a focus for 2022:
https://element.io/blog/introducing-native-matrix-voip-with-...
In my mind, as long as the self-hostable software isn't sending data back to some central server, yes? I guess we have different definitions, which is fine, this wasn't criticism of your list. I was just curious if you knew something I didn't.
> This is the key point that is never mentioned. The software is mentioned but nothing about who is running it.
It's interesting to have list of tools that can be self-hosted. My friends and I host mumble/irc/pastebin/img upload for our use. We've got it in a wireguard vpn, it works well. Finding out about other services that we can self-host and use is a always interesting. Although I can't really think of something we need at the moment.
For most people self-hosting isn't an option or something they want to do.
Software should be developed with E2EE from the beginning wherever possible.
Somebody should make a list of lists. Or a list of lists of lists...
> - Off-The-Record: Doesn't cover group chats or other side channels, such as status updates, VOIP.
... and yet it's still the ONLY cross-messenger system, not everybody uses group chats, and not everybody cares about status updates or whatever.
> PGP: NO. It has no forward secrecy, it's a terrible way to encrypt real time communication.
That's not what it's for, and email is not "real time communication". I have an archive of email going back 30 years. Forward secrecy is not always a win.
> Tox + qTox: Developed wrong. They developed the software then decided to write the spec afterwards.
Many of the projects you recommend don't even have specs. Tox may be a hot mess, but it's not unusual in that regard.
> Browser Extensions: NO JUST NO.
That's an awfully strong statement to make without a threat model...
> Video Platforms: These are not private
... but you list "social networks", which are intrinsically "not private" in their very purpose, just like video sharing...
Etc.
There is Matrix. The issue is that people don't know what actions are E2EE and what is not.
> That's not what it's for, and email is not "real time communication". I have an archive of email going back 30 years. Forward secrecy is not always a win.
It was listed under the "encrypted messaging" section.
> That's an awfully strong statement to make without a threat model...
It's not, its that browsers have evolved to the point where a lot of those extensions are unessary and actually are counter to privacy, modifying your fingerprint to be unique.
> ... but you list "social networks", which are intrinsically "not private" in their very purpose, just like video sharing...
As it happens we're removing those sections for this very reason https://github.com/privacyguides/privacyguides.org/discussio...
The difference with our video sharing section, is we primarily focus on clients which store data on the device
Privacy Guides, is a community project, we accept community contributions, which are then verified before being merged with the main repository.
We are now looking at translation of our content https://github.com/privacyguides/privacyguides.org/discussio... which is exciting because we feel there really many resources in languages other than English.
OpenPGP is a message standard that specifically covers the offline, end to end encryption case. So the contention that it bad at other cases isn't very interesting.
Forward secrecy can be implemented in the OpenPGP case in way compatible with regular usage, but no one bothers. Offline encryption can be made arbitrarily secure so that it is always better to spend the time and effort on preventing the compromise in the first place. Besides, no one wants to have to immediately delete all their emails after having read them. Forward secrecy is simply not relevant for offline applications.
It's an overly complicated protocol, https://latacora.micro.blog/2019/07/16/the-pgp-problem.html which has no place in an instant messenger protocol..
There are actually some XMPP clients which offer it as an option, which you should never use when you've got OMEMO, or (OTRv4). The double ratchet protocols olm, etc are better for this usecase.
There is also MLS https://en.wikipedia.org/wiki/Messaging_Layer_Security which is looking to become an IETF standard.
> Forward secrecy can be implemented in the OpenPGP case in way compatible with regular usage, but no one bothers. Offline encryption can be made arbitrarily secure so that it is always better to spend the time and effort on preventing the compromise in the first place. Besides, no one wants to have to immediately delete all their emails after having read them. Forward secrecy is simply not relevant for offline applications.
I was specifically talking about instant messengers, not email usecases. It's also why things like Deltachat are basically taking the worst parts of email encryption and mashing it into an instant messenger client.
* https://articles.59.ca/doku.php?id=pgpfan:tpp
I actually do PGP over XMPP these days. It is so simple that it ends up being quite reliable. So I consider it the superior protocol.
>I was specifically talking about instant messengers, not email usecases.
Forward secret PGP would be simple for an online application like instant messaging. You could just throw up a new public encryption key on the server before you delete the private key.
Deltachat also embodies some of the best parts of email encryption. Open federation based on the popular and well known SMTP standard. Encryption based on the popular and well known OpenPGP standard. Contrast with what happened with the Signal encryption protocol. OMEMO, Signal Messenger, Matrix are all entirely incompatible. Things are worse off now than they were before.
It also embodies all of the metadata associated with it, which is still not encrypted.
> Open federation based on the popular and well known SMTP standard
and inefficient for messaging protocols, attachments are literally base64 encoded, every message includes a heap of metadata.
For transient communication you're better off installing a purpose built client with a purpose built protocol rather than trying to butcher email to do it.
How is this worse than any system that depends on a server that routes messages? Like almost all of them...
>For transient communication you're better off installing a purpose built client with a purpose built protocol...
Yeah, the world definitely needs more "purpose built" protocols...
Not in the same way that email does. Email metadata is much more extensive than that of say Matrix.
If we look at metadata, often the subject isn't encrypted and ugly UX hacks then are made like https://tools.ietf.org/html/draft-autocrypt-lamps-protected-...
This replaces the subject with "...", however if I send that email to someone who doesn't support that every email I send is going to have the same subject, making it difficult for them to easily find the "correct" email from a group. Protonmail for example doesn't support encrypted subjects.
With Matrix for example the only real metadata is room id, and flow of events (what Matrix ID is in what room). You can have rooms which are centralized to a specific server and then that's not an issue.
It will be interesting to see where P2P functionality leads in the future. https://matrix.org/blog/2021/05/06/introducing-the-pinecone-... I think with any long-term identity, it's going to be trackable to some extent, so that is up to specific threat model, whether you get worried about that.
With Signal and Sealed Sender https://signal.org/blog/sealed-sender/ even less metadata is available, although this centralized model is not without downsides such as being operated by a single entity.
We discuss in quite some depth https://www.privacyguides.org/real-time-communication/
> Yeah, the world definitely needs more "purpose built" protocols...
With protocols like olm, you also have concept of different devices, device keys, which can be revoked, and shifted without having to ditch all your keys at once. Cross signing means new devices can be "trusted".
The “incompatibility” comes from the fact that the payloads within the encryption are utterly different. It’s nothing to do with the encryption; you’d see the same thing with PGP.
It feels as if their project was ill-defined and grew too quickly, and they're not really sure exactly what it's supposed to be yet.
Problem is they also serve to repeat bad/out of date practices.
I always feel people who put together these lists are in a competition to list as many products and cover as many areas as possible, without evaluation.
This is not just a simple list of software with summaries, and after looking at it more it's worse than I thought. And you're right about propagating bad/out of date advice being a problem.
> I always feel people who put together these lists are in a competition to list as many products and cover as many areas as possible, without evaluation.
Unfortunately this seems to be the quickest and easiest way to get the most attention. Proper curation takes lots of effort, and is hard to get noticed by people who don't know any better.
Where we notice this effect is in our subreddit /r/privacyguides and /r/privacy, particularly in regard to browser extensions.
Fortunately through re-nforcement from the Arkenfox, Librewolf and our project we're starting to turn the tide away from "install 100 privacy browser extensions", so I think that's a positive benefit.
> Unfortunately this seems to be the quickest and easiest way to get the most attention. Proper curation takes lots of effort, and is hard to get noticed by people who don't know any better.
Pretty much why we're about quality over quantity with privacyguides.org. People have often asked "why don't we have a section for "this" or "that".
Each section requires research, and not just parroting what someone else says.
I've followes the specs a little and it seems to be implemented in a cautious manner. But haven't seen it being mentioned anywhere on privacy focussing lists, and I haven't heard of any audit of their codebase/protocol specs.
Do you know by chance anyone currently auditing and/or describing threat models etc for it?
Briar is audited was audited https://briarproject.org/news/2017-beta-released-security-au...
It's a decent piece of software.
We list the Yubikey, as it is at the moment it's one of the better MFA products out there.
https://www.privacyguides.org/security/multi-factor-authenti...
The thing I've found great about Yubikeys is how easy it has been to onboard non-technical family members to using them.
That's one of the reasons I started using the word 'dignity' in place of saying 'privacy' without thinking more. In particular I've found the phrase "digital dignity" stands in more comfortably in some conversations with people who are jaded and cynical about privacy [1].
Privacy does not always equate to security nor mean that the user isn't abused in other ways (indeed many abusers leverage privacy or shame as a way to hide their abuse)
If you want to use Chromium based browsers it's probably the only browser that is:
- Cares about security, (not doing stupid shit like disabling CRLSets), they are proxied by Brave. See https://qua3k.github.io/ungoogled/
- Does try to do some anti-fingerprinting, while its not a strong as Firefox+Arkenfox, it's at least a step in the direction as opposed to other browsers which don't even attempt to do anything about it
- Its a resourced fork with timely security updates, don't use small browsers which lag behind.
- Their shields thing aren't bad, they have a script blocker (a bit like noscript) too you can enable, that isn't an addon.
Bromite is available on F-Droid, and unfortunately Vanadium is only available on GrapheneOS unless you build it yourself.
Vanadium doesn't really have any privacy features that people normally think of (anti-fp, adblocking etc), it's a series of security related patches https://github.com/GrapheneOS/Vanadium/tree/12.1/patches
Bromite does have some features like this https://github.com/bromite/bromite, but we've found in experience the adblocker, is not as comprehensive as uBO, particularly in harder blocking modes https://github.com/gorhill/uBlock/wiki/Blocking-mode:-medium...
That said for Android Firefox doesn't have the same process isolation like we see from chromium browsers.
I still wouldn't bother with Brave on mobile when you've got Bromite though.