E2EE in the browser is a bad idea, this blog post explains why. It’s simply not doable properly without significantly reducing the security of the encryption.
That blog post is not about Element and doesn’t include any of the ways Element stores data and sets up encryption. Basically they’re just saying ‘there’s no sane defaults and websites want to spy on you’, which I totally agree to, but which still misses the point. It is doable, it’s just not done well. To just send everything in plaintext is definitely not the solution here.
there’s no sane default and websites want to spy on you
If you’re considering E2EE you’re already considering that the server cannot be trusted (AKA it wants to spy on you).
It’s not about defaults, it’s about the fact that you’re doing crypto to protect yourself from the server, using code that the server just sent you.
This is the key point of the post:
Where installation of native code is increasingly restrained through the use of cryptographic signatures and software update systems which check multiple digital signatures to prevent compromise (not to mention the browser extension ecosystems which provide similar features), the web itself just grabs and implicitly trusts whatever files it happens to find on a given server at a given time.
It is doable, it’s just not done well. To just send everything in plaintext is definitely not the solution here.
If you’re serious about security, the only good way to do it is to not do it at all. It really pisses me off that even password manager don’t care.
There are still many issues with that. This stackoverflow discussion shows that it is not really possible to do. Some of the points are irrelevant, but the general takeway is that local storage, caches and all are not designed for security but for performance.
The thing is that the browser is absolutely not designed for this kinds of uses.
This post specifically says that browser crypto can be great to protect the interest of the website owner… well if you self-host your own Element or e2ee encrypted xmpp webclient you are the owner of the website.
The entire argument against javascript and webapps is always serverly distorted by all sort of false assumptions and compared to random binary only apps downloaded and run on MS Windows, I would take a modern browser and webapp in most cases.
if you self-host your own Element or e2ee encrypted xmpp webclient you are the owner of the website
That’s 0.01% of the general population, and even here, I guess very few people self-host their email or Matrix or XMPP. And it still doesn’t protect you against someone breaking the TLS connection between you and your server. This is a serious security concern, there have been multiple cases of certificate authorities issuing bad certificates.
The entire argument against javascript and webapps is always serverly distorted by all sort of false assumptions and compared to random binary only apps downloaded and run on MS Windows, I would take a modern browser and webapp in most cases
I mostly agree, but because proprietary, windows only apps are not generally designed with security as the number 1 concern. For FLOSS apps that do highly value security (like Matrix), this is not an acceptable compromise to me. Signal doesn’t have a web client for this exact reason. As I said in another comment, even password managers don’t care about this issue, which is really disappointing.
I guess very few people self-host their email or Matrix or XMPP.
You don’t need to self host email, Matrix or XMPP to use E2EE. I meant self hosting the web clients.
And it still doesn’t protect you against someone breaking the TLS connection between you and your server.
HSTS, Certificate Pinning, …
Every communication method suffers from this, it’s not exclusive to web-based communication.
proprietary, windows only apps are not generally designed with security as the number 1 concern
Yeah, Open Source software down to the OS itself is important for security. But even then, who audits their own software? It’s probably 0.01% of the 0.01% of the general population you mentioned.
You don’t need to self host email, Matrix or XMPP to use E2EE. I meant self hosting the web clients.
Nobody does that
HSTS, Certificate Pinning, …
HSTS is great but doesn’t protect you against maliciously issued certificates, and Certificate pinning is deprecated on the Web.
Yeah, Open Source software down to the OS itself is important for security. But even then, who audits their own software? It’s probably 0.01% of the 0.01% of the general population you mentioned.
That’s why you stick to software under high scrutiny and highly visible for security sensible stuff, and avoid using software with a broken security model for sensible stuff.
It’s much less than perfect.
E2EE in the browser is a bad idea, this blog post explains why. It’s simply not doable properly without significantly reducing the security of the encryption.
That blog post is not about Element and doesn’t include any of the ways Element stores data and sets up encryption. Basically they’re just saying ‘there’s no sane defaults and websites want to spy on you’, which I totally agree to, but which still misses the point. It is doable, it’s just not done well. To just send everything in plaintext is definitely not the solution here.
If you’re considering E2EE you’re already considering that the server cannot be trusted (AKA it wants to spy on you).
It’s not about defaults, it’s about the fact that you’re doing crypto to protect yourself from the server, using code that the server just sent you.
This is the key point of the post:
If you’re serious about security, the only good way to do it is to not do it at all. It really pisses me off that even password manager don’t care.
By “not doing it at all” I mean redirect people towards full blown apps that can do proper crypto.
Ah, yes, makes sense. Solutions to this may be to use client applications, local storage in browsers or checksumming.
There are still many issues with that. This stackoverflow discussion shows that it is not really possible to do. Some of the points are irrelevant, but the general takeway is that local storage, caches and all are not designed for security but for performance.
The thing is that the browser is absolutely not designed for this kinds of uses.
This post specifically says that browser crypto can be great to protect the interest of the website owner… well if you self-host your own Element or e2ee encrypted xmpp webclient you are the owner of the website.
The entire argument against javascript and webapps is always serverly distorted by all sort of false assumptions and compared to random binary only apps downloaded and run on MS Windows, I would take a modern browser and webapp in most cases.
That’s 0.01% of the general population, and even here, I guess very few people self-host their email or Matrix or XMPP. And it still doesn’t protect you against someone breaking the TLS connection between you and your server. This is a serious security concern, there have been multiple cases of certificate authorities issuing bad certificates.
I mostly agree, but because proprietary, windows only apps are not generally designed with security as the number 1 concern. For FLOSS apps that do highly value security (like Matrix), this is not an acceptable compromise to me. Signal doesn’t have a web client for this exact reason. As I said in another comment, even password managers don’t care about this issue, which is really disappointing.
You don’t need to self host email, Matrix or XMPP to use E2EE. I meant self hosting the web clients.
HSTS, Certificate Pinning, …
Every communication method suffers from this, it’s not exclusive to web-based communication.
Yeah, Open Source software down to the OS itself is important for security. But even then, who audits their own software? It’s probably 0.01% of the 0.01% of the general population you mentioned.
Nobody does that
HSTS is great but doesn’t protect you against maliciously issued certificates, and Certificate pinning is deprecated on the Web.
That’s why you stick to software under high scrutiny and highly visible for security sensible stuff, and avoid using software with a broken security model for sensible stuff.
So, like Element? scnr
More like Signal