Why .Secure? Part I: Listening to the User

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:

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 21^st 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.

Image by Susie Blackman

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.