Making better security less and less inconvenient is the name of the game. Even if 100% security would be as easy as ticking a box, though, the fact of the matter is that most people don't care and if it's not "secure by default", it simply will stay not secure.
Maybe a synonym for "turned on by default" is "absolutely zero inconvenience or attention needed"
So, IMO the barrier is, "actually working"
https://github.com/signalapp/Signal-Android/issues/5253 https://github.com/signalapp/Signal-Android/search?q=missing...
If they don't, anyone who has ever used Signal to communicate with them will be silently unable to contact them anymore.
I can't understand why it requires ID/passport from you to use it. I guess if you want to use an encrypted messaging platform then you don't want it to be tied to the government issued ID.
p.s. you phone number is tied you your ID, so it's basically your ID
It may not be for you, but Signal does a very good job of solving the problems it does aim to solve for the millions of people who use it.
[0]https://medium.com/@mshelton/using-signal-without-giving-you...
Probably depends on the use-case, but as a normal user that lives in a non-repressive state, there is little value in using Signal. (FWIW Signal uses central servers, so in a repressive state it can just be turned off?) GPG based security is superior and not tied to a blackbox platform...
"[A correspondent's security code which is the only way to be sure you aren't MITM'd] can change repeatedly": It will tell you this happened, allowing you to take whatever action you think is appropriate. Also like modern TLS the behaviour is that you are always protected by the protocol from passive eavesdroppers regardless. Pervasive Monitoring Is An Attack and so protection against this is far more than "just Marketing".
"Most people install it through the Play Store": Play Store APKs are signed by their creator, not (only) by Google. If Open Whisper Systems says you're getting Signal, Google don't get to substitute something else except if you buy a Google phone and only then by replacing your OS.
"Phone number based apps are vulnerable to SIM hijacking". Signal users can choose to "lock" their account with a PIN so that an apparently new phone with that number doesn't get access unless its owner presents the PIN.
Assuming that you think the phrase "non-repressive state" includes countries like the US that spend billions of dollars to spy on their own citizens, just the first item is already a huge benefit.
Harvesting every single SMS message is trivial and so undoubtedly the NSA does it, they can run simple keyword matching an statistical analysis, and keep everything in case it's interesting. Each SMS message carries the sender, recipient and full text. In contrast harvesting even the encrypted Signal messages is difficult, and even with a successful (and relatively unlikely) breach of Open Whisper Systems itself neither the contents or in most cases senders are revealed by doing this. (Messages to friends or to those happy to receive messages from strangers don't need to reveal who sent them to Signal's own systems, only to the recipient). So instantly such government bulk collection isn't possible.
GPG's security is definitely not "superior" because it's based on the PGP hybrid crypto which is from last century. For example there's no Forward Secrecy, so it makes sense to steal encrypted PGP data on the expectation that you'll some day be able to decrypt it. In contrast old Signal encrypted messages are probably completely useless because the keys needed to decrypt them likely no longer exist anywhere. PGP offers only a signature mechanism, so a recipient can prove you sent a message, whereas in Signal the recipient only has their own certainty that it's not a forgery - nobody else could have forged it, but they easily could and so they can't use that as proof of anything.
But it's only OWS that control that check, right?
> Harvesting every single SMS message is trivial and so undoubtedly the NSA does it, they can run simple keyword matching an statistical analysis, and keep everything in case it's interesting. Each SMS message carries the sender, recipient and full text. In contrast harvesting even the encrypted Signal messages is difficult, and even with a successful (and relatively unlikely) breach of Open Whisper Systems itself neither the contents or in most cases senders are revealed by doing this. (Messages to friends or to those happy to receive messages from strangers don't need to reveal who sent them to Signal's own systems, only to the recipient). So instantly such government bulk collection isn't possible.
Comparing to SMS is a strawman. If the best thing you can say for your crypto is that it's more secure than SMS, it sucks.
Practically Signal offers little advantage over any messenger with transport encryption (e.g. Facebook Messenger): in both cases you pretty much have to trust the organisation itself.
> GPG's security is definitely not "superior" because it's based on the PGP hybrid crypto which is from last century.
It's based on a mature cryptosystem which we know the NSA tried and failed to break. That's better than using something novel and unproven.
> For example there's no Forward Secrecy, so it makes sense to steal encrypted PGP data on the expectation that you'll some day be able to decrypt it. In contrast old Signal encrypted messages are probably completely useless because the keys needed to decrypt them likely no longer exist anywhere.
True as far as it goes (though the PGP standard has good support for key rotation via subkeys - it would be good to improve the UX around this), but think about your threat model - reading messages from 10 years ago might not be the biggest vulnerability. In contrast, using Signal means an attacker who gains access to one person's phone has immediate access to phone numbers for all their contacts - which for a government means probably getting immediate access to their names, addresses, and real-time locations.
Signal does do a few good things that PGP-based cryptosystems don't. But the downsides massively outweigh the upsides in my book.
There's a critical difference you're papering over: the level of trust that is required is very different. With transport encryption you have to trust that the infrastructure is secured on an ongoing basis. With end-to-end encryption implemented in a real-world app (i.e. distributed through a walled garden) you need only trust that the version of the app delivered to you is based on the code it claims to be.
> Signal does do a few good things that PGP-based cryptosystems don't. But the downsides massively outweigh the upsides in my book.
One of the things Signal does well that PGP systems don't is actually being usable by real humans, which for a security system is everything.
If we're talking about a government bulk surveillance programme then not really - servers and infrastructure change all the time and sysadmins are naturally curious. An ever-expanding pool of people at Facebook (or wherever) would have to be on board with the surveillance programme for it to be worth setting up.
> With end-to-end encryption implemented in a real-world app (i.e. distributed through a walled garden) you need only trust that the version of the app delivered to you is based on the code it claims to be.
Those walled gardens don't let you pin a fixed version of that app, and OWS stops people from redistributing the APK or putting it up on open-source app stores, with their rationale being that they can't handle old versions of the app using their servers. So in reality you have to trust them on an ongoing basis.
> One of the things Signal does well that PGP systems don't is actually being usable by real humans, which for a security system is everything.
Being secure is everything. Usability is important, but better a secure system that only a few people can use than an insecure system that everyone can use.
This is moving the goal posts. Your quoted threat model was "SIM hijacking" not an insider attack.
> Practically Signal offers little advantage over any messenger with transport encryption (e.g. Facebook Messenger): in both cases you pretty much have to trust the organisation itself.
Only if you squint enough to believe that there's no difference in what you have to trust them to do and for how long which is a stretch.
You must trust Facebook to hold on to your messages without ever choosing to look at them for any reason even though they easily could, indefinitely. If you subsequently decide this trust was misplaced, too bad, they've got all your data.
Whereas you only have to trust OWS to not have hidden some backdoor in the software they publish, which they've no incentive to do, at the point where you use the software.
(I also have three hard tokens for from banks and investments, two ubikeys (both for LastPass, one in storage), and google authenticator on my iphone for anyone that offers it... so I've taken a step backward for added security.)
Which happens to also be more secure.
Hell, I store my 2FA keys in my pw manager and have it autofill those too -- a reduction in security! But there are some services that refuse to not spam your phone number if you don't set up some 2FA.
SSH is flawed in that you have to trust the host the first time you connect to it. For most people this is a reasonable tradeoff, but for security nerds it can be an impossible barrier to adoption. This is why some SSH servers spit out big long hexcodes or weird picture things, you are supposed to securely message the owner of the server to verify it before you accept it. Details are of course left up to the user because any default system you set up will of course be exploited. It's head of line security exploits all the way down.
Are the policy concerns you raise related to the above, or something else?
- user checks box that says they want certs issued automatically.
- your software handles the rest.
Of course there are plenty of details for the engineers to work out, but the end user shouldn't need to know any of them.
I was thinking that you were imagining that they would need to set up some kind of internal ACME infrastructure or something. Now I see you were just imagining certbot. Maybe half the domains I've seen used aren't actually publicly resolvable. Once I saw one that was, but was actually owned by someone else.
Anyway, there is no easy way out.
There are a number of ways to cut certs internally.
Still requires a passphrase or initializing a keypair on the client & server.
> HTTPS
HTTPS requires user interaction when a site forgets to renew a certificate.
Also SSH and HTTPS don't compare well. One does client authentication, the other doesn't.
The obvious point being made is that going from SMS -> E2E should be as seamless as from telnet -> ssh.
SMS and messaging systems generally do require some level of authentication so you're making a ridiculous comparison.
And far less space to mess things up than with coding a fancy login page.
So we're very far from perfect, but still better than most providers in this space. However, the fact that we can't easily do database migrations, debugging, etc makes our lives extremely hard, and it's much more difficult to compete in terms of UX.
If you measure two things, you can draw the "frontier" between them, sketching out the max of X that you can have while having an amount of Y. This will draw a graph where the lower left is the part you can reach, and the the upper right is the part you can't, e.g. you can't have 100% security and 100% usability.
When you are on that frontier, than the two things are in apparent opposition to each other, in the sense that you can't get more of one without having less of the other. However, if you are not on that frontier, then suddenly the conflict evaporates, because you can indeed have more of one without less of the other.
(Almost everything we ever talk about as software engineers being in "opposition" to each other is actually in this relationship. Sometimes optimality on one axis is so easy to achieve that it's still practical to discuss the two things as being in "opposition", but most of the time, before worrying about to things being in opposition it should first be checked that we are indeed on this optimality frontier. Otherwise we risk constraining our thoughts into a win/lose frame and miss the win/win options on the table.)
All of that is a lead up to my claim that the idea that GPG is on the Pareto frontier for usability and security doesn't pass the smell test. In fact it manages to have such a bad UI that it adversely impacts the security it can provide. It isn't just what git calls the "porcelain", either; some of the fundamental data structures GPG uses are just not quite right and produce fundamental confusion. It certainly doesn't help that the UI is so obscure that even a heavy user can be confused by everything that is going on.
GPG really needs a total UI overhaul, but I think this is one of those cases where the existence of an apparently "blessed" product (the GPG distribution itself) prevents anything better from being able to get enough of a foothold to succeed. If you waved a magic wand and made me the PM over the GPG product, I'd be putting out a call to the community to make a better UI, no holds barred (i.e., fundamental data structure changes are on the table and while I wouldn't necessarily want to promise a lack of backwards compatibility, don't be afraid to break it), and in a year we'll circle back around to the proposals and the GPG project itself will bless one of them. But that probably won't happen. (And I personally lack the bandwidth and the gpg street cred, so "why don't you do it" isn't a terribly practical response.)
What's the 3rd point in your triangle? I suspect it's "developer time" or "price" which boil down to the same thing depending on who's doing the measuring.
This is why almost no matter what you put on the points of the triangle, it works; as long as on the frontier there is at least some opposition, it works. The times you can have all of X and all of Y are rare, and all of three things essentially unheard of.
Skill.
Writing slow, unmaintainable code is usually a false economy. But many people just don’t know any better.
Take the refactoring Extract Variable, which is probably the simplest example. You name an intermediate value, thereby documenting it. Then hoist it out of the loop, making it faster, shorter, and clear that this value should not change.
Bingo. It's really easy to overlook UX, but it's the name of the game for actually improving things. Dev Experience too. There's a perverse problem in secure development, where you need to know enough to figure out why something is going wrong, but you must not leak information.
Consider the magnitude of inconvenience from having your identity stolen. I think it dwarfs any minor inconvniences needed to secure your identity.
That said, no doubt user-computer interaction should study security a little more I think.
It's not as simple as a boolean situation, though. There's not any single set of security steps that a person can take to definitively 'secure their identity'.
It's a gigantic continuum, where inconvenience asymptotically increases as you approach complete security. Everyone chooses some amount of risk which is less than complete security. The only real argument is over which point along the continuum is appropriate. There is no one correct answer, either.
I hate this attitude. Vehemently. It's borderline ethically irresponsible to say it out loud, because it gives muggles the notion that they can save costs by reducing security, which is often simply not true.
Security is very often the cheaper option, or at least the smoother one. Certainly from an end-users' point of view, it's more convenient.
Let me list some examples:
Windows v1909 has a bunch of hardware-enfoced security turned on by default (=low admin effort), invisibly to the end user (=convenient). Older operating systems either have none of this, or it's a manual task to enable these optional features (=expensive).
A good HR automation process means that when a new employee starts, they automatically gain access to whatever they need, and nothing they don't. This is great for the user, because "everything just works" and they have everything they need available (=convenient), but it's secure because there is no error-prone manual processes to grant them access to things (=cheaper).
Windows 10 Hello for Business is essentially a virtual smart card stored in the TPM chip of your laptop, secured with a PIN or biometrics as a second factor. It uses modern cryptography and works transparently with Kerberos. It's as strong as a Smart Card but is more automatic than a password.(=convenient) It requires no hardware to deploy, and essentially eliminates a bunch of attack vectors (=cost neutral or even cheaper).
Simply enabling WSUS or leaving Windows in automatic patch mode is literally the cheapest and most secure option, yet many organisations insist on spending tons of time, effort, and money on "managing" their patches. This inevitably results in totally unnecessary paper pushing, and no measurable benefit. Meanwhile, Microsoft releases protocol-breaking changes (such as the CredSSP thing recently) in waves, with the "enabling" patch one month, and then the "enforcing" patch the next month. Smooth as silk. Except for every. Single. One. Of my customers that insisted on "managing" their patches in quarterly rollouts or whatever that had a major outage because they skipped patches.
You get the idea. There is a "happy" path of less effort, more convenience, yet very good security. Not perfect, but good enough.
Conversely, this attitude of "we must reduce security to reduce costs or improve convenience" is just insane. I've seen people go out of their way to purposefully weaken the default security of a system because of this logic.
So please. Even if you know better, just never, ever say anything like this out loud. The world is full of Muggles, and they hear this shit and do random stupid stuff that lets the Chinese government steal our hard work.