3 ms·

> Make the secure option more convenient than the insecure one, and you can't keep people away. Can you define convenient? Do you mean convenient from a usabil

by dsacco 9y ago

> Make the secure option more convenient than the insecure one, and you can't keep people away. Can you define convenient? Do you mean convenient from a usability perspective, or convenient from a risk/financial consequence perspective? I would assume you're using the first definition if you just leave it undefined. But strictly speaking, convenience and security are inherently at odds under the first definition; as stated I don't find that this approach generally works. Security features don't really augment usability so much as they trade off some of it - at best, if you were to make the functionality incredibly seamless and abstract away much or all of the decision making, I suppose you could make secure software as usable as insecure software, but it's not straightforward to design secure software to be as enjoyable to use as insecure software. If we take the example of iMessage: iMessage's security features do not make it intrinsically more or less usable in a general sense; the usability features are those that differentiate it from SMS. Apple happily baked strong cryptography into the protocol as well. An iMessage with the usability features but without the strong cryptosystem would be as useful, and users wouldn't generally be aware of a difference (in fact, it would technically be faster, so in that sense it would more usable). We can't add any further significant security services to iMessage without meaningfully reducing its usability. If iMessage were implemented as a protocol with end-to-end encryption, it would inherently be less usable due to key management and analytics costs on the client-side. This is why I take the position that security and usability are diametric opposites in software design. I've never observed software where this is not the case, unless you contrive the definition of "usability" to mean something like, "the user is hacked less, so they can use the application more" (and I've seen people apply this kind of thinking).

mikeash 9y ago
I thought iMessage was implemented as a protocol with end-to-end encryption. At least Apple claims that it is. I don't see how security and usability can be opposites. They are in conflict with each other to an extent, but increasing security doesn't necessarily hurt usability or vice versa. There are many products which have become both more usable and more secure over time, or which are both more usable and more secure than their competitors.
- dsacco 9y ago
  > I thought iMessage was implemented as a protocol with end-to-end encryption. At least Apple claims that it is. Sorry, let me be more precise: iMessage is not a true "zero knowledge" protocol construction - Apple could, theoretically, port your iMessage history to another iPhone without using your device's private key or iCloud password. This might be helpful to read: https://blog.cryptographyengineering.com/2013/06/26/can-apple-read-your-imessages/ https://blog.cryptographyengineering.com/2013/06/26/can-appl... > I don't see how security and usability can be opposites. They are in conflict with each other to an extent, but increasing security doesn't necessarily hurt usability or vice versa. There are many products which have become both more usable and more secure over time, or which are both more usable and more secure than their competitors. Let me try to formalize it a bit. Security is offered through confidentiality, integrity or authentication (increasingly integrity is just a sub-feature of authentication). Before you add authentication, a user might have been able to access their data or account somewhere without needing to log in. But access control was required, so now they need to enter a password, which requires password management of some kind. When you add a security service, what capabilities in the application are now impossible, or more difficult? Maybe those capabilities were undesirable or negligible, but they were there; by removing those capabilities you have added a cost, or a friction in its place. A possible workflow has been diminished, even if its for good reason. In practice you can reduce the impact of these quite a lot, i.e. encrypted messaging doesn't have to be PGP, it can be like iMessage. But fundamentally security (or cost) and usability have been transacted.
  - mikeash 9y ago
    Interesting, so it's "end-to-end" in that the messages are encrypted on one end and decrypted on the other without being decrypted in between, but nothing stops Apple from inserting themselves in the middle without our knowledge? I agree that the two are generally in tension, but I don't think they're opposites, and they don't always fight. Consider, for example, switching from a plaintext network protocol to one that uses encryption with an unauthenticated key exchange. The result isn't particularly secure since it's vulnerable to a MITM attack, but it's a definite improvement since it shuts down passive snooping, and it doesn't impact usability at all. Or consider something like HSTS. You shut down a real avenue of attack and the user never even sees the difference.
bostik 9y ago
> Can you define convenient? Of course. I mean convenient from the user's perspective, whether that is the developer (APIs, libraries, etc.), or the end user (workflow, UX, etc.); make the usability of the secure option/behaviour more appealing and you've guaranteed that human nature will take care of the rest. I'm not saying it's easy.

by dsacco 9y ago

mikeash 9y ago

I thought iMessage was implemented as a protocol with end-to-end encryption. At least Apple claims that it is. I don't see how security and usability can be opposites. They are in conflict with each other to an extent, but increasing security doesn't necessarily hurt usability or vice versa. There are many products which have become both more usable and more secure over time, or which are both more usable and more secure than their competitors.

dsacco 9y ago
> I thought iMessage was implemented as a protocol with end-to-end encryption. At least Apple claims that it is. Sorry, let me be more precise: iMessage is not a true "zero knowledge" protocol construction - Apple could, theoretically, port your iMessage history to another iPhone without using your device's private key or iCloud password. This might be helpful to read: https://blog.cryptographyengineering.com/2013/06/26/can-apple-read-your-imessages/ https://blog.cryptographyengineering.com/2013/06/26/can-appl... > I don't see how security and usability can be opposites. They are in conflict with each other to an extent, but increasing security doesn't necessarily hurt usability or vice versa. There are many products which have become both more usable and more secure over time, or which are both more usable and more secure than their competitors. Let me try to formalize it a bit. Security is offered through confidentiality, integrity or authentication (increasingly integrity is just a sub-feature of authentication). Before you add authentication, a user might have been able to access their data or account somewhere without needing to log in. But access control was required, so now they need to enter a password, which requires password management of some kind. When you add a security service, what capabilities in the application are now impossible, or more difficult? Maybe those capabilities were undesirable or negligible, but they were there; by removing those capabilities you have added a cost, or a friction in its place. A possible workflow has been diminished, even if its for good reason. In practice you can reduce the impact of these quite a lot, i.e. encrypted messaging doesn't have to be PGP, it can be like iMessage. But fundamentally security (or cost) and usability have been transacted.
- mikeash 9y ago
  Interesting, so it's "end-to-end" in that the messages are encrypted on one end and decrypted on the other without being decrypted in between, but nothing stops Apple from inserting themselves in the middle without our knowledge? I agree that the two are generally in tension, but I don't think they're opposites, and they don't always fight. Consider, for example, switching from a plaintext network protocol to one that uses encryption with an unauthenticated key exchange. The result isn't particularly secure since it's vulnerable to a MITM attack, but it's a definite improvement since it shuts down passive snooping, and it doesn't impact usability at all. Or consider something like HSTS. You shut down a real avenue of attack and the user never even sees the difference.

bostik 9y ago

> Can you define convenient? Of course. I mean convenient from the user's perspective, whether that is the developer (APIs, libraries, etc.), or the end user (workflow, UX, etc.); make the usability of the secure option/behaviour more appealing and you've guaranteed that human nature will take care of the rest. I'm not saying it's easy.