Moxie Marlinspike has a plan to reclaim our privacy
newyorker.com
newyorker.com
There's a middle way for a lot of product categories: find an enthusiast community and get their recommendation for a low-cost and beginner-friendly product. It's often listed in their FAQ. The gap between enthusiast-grade and mass-market products in some categories is huge, while the gap in price may not be.
https://moxie.org/2013/06/12/we-should-all-have-something-to...
Do the right thing poorly instead of the wrong thing correctly.
I've bought a lot of junk and I've spent more time trying to fix the junk or replace it than I'd like to admit and I'd rather spend the upfront time finding the stuff that's not junk in the future so I can spend more time with my family and less time running to the store for a new toaster after mine blows up. just my 2 cents.
But there is also an enjoyment to be had with nice stuff. Just be aware that that enjoyment often comes with a "duty" to care for it. The trade-off might be worth it, might not. That care might even be part of the enjoyment: my dad _really_ enjoys cleaning, waxing and polishing his Mini Cooper S (a special edition John Cooper Works model).
In 2013, I started gradually unsubscribing from things which were not absolutely essential to my existence.
It's great that you're learning a bunch by buying the worst motorcycle or boat, but you probably don't want to buy the worst lifejacket or helmet.
> The best means waiting, planning, researching, and saving until one can acquire the perfect equipment for a given task. Partisans of the best will probably never end up accidentally riding a freight train 1000 miles in the wrong direction...
Also, and I'm being a bit tongue-in-cheek here: with people trusting Moxie with their privacy, I hope he's past his phase of (metaphorically) riding freight trains without checking maps, and is spending some time waiting, planning, researching and saving.
“
Perrin told me that, despite appearances, ‘Moxie leads from the front, and he just leads by doing. One of his favorite quotes is “The only secret is to begin.” If you want to get good at something or do something, you just do it, and you figure it out along the way.’
“
I have my own kibbitz about stuff down in the weeds, I think the decision to make a cellphone/SMS identity key in the recruitment and to have one device per identity is a design issue for me and my use case, but I understand this is not a black/white thing, and there were noises made in 2019 about moving to a different model of identity, I an content to wait, but there is the vague meta-question if the ranking of this kind of idea gets exposure too: How do we know the thinking around identity and recruitment?
It's not just black and white.
Read some advanced cryptography papers and you'll discover it's not quite that simple. There are the exotic hardness assumptions: are those mathematical problems really hard to solve or not? They aren't classical, natural problems like discrete log. Then there are the odd threat models, e.g. plenty of algorithms out there claim to be proven secure in the honest-but-curious model. Although this threat model isn't entirely naive, in the real business world "honest but curious" adversaries do appear in the imaginations of business leaders at least, but most people assume the point of cryptography is to keep you secure against arbitrarily malicious adversaries.
I am a bit more confident now that usernames will eventually come.
But the fact that it’s so slow to change is quite ironic, considering that the whole point is “the ecosystem is moving”. Well apparently it moves like molasses.
> You can now get someone’s attention with @mentions in groups. You can mention anyone in a group message simply by typing “@” and selecting them from the picker. […] And you can configure the group’s notifications in Group Details to only notify you when you’re mentioned.
Re: mention-only notifications I definitely agree - if they exist now for groups then this makes Signal quite an attractive alternative to other messengers. I'm using Matrix for some things now but notifications are set globally (not per client/device). I'd like to keep all channels on mobile on mention-only (I try to minimize mobile notifications in general) but when I have the desktop (or web) app open I don't mind getting all notifications from particular channels. That makes me able to keep up with conversations in real time. And if I want to not be disturbed I just close the app or disable notifications globally (MacOS). With Matrix (at least the Element.io clients) this is not possible so I end up switching the notification settings back and forth...
I have lots of respect for the man and love his thinking, writing and outlook on things. His blog[1] has a lot of good reads.
During the Snowden Leaks the same thing happened with Jacob Appelbaum and Julian Assange. There was no critical analysis on what they were actually doing or a lot of the advice they were giving people.
It's almost like the field somehow requires a defacto head who conveniently fits the media stereotype.
Signal's constitutional emphasis on usability supports user demographics that no other security product can attract. My elderly relatives use Signal now instead of Skype. This drew in other family members who just wanted to video chat with grandma and grandpa. Matrix will never win markets like this.
When tech nerds nit pick Signal's implementation, they ignore that the unfederated nature of Signal limits the damage these decisions can cause. Thanks to Signal's security posture, global protection from weak ciphers, buffer overflows, and even SGX, is just one software update away. This even protects you from faults in your contact's clients! Like the key agility that makes the Axolotl Ratchet so superior to GPG, update agility makes Signal infinitely superior to every existing or proposed federated network.
The Signal group has an uncompromising commitment to user privacy and a poignant security philosophy. Signal has no competition in its usability class, making hypothetical protections from other products worse than useless for user cohorts who will probably switch back to skype or sms. Signal's detractors do a terrible disservice to the people they dissuade from using it.
It limits the damage that some decisions can cause, but exacerbates others. Signal only allows the first-party client to connect to its network; if the developers were legally compelled to add a backdoor into that client, users would have few options.
Its security depends on a single company being perpetually trustworthy, free of influence, and supported. Having used many chat platforms that have been shut down/acquired/etc in the past, that’s not a bet I’m willing to take.
I’d also contest the idea that Matrix can never have a client as usable as Signal, but I’ll agree that there isn’t one yet.
App publishing platforms not having a good binary signature verification system is the orthogonal issue that you're bringing up, that would in many ways apply to matrix for most users too. Most will never bother to sideload it.
You can't though, what use is your own fork when nobody uses it?
Resources and network effects make this a much much less likely endeavor than in federated systems. I can reasonably (and do!) self-host Matrix and XMPP servers for myself and a few friends; I cannot reasonably host a Signal server for everyone I might want to possibly contact via Signal. (And that's setting aside the effort involved in convincing everyone I might possibly want to contact to use my Signal server. It's just not going to happen.)
EDIT: Oh, and I don't think the VoIP side of the Signal server is FOSS? At least I believe that used to be the case.
>App publishing platforms not having a good binary signature verification system is the orthogonal issue that you're bringing up, that would in many ways apply to matrix for most users too. Most will never bother to sideload it.
If the main client developers are pressured to put a backdoor into their client, I would expect non-backdoored forks to rapidly pop up in the stores.
If the platform provider is also legally pressured to not allow any non-backdoored clients into the store... well, I hope that never happens, but if we get to that point I hope more people would bother to learn more and start sideloading things. Maybe wishful thinking on my part.
It's not a stretch to imagine a repeat. That moxie will brag in 10 years about how much he is banning people and how well it works. I wonder who will be unpopular in 10 years..
EDIT: Or he might hang himself like Aaron Schwartz.
Someone could perhaps distribute their own patched client binary as well, but given Moxie/OWS's views on patched clients, I'd expect them to run into trouble at some point doing that: https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
After being around for multiple years and having not managed to do it even once (or come close) I think I am inclined to bet they won't. Or they'd just focus on being enterprise software (which I think they are doing and they must if they want to earn money).
Of all the IM apps Matrix is my most favourite in the spirit and least favourite in usability. Any attempt to introduce friends and family has failed miserably. Irony is, I myself was not convinced and I was trying to convert them.
There are other clients in development that are closer UI-wise to your typical mobile messenger, e.g. https://dittochat.org/
I'm of the completely opposite opinion I find Element absolutely atrocious compared to Slack in terms of usability The mobile app is decent though. And I don't know at what pace Element is being improved, only been using it for a couple of weeks.
That said Slack has been going downhill UI/UX-wise for years now.
Another client that I think is aiming to fill that gap (and also has a provider with bridges to eg Messenger et al) is Novachat: https://nova.chat/
Matrix is not an IM app, it’s a protocol. Anyone is encouraged to make an app for it.
It’s a long game. I’d give it another year or two before I think it’s grandma-ready.
Despite this, there are multiple alternative server implementations. Dendrite is the next gen server from the same core team, though Construct and Conduit are fledgling servers from different groups.
Huh? I send messages to my friends daily using the API via https://gitlab.com/thefinn93/signald which is definitely third party.
Makes it pretty clear that OWS does not want people using third-party clients with the official Signal servers.
I am not sure how you can usefully compare a thing originally intended to secure email to a thing intended to secure IM.
The ratchet only provides forward secrecy anyway. My take on that is that it is a pointless thing for something like email and pointless in practice for most IM applications. Most IM users keep their old messages and practically all email users keep their old messages...
There is nothing particularly wrong with Signal. Some of the criticism might a reaction to the constant promotion of it over all other things, even when (as in this case) the things are fundamentally different.
In court none of that is likely to hold up anyway, as evidence like chat databases is pretty much assumed to be true until proven otherwise.
* The burden of evidence to introduce chat logs in legal proceedings is much lower than you would think. Often screenshots of Facebook messages are used, or SMS records (which are also easily spoofed). A judge or jury will likely not entertain the possibility the messages were fabricated unless you have substantial evidence to the contrary.
* If you're scared of national security actors discovering you've leaked some information, the fact there is a record of the secret information in the other person's phone is more than enough for them to black bag you. (And let's be honest, lack of evidence has never stopped the USA from black bagging people.)
* Generally speaking, the probability of the chat record being faked is so small that no reasonable person will entertain the possibility it was faked (even though it could've been).
Not to mention there are all sorts of forensic methods to prove that a particular person wrote some message using fingerprinting, and ultimately Signal LLC does actually know whether you sent a message or not and who to (though admittedly they claim they don't keep metadata logs).
Now, if you're dealing with an anonymised chat system with this property then it could be argued it is practically useful. But at that point the anonymisation is doing most of the heavy lifting.
This is true for now. It seems likely that fabrication of screenshots etc will start to appear in legal cases, and as soon as it does, the burden of proof will shift.
Translation: Signals ability to forcefully change the software and protocol out for users without any consent (much less informed consent) renders it functionally immune to any criticism or review because any aspect of the protocol could be changed ('improved') at a moments notice.
I think signal is a fine insecure messenger. If you mistake it for a cryptographic security product you are making a significant mistake. The fact that is uses cryptographic techniques internally just means that it isn't grossly incompetently constructed, but that doesn't make it achieve any particularly strong notion of security against any particular attack model.
I strongly recommend people us it (at least on devices which are already compromised by mystery meat binary updates that could be remotely backdoored at any time)... just don't think it's going to provide you with substantial security against active attackers (much less state level attackers or from Signal themselves).
What percentage of users, globally, do you suppose are qualified to make informed consent on arbitrary patches to $secure_messenger of your choosing?
Signal's software management practices make the system largely opaque even to experts, and what review does happen comes at a significant lag. This is evidenced by the substantial number of times that signal has had to back-pedal on a change after substantial backlash. Even where it isn't opaque, there is no consent: the software stops running if you don't accept all changes, and seldom are changes introduced as optional features (default-on or otherwise).
It's properly federated, with a diversity of client and server implementations (something that will likely never happen with Matrix due to the excessive complexity and poor design of the protocol), servers are easy to deploy and don't need a lot of system resources, and it has strong security.
The main issue is that there are only a few really good clients, since network effects convinced everyone to use inferior (but better marketed) messaging systems. Conversations (on Android) is excellent, though.
XMPP has a clear design based around general concepts, that make it useful for a wide variety of messaging-type applications. The criticism I hear often seems to come from people approaching it as an IM protocol, and then being upset that they need to learn some general XMPP concepts to understand how IM is implemented on top of XMPP. The reality is that it's a general protocol, which can be used to implement a variety of different real-time messaging applications. That generality can cause people to think it's overcomplex if they approach it as if it's designed purely for IM.
You'll often find XMPP as the underlying tech for IoT real-time communication, or for signaling/presence (as an alternative to SIP) for videoconferencing (for example, Jitsi Meet uses XMPP for signaling). In this way, XMPP is quite widely used, but often not in a way that people are aware of.
By contrast, Matrix appears to attempt a clean-sheet design without learning any of the lessons of the many protocols that came before it. The protocol is heavy on special cases, has many serious inefficiencies (many coming from an apparent desire to make the protocol "more Web"), and especially on the server side requires a large amount of implementation work simply to get to a basic level of functionality (as opposed to XMPP, where a simple server for a basic set of functionality can be written in a very small amount of code, especially if you make use of an existing XML library).
I've written code for both protocols (as well as many other protocols with similar goals) and will do my best to avoid touching Matrix ever again.
Anything that relies on SS7/PSTN working correctly is a very bad design choice in my opinion.
Giving out your phone number to possibly untrusted contacts is also a bad decision because it opens up opportunities for scams, spam and social-engineering attempted hijacks of accounts (SIM swap attacks etc).
Conversely, thanks to Signal's centralized model, implementations of backdoors are also one software update away. By the time the "nerds" find out, it'd probably be far too late and lives could be at stake.
It's unfortunately such the nature of the beast that being half-hearted about security does not yield a half-secure product, or a product that's fully secure against half the hostile actors, it yields a product that only gives the presumption of safety, which is far more dangerous.
I use many messaging services in my life as security absolutism leads to a very miserable, very paranoid life, but my expectations are accordingly tempered when I use them, and I let my contacts know my expectations too. Everyday chat? Sure. Sensitive, personal info? Maybe, depends on the exact topic. Trade/state secrets (if I were to handle them)? Hell no.
Would you say that outing people who are signal users and putting them in signal contact lists without their permission is 'uncompromising commitment to user privacy?'
Without automatic contact discovery "Signal private messenger" would be forced to default to not-private for all contacts until manual confirmation could occur. Adding UX friction to the primary use case would hinder adoption among non security-enthusiasts. With protection for the casual user eliminated, the truly sensitive communications of those motivated for privacy would stick out like a sore thumb, revealing many more bits of meta data than just "this number had signal once."
Elite users who care about being "outted" simply for signal participation can take steps to mitigate. The rest of us need automatic contact discovery for Signal to not be useless.
I mean, the fact that Signal actively notifies you when a contact registers for Signal is a complete misfeature (yes, this is basically a cosmetic complaint). It actively outs people who don't want to be outed and it's a useless notification to all of your contacts if you don't care about it.
But update or no, it's irresponsible to proffer these scenarios as relevant to the typical westerner, especially given the abysmal privacy of the popular alternatives.
If you're reading this in English, Signal is the most effective tool for private communications available to you.
Have you considered the (sadly) common case of an abusive partner who is likely to see your sudden usage of Signal as an indication that you are speaking to other people about their abuse, or at the least asking others for help?
I don't think these scenarios are nearly as rare as you think they are. These cases do definitely happen in English-speaking countries -- not that I understand your argument here in the first place (Signal is available world-wide and has been translated to many other languages, what does language have to do with anything?). Not to mention that Signal themselves don't warn you about this behaviour at all.
(Yes, you could argue that an abusive partner has many other avenues through which to discover that you're asking for help -- but that isn't a defense of providing more avenues for an abuser to discover you're asking for help. Again, Signal actively notifies all of your contacts that you've started using Signal -- which is above and beyond the transparent upgrade from SMS to Signal messages you mentioned.)
But isn’t that scenario a weak one? How would you know to install signal and reach out to a specific person for help if you hadn’t already asked for help?
However, their decision to force PINs broke Signal for one of my non-technical contacts, to this day (despite them supposedly offering an opt-out now). This person opens Signal, gets some weird confusing modal dialog, and is now stuck.
There is supposed to be a way to opt out without having to set and remember a PIN now, but I was unable to guide this person to find it, and I can't exactly travel there to see what's on the screen and find the damn button (or figure out why it isn't showing up). So this person can no longer use Signal, and we had to fall back to WhatsApp. Which leaks more information, but has a killer feature that Signal now lacks: it allows me to communicate with this person!
(For those unaware: Signal made a really boneheaded decision a couple months ago, against all specific criticism that they were receiving - they introduced PINs that would then be used to back up at least metadata to the server, protected under a questionable scheme whose security assumptions only work if SGX is unbreakable. To force users into this, they blocked access to the messenger and your messages, so you had to set a PIN and upload your data if you wanted to talk to your friends and didn't have a contact for them on a different messenger.)
Intentionally breaking a product like this also breaks trust. I can no longer rely on Signal for "just wanting a video chat with Grandma and Grandpa". I can no longer trust that Moxie will make reasonable decisions, and not e.g. tomorrow break my ability to communicate with people unless I agree to upload my message history.
If I'm not mistaken, this PIN also allows people to hijack your account. That's kind of the point; you export here and you import on your next phone.
But I'm not sure, because the whole thing is so badly explained!
Saying the usability mode of: “you lose your history when you get a new device unless it happens to fall into a very narrow window” isn’t user friendly. And it has nothing to do with geeky nitpicking.
Under monarchy, the power of the monarch is greatly amplifed. A great monarch can accomplish beneficial reforms at scope and speed not achievable by any republic. A bad monarch can inflict damage at scope and speed unprecedented in any republic.
Equally, a centralized network can achieve colossal heights of UX, security, speed, architectural cleanliness, etc; moxie wrote a lot about that. Or it can fall into bottomless chasms of poor UX, poor functioning, and insecurity (examples are many, take maybe ICQ by the early 2000s). By construction, three's no way for a part of the network to avoid the common fate, try and find a recourse, etc.
A republic (and a democracy) severely limits the power of officials it elects, more, it intentionally pitches different branches against each other in a system of checks and balances. This prevents it from achieving grandiose visions in short time, most of the time, even when the best officials are elected. It also prevents it from turning into hell, most of the time, even if some egregiously bad officials are elected to the highest offices.
Same with federated networks: they offer a much less coherent UX, are more complex, less powerful, more slow, harder to upgrade — but they are also resilient against a bad actor that grabs power, for they lack a SPOF, and have a healthy nonzero amount of distrust between parts. If one part rots, others remain, and new can be made.
So yes, bet on the centralized system, a brilliant benevolent dictator if you think the dictator outlives your need to use a system. Bet on moxie, Steve Jobs, or king Arthur to live effectively forever.
Or bet on an open standard with a half-dozen implementations of varying quality if you think that things will inevitably go sour in some of them during your lifetime, or whatever is the time scope for your use of the system.
There is no single right answer, no Goldilocks solution. Choose your poison.
This is a big usability no-go for me an the reason I’m not using Signal anymore. Don’t interfere with other messaging systems like SMS.
Some people have prominent positions or intend to do important things in their life and they don't want to see personal conversations being leaked under the threat of blackmail.
This is a tired trope and it's time we put it to rest. There is nothing wrong with software not intended for a "mass market".
Marlinspike is the guy who wrote a protocol with a built in MITM functionality, and had enough chutzpah to call it end-to-end encryption, and said that UI feedback for key changes will "confuse users."
A bad, and weak encryption scheme he wants. It's like the previous discredited idea: "let's put SSL/TLS everywhere, but trust self signed certs because otherwise we will confuse users"
It could certainly implement contact matching based on number pairs instead of just numbers, but I haven't reasoned through whether it could robustly (and efficiently I suppose) keep other parties from enumerating the number pairs.
Please do your research before putting this stuff out there in the future: it spreads unnecessary fear, uncertainty and doubt.
So asking the parent to “ do their research” isn’t helpful. And it isn’t FUD to treat an unknown system as insecure.
The gp comment literally just posted a link to a deprecated comment that painted MTProto 1 as (rightfully) insecure.
That was not thorough research and it attaches the FUD associated with an unused protocol to MTProto 2, which I'd again like to remind you and everyone, not a single security researcher or otherwise has found fault in.
We have to assume that all protocols are insecure by default. That is standard practice.
Only protocols which have withstood serious scrutiny and incentivized adversaries can be considered to have a level of security.
So if you want to claim MTProto 2 to be secure, it isn’t enough to say ‘it uses standard primitives’. It also isn’t enough to say ‘nobody has found any bugs yet’.
You need to demonstrate that received sufficient attention from motivated attackers before you can claim it is secure. That’s just how it is with crypto.
I don't need to demonstrate anything other than what I have already: when would we know a protocol has received significant attention from motivated hackers? I'll take a gander and say it's when that protocol is broken and is discovered by a security researcher or someone on the crisis response team.
I'm not claiming MTProto 2 is secure. Neither am I claiming Signal Protocol is secure. Undoubtedly both protocols have undiscovered vulnerabilities. I am directly refuting and admonishing a user for linking to a Stack Exchange comment that addresses a previous protocol with almost nothing in common to the present one.
I was responding to that, and only that, because it an invalid security argument, and irrelevant to the ‘admonishment’ of the other commenter.
The 100k bounty is a somewhat better argument. It would have been far more helpful to lead with that.
“You are welcome to develop your argument and point out where in MTProto 2 you find fault or why using standard crypto primitives isn't enough and what you'd like to see from MTProto 2 to secure it in your mind.”
The only person putting words in someone’s mouth is you - I never compared MTProto 2 to signal. You keep claiming that you never said MTProto 2 is more secure than signal. I never said you did.
The idea that being based on standard primitives is enough is a commonly held but dangerous piece of cryptographic reasoning.
Those are the words you put in my mouth. I don't trust MTProto 2. When did I say that I trusted MTProto 2?
This whole argument was me putting bad research to shame and then challenging another user not you to develop their argument.
But you wanted to back them up with something about concentrated efforts from serious adversaries which is an impossible argument to refute because neither of us has the insider knowledge to know what these protocols have endured and survived since only knowledge of their successful exploitation would be on the menu for public consumption.
So please, do bring something of greater meat to the table if you have something to share.
Enough for what? Sure looks like an assertion of trust.
Note that I’m not saying it isn’t trustworthy, just that your argument that using standard primitives is enough, is not a reason to trust it.
The contests are not remotely sufficient. Here's a good article:
https://www.cryptofails.com/post/70546720222/telegrams-crypt...
"I’ll repeat it again: If you want to show that a system is secure, give the adversary as much power as possible, and if they still can’t break it, the security is good."
Secure protocols take a lot of expert analysis to build consensus that they're worthwhile. That requires engaging with the community of researchers on their own terms and using established best practices.
Finally, Telegram's server code is still closed source and thus can't be reasonably audited. Could an attacker (or state actor) with server access decrypt stored messages? Maybe! That's why default e2e encryption with well-audited, open-source code is the gold standard...
> and thus I didn't (and still don't) think it worth my time to follow their changelog.
I strongly advise you not to comment on topics you don't find worth following. You directly harm a project that has done a lot of good (for protestors in Hong Kong, Belarus, and Russia) with your ignorance.
> Paying people rewards for finding security flaws is not the same as hiring your own analysts and testers. It’s a reasonable addition to a software security program, but no substitute.
Sounds like a reasonable addition to me!
As a result of this combination of constraint and desire, we get a bunch of comments where HNers talk about how they'd make Signal (as well as every other product) better/more useful.
[1] From Deborah Tannen's works
Last, phone numbers are general identifiers used in the search boxes of various data collection tools. Maybe you can search by the Threema ID as well, but that requires the tool to be a tiny bit more sophisticated, and that means the people who like to invade privacy of are a bit more frustrated.
That isn't "smartness signalling" or whatever, that's a real concern.
Please leave this social darwinism propaganda out of HN.
So I think it's unfair to bash people who criticise the project. The 'drag' they apply to wider adoption is still miniscule.
Put it this way: why does Signal exist when WhatsApp is good enough? Wouldn't Mr Rosenfeld be better putting all that effort and ingenuity into a truly innovative new messenger?
Signal allows chat backups but it's not the default option and the UX deliberately discourages this behaviour. They are also encrypted with a password which offers more security.
WhatsApp sends all your contacts to Facebook instead of the Signal Foundation, and unlike Signal, doesn't use SGX to keep Facebook from knowing what they are.
I kind of like Signal. It seems like an honest effort for a really great goal and the dedication as well as some of the things they have achieved seems seriously impressive!
As for WhatsApp, you realize that they upload all your chats to the cloud, unencrypted, easily retrievable by you and whoever you chat with, and that getting rid of them will take effort on both sides?
You are aware that Facebook probably use your metadata to feed their algorithms?
Edit: my point is that as engineers and technologists it is so easy to be blinded by tbe technical rick solid technical implementation if an (important) part and forget that security depends on all parts of the puzzle.
- End-to-end doesn't matter if the endpoints by default upload everything to cloud storage unencrypted. If it is going to end up unencrypted in Googles cloud you can just as well use gmail. That way you won't make your metadata accessible to Facebook at the same time.
- End-to-end only means so much when an adversary is running the routing: they cannot know the contents of your messages as they fly through their networks but if you don't trust Facebook, do you really want them to know who you talk to and when?
I also think there is some envy in it. Some people wish they had the same success and only can criticize in envy.
Fact is right now Signal is the only safe option for a messenger that hides your messages and other meta data.
The version I've heard is that taxi drivers are the ones who best know how to run a country. :)
They have built a tor/onion network and use it as the backend for their messenger (forked from signal). Its end to end encrypted and doesnt have centralised servers.
That's what I did initially for my kid on an android tablet, and always did for my data-only phone.
Sounds worse than buying a prepaid SIM if you ask me.
Matrix still has a high burden of me setting up my own server and maintaining it. Till their P2P solution doesnt release, they have their own metadata problem.
Ethereum: https://status.im/
Loki: https://getsession.org/
Gun: https://iris.to/
IPFS: https://berty.tech/
Also they announced that they will open source their client.
Disclosure: worked for them.
https://scuttlebutt.nz/ https://librelounge.org/episodes/episode-14-secure-scuttlebu...
* For the longest time, requires phone number as identifier. When asked to remove this restriction, the reply is "so we can bootstrap off the phone's native contact application". But Android and iOS contacts have natively supported e-mail addresses on contacts since forever? And those could be optional? Every time the conversation has gone this far with anyone involved in Signal, silence/ghosting.
* The whole PIN requirement debacle - where further amounts of metadata would be uploaded to Signal's servers (encrypted of course, with the PIN as passphrase of the key). Suddenly the app wouldn't start and users were locked out of all their Signal conversations (even reading them) without setting a PIN, no way to circumvent it. We were told this would be a strict requirement to be able to solve the above. After a lot of backlash they rolled it back after a week or so?
* Hostility towards alternative implementations.
* There's an open issue on GH for verified builds. Since 2015.
Signal may be good today. What about tomorrow? I think the only durable and realistic solution (because let's face it, pure P2P for the mainstream is not the latter) is federation.
Anyone feeling similarly should check out matrix.org. It may not be ready for the masses yet. But if we consider how we communicate in 5, 10, 20 years from now, it becomes obvious that we can't rely on a single actor as provider, regardless of how good they are today. The only way we get there is with people like the ones frequenting HN getting involved by using it, contributing, filing bugs, hosting home servers and using the clients.
Additionally I find concerning the choice to bet the farm on SGX which has been repeatedly broken with repeated opportunities to extract the keys, at which point cracking small numeric pins is trivial.
Moxie simply promised they always patch right away and never take the keys when they have such opportunities to do so.
I do believe him, today, but I don't believe he is above being threatened or coerced tomorrow or that he won't get replaced by someone that cooperates better with state powers as happened with VK and countless others.
I also took issue with Signal having central network metadata chokepoints his DCs or ISP could do timing heuristics on even if he does not.
I tried to engage with Moxie about these issues but he dismissed each as things we will mostly have to accept because he feels it is not possible to create and rapidly improve a privacy focused communication tool for the masses that isn't produced and controlled by a single large company.
Moxie is brilliant, and his contributions to cryptography and bringing education on privacy and end to end encryption to millions can't be overstated.
The problem is Moxie and Signal are struggling to engineer best efforts under an assumption they treat like a law of nature: No end to end end encrypted messaging platform can succeed without complete centralization.
I operate under a different assumption: No centralized platform will ever escape censorship and control by the government it operates under.
Moxie has said before he is happy to be proven wrong.
I hope as Matrix and others continue to prove him wrong with his own cryptography research that he comes around and rejoins the fight for a decentralized internet with irrevocable privacy.
Security is always about tradeoffs and compromises. A system that is very, very good, but not perfect and widely used is far preferable to a system that is perfect but used by no one.
[1]: I work around this by running Signal in a work profile with no contacts. So it's... kinda sorta optional, but in practice there are many caveats and complications that make it effectively not. Certainly not when we're claiming it for average users, which is Signal's argument for using it.
I think there’s a difference between what you’re saying, which seems to be that you personally don’t upload your contact metadata to Matrix, and what I asked / the previous commenter was describing, which is the idea that there are messaging platforms which have decided to not support storing this kind of metadata.
Notably, last I looked, Signal does allow users to opt out of SGX metadata storage, though the initial implementation didn’t cleanly allow for that.
What Signal does is 1) require your phone number, 2) automatically upload every phone number in your contacts, and 3) send a push notification to people on Signal that have uploaded your number in the past that you have joined.
It's a world of difference. And a huge breach of implied trust for multiple people I've known, who joined and immediately uninstalled when they found out a bunch of random people were notified.
But again, the point I made originally, and which you replied to, isn’t about what users may or may not do. It’s whether any messaging platforms have resolved to not store metadata, rather than attempting (as Signal has) to only store it securely.
We can debate whether people agree with Signal’s approach to the tech or the UX, but Matrix doesn’t bother; if you give them your metadata, they’re just storing it without any attempt at E2E encryption.
An entirely separate system exists to facilitate contact discovery. You have to explicitly choose to publish an identifier to it. You choose the server you want to publish to. You choose if, which, and when to query such servers. You choose what to query them with.
A server implementation can (in theory) support whatever arbitrary thing it wants to for an identifier. The fact that email addresses are commonly supported is already _significantly_ better than being forced to use a phone number.
Per the top recommendation from matrix.org, I downloaded the Elements app for iOS. When I opened it, the very first thing it did was ask me if it could access my contacts for sharing them with my (as yet unchosen?) identity server.
Then, I registered an account and clicked the “People” tab. I was immediately prompted to enable contact discovery, via a modal called “Contact Discovery”. It specifically calls out finding contacts by email and phone number. There was never an option presented to select my own identity server, or change what info is published.
If “contact discovery” isn’t part of the core offering, it certainly makes a great attempt to look like it is. The only choice I had available to me is to decline sharing my metadata, which is the same option Signal makes available for SGX.
I get that due to the magic of open source and federation, Matrix implementations could technically use random numbers or favorite colors or some other identifier, and I’m sure there are other less recommended clients which let me pick my own identity server or only share certain slices of data. But if we can’t agree that the flow recommended on the website is the one that the vast majority of users are going to follow, there’s not much room for a productive discussion.
You are looking at only a single implementation here. The point is that this is a set of federated protocols that has been specifically designed to provide freedom of implementation in this regard.
> But if we can’t agree that the flow recommended on the website is the one that the vast majority of users are going to follow, there’s not much room for a productive discussion.
I never claimed otherwise? We seem to be talking past each other.
You say you followed the top recommendation provided to you and that the end result was essentially equivalent to Signal. Since you appear to approve of how Signal handles things, that hardly seems like a complaint to me?
The key difference, of course, is that for Signal that's the only option. If the central authority changes it tomorrow, then tough. Matrix, on the other hand, provides you the freedom to select (or build, or patch, or whatever) a client that meets your needs. It's providing a superset of what Signal is offering.
My initial question, earlier up the chain, was in regards to this dilemma: Signal didn’t upload contact metadata to their servers for years, until they implemented SGX to allow them to do so securely. By contrast, every other messaging platform (Matrix included) just wrote up a spec for contact metadata storage that doesn’t address protections from the server operator.
We’ve got back and forth about the upsides of federation and open source clients and such, but as I’ve tried to point out, none of that is relevant to the actual question I asked, or the upstream point in the thread: that Signal’s spec didn’t include contact uploads at all until there was a way they could store them securely, and other message platforms just skipped straight to storing them.
In practice I have no way of preventing Signal from turning off SGX any time they feel like it because they aren't open and federated. They could push a software update and I'd be none the wiser until a security researcher noticed and pointed it out!
I guess it would be nice if Matrix integrated some sort of remote attestation support into the identity server protocol. Maybe they should have done so from the start, maybe not. At this point I don't see their offering as being less secure than Signal's though, just slightly different.
It's also worth noting that SGX (and AMD's competitive offering) has been broken an embarrassing number of times at this point. From my perspective, secure storage by the server is more or less orthogonal to any given spec or implementation. You either provide data to a server as cleartext or ciphertext. The server does with it what it will - you as the user have effectively no control over that.
Oh, and any/every device/client is a first-class citizen which means you can run it on more then one phone at the same time, or use it without a phone at all.
You can be: It isn't difficult to argue that signal overstates the security properties of their solution.
It's not an incoherent position to say that it's more important to be conservative (or at least accurate) about the claimed properties than it is to provide epsilon more security.
If it were the case that signal claimed that this metadata had no privacy towards them (and the hosts running their systems), but when you dig into the protocol or detailed tech docs you find that they're using SGX to minimize risk-- then I think there would be nothing to fault about the addition of SGX. In that case it would be purely additive security.
One can have metadata for sensitive internal corporate channels stay on a network they own in whatever country they want while still being able to chat with outside parties on matrix.org or other servers. Several friends host their own servers and more recently matrix p2p is rapidly maturing to dump the need for servers at all for many use cases.
Federated systems allow people like me to choose to host a server for my own family in my own home closet rack so data shared between my family and I never leave our network.
Still others can host matrix as a Tor hidden service where it will be very expensive to even learn who to target.
If all participants are using Tor and not using identifying information like a phone number, then bulk deanonymization becomes very expensive, particularly if many small highly targeted social circles roll their own.
Signal does not give users a choice but to trust one SPOF setup built under a one size fits all threat model that flows all IP metadata to one place which can leak information regardless of any encryption.
I don't want a world where one central party holds all communications metadata in one place under one legal jurisdiction with one proprietary memory isolation technology under one threat model.
Moxie here likes to point out that email demonstrates all the things that can go wrong with federated systems, but if had chosen the popular alternative of letting a single party take over this whole class of communication, we could all still be using AOL.
Internet messaging will outlive us all, and if we advocate everyone lock up their communications with one (even benevolent) dictator, it won't end well when the next dictator is not so benevolent.
See: pretty much every social network in China and Russia that is now under state control in spite of early promises of privacy by founders.
This is, granted, not as easy as it should be, but it is an issue the matrix team is working on improving.
You also don't need to use the identity service at all. It is totally optional for user discovery.
Third party implementations of the identity server already exist too.
Someone could even write their own replacement that uses SGX if they really wanted ;)
They either have your phone number and other contact details in their phone or they don't. They either make good decisions or they don't. You choose how much to trust them and what with. Federation and third party implementations of identity servers for one particular app changes absolutely none of that.
If you don't register your phone number or email address (which last I checked is not part of the default account creation flow) then it really makes no difference. I agree they should be federated (and they have been working on that among many other things) but it's not like every user's identity is centralised.
With a centralized approach like Signal, I have to trust one single provider, i.e. the Signal Foundation running the servers, with my (meta)data. Sure, in an ideal world I'd rather not trust anyone. Fair enough. With a federated network, however, I generally have to trust every single host that any of my contacts has decided to sign up with, as my metadata will necessarily leak to those hosts when I'm communicating with those contacts in question. And while I personally put in a lot of time and effort into making sure I only use software and internet platforms that protect my privacy as best as possible, most of my contacts don't. The NSA would have an easy time setting up a rogue host.
Now imagine that, in addition, there weren't just one single version of the Signal app, but dozens of forks by dozens of developers. The security risks would get even greater and I would now also have to make sure that my friends use the right (secure) version.
Am I the exception here? Does everyone here only have friends who are IT security experts and know how to tell apart trustworthy hosts and app developers from non-trustworthy ones?
On a side note, another reason why I no longer strongly believe in the idea of decentralization is the following: There was a CompSci paper a few years ago that argued that in any human-made (initially) decentralized network/graph (whether digital or analog; whether a graph of company relationships or mankind's social graph) there will eventually appear "supernodes" which have a disproportionally high number of edges/connections to other nodes. (In the same vain, even in federated networks like email, some hosts will become bigger than others and will eventually take over most of the users and traffic.) In short: There is no such thing as full decentralization. Nodes will necessarily "accumulate" and gather around local centers. (If anyone finds/knows that paper: Please let me know!)
I can see why, at first glance, this seems strictly worse because there are more entities to trust, but this is not a static system.
As an analogy, think about Facebook. Let's say that your friends all hate Facebook, but continue to use it, because for them the inconvenience and switching costs of moving to a different social network (perhaps one you are offering to host for them) is higher than the cost of continuing to use Facebook.
With a federated network, not only can you encourage (or demand) your friends to use a host that you approve of, but also, the very fact that people can move from one host to another (and there isn't a single basket containing all the eggs) means that these hosts are less likely to risk their reputation or be attacked in the first place.
> even in federated networks like email, some hosts will become bigger than others and will eventually take over most of the users and traffic
It seems you are arguing both that federated systems lead to there being too many nodes to trust, and also that in practice only a few big nodes will be trusted. I may be over-simplifying your points there, and I do think there are challenges with federated networks (particularly when federation is deliberately broken due to spamming/abuse/politics) but it's worth having a clear SWOT analysis here.
Anyway, my point, as before, is that a network coalescing around a few big nodes is not a problem as long as there is portability of accounts between them. I would rather trust 3 big providers who fear losing users to a more secure platform, than 1 monopolistic provider that's too big to fail.
I think it's worth explicitly spelling out that federation reduces the cost to switch hosts to near zero in many cases. There's no technical reason you can't use a different host on your end per contact in Matrix (for one to one messaging at least). It would be absurd, but you could do it provided that your client supported it.
If it's really needed, federation combined with open source software means that tooling can be adapted to facilitate your particular security and workflow requirements. (Not that you should need it generally, but the freedom is always there if you do.)
In theory, yes. In practice, however, it gets very complicated. (See e.g. Jabber.) You end up with a situation where only experts are able to set up a secure system for themselves, whereas the average user can't even accurately assess how well her/his privacy is currently protected.
It's analogous to open source vs proprietary software. End users shouldn't generally need to modify the software they use. Doing so isn't typically easy or straightforward for the vast majority of people. But if you ever need to do so, the option is there.
> ... I generally have to trust every single host that any of my contacts has decided to sign up with ...
In general, you should only have to trust a particular host with communications going to the specific contact that uses it.
> Am I the exception here? Does everyone here only have friends who are IT security experts ...
No, I think you're just looking at the problem the wrong way.
With a centralized model, you generally have to unconditionally trust the central authority.
A federated system offers much more flexibility. Metadata is likely to be spread piecemeal across multiple hosts and network paths, making it much more difficult for an adversary to analyze in the general case. Instead of a blanket trust decision, you make a per-contact decision based on the nature of the interaction you intend to have with them. If you feel the need, you can even self host and insist that a particular contact register with _your_ server to communicate with you.
If you absolutely can't trust someone to make good decisions with security critical information, it's unlikely Signal can do much to change the threat they pose to you in a real world scenario anyway. At the end of the day you're ultimately choosing how much trust to place in the person you're communicating with regardless of which system you use to do so.
> ... there will eventually appear "supernodes" which have a disproportionally high number of edges/connections to other nodes ...
That's certainly an interesting dynamic but it's hardly an argument against federation. Centralization is literally the worst case in that model (ie a single node and nothing else). In a federated network you have a choice of whether to make use of such supernodes. If it really matters, I can (for example) refuse to communicate with a particular contact regarding some sensitive topic via (say) gmail. A centralized system doesn't provide that option at all.
Signal's goal, however, is to protect the masses and, thus, society as a whole, by protecting as many people's privacy as possible. The things that are at stake here are not the data and the social graph of a handful of individuals, but the data and social graph of society as a whole. (I'm sure I don't have to mention the implications for democracy and social order.)
My perspective, therefore, was that of an average user. The reason I mentioned my personal situation and the fact that I myself spend quite a bit of time on making sure my systems are safe, was to emphasize that if the situation is already overly complicated for me, it will be much worse for the average user.
> In general, you should only have to trust a particular host with communications going to the specific contact that uses it.
I don't think the word "only" is appropriate here. Let's say John Doe has roughly ~1000 contacts. This means that, in the worst case, he would have to research ~1000 hosts and their privacy policies. Now the "accumulation effect" I mentioned previously will reduce that number quite a bit but there are still going to be dozens of different hosts. I doubt we could expect John to look into each and everyone of them before he gets in touch with his contacts. (Note that this gets even worse when people can freely switch between hosts, as suggested e.g. by other replies to my comment, as John will then have to repeatedly do the checking.) Therefore, I think it is reasonable to expect that a significant number (millions, if not billions) of users will end up residing on insecure and untrustworthy hosts and their social graph and metadata – and possibly even their data (see below) – won't be protected at all.
> With a centralized model, you generally have to unconditionally trust the central authority.
In the federated model, John has to do that, too. Sure, he can self-host but how many people are actually going to do that? Put differently, the vast majority of all acts of communication in the network is going to get routed not through self-hosted nodes but through the servers of providers whose trustworthiness is at least questionable. I hope you will agree that, for society as a whole, this exacerbates the trust problem you mentioned.
> A federated system offers much more flexibility. Metadata is likely to be spread piecemeal across multiple hosts and network paths, making it much more difficult for an adversary to analyze in the general case.
A federated system also makes it much easier for adversaries to enter the game, as they don't have to compromise a well-known provider like Signal that is under the close scrutiny of the public. Instead, they can just create new hosts (just like they do in the case of the Tor network). What's worse, in this case they won't just be able to access their user's social graphs but very likely also the content of their messages, as the key discovery problem is usually solved by hosts distributing their users' public keys.
> Signal's goal, however, is to protect the masses and, thus, society as a whole, by protecting as many people's privacy as possible.
Sure, by positioning themselves as the only node, which you are then forced to trust. That hardly seems like an acceptable solution to me.
The chance of a given mainstream node being actively malicious seems unlikely to me. Maybe that's misguided, but at least (as you point out) there will be relatively few big ones to research. Non-mainstream nodes don't pose a significant threat by virtue of having little to no use (and so seeing little to none of your traffic and contact graph).
> ... the vast majority of all acts of communication in the network is going to get routed not through self-hosted nodes ... I hope you will agree that, for society as a whole, this exacerbates the trust problem you mentioned.
Actually, it seems to diminish the problem to me. Instead of everything going through one central authority it's now being split across multiple actors. No single entity has access to the complete picture anymore. Moreover, you as the user have the freedom to avoid such supernodes if you feel the need. Yes, that will likely introduce usability hurdles, but at least you have the freedom to do so (as compared to a strictly centralized model).
> Instead, they can just create new hosts (just like they do in the case of the Tor network).
Doesn't this attack model fail to account for how users go about selecting and using servers? If I join the Mozilla instance to chat with them, that wasn't an arbitrary choice - I selected the instance that the organization I want to communicate with is using. So the other party, which I'm going to communicate with one way or another, is the real threat here.
As far as MITM attacks go, that scenario seems to get a bit out into the weeds cryptographically. I'm not sure how viable a large scale attack would be here - presumably at some point odd traffic patterns would become noticeable? And you still have the issue of a malicious node that actively attacks all traffic needing to somehow manage to grow its user base to a significant degree.
The initial $50M in funding was a loan, not a donation, from Brian Acton to the new nonprofit Signal Technology Foundation. By the end of 2018, the loan had increased to $105,000,400, which is due to be repaid on February 28, 2068. The loan is unsecured and at 0% interest.[5]
The Foundation is completely controlled by Brian Acton, who is the sole "member" of the nonprofit, with the right to appoint or remove every member of the Board of Directors. The Board consists of Acton and Marlinspike. Acton is also the President.[5]
https://en.wikipedia.org/wiki/Mitch_Kapor
I would be very disappointed if I found out that Acton had any hidden motivations behind his philanthropic support.
It doesn't seem unusual to have a single member nonprofit. However, is it a usual thing to loan to your own nonprofit foundation at 0%? Without a plan to generate positive cashflow into the foundation, would he forgive this loan to offset future taxes?
Genuinely curious.
A secure messenger product nobody uses helps nobody's security.
For example, for years we asked for a simple mechanism which could be used to view a users key and mark it as identified, to prevent MITM -- even one buried in a menu for advanced users (who could at least act as canaries against widespread interception). Not only was the request turned down but usually responded to with vigorous personal attacks against the requesters.
Subsequently once a fingerprint validation method was added it was gratuitously bound to be pair-wise, making it largely unusuable -- e.g. post a pgp signed signal fingerprint that any of your contacts could use to transfer trust from an existing key. Requests for a non-pairwise version, even as just some advanced thing that grandma never sees ... again, hostility.
The constant logic-bombed auto-expiring software that make signal effectively open-source-in-name-only. etc.
I think signal is fine as an insecure messanger: Unencrypted communications protocols should have no place in on the internet today. But to advance it as a security tool almost certainly puts people's lives and freedom at risk.
Common usage of signal has zero security against MITM: users aren't effectively notified that the contacts keys have changed-- and given how often users lose/wipe phones perhaps that's really the best that can be done for normy friendly software.
If that's how it is, that's how it is. Some resistance against passive monitoring is still a critical upgrade. But don't call it secure: if you do people will do and say things using it that they wouldn't otherwise.
In spite of the many issues to complain about signal it's still a lot better than what $random_person would likely use otherwise.
Do we do the most good for the world by under-representing signal's weaknesses and overstating its security in order to maximize the people using it over choices that are worse and cheerlead its development, or do we do the most good by trying to be frank and being critical of its limitations (at least some of which are pretty nitpicky), potentially at the expense of the discussion causing people to continue using clearly worse alternatives?
Personally I answer this conflict like this: Outside of a techy venue I don't go into any details about signal's limitations-- I tell people they should use it, but don't assume it keeps them private from governments, google, or other powerful parties.
Can you provide more details on that? I’ve been using signal for years and often get key change notices.
And even there, if I send a message to you and on receipt the software finds that your key has changed, my client sends it again to the new key. Which means that even if I was savvy enough to catch the message, it's tool late and potentially a critical secret has already been disclosed to a MITM by the time I see it.
By far the biggest complaint I read about Signal is "It uses phone numbers, and I don't like that". While I agree that I'd prefer to be able to make up my own unique/random identifier, there's absolutely no doubt in my mind that the downside of phone numbers was far far outweighed by the benefits of usability. Most of my friends use Signal, I seriously doubt I'd have been able to help make that come true if the contact discovery features - along with their side channel privacy leaks - didn't work as well as they do. In retrospect, if I were trying to kickstart a global-scale network of secure messenger users - I'd make exactly the same choice today as Moxie did back then.
> users aren't effectively notified that the contacts keys have changed
That's just not true. Its become a running joke amongst my friends that Signal Safety Numbers changing is how we know when people broke or upgraded their phones.
On Apple this is less true, but it is also a centralized black box that grants you no freedom, and apps can be banned at any time with little recourse.
You could use something other than Android like PostmarketOS or Librem5 however odds are Signal won't create clients for those platforms considering Moxie has stated publicly he prefers distribution through proprietary channels in order to collect usage stats. Moxie has also stated he will actively fight any third party clients that try to join his network, so we won't likely see many of those attempted for alternative platforms either.
Fortunately this seems to be going away.
For those not aware as to what you're talking about, this is the proprietary 'rootkit' providers like Sprint had to use to activate CDMA modems on their carriers on many of their devices that did not come with a CSIM. As it's doing a lot with the phone's modem, it needs tons of permissions on the device. Verizon Wireless and Google Fi also had similar apk's that were required to provision phones and update PRL (prority roaming list) information.
In the US all modern devices on Verizon are CDMA-less and new Sprint customers are usually activated on T-Mobile network (with fallback to GSM/WCDMA not CDMA).
Whether or not Google respects it is not clear, but it does show a little incognito mode icon on the keyboard.
This is with the default Google keyboard (gboard), your mileage may vary with other keyboards.
They do disable personalized text prediction. You are just misleading readers.
Is there a setting somewhere that needs to be flipped to opt into this behavior?
EDIT: Yep, there is a setting in Signal for "Incognito Keyboard", I've never toggled it, and it was off when I went to settings.
Seemingly other sloppy typos like "Signal could only proffer the relevant".
No critique against the substance of the article though, seems great so far, love Moxie.
Edit: And the date in the URL is October 26.
See https://en.wikipedia.org/wiki/Diaeresis_%28diacritic%29#Engl...
"proffer" is also a perfectly legitimate word: https://www.merriam-webster.com/dictionary/proffer
Also, I don’t see any spelling mistakes in the sentence you mention...
> Marlinspike is the C.E.O. of Signal, the end-to-end encrypted messaging service, which he launched in 2014; he is also a cryptographer, a hacker, a shipwright, and a licensed mariner.
What's all the hype about Signal? It's a bad application.
Let's see. Install it. Oh, it starts with a screen about Terms and confidentiality. But... why does Signal get me to agree to things if it's so much about privacy? Are they... reading our chats?
OK, next. Oh, it needs access to Contacts and Media to improve communications. Right -- because nothing like that sweet social graph. But I can skip this one.
Oh, now it wants my phone number!
Experiment complete. Let's uninstall this app.
I fail to see how this is any better than Whatsapp.