> As for Signal it’s at least open source, but there’s no way to check that the client I’m using, or my friend is using, actually matches that source code.
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.
How does reproducible builds help you verify that you friends don’t have compromised builds installed? I haven’t used Signal, so I don’t know, but is there some way for your client to verify the client on the other end?
Knowing that your client isn’t compromised is pointless if you friend can’t/won’t do verification on their end.
This isn't something you can reasonably protect against and I don't even see this as a purely technical problem.
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?
Even if you could verify the client on the other end, that doesn't help you if the OS that client runs on is compromised because your friend carelessly allowed macros in an office document.
>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.
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.
I don't think Signal was ever on F-Droid? IIRC its code does contain some proprietary blobs and Signal doesn't want non-official clients to connect to their servers, so it'd be against Signal's wishes to have a fork on F-Droid without those proprietary blobs.
Agree though making it faster or more convenient would be a benefit. But I disagree that most people don't have time to check. It's just inconvenient or not important enough for those who choose not to.
Yeah the logic of the article seems absurd to me. The hypothetical problem applies to any client. If the open source software Signal cannot be trusted, how do you trust any other software you are using? It’s not the software problem , it’s the problem of the build and distribution of the software. As mentioned in other comments, you can use trusted build and distribution channel. The worst you can do is to build by your own if you want to be really safe. I have done that and it’s not so hard .
> 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.
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.
Right, but the point about the closed server infrastructure still stands, though, and you have to blindly trust them not to collect data about you or interfere with your message delivery, compared to a possible decentralized system.
> you have to blindly trust them not to collect data about you
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.
"You can verify that the apk in the app store corresponds to a specific point in git history"
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.
This argument is "true" for every non-static website. In theory, different content can be delivered based on certain criteria (activist, lawyer, etc).
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.
> Is there an easy way to get a direct HTTPS download link from the Play Store?
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?
Reproducible builds refers to the process where a binary/package can be verified that it been built from a specific commit (for example). If the build process is reproducible, it means that every time you build the project, the output is always the same (idempotent). So Signal can publish a binary + a hash + which commit it been built from, and you should be able to checkout that commit, build the project, and once built, both binaries should be exactly the same (the hash for both should be the same).
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).
Preface: No one, and I mean no one should take anything Mike Hearn has to say as credible, the guy is up there with Ver in terms of being persona non-grata for his blatant incompetence. His words seethe with a sense (and rejection) of wanting to be relevant, but as he proved with his 'rage quit' not only were his constant forks failures, but Bitcoin has survived all the attacks since he left proving he never could project anything accurately.
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!
It's interesting that the article touches on the reasons why end users might not want to run servers but doesn't mention at all one of the ones that comes to my mind most quickly, which is security.
Running a production server on your home network is a risky thing to do as, if there's a vulnerability in the code (and historically this has been quite common, especially when products are new), it allows attackers into home networks which are very likely to have a load of easily compromised unpatched consumer IT products.
Obviously it's possible to do this securely, if you have the right technical knowledge and the time and dedication to apply it, but I'd guess that it's a very small percentage of people who fall into that camp.
Your right. Ive been saying for years that routers should come with 2 networks (vlans) out of the box (colour coded red and blue) to make it easier to seperate out kit/appliances. One side for IoT stuff that you dont trust and the other side for our own equipment. But as you mention, even then consumers need to know how to set the networks up etc. As the old adage goes, you dont know what you dont know.
The issue with two networks is that many IoT things work by interacting with other things/users. A Philips Hue bridge or a Chromecast need to be accessible from the network you're on. And they rely on things like multicast and UPnP to function, which are hard if not impossible to do cross-vlan ( i looked into putting my Chromecasts on a different vlan and the setup was quite heavy).
Many routers already come with two networks separated with vlans. It's a common feature on TP-Link devices, among many others. They call it "Guest network", which makes it really easy to understand.
There are lots of reasons why people don't do it today, I didn't list all of them because it's easy to come up with them as indeed you've done here.
But again, note there's nothing fundamental about this problem. People routinely download and run arbitrary code on their desktops, laptops and smartphones, and most servers don't ever do that. If servers are less secure than web browsers it's a matter of effort put into the implementations, not something fundamental about human nature or computers.
>But again, note there's nothing fundamental about this problem. People routinely download and run arbitrary code on their desktops, laptops and smartphones...
But isn't that in fact the fundamental problem we're talking about? You get security without knowledge exactly if you give up all control over the device. What's the point of "running" your own server if all control you have left is that you can physically smash it to pieces?
Yes you can take control, but only to the degree to which you acquire the knowledge to keep it secure. I think this is a very fundamental trade-off.
Servers are directly attackable over the internet, unlike browsers :) Browsers are a very well hardened target at this point after decades of attacks. The fact that browsers still see exploitation, despite the money spent on their security by large well funded teams like those at google and Microsoft, shows the difficulty of securing applications.
Where servers have a direct correlation to money (e.g. if they are involved in processing crypto payments), there's a direct financial gain to exploitation, increasing the likelihood of attack.
(IMHO) After the first wave of worms compromising home users web3 servers, it would be pretty hard to convince people that it was a good idea to do it again
> Obviously it's possible to do this securely, if you have the right technical knowledge and the time and dedication to apply it, but I'd guess that it's a very small percentage of people who fall into that camp.
I think there's an underlying subtext that is missed in the article and this comment. Like, I don't disagree with the quoted bit above, but at the same time, I can't help but recognize that its truth is a consequence of design choices rather than an inevitability.
Americans happily own cars, which are themselves quite dangerous, laborious to manage, expensive to operate, have to be insured, and require an extensive and constantly updated training to maintain. They are companies that offer rental models, rather than ownership models, but they are mostly used by urban dwellers with limited income and travelers. Most people would tell you they'd prefer to own one. It's just a cultural context.
The same applies to servers. We could have servers that were well designed for people to self-manage with perhaps some basic training (certainly no more difficult than what is required than to pass a driving test), regular servicing, recalls, service stations spread throughout the nation, legal adjusted to favour ownership, etc.
Really, from a practical standpoint, the difference between a server and so many other computers deployed in homes (routers, mobile phones, IoT devices, cars, laptops, etc.) is far more subtle than we're willing to acknowledge... and frankly we actually introduce a lot of systemic risk by NOT requiring basic skills, regular servicing, insurance, etc. for these "pseudo-servers".
Both authors are conflating 2 different things and managing to talk past each other.
Moxie did conflate the state of Ethereum with the technical state of blockchain technology as a whole. In practice I am not sure this conflation actually matters though as right now most of the interesting stuff that is happening -is- on Ethereum. For the most part Moxie's arguments are completely on point regarding deficiencies in the offerings and the improvements he suggests would both be simple and materially improve them (whilst not addressing Mike's main problem which is semi-centralisation).
Mike manages to completely miss Moxie's point regarding how cryptography can be used to obviate some of (but not all) the problems with centralised infrastructure and work with the devices people actually have and use (mobile phones). He goes on to argue that if "people would just have desktops/linux servers at home this would all be different". But that isn't going to happen, that is a fantasy land.
The world isn't going back to a fully decentralized web. There are very good practical, commercial and political reasons for this.
For what it's worth, I do agree with Moxie that encryption is under-used and can make many kinds of semi-centralized infrastructure private. But that's irrelevant in this case. The focus is on WhatsApp because Moxie likes to use the speed with which it rolled out e2e encryption as the canonical example of why centralized services are better for privacy (this isn't the only place he's made this claim). But it's meaningless: something switched on quickly on a whim can also be switched off quickly on a whim. And, note, we found out that WhatsApp was newly encrypted because of a blog post and some messages in the UI. It could be switched off again silently and who would notice? We know the answer to this because hardly anyone realizes there are forwarding limits, even though it's in their FAQ. Apparently there aren't any groups reverse engineering every WhatsApp update to figure out if it's still encrypting everything.
With respect to the latter part, there might be a terminology issue here. I'm using "desktop" to mean any non-mobile/tablet/server device, including laptops or
stick PCs. A whole lot of people have such devices and in particular the sort of people who create content do. The idea that people only have mobile phones is false. There certainly are plenty of people who only have mobile phones and they matter, but there is also a huge population of people who have more powerful computers as well. And even for those who don't, a big part of why is not inability to have one but because they don't see any reason to buy one. That's not exactly fundamental.
Finally I would be very careful with predictions about technology trends. The computing industry has oscillated between big centralized computers and smaller more personal devices several times already. Even today the picture is quite ambiguous: as I argue in the article, a fully-bought-in Apple user is very much still a child of the PC revolution. Modern iPhones are as powerful hardware-wise as many PCs, just the form factor and usage model is different. The ecosystem there is very far from the canonical cloud-über-alles vision promoted by Google via the ChromeBooks.
> Apparently there aren't any groups reverse engineering every WhatsApp update to figure out if it's still encrypting everything.
If that were true--in the case of WhatsApp, I'm pretty sure it's not, as another poster here pointed out--it would be equally true for any open source app. Like, I dunno, Debian (https://jblevins.org/log/ssh-vulnkey).
There's absolutely a place for reproducible builds and binary transparency in the ecosystem. But those seem to me to be examples of what Moxie described: using cryptography to provide privacy and security guarantees while building on top of centralized infrastructure.
Would you rather binary transparency, or would you rather run Sendmail on your Debian server in your closet because, hey, it's physically yours? The conclusion that the latter is better is just nonsensical.
(And of course, Bitcoin Wallet is in the Play store, distributed in exactly the same way as Signal...)
Zerodium pays up to 1.5M$ for working exploits in i.e. WhatsApp [1]. Every widely used software, especially those used by millions and billions of users, is reverse engineered momentarily after every single patch by multiple groups.
Your argument is pretty much that you can't/shouldn't trust WhatsApp/Signal and Moxie's argument is you don't need to if the cryptography is implemented correctly. It can't be just switched off, any update to the applications gets reversed within hours of release well before it's rolled out to a significant population of the users because exploits in both are quite prized. As someone else pointed out WhatsApp RCEs go for ~$1.5M USD, that is in a similar class to iMessage.
Signals relay system is effectively untrusted at the protocol layer, this isn't much different from Bitcoin. The only real difference is the only people running it are the Signal folk. Is it an improvement to have a decentralized backend? Only arguably. From a user perspective it's actually often worse as fully decentralized peer-to-peer systems often perform worse and can't implement optimisations that are possible in centralised systems. From a purely "I can't trust anyone" perspective then no, but even Bitcoin and friends aren't that either. You trust the Bitcoin developers to not alter the protocol in a subtle way to weaken it just like you trust the Signal developers and server infrastructure not to subley subvert the cryptosystem.
What I am saying is I think trusting the protocol developers of blockchain like systems isn't substantially different from trusting the Signal developers with the exception that it would be easier to fork a blockchain if you disagreed while spinning up your own Signal infrastructure would be quite a lot more work.
As for powerful wall connected devices I do think you are being a bit facetious here. The vast majority of the population the mobile phone is their primary computing device. This is true across most of Asia, India and Africa. More modern developed countries have a wider proliferation of powerful consumer computing hardware but even there non-mobile computing is dwindling and while devices like iPad/tablets are becoming more popular they are prone to the same shortcomings of mobile devices (locked down OS, little/no background processing capability, unreliably connectivity).
Also I wouldn't cling too quickly to the idea that Apple is selling you something drastically different from Google. If you look at their recent earnings reports they are now generating more and more of their profits as a precentage from their services business. They very much are attempting to follow the Google model, they just weren't as aggressive in the route they took.
I don't actually see that as a problem though. If they can pursue a very cloud heavy model that is privacy preserving and protected by sufficient cryptography I don't see a problem. If however they keep going down the path of the device local CSAM scanning and the like... well I guess I won't be buying more Apple products.
At the end of the day user experience is king. Everything else fades away under the weight of sheer amounts of money that comes from bowing to consumerism. If all this Web 3.0 stuff has a poor user experience vs what is being peddled by Google/Apple then don't expect it survive for that long.
> He goes on to argue that if "people would just have desktops/linux servers at home this would all be different". But that isn't going to happen, that is a fantasy land.
I don't know. I'm looking around my home, and I have a WiFi router, an Android phone, a Chromebook, a Kindle, and a car. The distinction between those five devices and a linux desktop/server is pretty subtle --to the point of being a matter of semantics more than anything else. ;-)
I share the view that end-to-end encryption (E2EE) provides strong security guarantees only if the clients used to exchange data/messages are fully under control of the end users. All it would take Signal to undermine their E2EE is a single update of their app that exfiltrates all chat messages (not saying that I think they would ever do that). Same story for WhatsApp. In my opinion, a necessary ingredient for secure E2EE is that you don't have to trust the central infrastructure operator, at all. And that just doesn't work if the provider controls the client software.
Another problem is that almost all E2EE messengers can still be trivially man-in-the-middled (MITM) by the infrastructure operator, as there's no out-of-band verification of keys. The central server can just replace client keys in transit and decrypt all the data exchanged between two clients. This can only be detected by clients comparing their public keys over an out-of-band channel. Most E2EE messengers simply disregard this risk [1], while some provide functionality for out-of-band key verification (e.g. Threema). Always struck me as a bit odd as it's like using self-signed TLS certificates for your server, which leads to a security exception in all modern browsers but somehow seems to be fine for E2EE messengers. Keybase tried to solve this problem but unfortunately they got acquired by Zoom so I doubt they will continue working on that.
The article mentioned something I was not aware of - that WhatsApp has already started sending metadata (the number of times a message has been forwarded) in the clear:
> This is not a theoretical argument. Disabling E2E encryption has already happened, although hardly anyone knows about it. In 2019 WhatsApp imposed forwarding limits on messages in order to “slow down the spread of rumors, viral messages, and fake news”. This represents a total defeat of the Signal protocol’s cryptographic objectives: a basic goal of any modern cryptographic scheme is to ensure the same message encrypted twice doesn’t encrypt to the same bytes. The point of this is to stop the adversary knowing when you’re repeatedly sending the same message and encryption modes that get this wrong (like AES/ECB) are discredited. Yet once Facebook — the adversary — became dominated by authoritarians who see unlimited communication as chaotic, they simply changed the client to include a forwarding counter outside the encrypted part of the message. There was nothing anyone could do about this. It just showed up one day, and all the fancy mathematics designed to stop this “attack” were irrelevant.
WhatsApp does the counting of message forward completely on the client side. Their server does not know how many times a message has been forwarded.
THe article author's point was not that metadata is being sent in the clear, but that the real goal of encryption is to be unable to manipulate social behaviour. And because WhatsApp controls the client, they are able to do this without breaking E2EE or leaking metadata.
"Trivial" is overstating it, for exactly the reasons posted in that blogpost. People can and do verify keys out-of-band, and for that reason there is an extremely low chance that whatsapp (or signal) is wholesale MITMing connections. If you are concerned you will be targeted specifically you can treat key changes with much more suspicion.
But note, this still requires trusting the client. If the provider is going to change a key on you to spy on your messages, they will start by pushing a routine update to take out the warning and - assuming some cooperation from the app stores - that update could be sent only to you or your contacts.
> And that just doesn't work if the provider controls the client software.
The web platform is now capable of making this not required, we just need to build solutions that take advantage of it. The coupling of the service and the client (web/mobile apps) is something that should be challenged in "web 3.0" designs.
I’m excited to launch this product and the company behind it OK, so it's kind of an ad, although no product yet.
He makes an interesting point. If you're going to have home servers so you own your data, they need to be in something you own and control that's always plugged into power. There's the router, but you usually don't own that. It belongs to the telco or the cable company. A "speaker", i.e. Alexa and friends? Amazon controls that. The TV? That's a slave to the TV maker, Google, or the cable company. The doorbell? That's run by Amazon and the cops. The refrigerator?
Apple used to sell a box, their "Time Capsule", which was a home server. But Apple discontinued that. Apple became so cloud-oriented that their thermostat has to contact an external server to get the outside temperature.
Most people now have no home electronics that isn't a slave to someone else. Where do you put a home server?
> Apple used to sell a box, their "Time Capsule", which was a home server. But Apple discontinued that
Because no one is interesting in running their own server.
> Apple became so cloud-oriented that their thermostat has to contact an external server to get the outside temperature
Apple doesn't make a thermostat but they, along with many others, are moving to Matter. An interoperable, secure, private, open standard i.e. the very opposite of being cloud orientated.
>> Apple doesn't make a thermostat but they, along with many others, are moving to Matter. An interoperable, secure, private, open standard i.e. the very opposite of being cloud orientated.
Matter (formerly CHIP)? The protocol whose identity layer is allegedly based on a blockchain [0]? I think it needs the cloud, in the same way Moxie describes it.
> Because no one is interesting in running their own server.
"Home facing" servers and "network facing" servers are not the same thing at all. I'm not saying that implies a completely different attitude towards using them, but the differences are really important. If your social media identity lived on your own network-facing server, rather than FB/Twitter/Twitch/Discord/etc. servers, you may well feel differently about running it.
This is a cost of migration. I am totally fine with renting my server at AWS if I can move it to another provider at any time.
The goal of decentralization is ownership of your data and services. Centralization only becomes a problem if there is no competition and a company has too much power.
For that matter, how is that even a criticism? A thermostat sits on your (interior) wall; If you want it to be aware of the outside temperature for any reason, you either provide additional equipment that consumers need to mount outside their building (in such a way as to get an accurate reading whilst being weatherproof and having reliable power/connectivity)... or you just fetch it from an API based on your postal code like a sane person would
Don’t people here run raspberry pi’s for their home server needs?
As for the general public, they have to trust someone to run their home servers for them, whether that is google, apple, amazon or their friendly neighborhood HN reader. Trusting a megacorp is not necessarily a bad move because while they do take abusive steps to further their bottom line, they are pretty good about security and software updates and as a customer you are unlikely to experience severe harm like having your bank accounts emptied because of the privileged access they have (well, except if you buy into the apple ecosystem, then the emptying of the accounts happens willingly).
I'm not sure I buy the idea of "people just don't want servers in their homes". I think the people who have figured out how to do it, have captured the value. Some are hesitant to buy into that captured ecosystem.
Many people who own 3D printers, plug them into a raspberry pi running something called "octo-pi". 3D printer people are more technical than most, but they're not allways coders and highly skilled IT people. Octo-pi's are open source, free as in beer, and free as in speech software.
I know A LOT of people who go to pepole's houses, and say "hey that Alexa thing is cool, but why do you want Amazon to have a mic in your home". Lots of people see the value, many don't trust it.
> Apple used to sell a box, their "Time Capsule", which was a home server. But Apple discontinued that. Apple became so cloud-oriented that their thermostat has to contact an external server to get the outside temperature.
Time Capsule wasn’t a home server, just a NAS with integrated networking and backup. You couldn’t run software on it.
There has never been an Apple thermostat. Are you confusing Apple with a different company?
There’s nothing strange about a thermostat calling an API to get the outside temperature. Most thermostats aren’t physically able to measure the outside temperature themselves.
> I agree with points 1 and 2, but there’s a conceptual problem with the argument: cryptography cannot impose any limits on an adversary that also controls the client doing the encryption.
> Let’s put it less abstractly.
And then goes on to very concretely criticise WhatsApp and Signal instead of addressing Moxie's point, or how any of the crypto technologies address Moxie's point.
> Quick fixes
> Firstly let’s look at mobile messengers.
Why? Why look at them. If you're addressing Moxie's points, address them, and Moxie's article wasn't about the messengers.
> Why don’t non technical users want to run servers? After all, they have done in the past via programs like BitTorrent and Gnutella.
No. No, they haven't. While it was rather wide-spread, it still wasn't nearly as en masse as people pretend it was. An average non-technincal person wasn't running those clients. And, most importantly, the moment iTunes, then Steam, then Spotify appeared, people ditched running those torrent clients.
I wonder why /s
> They don’t do that today because the software industry outside of Cupertino isn’t interested in easily letting them do that.
Apple apps are not servers. And users are not running them. What wild logic leaps! Apple's iTunes ba sically single-handedly reduced the number of people running their own servers aka torrent clients.
> I’m excited to launch this product and the company behind it,
So. A marketing message hidden behind a rather inconherent "response"
As someone that indulges in both legal and pirated games, the benefits isn't in downloading content, but extra features. Stuff like auto-update, cloud saves, friends list, etc.
I don't trust any store to keep list of my games forever, sooner or later they will all fail.
> the benefits isn't in downloading content, but extra features. Stuff like auto-update, cloud saves, friends list, etc.
Features like donloading content is the main benefit. Or, rather, quick and painless access to content.
iTunes/Apple Music and Spotify never had any friends lists etc. And there are no "auto updates" to music. Same goes for Netflix (and other streaming services). And yet they reduced piracy probably a hundredfold.
Same goes for games. There are many features we associate with Steam these days, but many of those features weren't there for years, and still Steam was extremely successful and also significantly reduced piracy.
People don't want to chase content somewhere and then chase cracks/unlocks that may or may not work, that may or may not contain any number of viruses etc.
Mike's point seems to apply, practically speaking, to any software, including Bitcoin:
- Most users of Bitcoin Wallet download it from the Play Store
- Even if it's open source (as is the Signal client), "nobody's" reading through it and compiling their own builds
This sort of sweeping argument--that e2ee doesn't work because most users don't read source code--applies to everything, and as such isn't at all illuminating.
Readit News
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.
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?
Deleted Comment
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.
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.
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.
Deleted Comment
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?
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
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?
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...
Running a production server on your home network is a risky thing to do as, if there's a vulnerability in the code (and historically this has been quite common, especially when products are new), it allows attackers into home networks which are very likely to have a load of easily compromised unpatched consumer IT products.
Obviously it's possible to do this securely, if you have the right technical knowledge and the time and dedication to apply it, but I'd guess that it's a very small percentage of people who fall into that camp.
But again, note there's nothing fundamental about this problem. People routinely download and run arbitrary code on their desktops, laptops and smartphones, and most servers don't ever do that. If servers are less secure than web browsers it's a matter of effort put into the implementations, not something fundamental about human nature or computers.
But isn't that in fact the fundamental problem we're talking about? You get security without knowledge exactly if you give up all control over the device. What's the point of "running" your own server if all control you have left is that you can physically smash it to pieces?
Yes you can take control, but only to the degree to which you acquire the knowledge to keep it secure. I think this is a very fundamental trade-off.
Where servers have a direct correlation to money (e.g. if they are involved in processing crypto payments), there's a direct financial gain to exploitation, increasing the likelihood of attack.
(IMHO) After the first wave of worms compromising home users web3 servers, it would be pretty hard to convince people that it was a good idea to do it again
I think there's an underlying subtext that is missed in the article and this comment. Like, I don't disagree with the quoted bit above, but at the same time, I can't help but recognize that its truth is a consequence of design choices rather than an inevitability.
Americans happily own cars, which are themselves quite dangerous, laborious to manage, expensive to operate, have to be insured, and require an extensive and constantly updated training to maintain. They are companies that offer rental models, rather than ownership models, but they are mostly used by urban dwellers with limited income and travelers. Most people would tell you they'd prefer to own one. It's just a cultural context.
The same applies to servers. We could have servers that were well designed for people to self-manage with perhaps some basic training (certainly no more difficult than what is required than to pass a driving test), regular servicing, recalls, service stations spread throughout the nation, legal adjusted to favour ownership, etc.
Really, from a practical standpoint, the difference between a server and so many other computers deployed in homes (routers, mobile phones, IoT devices, cars, laptops, etc.) is far more subtle than we're willing to acknowledge... and frankly we actually introduce a lot of systemic risk by NOT requiring basic skills, regular servicing, insurance, etc. for these "pseudo-servers".
Moxie did conflate the state of Ethereum with the technical state of blockchain technology as a whole. In practice I am not sure this conflation actually matters though as right now most of the interesting stuff that is happening -is- on Ethereum. For the most part Moxie's arguments are completely on point regarding deficiencies in the offerings and the improvements he suggests would both be simple and materially improve them (whilst not addressing Mike's main problem which is semi-centralisation).
Mike manages to completely miss Moxie's point regarding how cryptography can be used to obviate some of (but not all) the problems with centralised infrastructure and work with the devices people actually have and use (mobile phones). He goes on to argue that if "people would just have desktops/linux servers at home this would all be different". But that isn't going to happen, that is a fantasy land.
The world isn't going back to a fully decentralized web. There are very good practical, commercial and political reasons for this.
With respect to the latter part, there might be a terminology issue here. I'm using "desktop" to mean any non-mobile/tablet/server device, including laptops or stick PCs. A whole lot of people have such devices and in particular the sort of people who create content do. The idea that people only have mobile phones is false. There certainly are plenty of people who only have mobile phones and they matter, but there is also a huge population of people who have more powerful computers as well. And even for those who don't, a big part of why is not inability to have one but because they don't see any reason to buy one. That's not exactly fundamental.
Finally I would be very careful with predictions about technology trends. The computing industry has oscillated between big centralized computers and smaller more personal devices several times already. Even today the picture is quite ambiguous: as I argue in the article, a fully-bought-in Apple user is very much still a child of the PC revolution. Modern iPhones are as powerful hardware-wise as many PCs, just the form factor and usage model is different. The ecosystem there is very far from the canonical cloud-über-alles vision promoted by Google via the ChromeBooks.
If that were true--in the case of WhatsApp, I'm pretty sure it's not, as another poster here pointed out--it would be equally true for any open source app. Like, I dunno, Debian (https://jblevins.org/log/ssh-vulnkey).
There's absolutely a place for reproducible builds and binary transparency in the ecosystem. But those seem to me to be examples of what Moxie described: using cryptography to provide privacy and security guarantees while building on top of centralized infrastructure.
Would you rather binary transparency, or would you rather run Sendmail on your Debian server in your closet because, hey, it's physically yours? The conclusion that the latter is better is just nonsensical.
(And of course, Bitcoin Wallet is in the Play store, distributed in exactly the same way as Signal...)
[1] https://zerodium.com/program.html
Signals relay system is effectively untrusted at the protocol layer, this isn't much different from Bitcoin. The only real difference is the only people running it are the Signal folk. Is it an improvement to have a decentralized backend? Only arguably. From a user perspective it's actually often worse as fully decentralized peer-to-peer systems often perform worse and can't implement optimisations that are possible in centralised systems. From a purely "I can't trust anyone" perspective then no, but even Bitcoin and friends aren't that either. You trust the Bitcoin developers to not alter the protocol in a subtle way to weaken it just like you trust the Signal developers and server infrastructure not to subley subvert the cryptosystem.
What I am saying is I think trusting the protocol developers of blockchain like systems isn't substantially different from trusting the Signal developers with the exception that it would be easier to fork a blockchain if you disagreed while spinning up your own Signal infrastructure would be quite a lot more work.
As for powerful wall connected devices I do think you are being a bit facetious here. The vast majority of the population the mobile phone is their primary computing device. This is true across most of Asia, India and Africa. More modern developed countries have a wider proliferation of powerful consumer computing hardware but even there non-mobile computing is dwindling and while devices like iPad/tablets are becoming more popular they are prone to the same shortcomings of mobile devices (locked down OS, little/no background processing capability, unreliably connectivity).
Also I wouldn't cling too quickly to the idea that Apple is selling you something drastically different from Google. If you look at their recent earnings reports they are now generating more and more of their profits as a precentage from their services business. They very much are attempting to follow the Google model, they just weren't as aggressive in the route they took.
I don't actually see that as a problem though. If they can pursue a very cloud heavy model that is privacy preserving and protected by sufficient cryptography I don't see a problem. If however they keep going down the path of the device local CSAM scanning and the like... well I guess I won't be buying more Apple products.
At the end of the day user experience is king. Everything else fades away under the weight of sheer amounts of money that comes from bowing to consumerism. If all this Web 3.0 stuff has a poor user experience vs what is being peddled by Google/Apple then don't expect it survive for that long.
I don't know. I'm looking around my home, and I have a WiFi router, an Android phone, a Chromebook, a Kindle, and a car. The distinction between those five devices and a linux desktop/server is pretty subtle --to the point of being a matter of semantics more than anything else. ;-)
Sure there are other paths in crypto land that theoretically could have been better than what we got. It's besides the point though.
Moxie's original argument wasn't against what is theoretically possible - it was about what actually happened.
Another problem is that almost all E2EE messengers can still be trivially man-in-the-middled (MITM) by the infrastructure operator, as there's no out-of-band verification of keys. The central server can just replace client keys in transit and decrypt all the data exchanged between two clients. This can only be detected by clients comparing their public keys over an out-of-band channel. Most E2EE messengers simply disregard this risk [1], while some provide functionality for out-of-band key verification (e.g. Threema). Always struck me as a bit odd as it's like using self-signed TLS certificates for your server, which leads to a security exception in all modern browsers but somehow seems to be fine for E2EE messengers. Keybase tried to solve this problem but unfortunately they got acquired by Zoom so I doubt they will continue working on that.
[1] https://signal.org/blog/there-is-no-whatsapp-backdoor/
> This is not a theoretical argument. Disabling E2E encryption has already happened, although hardly anyone knows about it. In 2019 WhatsApp imposed forwarding limits on messages in order to “slow down the spread of rumors, viral messages, and fake news”. This represents a total defeat of the Signal protocol’s cryptographic objectives: a basic goal of any modern cryptographic scheme is to ensure the same message encrypted twice doesn’t encrypt to the same bytes. The point of this is to stop the adversary knowing when you’re repeatedly sending the same message and encryption modes that get this wrong (like AES/ECB) are discredited. Yet once Facebook — the adversary — became dominated by authoritarians who see unlimited communication as chaotic, they simply changed the client to include a forwarding counter outside the encrypted part of the message. There was nothing anyone could do about this. It just showed up one day, and all the fancy mathematics designed to stop this “attack” were irrelevant.
THe article author's point was not that metadata is being sent in the clear, but that the real goal of encryption is to be unable to manipulate social behaviour. And because WhatsApp controls the client, they are able to do this without breaking E2EE or leaking metadata.
The web platform is now capable of making this not required, we just need to build solutions that take advantage of it. The coupling of the service and the client (web/mobile apps) is something that should be challenged in "web 3.0" designs.
He makes an interesting point. If you're going to have home servers so you own your data, they need to be in something you own and control that's always plugged into power. There's the router, but you usually don't own that. It belongs to the telco or the cable company. A "speaker", i.e. Alexa and friends? Amazon controls that. The TV? That's a slave to the TV maker, Google, or the cable company. The doorbell? That's run by Amazon and the cops. The refrigerator?
Apple used to sell a box, their "Time Capsule", which was a home server. But Apple discontinued that. Apple became so cloud-oriented that their thermostat has to contact an external server to get the outside temperature.
Most people now have no home electronics that isn't a slave to someone else. Where do you put a home server?
Because no one is interesting in running their own server.
> Apple became so cloud-oriented that their thermostat has to contact an external server to get the outside temperature
Apple doesn't make a thermostat but they, along with many others, are moving to Matter. An interoperable, secure, private, open standard i.e. the very opposite of being cloud orientated.
Matter (formerly CHIP)? The protocol whose identity layer is allegedly based on a blockchain [0]? I think it needs the cloud, in the same way Moxie describes it.
[0] https://staceyoniot.com/blockchain-101-how-distributed-trust...
"Home facing" servers and "network facing" servers are not the same thing at all. I'm not saying that implies a completely different attitude towards using them, but the differences are really important. If your social media identity lived on your own network-facing server, rather than FB/Twitter/Twitch/Discord/etc. servers, you may well feel differently about running it.
The goal of decentralization is ownership of your data and services. Centralization only becomes a problem if there is no competition and a company has too much power.
It seems often when an API is used to migrate to a new system the API is turned off. Thats if there was an API at all.
If the centralized service is an easily replaceable commodity... I'm not super concerned.
Did you mean Google with their Nest devices?
Apple don't sell a thermostat. Although I wouldn't be surprised if HomeKit enabled devices needed to do what you described LOL :-)
As for the general public, they have to trust someone to run their home servers for them, whether that is google, apple, amazon or their friendly neighborhood HN reader. Trusting a megacorp is not necessarily a bad move because while they do take abusive steps to further their bottom line, they are pretty good about security and software updates and as a customer you are unlikely to experience severe harm like having your bank accounts emptied because of the privileged access they have (well, except if you buy into the apple ecosystem, then the emptying of the accounts happens willingly).
Many people who own 3D printers, plug them into a raspberry pi running something called "octo-pi". 3D printer people are more technical than most, but they're not allways coders and highly skilled IT people. Octo-pi's are open source, free as in beer, and free as in speech software.
I know A LOT of people who go to pepole's houses, and say "hey that Alexa thing is cool, but why do you want Amazon to have a mic in your home". Lots of people see the value, many don't trust it.
Time Capsule wasn’t a home server, just a NAS with integrated networking and backup. You couldn’t run software on it.
There has never been an Apple thermostat. Are you confusing Apple with a different company?
There’s nothing strange about a thermostat calling an API to get the outside temperature. Most thermostats aren’t physically able to measure the outside temperature themselves.
> Let’s put it less abstractly.
And then goes on to very concretely criticise WhatsApp and Signal instead of addressing Moxie's point, or how any of the crypto technologies address Moxie's point.
> Quick fixes
> Firstly let’s look at mobile messengers.
Why? Why look at them. If you're addressing Moxie's points, address them, and Moxie's article wasn't about the messengers.
> Why don’t non technical users want to run servers? After all, they have done in the past via programs like BitTorrent and Gnutella.
No. No, they haven't. While it was rather wide-spread, it still wasn't nearly as en masse as people pretend it was. An average non-technincal person wasn't running those clients. And, most importantly, the moment iTunes, then Steam, then Spotify appeared, people ditched running those torrent clients.
I wonder why /s
> They don’t do that today because the software industry outside of Cupertino isn’t interested in easily letting them do that.
Apple apps are not servers. And users are not running them. What wild logic leaps! Apple's iTunes ba sically single-handedly reduced the number of people running their own servers aka torrent clients.
> I’m excited to launch this product and the company behind it,
So. A marketing message hidden behind a rather inconherent "response"
I don't trust any store to keep list of my games forever, sooner or later they will all fail.
Features like donloading content is the main benefit. Or, rather, quick and painless access to content.
iTunes/Apple Music and Spotify never had any friends lists etc. And there are no "auto updates" to music. Same goes for Netflix (and other streaming services). And yet they reduced piracy probably a hundredfold.
Same goes for games. There are many features we associate with Steam these days, but many of those features weren't there for years, and still Steam was extremely successful and also significantly reduced piracy.
People don't want to chase content somewhere and then chase cracks/unlocks that may or may not work, that may or may not contain any number of viruses etc.
- Most users of Bitcoin Wallet download it from the Play Store
- Even if it's open source (as is the Signal client), "nobody's" reading through it and compiling their own builds
This sort of sweeping argument--that e2ee doesn't work because most users don't read source code--applies to everything, and as such isn't at all illuminating.