Seems like a step up from "Covenant Eyes" with weirdo politicians sharing their porn habits with their children.

I know with standard setttings my isp see everything, but if i will use some encrypted dns what they will see exactly

Basically the same thing.

Encrypted DNS is not for privacy, it is for stopping someone from altering your queries basically, because normal DNS is not encrypted. Domains are exposed through other various methods we explain. Please see our website where we've gone to the effort to explain this https://www.privacyguides.org/en/advanced/dns-overview/ we have a flow chart that characterizes the above methods of obtaining the domains you're requesting.

Yes the article is FUD and sloppy. This is what Matthew Hodgson (Arathorn) had to say about it:

Talking of sloppiness, that hackea.org article is a huge steaming pile of FUD about Matrix.

For what it’s worth, the team who came up with Matrix was originally based in two separate startups: one in the UK doing VoIP, one in France doing mobile dev. Both got acquired by Amdocs in 2010, but we ended up forming an independent “incubated startup” first to build telco apps, and then we came up with the idea of Matrix in ~2013. We then built out Matrix until 2017 when Amdocs killed our funding, having run out of patience for what amounted to generous FOSS philanthropy.

We then set up New Vector (now Element) as an entirely independent UK/FR startup, and have received zero funding from Amdocs since. To be crystal clear: Amdocs has zero privileged influence or control over Matrix (or Element, for that matter), and has zero access to the Matrix servers we operate as Element. And besides - the whole point of Matrix is that you can and should run your own servers so you can pick who to trust, even if you don’t trust the project itself.

you’re referring is using XMPP without OMEMO

OMEMO encrypts text messages for VOIP you need DTLS-SRTP encryption or Jingle session encryption. OMEMO has no concept of cross signing, ie one device being trusted and therefore the others either if they do an authentication with each other. Device verification has to be done each session which is a massive pain.

warns you your message content is unencrypted if this is disabled

The point is that Matrix 1:1 calls are always encrypted and soon with MSC3401: Native Group VoIP Signalling 1:many VOIP calls will be as well. Having foot guns about what might be encrypted or not in a client isn't very private at all.

Also, XMPP has better (imo) and more numerous clients than Matrix on every platform except iOS and MacOS (No better XMPP client than Element on these platforms).

I've used Nheko and that's pretty good. Last time I checked the XMPP clients that existed had a lot of rough edges and feature inconsistency.

I definitely prefer an extensible protocol to a much heavier, metadata-leaking, less-feasible to self host solution like Matrix.

That is definitely your opinion, Matrix has shown to be very feasible in a commercial sense as there are many providers and commercial clients using it, french, german government etc. There are also quite a few clients using EMS. They claim: "Matrix is an open network for secure, decentralised communication, connecting 80M+ users over 80K+ deployments."

Which is probably a lot more than XMPP.

Matrix really can be quite lightweight enough that it will be entirely possible to run a homeserver locally in WASM which is what the Matrix P2P project is about. https://arewep2pyet.com/ has more details about that. It's also possible to have very light Matrix servers Breaking the 100bps barrier with Matrix, meshsim & coap-proxy. The reason that a lot of public Matrix servers are quite "heavy" is because they have many numbers of users, and activity. Synapse has also made huge gains in this regard to what it was originally, and we know that Dendrite uses a lot less resources (that I've tested privately).

With RFC 9420 aka Messaging Layer Security (MLS) it should be entirely possible to have large E2EE rooms without too much of a performance hit. Matrix is also working on MLS: A giant leap forwards for encryption with MLS. They have a site tracking that: https://arewemlsyet.com/

The point is a lot of testing and thought goes into these things.

metadata-leaking

You're pretending XMPP doesn't have metadata between servers, it certainly does it's really no more private than Matrix.

This is what Matthew Hodgson (Arathorn) - CEO of Element had to say about it in March 13, 2022:

Talking of sloppiness, that hackea.org article is a huge steaming pile of FUD about Matrix.

For what it’s worth, the team who came up with Matrix was originally based in two separate startups: one in the UK doing VoIP, one in France doing mobile dev. Both got acquired by Amdocs in 2010, but we ended up forming an independent “incubated startup” first to build telco apps, and then we came up with the idea of Matrix in ~2013. We then built out Matrix until 2017 when Amdocs killed our funding, having run out of patience for what amounted to generous FOSS philanthropy.

We then set up New Vector (now Element) as an entirely independent UK/FR startup, and have received zero funding from Amdocs since. To be crystal clear: Amdocs has zero privileged influence or control over Matrix (or Element, for that matter), and has zero access to the Matrix servers we operate as Element. And besides - the whole point of Matrix is that you can and should run your own servers so you can pick who to trust, even if you don’t trust the project itself.

I am sure that Tutanota does not use any custom encryption algorithm. It is clearly stated in the FAQ that they use RSA (with PFS) and AES to encrypt emails exchanged between Tutanota users. https://tutanota.com/encryption

These are only primitive algorithms, the actual implementation is custom and specific to Tutanota, which mean it will only work with Tutanota as nothing else will implement it.

There is no way to do key distribution outside of Tutanota's service.

That is the nature of any federated protocol.

E2EE works well enough within rooms and that is likely where private data is to be anyway. As long as you Matrix and assume that everyone can see your Matrix ID and room IDs you'll be okay.

XMPP isn't any better in that regard.

leaks more metadata than XMPP

XMPP is not a private protocol either. In a lot of cases data is not E2EE, there is no reference clients and there's a mess of standards that very few if any clients fully implement.

Generally we'd say no, not really, and certainly not with the highest security.

The whole point of a security key is that it is supposed to be impossible to extract the key material, that simply isn't going to be the case for a DIY solution. They have shields, and light sensors to prevent decapping/forensic inspection.

Recommend taking a look at this: https://duo.com/labs/research/microcontroller-firmware-recovery-using-invasive-analysis

They still disable CRLSets and have binaries built by "contributors" not in an automated fashion by the developer themselves.

Disabling CRLSets though is worrisome, and its binaries are built by potentially unknown third parties with compromised systems.

Too bad it is on Kiwi Farms, yikes

Yeah, I almost wasn't going to link it because of that, however, it is fairly tame compared to most of the garbage on there.

The info about One Guy Ltd and it's links to his previous company Viral Video Web Ltd was interesting though and the fact he's set up a bullshit "review" website (Erfahrungen) is amusing.

1. Pretty much Crowdin works very well, particularly with it's TM (Translation Memory) and specific terms.
2. We are currently mirroring there but there's no reason you couldn't use git-send-email to one of the team members if you need to really do that. Ideally, just use a VPN or Tor anyway, because you're probably going to need that anyway. Github is available in Iran nowadays https://github.blog/2021-01-05-advancing-developer-freedom-github-is-fully-available-in-iran/
3. Because they often lag behind in security https://www.phoronix.com/news/GNU-Linux-Libre-5.7-Released (for example this allowed the GPU to be used in browser fingerprint.
4. In a lot of cases the site is research, and words we've written based on our experience. There isn't much reason for derivatives to exist based on our content. If there were, those would be a complete re-write. We aim to have the site as accurate as possible, and want changes contributed back there to benefit everyone and be translated. That does promote centralization, but in this case that is a good thing.
5. Libreboot won't ever be recommended, basically because unless you want an ancient laptop from 8-10 years ago it's a non-starter.