I appreciate that soatok sees the problems with Signal-style centralized control over the infrastructure and employment of the one legitimate app that can connect to a E2EE chat network, and wants to try to solve through other means the problem of ensuring that everyone is using maximally-correct cryptographic protocols that the centralized-control solution does provide.
Cryptographic alacrity as described in this post seems like fundamentally a call for a certain type of deprecation behavior on the part of library maintainers - dropping the ability to read old protocol versions after (roughly) 2 years. This means that everyone using a regularly-updated client will no longer be able to read messages sent by non-up-to-date clients after that time. And what this will look like in practice for end users of regularly-updated clients is that, after one such regular update, they suddenly find that they can’t read new messages sent by random other users (the users who are still on clients that are at least two years out of date).
This will be annoying behavior to those users, who probably don’t understand the cryptographic theory behind that decision (and even the ones who do). So there will be some pressure from those users to add back the ability to read old protocol messages (perhaps with a visible “out of date encryption protocol” warning in the UI of the app). If maintainers implement this, they’ll be working around the wishes of the underlying cryptographic library authors, and working against the game theory that incentivizes the maintainers of clients to update their crypto libs at least once every two years, and incentivizes users to stop using clients that are that far out of date. But clients that are that far out-of-date will also be unable to read messages sent by new clients, so that should also be a powerful incentive to upgrade even if reading old protocol versions is never actually removed.
I would definitely want to read the comments of people who think this is a bad idea (or a good idea with an important flaw), but this seems pretty reasonable to me as a non-cryptographer who just wants to use E2EE software in as secure a way as is feasible.
(Out of topic) Ooh now I understand why Alacritty (the terminal emulator) is named like that, as a non native speaker I had no idea “alacrity” was a real English word
I use it occasionally (once or twice a year, at a guess?), and have encountered it in the wild enough that I understood the reference when I first encountered Alacritty. It’s very real, but certainly niche.
Nice idea to “nudge the ecosystem”. I think developers of applications in such a scenario would be smart to write a clear guide for instructions on how to publish a version update that only increases the protocol version. Maybe even male it easy to supply vis config rather than in code (to prevent other non-crypto updates to break someone’s installation that has suddenly become outdated).
Another nice “carrot” could be a bot, a service, a tool that lives on the fediverse which is a bit stricter or some other social mechanism that encourages people to upgrade more eagerly (yearly sticker packs? Bots that will only comply to people who have upgraded to the current year before end of H1, etc).
I appreciate that soatok sees the problems with Signal-style centralized control over the infrastructure and employment of the one legitimate app that can connect to a E2EE chat network, and wants to try to solve through other means the problem of ensuring that everyone is using maximally-correct cryptographic protocols that the centralized-control solution does provide.
Cryptographic alacrity as described in this post seems like fundamentally a call for a certain type of deprecation behavior on the part of library maintainers - dropping the ability to read old protocol versions after (roughly) 2 years. This means that everyone using a regularly-updated client will no longer be able to read messages sent by non-up-to-date clients after that time. And what this will look like in practice for end users of regularly-updated clients is that, after one such regular update, they suddenly find that they can’t read new messages sent by random other users (the users who are still on clients that are at least two years out of date).
This will be annoying behavior to those users, who probably don’t understand the cryptographic theory behind that decision (and even the ones who do). So there will be some pressure from those users to add back the ability to read old protocol messages (perhaps with a visible “out of date encryption protocol” warning in the UI of the app). If maintainers implement this, they’ll be working around the wishes of the underlying cryptographic library authors, and working against the game theory that incentivizes the maintainers of clients to update their crypto libs at least once every two years, and incentivizes users to stop using clients that are that far out of date. But clients that are that far out-of-date will also be unable to read messages sent by new clients, so that should also be a powerful incentive to upgrade even if reading old protocol versions is never actually removed.
I would definitely want to read the comments of people who think this is a bad idea (or a good idea with an important flaw), but this seems pretty reasonable to me as a non-cryptographer who just wants to use E2EE software in as secure a way as is feasible.
(Out of topic) Ooh now I understand why Alacritty (the terminal emulator) is named like that, as a non native speaker I had no idea “alacrity” was a real English word
As a native English speaker, I can’t remember ever having heard it used, so it’s certainly not a common word.
I see it appears in Shakespeare four times, and I see it popping up in some newspaper articles that are modern, so it does seem to be a real word.
I use it occasionally (once or twice a year, at a guess?), and have encountered it in the wild enough that I understood the reference when I first encountered Alacritty. It’s very real, but certainly niche.
From Latin alacritatem, “liveliness, ardor, eagerness”. But yeah, it’s not a particularly common English word.
Y’all need to read more fiction set in the Napoleonic wars, the Royal Navy loved that name
https://en.wikipedia.org/wiki/HMS_Alacrity
Nice idea to “nudge the ecosystem”. I think developers of applications in such a scenario would be smart to write a clear guide for instructions on how to publish a version update that only increases the protocol version. Maybe even male it easy to supply vis config rather than in code (to prevent other non-crypto updates to break someone’s installation that has suddenly become outdated).
Another nice “carrot” could be a bot, a service, a tool that lives on the fediverse which is a bit stricter or some other social mechanism that encourages people to upgrade more eagerly (yearly sticker packs? Bots that will only comply to people who have upgraded to the current year before end of H1, etc).