So we need to get better. We need to start fixing our messages to users so that we are more accurately communicating security information, while being mindful to not bury them in technicalities they neither want nor need. We need cues that are persistent (not relying on people to notice their absence), that are difficult to spoof, and that don’t mix metaphors.
We also, difficult as it is, need to get out of the “safety” game. We can’t tell users “this site is safe” because we don’t know that. Even ignoring the liabilities that might come with such a claim, there isn’t a good technological way to tell, right now, whether a particular site is safe in the way users care about. Do they handle credit card information properly? Do they ignore angry customers? Are they a front for stolen goods? These kinds of naughty people could get SSL certificates (and accompanying padlocks) and even the extended validation practices being discussed wouldn’t really stop them.
What we can do is equip people to make the safety decision for themselves, just as they often have to in the physical world, because we do have some information. It’s like putting ingredients labels on food. What we can do is change the conversation to be about identity instead of safety. This is important, so pay attention:
We need to change the conversation to be one about identity, not safety.
Identity is something we can verify. The padlock conflated identity with other things like encryption status and security, and while that conflation is almost natural to PKI-veterans, it has proven misleading for users.
This is a preliminary mockup, and mostly it demonstrates my inability to draw. Having said that though, it’s something I’d like to see us looking at for Firefox. The idea is that as soon as the user starts loading a page on a site they’ve never visited, Firefox tries to identify it.
Why The Dude?
He is the international standard passport guy. I call him Larry.
If we’re going to be making a change like this, to talk about identity instead of security, then our visual language needs to reflect that too. I’m not at all stuck on the passport dude in particular, but he is iconic, somewhat visually simple (though not as much as I might like), internationalizable, and already familiar to a large percentage of the population, in a role not unlike the one he would be playing here (i.e. a verifier of trusted identity documents).
Other thoughts have included:
- The blue i for “information”. Visually simple and already in common use, but we’re looking for something a little more specific than just generic “information.” It also might not internationalize well to non-latin alphabets.
- A simpler icon representing a passport (i.e. sans-Larry). This would seem to get us over the visual simplicity hump, but it’s hard to distinguish a passport from a generic book without resorting to either fine detail or language, both of which hurt us here.
- Very simple icons like ? or checkmarks in place of the lock. There isn’t a visual constant (like Larry) to tie the icons together in this case, which risks leaving the icons as visual clutter, and users without a clear idea of what they represent.
But other ideas (or more attractive, royalty-free renderings of Larry) are certainly welcome.
How Does It Work?
To avoid being profoundly irritating, I’m thinking we don’t get in your face on sites that have already been checked out once. In all cases the little dude will live in the address bar, to be interacted with as and if desired, but only on new sites will the speech bubble and text come up. This means that on, say, a phishing site, the speech bubble is basically guaranteed to pop up, actively informing the user. The fact that the speech bubble crosses between chrome and content area is something that also makes spoofing more challenging.
Technologically, what’s happening here is that we’re looking for an EV or other high-assurance certificate. This is a precursor to loading an HTTPS connection anyhow, which means this can be happening before content is presented, minimizing the impact on actual web interactions. And yes, those among you who know how this works might object to the claim that Firefox is “verifying” – it takes us milliseconds to verify an SSL cert’s validity and we’re really only checking an OID attached by the CA. But it’s a sensible mental model to develop with our users, I’d argue.
Firefox verifies, and then, assuming everything’s super, we get:
After a few seconds (or on any activity within the content area, scrolling, mouse clicks, or typing) the bubble will collapse back into the address bar icon and get out of your way. This collapsing action helps tie the two pieces of presentation together, and invites the user to interact with the address bar entry in the future. On mouseover or click, we can bring the speech bubble back up and so reinforce our users’ behaviour to go here when seeking information.
The visuals, once again, are open to design revision, but the key takeaways are that when a site can be properly identified, we:
- Change the visual treatment to reflect the fact that we have received valid identification.
- Show the user a meaningful, verified business name, giving the user something other than only the domain name to work with.
- Identify the party responsible for verifying that identification, since there has been, until now, very little way for a user to make informed decisions about which CAs they trust – the supposed root of the entire public SSL infrastructure.
- Provide them with a discoverable method to get more information.
If that last bullet makes you wonder whether we are also looking to change the way we present the “Page Info” dialogs, you get a gold star. That is another blog post though.
Identity Unknown
When the site cannot be identified, we get this instead:
Personally, I think that text is a little wordy, though less so than my first attempts. We have to be mindful here not to make every site without an EV cert feel criminal. Even the red in the question mark might be too harsh, but again the key design points are:
- The visuals have been weakened – lower contrast, question marks. The idea is not to portray danger, just uncertainty.
- Instead of identifying company and verifier, we have only some text to elaborate on the situation. Must be kept to a sentence, and ideally a short one, so that it has some chance of being read.
- Once again, there is a call to investigate the page further should the user desire. Once again we are putting the decision making power in the hands of the person who can make it. Ingredients on a soup can.
Putting It All Together
Changing the conversation about web security is easier said than done. And it’s easier to bitch about the padlock than it is to try to put something new out there. But passive, intermittent, spoofable and misleading security cues really are a bad thing because there are lots of bad people out there. The design I discuss here is evolving, but it is persistent, elaborative, difficult to spoof and avoids complicating things with mixed metaphors.
There are pragmatic issues aplenty, of course. This blog post isn’t intended to delve into all of them, but a couple we’ll need to look at are:
- How to handle self-signed certs or CA-issued but non-EV certs that you are confident you can trust. Answer: probably we just let you manually add those certs, at which point they get the checkmark, and read “Verified by: You.” This task needn’t be particularly easy or prominent in the UI, since it’s somewhat rare, and relatively expertish. It’s not like you can’t proceed without it.
- Do we have the right set of information in the speech bubble? Should the domain name be there too? Is it more likely to help, or hinder, decision making?
As for the padlock, I think it has had its day. That’s a hard thing to say for me not just because I remember its birth, and have lived with it ever since, but also because it has a very significant amount of user learning behind it and that’s a hard thing to abandon. But that inertia can’t keep us stuck somewhere we don’t want to be. If the padlock had all that hifalutin learning behind it, I dare say that phishing incidents would be somewhat rarer than they are, and a bad idea doesn’t get better by being old.
I’m not opposed to displaying the padlock as a secondary indicator somewhere for users that want to dig for it, as an emblem purely of encryption (as it was, arguably, initially intended). But I think its time as the primary security indicator is ending.
What do you think?
[N.B. I know beltzner hates it when people ask open-ended questions like that, but it turns out I already know what he thinks. And he gets partial credit for much of this thinking, having been Mozilla’s sit-in on a lot of security UI stuff before I came around.]
meandering wildly 
What would you do about http (non-SSL) sites? If we’re going to treat non-EV certs as really not providing any identity, we should use the same UI for them as for completely unsecure communications, no?
I think that there are two additional things that we should consider:
1) Have a social identity system: e.g. many people visit their bank and are pretty sure that it’s their bank. When I visit the bank, Firefox compares the cert against the one all my neighbors trust. Of course this requires a “SLL phishing” provider.
2) Most of the time I don’t care in advance where I put my credit card number: the fraud protection on the credit card will cover me. But if there is a problem, I’d like to have a log of all the places I entered my card number, and what certificate they were using.
–BDS
@BDS
Yes – I would absolutely agree that non-ssl sites aren’t identified, and hence get the same treatment. I was deliberate in not mentioning SSL in that section, but I ought to have more explicitly mentioned non-SSL, so thank you.
1) Yes, I’m a big fan of both social identity and 3rd party safety providers (BBBonline, resellerratings, etc). I don’t know if we can introduce a vendor-specific dependency into the core without an existing standard around such things (our vendor dependence on CAs has specs behind it and other roots can be added, ditto our vendor dependency on search engines.) I do, however, think it would be great to see some addons hook into the identity & page info UIs to provide more comprehensive detail.
2) Interesting! I wonder how much of that we get for free with the work that’s happening in History/Bookmarks world. I’ll ask around.
Covering part of the content area every time I visit a new site would become annoying very quickly.
If you are saying get rid of the padlock, what about changing the color for an SSL secured site too? I really think IE7 does it better with green being good, and red being bad. Sure, we’ve used yellow all along, but if we are getting rid of the padlock, it’d be good to make other changes too. This way it’s not just one thing that’s changing, it’s the whole system, and will have a higher chance of being noticed by the user.
Random comments from the top of my head:
It would be interesting to explore notifications with stronger binding to the chrome. A site can spoof anything in the content area, so the only non-spoofable bit is the little triangular wedge connecting it to the URL bar. I bet that’s enough to trick or confuse most people.
I think the EV vs non-EV notification is going to be really hard to get right. If the difference is too strong, it trains users to ignore the notification because most sites will be legit yet non-EV (ie, don’t cry wolf). But if the difference is too weak, there’s not much benefit to having an EV cert and the notification is just another padlock flavor. [By that, I mean: users won’t expect to see an EV-positive notification, and if anyone can get a non-EV cert then “Verifying” that identity doesn’t really accomplish much.]
But this is sure a step in the right direction…
You haven’t documented whether this change is chrome-count-neutral. Have you removed a piece of chrome for each one you’ve added?
Possible wording: “Firefox cannot identify who owns this web site” or “Firefox cannot identify the owner of this web site”.
I like it though.
You are smart. This is why the hired you.
Because I can best look at the graphics angle, I kind of like the passport dude, but I agree he’s kind of detailed for such a small space. People like me who use huge screen dimensions would never see it in detail, and while its mere presence may be enough, it’s nice to have something a little more iconic. What about something that looks like a certificate stamp?
I really like the ideas being discussed, but like Jesse said, having a dialog box come up for every new site would be very annoying. What about like a small strip like the “Popup blocked” one that comes up now? It would leave little space for “Larry,” but could display the relevant information much less obtrusively.
“Firefox cannot identify the person or business that owns this web site” – that’s probably good to know but I imagine an unexperienced user asking himself what he should do with it. Should he immediately close the window? Or is it just some non-sense and you can proceed without second thoughts? Or what? Good UI should not leave such doubts.
Also, if this UI gets overused users will simply ignore it. Having this bubble appear on every new non-SSL site you visit is rather pointless if not harmful IMO.
I like the text baloon idea and Larry too. I agree it’s time for the lock icon to go. It’s time for the address bar, and not the status bar, to be the non-optional piece of chrome, not spoofable by phishers.
I don’t think we want to treat non-EV certs the same as self-issued certs. Non-EV certs from CAs have had SOME information verified by a third party, even if it’s only that the applicant has some control over the domain in which the named host resides. Self-issued certs have nothing verified by a third party. They offer nothing but “proof by assertion” (as a famous cryptographer put it so sarcastically).
The baloon you called “Identity verified” really means two things: (a) you’ve got an impenetrable opaque pipe to the server that really is the host named in your URL, and (b) we know the identity of the party who owns/runs it.
The baloon you called “Identity Unknown” means we know neither of those things.
In between those two, there is a state that means (a) you’ve got an impenetrable opaque pipe to the server that really is the host named in your URL, but (b) we cannot identify the owner/operator. There’s still value in differentiating that from “Identity Unknown”, IMO, especially since the majority of https sites will be in that category (at least initially).
I’d like to give a strong yay on the shift to identity. It’s sweet, simple, just right.
I bet there are tons of technical details, in particular, when to display it and when not. One trigger I see would be whether the page has a form on it or not.
Do we need to care about https://people.mozilla.org/~axel/mybadform.php vs https://people.mozilla.org/~timr/mybadform.php? (Sorry, Tim)
As for the bubble, this is composing strings from different realms in terms of RTL, possibly, not sure how to get that right, but asking the affected localizers for input might be a good idea. But that should probably wait ’til we’re in a much later state of this discussion.
I do like Larry, some anti-aliasing and he’s cool. Funny thought in my head, could a pictogram with a person make people think that we’re actually sending their URLs to some office in India or the Balkans to visually check? Maybe it’s something that can be easily worked around by the right wording around Larry, I’d rather keep him than drop him.
Having a negative indicator has the disadvantage that it needs to appear on 99.9% of websites, including all those not secured with SSL – which means it can’t be too intrusive. Having a positive indicator at least has the advantage that you can make it bigger and bolder.
Then again, if you only have negative indicators, it’s never in anyone’s interest to spoof them.
So if you have both types, you get the worst of both worlds. The existence of a negative indicator means you have to display it almost everywhere, potentially annoying the user. The existence of a positive indicator gives phishers something to spoof.
Also, a problem with saying “Firefox cannot identify the person who owns this web site”, is that the user will think. “Well, duh! I can – it’s written right there on the page.” And if you make the language stronger, then you stigmatise legitimate websites which have nothing to do with money or finances.
My view on this is that you will never get users to make such decisions. They just don’t care enough. There are 50 CAs in our current root store. Are we really going to expect them to have an opinion on them all? If they don’t recognise the CA, what do they do? If the answer is “visit anyway”, then brand recognition becomes a positively bad thing for a CA to have. If the answer is “don’t visit”, then they’ll be not visiting a lot of legitimate sites.
It’s our responsibility to pick a set of trustworthy CAs. The user already trusts us – they’ve installed our software on their machine.
Good stuff!
Mindful indeed, as we could find ourselves starting the next phishing revolution. If you are assuming that in some sense EV “solves the identity problem” then consider that EV only represents the old model, done again, but this time “with feeling!” There is nothing fundamentally new in EV, so how is it possible to select it as the future answer to … anything?
Consider, if the contrast is between “EV identifies this site” and “Firefox can’t identify this site” then you are suggesting that all Firefox identifications until the moment this change is rolled out … 2008? … were and are false. Do you really want to say that anything identified by Verisign until now was … not acceptable?
There is a fairly large spectrum of statements being made, and trying to get the whole lot compressed into one binary indicator “GOOD” or “BAD” is precisely the trap that the padlock fell into. The way forward is not a new padlock, not a new binary indicator, but is a capability to deal with that spectrum of statements:
Verisign said this is Mozilla.org
EV/Verisign said this is Bank of America
Startcom said this is First Peoples Bank
CAcert said this is MySecurityBlog.com
You said last time that SelfSigned.com was cool
EU/CertServices said that BundesTaxes.de was ok to post yous tax return…
In that all, we need “authority” statements from various authorities, and we need also “self-authority” statements, because classically, CAs do not know as much as the user knows about her secure sites (quick test: what do you know about your bank? What does a CA know about your bank?).
So we also face the need to integrate the user into the negotiation (which is to simply re-state Kerckhoffs’ 6th). Looking forward with interest to how that negotiation pans out 🙂
It sounds like a couple of great ideas, which I really hope will make their way into Firefox 3. You really hit the spot on what’s wrong with current security UI, I think, and how it has to be.
~Grauw
One thing that came to my mind is—maybe you shouldn’t depend on EV too much either.
A yellow/green address bar really conveys a strong subliminal message, I think. If people are used to a green bar for their bank and suddenly get a yellow one, they will immediately notice something’s different.
So, that makes me think: wouldn’t it be a good idea to make the address bar not green based on whether it has an EV or not, but based on whether you at some point in the past said ‘yes, I trust this website’ through some simple and unobtrusive interface.
Well, maybe it’s superfluous if you’ve already got the Larry-popup appearing on a site which you have never visited before. Then again, will people recognise that the Larry-popup appearing again means that something strange is going on, or just ignore it because they see it so often anyway? I think the latter.
So, explicitly indicating you trust a site (or rather: ‘recognise’) still seems like a good idea to me. If I could do that with my bank and Paypal with just a few simple clicks, I’d feel a little more comfortable.
~Grauw
Laurens,
the user indicating that they trust a site has been experimented with in toolbars like Trustbar and Petname and other research projects. It works well.
It has one “flaw” in that it involves the user. That is, we would ask the user to indicate their trust of certain sites. That is a cost.
Now, is this a flaw? The conventional browser wisdom has it that the user won’t be involved in anything, and that the security must start up in secure mode, first time, without any user interaction. (Perhaps the Skype model is the best current example, and the padlock model is a now out-dated example of this.)
However, in the security world, we also know that this can only really deliver average security in a static scenario. It raises significant barriers, but because security is a dynamic field, it can do no more than mitigate the easy or routine attacks. All serious high-level security situations involve the user as part of the protocol, at some level or other.
Phishing, etc, has now crossed that rubicon, and we are dealing with active, aggressive targetted attacks. So security thought might suggest that we can no longer rely on the default “user does nothing” approach, and that we need to engage the user in part of the security protocol.
If, that is, we want to secure the user against an aggressive attack. I guess the cost to the user of not wanting to engage in the protocol is that they only get some sort of base grade, “what you get for free” protection?
Maybe this is should be left as their choice; it is for example no particularly sensible objective that we should impose our security standards on the users, as generally the users will understand their local conditions much better than we (developers, pontificators) do.
I’ve seen another alternative. The implementation is quite unpolished, but the idea is nice: http://www.cs.biu.ac.il/~herzbea//TrustBar/
A blue ‘i’? Please!
As someone who oversees a public CA (no, not the one you’re thinking of 🙂 ), I’m reacting to the implication that there will be a bright line between “EV=trusted” and “everything else=untrusted”. Granted, if the number of steps a CA takes to give someone an SSL certificate for their host/domain is the same as the number of steps to get the original domain name in the first place then the notion of who or what is being identified is identical as well.
But some CAs do more than send an email ping to confirm that the applicant has possession of the domain name in question, or that they still have a (someone’s) valid credit card. You can’t lump all non-EV CAs into the same category. When a CA is missing the EV magic sauce it doesn’t mean that FF should throw up its hands and put the entire burden of validation on the user (“Verified by: You”) either. Speaking for my company, we’ve spent considerable money and resources building an infrastructure that protects people’s credentials and financial information via SSL transport encryption and provides a hint to savvy people that the site they’re connecting to is who it claims to be. We stand behind those certificates and have established a reputation on them, despite not having built everything again with a special magic OID to denote EV-ness.
I really like that idea. The implementation is pretty simple (except for the bug where xul can’t float over html), and it doesn’t rely on the site having an EV cert. What do you think it should say for a non-ssl site?
that’s why it will never wor. Mihangel Caiaphas.
I downloaded the 12/21/07 nightly and installed it.
First, I’m reading bug reports talking about Larry and I’m seeinig nothing on EV sites. Then I finally read something that says to click the favicon. What is the point of building a new UI feature you are going to hide.
I agree, there is a difference between encryption and identity even though if you have a certifiicate that identifies a site it also gives you encryption.
I personally think if you are going to have an icon for identity then the padlock has to be the encryption icon. The duplication I see between the padlock and this larry thing seems dumb. Either separate the features or keep them as one icon.
Second, Larry needs an icon it can’t be a hidden feature. What is the point of spending all that time codeing to hide it.
Lastly, I don’t care what you think about EV and its useful or uselessness, it is out, and costs $$$. Companies expect to get something special in the UI for the extra $$$ they paid their CA. I don’t care if that is the green bar or a special designation in Larry (provided Larry is clearly visible).
@Kevin B: I find it interesting that people who write combative, declarative comments nevertheless adopt a tone that suggests they expect thoughtful and engaged replies, when their choice of language undermines the possibility of any such thing.
Instead I’ll refer you to blog posts more recent than May, to bugs like 406612, and to the general premises that:
a) Assuming your counterparty is an idiot is never a fruitful way to foster discussion, and
b) our obligation as browser vendors is to our users. Neither the amount of money CAs charge their customers, nor the expectations of those customers, is of any concern whatsoever to us except insofar as the product they sell provides more value to our users.
“@Kevin B: I find it interesting that people who write combative, declarative comments nevertheless adopt a tone that suggests they expect thoughtful and engaged replies, when their choice of language undermines the possibility of any such thing. ”
Ok, point taken. I guess I was getting frustrated. I haven’t been in bugzilla much the last couple of years bug decided to find out what was going on with EV in Mozilla. I was skimming bug 383183 and one of the first links was to this Blog.
Anyway, the frustrating thing I’ve been finding is that many bugs related to this are closed, yet, running the 12/21/07 nightly I had to uncover Larry because it wasn’t intuitive that it was even there and even when I did find Larry, EV sites didn’t show up any different.
Just a note to let you know that the link to
Click to access Signs&symbols.pdf
is broken.
http://www.aiga.org/content.cfm/symbol-signs
may be a better one.
Thanks Gen!
I saw Larry on beta 5 – nice!
Is there an interface to this feature? Can I, as a security related extension developer, use Larry to display some more info?
@hashi: The panel itself is in browser.xul, and most of the IdentityHandler() code is in browser.js, so in principle you should be able to interact with it from an extension like other chrome code. If there is something specific you’re interested in doing, I can try to be of more assistance.