<div dir="ltr">Sorry for the delayed reply, been thinking about this for a few days.<div><br><div>On reflection, I think email identifiers can meet the same bar as an SN (as in the proposal), as long as there is a  'registration lock' type feature (same as phone numbers as in Signal) to mitigate compromise of the email account.</div></div><div><br></div><div>> <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I think email addresses would solve the problem of letting people create throwaway identities more easily, while also preserving all of the existing Signal user experience. Yes there are security drawbacks to this approach, but there are also huge UX wins, especially in terms of simplicity and consistency.</span></div><div><br></div><div>On second thought, I agree the UX wins of an email address outweigh the security value of an intrinsic hash-based identifier. Lets do email addresses instead.</div><div><br></div><div><br></div><div>Implementing support for email addresses in signal is actually easier than the original proposal - no funky hashes + challenge-response verification when signing up and sharing a signalling-key/registrationID. Client implementation is probably about the same level of complexity.</div><div><br></div><div>Thanks for all the feedback,</div><div>-T</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 29, 2018 at 10:33 AM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, May 28, 2018 at 8:06 PM Trevor Jameson <<a href="mailto:trevorjameson87@gmail.com" target="_blank">trevorjameson87@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This wins the UX game because emails are memorable, short and can be put in an existing users contacts. SNs and hash-based proposals arent memorable, but thanks to the prevalence of deeplinking and QR codes, they can be trivially shared by users. Snapchat did this and proved the effectiveness of this UX.</div></div></blockquote><div><br></div></span><div>These are two completely different experiences for the user though.</div><div><br></div><div>In the case of an email address, it would work exactly as Signal does today where it can auto-discover Signal contacts based on your phone's contacts without the need for Signal to store a social graph. It also means the user has an identity that outlives any one cryptographic key and therefore supports key rotation.</div><div><br></div><div>In the case of an identifier based on a cryptographic key, it behaves quite differently: we've moved out of the "human meaningful" section of Zooko's triangle into the "decentralized" one. In doing so a lot of the nice properties of these identifiers are lost:</div><div><br></div><div>- Auto-discovery via Contacts won't work for this approach, since we don't have a stable, reusable, human meaningful identifier for people. So, these identifiers can only be exchanged securely via things like QR codes, or bootstrapping via another secure channel (or potentially insecure channel)</div><div>- Key rotation won't be automatic and seamless. This also raises questions about how multi-device support should be handled.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Beyond the obvious (backup your keys somewhere), I dont have a good answer for this. The best UX here would be some artifact you store offline ('print' a QR code, download to a USB stick) but this has its own set of issues.</div><div><br></div><div>At some level this is an inherent problem of online identity, and by keying off email addresses, we are only deferring the problem to the email password/2FA/recovery-<wbr>mechanisms. Personally, I rather the trade-off where we address backup ourselves.</div></div></blockquote><div><br></div></span><div>From a UX perspective, email recovery is something most users will understand. Printing out a QR code is comparatively quite weird, and then there's the question of even printing anything securely (I suppose you can print out a KDF input/salt or keywrapped key which needs an additional password component).</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>We can also explicitly not address this: By explicitly stating our alternative identifiers are non-recoverable if you loose key material, and you accept this trade-off. This is okay as phone-based identifiers remain an option for users who dont lean this way.</div></div></blockquote><div><br></div></span>This sounds like the sort UX-compromising power-user feature that Signal has typically avoided as opinionated software with a simple interface. It feels like it accomplishes largely the same ends as safety numbers (verify cryptographic keys), using the same UX as safety numbers (confirm a QR code). It simplifies the creation of throwaway identities by reintroducing a UX that's giving me flashbacks to PGP/GPG and keysigning parties.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I think email addresses would solve the problem of letting people create throwaway identities more easily, while also preserving all of the existing Signal user experience. Yes there are security drawbacks to this approach, but there are also huge UX wins, especially in terms of simplicity and consistency.</div><span class="HOEnZb"><font color="#888888"><div class="gmail_quote"><br></div>-- <br><div dir="ltr" class="m_-2015720652441245098gmail_signature" data-smartmail="gmail_signature">Tony Arcieri<br></div></font></span></div>
</blockquote></div><br></div>