getting web sites to adopt a new identity system

Posted on April 30, 2013 by ben

My team at Mozilla works on Persona, an easy and secure web login solution. Persona delivers to web sites and apps just the right information for a meaningful login: an email address of the user’s choice. Persona is one of Mozilla’s first forays “up the stack” into web services.

Typically, at Mozilla, we improve the Web by way of Firefox, our major lever with hundreds of millions of users. Take asm.js, Firefox’s new awesome JavaScript optimization technology which lets you run 60-frame-per-seconds games in your web browser. It’s such a great thing that Chrome is fast-following. Of course, Chrome also innovates by deploying features first, and Firefox often fast-follows. Standardization ensues. The Web wins.

With Identity, we’ve taken a different approach: out of the gate, Persona works on all modern browsers, desktop and mobile, and some not-so-modern browsers like IE8 and Android 2.2 stock. We’re not simply building open specs for others to build against: we are putting in the time and effort to make Persona work everywhere. We even have iOS and Android native SDKs in the works.

Why would we do such a thing? Aren’t we helping to improve our competitors’ platforms instead of improving our own? That reasoning, though tempting, is misguided. Here’s why.

working on all modern platforms is table-stakes

We talk about Persona to Web developers all the time. We almost always get the following two questions:

  1. does this work in other browsers?
  2. does this work on mobile?

These questions are actually all-or-nothing: either Persona works on other browsers and on mobile, or, developers tell us, they won’t adopt it. To date, we have not found a single web site that would deploy a Firefox-only authentication system. Some web sites have adopted Persona, only to back out once they built an iOS app and couldn’t use Persona effectively (we’re actively fixing that.) So, grand theories aside, we’re targeting all platforms because web sites simply won’t adopt Persona otherwise. After all, Facebook Connect works everywhere.

When you think about it, is that actually so different from the asm.js strategy? asm.js is much faster on Firefox, but it works on Chrome and any other JavaScript engine, too. Heck, even Google’s DART, a brand new language they want to see browsers adopt, comes with a DART-to-JavaScript-compiler so it works on all other browsers out of the gate. These are not after-thoughts. These are not small investments. asm.js was designed as a proper subset of JavaScript. The DART-to-JS compiler is a freaking compiler, built just so non-Chrome browsers can run DART.

When appealing to web developers to make a significant investment — rewriting code, building against a new authentication system, .. —, cross-browser and cross-device functionality from day 1 is table-stakes. The alternative is not reduced adoption, it’s zero adoption.

priming users is the winning hand

The similarities between Identity and purely functional improvements like asm.js stop when it comes to users. The reason web sites choose Facebook Connect is not just because it works, but because 1 Billion users are primed with accounts and ready to log in. Same goes for Google+ and Twitter logins.

Persona doesn’t have a gigantic userbase to start from. That sucks. The good news is that, unlike other identity systems, we don’t want to create a huge silo’ed userbase. What we want is a protocol and a user-experience that make Web logins better. We want users to choose their identity. We’re happy to bridge to existing userbases to help them do just that!

So, bridging is what we’re doing. You’ve seen it already with Yahoo Identity Bridging in Persona Beta 2. More is coming. With each bridge, hundreds of millions of additional users are primed to log in with Persona. That’s powerful. And it’s a major reason why sites are adopting Persona.

Working everywhere is table-stakes. Priming users so they’re ready to log in with just a couple of clicks, that’s the winning hand.

beautiful native user-agent implementations sweetens the pot

Meanwhile, the Persona protocol is specifically tailored to be mediated by the user’s browser. Long-term, we think this will be a fantastic asset for the Persona login experience. Beautiful, device-specific UIs. Universal logout buttons. Innovation in trusted UIs. And lots of other tricks we haven’t even thought of yet. We’re doing just that kind of innovation on Firefox OS with a built-in trusted UI for Persona.

But let’s be clear: that’s not an adoption strategy. An optimized Firefox UI for Persona will not affect web-site adoption because it does nothing to reduce login friction. In a while, once Persona is widespread with hundreds of thousands of web sites supporting it, and users are actively logging in with Persona on many devices and browsers, Firefox’s optimized Persona UI will be a competitive advantage that other browsers will feel pressure to match. Until then, web site adoption is the only thing that matters.

now you know our priorities

