How does E2EE work here? How can the user know their communication isn't being intercepted?
To track the identity of who you’re talking to we can do TOFU and/or normal out of band Matrix verification as per https://github.com/vector-im/hydrogen-web/issues/518 - but this isn’t yet exposed in Chatterbox. We’ll get it added, as without verification you obviously can’t spot a MITM.
Edit: sorry I should have clarified that I was answering your second question. As for the first question, the user still has to trust the business to a certain extent
This threat model just does not make sense.
This use case is more for the business, who knows that the chat is hosted by a 3rd party, but is reassured that the 3rd party wont have access to messages.
With e2ee you have to trust the client. But a client that is running as a website hosted by someone else can't be trusted as the host can modify it and you'd never known because browsers don't have a way to alert you when a site changed.
The only way this makes sense is if you (or your business) self-hosts.
This is one of the major benefits of having an open protocol like Matrix. The clients are separate from the servers. People with more resources and more expertise can host the servers, while regular users just need to download an open source client, and they can rest assured that the messages are secure.
* You may not want to trust the hosting entity for all of time. If you trust that E2E is deployed now, then you don't have to trust the future version of the host
* You may want additional protection against the host database being compromised. If you trust that E2E is deployed then a compromise of the host would not mean anything for your users privacy
From TFA:
>there’s no need for them to register or create an account just because it’s E2EE, and it still supports persistent messaging.
How does that work? Arathorn in a sibling comment says that there's out of band something, which I interpret to mean some verification process, but for the life of me I can't imagine what that process might be or how it might work without any sort of account... unless the client generates a unique a key per user session and coordinates the key exchange with a single host server behind the scenes to encrypt that session's data?
What am I missing?
I think this is targeted towards securing chat traffic from thrid-party hosting services accidentally leaking or passively spying on you. Think problems that arise from early HTTPS termination like the cloudflair's https leak.