4 ms·

This is a really interesting point. We deliberately built Element to help prove the spec and define its direction (including ensuring it has decent privacy prop

This is a really interesting point. We deliberately built Element to help prove the spec and define its direction (including ensuring it has decent privacy properties), to avoid all the failure modes where folks build a protocol without a real app or product in mind and end up with something which tried to be all things to all people and useful to none. While I’d have loved us to have infite manpower getting all the security features in from day 1, we had to bootstrap and we prioritised usable apps over optimising for a perfect spec. And judging by some of the rest of the thread, we didn’t so well even then; it would have been even worse otherwise.

kevincox 5y ago
I think it is helpful to have Element to test out the spec. I think the problem is that the "bar" for accepting features is too low for my taste. > While I’d have loved us to have infite manpower getting all the security features in from day 1, we had to bootstrap and we prioritised usable apps over optimising for a perfect spec. I get the decision. But it leaves a sour taste in my mouth that Matrix advertises itself as "secure" but almost any user is leaking sensitive information without knowing. I suspect that 95% of users would be surprised if you told them about the number of things that leak in E2EE rooms. Probably the better approach would have been to skip pushing E2EE as the default, and disable all insecure features in Element for E2EE rooms (or have an explicit opt-in). The marketing team would hate this approach but it least it is honest and safe.
- Arathorn 5y ago
  There isn’t a marketing team for Matrix, unless you count me & the dev advocacy team. I actually have another (big) blog post called Metadata And Matrix which attempts to enumerate the privacy properties we have today to try to educate everyone, and how we’re improving it in future - will post it shortly. Agreed it could be better, but if you’re on your own server you are in a pretty good place.
  - twicetwice 5y ago
    I want to voice strong agreement with kevincox. I use an encrypted Matrix room daily and had no idea that reactions, relations (does that mean that edits are in cleartext??), etc are completely unencrypted. I've read a little bit of the spec (though clearly not very much), I've written a bot, I've patched the Element desktop client, I've even been working with a JSON export of my message history and didn't notice—perhaps I should have, but my point is that it's not obvious at all, and users SHOULD be proactively made aware of what's encrypted and what's not. Sending things unencrypted that users have every reason to think are encrypted is extremely irresponsible. And I assumed, as I think is perfectly reasonable, that everything in an E2EE room is in fact end-to-end encrypted. I'm very disappointed to find out this way that it's not (and won't be for the foreseeable future), and I don't see any justification for failing to making users aware of that. All that said, I love Matrix, will continue to use it every day, and am hugely rooting for the success of the project. Thanks for all your hard work on it!
    - Arathorn 5y ago
      Is it really that surprising that the act of reacting to a message with an emoji isn't E2EE, given the server needs to count the number of reactions? One could encrypt the emoji itself, but it doesn't seem like a massively sensitive datapoint in its own right. (That said, we will encrypt them eventually, but it's just not very high priority given the fact it doesn't practically feel very high impact, relative to all the other things we could be doing to improve Matrix).
      - snvzz 5y ago
        It is. The expectation in an E2EE room is that everything that happens there is E2EE. Breaking this expectation is a massive red flag, particularly because Matrix is often chosen with this expectation at the core of the decision.
        jimmygrapes 5y ago
        Just chiming in as a plus one updoot etc. here. I understand the balance of complexity and resources needed to make essentially meaningless data encrypted, and I fall firmly on the side of "do it anyway". I can explain to users that things take longer because they're encrypted, I can't explain to them why they have general sentiment analysis derived from emojis used over time intercepted by <X> in a room they thought was secured.

kevincox 5y ago

I think it is helpful to have Element to test out the spec. I think the problem is that the "bar" for accepting features is too low for my taste. > While I’d have loved us to have infite manpower getting all the security features in from day 1, we had to bootstrap and we prioritised usable apps over optimising for a perfect spec. I get the decision. But it leaves a sour taste in my mouth that Matrix advertises itself as "secure" but almost any user is leaking sensitive information without knowing. I suspect that 95% of users would be surprised if you told them about the number of things that leak in E2EE rooms. Probably the better approach would have been to skip pushing E2EE as the default, and disable all insecure features in Element for E2EE rooms (or have an explicit opt-in). The marketing team would hate this approach but it least it is honest and safe.

Arathorn 5y ago
There isn’t a marketing team for Matrix, unless you count me & the dev advocacy team. I actually have another (big) blog post called Metadata And Matrix which attempts to enumerate the privacy properties we have today to try to educate everyone, and how we’re improving it in future - will post it shortly. Agreed it could be better, but if you’re on your own server you are in a pretty good place.
- twicetwice 5y ago
  I want to voice strong agreement with kevincox. I use an encrypted Matrix room daily and had no idea that reactions, relations (does that mean that edits are in cleartext??), etc are completely unencrypted. I've read a little bit of the spec (though clearly not very much), I've written a bot, I've patched the Element desktop client, I've even been working with a JSON export of my message history and didn't notice—perhaps I should have, but my point is that it's not obvious at all, and users SHOULD be proactively made aware of what's encrypted and what's not. Sending things unencrypted that users have every reason to think are encrypted is extremely irresponsible. And I assumed, as I think is perfectly reasonable, that everything in an E2EE room is in fact end-to-end encrypted. I'm very disappointed to find out this way that it's not (and won't be for the foreseeable future), and I don't see any justification for failing to making users aware of that. All that said, I love Matrix, will continue to use it every day, and am hugely rooting for the success of the project. Thanks for all your hard work on it!
  - Arathorn 5y ago
    Is it really that surprising that the act of reacting to a message with an emoji isn't E2EE, given the server needs to count the number of reactions? One could encrypt the emoji itself, but it doesn't seem like a massively sensitive datapoint in its own right. (That said, we will encrypt them eventually, but it's just not very high priority given the fact it doesn't practically feel very high impact, relative to all the other things we could be doing to improve Matrix).
    - snvzz 5y ago
      It is. The expectation in an E2EE room is that everything that happens there is E2EE. Breaking this expectation is a massive red flag, particularly because Matrix is often chosen with this expectation at the core of the decision.
      - jimmygrapes 5y ago
        Just chiming in as a plus one updoot etc. here. I understand the balance of complexity and resources needed to make essentially meaningless data encrypted, and I fall firmly on the side of "do it anyway". I can explain to users that things take longer because they're encrypted, I can't explain to them why they have general sentiment analysis derived from emojis used over time intercepted by <X> in a room they thought was secured.