Wherever it makes sense, we’re implementing Firefox-specific Persona UIs. However, when it comes to an adoption strategy, we know from our customers that this won’t help. What will help is:

  1. Persona working everywhere
  2. As many users as possible primed to log in

Those are our priorities.

We know this is different for Mozilla. But it’s quite common for folks implementing Services. What you’re seeing here is Mozilla adapting as it applies its strongly held principle of user sovereignty up the stack and into the cloud.

Posted in identity, mozilla, web | 3 Comments

Identity Systems: white labeling is a no-go

Posted on April 25, 2013 by ben

There’s a new blog post with some criticism of Mozilla Persona, the easy and secure web login solution that my team works on. The great thing about working in the open at Mozilla is that we get this kind of criticism openly, and we respond to it openly, too.

The author’s central complaint is that the Persona brand is visible to the user:

It [Persona] needs white-labeling. I know that branding drives adoption, but showing the Persona name on the login box at all is too much; it needs to be transparent for the user. Most of the visits to any website are first-time visits, which means the user is seeing your site/brand for the first time. Introducing another brand at the sign-up point is a confusing distraction to the user.

The author compares Persona to Stripe, the payment company with a super-easy-to-use JavaScript API, which lets a web site display a payment form with no trace of the Stripe brand, and all the hard credit-card processing work is left to the Stripe service.

This is an interesting point, but unfortunately it is wrong for an Identity solution. Consider if Persona were fully white-labeled, integrated into the web site’s own pages, with no trace of the Persona system visible to the user. What happens then? Two possibilities:

  1. no user state is shared between sites: users create a new account on every site that uses Persona. The site doesn’t have to do the hard work of password storage, it can let Persona handle this. There’s no benefit to the user: every web site looks independent from the others, with its own account and password. And while this is incrementally better than having web sites store passwords themselves, that increment is quite small: web sites tend to use federated authentication solutions if they can lower the friction of users signing up. If users still have to create accounts everywhere, friction is high, and the benefit to the web site is small.

  2. user state is shared between sites: users don’t have to create new accounts at every web site, they can use their existing single Persona account, but now they have no branding whatsoever to indicate this. So, are users supposed to type in the same Persona password on every site they see? Are they supposed to feel good about seeing their list of identities embedded within a brand new site they’ve never seen before, with no indication of why that data is already there? This is a recipe for disastrous phishing and a deeply jarring user experience.

So what about Stripe? With Stripe, the user retypes their credit-card number at every web site they visit. That makes sense because the hard part of payment processing for web sites isn’t so much the prompting for a credit card, it’s the actual payment processing in the backend. And, frankly, it would be quite jarring if you saw your credit card number just show up on a brand new web site you’ve never visited before.

But identity is different. The hard part is not the backend processing, it’s getting the user to sign up in the first place, and for that you really want the user to not have to create yet another account. Plus, if you’re going to surface the user’s identity across sites, then you *have* to give them an indication of the system that’s helping them do that so they know what password to type in and why their data is already there. And that’s Persona. Built to provide clear benefits to users and sites.

By the way, though we need some consistent Persona branding to make a successful user experience, we don’t need the Persona brand to be overbearing. Already, with Persona, web sites can add a prominent logo of their choosing to the Persona login screen. And we’re working on new approaches that would give sites even more control over the branding, while giving users just the hint they need to understand that this is the same login system they trust everywhere else. Check it out.

Posted in identity, mozilla, security | 3 Comments

so what if torture works?

Posted on April 23, 2013 by ben

I’ve seen most of Zero Dark Thirty, the movie that claims to tell the story of the search for and killing of Bin Laden. It’s a pretty gruesome film, with clear implications that torture led to information that led us to Bin Laden. There are fierce debates about whether that fact – that torture led us to Bin Laden – is true or not. Almost every time torture is discussed, the discussion quickly shifts to one side saying “see, it’s effective!” and the other saying “it doesn’t even work!”

Here’s a simple question I don’t hear asked all that often: who cares if it works? It’s simply wrong. If “it works!” is our only criteria, then forget the Rule of Law. Many lives would be saved if police could willy-nilly enter anyone’s home and search their belongings, because some of those folks are probably murderers that we can’t catch if we strictly follow the rules. We could have captured all of Bin Laden’s extended family and tortured them, publicly threatening him to surrender. That might have worked. Especially if we did it to his kids. Especially the young ones.

What is wrong with the world when we even consider this most extreme version of the ends justifying the means?

