Thoughts on FF4 SSL UI Changes

19 views
Skip to first unread message

Stephen Schultze

unread,
Jan 18, 2011, 5:01:24 PM1/18/11
to
This group may be interested in a blog post I just did, going into some
detail on FF4 SSL UI changes. I'm curious what folks think.

Web Browser Security User Interfaces: Hard to Get Right and Increasingly
Inconsistent
http://www.freedom-to-tinker.com/blog/sjs/web-browser-security-user-interfaces-hard-get-right-and-increasingly-inconsistent

For those of you also on m.d.s.policy, sorry for the cross-post.

Mike Beltzner

unread,
Jan 19, 2011, 11:27:48 AM1/19/11
to dev-us...@lists.mozilla.org
On 1/18/2011 5:01 PM, Stephen Schultze wrote:
> This group may be interested in a blog post I just did, going into some
> detail on FF4 SSL UI changes. I'm curious what folks think.

I think your foundational premise is incorrect, sadly.

The padlock was incorrectly making assertions about security which the
SSL model could not back up. It was shown whenever an SSL connection was
present, which merely guarantees that there is a tunnel between two
endpoints present, and that tunnel is protected by encryption, meaning
that no other actor on the networks between those two endpoints can
casually inspect the content of the communication. While SSL makes no
guarantee that endpoint is who is declares itself to be, or that they
are a trustworthy actor in any way, academic studies on the topic (no
cites to hand, sorry!) showed that the padlock was communicating all of
this to users.

The DV model of SSL was created to address this, but quickly became
devalued as the competitive pressures of the SSL certificate marketplace
put a downward pressure on the requirements for domain validation, and
no standard practice was agreed to by various vendors.

The EV model imposes pretty stringent standard practices for CA vendors
to guarantee the *identity* of the entity to which an EV-SSL certificate
is provided, as well as assurances that a compromised certificate will
quickly be revoked and invalidated. These practices are standard across CAs.

Members of the CA/Browser forum responsible for that specification have
requested that browser vendors provide a standard UI presentation for
the presence of EV-SSL certificates. I have so far been very resistant
to that pressure because:

* it adds a design constraint to the interface design of browsers,
* I can't think of another product that has this consistency enforced,
* the specific mechanisms proposed have all been similar to the padlock,
looking for a single glyph or indicator which the user can identify as
meaning "safe" or "secure"

Fundamentally I do not believe browsers can tell users if they are
secure. We can (and should, and do not do this enough) tell users when
they are AT RISK. For example, submitting credit-card numbers on non SSL
protected sites is a known risky behaviour, and we should warn and stop
users from doing that. But we can't tell them that https://somesite.com
is "secure" just because it has an EV-SSL certificate. All we can do is
tell them that nobody is eavesdropping, so if they trust "Somesite Inc"
with their credit card information, then they're set.

Thus, I actually think that what you're seeing in IE9, Chrome 8 and
Firefox 4 and Safari 4 is a large degree of consistency: in all cases,
we make the *identity* of the endpoint prominent to users, and associate
that with a colour (green) that most cultures associate with "go" or
"clear" or "no risk present". The specifics of presentation are slightly
different, as per brand and design consistency, but the overall idea of
what we're presenting is quite conistent, IMO.

cheers,
mike

(note: Chrome makes the exception of associating green with SSL, which I
think is slightly problematic, just as I believe that Chrome, Safari and
IE's use of the padlock will continue to cause the problems of
over-interpretation that caused Firefox to drop it)

Steve Schultze

unread,
Jan 19, 2011, 11:58:31 AM1/19/11
to
On 1/19/11 11:27 AM, Mike Beltzner wrote:
> The padlock was incorrectly making assertions about security which the
> SSL model could not back up. It was shown whenever an SSL connection was
> present, which merely guarantees that there is a tunnel between two
> endpoints present, and that tunnel is protected by encryption, meaning
> that no other actor on the networks between those two endpoints can
> casually inspect the content of the communication. While SSL makes no
> guarantee that endpoint is who is declares itself to be, or that they
> are a trustworthy actor in any way, academic studies on the topic (no
> cites to hand, sorry!) showed that the padlock was communicating all of
> this to users.

