Why .Secure? Part I: Listening to the User

“Security and usability must not be in conflict. If it’s not safe, it’s not usable; if it’s not usable, it can’t be used safely.”
            – Chris Palmer, circa 2008

If you are one of the dozens of people who have found this blog you undoubtedly have heard of our controversial conversation-starting proposal to operate the .secure TLD.  I thought I would take this opportunity to discuss our motivations for going after this part of the namespace before diving into more technical details.

The Internet experience is completely broken for the vast majority of the world.  Of all of the problems that could lead one to this conclusion (I18N, governance, the inability to leave behind 1970’s technology) I would like to focus on an area somewhat within my expertise: trust and safety.  As you read this, on this planet someone is using a laptop on a café wifi network to pay a bill, over there that person is clicking on a link from an SMS message, and a lot of people are sending private information in an email.

If you interrupted any of these people and asked verbally if they trusted the Internet, or more specifically the technology they held in their hand that moment, they would likely hear the leading tone in your voice and answer “No.”  Yet apparently they each believe that the likelihood of a negative outcome is so low that there is no need to think before performing these actions.  Why do they think that?  In the developed world I would guess this “trust” derives from the trust we have been trained to put into all technology.  Do you carefully read a status message and push the correct button to keep your car from exploding?  Do you have to perform a risk assessment each time you cross a bridge?  No, you do not, because the engineers behind these types of products understand risk management under real world use and a great deal of thought is put into fool-proofing them against even a first decile consumer.

Should we blame them that they expect the same from us, the software and security engineers who build the shiny things they love?  When a normal, intelligent educated person picks up a $400 device with the computing power of Apollo-era NASA they naturally assume that somebody has taken care of problems like “click on the wrong link and my phone turns into a spam sending zombie”.  Sure, they read about malware, and hackers, and account take-over… “Heck, Aunt Julie had her identity stolen last year, and nobody figured out how.” I think it’s clear that even the most aware consumer still assumes that there is a man behind the curtain.

Which brings us to our topic, misplaced trust in the web.  This is a dialog that perhaps hundreds of thousands of people see each day:


Safari Certificate Error


Imagine that your uncle calls you, asking which button it is safe to push.  Where do you start the conversation?  An introduction to discrete mathematics?  A treatise on the difficulty of factoring large numbers across a finite field? An introduction to the X.509v3 standard?

I have deep sympathy for the browser engineers who maintain this code; they have been given the impossible job of creating a user experience that warns a user without bothering them and that allows a user to accept a risk they almost certainly do not understand.  We have come a long way from the completely obtuse dialogs of the past, but I doubt the average user is more likely to make the correct choice than they did with IE4.

One of the key goals of .secure is to invert the user’s security experience.  The human does not exist to serve the software.  Why does the user politely ask “I would like to go to my bank” and then need to interpret the 21st century pixelated entrails to determine if they arrived at their destination safely?  The user is in charge; they tell the software what they want, and it’s our jobs to make the software listen.



In my view, .secure is not a category, it is an expression of intent.  When a user types bank.secure, they are not saying “I want to go to the bank in the category of secure”, they are saying “I want to go to my bank securely”.  That means that all of the software standing between them and their destination needs to understand this intent, and then make the thousands of small decisions needed to make it so.   .Secure and the Domain Policy Framework are not the only ways to make that happen, but I believe they are the most expedient.

Posted from the sidewalk in front of Cafe Nero (cafes close at 8!?!), Waterloo Bridge, London

One response

  1. Pingback: Introducing something that might become the Domain Policy Framework « Unhandled Exception

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 104 other followers

%d bloggers like this: