Knowing that your client isn’t compromised is pointless if you friend can’t/won’t do verification on their end.
Even if you could verify Signal, what about the OS being compromised, the phone being lost or a shoulder surfer reading the message?
Even if I tell a friend a secret over dinner I can't 100% verify that they are not going to tell someone else. So some degree of trust in the other party is required.
If you can't trust the person to take the technical steps needed to secure the information, why do you trust them to not just share your secret the old fashioned way?
A better way to verify this is latest Signal build in F-Droid? Last time I checked it is behind quit few version. If Signal can satisfy the F-Droid build check to be open and free, then it is legit. Most people don't have time to go through the git commit to verify the build.
They do offer an apk on their website though.
Being open/free is to allow people to have any version they chose. I've pushed both in App Store and Google Play Store, if the software is truly free/open it shouldn't be hard to publish it on F-Droid. The problem is when there are mixxed proprietary code in the project then F-Droid tend to reject it.
But that argument would make for a convenient smokescreen if they were.
Actually, for both the commercial app stores - you cannot. Google requires app bundles where they package different APK for devices and sign it using their keys for new apps from 2021, August.
Source: I have been developing on Android since Android 1.0. Also see https://stackoverflow.com/questions/68710048/no-opt-out-opti...
Why blindly trust them if you can inspect the client, like you easily can with Signal? It's all about how you choose to update your client and which due diligence you want to apply, and for this a decentralized system doesn't help.
The Signal server implementation is mostly open-source, and some users managed to run their own instance.
> you wouldn't know if they actually run that code without modifications
That's the point of SGX, but even without it, most guarantees you get from the Signal protocol come from the clients. E.g. you don't need to know what the server is running to ensure that the content of your messages is not leaking. Other than that, being decentralized on its own doesn't magically solve the metadata problem. Signal leaks less metadata than most messengers, including decentralized ones.
Is there an easy way to get a direct HTTPS download link from the Play Store? The app itself certainly doesn't let you get the direct APK, or if it does then this must be a very obscure or new feature because I've been using Android for years and never seen it. My understanding is that the Play Store protocol is quite complicated.
Even if you can get such a link:
• It's not the case for iOS.
• It's not the case for WhatsApp.
• You have to repeat the process for every update, of which there are many.
• You don't know what version other people are running, which also matters. Consider group chats!
This is really something possible only in theory, not something normal users can actually do, hence the threshold signing/auditing proposal.
The claim that "Signal encryption doesn’t actually work" just seems inaccurate
I see a bunch of people getting hung up on this point. It's missing the forest for the trees.
Encryption in which you rely on your adversary to encrypt messages for you is conceptually broken. It doesn't matter if the encryption scheme works in theory in another context, in that context it's a failed setup. The example of WhatsApp (which uses the Signal encryption scheme) makes this clear: the Signal protocol in the abstract prevents the adversary learning when the same message is sent twice. In the most important concrete instantiation it actually doesn't: Facebook simply changed the client to expose that information unencrypted, and there's nothing anyone can do about it. Signal could do the same for their own network tomorrow, and given the ideological trends in the Bay Area perhaps they will. Or maybe they already did for some people? We have no way to know, only faith.
"If you do wish to continue communicating with people who are using Signal, you're still able to reappraise what you feel comfortable saying now you know that the behaviour has changed."
I think you're agreeing with me. The point of encryption is to turn the infrastructure provider into a "dumb pipe" that doesn't have opinions on what you think. If one day Signal or WhatsApp change the deal - as indeed Facebook did in 2019 - and you suddenly have to care what random Facebook employees think - then we can no longer really claim the service is end-to-end encrypted.
- 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?
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).
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.
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.
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.
This is not a game you can win with centralised app stores and app architecture that relies on push notifications.
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.
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.
Telegram, actually, can send push notifications to third-party clients, but requires uploading developer keys to them.
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.
https://www.eff.org/deeplinks/2022/01/eff-threat-labs-apkeep...
Every interaction with other humans or institutions is based on a degree of trust. Even https was designed by humans and a signing ceremony is being carried by humans that could have bad intentions. Trust has to be created or verified, if interacting entities have no knowledge about each other.
Audit trails were created for this reason and are ubiquitous in the world of the centralized web.
Have you tried search engine? I've got a lot of good answers by typing your exact question into duckduckgo.com
Note that PCs have this problem less, because there's filesystem access and a culture of direct distribution. I can go find the actual install folder and take a look at what's in there. For mobiles it's harder and we're forced to rely on these shady sites. Even on PC though someone has to reproduce the build, keep doing so and keep up with auditing source code changes. Nowhere does this. Even if there are reproducible builds, who exactly does the reproduction and much more expensive audit work is handwaved away. As an industry we're not even auditing the libraries we include into the final binaries, so we're a long way from being able to have a group of different people make confident claims about what a binary actually does.
Download apk from your phone (using adb) and compare?
Easy? No. But you can grab the apk from any number of third party download sites and verify the signature, and you can also just download it from https://signal.org/android/apk/ . Unless you've installed something via the Play Store, Android won't autoupdate it.
> • It's not the case for iOS.
It's still not hard to obtain iOS packages and verify their contents - it's definitely not as straightforward to use those as it is to sideload updates for Android, but it's still possible to verify that the binary matches the source, and you only need one person to notice.
> • It's not the case for WhatsApp.
Your claim was "Signal encryption doesn’t actually work". WhatsApp uses a whole bunch of Signal, but it's not Signal. This is like claiming that the IoT device I found that uses Signal in the backend but has all the key material in an unprotected Firebase bucket tells us anything about the security of Signal.
> • You have to repeat the process for every update, of which there are many.
No, someone has to. And that's something that could be automated.
> • You don't know what version other people are running, which also matters. Consider group chats!
If your position is "We should have infrastructure that makes it easy for third parties to audit Signal updates correspond to the source code", I absolutely agree! But we can build that with what currently exists, Signal's centralised infrastructure does nothing to prevent that.
> Encryption in which you rely on your adversary to encrypt messages for you is conceptually broken.
Every time someone sends an encrypted message, they're relying on a huge stack of technology that's largely outside their control. If my keyboard becomes untrustworthy, my guarantees are gone. If my video driver becomes untrustworthy, I'm in a bad place. Using any form of technology implies placing some trust in an awfully large set of people. On a daily basis, we're relying on an awful lot of faith. The Signal devs have gone out of their way to make it easier to verify whether that faith is misplaced or not.
But:
> We have no way to know, only faith.
We literally do have a way to know. We can dump every Signal APK installed on every phone and determine whether they match the source. It wouldn't be easy, but it could be done.
> If one day Signal or WhatsApp change the deal… then we can no longer really claim the service is end-to-end encrypted.
Signal doesn't appear to have changed the deal, so it seems like you're saying we can currently claim that it's end-to-end encrypted?
But people get it from the official app stores and for WhatsApp there's no other option (which is the main one I actually care about because that's where my contacts live).
I think some of this discussion is caused by conflation between Signal-the-tech and Signal-the-app. I could have called it the Axoltl Ratchet instead but I don't think anyone would know what I'm talking about, and anyway, I think it'd be less technically accurate as by now there's lots of stuff to do with group chats etc and I don't know what the underlying code-name is of those schemes. I normally see the whole encryption scheme just be called "Signal encryption".
If your position is "We should have infrastructure that makes it easy for third parties to audit Signal updates correspond to the source code", I absolutely agree! But we can build that with what currently exists, Signal's centralised infrastructure does nothing to prevent that.
We are in 95% agreement indeed! I proposed such an infrastructure in the article, based on threshold signatures, however, it doesn't exist today yet our industry is claiming "we use end-to-end encryption which means we can't read your messages". This claim isn't true - they can read our messages if they want to - and progress seems to have stopped after these rollouts. The claim that it's possible to have a trustless centralized infrastructure provider is a very bold one and currently it's not convincing, so to prove this is possible we need to keep things moving. There has been no attempt to make these services auditable nor even really any recognition that there needs to be. That troubles me a lot. At some point people are going to notice these claims don't add up and trust in the whole software industry may be damaged.
Edit: actually if I recall correctly Signal uses Intel SGX to make some parts of its contact list intersection system auditable. That's a great use of tech to solve some of these problems. SGX is one way to attack the centralized-but-untrusted-provider problem. I don't know if anyone is actually doing remote attestations on a regular basis though.
"Every time someone sends an encrypted message, they're relying on a huge stack of technology that's largely outside their control"
Yes, but those components come from different players, in different countries, with different governments and agendas who often do not trust each other blindly. Hence why mobile radios are now sandboxed, why keyboard apps are sandboxed, Samsung presumably watches out for Google playing naughty games with the Android source as part of their patching and distribution process, etc. Certainly carriers have a long history of treating phone makers as semi-trusted, hence the historically long approval processes.
"Signal doesn't appear to have changed the deal, so it seems like you're saying we can currently claim that it's end-to-end encrypted?"
I believe that is currently the case. I cannot prove it, nor can I prove it will remain the case tomorrow, if it is today, nor can anyone else I trust prove it. Which, logically, means it boils down to faith in Moxie and his employees, people I've never met and do not know. A blog post saying "we promise we're not logging messages" should really carry equal weight.
It doesn't matter what "people" do - what matters is whether a third party can obtain the same package and verify it. And they can!
> This claim isn't true - they can read our messages if they want to
They can read our messages if they want to, and we can detect that that happened, and then nobody uses their app any more.
> Samsung presumably watches out for Google playing naughty games with the Android source
Right! And we can watch out for Signal playing naughty games with their source. If you're ok trusting that Samsung will catch Google being untrustworthy, why are you not ok with trusting that signalverifier69's CI toolchain will catch Signal doing the same? The whole point here is that we don't need to trust Signal, we can absolutely verify it.
That said, it's a thin line. If Google had changed things at some point so that the Play Store could override the signing continuity requirement I wouldn't be remotely surprised.
They can’t, however Google have recently changed the requirements for submitting an application to the Play Store. You now need to hand over your application signing key. Instead of signing the application to prove authenticity to Android devices then giving it to Google to host, you now sign the application to provide authenticity to Google, and then Google re-signs it with the key you gave them to prove authenticity to Android devices.
So if Google want to provide an alternative binary to a specific person, they can now do that.
The Signal protocol[0] is used in Signal[1].
[0]: https://en.wikipedia.org/wiki/Signal_Protocol [1]: https://en.wikipedia.org/wiki/Signal_(software)
> they can read our messages if they want to
If Alice and Bob use the current version of the Signal app, they can't. You're worried about updates, fair enough, if that's within your threat model you're free to delay your updates for as long as you want, until you've reviewed them and waited enough to be relatively confident that a backdoor would have been found by then. Splitting the signing key into several like you suggest would delay updates for everyone while bringing negligible benefits to a tiny minority of Signal users.
Heya thanks for your comment.
Would you mind expanding on what the above means?
For the App Store newbies here - myself included :-)
Not only helpful in being able to verify that the binaries people publish are without 3rd part modifications, but also helpful in debugging and some other scenarios. More info here: https://reproducible-builds.org/
Although, on iOS I think reproducible builds are mostly useless (for the use case of verifying the binaries) as you can't download the binary straight from the App Store nor can you inspect installed binaries on your iPhone (AFAIK).
Web3, a boomerism in terms of indexing the internet as they see it, is hapless fad that people who don't or can't see that the current model of the internet is fundamentally broken and instead want to patch instead of fix the rot.
Kazakhstan has shown how hastily this centralized cesspool, that relies on spying and data collection, can be turned off. Which has been seen time and again since the uprising in the the Arab Spring. The Internet infrastructure as it currently exists is THE problem, and it is that needs to be corrected.
I think as technologists we have to accept that using a centralized blockchain, which ETH is, built on a horrible language (Solidity) has not and cannot bring about the progress Vitalik or anyone else has fantasized and sold many people on. To date, whether it be the DAO hack or 2.0 or whatever, all we see is how centralized systems make failure an inevitability rather than a possibility.
What I hope is that Starlink and Starship make it possible for new types of uncensorable ISPs get created that do not rely on these archaic models that rely on backbones out in the Ocean that are readily prone to attacks by adversaries that can be shut off at will [0] and rely on Nation-States to operate as a despot or regime sees fit.
That alone, beyond Mars colonization, should be enough for people to celebrate Spacex's success!
0: https://news.sky.com/story/russian-submarines-threatening-un...
This is… not true? Signal builds are reproducible. You can verify that the apk in the app store corresponds to a specific point in git history, and if you don't trust Google you can sideload that.
> Even if there was it’s irrelevant. Centralized infrastructure can claim to provide privacy but can never provide control: they can openly alter the deal at any time and I’d be forced to continue using it, if I couldn’t get my friends to switch to something else.
If you're using Signal because of the E2E properties, and Signal unilaterally changes its behaviour, you are absolutely not forced to continue using it. If you do wish to continue communicating with people who are using Signal, you're still able to reappraise what you feel comfortable saying now you know that the behaviour has changed.
The claim that "Signal encryption doesn’t actually work" just seems inaccurate. We can verify that Signal has the properties it claims it has. "Signal encryption could stop working" would be true - the client could absolutely just choose to start sending everything in plaintext, but we're not relying on a centralised group to make that claim! Anyone can look at the commits to Signal and flag that the claimed properties no longer apply.