4 ms·
one big difference between email and the systems that the author suggests is that email is a standard and a protocol, where the systems referenced by the author
by a-dub 5y ago
one big difference between email and the systems that the author suggests is that email is a standard and a protocol, where the systems referenced by the author are pretty much single implementation systems maintained by a single authority.
some of these authorities have all sorts of structure to prevent corruption. passionate people, nonprofit or open governance. however, they are still single points of failure, or targets, or whatever you'd like to call them.
it seems that after years of pain with poor effectiveness of specification or poor verification tools for implementations, it has become en vogue for modern cryptosystems to insist on tight centralized control of reference implementations to ensure correctness. (otherwise known as the apple computer model). while this does seem to work in terms of ensuring high quality and problem free implementations, it does open up the single point of failure issue.
i'd argue that email's replacement must retain email's greatest quality: it's an open specification, not a system or implementation owned or controlled by a single entity and that the true challenge in bringing it to fruition won't be clever protocol and cryptographic design (although these will be crucial) but also substantial advances in protocol definition and implementation verification such that any competent developer can implement compatible components and plug them in.
- SV_BubbleTime 5y agoI agree entirely. Now help me understand something… why have signal and telegram and everyone made proprietary formats and centralized implementations instead of an open email2.0 that they also support immediately? This isn’t my field, so maybe someone has?
- remirk 5y agoSignal says it's harder to innovate in a federated system. [1] [1] https://signal.org/blog/the-ecosystem-is-moving/ https://signal.org/blog/the-ecosystem-is-moving/
- tptacek 5y agoIt clearly is harder to innovate in a federated system. Look at what happened with Matrix, and how much time passed between them standardizing E2E encryption and getting E2E encryption universally deployed (I think that switch just flipped last year?). Not everything Moxie Marlinspike writes is correct, but he's been pretty well vindicated on that. Use whichever secure messenger you like, though.
- SV_BubbleTime 5y agoUnderstood, and that makes sense. But do I want innovation? Or do I want encrypted email 2.0? They didn’t want to make it, good to go there, but why hasn’t anyone else wanted to make it?
- rytor718 5y agoI missed this, very interesting read. He's not entirely wrong. But why are these protocols frozen? I've never developed one so I may just be ignorant of the challenges there, but if, for example, I wanted the XMPP protocol to be able to work with rich media, what's stopping me from updating said protocol to work with rich media instead of relying on optional extensions? In my mind, users of the protocol will receive the update (if they choose of course), thereby making the feature a default for the protocol that isn't reliant on extensions. I admit I don't fully understand why protocols are frozen in this way, even though I agree with the author that the ones we currently have are definitely frozen. Any insights appreciated!
- MattJ100 5y ago> But why are these protocols frozen? They're not "frozen". As mentioned in a sibling comment I wrote a blog post about this very topic - https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/ Your point about optional extensions vs a protocol update isn't really as clear-cut as people think it is. To add a non-optional change to an open protocol in a decentralized network would necessitate blocking people from the network when you roll it out. That's not going to make for a good communication network. The alternative is what XMPP does. The protocol evolves by adding new extensions, and deprecating old ones. Each extension generally has fallback considerations. For example when group/offline media sharing was added many years ago, it was designed such that clients implementing the extension could render the media. Older clients, or clients that can't render media (e.g. terminal clients) simply display a URL. The XMPP Standards Foundation annually publishes its "compliance suites", which (versioned by year) guides implementations on what they need to support. https://xmpp.org/about/compliance-suites.html https://xmpp.org/about/compliance-suites.html
- a-dub 5y agovery interesting. lots to think about!
- MattJ100 5y agoMany people, including myself, disagree with Moxie's stance towards decentralization. I wrote a blog post comparing Signal's approach to the approach taken by many decentralized networks: https://snikket.org/blog/products-vs-protocols/ https://snikket.org/blog/products-vs-protocols/ And others have written their own: - An Objection to "The Ecosystem is Moving": https://gultsch.de/objection.html https://gultsch.de/objection.html - "Have you considered the alternative?" https://homebrewserver.club/have-you-considered-the-alternative.html https://homebrewserver.club/have-you-considered-the-alternat... - "Re. The Ecosystem is Moving": https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-moving/ https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-mo... Decentralized networks can certainly move. They may not usually move as fast as a centralized one can, but that does not make reliance on a central entity a good alternative.
- cwyers 5y agoOkay, but Moxie has actually produced a secure and usable messaging system, based on his stance. Have any of the people who disagree with him gone ahead and produced something that proves their viewpoint?
- d110af5ccf 5y agoCynically, because they are companies trying to turn a profit. Also many (most?) of the complaints raised in the article will be an issue for any federated system. The article is arguing against end user control and decentralization. It just isn't upfront about it.
- sneak 5y agoSignal is a nonprofit.
- SV_BubbleTime 5y agoThat doesn’t mean they don’t make money, pay salaries, pay grants, accept grants, invest, etc. They are allowed operating reserves, pay taxes, etc. People seem to think non-profit means no money collected, that’s incorrect. It is also within Signal’s interest that the remain competitive and achieve market success.
- notriddle 5y ago> It is also within Signal’s interest that the remain competitive and achieve market success. What good is a communication protocol with nobody to talk to?
- hda2 5y agoOpenAI started as a nonprofit :)
- thayne 5y agoSignal is a non-profit. Signal also has a blog post on why they chose not to support federation: https://signal.org/blog/the-ecosystem-is-moving/ https://signal.org/blog/the-ecosystem-is-moving/ It basically boils down to being able to add features and change things without worrying about whether the federated servers keep up.
- R0b0t1 5y agoThey have, it's called mixmaster/mixminion. It hasn't seen much use since it was introduced.
- SV_BubbleTime 5y agoThat’s an anonymous remailer isn’t it? Is that a ground up replacement for email or is it an extension (bandaid)?
- R0b0t1 5y agoIf it actually enhances security why is it "just a bandaid?" Recreating everything for fun isn't productive.
- SV_BubbleTime 5y agoI was under the impression that the topic is “email will never be secure and must be replaced”.