Yes, I agree that this is a problem, as I note in detail in the second
paragraph of the post. The question is whether removing the lock and
making other changes in the manner it is being done is on balance worse.
The aspects of the FF4 decision that I think are problematic are:

* blue doesn't really signify anything, so it is not clear to users how
to check for baseline DV encryption
* the design is inconsistent with other browsers, causing user confusion
and difficulty with user education
* there has been no concerted effort on the part of Mozilla to do user
education on these changes

> Members of the CA/Browser forum responsible for that specification have
> requested that browser vendors provide a standard UI presentation for
> the presence of EV-SSL certificates. I have so far been very resistant
> to that pressure because:
>
> * it adds a design constraint to the interface design of browsers,
> * I can't think of another product that has this consistency enforced,
> * the specific mechanisms proposed have all been similar to the padlock,
> looking for a single glyph or indicator which the user can identify as
> meaning "safe" or "secure"

I am unfortunately not part of the CA/Browser Forum secret society, so I
don't have the benefit of having been a part of those discussions.
However, on your points:

* a voluntary standardization of browser UI is indeed a "constraint" in
that browsers would have to work together, but that is also a feature
* just because it is not common in other products doesn't mean it's not
a good idea here
* debate over specific mechanisms could be made much more dependent on
actual user studies rather than speculation by the parties involved

> Fundamentally I do not believe browsers can tell users if they are
> secure.

I agree here too. My point is less about specific indicators and more
about the process by which the indicators are chosen and rolled out.

> Thus, I actually think that what you're seeing in IE9, Chrome 8 and
> Firefox 4 and Safari 4 is a large degree of consistency: in all cases,
> we make the *identity* of the endpoint prominent to users, and associate
> that with a colour (green) that most cultures associate with "go" or
> "clear" or "no risk present". The specifics of presentation are slightly
> different, as per brand and design consistency, but the overall idea of
> what we're presenting is quite conistent, IMO.

In the case of EV, I would agree (with the exception of Safari and the
mobile browsers).

The major differences for DV are:
- FF is the only browser that gets rid of the lock
- FF is the only browser that uses blue (except for Safari Mobile, but
even there it is extremely subdued)
- Chrome uses green
- The mobile browsers often use identical UI for DV and EV
- The portions of the URL that are highlighted are inconsistent (ie:
Safari doesn't make the identity any more prominent on DV than on
non-encrypted)

Richard Matthew McCutchen

unread,
Jan 19, 2011, 1:51:53 PM1/19/11
to
On Jan 19, 11:58 am, Steve Schultze <sjschultze.use...@gmail.com>
wrote:

> * blue doesn't really signify anything, so it is not clear to users how
> to check for baseline DV encryption

Right, this is something users will have to learn.

> * the design is inconsistent with other browsers, causing user confusion
> and difficulty with user education

This may change in the future if other browsers adopt Beltzner's point
of view and make the same changes.

> * there has been no concerted effort on the part of Mozilla to do user
> education on these changes

I think this is a valid point.

--
Matt

Matt Brubeck

unread,
Jan 19, 2011, 5:44:23 PM1/19/11
to
Thanks for the link, Stephen. Anyone interested in this topic might also like to see the security UII for mobile Firefox 4.0 (a.k.a. "Fennec"). In Fennec, the background of the favicon area changes color to indicate EV (green), DV (blue), no SSL (gray), or broken/weak SSL (red). Tapping on the favicon reveals more security and identity information. You can see some examples here:

http://people.mozilla.com/~mbrubeck/screenshot-ssl.png

Mike Beltzner

unread,
Jan 19, 2011, 9:38:55 PM1/19/11
to dev-us...@lists.mozilla.org
On 1/19/2011 11:58 AM, Steve Schultze wrote:
> * blue doesn't really signify anything, so it is not clear to users how
> to check for baseline DV encryption
> * the design is inconsistent with other browsers, causing user confusion
> and difficulty with user education
> * there has been no concerted effort on the part of Mozilla to do user
> education on these changes

http://www.mozilla.com/en-US/firefox/features/#security
http://support.mozilla.com/en-US/kb/Site%20Identity%20Button