Torture is wrong. Period. Even if it works.

Posted in uncategorized | 1 Comment

Firefox is the unlocked browser

Posted on March 19, 2013 by ben

Anil Dash is a man after my own heart in his latest post, The Case for User Agent Extremism. Please go read this awesome post:

One of my favorite aspects of the infrastructure of the web is that the way we refer to web browsers in a technical context: User Agents. Divorced from its geeky context, the simple phrase seems to be laden with social, even political, implications.

The idea captured in the phrase “user agent” is a powerful one, that this software we run on our computers or our phones acts with agency on behalf of us as users, doing our bidding and following our wishes. But as the web evolves, we’re in fundamental tension with that history and legacy, because the powerful companies that today exert overwhelming control over the web are going to try to make web browsers less an agent of users and more a user-driven agent of those corporations. This is especially true for Google Chrome, Microsoft Internet Explorer and Apple Safari, though Mozilla’s Firefox may be headed down this path as well.

So so right… except for the misinformed inclusion of Firefox in that list. Anil: Firefox is the User Agent you’re looking for. Here’s why.

user agency

Two years ago, I joined Mozilla because Mozillians are constantly working to strengthen the User Agent:

In a few days, I’ll be joining Mozilla.

[..]

[I want] to work on making the browser a true user agent working on behalf of the user. Mozilla folks are not only strongly aligned with that point of view, they’ve already done quite a bit to make it happen.

browser extensions

Like Anil, I believe browser add-ons/extensions/user-scripts are critical for user freedom, as I wrote more than two years ago, before I even joined Mozilla:

Browser extensions, or add-ons, can help address this issue [of user freedom]. They can modify the behavior of specific web sites by making the browser defend user control and privacy more aggressively: they can block ads, block flash, block cookies for certain domains, add extra links for convenience (i.e. direct links to Flickr’s original resolution), etc.. Browser extensions empower users to actively defend their freedom and privacy, to push back on the more egregious actions of certain web publishers.

mobile

Again, like Anil, I saw, in that same blog post, the threat of mobile:

Except in the mobile space. Think about the iPhone browser. Apple disallows web browsers other than Safari, and there is no way to create browser extensions for Safari mobile. When you use Safari on an iPhone, you are using a browser that behaves exactly like all other iPhone Safaris, without exception. And that means that, as web publishers discover improved ways to track you, you continue to lose privacy and control over your data as you surf the Web.

This situation is getting worse: the iPad has the same limitations as the iPhone. Technically, other browsers can be installed on Android, but for all intents and purposes, it seems the built-in browser is the dominant one. Simplified computing is the norm, with single isolated applications, never applications that can modify the behavior of other applications. Thus, no browser extensions, and only one way to surf the web.

so Firefox?

To Anil’s concerns:

  • Firefox Sync, which lets you share bookmarks, passwords, tabs, etc. across devices, is entirely open-source, including the server infrastructure, and if you don’t want Mozilla involved, you can change your Firefox settings to point to a Sync server of your choosing, including one you run on your own using our open-source code. PICL (Profile in the Cloud), the next-generation Sync that my team is working on, will make it even easier for you to choose your own PICL server. We offer a sane default so things work out of the box, but no required centralization, unlike other vendors.

  • Mozilla Persona, our Web Identity solution, works today on any major browser (not just Firefox), and is fully decentralized: you can choose any identity provider you want today. This stands in stark contrast to competing solutions that tie browsers to vendor-specific accounts. Persona is the identity solution that respects users.

  • Firefox for Android is the only major mobile browser that supports add-ons. Anil, if you want “cloud-to-butt”, you can have it on Firefox for Android. You can also have AdBlock Plus. Try that on any other mobile browser.

the unlocked browser

Anil argues that we should talk about unlocked browsers. I love it. Let’s do that. Here’s my bet, Anil: write down your criteria for the ideal unlocked browser. I bet you’ll find that Firefox, on desktop, on mobile, and in all of the services Mozilla is offering as attachments, is exactly what you’re looking for.

Posted in identity, mozilla, privacy, web | 4 Comments

the Web is the Platform, and the User is the User

Posted on February 28, 2013 by ben

Mid-2007, I wrote two blog posts — get over it, the web is the platform and the web is the platform [part 2] that turned out to be quite right on one front, and so incredibly wrong on another.

Let’s start with where I was right:

