[deleted] But wait. In the case of this extension where it's possible that there won't be a third party who would host the keys, but you, you DO have access to the keys. I realize it's not really end-to-end encrypted since you could practically decrypt stuff yourself, but you'd have to decrypt stuff then upon request because you can, right?
Yalfoosh this is also untrue. The point of this is encryption at rest and in transit. You are duly bound under GDPR regulation to protect both at rest and in transit data. You do not have to completely encrypt all data held about the user (but must be able to demonstrate applicable controls) and you must be able to present all of it in a subject access request if this is required. In most cases, what you would present as part of that would be plain text and not encrypted.
I think you've misunderstood the role of encryption when used alongside a regulatory control like GDPR.
Yalfoosh potentially true, but see my next post
[deleted] My thing though is that if the keys are generated on the client and stored by the client only and the provider has no way to read the messages how does that affect the GDRP data request process? My guess would be that the provider can just say that they can't access it?
tankerkiller125 that's correct. If they do not hold the keys to decrypt, then it's not possible. AWS for example of one such vendor who takes this approach. You lose the key, you lost access to your machines.
Taking this route allows the host to exonerate themselves in the sense that they cannot be considered in scope when they possess no means of decrypting the content and can demonstrate that as part of their controls. This world also be covered by SOC 2
Yalfoosh To clarify, it's a combination of Article 12 and 15. 15 gives users the right to ask for their data. 12 forces you to provide that data,
With this kind of e2e isn't data then stored only at the client level and thus you as a forum owner are not the data processor of this PII and user data to begin with?
PS. I have no idea whether data storage was previously discussed 
luceos With this kind of e2e isn't data then stored only at the client level and thus you as a forum owner are not the data processor of this PII and user data to begin with?
Yes. You can't be a custodian of data you do not control
Just to throw this in here, this is how political the GDPR can be as soon as you make personalised data from a home environment and then make it available to a wider audience via social media without consent
BBC News - Grandmother ordered to delete Facebook photos under GDPR
https://www.bbc.co.uk/news/technology-52758787
Might help to chime in on some of the specifics of the encryption implementation.
At the current state, admins will be completely unable to decrypt messages. The private keys for each user will be stored on the server but will be AES-256-GCM encrypted with the user's password ran through PBKDF2 with 12800 iterations to stretch it to 256 bits. The actual keys to decrypt messages are double ratchet keys, meaning they change after each use. If a hacker or admin managed to get ahold of one of these keys, they'd only be able to decrypt 1 message.
Double ratchet creates a problem with reading old messages however. Once a message is read, it is simply encrypted with that same stretched password. If a user loses access to their password, he will lose access to previous messages as well.
Any admin of Flarum or any other website could conceivably steal any of their user's passwords by using bad JS code. This could be mitigated in a few ways but makes the user experience significantly worse (having to export and manually keep track of keys).
JS is at the moment is an inherently insecure programming language, I am taking as many steps as possible in the extension to prevent tampering by any party (including the admin) and I will make these steps clear in the final version. But once the code leaves my computer there isn't a lot I can do to JS to secure it from a bad admin.
Kyrne there's a couple of questions that arise from this methodology. JS isn't secure enough to guarantee maximum protection possible without the risk of tamper via inject and this creates an immediate security issue which on the face of it is likely insurmountable.
If you consider how WordPress handles this from a plugin perspective, it is not encrypted. My question here would be why we need to encrypt messages in the first place in a forum. Based on the above, there should be an option to enable or disable depending on your preference. The messages are still private, but not encrypted and controlled by permissions instead.
[deleted] the JS code of the ext is verified using Subresource integrity which is a feature in JS. This means that as long as you are using https, the implementation is secure, no one but the site admin can tamper with the js code.
It's important to think about how apple could totally read your iMessages if they want, they just need to get your password which again is very possible.
The only way in the world to have 100% secure true end to end encryption is decentralized peer to peer messaging (the platform doesn't have control of the client). This is something no popular encrypted messaging service can provide
Kyrne that's correct of course in the sense of decentralised messaging, but what about the ability to disable or enable the encryption ? Requesting users to control their own keys is asking for it.
