I outlined a proposal for what they can do in the article.
In reality even if some people checked it'd make no difference. Networks are very sticky. When WhatsApp broke the encryption by allowing Facebook to detect forwarded messages, there was no uproar or sudden loss of trust. There was no mass migration away from WhatsApp. One day there was privacy. The next there was less, because having made its fortune on the back of viral sharing in social networks Facebook decided that maybe there was a little bit too much social going on and not enough hierarchy. And there's no possible fix, beyond "convince everyone not to use WhatsApp" which isn't going to happen anytime soon.
That's why I suggested a globally distributed group of auditors creating threshold signatures. It should be backwards compatible with the app stores because the resulting signatures are/can be indistinguishable from a regular signature. I have a Shoup RSA implementation lying around in my mail archive somewhere.
Anyway, encryption is about meeting social goals, not merely doing maths for the sake of it. There's no way to meet the underlying social goals here without decentralization - the fact that this is hard is irrelevant (even though I fully agree with Moxie on the problems around iteration speed etc).
> When WhatsApp broke the encryption by allowing Facebook to detect forwarded messages, there was no uproar or sudden loss of trust. There was no mass migration away from WhatsApp.
Well, you’re giving a not so great example there.
I don’t know anyone that uses WhatsApp because of their encryption system or privacy claims. Whereas I also don’t know anyone who would keep using signal if not for their encryption and privacy claims.
In every metric I can perceive signal is just playing catch-up with WhatsApp or telegram features. The only winning feature is privacy and encryption. So, your argument that:
> In reality even if some people checked it'd make no difference
Makes no sense, if one person could break the trust on signal, it would be absolutely dead. No one would keep using a poor substitute with barely any user compared to the mainstream chat services if not for privacy and trust.
The primary reason Whatsapp had to change the forwarding was because of the social impact of forwarding in some nations that lead to social unrest and deaths. So while there was a loss of privacy, the alternative was to remove the offer of the application itself in its entirety.
> So while there was a loss of privacy, the alternative was to remove the offer of the application itself in its entirety.
OP's point is that the change in forwarding was practically equivalent to (partially) defeating the encryption.
I think the argument is that, previous to this Whatsapp forward counter rollout, one would assume significant hits to credibility would block a company/org rolling out such a thing in a client. And that hit apparently didn't happen.
> In reality even if some people checked it'd make no difference. Networks are very sticky. When WhatsApp broke the encryption by allowing Facebook to detect forwarded messages, there was no uproar or sudden loss of trust. There was no mass migration away from WhatsApp. One day there was privacy. The next there was less, because having made its fortune on the back of viral sharing in social networks Facebook decided that maybe there was a little bit too much social going on and not enough hierarchy. And there's no possible fix, beyond "convince everyone not to use WhatsApp" which isn't going to happen anytime soon.
This seems to miss two things.
First, "networks are very sticky" is the reason Signal uses telephone numbers as identifiers. Your network is not tied to Signal, or even to your contacts having smartphones that can run apps of any kind.
Second, the target markets for Signal and WhatsApp are quite different. WhatsApp users more often than not don't care about privacy. They care that everyone they want to talk to, including possibly critical government services in many countries, requires them to use WhatsApp. So if WhatsApp stops encrypting entirely, I'm not sure very many users care. Signal is much more likely to be used by people who actually care about privacy and security and is much more likely to be abandoned if it breaks the promise of maintaining those things. It's even designed to be easy to abandon, whereas WhatsApp very much is not. Leave WhatsApp and there are a whole lot of people and services you just can't talk to any more.
Signal (with Google / Apple cooperation) can potentially ship modified backdoored versions to specific targeted users, while that one geek that verifies every Signal build still gets a clean version.
This is not a game you can win with centralised app stores and app architecture that relies on push notifications.
This is true even in a decentralised world - even if the protocol can be guaranteed to be secure, you could still push a modified binary to an individual.
Not if you build the binary yourself. It is perfectly doable in PC world, where you can run background processes and such, but much harder to do in current mobile world, where both iOS and Android restrict background processes (Android to the lesser degree, but it is going to the same place as iOS), and force apps to rely on push notifications.
No, mjg59 is right - the operating system is a root of trust. Microsoft could push a Windows update that patches a messenger app in place for example. I probably shouldn't have brought up the "knowing what your peer is running" problem as it just confuses things.
There is plenty of progress to be made here without getting into the next layer of how do you trust your OS. Android is at any rate in a decent place because so many users don't get their OS bits from Google but rather, an intermediary, and it's very easy to change those intermediaries (it means buying a new phone but people do that all the time anyway).
Reproducible builds and audits are all very theoretical today. Reproducible builds on their own aren't actually useful because you're just comparing hashes: someone has to have actually read the source code, understood it, documented what it does or compared it to some natural language description, and they have to keep up with all the code changes, and they have to convince other people to trust their judgement. It's a lot of work and we don't have any companies that do this sort of thing today. The industry needs a network of auditing firms that specialize in this but it's a chicken-and-egg problem: there's no point creating such a firm when their outputs are so hard to use, and there's no point making their outputs easier to use when there are no auditors who would create them.
With respect to reproducible builds, they're pretty extensively used in engineering but have you considered that the reason they aren't more widely used outside of the industry is that most people simply don't care? I don't think that it's that the outputs are hard to use - it's that the vast majority of people installing and running software on their devices are perfectly fine with trusting the existing distribution infrastructure.
By "outputs" I mean "understandable and meaningful trust assertions" here, not actual binaries.
As for don't care, sure, but I guess you can make that argument for almost anything security or privacy related. Do most people care if an app or website uses SSL? Nope. They probably can't even tell. Sometimes it's just up to the people building the infrastructure to plan ahead a bit, see what problems can arise and take countermeasures.
I think it's much easier to make progress on audited builds than e.g. PGP style end-to-end encryption. Audited builds and remote attestations are the sort of thing that can be done behind the scenes, they don't inconvenience end users. People who care can double-check what the auditors are saying, and "people who care" might include journalists, politicians and other people with powerful megaphones who can affect change.
Plus it doesn't require a big breakthrough in tech. It does require Facebook (and Apple etc) to accept that just asserting their products are encrypted isn't really achieving anything, and for some engineers to say "OK, let's find a few foreign companies to cross-sign with us". It might require some changes in the app stores. I see a post elsewhere claiming that Google is phasing out the model in which developers sign their own APKs, which is a pity and a retrograde step. But if the right people agree with these arguments, all those problems are solvable.
There are many sources to get Android OS, but they all share one and the same Google Play. So this is the most logical piece of infrastructure to ship you tampered apps, on any Android device with Google services.
You can, but you won't be able to receive push notifications with it - to send push notifications to your app Signal will need your developer keys, or relay push notifications via your server. And I don't think Signal can relay push notifications.
Telegram, actually, can send push notifications to third-party clients, but requires uploading developer keys to them.
I think it is also not a game you can win (as in world wide usage) if you need users to build their own apps. The majority of users will not do that no matter how many tutorials one can write.
well, this is something that can be somewhat mitigated by giving users a meaningful choice of software repositories. Like, f-droid maintainers are trusted not to tamper apps because of their reputation. However, this would also require making third-party repositories ("app stores" is the modern fancy term) to have the same system privileges as Google Play / Apple Appstore have - and by this I mean giving apps access to third party push notifications services.
The exact same argument can be made for the centralized services that Ethereum relies on. If Infura would serve incorrect or censored data, it only takes _one_ person to find out and the trust we have in them is also lost forever.
There is no fundamental difference between the trust placed in relaying services like Infura, and the trust placed in software supplier like Signal. Both companies/services are able to cheat or betray that trust in a way that regular users will not easily notice, but both of them are fully auditable by technical users. Since their whole business model relies on being a trustworthy service provider, it makes no sense for either of them to attempt to cheat, because they risk their entire reputation.
- It take one person to notice that builds don't match or that something fishy is happening for the trust on Signal to be lost forever.
- Someone for whom the integrity is critical can do the check / compile themself
- I don't know if this has happened yet, but the way Signal is built and distributed allows a community of "checkers" to exist.
What can Signal do to improve this aspect?