Apps will be written using HTML and JavaScript. [...] The Web is the Platform. The Web is the Platform. It’s going to start to sink in fast.

[...]

Imagine if there’s a way to have your web application say: “please go pick a contact from your address book, then post that contact’s information back to this URL”. Or if the web application can actually prepare a complete email on your behalf, image attachments included (oh the security issues….), and have you just confirm that, yes, you really want to send that email (the web app definitely can’t do that without confirmation)?

[...]

[We could] begin to define some JavaScript APIs, much like Google Gears for offline data storage, that enables this kind of private-public mashup. It would be fantastically interesting, because the security issues are mind boggling, but the resulting features are worth it. And it would spearhead some standards body to look into this issue more closely.

Whatever happens, though, the web is the platform. If you’re not writing apps in cross-browser-compliant HTML+JavaScript, the clock is ticking.

And in my followup post:

Add incremental features in JavaScript. First an offline functionality package, like Google Gears, so applications can work offline. Then, an interface to access the user’s stored photos. Over time, a way for web applications to communicate with one another.

[...]

Then there’s one tweak that could make a huge difference. Let a web application add itself to the dashboard.

Where did I go wrong? I thought this innovation was going to be unleashed by Apple with their introduction of the iPhone.

In my defense, if you read between the lines of the iPhone announcements back in 2007, it’s possible that Apple actually meant to do this. But then they didn’t, and they released an Objective C API, and a single closed app store, and locked down payments, and disallowed competition with their own apps, … So much for the Web.

It’s only fitting that the organization that is making this happen is my employer, Mozilla, with Firefox OS. Don’t get me wrong, I’m not taking credit for Firefox OS: there is a whole team of amazing leaders, engineers, product managers, product marketers, and generally rockstars making that happen. But it’s nice to see that this vision from six years ago is now reality.

So, the Web is the platform. HTML and JavaScript are the engines.

What about data? What about services? It’s time we redesign those. They, too, need to be freed from central points of control and silos. Data & Services need to be re-architected around the user. I should get to choose which organization I want to trust and which of my existing accounts I want to use to log into a new site/app/service. I should be able to access my data, know who else is touching it, and move it around as I please. I should be able to like/share any piece of content from any publisher I read onto any social network I choose. Amazing new apps should have easy access to any data the user wishes to give them, so that new ideas can emerge, powered by consenting users’ data, at the speed of the Web.

That, by the way, is the mission of my team, Mozilla Identity, and those are the guiding principles of our Persona login service and our upcoming project codenamed PICL. And of course we’ll continue to build those principles and those technologies into the Firefox OS phone (Persona is already in there.)

The Web is the Platform. And the User is the User. I’m quite sure Mozilla is the organization made to deliver both.

Posted in identity, mozilla, web | 7 Comments

Aaron

Posted on January 13, 2013 by ben

I heard about Aaron Swartz in 2000, when he won the ArsDigita prize. I met him for the first time in early summer 2002, when my little open-source webdev company, OpenForce, joined the Creative Commons team to build the CC web site. That’s also when I met Matt Haughey, whose words helped trigger a bunch of memories in me about Aaron.

Most hackers inevitably meet a younger, better, smarter version of themselves. For me, it happened probably earlier than for most, and it was the day I met Aaron. I was 25, an MIT graduate with a near-perfect GPA, leading my second startup. He was 15 and in high school, self-taught. And he wasn’t just better. He was unbelievable. He mastered complex software topics with an ease that made me look awkward. He got visibly impatient with me. It made me a little bit jealous.

Aaron came to New York City once during the Creative Commons site buildout. He came by our offices, introduced us to the future: newsreaders and RSS. I took him and his father out to lunch for a fancy burger in Soho. He was unimpressed and hated the food. And he said it.

Aaron was brutally honest like that. A few weeks into our work on Creative Commons, Aaron published an update on his web page: “OpenForce… bad, slow, expensive.” I barely slept that night. Here I was, trying to impress one of my idols (Larry Lessig), and this guy was just killing me. I was afraid he was right. I was also mesmerized by his ability to be so direct, so honest, because the truth was all that mattered, consequences be damned.

