[zimbatm]

If browsers are able to deprecate old encryption layers I don't see a reason why matrix client wouldn't be able to do the same. And as with browsers, if the clients or servers don't get upgraded then at some point they will stop working.

[meredydd]

That is only possible at all because web browsers are an oligopoly. There are only four organisations whose opinions matter, so they can coordinate to make breaking changes. (Even so, SHA1 deprecation is happening 1000x slower than, say, Whatsapp's rollout of E2E encryption.)

This level of oligopoly would not be tolerable to those who want to federate Signal-like apps. The whole point is to make it practical to use a small operator that's not such an easy target for one government's intervention (eg an NSL). But that ecosystem looks much more like email than web browsing - diverse, but fragmented, and impossible to upgrade in this way.

[Arathorn]

In the end it's a governance problem. If you create an ecosystem which sets a precedent of taking security seriously and thoroughly excommunicating insecure clients, netsplitting them out of the mainstream, then I think you'd see a lot more interest in client vendors and users routing around obsolescence and upgrading to whatever the current best practices are. This is particularly nice if the protocol is designed to let you enforce this, by ratcheting up to new versions.

Email never had this, and it shows. SHA-1 in HTTPS is a kinda intermediary example; browser and server vendors have been petrified to break legacy systems and generally not accorded that much priority to security updates. In Matrix, we hope to avoid this by setting a precedent that if Olm/Megolm is found broken tomorrow, we'd work with the major client authors to upgrade them, patching their clients ourselves if we have to, or providing a localhost shim or whatever, and then take the biggest community anchor points (e.g. #matrix:matrix.org) and throw the switch to the new protocol, and make it abundantly clear that folks on old clients have been left out in the cold for security reasons and need to get upgraded immediately. If you're a big enterprise with a private deployment who doesn't want to upgrade rapidly, that's fine. But the societal pressure will enormously be to get with the program and upgrade. Let's see how well that works though - we haven't really had to make any backwards incompatible changes yet since we started in Sep 2014.

(p.s. hi! :D)

[vertex-four]

A reasonable upgrade path is to do "room versioning". Each server would have a maximum supported room version, and publish it to each room they participate in, and every room has a version. When every server in the room agrees on a new version, they can publish a message to update the room version, and start talking over the new protocol. Older servers then can't join the room unless they agree to the room's new protocol.

Clients can then warn when they're in rooms with older versions than the latest supported, and since nobody wants the people they're talking to to receive scary warnings about insecurity, they'll upgrade.

And, of course, we can do similar with client versioning.

[x0x0]

This is remarkably contrary to how people actually use software. What people see is "click this button to make annoying red flashing shit stop so I can do what I want to do".

ala http://i.imgur.com/H0uVqFe.jpg

[vertex-four]

There's a reason web browsers just don't allow users to easily get past the annoying pages when there is a chance they're being attacked. I see no reason that Matrix clients would be required to allow users to break security without having a persistent banner saying "this room is insecure".

[x0x0]

Which they will ignore.

[vertex-four]

Cool. If they ignore the great big banner which says "do not enter any personal info, bank info, etc etc into this window" and they're attacked, obviously they didn't care much. In the meantime, people who actually understand security can make a reasonable decision.