3 ms·

> The right to privacy isn’t just for dorks who practice keyring bonsai. I never said anything contrary to that. I know that normal people are part of the int

> The right to privacy isn’t just for dorks who practice keyring bonsai. I never said anything contrary to that. I know that normal people are part of the intended audience - I'm interested in whether you think that Signal's target audience includes or excludes "keyring bonsai" users (which, admittedly, is an amusing and not entirely inaccurate way of describing much of the security community). If it includes those users - then why Signal couldn't have been designed such that use of phone numbers for identification are optional (but the default)?

woodruffw 3y ago
I think the short version is that doing so substantially complicates Signal’s design (meaning more edge cases, more complicated threat models, more exploitable bugs) for a marginal user case. Parsimony is a significant virtue in E2EE designs. But for those users: you can effectively use Signal without a phone number by using a virtual number or similar for the one-time registration process. That’s clunky and not ideal, but IMO is a reasonable hurdle for “bonsai” users.
- throw10920 3y ago
  > I think the short version is that doing so substantially complicates Signal’s design (meaning more edge cases, more complicated threat models, more exploitable bugs) for a marginal user case. Marginal users are just as human as the rest of us. Can you show examples of how this complicates Signal's design? The idea in my head requires only marginally more complexity to serve ~hundreds of thousands of more users.
  - woodruffw 3y ago
    Closer to tens of thousands, if you use other “keyring bonsai” metrics (such as maintaining a PGP key). Signal’s intended userbase is O(humanity). The complexity here is in crossing domains: Signal will need to decide how to communicate which “kind” of identity a user has, what that means, etc. They’ll need to decide whether to use random-but-intelligible identifiers (easy to make errors with) or allow people to configure identifies (which means storing more personal data, plus impersonation risks). And so forth.
    - throw10920 3y ago
      > Closer to tens of thousands, if you use other “keyring bonsai” metrics I'm talking about users that have the understanding and desire/need to disconnect their Signal identity from their phone number. That's hundreds of thousands, minimum, if not millions. > Signal’s intended userbase is O(humanity). This doesn't obviously interfere with Signal's ability to create Good privacy mechanisms, e.g. disassociation between identity and phone number. > The complexity here is in crossing domains: Signal will need to decide how to communicate which “kind” of identity a user has, what that means, etc. They’ll need to decide whether to use random-but-intelligible identifiers (easy to make errors with) or allow people to configure identifies (which means storing more personal data, plus impersonation risks) None of these obviously "substantially complicates Signal’s design" as you claimed earlier. > communicate which “kind” of identity a user has Tell the user that other users either have a "phone number" identity or a "certificate" identity. Done. They're already responsible for verifying that the phone number matches the person they think it does. > what that means Tell users that a "certificate identity" just means that that person isn't using a phone number. And they need to be extremely careful when interacting with people using these, and absolutely should verify them using a secure channel. Or just disable these entirely until the user taps the "about signal" button in the settings menu 7 times or something. I don't see any problems here that can't be overcome with a very modest amount of engineering. And, because it's the right thing, they should invest that effort.

woodruffw 3y ago

I think the short version is that doing so substantially complicates Signal’s design (meaning more edge cases, more complicated threat models, more exploitable bugs) for a marginal user case. Parsimony is a significant virtue in E2EE designs. But for those users: you can effectively use Signal without a phone number by using a virtual number or similar for the one-time registration process. That’s clunky and not ideal, but IMO is a reasonable hurdle for “bonsai” users.

throw10920 3y ago
> I think the short version is that doing so substantially complicates Signal’s design (meaning more edge cases, more complicated threat models, more exploitable bugs) for a marginal user case. Marginal users are just as human as the rest of us. Can you show examples of how this complicates Signal's design? The idea in my head requires only marginally more complexity to serve ~hundreds of thousands of more users.
- woodruffw 3y ago
  Closer to tens of thousands, if you use other “keyring bonsai” metrics (such as maintaining a PGP key). Signal’s intended userbase is O(humanity). The complexity here is in crossing domains: Signal will need to decide how to communicate which “kind” of identity a user has, what that means, etc. They’ll need to decide whether to use random-but-intelligible identifiers (easy to make errors with) or allow people to configure identifies (which means storing more personal data, plus impersonation risks). And so forth.
  - throw10920 3y ago
    > Closer to tens of thousands, if you use other “keyring bonsai” metrics I'm talking about users that have the understanding and desire/need to disconnect their Signal identity from their phone number. That's hundreds of thousands, minimum, if not millions. > Signal’s intended userbase is O(humanity). This doesn't obviously interfere with Signal's ability to create Good privacy mechanisms, e.g. disassociation between identity and phone number. > The complexity here is in crossing domains: Signal will need to decide how to communicate which “kind” of identity a user has, what that means, etc. They’ll need to decide whether to use random-but-intelligible identifiers (easy to make errors with) or allow people to configure identifies (which means storing more personal data, plus impersonation risks) None of these obviously "substantially complicates Signal’s design" as you claimed earlier. > communicate which “kind” of identity a user has Tell the user that other users either have a "phone number" identity or a "certificate" identity. Done. They're already responsible for verifying that the phone number matches the person they think it does. > what that means Tell users that a "certificate identity" just means that that person isn't using a phone number. And they need to be extremely careful when interacting with people using these, and absolutely should verify them using a secure channel. Or just disable these entirely until the user taps the "about signal" button in the settings menu 7 times or something. I don't see any problems here that can't be overcome with a very modest amount of engineering. And, because it's the right thing, they should invest that effort.