Our UX team has many designs that add more valuable and frequently used
functionality to the site identity button, all of which have been
deprioritized for two releases now (much to our chagrin!)

However, as we continue to iterate on the UI, I believe that clicking
the favicon will be the natural interaction point for "things to do with
the website that I'm connected to" and thus information about that
site's identity will become a pretty natural part of a user's task.

(As I stated earlier, though, the real key is for browsers to help users
understand when they are at risk, not try to provide unambiguous (and
inherently flawed) indicators of when they are "secure." This is the way
the real world works: nobody tells you that you're safe to share your
credit card number with a business, you make that judgement yourself
based on the information you have to hand.)

> I am unfortunately not part of the CA/Browser Forum secret society, so I
> don't have the benefit of having been a part of those discussions.

Oh, piffle. It's not a "secret society", it's a voluntary organization
and quasi standards body for the EV specification: http://cabforum.org/

The discussion list is archived here:
http://cabforum.org/pipermail/questions/

You may be interested, indeed, in this thread:
http://cabforum.org/pipermail/questions/2010-December/000446.html

(There is a members-only list for management and voting issues, too, but
I assure you we are not exchanging secret plans to rule the web on that
list, and indeed it's been ages since it's seen traffic)

> However, on your points:
>
> * a voluntary standardization of browser UI is indeed a "constraint" in
> that browsers would have to work together, but that is also a feature

It's not just a constraint in having to work together. Let's say that
it's decided that a "green URL bar" is the way to indicate "security."
Now let's say that Firefox 5 wants to look at removing the URL bar and
replacing it with a different widget - what's to be done?

The goal should be to standardize the task that we'll support (ex:
determining the identity of a site) and to co-ordinate on the terms and
"verbs" exposed to users, if not the specifics of presentation.

> * just because it is not common in other products doesn't mean it's not
> a good idea here

Sure, that's a fair point. And there are conventions like the pause/play
button glyphs that are used on all media devices, etc, but none of those
things are standardized.

> * debate over specific mechanisms could be made much more dependent on
> actual user studies rather than speculation by the parties involved

All user studies say the exact same thing about standardized security
UI: it is trivially defeated by malicious websites which will spoof
those UI bits. The literature is already there.

User studies are - I hate to burst your bubble - prone to confirmation
bias, and only truly useful as ways of determining what people do now,
not how people will think or feel in the future.

Though I concur that it would be best if any and all user studies on
security indicators was shared between the vendors, who could then
decide how they wish to act on them.

cheers,
mike

Steve Schultze

unread,
Jan 20, 2011, 11:52:00 AM1/20/11
to
On 1/19/11 9:38 PM, Mike Beltzner wrote:
> On 1/19/2011 11:58 AM, Steve Schultze wrote:
>> * blue doesn't really signify anything, so it is not clear to users how
>> to check for baseline DV encryption
>> * the design is inconsistent with other browsers, causing user confusion
>> and difficulty with user education
>> * there has been no concerted effort on the part of Mozilla to do user
>> education on these changes
>
> http://www.mozilla.com/en-US/firefox/features/#security
> http://support.mozilla.com/en-US/kb/Site%20Identity%20Button

Yes, and I'm arguing that those pages don't necessarily constitute
sufficient user education. And of course, user education/habituation is
substantially more difficult when browsers use different approaches.

By the way, the second link uses screenshots that are actually out of
date as of some point in the 3.x series.

> Our UX team has many designs that add more valuable and frequently used
> functionality to the site identity button, all of which have been
> deprioritized for two releases now (much to our chagrin!)

I'm not sure what you mean.

> However, as we continue to iterate on the UI, I believe that clicking
> the favicon will be the natural interaction point for "things to do with
> the website that I'm connected to" and thus information about that
> site's identity will become a pretty natural part of a user's task.

I hope so, and I'm not disagreeing that this is would be a good thing
(certainly better than the padlock regime).

>> I am unfortunately not part of the CA/Browser Forum secret society, so I
>> don't have the benefit of having been a part of those discussions.
>
> Oh, piffle. It's not a "secret society", it's a voluntary organization
> and quasi standards body for the EV specification: http://cabforum.org/
>
> The discussion list is archived here:
> http://cabforum.org/pipermail/questions/

