Thread by @moxie

I've had a bunch of discussions with people here about Signal PINs over the past day.

I don't usually spend this much time on Twitter, so parallel to the direct discussion, these are a few of the adjacent thoughts that have come up for me:

1/14

1) I think it's increasingly important to consider how discussions around technology are perceived across the full spectrum of backgrounds (from technical to non-technical) for everyone interested in the topic of their own privacy/security -- which is basically everyone now!

Its interesting that some folks who see discussion around PINs conclude "switch to app X!" where X invisibly stores the same data in plaintext rather than e2e.

Signal's efforts are a discussion b/c we're designing not to store data in plaintext, while plaintext got no discussion

This is similar to a larger pattern I've seen where projects that make no attempt to provide privacy will never have any discussion about security/privacy bugs that are discovered (can't have vulns if there's no security to break!), and those that do will face periodic headlines.

The latter is obviously important, but it seems to me that we need to think about ways to contextualize those discussions now that everyone *outside* of "infosec" is also watching

Otherwise, I've seen people w/o tech backgrounds watch the headlines and draw the wrong conclusions

2) Building apps without analytics can be a challenge, and if we want developers to do that, we need to figure out how to make it less so.

For instance, one reaction here has been frustration that folks were suddenly forced to create a PIN...

Our goal with PINs is to enable non-phone # based addressing. Since that will mean your Signal contacts can't live in your address book anymore, they're Signal's responsibility. Every other messenger does this by storing them in plaintext, but that's not private, so we built SVR.

In addition to being the basis for non-phone # based addressing, the other big benefit for most users is that rather than Signal contacts syncing to Google and Apple from the address book, they'll remain encrypted within Signal.

But it's a big change that we have to do carefully

The whole project was a long rollout. To get everyone a PIN, we had a non-blocking "create PIN" flow that everyone saw persistently for ~4-5 months with refinement cycles along the way.

But w/o analytics, we don't have insight into how often people see and don't create, or...

...if there's copy we can A/B to make things less confusing, or how often people are looking at it, or what people's reaction is in the app.

Instead we try making incremental changes and talking to users. In this case, most of the people we talked to had gone through the flow.

When we got to the end of the rollout and it became a blocking flow, that's when we realized some people have been living with that prompt at the bottom of their screen for 5 months.

We're working on an option to disable PINs as a result, but ideally we'd have visibility sooner.

We can do that, and folks can take comfort that there are no analytics/trackers in Signal, but it can periodically make for a frustrating UX

If we want "no analytics/trackers" to be standard for all, we prob need to develop methods to get the same insights with privacy.

3) It is sometimes difficult for me to have design discussions with people who work in infosec, in part because of what feels like a gap between what one might consider "practical" and what I've found to be so.

I'm not sure how to bring the user stories Signal sees...

...into a common basis for discussion. I almost wish there were some way that we could open up Signal user support channels, so interested people in this space could have the perspective of doing that for 24hrs (without somehow degrading the quality of Signal user support)?