Over time, I got to understand that none of this technical criticism was personal. Aaron’s standards of openness, expertise, and focus were just incredibly high. By the time we launched Creative Commons, we were on reasonably good terms. We became friendly. We were never very close, and the friendship didn’t get deeply personal. We talked about web frameworks, our mutual passion for a few years (before he moved on to bigger things.) We discussed Creative Commons, semantic web, etc. We chatted over email a bit every few months. We saw each other at a couple of Creative Commons events. I think the last time I saw him in person was in 2006.

One day, he mentioned me in a blog post and called me his friend. I was honored. A year or so ago, we chatted again when he became interested in the work I’m doing at Mozilla. He was excited about what we were doing and started telling people. I was honored, again.

When I heard about Aaron’s JSTOR shenanigans, I reacted much like many others: okay, that was stupid, he’ll get slapped on the wrist and we’ll all move on, because where’s the harm, really? I was pretty busy with my own life and growing family. I didn’t think about his situation very much. I didn’t realize how serious it was getting. I missed how MIT played a role in his predicament (something that makes me incredibly angry right now.) I basically gave to his legal defense fund and moved on.

I wish I’d at least reached out. Said something. Maybe given him an opportunity to vent. It’s unlikely it would have made any difference: he was surrounded by people who knew him far better and who loved him. But you know, maybe. I’m sorry, Aaron, that I didn’t reach out. I’m sorry that the world failed you in the most insane way, that you were put in an unfathomable situation for doing something that harmed no one. That I didn’t appreciate you nearly as much as I could have while you were around.

I spent some time today digging up old photos, and finally found ones I took on the day Creative Commons launched, in December 2002. Here’s a few of Aaron: one with Matt Haughey, one with Glenn Brown and Larry Lessig, one interview with Dan Gillmor, and one on stage describing Creative Commons technology.

Matt Haughey and Aaron Swartz at CC Launch – December 2002

Aaron Swartz, Glenn Brown, Larry Lessig, preparing CC Launch – December 2002

Aaron Swartz interviewed by Dan Gillmor at CC Launch – December 2002

Aaron Swartz speaking at CC Launch – December 2002

I know there was one photo of Aaron, Glenn Brown, and me in front of the Supreme Court on the day of the Eldred argument, November 2002, but I can’t find it. I’ll keep looking.

Hugs to Aaron’s family and friends, we lost someone big.

Posted in personal | 1 Comment

The Onus is on Scientists – Shame on the AAAS

Posted on November 2, 2012 by ben

The American Association for the Advancement of Science (AAAS) has just come out against California’s Proposition 37, which would mandate the labeling of genetically-modified foods. In my opinion, the AAAS has failed its duty as promoters of Good Science.

The question is not whether genetically-modified foods are safe. I see the benefits, and I see the downsides (especially as a security guy, since food safety testing is, in my opinion, very poorly done), and the debate will rage on for a long time. But whether genetically-modified foods are safe is not the issue. The issue is whether consumers have a right to know what food they eat. There should be no debate here. Of course people have a right to know. And what better way to hear the people’s voice than to vote on this issue? The AAAS should be pro-labeling. If the AAAS believes that genetically-modified foods are, in fact, safer, as they claim in their statement, then they can make that point and rally the troops to explain to consumers that they should specifically seek out the GM-labeled foods. But withholding knowledge? Are you kidding me?

The world would be better off if people behaved according to scientific consensus. I wouldn’t have to worry about sending my kids to a school where up to 10% of kids might not be vaccinated, for example. But does that mean we should force parents to vaccinate their children? Of course not.

The onus is on scientists to make their case. Paternalism has no place in science. People have a right to know. The AAAS Board should be ashamed.

Posted in health, medical, policy | 4 Comments

connect on your terms

Posted on August 23, 2012 by ben

I want to talk about what we, the Identity Team at Mozilla, are working on.

Mozilla makes Firefox, the 2nd most popular browser in the world, and the only major browser built by a non-profit. Mozilla’s mission is to build a better Web that answers to no one but you, the user. It’s hard to overstate how important this is in 2012, when the Web answers less and less to individual users, more and more to powerful data silos whose interests are not always aligned with those of users.

To fulfill the Mozilla mission, the browser remains critical, but is no longer enough. Think of the Web’s hardware and software stack. The browser sits in the middle [1], hardware and operating system below it, cloud services above it. And the browser is getting squeezed: mobile devices, which outnumber desktop computers and are poised to dominate within a couple of years, run operating systems that limit, through technical means or bundling deals, which browser you can use and how you can customize their behavior. Meanwhile, browsers are fast becoming passive funnels of user data into cloud services that offer too little user control and too much lock-in.