Fascinating. In all my previous searching I never came up with that
list link. It's not linked from the CAB Forum site, and I couldn't even
construct a google search just now that would give it to me. I'm very
glad that it is available, and appreciate you pointing it out. On the
other hand, there is still a great deal of CAB Forum activity that is
restricted to members, and I'm glad that folks like Gerv are at least
persuading them to occasionally share draft documents with the rest of
the world that does not qualify for membership.

> You may be interested, indeed, in this thread:
> http://cabforum.org/pipermail/questions/2010-December/000446.html

You're right, there's some great stuff in that thread, including this
study by Comodo (PDF link at the bottom):
http://cabforum.org/pipermail/questions/2010-December/000457.html

And Rich Smith's suggestion here:
http://cabforum.org/pipermail/questions/2010-December/000471.html

Your response to his post I think maps out the difference of opinion well:
===
mbeltzner:
Put plainly, let's say we decide that "Identified" and a 12-pointed star
(✹) meant "Identity has been verified". That is I think as far as this
group should go. Whether or not browsers decide to place that in the URL
bar, or the status bar, or badge the favicon, or in a dialog that users
can call up when trying to establish identity ... that's up to them.
However, only websites with verified EV SSL certificates can be called
"Identified" and use the 12-pointed star. That sort of standardization
is what we should be aiming for, and is consistent with the way web
standards are authored in my experience. It's also consistent, I think
you'll find, with how business practises are established for obtaining
EV SSL. We don't tell you how to architect your servers, or what prices
to use, or even how to market EV SSL (though I'd like to use the
consistent terminology we agree on for your marketing purposes, as well!).
===

>> * a voluntary standardization of browser UI is indeed a "constraint" in
>> that browsers would have to work together, but that is also a feature
>
> It's not just a constraint in having to work together. Let's say that
> it's decided that a "green URL bar" is the way to indicate "security."
> Now let's say that Firefox 5 wants to look at removing the URL bar and
> replacing it with a different widget - what's to be done?

Er, continue to work together to decide what browsers that don't have a
URL bar should do?

> The goal should be to standardize the task that we'll support (ex:
> determining the identity of a site) and to co-ordinate on the terms and
> "verbs" exposed to users, if not the specifics of presentation.

Yeah, and I think I'm more persuaded by Rich Smith's position (although
I might substitute "consistent" for "conspicuous":
http://cabforum.org/pipermail/questions/2010-December/000473.html
"I think that having something conspicuous is necessary in order to
properly communicate it to the end user who typically doesn't understand
either identity or security when dealing with internet transactions."

>> * just because it is not common in other products doesn't mean it's not
>> a good idea here
>
> Sure, that's a fair point. And there are conventions like the pause/play
> button glyphs that are used on all media devices, etc, but none of those
> things are standardized.

True, but in the case of UI elements like those they are essential for
the primary task of operating the product. Security indicators are
secondary and non-essential to "getting the thing to do what you want"
even though they are important. Users inevitably encounter a need to
figure out where the play button is in order to watch the media, but the
same is not true for security indicators. In addition, they communicate
more abstract concepts than "mash this to make the media go."

>> * debate over specific mechanisms could be made much more dependent on
>> actual user studies rather than speculation by the parties involved
>
> All user studies say the exact same thing about standardized security
> UI: it is trivially defeated by malicious websites which will spoof
> those UI bits. The literature is already there.

So am I right in hearing that you are arguing that different UI's are a
good thing because it's harder for attackers to spoof them all? This is
an interesting argument I haven't heard before. Of course, I see no
reason why sslstrip or the like couldn't just as easily detect the
user-agent and customize appropriately.

> User studies are - I hate to burst your bubble - prone to confirmation
> bias, and only truly useful as ways of determining what people do now,
> not how people will think or feel in the future.
>
> Though I concur that it would be best if any and all user studies on
> security indicators was shared between the vendors, who could then
> decide how they wish to act on them.

No doubt user studies have problems, but they are of course very useful
for determining how users experience current interfaces and how they
react to prototypes. If the alternative is speculation by each browser
vendor, it seems clear that voluntary collaboration by the browsers,
informed by user studies, is superior.

Reply all
Reply to author
Forward
0 new messages