Element web-client also phones home
It doesn't send metadata about your use. There is a version check though.
Element web-client also phones home
It doesn't send metadata about your use. There is a version check though.
Yes, but Matrix leaks way more metadata to other servers
FUD, Matrix doesn't leak any more data than XMPP in that regard. Admins of either service can know what rooms you're in and information about events such as time they were sent.
XMPP isn't any better in this regard.
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.
Session has no server so that’s what I’d recommend if you have the option.
Closed rooms in session are limited to 100 people iirc. You can have Matrix rooms with any number of users.
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.
Probably another point is that the encryption for Matrix/Element has undergone multiple audits, one in 2016 and another one of their newer rust library. Whereas telegram just has not. There was this also a not too long ago. MTProto is also used nowhere else, whereas a lot of encryption has been influenced by the Double Ratchet which is well understood.
The other thing worth noting is that Matrix is the foundation for other products which many governments use for secure communications.
I certainly think so.
Even Windows or Chrome OS, provides quite a bit of "control" it's just that a lot of it is "opt out". Google does, for example record what YouTube videos you look at against a logged in account by default. Windows does have targeted advertising enabled by default.
I think privacy is really more about what you do on such platforms. If you use products (sites) that clearly have bad policies in regard to privacy then no OS is going to provide really all that much improvement.
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
Stopped reading at “storing my passwords on a db”. Even if you encrypt the data, is it not just plain better to use a generative algorithm for passwords instead that needs no cloud?
There are quite a few reasons why we don't recommend deterministic password managers and I have been meaning to write an article about it. There is a summary and further discussion in that thread.
Third party blog article which is still relevant https://tonyarcieri.com/4-fatal-flaws-in-deterministic-password-managers
I disagree, the whole usecase for decentraleyes (although i’d recommend localcdn instead as it supports a lot more frameworks), if for users not using a vpn, in which case you’d be fingerprintable via your ip address anyways, what localcdn achieves is having privacy from third parties, as opposed to the website itself.
That is not how it works. It modifies your fingerprint because its no longer requesting certain resources. Even one of the Tor developers points that out and it's why it's mentioned on https://github.com/arkenfox/user.js/wiki/4.1-Extensions#-dont-bother
It's described in the documentation for uBO https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#removeparam
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.