Mozilla is moving quickly to address the first issue with Boot2Gecko, a free, open, and Web-based mobile operating system due to launch next year. This is an incredibly important project that aims to establish true user choice in the mobile stack and to power-charge the Open Web by giving HTML5 Apps new capabilities, including camera access, dialing, etc.

The Mozilla Identity Team is working on the top of the stack: we want users to control their transactions, whether using money or data, with cloud services. We want you to connect to the Web on your terms. To do that, we’re building services and corresponding browser features.

We’re starting with Persona, our simple distributed login system, which you can integrate into your web site in a couple of hours — a good bit more easily than our competitors. Persona is unique because it deeply respects users: the only data exchanged is that users wish to provide. For example, when you use Persona to sign into web sites, there is no central authority that learns about all of your activity.

From Persona, we’ll move to services connected to your identity. We’ll help you manage your data, connect the services that matter to you, all under your full control. We want to take user agency, a role typically reserved for the browser sitting on your device, into the cloud. And because we are Mozilla, and all of our code and protocols are open, you know the services will build will always be on your side.

All that said, we know that users pick products based on quality features, not grand visions. Our vision is our compass, but we work on products that fulfill specific user and developer needs today. We will work towards our vision one compelling and pragmatic product at a time.

The lines between client, server, operating system, browser, and apps are blurring. The Web, far more than a set of technologies, is now a rapidly evolving ecosystem of connections between people and services. The Mozilla Identity Team wants to make sure you, the user, are truly in control of your connections. We want to help you connect on your terms. Follow us, join us.

[1] David Ascher spoke about this in his post about the new Mozilla a few months ago.

Posted in identity, mozilla, privacy, security, web | Leave a comment

in praise of hands-on expertise

Posted on May 17, 2012 by ben

(I don’t usually share personal stories in public fora, but in this case, and with my wife’s permission, I’m making an exception.)

“Shoulder Dystocia,” said the Obstetrician, as we neared the end of my wife’s otherwise-routine delivery of our son last week. This meant nothing to me. My wife, on the other hand, freaked out. She’s a physician and had understood something I’d missed. My child’s head, which had only just emerged, began to visibly turn blue. I froze and, not for the first time in these medical situations, felt utterly useless.

What followed is best described as a highly coordinated dance. The Doctor started a set of rough and involved maneuvers, with stern orders to the nurse to apply pressure here, apply pressure there. The nurse pushed with one hand and grabbed the phone to call for help with the other. Within 30 seconds, before the additional help even arrived, a shoulder was out, one twist, and then the other. Our son cried and his color quickly turned pink. Cord clamped, scissors handed to me, I cut, doing my best not to shake from the adrenaline. The Pediatric team evaluated our son, and, 5 minutes later, he was in my wife’s arms. His left arm was visibly sore for a few hours. By end of day, though, the pediatrician was confident he had sustained no permanent damage.

So now, a few days later, I am beginning to understand. My son’s shoulder got stuck right after his head emerged. This happens in approximately 1% of births, though oftentimes the situation resolves itself. When it doesn’t, permanent nerve damage is a not-unlikely outcome, with reduced or even no use of the impacted arm. And, because the umbilical cord is compressed, the child cannot breathe. If my son hadn’t been delivered in the 5-10 minutes that followed, he could have suffered permanent brain damage or even died.

Instead, he is a perfectly happy 1-week old baby.

We’re so accustomed to things going well, we forget how quickly things can go wrong. We don’t often enough praise the folks in our society who have deep hands-on experience, with the training to react in a highly coordinated, rehearsed, scientifically proven manner in a matter of seconds. They’re the ones ensuring things go well. Most white-collar professionals, like myself, never need this kind of precise, automatic response. We see it in athletes, but we forget that doctors, pilots, soldiers, and a few others need it too. It’s a response so well learned it’s hard to imagine it could be anything but instinct. So we thank chance, fate, or some other mystical agent. We forget the role of these hands-on experts. We figure we can do without them.

Not so. In that one moment last week, decades of accumulated medical knowledge, analyzed by dozens of researchers poring over thousands of data points, condensed and taught to a team of doctors and nurses, rehearsed through years of training and ingrained through careful checklists, came together so that my son will never need to care that this ever happened. It’s awe-some, in the true sense of the word.

Posted in medical, personal | 4 Comments

