Difference between revisions of "Sweet Lies"
Line 31: | Line 31: | ||
= Sweet Lies FAQ = |
= Sweet Lies FAQ = |
||
− | '''How long will this take?''' It is now November 2021, and I estimate the first test builds will be available by around the beginning of March 2022, with |
+ | '''How long will this take?''' It is now the end of November 2021, and I estimate the first test builds will be available by around the beginning of March 2022, with publicly visible progress well before that. There are a lot of details to figure out, ''including administrative details with NLnet.'' |
'''Signal is an old design. Why not just write a modern distributed chat system?''' Because that will take years to build and have verified, and people need secure chat now, sometimes for life-and-death reasons. In 5-10 years probably nobody will be using Signal, but today there really isn't a choice. |
'''Signal is an old design. Why not just write a modern distributed chat system?''' Because that will take years to build and have verified, and people need secure chat now, sometimes for life-and-death reasons. In 5-10 years probably nobody will be using Signal, but today there really isn't a choice. |
Revision as of 05:29, 26 November 2021
Sweet Lies is a small but vital modification of the Signal secure communications app. Signal is similar in function to WhatsApp and Telegram end-to-end communication systems, but unlike them is completely open source. NLnet has awarded funding to Sweet Lies. Signal is the best existing solution for private communication we have, and the team are quite rightly respected around the world.
The good news: Signal is the only personal messaging codebase which is all of:
- Validated by independent, academic, cybersecurity peer review
- Open Source
- Widely used, ported, accessible and accepted
- Mainstream - even the EU parliament insists on its use for internal communications
- Seemingly, so far, successfully resisting efforts of many authorities to break its security
The bad news: Signal also has some critically urgent problems:
- Signal is not reproducible. Reproducibility is a first basic requirement for security and therefore trust. This is a not a deliberate ploy on the part of the Signal team, they are simply very busy making a good app.
- Nobody can deploy a Signal server themselves (calling it something other than "Signal", of course).
- Signal is end-to-end and does not store user data except to forward when necessary. Nevertheless, inspection of the Signal server code shows that it uses six US-based closed source cloud services. Even though the data is safe, and even though many attacking organisations (eg the US FBI) have been frustrated that Signal does not keep data, this is still not ideal. These US services remain a significant opportunity for sidechannel attacks and traffic analysis.
- Signal no longer enables federation of user data, meaning interoperability is not testable and that the Signal servers are a single point of failure.
- Signal is not legal or suitable for use for sensitive purposes in Europe, because of the US cloud dependencies and because of the lack of reproducibility. Something as vital as this (eg recommended for use by the EU parliament) needs to fully comply with EU privacy regulations, for the benefit of all.
Introducing Sweet Lies
The Sweet Lies scope is to create a reproducible build of Signal client and server code, and then uses this to set up a Signal network that has federation enabled for connecting to other, independent Signal server instances. The outcomes will be a recipe for creating a Signal-identical network, and a working proof that this recipe works for some
Sweet Lies relies on the production Not Forking tool developed for LumoSQL.
It seems very likely that when we can turn on a clone Signal network, that organisations of all kinds would very much like to have that same system themselves so they can be assured they have their own private Signal. This is a commercial opportunity.
(Why the name "Sweet Lies"? Several other names proved unusable, and the Fleetwood Mac song is about keeping secrets safe!)
Sweet Lies FAQ
How long will this take? It is now the end of November 2021, and I estimate the first test builds will be available by around the beginning of March 2022, with publicly visible progress well before that. There are a lot of details to figure out, including administrative details with NLnet.
Signal is an old design. Why not just write a modern distributed chat system? Because that will take years to build and have verified, and people need secure chat now, sometimes for life-and-death reasons. In 5-10 years probably nobody will be using Signal, but today there really isn't a choice.
If Signal has all these problems, why not do a hard fork and fix them? Because the Signal team are doing a really good job, and I would not want to try to duplicate what they do without having a large team with plenty of funding. Especially if it was just to try to replicate all the best parts of Signal which we could have for free already!
What about Matrix? They are open source and they just got lots of funding! The Matrix team are lovely and I wish them every success. I have found their solutions to be unstable at even quite modest scale and a very large codebase for the functionality it delivers. A lot of projects would love to use Matrix instead of, say, libera.chat irc - but they can't because Matrix still has implementation issues. And as for independent security review, well there's a lot of attack surface on Matrix. I'm very open to hear updates and corrections on this.