I don't think better email will help with the problems described in this essay. Two of the big problems the essay claims are forever archives and ease of forwarding to regular, non-encrypted email. From what I know of darkmail, it is not going to help with either of those.
Text Secure/The Signal Protocol the author praises was basically the SMS equivalent of PGP/what they spend the first half of the article bashing from all sides. Even in 2021 while it has switched from SMS transport for the encrypted streams (mostly because it's just a shit transport that cost users more money than data at that point anyways) it still allows comingling and sending messages as plain SMS instead of over the encrypted channel. If used properly Signal solves one or two of the main points listed but is just as guilty in the other half. It's also been found to be imperfect over time even though it hasn't been around as long as PGP.
Pretty sure I have never seen this behavior in Signal or any of my group chats in Signal. At least the way me and my peer groups use Signal this simply isn’t possible as far as I can tell.
"Very few people use signal like that" makes me think you first tried Signal within the last ~year. Why do you think it was originally "TextSecure" and why do you think it, to this day, uses phone numbers as the identity mechanism instead of usernames? It's because it allows it to automatically know when it can upgrade from sending SMS to that contact to sending encrypted messages. And as I originally explained just around the time the mentioned award for the protocol was given (2017) it was still sending the encrypted messages over SMS instead of data.
Plenty of people still use it this way on Android though. I'd say about half my Signal contacts do. I don't but that's because I use Google Voice a lot for texting (mostly as an easy way to receive 2 factor codes for work not actual messaging with anyone) and Signal only replaces the local SMS app.
Then either it's much older than you thought when you installed it or you've since forgot it used to be SMS only when it originally released. It wasn't even until late 2015 (i.e. post rename) Signal stopped using SMS for encrypted chats let alone those using it for mixed chat support.
"You can’t hide secrets from the future with math. You can try, but I bet that in the future they laugh at the half-assed schemes and algorithms amassed to enforce cryptographs in the past"
I think it also argues against commercial encrypted email.
But any complex enough system, you want it to run by folks with some expertise. Greater chance to have providers hire capable people than you being one (simply matter of size)
This is a great article and I agree with the overall premise and ~90% of the individual points made.
But.
> If messages can be sent in plaintext, they will be sent in plaintext.
This format is such a common line of attack in critiques of technology that I think it needs a new logical fallacy coined to describe it. I've seen it used as the primary basis for entire "x considered harmful" essays (thankfully not the case here as the rest of the bullet points more than hold up without it).
The idea that many people will use technology wrong is not an argument in itself against that technology. It's essentially an argument against UX, which is important (especially in the case of security) but while a false sense of security is much worse than no security, that doesn't justify advocating against correct application of that technology (or against efforts to improve the UX of said tech).
As mentioned the point here is moot given encrypted email's other larger failings, but without them this point simply wouldn't stand.
> that many people will use technology wrong is not an argument in itself against that technology
Author makes this argument best when they say PGP leaves emails "at the mercy of the least secure person they’ve sent them to."
You can have the best UX gating your PGP emails. But if you send them to me, and I have the option of replying on plaintext, there is a non-zero chance that I will eventually respond in plaintext. The blast radius of that compromise is the entire message thread. If what you're communicating about requires actual security, that is an unacceptable risk. If what you're communicating about doesn't, it's fine. Herego, it's a bad solution for secure messaging.
I think the serious issue around this would be not so much that a person in a secure email conversation can easily send a plaintext email, but that a person who does that could also easily include a plaintext copy of the entire rest of the formerly-secure conversation through automatic quotation.
I’m increasingly confident there’s a campaign in progress to persuade abandoning standards the NSA can’t crack and migrate us into projects using algorithms with built in backdoors. RSA is not cracked and PGP works fine.
PGP has been the target of everyone's ire for years and years, yet since we're still talking about it, I guess it works.
Every thread that mentions PGP will eventually devolve into a discussion about how it's a foot gun and mere mortals will blow themselves up with it...
... but it works.
Seriously though, I remember discussions in the mid to late 90s about UI/UX difficulties and about how every single person that doesn't understand the operation perfectly IS going to be black-bagged by their local black-ops group; the same discussions that pop up in every PGP thread.
It's like one of the oldest running jokes in CS at this point -- not that PGP is broken and failed but that it attracts tons of individuals to congregate and be upset en masse about the UX.
> doesn't understand the operation perfectly IS going to be black-bagged by their local black-ops group
More likely, they simply aren't noteworthy targets. If you rely on PGP to secure your emails, those emails will probably end up not actually secured, but you won't notice because your emails aren't valuable anyways and are probably secured by other stuff, like TLS, and Google's server security.
I think it would make more sense to point to the Matrix protocol instead of Signal.
Matrix is actually decentralized like Email, allows any service provider as well as app provider - free to choose as a user.
It supports Perfect Forward Secrecy (based on the Signal Protocol), arbitrary many devices and "one verification for each individual".
Well, you might argue Matrix stores meta data server side (the ones chosen), while Signal at least doesn't have to.
But do you really want to give up all that freedom trusting a single service provider in that really no data is kept?
Maybe you can wait until Matrix allows you to avoid signing up on a server using P2P[0], then you have got it all, and don't have to commit to an alternative that has advantages, but also big draw backs.
XMPP is good, great even, but it has the same issue as email where you could interface with someone not using OMEMO or whatever your encryption scheme is and it would fall back to plaintext.
The story is not quite the same for XMPP. For example, with XMPP you can determine ahead of time whether or not a contact has OMEMO. And clients configured to only use OMEMO won't "fall back".
The fallback has to be client dependent. With E2EE the server can't decrypt messages. So there's no way for the server to decrypt the message to "downgrade" the channel. The client is also the node responsible for encrypting all messages for all recipients so it has to know if any of those recipients haven't done a key exchange.
Yes. It's client-dependent for all other systems too. For example Signal's end-to-end encryption only works if both parties are using Signal.
For XMPP the difference is that there are multiple E2EE clients to choose from (see https://omemo.top/ ). And if someone chooses to use a none E2EE client, you still have the choice whether to communicate with them without E2EE, if that's acceptable to you in the specific context (not all conversations demand E2EE).
Roster/conversation capability (server holding message until recipient comes online) is a basic extension to XMPP. I don't think I've ever used a Jabber server not supporting it, and all the popular clients support it.
Yes. Same thing, same feature. This is what "conversation" mode is, also known as message archive management, or XEP-0313 (a standardized extension/feature of XMPP).
I love the idea behind Matrix and dearly want it to succeed, but unlike IRC and XMPP as well as (to a lesser extent) email and netnews, it has the inherent problem that it implements a genuinely difficult thing: a large partition-tolerant distributed database without a central authority and even a bit of mistrust between nodes. Now that I’ve put this in writing, I wonder if there were any attempts to do this at all before the current generation of systems. (IRC and netnews basically YOLO their consistency away because they can’t afford it, which was indeed correct when they were designed, but people did a lot of distributed systems work between then and now...) That implies that a Matrix server is necessarily somewhat heavy and rather difficult to implement.
This makes me think that the federated network must by necessity exist in a fragile and tender state while Matrix is young, and need to be tended to with attention and care. The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. (To put it uncharitably: Look, there are now a whole two comprehensive server implementations, and the second one you could even afford a server for! Yeah, the Gnome people gave up on independently implementing a secure client, but surely an Electron one should be enough?..)
I’ve spent a very limited time studying the situation so I am not going to make any dire-sounding prophecies; besides, I actively don’t want any such prophecies to come true. What I am is worried. It doesn’t take much for a protocol to become a non-interoperable tangle of implementation details, and Matrix is an extraordinarily ambitious one.
I agree that Matrix is quite complicated. However, adding new features doesn't have to make it that more complicated. I get the impression that it's not that bad as most new features are actually based on existing parts of the protocol. Everything is just based on events in a room. Most 'special' events have a fallback mechanism to text, to insure clients that haven't implemented the event type can still show the information to the user. Replies and stickers make use of this for instance.
My point is not that Matrix is complicated, thus we should avoid making it more so. My point is that the approach that Matrix chooses, even in its most minimal form, requires Matrix to be complex and resource-hungry, thus it seems prudent to direct attention and effort towards cultivating a multitude of implementations and deployments rather than enhancing marketability.
A social argument against features, not the standard technical one.
> The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach.
We are in agreement as to which part you were replying to, then :)
> I don't agree the growing features is an issue.
And I’m not arguing that it’s an issue in itself, either. I’m arguing that it is an issue when allocated development effort in preference to growing an ecosystem, because Matrix is both (inherently) bound to have an difficult time at it and (factually) not in a good place right now from that point of view. And that is my perception of the protocol developers’ priorities.
(Once there are a half-dozen independent server implementations and a decent number of clients, all with reasonably complete coverage of the current spec, this argument becomes irrelevant, so I’m not pleading featuritis here.)
Ouch, I wanted to reference to its state “a couple of months ago” when I looked at it, but looks like it has been half a year at least. My calendar is completely out of order it seems.
In any case, it’s encouraging to hear that the development (well... rewrite) is proceeding along and E2EE is once more on the roadmap. But my point still stands, partly, because the developers have given up on implementing the protocol on their own, see e.g. https://gitlab.gnome.org/GNOME/fractal/-/commit/6bcb5e9 (announcement of switch to matrix.org SDK).
> This makes me think that the federated network must by necessity exist in a fragile and tender state while Matrix is young, and need to be tended to with attention and care. The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. (To put it uncharitably: Look, there are now a whole two comprehensive server implementations, and the second one you could even afford a server for! Yeah, the Gnome people gave up on independently implementing a secure client, but surely an Electron one should be enough?..)
It's one thing to be uncharitable; it's another thing to be spouting stuff which is demonstrably false.
There are three usable server implementations participating in the network; synapse, dendrite and conduit (four, if you include construct). Synapse runs fine on a VPS with 2-4GB of RAM for almost all personal usage patterns, so snark about "servers you can afford" is BS. In addition to that we reduced its RAM footprint by 2-3x over the last few months (https://twitter.com/matrixdotorg/status/1434912387933560837).
The GNOME Fractal team hasn't given up at all - they just chose to rewrite the app for Gtk4, shifted to using matrix-rust-sdk in order to focus on the GUI layer and have been busier than ever. Meanwhile, there are tens of other implementations - a non-exhaustive list of the clients and SDKs today implementing E2EE is:
I wrote this article. Honestly, I don't care which secure messenger you use. I'm going to recommend the one I feel is safest, but they're all leagues better than email. Don't use encrypted email; that's the point of the article, not "use Signal".
emphatically: no. the solution to things that are broken and hard is not to abandon them like a petulent child out of frustration.
defeatist bullshit from the article:
>Every long term secret will eventually leak.
is not a valid excuse for abandoning PGP or encrypted email, its wishful thinking at best.
>The standard and best answer here is Signal
Signals github releases are sporadic at best and hard to compile consistently. its also centralized and has a dependency on google services to operate and lacks real transparency about its outages or plans to scale/operate, but at least its not too hard for you.
>Hop-by-hop encryption is a good thing: it makes untargeted dragnet surveillance harder.
the devices that handle this mail are commercial MTAs and are already largely backdoored by three letter agencies. a poison prime here, a weak cipher there, or even an opportune warrantless surveillance national security letter can sidestep this easily. companies will bend to the rule of US law.
>PGP don’t make this kind of surveillance any harder, and a targeted attacker will still get access to mail servers and messages.
this is a tangible, almost white-hot ignorance i cant abide. yes. youll get a PGP message. that message is encrypted with an asymmetric key and with a strong passphrase will have your adversary guessing until the last star falls from the heavens* and the statute of limitations for what was once your proud nation finally expire. PGP was invented to secure things that were transmitted IN PLAINTEXT.
trust was sacrosanct as you were expected to verify and know the person to which you were sending...you had keysigning parties and you used PGP to talk about important things with people you trusted. PGP is still valid and useful to this day.
* quantum computing may make this easier, but if it does, post-quantum ciphers are still an option
> the solution to things that are broken and hard is not to abandon them like a petulent child out of frustration.
Are we trying to enable secure E2E encrypted messages, or are we trying to enable secure E2E email? Because those are two different goals.
If we're worried about fixing unencrypted messages, then I think it's completely valid to look at systems like Email and SMS and to say that they're just not suitable for secure conversations, and to advise people to move to other platforms/protocols for secure communication that doesn't have their flaws.
Signal is currently a good solution for a lot of people. That doesn't mean it doesn't have problems, but it has great encryption that is almost impossible for an ordinary user to accidentally mis-configure. Matrix is also coming into its own as a good solution, and while I don't necessarily recommend Matrix over Signal if encryption is absolutely important, it is very likely going to be a better solution in the future, and for casual encryption is a pretty good solution today.
Both Matrix and Signal are easier to use than PGP for ordinary users. They are both (frankly) more reliable even for advanced users. And with the amount of effort we could put into fixing PGP-encrypted emails, we could also make a platform like Matrix really good and push really hard for its adoption. Getting people to adopt Matrix is going to be easier than getting people to adopt encrypted emails. Incidentally Matrix also improves upon a number of other centralization and protocol problems with email as well, but we're focusing specifically on encryption here.
Sometimes working to a specific goal (encrypting plaintext communication) means recognizing when a strategy is bad, and pivoting to another strategy that's more pragmatic but that accomplishes the same goals. For example, I'm not going to waste time trying to "fix" SMS security for 2FA when I can tell people to install an Open Source 2FA app instead -- because the goal isn't to make email safe, and the goal isn't to make SMS safe, the goal is to make people safe. Broadening out our strategies and building cleaner, more fundamentally secure technologies is part of that.
I think you're both right. Email is subpar as a protocol for sending secure messages (what you said) and should therefore be abandoned as a protocol in favor of something better, and also many of the specific arguments made in the article are quite weak (what they said).
E.g. PGP doesn't make dragnet surveillance harder?? Unless you assume that point-to-point encryption makes it entirely impossible (wrong), PGP clearly makes it much harder for anyone to read your message.
Browsers also expect plain-text. Is https by the same logic also pointless, and should no longer be used?
(I get what the author is trying to say, I'm just reacting to the strange way the argument is phrased. I don't think they thought their wording and reasoning in that passage through enough.)
> Browsers also expect plain-text. Is https by the same logic also pointless, and should no longer be used?
> I'm just reacting to the strange way the argument is phrased.
It's made so in a manner to provoke a lot of loud noises to make it to spread, and resonate across the blogosphere more than the original lacking substance message ever could. A publicity stunt.
It's a self-promotion tactic - saying something outrageous often earns more notoriety for somebody unable to earn fame through virtue.
And HTTP has solved this with a hodgepodge of solutions like HSTS + preloading for producers and HTTPs everywhere/new browser settings for users but it has taken years.
I think email could do this, but it require some dominant players (probably Google + Microsoft as providers for home + business users, or maybe Google/Apple/MS as dominant client producers) to participate actively.
That's not the same logic because http is not a messaging protocol and it took many years to get to something resembling 'https by default'. Still, not being a messaging protocol https and browsers alone are not much better at exchanging end-to-end encrypted messages than plaintext since an https server sees plaintext content.
> Browsers also expect plain-text. Is https by the same logic also pointless, and should no longer be used?
> (I get what the author is trying to say, I'm just reacting to the strange way the argument is phrased. I don't think they thought their wording and reasoning in that passage through enough.)
Your question explicitely ignores the argument that was made and pretends a point to point protocol operates similarly to a store and forward protocol.
That's disingenous. I quoted the entire part within parenthesis, and pointed out what part of the stated argument from the article was being ignored.
The issue is not that email or browsers can be configured to accept plain-text. What you incorrectly equate is two different protocol mechanisms, but you are focusing on the types of traffic.
one big difference between email and the systems that the author suggests is that email is a standard and a protocol, where the systems referenced by the author are pretty much single implementation systems maintained by a single authority.
some of these authorities have all sorts of structure to prevent corruption. passionate people, nonprofit or open governance. however, they are still single points of failure, or targets, or whatever you'd like to call them.
it seems that after years of pain with poor effectiveness of specification or poor verification tools for implementations, it has become en vogue for modern cryptosystems to insist on tight centralized control of reference implementations to ensure correctness. (otherwise known as the apple computer model). while this does seem to work in terms of ensuring high quality and problem free implementations, it does open up the single point of failure issue.
i'd argue that email's replacement must retain email's greatest quality: it's an open specification, not a system or implementation owned or controlled by a single entity and that the true challenge in bringing it to fruition won't be clever protocol and cryptographic design (although these will be crucial) but also substantial advances in protocol definition and implementation verification such that any competent developer can implement compatible components and plug them in.
I agree entirely. Now help me understand something… why have signal and telegram and everyone made proprietary formats and centralized implementations instead of an open email2.0 that they also support immediately?
It clearly is harder to innovate in a federated system. Look at what happened with Matrix, and how much time passed between them standardizing E2E encryption and getting E2E encryption universally deployed (I think that switch just flipped last year?). Not everything Moxie Marlinspike writes is correct, but he's been pretty well vindicated on that.
I missed this, very interesting read. He's not entirely wrong.
But why are these protocols frozen? I've never developed one so I may just be ignorant of the challenges there, but if, for example, I wanted the XMPP protocol to be able to work with rich media, what's stopping me from updating said protocol to work with rich media instead of relying on optional extensions? In my mind, users of the protocol will receive the update (if they choose of course), thereby making the feature a default for the protocol that isn't reliant on extensions.
I admit I don't fully understand why protocols are frozen in this way, even though I agree with the author that the ones we currently have are definitely frozen. Any insights appreciated!
Your point about optional extensions vs a protocol update isn't really as clear-cut as people think it is. To add a non-optional change to an open protocol in a decentralized network would necessitate blocking people from the network when you roll it out. That's not going to make for a good communication network.
The alternative is what XMPP does. The protocol evolves by adding new extensions, and deprecating old ones. Each extension generally has fallback considerations.
For example when group/offline media sharing was added many years ago, it was designed such that clients implementing the extension could render the media. Older clients, or clients that can't render media (e.g. terminal clients) simply display a URL.
The XMPP Standards Foundation annually publishes its "compliance suites", which (versioned by year) guides implementations on what they need to support. https://xmpp.org/about/compliance-suites.html
Decentralized networks can certainly move. They may not usually move as fast as a centralized one can, but that does not make reliance on a central entity a good alternative.
Okay, but Moxie has actually produced a secure and usable messaging system, based on his stance. Have any of the people who disagree with him gone ahead and produced something that proves their viewpoint?
Cynically, because they are companies trying to turn a profit.
Also many (most?) of the complaints raised in the article will be an issue for any federated system. The article is arguing against end user control and decentralization. It just isn't upfront about it.
That doesn’t mean they don’t make money, pay salaries, pay grants, accept grants, invest, etc. They are allowed operating reserves, pay taxes, etc. People seem to think non-profit means no money collected, that’s incorrect.
It is also within Signal’s interest that the remain competitive and achieve market success.
They are referring to https://efail.de/ - works on both PGP and S/MIME, which was disclosed just over a year before the article was published. The article references this in a link to another post a few sentences before the one you quoted.
Processing PGP messages where correctly signed MAC doesn't match the ciphertext should not be an option at all. Message was tapered with, so MUAs have no business processing it.
So unless the attacker can also produce the correct MAC matching the ciphertext, which should not be possible with out knowing a private key, I don't see how this can't be easily fixed just by checking the ciphertext against the MAC.
Minor quibble, OpenPGP uses an authentication method called the modification detection code (MDC). It's kind of a checksum that is protected by the overlaying encryption. Very simple. It turned out to be more secure than anticipated and as a result is still in use.
The issue with encrypted email a-la PGP even beyond security issues is the laughably bad UX. I'm not going to be able to convince people to adopt the best practices involved in maintaining keys and using them to encrypt and decrypt the mail they send. Whether that is good or bad is immaterial- the cat is out of the bag and people are already used to the convenience of insecure incumbents.
For messaging, we need something that is end to end encrypted by default, and is also only available in an e2ee format. Decentralization is an additional bonus, but really as long as the protocols are heavily audited and the clients are reasonably open (reproducible builds etc), it doesn't matter what your choice is and what networks your messages go through/who controls them.
Could Signal ever do an email service? I’d switch to it in a second. I realize I’d be sending it to insecure addresses but at least my end wouldn’t spy on me? I just realized how dystopian that sentence is.
even if they do, you have to maintain compatibility with "other" popular email providers. Protonmail encrypts all it's emails among it's own users. But at the end me with my gmail can't read them without jumping through hoops.
Thing with email is that you'd also have to get everyone you talk to to move to it and ensure they don't fall back to any of the services they have been using for all this time for convenience's sake. At which point, it doesn't even matter if it is email behind the scenes or something else.
There's also the issue of SMTP being very metadata heavy and there being no option to mitigate or encrypt any of the metadata. Which is why something like Delta Chat (if you haven't heard of it, it's basically Signal/WhatsApp like IM piggybacking over email) isn't very private.
The guerilla growth marketers working for Signal would probably be unable to resist the viral temptation of spamming all your email address list who have already joined signal to "let them know" about your newly installed contact channel.
I was super-annoyed when two people from my distant past started trying to contact me via Signal purely because of the unwanted and un-asked for behaviour of vacuum-and-spam notification of my phone contact list (which had accumulated from before 2000) who were in the subset of already-Signal-members.
In particular one huckster I lost $22k to, and who I came close to being liable for taking illegal action on behalf, through his fraudulent lack of full disclosure, who I had thoroughly removed from all my social media, plus filtered his email straight to trash, and permanently blocked from calling my phone.
Because his phone number was in my address book (so I could block him) Signal thought it had the right to let him know he can now contact me.
The mere fact that you had a phone number in your address book is what made your locally client-side Signal app made the notification… locally.
This newly discovered mechanism does not alert the remote Signal app.
Just the mere fact that you allowed Signal app access to your local address book and actually ran all numbers against the central server is not clearly stated in their type of service (TOS).
This is the primary reason why i never let Signal app have access to my Contacts/address-book.
This is why we have no idea what else Signal is doing with remote phone numbers found in our address book. I was able to ascertain between two phones of this one-sided aspect (but for how long)?
I expect any app or service to at least warn me first before they instigate unsolicited actions on my behalf.
Signal has no doubt already legally covered their ass with regards to me giving this consent.
However in reality I never would have allowed this if I was asked or even given a fraction of a hint as to what was about to happen once I gave them the requested permissions to be installed.
One of the things I quite enjoy about the legal system in Quebec is our strong consumer protection laws. Additionally it is not possible for a consumer to “wave” any rights provided in our consumer protection act.
That along with numerous parts of the law defining exactly what can be a binding contract create a system (with ample case law and precedent to back it up) where most company’s terms and conditions are not valid contracts in Quebec.
If someone here were able to show harm and have standing in a case they would likely be able to bring a solid case forward.
They didn't take "unsolicited actions on [your] behalf" to drive this feature.
The other person's phone looked at their address book and asked if it can reach you over Signal, which it can. It chooses to do this (it's a config option, on their phone).
The "unsolicited action on your behalf" is that given access to your contacts your phone will provide your contacts with some information over Signal, such as a Signal name and profile picture you've set - if they ask for it, unless you've blocked them. So if you set your name in Signal to "Barry is God" as a joke, that might be awkward if your very religious parents get Signal, but then that's also probably true if the name outside your dorm says "Barry is God" or if that's what the name says next to your apartment buzzer or on Facebook...
Likewise if the profile photo is of a marijuana leaf which was funny for two close friends on Signal but then your very straight boss gets Signal and they know your phone number...
Signal doesn't want to be another niche app that you only use to send encryption nerd stuff to other nerds who also installed the nerd app. It wants to be for everybody for everything, because there is safety in numbers. If there are six encrypted messages sent in Iran, the secret police really could just track down, arrest and torture everybody who sent or received an encrypted message just in case. But if it's six million messages that's just not practical.
Mere fact that Apple Contact address book can leak your contact name that was extracted by Signal and ran checks against Signal for “in-Signal-network” flag or not
It’s not just about the avatar but your name too. now being tied to your phone number.
> Because his phone number was in my address book (so I could block him) Signal thought it had the right to let him know he can now contact me.
Nope. Because your number was in his address book, his device periodically asks Signal "Hey, can I use Signal to message this contact?" and once you use Signal it says "Yes". The fact he's in your contacts means, by default, your phone thinks you know each other and it should provide information like your preferred name and photo if asked. Of course if you've got the number in there "so I could block him" you should... block him. In Signal too. Having blocked him, your phone won't provide your information and he can't contact you on Signal.
Under the hood if you do this, your phone ignores Signal messages from this number but it also mints fresh "postage stamps" for Signal's anonymous sender capability, it won't give the new ones to the newly blocked person and the old ones no longer work, so your actual friends can get new stamps and send you messages without even Signal being able to tell who sent them, but blocked people can't waste the service's time sending messages you won't even see.
This capability is necessary for Signal to function as something more than a fun "secret decoder ring" for a small circle of nerds. Without it for example, the ex-colleague I suddenly needed to contact a month ago wouldn't have been reached over Signal, he had no reason to tell me, a person he rarely talks to, that he's got Signal since we last met, but since his phone does have Signal, and my phone checked my contact list, it knew that Signal would work and it transparently used Signal for the conversation.
Lacking any protocol changes in the near term, is the best (portable and somewhat secure) approach for an average person to just put sensitive stuff in an encrypted zip file or something...?
That's how I read it -- the claim being that those people are basically doing it for fun, 'playing the role' of someone with important secrets or powerful adversaries.
> Metadata is as important as content, and email leaks it
There are a lot of cases where I don't have any reason to care about metadata leaks. I've written plenty of reports for example where it was no secret that I was writing the report, what it was about, about how long it would be, when it would be finished, and to whom it was to be delivered.
As far as I can see delivering those reports as encrypted attachments to email would be fine.
> Every archived message will eventually leak
My encrypted attachment would be fine with this too. If some receiver archives the email the attachment will be encrypted in the archive.
Yours is a rare usecase. The metadata is bad for two reasons.
First, simply knowing who mailed whom and when, the powerful adversary can merely visit all participants and urge them to divulge the key and contents. If the adversary didn't know the participants beforehand, they do after seeing the helpful metadata.
Second, even failing to read the mail, the powerful adversary can still apply guilt by association, so merely being on the email is enough to attract their attention.
Aren't both of those "powerful adversary" attacks equally valid against Signal, and really any digital communications platform?
It depends on how accessible this email metadata is compared to Signal traffic, and how big you'd have to be to be able to eavesdrop on it. IIRC this was even a problem for Tor, when there are too few users relative to the nodes being snooped on.
The author says not to use email encryption but what is the case for sending email in plain text? Is encrypted email detrimental to my privacy in some way that unencrypted email is not? Or if the argument is that encrypted email is useless and no better than unencrypted email (since it is always unencrypted at rest) then what is the point of avoiding it in favor of the alternative? Aren't they equivalent, making the distinction meaningless?
This is my problem with the article. It feels like it suffers from a bit of zero-sum fallacy. The statement here is, "it can be broken therefore it's fundamentally broken." I think it's more useful to think in terms of probabilities. If I disable password authentication for SSH and require public key authentication on my web server, an attacker can still get in by stealing my private key. That isn't a reason to take the opposite approach however - botnets commonly employ password-guessing attacks against entire IP ranges so you're not actually safer by avoiding this practice just because it isn't a perfect solution. There is no silver bullet for security, only endless layers of strategies and adaptations to edge cases.
I did enjoy some of the points about the limitations of email encryption (the email chain example is a great reminder of how security is often more about human behavior than software). But I think the article could have been more compelling had it presented a less dogmatic thesis - perhaps "Email Encryption Won't Save You" or something like that.
The point being made is that, if something is sensitive enough that you would hesitate to send it in the clear, you should send it over Signal or some other system that doesn't have the security flaws that encrypted email has. Given that that option exists, and that encrypted email isn't suitable for many use cases that people are tempted to use it for (and is therefore an attractive nuisance securitywise), there's not much reason to use or support encrypted email at all.
One of the best ways for the "secure online communication with normies" idea to die is to try to buy a house, especially when not living in a city close to the relevant banks/lawyers/etc. If you don't stop caring and send some document scan full of PII as an email attachment after a few weeks - congratulations.
Does it matter? If you send it securely or provide the documents for scanning at the office, they will go on and email it around themselves anyway.
If this ever is to stop there needs to be a strict ban on using email for these things combined with checks and serious consequences for violations. But that will not happen anywhere soon because guess what, the government that would have to create these rules violates them routinely.
You have to set up a corporation that has your attorney (or other trustworthy authorized representative) as manager of the LLC. Then all the docs have their name/email/signature, and the LLC can just keep the name of the member in its own records.
It's still PII, but at least it isn't your PII. The droids that process these things are not going to change their means of communication or list of requirements for your deal, so you just have to ensure that the information being plugged into their systems is the information of a placeholder person (ie your attorney/business manager) instead of your own.
And when you send it over Signal you ALWAYS do so as a disappearing message, because as the article says, "every archived message will eventually leak." (Also you hope nobody quote-replies to your message.)
What about the use case of "I don't want my email provider to be able to read all my past transactional emails at a moment's notice"? Sure, there are "reputable" non-encrypting mail providers, but why not have a reputable mail provider AND encryption, so there's a barrier if they try to go rogue?
Play services / store isn't needed to run Signal (try it on AOSP, works just fine) and none of the iOS devices that run Signal have the play store installed.
Unfortunately, there isn't a ubiquitous enough system for a lot of messages that should be secure. Like password reset links, financial and medical documents, vulnerability disclosures, etc.
Besides the fact that no encrypted messaging system is sufficiently ubiquitous, Signal is not a great fit for these things because it is tied to a phone number (what would be the equivalent of security@mycompany.example? What if you don't want to give out your phone number, or your phone number changes?) And it is optimized for mobile messaging, and while there is a desktop app it isn't a great experience, and Signal strongly discourages third party clients.
And I do love Signal, I just don't think it can really fully replace email. And I don't know of anything else that is well positioned to do so either, though I would love to learn of something.
Encrypted email maybe works if both you and your counterparts are power users that know how to use GPG, or how to properly configure it through Thunderbird or any other email client.
The moment you have to implement encrypted emails in a high-risk organization or ad-hoc collective, it all goes out the window. There are simply way too many pitfalls to get it working properly. You have to continuously educate your users and ensure they don't shoot themselves in the foot.
This all day. I don't get why you'd take time out of your day to write "Stop Using Encrypted Email" instead of "Can Encrypted Email Be Done Right?" unless the answer is provable and obvious no.
The author is arguing that it cannot ever be done right.
Hasn't been fixed in 25 years and has fairly unfixable downgrade-to-plaintext attacks.
You could enforce encrypted communications in the protocol by changing it, but you'd need to block downgrade-to-plaintext in the process, which would remove backwards compatibility and what you've got is something that looks like e-mail but is incompatible with the entire rest of the existing e-mail system and you've forked the whole ecosystem anyway. Might as well just write a better protocol and app while you're at it.
Unauthenticated TLS has trivial downgrade to plaintext attacks too, but it's still better than unencrypted HTTP because it upgrades the necessity for a passive attack into an active one.
You've smuggled "unauthenticated" in there to make a reference to a mode of deployment that nobody thinks is secure. "Real" TLS (the alternative) doesn't have trivial downgrade attacks.
The argument is essentially that the only thing worse than no security, is the illusion of security.
Encryption on email is like a padlock on a suitcase. It makes you feel good, but really doesn't prevent much. It's common knowledge that you don't trust your valuables to unattended luggage. My reading of the article is that we should shed the illusion to help promote the same common knowledge for email.
I disagree with this author's take on PGP. Perhaps the people they communicate with reply in plaintext, quoting the author...but that's not my experience. That type of behavior is an opsec failure, not a PGP failure.
A tool (like PGP) does not imply a privacy-guaranteed scenario. For an analogy, carrying a handgun does not make you James Bond, and carrying a lockpick does not make you a locksmith. They are just tools, and possessing one of them [like PGP] does not intrinsically include the knowledge and ability to use that tool properly.
> So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages. Most technologists who work with PGP don’t understand it at a low enough level to see what’s wrong with it.
This is news to me, but I’ll admit I’m one of those technologists who doesn’t understand it enough. Can anyone point me to more info on this?
This is such a bizarre article. Efail was, among other things, a peer-reviewed accept at Usenix Security in 2018. It is certainly and obviously not a "hoax". Cryptography engineers have been warning about the pattern of PGP weaknesses that led to it for almost a decade prior.
You might want to read the article more carefully taking into account context:
>The word “Hoax” in the title of this article refers to the attempts to make it seem that EFAIL represented some deficiency in PGP.
Which was found after an example of a "hyperbolic headline". Later in the article it explicitly addresses the media distortion. I don't know how anyone could get from that that the article was claiming that the article was some sort of hoax, particularly when the article actually praises the work represented by the paper.
I know we’ve gone back and forth about this before, but EFAIL was caused by a major deficiency in PGP. PGP tees up failure modes like this, as evidenced by the fact that the vast majority of implementations all suffered from the same issue.
>If that is true (and there is evidence that it was) then the whole thing was just a hoax, _at least as presented_.
I suppose this is an example of the perils of attempting to be nuanced on the internet. The EFAIL paper is great work. I recently referenced it in an article I wrote. The group involved has subsequently done other good work in the messaging space I am interested in.
I shall go and update the article to be even more explicit on this point. Thanks for the assistance...
What I like most about PGP is message signing.
A signed message can prove to the receiving party that it was really me who send the message.
Also it does not require any setup on the receiving end.
If you want deniability you simply don't sign the email in the first place. That actually works, as opposed to something like Signal that attempts to claim deniability through forgability.
The author's tone is really grating; they insult anyone who disagrees with them. I think they're rude and need to learn how to write better. "LARP LARP LARP". How shitty.
Essentially, their argument is: Metadata isn't protected, and mail gets archived when perhaps you want messages to disappear. If you're writing messages on any system with the assumption they aren't stored somewhere indefinitely, you're already failing, buckaroo.
178 comments
[ 3.8 ms ] story [ 194 ms ] threadhttps://darkmail.info/
A lot easier for politicians to ban "Darkmail" than SecureMail/AdvancedMail or something of that sort.
It's basically Tor but with variable, high latency. It never took off, you need people to buy in and run nodes.
Plenty of people still use it this way on Android though. I'd say about half my Signal contacts do. I don't but that's because I use Google Voice a lot for texting (mostly as an easy way to receive 2 factor codes for work not actual messaging with anyone) and Signal only replaces the local SMS app.
https://www.youtube.com/watch?v=FUPstXCqyus
"You can’t hide secrets from the future with math. You can try, but I bet that in the future they laugh at the half-assed schemes and algorithms amassed to enforce cryptographs in the past"
But any complex enough system, you want it to run by folks with some expertise. Greater chance to have providers hire capable people than you being one (simply matter of size)
But.
> If messages can be sent in plaintext, they will be sent in plaintext.
This format is such a common line of attack in critiques of technology that I think it needs a new logical fallacy coined to describe it. I've seen it used as the primary basis for entire "x considered harmful" essays (thankfully not the case here as the rest of the bullet points more than hold up without it).
The idea that many people will use technology wrong is not an argument in itself against that technology. It's essentially an argument against UX, which is important (especially in the case of security) but while a false sense of security is much worse than no security, that doesn't justify advocating against correct application of that technology (or against efforts to improve the UX of said tech).
As mentioned the point here is moot given encrypted email's other larger failings, but without them this point simply wouldn't stand.
Author makes this argument best when they say PGP leaves emails "at the mercy of the least secure person they’ve sent them to."
You can have the best UX gating your PGP emails. But if you send them to me, and I have the option of replying on plaintext, there is a non-zero chance that I will eventually respond in plaintext. The blast radius of that compromise is the entire message thread. If what you're communicating about requires actual security, that is an unacceptable risk. If what you're communicating about doesn't, it's fine. Herego, it's a bad solution for secure messaging.
It absolutely is. Look at the shitshow that is Bluetooth. A good standard should be easy to implement properly.
It's a bad advise, don't listen.
Every thread that mentions PGP will eventually devolve into a discussion about how it's a foot gun and mere mortals will blow themselves up with it...
... but it works.
Seriously though, I remember discussions in the mid to late 90s about UI/UX difficulties and about how every single person that doesn't understand the operation perfectly IS going to be black-bagged by their local black-ops group; the same discussions that pop up in every PGP thread.
It's like one of the oldest running jokes in CS at this point -- not that PGP is broken and failed but that it attracts tons of individuals to congregate and be upset en masse about the UX.
More likely, they simply aren't noteworthy targets. If you rely on PGP to secure your emails, those emails will probably end up not actually secured, but you won't notice because your emails aren't valuable anyways and are probably secured by other stuff, like TLS, and Google's server security.
Well, you might argue Matrix stores meta data server side (the ones chosen), while Signal at least doesn't have to.
But do you really want to give up all that freedom trusting a single service provider in that really no data is kept?
Maybe you can wait until Matrix allows you to avoid signing up on a server using P2P[0], then you have got it all, and don't have to commit to an alternative that has advantages, but also big draw backs.
[0] https://news.ycombinator.com/item?id=27077660
However, both points you mentioned are client dependent, right?
For XMPP the difference is that there are multiple E2EE clients to choose from (see https://omemo.top/ ). And if someone chooses to use a none E2EE client, you still have the choice whether to communicate with them without E2EE, if that's acceptable to you in the specific context (not all conversations demand E2EE).
Every single XMPP client I’ve used sucks. Really suck. And there are always quirks setting up group chat and image sharing with XMPP servers.
This makes me think that the federated network must by necessity exist in a fragile and tender state while Matrix is young, and need to be tended to with attention and care. The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach. (To put it uncharitably: Look, there are now a whole two comprehensive server implementations, and the second one you could even afford a server for! Yeah, the Gnome people gave up on independently implementing a secure client, but surely an Electron one should be enough?..)
I’ve spent a very limited time studying the situation so I am not going to make any dire-sounding prophecies; besides, I actively don’t want any such prophecies to come true. What I am is worried. It doesn’t take much for a protocol to become a non-interoperable tangle of implementation details, and Matrix is an extraordinarily ambitious one.
My point is not that Matrix is complicated, thus we should avoid making it more so. My point is that the approach that Matrix chooses, even in its most minimal form, requires Matrix to be complex and resource-hungry, thus it seems prudent to direct attention and effort towards cultivating a multitude of implementations and deployments rather than enhancing marketability.
A social argument against features, not the standard technical one.
> The current stewards of the protocol don’t seem to be giving it that, growing features (even if good and competently designed ones) while treating the surroundings with something of a “they will come” approach.
I don't agree the growing features is an issue.
> I don't agree the growing features is an issue.
And I’m not arguing that it’s an issue in itself, either. I’m arguing that it is an issue when allocated development effort in preference to growing an ecosystem, because Matrix is both (inherently) bound to have an difficult time at it and (factually) not in a good place right now from that point of view. And that is my perception of the protocol developers’ priorities.
(Once there are a half-dozen independent server implementations and a decent number of clients, all with reasonably complete coverage of the current spec, this argument becomes irrelevant, so I’m not pleading featuritis here.)
(Looks closely.)
Ouch, I wanted to reference to its state “a couple of months ago” when I looked at it, but looks like it has been half a year at least. My calendar is completely out of order it seems.
In any case, it’s encouraging to hear that the development (well... rewrite) is proceeding along and E2EE is once more on the roadmap. But my point still stands, partly, because the developers have given up on implementing the protocol on their own, see e.g. https://gitlab.gnome.org/GNOME/fractal/-/commit/6bcb5e9 (announcement of switch to matrix.org SDK).
It's one thing to be uncharitable; it's another thing to be spouting stuff which is demonstrably false.
There are three usable server implementations participating in the network; synapse, dendrite and conduit (four, if you include construct). Synapse runs fine on a VPS with 2-4GB of RAM for almost all personal usage patterns, so snark about "servers you can afford" is BS. In addition to that we reduced its RAM footprint by 2-3x over the last few months (https://twitter.com/matrixdotorg/status/1434912387933560837).
The GNOME Fractal team hasn't given up at all - they just chose to rewrite the app for Gtk4, shifted to using matrix-rust-sdk in order to focus on the GUI layer and have been busier than ever. Meanwhile, there are tens of other implementations - a non-exhaustive list of the clients and SDKs today implementing E2EE is:
> I’ve spent a very limited time studying the situationThis is clear.
defeatist bullshit from the article:
>Every long term secret will eventually leak.
is not a valid excuse for abandoning PGP or encrypted email, its wishful thinking at best.
>The standard and best answer here is Signal
Signals github releases are sporadic at best and hard to compile consistently. its also centralized and has a dependency on google services to operate and lacks real transparency about its outages or plans to scale/operate, but at least its not too hard for you.
>Hop-by-hop encryption is a good thing: it makes untargeted dragnet surveillance harder.
the devices that handle this mail are commercial MTAs and are already largely backdoored by three letter agencies. a poison prime here, a weak cipher there, or even an opportune warrantless surveillance national security letter can sidestep this easily. companies will bend to the rule of US law.
>PGP don’t make this kind of surveillance any harder, and a targeted attacker will still get access to mail servers and messages.
this is a tangible, almost white-hot ignorance i cant abide. yes. youll get a PGP message. that message is encrypted with an asymmetric key and with a strong passphrase will have your adversary guessing until the last star falls from the heavens* and the statute of limitations for what was once your proud nation finally expire. PGP was invented to secure things that were transmitted IN PLAINTEXT.
trust was sacrosanct as you were expected to verify and know the person to which you were sending...you had keysigning parties and you used PGP to talk about important things with people you trusted. PGP is still valid and useful to this day.
* quantum computing may make this easier, but if it does, post-quantum ciphers are still an option
Are we trying to enable secure E2E encrypted messages, or are we trying to enable secure E2E email? Because those are two different goals.
If we're worried about fixing unencrypted messages, then I think it's completely valid to look at systems like Email and SMS and to say that they're just not suitable for secure conversations, and to advise people to move to other platforms/protocols for secure communication that doesn't have their flaws.
Signal is currently a good solution for a lot of people. That doesn't mean it doesn't have problems, but it has great encryption that is almost impossible for an ordinary user to accidentally mis-configure. Matrix is also coming into its own as a good solution, and while I don't necessarily recommend Matrix over Signal if encryption is absolutely important, it is very likely going to be a better solution in the future, and for casual encryption is a pretty good solution today.
Both Matrix and Signal are easier to use than PGP for ordinary users. They are both (frankly) more reliable even for advanced users. And with the amount of effort we could put into fixing PGP-encrypted emails, we could also make a platform like Matrix really good and push really hard for its adoption. Getting people to adopt Matrix is going to be easier than getting people to adopt encrypted emails. Incidentally Matrix also improves upon a number of other centralization and protocol problems with email as well, but we're focusing specifically on encryption here.
Sometimes working to a specific goal (encrypting plaintext communication) means recognizing when a strategy is bad, and pivoting to another strategy that's more pragmatic but that accomplishes the same goals. For example, I'm not going to waste time trying to "fix" SMS security for 2FA when I can tell people to install an Open Source 2FA app instead -- because the goal isn't to make email safe, and the goal isn't to make SMS safe, the goal is to make people safe. Broadening out our strategies and building cleaner, more fundamentally secure technologies is part of that.
E.g. PGP doesn't make dragnet surveillance harder?? Unless you assume that point-to-point encryption makes it entirely impossible (wrong), PGP clearly makes it much harder for anyone to read your message.
(I get what the author is trying to say, I'm just reacting to the strange way the argument is phrased. I don't think they thought their wording and reasoning in that passage through enough.)
> I'm just reacting to the strange way the argument is phrased.
It's made so in a manner to provoke a lot of loud noises to make it to spread, and resonate across the blogosphere more than the original lacking substance message ever could. A publicity stunt.
It's a self-promotion tactic - saying something outrageous often earns more notoriety for somebody unable to earn fame through virtue.
I think email could do this, but it require some dominant players (probably Google + Microsoft as providers for home + business users, or maybe Google/Apple/MS as dominant client producers) to participate actively.
> (I get what the author is trying to say, I'm just reacting to the strange way the argument is phrased. I don't think they thought their wording and reasoning in that passage through enough.)
Your question explicitely ignores the argument that was made and pretends a point to point protocol operates similarly to a store and forward protocol.
The issue is not that email or browsers can be configured to accept plain-text. What you incorrectly equate is two different protocol mechanisms, but you are focusing on the types of traffic.
some of these authorities have all sorts of structure to prevent corruption. passionate people, nonprofit or open governance. however, they are still single points of failure, or targets, or whatever you'd like to call them.
it seems that after years of pain with poor effectiveness of specification or poor verification tools for implementations, it has become en vogue for modern cryptosystems to insist on tight centralized control of reference implementations to ensure correctness. (otherwise known as the apple computer model). while this does seem to work in terms of ensuring high quality and problem free implementations, it does open up the single point of failure issue.
i'd argue that email's replacement must retain email's greatest quality: it's an open specification, not a system or implementation owned or controlled by a single entity and that the true challenge in bringing it to fruition won't be clever protocol and cryptographic design (although these will be crucial) but also substantial advances in protocol definition and implementation verification such that any competent developer can implement compatible components and plug them in.
This isn’t my field, so maybe someone has?
[1] https://signal.org/blog/the-ecosystem-is-moving/
Use whichever secure messenger you like, though.
They didn’t want to make it, good to go there, but why hasn’t anyone else wanted to make it?
But why are these protocols frozen? I've never developed one so I may just be ignorant of the challenges there, but if, for example, I wanted the XMPP protocol to be able to work with rich media, what's stopping me from updating said protocol to work with rich media instead of relying on optional extensions? In my mind, users of the protocol will receive the update (if they choose of course), thereby making the feature a default for the protocol that isn't reliant on extensions.
I admit I don't fully understand why protocols are frozen in this way, even though I agree with the author that the ones we currently have are definitely frozen. Any insights appreciated!
They're not "frozen". As mentioned in a sibling comment I wrote a blog post about this very topic - https://snikket.org/blog/products-vs-protocols/
Your point about optional extensions vs a protocol update isn't really as clear-cut as people think it is. To add a non-optional change to an open protocol in a decentralized network would necessitate blocking people from the network when you roll it out. That's not going to make for a good communication network.
The alternative is what XMPP does. The protocol evolves by adding new extensions, and deprecating old ones. Each extension generally has fallback considerations.
For example when group/offline media sharing was added many years ago, it was designed such that clients implementing the extension could render the media. Older clients, or clients that can't render media (e.g. terminal clients) simply display a URL.
The XMPP Standards Foundation annually publishes its "compliance suites", which (versioned by year) guides implementations on what they need to support. https://xmpp.org/about/compliance-suites.html
I wrote a blog post comparing Signal's approach to the approach taken by many decentralized networks: https://snikket.org/blog/products-vs-protocols/
And others have written their own:
- An Objection to "The Ecosystem is Moving": https://gultsch.de/objection.html
- "Have you considered the alternative?" https://homebrewserver.club/have-you-considered-the-alternat...
- "Re. The Ecosystem is Moving": https://blog.jabberhead.tk/2019/12/29/re-the-ecosystem-is-mo...
Decentralized networks can certainly move. They may not usually move as fast as a centralized one can, but that does not make reliance on a central entity a good alternative.
Also many (most?) of the complaints raised in the article will be an issue for any federated system. The article is arguing against end user control and decentralization. It just isn't upfront about it.
It is also within Signal’s interest that the remain competitive and achieve market success.
What good is a communication protocol with nobody to talk to?
Signal also has a blog post on why they chose not to support federation: https://signal.org/blog/the-ecosystem-is-moving/
It basically boils down to being able to add features and change things without worrying about whether the federated servers keep up.
AFAIK Google (via GMail) reads emails from/to “normal people”. Is Google not a “powerful adversary”?
Sadly without reference. Does anyone know more about this?
So unless the attacker can also produce the correct MAC matching the ciphertext, which should not be possible with out knowing a private key, I don't see how this can't be easily fixed just by checking the ciphertext against the MAC.
For messaging, we need something that is end to end encrypted by default, and is also only available in an e2ee format. Decentralization is an additional bonus, but really as long as the protocols are heavily audited and the clients are reasonably open (reproducible builds etc), it doesn't matter what your choice is and what networks your messages go through/who controls them.
https://chrome.google.com/webstore/detail/mailvelope/kajibbe...
There's also the issue of SMTP being very metadata heavy and there being no option to mitigate or encrypt any of the metadata. Which is why something like Delta Chat (if you haven't heard of it, it's basically Signal/WhatsApp like IM piggybacking over email) isn't very private.
I was super-annoyed when two people from my distant past started trying to contact me via Signal purely because of the unwanted and un-asked for behaviour of vacuum-and-spam notification of my phone contact list (which had accumulated from before 2000) who were in the subset of already-Signal-members.
In particular one huckster I lost $22k to, and who I came close to being liable for taking illegal action on behalf, through his fraudulent lack of full disclosure, who I had thoroughly removed from all my social media, plus filtered his email straight to trash, and permanently blocked from calling my phone.
Because his phone number was in my address book (so I could block him) Signal thought it had the right to let him know he can now contact me.
Poor form there Signal...
The mere fact that you had a phone number in your address book is what made your locally client-side Signal app made the notification… locally.
This newly discovered mechanism does not alert the remote Signal app.
Just the mere fact that you allowed Signal app access to your local address book and actually ran all numbers against the central server is not clearly stated in their type of service (TOS).
This is the primary reason why i never let Signal app have access to my Contacts/address-book.
This is why we have no idea what else Signal is doing with remote phone numbers found in our address book. I was able to ascertain between two phones of this one-sided aspect (but for how long)?
I expect any app or service to at least warn me first before they instigate unsolicited actions on my behalf.
Signal has no doubt already legally covered their ass with regards to me giving this consent.
However in reality I never would have allowed this if I was asked or even given a fraction of a hint as to what was about to happen once I gave them the requested permissions to be installed.
That along with numerous parts of the law defining exactly what can be a binding contract create a system (with ample case law and precedent to back it up) where most company’s terms and conditions are not valid contracts in Quebec.
If someone here were able to show harm and have standing in a case they would likely be able to bring a solid case forward.
The other person's phone looked at their address book and asked if it can reach you over Signal, which it can. It chooses to do this (it's a config option, on their phone).
The "unsolicited action on your behalf" is that given access to your contacts your phone will provide your contacts with some information over Signal, such as a Signal name and profile picture you've set - if they ask for it, unless you've blocked them. So if you set your name in Signal to "Barry is God" as a joke, that might be awkward if your very religious parents get Signal, but then that's also probably true if the name outside your dorm says "Barry is God" or if that's what the name says next to your apartment buzzer or on Facebook...
Likewise if the profile photo is of a marijuana leaf which was funny for two close friends on Signal but then your very straight boss gets Signal and they know your phone number...
Signal doesn't want to be another niche app that you only use to send encryption nerd stuff to other nerds who also installed the nerd app. It wants to be for everybody for everything, because there is safety in numbers. If there are six encrypted messages sent in Iran, the secret police really could just track down, arrest and torture everybody who sent or received an encrypted message just in case. But if it's six million messages that's just not practical.
It’s not just about the avatar but your name too. now being tied to your phone number.
Nope. Because your number was in his address book, his device periodically asks Signal "Hey, can I use Signal to message this contact?" and once you use Signal it says "Yes". The fact he's in your contacts means, by default, your phone thinks you know each other and it should provide information like your preferred name and photo if asked. Of course if you've got the number in there "so I could block him" you should... block him. In Signal too. Having blocked him, your phone won't provide your information and he can't contact you on Signal.
Under the hood if you do this, your phone ignores Signal messages from this number but it also mints fresh "postage stamps" for Signal's anonymous sender capability, it won't give the new ones to the newly blocked person and the old ones no longer work, so your actual friends can get new stamps and send you messages without even Signal being able to tell who sent them, but blocked people can't waste the service's time sending messages you won't even see.
This capability is necessary for Signal to function as something more than a fun "secret decoder ring" for a small circle of nerds. Without it for example, the ex-colleague I suddenly needed to contact a month ago wouldn't have been reached over Signal, he had no reason to tell me, a person he rarely talks to, that he's got Signal since we last met, but since his phone does have Signal, and my phone checked my contact list, it knew that Signal would work and it transparently used Signal for the conversation.
I uninstalled Signal instead of blocking him
For storage, I would recommend Veracrypt though since it's more specifically designed for this purpose.
BTW, I am curious, if he used secure messenger instead of email, as the article suggests, would police be able to track him...
There are a lot of cases where I don't have any reason to care about metadata leaks. I've written plenty of reports for example where it was no secret that I was writing the report, what it was about, about how long it would be, when it would be finished, and to whom it was to be delivered.
As far as I can see delivering those reports as encrypted attachments to email would be fine.
> Every archived message will eventually leak
My encrypted attachment would be fine with this too. If some receiver archives the email the attachment will be encrypted in the archive.
First, simply knowing who mailed whom and when, the powerful adversary can merely visit all participants and urge them to divulge the key and contents. If the adversary didn't know the participants beforehand, they do after seeing the helpful metadata.
Second, even failing to read the mail, the powerful adversary can still apply guilt by association, so merely being on the email is enough to attract their attention.
Obviously it's a problem for like, whistleblowers, but that's not most people.
If the head of M+A of one corp is talking to the CEO of another, that might be interesting.
If a bunch of Silicon Valley HR leads are mailing each other, is there another anti-poaching agreement in the works?
If some retail competitors' sales VPs are mailing each other, is there some price fixing or collusion going on?
There's a lot of signals here revealed by metadata.
It depends on how accessible this email metadata is compared to Signal traffic, and how big you'd have to be to be able to eavesdrop on it. IIRC this was even a problem for Tor, when there are too few users relative to the nodes being snooped on.
This is my problem with the article. It feels like it suffers from a bit of zero-sum fallacy. The statement here is, "it can be broken therefore it's fundamentally broken." I think it's more useful to think in terms of probabilities. If I disable password authentication for SSH and require public key authentication on my web server, an attacker can still get in by stealing my private key. That isn't a reason to take the opposite approach however - botnets commonly employ password-guessing attacks against entire IP ranges so you're not actually safer by avoiding this practice just because it isn't a perfect solution. There is no silver bullet for security, only endless layers of strategies and adaptations to edge cases.
I did enjoy some of the points about the limitations of email encryption (the email chain example is a great reminder of how security is often more about human behavior than software). But I think the article could have been more compelling had it presented a less dogmatic thesis - perhaps "Email Encryption Won't Save You" or something like that.
The idea that "email is insecure" is not a widely known one.
If this ever is to stop there needs to be a strict ban on using email for these things combined with checks and serious consequences for violations. But that will not happen anywhere soon because guess what, the government that would have to create these rules violates them routinely.
It's still PII, but at least it isn't your PII. The droids that process these things are not going to change their means of communication or list of requirements for your deal, so you just have to ensure that the information being plugged into their systems is the information of a placeholder person (ie your attorney/business manager) instead of your own.
If I use PGP-encrypted mail, I have to trust that the receiver is not stupid. If I use Signal, I have to trust that Google is not evil. Hmm...
Use something else to send messages you wish to not be compromised.
Besides the fact that no encrypted messaging system is sufficiently ubiquitous, Signal is not a great fit for these things because it is tied to a phone number (what would be the equivalent of security@mycompany.example? What if you don't want to give out your phone number, or your phone number changes?) And it is optimized for mobile messaging, and while there is a desktop app it isn't a great experience, and Signal strongly discourages third party clients.
And I do love Signal, I just don't think it can really fully replace email. And I don't know of anything else that is well positioned to do so either, though I would love to learn of something.
The moment you have to implement encrypted emails in a high-risk organization or ad-hoc collective, it all goes out the window. There are simply way too many pitfalls to get it working properly. You have to continuously educate your users and ensure they don't shoot themselves in the foot.
Hasn't been fixed in 25 years and has fairly unfixable downgrade-to-plaintext attacks.
You could enforce encrypted communications in the protocol by changing it, but you'd need to block downgrade-to-plaintext in the process, which would remove backwards compatibility and what you've got is something that looks like e-mail but is incompatible with the entire rest of the existing e-mail system and you've forked the whole ecosystem anyway. Might as well just write a better protocol and app while you're at it.
It's still better than http:. Eavesdropping requires an active attack instead of simply a passive one.
Encryption on email is like a padlock on a suitcase. It makes you feel good, but really doesn't prevent much. It's common knowledge that you don't trust your valuables to unattended luggage. My reading of the article is that we should shed the illusion to help promote the same common knowledge for email.
Your technology is imperfect and therefor should never be used
A tool (like PGP) does not imply a privacy-guaranteed scenario. For an analogy, carrying a handgun does not make you James Bond, and carrying a lockpick does not make you a locksmith. They are just tools, and possessing one of them [like PGP] does not intrinsically include the knowledge and ability to use that tool properly.
This is news to me, but I’ll admit I’m one of those technologists who doesn’t understand it enough. Can anyone point me to more info on this?
[1] https://articles.59.ca/doku.php?id=pgpfan:efail
>The word “Hoax” in the title of this article refers to the attempts to make it seem that EFAIL represented some deficiency in PGP.
Which was found after an example of a "hyperbolic headline". Later in the article it explicitly addresses the media distortion. I don't know how anyone could get from that that the article was claiming that the article was some sort of hoax, particularly when the article actually praises the work represented by the paper.
Edit: Hilariously, I went to look up the prior thread and it involves you calling EFAIL a hoax: https://news.ycombinator.com/item?id=21985303
>If that is true (and there is evidence that it was) then the whole thing was just a hoax, _at least as presented_.
I suppose this is an example of the perils of attempting to be nuanced on the internet. The EFAIL paper is great work. I recently referenced it in an article I wrote. The group involved has subsequently done other good work in the messaging space I am interested in.
I shall go and update the article to be even more explicit on this point. Thanks for the assistance...
Essentially, their argument is: Metadata isn't protected, and mail gets archived when perhaps you want messages to disappear. If you're writing messages on any system with the assumption they aren't stored somewhere indefinitely, you're already failing, buckaroo.