encryption is not gravy

Posted on April 30, 2012 by ben

When designing a secure service that stores user data, you might be temped to say “let’s make sure the data is encrypted.” That statement implies that you’re proposing adding goodness, without taking anything away. Something like “I’d like some of that delicious gravy on my roast turkey, please.” Clearly, turkey with gravy is strictly better than dry turkey. Who can possibly say no to gravy?

Unfortunately, encryption is not gravy. There are deep consequences to the product you’re building once you choose to encrypt data, and the consequences differ greatly depending on the key management mechanism you choose. I wrote about this in part in my previous crypto-realism post, encryption is not magic:

For the most part, encryption isn’t magic. Encryption lets you manage secrets more securely, but if users are involved in the key management, that almost certainly comes at the expense of usability and features.

That last point bears repeating: if you design a system with encryption where users manage keys, you’re going to lose features. You want gravy on that turkey? Sorry, no stuffing for you. “What?” you say. But I want my stuffing and my gravy! I want to believe I can have it all!

I’ve been there, and I’ve made that mistake. A few times. Every fan of cryptography, everyone who’s ever glimpsed that awesomeness and beauty, wants to believe that they can have all their features and all their crypto. They want to believe so badly that, when the glaring missing features come to light, denial is often the only escape. I’ve done this in my work on voting and health-data systems. End-user crypto was appropriate, I thought, users would get it, I thought. It’s their vote, their health data! How much more important does it get? If users don’t care about crypto and accept some inconvenience in those cases, when will they ever care?

Exactly. Users won’t accept inconvenience. Because the inconveniences aren’t small. If users are left to manage crypto keys, that means their data disappears if they lose the key. This is a mathematical certainty that makes absolutely no sense to non-cryptographers. Even safe deposit boxes can be forced open if you lose your key. The most expensive cars have unlocking fallbacks. There is nothing in the intuitive physical world that maps to the helplessness of losing your crypto key.

Now don’t get me wrong. You can still use crypto. The voting system I’ve proposed still does, and I’m not arguing it shouldn’t. I’m only saying that, whatever crypto you use, involving the user as an agent in the cryptographic protocol is bound result in significant usability limitations, often deal-breakers.

so what are my options

Broadly speaking, you have three:

  1. full-strength, randomly generated, user-managed key. This is the most secure setting. Access to the full server data gives the attacker no useful information. Unfortunately, it is also the most difficult to use. Enabling a new device requires coordination with an existing device. If users lose all of their devices, e.g. if they only have one device and it breaks, there’s no way to recover.

  2. password-derived key. The data is encrypted with a key derived from the user’s password. This is not as secure as the previous setting, since most user passwords are not nearly as strong as full-strength crypto keys. However, as my colleague Brian Warner is exploring, it may be possible to still make it quite expensive to break into a single user’s dataset, and prohibitively expensive to go fishing for data across many user accounts. Usability is significantly increased: a user can set up a new device simply by typing in their password. However, the crypto conundrum remains: lose your password, lose your data.

  3. server-side security. Users don’t manage keys, and servers technically have access to the user data. A number of techniques can be used to meaningfully restrict the chance of a leak (e.g. disk encryption or other type of encryption where the server holds the key somewhere.) Security against insider attackers is not nearly as high as with the two previous solutions. This is, of course, how almost every service on the Internet works today. It is the only model that maps to user intuition, where a user can forget their password, lose their devices, and still recover. Because that’s how the physical world works.

where Mozilla fits in

We’re having important discussions about these issues right now. I gave a talk about these issues a few weeks ago:

Firefox Sync fits the first, most secure model, but suffers because it is not the product that users think it is. In particular, most users of Sync use it as backup. In practice, it’s not: lose your device, lose your data. It’s also impossible to set up a new device without coordinating with an existing device. We are looking at providing new services based on password-derived keys, so that users can set up a new device with just their password and, if they remember their password, recover from complete device failure.

There remains a problem if users lose their device and forget their password. How often might that happen? I fear too often to make this solution complete for all data types. We will probably have to solve this by providing different, configurable levels of security, with corresponding feature compromises.

The discussion is ongoing. We have to keep in mind that the dilemma is very real. End-to-End Encryption is not gravy. We cannot have it for free. The choice of encryption architecture is as much a product decision as it is a technical one.

Posted in cryptorealism, mozilla | 21 Comments