Closed Bug 414627 Opened 16 years ago Closed 16 years ago

Decide default amount of site-button text for DV-SSL

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: johnath, Assigned: johnath)

References

Details

Attachments

(2 files, 1 obsolete file)

What should the default setting for the "browser.identity.ssl_domain_display" pref be, for the presentation of domain info in SSL?  

Bug 406612 introduces the pref, but keeps the presentation as-is, with the pref at 0, but setting it to 1 would certainly add discoverability and feedback, and still constrain us from the total duplication of the url bar contents.  I think this is my preference, but it does mean that the site button ends up more intrusive in those cases.

The patch is extremely low risk, we just need to decide which state we want as default.

I propose changing the default to 1, for the sake of spawning discussion.  I've copied people I could remember who had expressed an opinion on the subject.
I personally think we should try setting to to 1 to see what kind of feedback we get during the next beta.
Having it at 0 basically defeats the point of the feature. Betas are for testing; let's set it to 1, and ask people to look out for sites where the result is misleading.

Gerv
I've been using it with the value set to "1" for a while now and I think it's the most sensible default.  Looks fantastic on the mac theme, too!
Obvious patch.
CC'ng people that I seem remember complaining about earlier versions of DV text, lest I seem to be stacking the deck (which I am!  Because I think evidence points towards it being a good idea!  But that doesn't mean we can't argue about it! :)
It's repetitive and ugly. It also interacts poorly with autocomplete. Really wish we could could lose this location bar fetish.
Also it collapses when you navigate from an SSL site to an HTTP site, making the navigation transition even worse than it already is. Text that slides around is really, really wonky.
Of course, all of these criticisms apply to EV as well. When I first mentioned these, like *6 months ago*, I expected some of them might get dealt with. Instead, we're landing in some really late beta with all of the same problems.

It's pretty frustrating.
So I know Rob's removed himself from CC after commenting, but to address some of these:

 - Repetition is worth avoiding, and it's the motivation behind eTLD+1 instead of full domain, but it's got to be balanced against other things.  Location bar fetishism, at least in this case, has to do with the fact that it is where users look for identity information [1].  Having no text there reduces at-a-glance feedback, as well as discoverability.  If this bug doesn't get resolved, that's what we'll get, and having a site button for users who want to ask the question is better than nothing, but it misses an opportunity to improve things, imo.

 - Interaction with auto-complete (if I understand that correctly to refer to the ~9px misalignment between the dropdown and the favicon) is, afaik, not related to this bug, though I agree it's a good polish thing to fix. 

 - Navigation within a site that is consistently secured at a given level (DV or EV) doesn't cause the box to change (at least, when tested at paypal on current trunk), but it's true that navigating to a different site does.  I guess I just find this less jarring than others, but to me, it disappears inside the peripheral motion of the url changing and the page content changing.

 - It is late in the Beta cycle, but it's taken that long to get the themes up to date on trunk.  Early attempts to land unpolished versions were met with a fair bit of "temporary, for now" resistance (see bug 402260, for instance) so I think, given that there's little or no code risk here, that now's an appropriate time to re-evaluate how it should look in the final.  But I would be only too happy to see it in betas, since I think that's preferable to the academic work we have to go by currently.

It's a pref, so whatever decision we make, individuals will have the ability to change it, this is really about whether we think it will be more helpful with or without text in this case, given the tradeoffs that Sayre has pointed to.

[1] http://people.deas.harvard.edu/~rachna/papers/why_phishing_works.pdf
(In reply to comment #9)
> So I know Rob's removed himself from CC after commenting, but to address some
> of these:
> 
>  - Repetition is worth avoiding, and it's the motivation behind eTLD+1 instead
> of full domain, but it's got to be balanced against other things.  Location bar
> fetishism, at least in this case, has to do with the fact that it is where
> users look for identity information [1].

The main finding, hidden in the bad writing of that study, is that users look at /content/ for identity information, while the location UI is secondary or tertiary. Also, I've used the study before to support an argument, but I think we should stop--the sample size is too small to take it seriously.

That said, I also forgot to mention another 6-month old problem with doing this for DV certs: aren't we highlighting information that we can't verify?

> 
>  - Interaction with auto-complete (if I understand that correctly to refer to
> the ~9px misalignment between the dropdown and the favicon) is, afaik, not
> related to this bug, though I agree it's a good polish thing to fix. 

No. I am referring to the fact that autocomplete results are placed under the "identity" indicator 

http://people.mozilla.com/~sayrer/2007/09/06/hmm.png

We've painted ourselves into a corner that can be only solved with a text-moving transition effect. Those get tiresome.

> 
>  - Navigation within a site that is consistently secured at a given level (DV
> or EV) doesn't cause the box to change (at least, when tested at paypal on
> current trunk), but it's true that navigating to a different site does.  I
> guess I just find this less jarring than others, but to me, it disappears
> inside the peripheral motion of the url changing and the page content changing.

More text-moving is bad. I guess you can claim it's a drop in the bucket, but other browsers are pretty calm compared to us.

> 
>  - It is late in the Beta cycle, but it's taken that long to get the themes up
> to date on trunk.  Early attempts to land unpolished versions were met with a
> fair bit of "temporary, for now" resistance 

This bug makes that resistance look like a smart reaction, tbh.

> 
> It's a pref, so whatever decision we make, individuals will have the ability 

That argument is irrelevant to me. The browser should have input devices that don't move around, by default.

[My drive-by, don't over-rotate or write too many words in reply :-P. Do focus on the particular points. /be]

(In reply to comment #10)
> That said, I also forgot to mention another 6-month old problem with doing this
> for DV certs: aren't we highlighting information that we can't verify?

This seems like a fatal flaw.

> > It's a pref, so whatever decision we make, individuals will have the ability 
> 
> That argument is irrelevant to me.

That argument should be anathema -- it was in early Phoenix/Firebird/Firefox days. Prefs so those who know can work around usability or other problems don't solve anything, and they make the code more complicated and set bad precedents.

> The browser should have input devices that
> don't move around, by default.

Seriously -- did I miss the decade where this old and venerable UI (UE, UX, whatever) principle was rescinded?

/be

(In reply to comment #11)
> [My drive-by, don't over-rotate or write too many words in reply :-P. Do focus
> on the particular points. /be]
> 
> (In reply to comment #10)
> > That said, I also forgot to mention another 6-month old problem with doing this
> > for DV certs: aren't we highlighting information that we can't verify?
> 
> This seems like a fatal flaw.

I confess that I can't find the argument so I wonder if one of you would mind restating it?  eTLD+1 is not technically what the cert verifies, but it seems like a good trade-off between total repetition and telling users, in some broad sense, where they "are."  What about the domain is information we can't verify in a DV cert?

> > > It's a pref, so whatever decision we make, individuals will have the ability 
> > 
> > That argument is irrelevant to me.
> 
> That argument should be anathema -- it was in early Phoenix/Firebird/Firefox
> days. Prefs so those who know can work around usability or other problems don't
> solve anything, and they make the code more complicated and set bad precedents.

Yeah, that wasn't really what I was trying to say there, but I think it just messes up the discussion, so please consider it unsaid.

I absolutely agree that "we'll pref it out!" is a bad approach to UI design.

> > The browser should have input devices that
> > don't move around, by default.
> 
> Seriously -- did I miss the decade where this old and venerable UI (UE, UX,
> whatever) principle was rescinded?

I really think this problem is being overstated a touch.  When you navigate to a new page, the back/forward buttons change state, refresh disables, stop enables, the go button disappears, the yellow background on the url bar changes, the text content in the url bar changes, the favicon changes, the status bar text changes, the title changes, if you have tabs, the tab title and icon change, and throbber(s) starts throbbing. And for all that, I don't personally find it distracting.  I expect browser state to change when I navigate somewhere new, and I don't think, in this, that my expectations are significantly divergent from our user base, really.  What am I missing here?
(In reply to comment #12)
> (In reply to comment #11)
> eTLD+1 is not technically what the cert verifies, but it seems
> like a good trade-off between total repetition and telling users, in some broad
> sense, where they "are."

You just made the case -- "not what the cert verifies" and "compromise" (spelled "trade-off" here for some reason :-P).

It's a flawed compromise that adds redundancy and visual complexity. Those are not good things in general.

> > > The browser should have input devices that
> > > don't move around, by default.
> > 
> > Seriously -- did I miss the decade where this old and venerable UI (UE, UX,
> > whatever) principle was rescinded?
> 
> I really think this problem is being overstated a touch.  When you navigate to
> a new page, the back/forward buttons change state,

They don't move.

Please focus on "input devices that don't move around".

/be
I haven't been following this closely elsewhere, what are the options and what do they do?
This bug is about DV.

The "it moves around" behavior is not specific to DV.

You will get the "it moves around" behavior when switching between "EV sites" and "plain sites", regardless of the changes proposed here.

If you're concerned about the URL bar moving around, I think that's a separate bug.
(In reply to comment #15)
> 
> If you're concerned about the URL bar moving around, I think that's a separate
> bug.

Absolutely not. I don't care if sites using PKI science projects get a bad UI.
(In reply to comment #13)
> > eTLD+1 is not technically what the cert verifies, but it seems
> > like a good trade-off between total repetition and telling users, in some broad
> > sense, where they "are."
> 
> You just made the case -- "not what the cert verifies" and "compromise"
> (spelled "trade-off" here for some reason :-P).


I set up a demo site.

You should use a test profile and accept this CA for web sites:
http://kuix.de/mozilla/certwarndiscussion/test-ca.php

Then visit these sites:
  https://cust-1.kuix.de:451/
  https://cust-2.kuix.de:452/

I think this is sort of an edge case, but a valid one.

Imagine a web hosting company named "kuix.de" that provides secure hosting for their customers.

Let's say, their customers don't use their own domains, for whatever reasons.
Instead, they use subdomains.

For both customers, the DV shows the same domain, even though you are not connected to the hosting company, but to their customers.

(Please ignore that I had port to use port numbers, if you used one IP for each subdomain, that wouldn't be necessary.)

A valid scenario I could imagine, where no separate domains are used:
The web sites could be used to manage some non-public storage assigned to a company. It would be completely unnecessary to register separate domains for such non-public content.
>   https://cust-1.kuix.de:451/
>   https://cust-2.kuix.de:452/


Sorry, here are improved links:
  https://bank-of-nirvana.kuix.de:451/
  https://biggest-telco-ever.kuix.de:452/
  
When connecting to either site, the UI says "kuix.de"
Comment on attachment 301285 [details] [diff] [review]
Switch default to '1'

intranet.mozilla.org and bugzilla.mozilla.org get the same "identity".

r-
Attachment #301285 - Flags: review-
(In reply to comment #12)
> I really think this problem is being overstated a touch.  When you navigate to
> a new page, the back/forward buttons change state, refresh disables, stop
> enables, the go button disappears, the yellow background on the url bar
> changes, the text content in the url bar changes, the favicon changes, the
> status bar text changes, the title changes, if you have tabs, the tab title and
> icon change, and throbber(s) starts throbbing. And for all that, I don't
> personally find it distracting.  I expect browser state to change when I
> navigate somewhere new, and I don't think, in this, that my expectations are
> significantly divergent from our user base, really.  What am I missing here?

Not a single one of the examples you give moves the location of a UI element I'm expected to click into - to for example use the awesomebar.  
(In reply to comment #19)
> (From update of attachment 301285 [details] [diff] [review])
> intranet.mozilla.org and bugzilla.mozilla.org get the same "identity".

really, not to rathole too much, but for DV certs, "mozilla.org" is equally accurate.  If I control DNS for mozilla.org, I can redirect intranet.m.o and bugzilla.m.o to new IPs and get new automagic DV certs in minutes.  Kaie's example suffers from the same thing.  If you have bar.foo.com and baz.foo.com, if you're not using EV you are essentially trusting foo.com, so I don't think its at all some sort of automatic failure state.

(In reply to comment #21)
> (In reply to comment #19)
> > (From update of attachment 301285 [details] [diff] [review] [details])
> > intranet.mozilla.org and bugzilla.mozilla.org get the same "identity".
> 
> really, not to rathole too much, but for DV certs, "mozilla.org" is equally
> accurate.  If I control DNS for mozilla.org

If you are mismanaging your domain or delegating to someone who is, then we're amplifying that mistake.

I think that when there is any kind of encryption there should be some text in the site-button to increase discover-ability. So set the default to 1!

As to whether the text should contain the subdomain, I think it should. I know it makes the site button really long but it is necessary as many domains have different sites on their subdomains. (Think [username].googlepages.com or del.icio.us)
I agree with ChrisJF; showing a verified piece of information about the site's identity when applicable would improve discoverability of the identity feature, as the text would reinforce to the user that they are indeed seeing the site listed.

As for the issue of whether or not the subdomain should be displayed, I believe that due to both potential space considerations, as well as the issue of phishing sites using subdomains to look more "official," the subdomain should not be displayed in the site button.  However, it should be displayed in the identity popup, so that it matches with what's shown on the status bar and in the page info dialog.

With that in mind, I think the default should be set to "1".
If we do not flip this pref then there is zero visible difference between a secure and non-secure site. No lock, no background color change, nothing (unless you're on Mac in which case you get a little bit of blue peeking out from behind the favicon). This would be a major regression from all previous browsers since the invention of SSL.

Replacing the lock was a radical idea, but the idea was to _replace_ it, not kill it and remove all security indications (except EV-ness). Bring it back then, bring back the gold background, move Larry to the right side if changing the input element location is so horrible. Something, please.
> there is zero visible difference between a secure and non-secure site. No
> lock, no background color change, nothing (unless you're on Mac

I was a little ahead of myself, Windows does still have the yellow background for now (Alex told me it was going away, I should have looked closer). According to bug 417844 Windows and Linux will be made to match the Mac color behavior.
(In reply to comment #26)
> If we do not flip this pref then there is zero visible difference between a
> secure and non-secure site. No lock, no background color change, nothing
> (unless you're on Mac in which case you get a little bit of blue peeking out
> from behind the favicon). This would be a major regression from all previous
> browsers since the invention of SSL.

I've made a proposal for that: attachment 310962 [details]
Not as discoverable as the lock, but IMHO better than the simple background color change behind the favicon.

> move Larry to the right side if changing
> the input element location is so horrible.

Yeah, that would have been better. I think we suffered from the whole "site button" idea, and hence being tied to the favicon. I don't think we can change that now.
If we can't put etld+1 on the site button because it is easy to criticize the redundancy, perhaps another word or very short phrase (late l10n hit).

I'm personally finding the movement as the site button changes size to be really useful for realizing when I am entering and exiting a secure connection.  I don't think the color change alone will be nearly as noticeable.
(In reply to comment #26)
> If we do not flip this pref then there is zero visible difference between a
> secure and non-secure site. No lock, no background color change, nothing
> (unless you're on Mac in which case you get a little bit of blue peeking out
> from behind the favicon). This would be a major regression from all previous
> browsers since the invention of SSL.
> Replacing the lock was a radical idea, but the idea was to _replace_ it, not
> kill it and remove all security indications (except EV-ness). 


If I understand correctly the "lock in URL bar" was removed, but we still have the lock icon in the lower right corner of the window (and I'm really glad we still have it).
That may be true, but when the lock was "copied" to the URL bar, this move was accompanied by lots of reasons why just having it in the status bar wasn't sufficient. Have those reasons suddenly evaporated?

Also, users of Firefox 2 (most of our userbase) will be used to looking for it in the URL bar - or, at least, the URL bar colouring. 

(I don't have an installed copy of the very latest code, so I'm uncertain what the current exact UI is.)

Gerv
(In reply to comment #29)
> If we can't put etld+1 on the site button because it is easy to criticize the
> redundancy, perhaps another word or very short phrase (late l10n hit).

I might suggest "Encrypted" or "Connection Encrypted" (probably a little too long unfortunately) I think we already have the latter string for our page info dialog.

This represents exactly what the SSL certificate means, the connection to the site is encrypted, but makes no claim to the validity of the contents.
We are separating issues into individual bugs, and then deciding to block on different aspects of an overall design, and this process sometimes produces a pretty illogical end result for the user.

For instance, we decided to switch our security UI from being about the physical metaphor of a padlock, to being about the literal identity of the site (which happened to be placed on a blue button).  However, since bug 417844 blocks and this bug is still being debated, we have now switched from the physical metaphor of a padlock to a UI that isn't about anything other than blueness.

I really think we need an interface that is about more than blueness, we need to convey some level of actual meaning to the user, regardless of if we choose to focus on security, or if we choose to focus on identity.  I suggest we choose either:

a) Yellow bar with a padlock icon
b) Blue site button with etld+1

These interfaces only make sense if you happen to read some very long threads, or someone literally explains the interface to you:

c) Yellow bar
d) Blue site button
Requesting blocking to decide one way or another since shipping a UI devoid of direct and specific meaning (regardless of if that meaning is security or identity) feels like a mistake.
Flags: blocking-firefox3?
Er, what happens to the site button with etld+1 if say the longest domain in the world got an ssl site?
For example: http://www.thelongestdomainnameintheworldandthensomeandthensomemoreandmore.com/
alone takes up more than half the space of the URL bar default layout at 1280x1024

I think part of what needs to happen for the blue to work is the site button looking more like a button. It already does to some extent, but a hover/pressed state would be nice.
(In reply to comment #11)
> > The browser should have input devices that
> > don't move around, by default.
> 
> Seriously -- did I miss the decade where this old and venerable UI (UE, UX,
> whatever) principle was rescinded?

There is a User Interface principle (which are principles for building interfaces which make up part of an overall User EXperience), yes, which states that once presented with an interface, items within that interface should be located predictably, and not change location unless linked explicitly with a user action. It's often termed as "the user owns their screen".

So, for example, menu items that collapse and expand "helpfully" based on a timeout as a user is trying to read them (see: Windows 95 "smart menus"), or screens where the "OK" or "Next" button move around like crazy.

I don't think that's what's happening here, though. The size of the button changes between page loads, and the button remains consistently anchored to the left side of the location bar. This shifts the text content to the right before any page content is loaded. Selection is unaltered. The change is directly related to a user's request: they have navigated to a new page, and part of that page's location is the identity information located alongside the favicon.

(In reply to comment #20)
> Not a single one of the examples you give moves the location of a UI element
> I'm expected to click into - to for example use the awesomebar.  

To be caught this way would require that you're trying to click in the locationbar at the moment an SSL connection is forged. This is an unlikely scenario, as you would have had to decide to edit the page before any content was loaded.

Once the SSL connection has been forged, the time to seek to the location bar would be identical, since in either case you'll be relying on a fine grained "declaration" movement to reach your target. Muscle memory isn't used when targeting a movement from one random screen location (mouse source) to another (location bar within window at some screen position).

(In reply to comment #28)
> > move Larry to the right side if changing
> > the input element location is so horrible.
> 
> Yeah, that would have been better. I think we suffered from the whole "site
> button" idea, and hence being tied to the favicon. I don't think we can change
> that now.

I disagree that it would be better. The information needs to be tightly associated with the favicon since the favicon is the avatar or representation of the site being visited. Also, as previously mentioned, the design specifically attempts to grab the user's attention; over time this identity information will ambiently become part of a user's understanding of their location.

(In reply to comment #33)
> (which happened to be placed on a blue button).  However, since bug 417844
> blocks and this bug is still being debated, we have now switched from the
> physical metaphor of a padlock to a UI that isn't about anything other than
> blueness.

Not true. We've switched from an overstated metaphor (padlock = safe) and a non-standard colour metaphor (yellow = good as opposed to yellow = caution) with no friendly ability for disambiguation to one where there is a consistent control for investigating identity and security, and like other parts of the UI (see: star button, search drop-down, back button), it changes state when there is interesting functionality or information to impart.

Blue happens to be the highlight colour for one state. It doesn't collide with other semantic meaning of colour, which is good, but it's not about "blueness". It's about indicating that the state of the button has changed. It's an affordance.

> I really think we need an interface that is about more than blueness, we need
> to convey some level of actual meaning to the user, regardless of if we choose
> to focus on security, or if we choose to focus on identity.  I suggest we
> choose either:

I agree that the control is more valuable and more useful with additional meaning ascribed. I disagree that even with this pref off the control is only about "blueness" - that's an overstatement.

(In reply to comment #35)
> Er, what happens to the site button with etld+1 if say the longest domain in
> the world got an ssl site?

We can control and middle truncate so that it, like EV, is restricted to 64 characters. Middle truncation + random offset fuzz would ensure lack of spoofability.

> I think part of what needs to happen for the blue to work is the site button
> looking more like a button. It already does to some extent, but a 

Agreed, and we're there on OSX, getting there on Windows.
>it's not about "blueness". It's about indicating that the state of the button >has changed. It's an affordance.

Yes, the blue button draws attention to itself, and it affords clicking more than the non-blue button, but it is still only an affordance, it conveys no other meaningful information to the user.  The lock tells the user "secure," setting this pref to 1 tells the user "domain name," and the current design tells the user "blue, click me."  Given the pretty limited success of our open search discovery UI (commonly thought to be a visual glitch), my argument is that we need a UI that is about more than just an affordance for clicking.  Just an affordance is too meta.
I don't think redundantly displaying the domain name is a good UI. The blue background is also bad UI, because it's hard to see blue favicons (this criticism has never been addressed).

I don't buy the argument that this stuff doesn't constitute moving a text entry area around. The only reason it's even debatable is that we've added some mystery meat chrome that resides inside the text focus ring (and looks bad on mac, where the focus rings are supposed to surround a light color). It also has the never addressed criticism of adding confusing context to autocomplete.

This location bar stuff has consumed way too many resources, especially for something where we haven't examined alternative designs. Topping it off with delay and then landing the unchanged first design before RC1 is not a good idea. This is an unattractive and barely functional execution of an idea backed by little of substance.

We back things out if they're not ready.
There's nothing checked in here, so there's nothing to back out.

FWIW, comment 36 was meant to clarify what I saw as a bunch of misrepresentations of fact and accepted UI principle. While I happen to think that this preference is for the better, I also agree that it's a pretty major UI change coming late in the game and have reservations with including it at this time for that reason.
(In reply to comment #33)
> a) Yellow bar with a padlock icon

If it comes down to this one, perhaps we should put the padlock beside the site icon instead of the old location, that way it will symbolize secure connection to the site at least. Sites making their favicons padlocks on the other hand is a potential problem.
(In reply to comment #39)
> There's nothing checked in here, so there's nothing to back out.
> 

There is a UI checked in that doesn't make sense. See Comment #33.

> FWIW, comment 36 was meant to clarify what I saw as a bunch of
> misrepresentations of fact and accepted UI principle.

I don't think there are UI principles to back up a text box that has a moving left edge. It looks like a really bad idea to me. Are there any examples of this working well in other software?
The padlock was removed for sensible reasons, as Alex and Johnathan have both pointed out.

As Alex pointed out in comment 33, the site identity button is an end-to-end design which is meant to replace and augment a set of other UI elements that had previously communicated concepts of security and identity to a user. The new design uses a single, always-visible control to inform a user about their connection to a website. This design solves many problems that existed with the previous controls, where metaphors were used inappropriately (eg: lock = secure, yellow = good) and implementation language (eg: "encrypted", "certificate") was exposed in not-easily-understood ways. It also is more noticable than the previous control, and since it is always present you can see when there is identity information present vs. when there is not, and always investigate it.

This bug is about how we represent the various states within this new design. As it stands, the states are:

 no identity information - button in basic state
 DV identity information - button highlights
 EV identity information - button highlights, displays O name from cert

This specific preference would change the states to be:

 no identity information - button in basic state
 DV identity information - button highlights, displays eTLD+1 of CN from cert
 EV identity information - button highlights, displays O name from cert

Alex, Johnathan, and I all agree that the overall design benefits from this default preference, as the site identity button becomes more helpful and meaningful in terms of containing all available identity information when connected to a site. We have all experimented browsing with this pref in various states, and have gotten other users to try it, and the feedback has been very positive (though some of the concerns as raised in this bug were echoed, nobody thought they outweighed the benefits).

Since I wasn't very clear in comment 36 above, as UX lead, I endorse this change, though acknowledge that it's somewhat late in arriving. I think it vastly improves the overall design (and then becomes consistent between EV and DV treatment, which I think is valuable as well), though is not required for the overall design.
> The padlock was removed for sensible reasons, as Alex and Johnathan have 
> both pointed out.

Actually, only one of them was removed.

> As Alex pointed out in comment 33, the site identity button is an end-to-end 
> design which is meant to replace and augment a set of other UI elements that 
> had previously communicated concepts of security and identity to a user. 
> The new design uses a single, always-visible control to inform a user about 
> their connection to a website.

When I first raised the same unaddressed issues with this design like a year ago, I was told that it communicated "identity", not "security". I see that that UI claiming to communnicate these hopelessy vague terms is still be treated as an end in itself, without claiming to enable any concrete change in user behavior. While the lack of evidence of improvement is troubling, it does explain how the location bar UI evolved to encompass "security". The bar is so low that of course the design succeeds.

> This design solves many problems that existed with the previous controls, 

Disagree. The problems you're highlighting are inherent in sending clear text confidential information, even when a secure channel is used. UI design cannot solve that security problem, and an increase UI flare won't even mitigate it. I'm not sure where we got the idea that this is a UI design problem.

> where metaphors were used inappropriately (eg: lock = secure, yellow = good) > and implementation language (eg: "encrypted", "certificate") was exposed in
> not-easily-understood ways.

I agree that the dialogs behind the UI are improved, but this is unrelated to issue at hand.

> It is also more noticable than the previous control, and since it is always 
> present you can see when there is identity information present vs. when 
> there is not, and always investigate it.

The information provided is not particularly informative unless EV certs are used, and even then it is a stretch to claim anyone will click on that dialog regularly, or notice it once they become used to it.

> This bug is about how we represent the various states within the new design.

No, it's about how far or whether to extend the new design outside of the unproven EV science project. It should be clear by now that the entire effort suffers from lack of attention to detail and lack of accountability. We've added megabytes of code, countless hours of perf waffling and arguing, wonky UI (hard to argue that it's elegant). And all for a completely vague "identity" requirement added to a badly run PRD process that conributed to a very, very late release. I don't think we should further jeopardize the product by making changes with obvious design problems to a poorly-tested component just before RC1.

The existing eTLD+1 proposal incorrectly abbreviates the authority component of the URI syntax, and displays information that isn't quite verified by the certificate. If you buy the (dubious) notion that people will pay attention to the display, it is a security problem waiting to happen. So, my r- stands for that reason, and all of the other unanswered criticisms in this bug and elsewhere. The design and the process which generated it are both inadequate.

> Since I wasn't very clear in comment 36 above, as UX lead, I endorse this 
> change...

Let me clear up a misconception: this is barely a UI issue. We should only impose this security theory on the Web at large if we're sure it constitutes a clear security improvement, which we definitely have no consensus on. If we must argue from authority, the final word will not come from the UI designers. I would rather argue the issues with my colleagues, but that doesn't appear to be welcome. Instead, issues raised are greeted with silence, and maybe a blanket "benefits outweigh the problems" statement.

I am dismayed that we're landing even the EV security theater, and I'm further shocked by the recklessness with which changes are being imposed on web authors and site administrators that choose to avoid that fiasco.
To clarify, I am completely in favor of this design.  Where I happen to differ
from beltzner, and possibly johnathan, is if we should consider a watered down
version vs doing the entire change:

  no identity information - button in basic state
* DV identity information - button highlights, displays eTLD+1 of CN from cert
  EV identity information - button highlights, displays O name from cert

>is not required for the overall design.

I personally think this should be required for the overall design. I've been
browsing with the pref set to 1 for weeks, and I really like the UI for the
following reasons:

1) The change in size creates movement that captures your attention.  This
makes it very easy to process when you are entering and exiting an SSL
connection, even if you are just using your peripheral vision.

2) The domain name is shown by itself which means you can view and process it
with a single glance instead of a complicated focus and scan which is required
for pulling etld+1 out of the full URL.

Both of these attributes, movement to capture attention and the ability to
process a small chunk of text, are great ways of leveraging the properties of
our visual system. 

Using this pref I've even found out some things I didn't realize before, like
the fact that my bank uses a different domain name after I log in and am
viewing my account information.

>I don't think there are UI principles to back up a text box that has a moving
>left edge.

Not moving something the user is about to interact with could be considered a
UI principle.  This design does not do that, as the user is not likely to be in
the process of clicking the site button at the same time as a navigation event.
 There are also plenty of cases in Firefox where we move something the user may
later interact with (what we are doing here), including the scroll bar's bar,
and tabs. It is much more likely that the user will be trying to grab the
scroll bar as the page loads, and it will start changing size, which does break
this ui principle. 

I really think that this information would be best served tied in to an infobar, though I'm told that infobars can be spoofed.  I think that an infobar gives the user the proper information, more so than is allowed in the current UI. If they can be spoofed then that's a separate problem imo.  I really don't see users attaching themselves to the new UI unless we do away with URLS.

I don't have so much of a problem with the url bar moving around because I use a laptop and just hit ctrl+L, but when I'm on a desktop I use the mouse a lot more, and muscle memory will make me want to click in the same spot every time, which might move dependant on the domain as proposed here.

Is it correct to assume that even in beta5 the setting is to not include any domain information at all besides the favicon?  I have no way to say if including the domain info is intrusive to me as I've not had to deal with it.  When it was enabled in the alphas it was very annoying. I understand that I'm not a "typical" user because I understand urls and how to tell I'm on the site I mean to be on.  Though I think if we wanted to expose this info we really should have turned it on for a beta to get feedback.

On this site even, I"m told that this site is run by "unknown" verified by "equifax." so.. equifax doesn't know who this site is run by, yet it's verified encrypted?

Though I agree that using yellow for secure is confusing, as yellow does mean caution in other context. I think we really need to focus this discussion on what *Exactly* we're trying to do for the user, rather than on how.  What we want to do is let a user know whether the site is owned by the company they think it's owned by. I really can't say if I believe this should be an extra function outside our phishing protection.

I agree whole heartedly that clicking on the favicon is not obvious. If we're going to stick with the current implementation we should at least add a larry icon to the (already crowded) url bar as indication to users that there's more information to be had.  Though I think if we're telling ourselves that users care, we're kidding ourselves.  Simple enough though, stick up a user survey somewhere about the new UI, see how many of our advanced beta users have even noticed it.
Comment on attachment 301285 [details] [diff] [review]
Switch default to '1'

Ultimately, the buck stops here.  I'm going to make a call on this one way or another, but I want to go through the design one more time to be sure.
Attachment #301285 - Flags: review- → review?(mconnor)
Comment on attachment 301285 [details] [diff] [review]
Switch default to '1'

I'll leave my r-.
Attachment #301285 - Flags: review-
(In reply to comment #43)
> The problems you're highlighting are inherent in sending clear text
> confidential information, even when a secure channel is used.

Ding ding ding....

> UI design cannot
> solve that security problem, and an increase UI flare won't even mitigate it.

Did you mean "flair", as in "17 pieces of flair"? (Office Space ;-)

> The existing eTLD+1 proposal incorrectly abbreviates the authority component of
> the URI syntax, and displays information that isn't quite verified by the
> certificate.

This pair of points constitutes accurate criticism in my book. Anyone disagree?

> Let me clear up a misconception: this is barely a UI issue. We should only
> impose this security theory on the Web at large if we're sure it constitutes a
> clear security improvement, which we definitely have no consensus on. If we
> must argue from authority,

I agree there's been too much of that. It's a warning sign, even in an area full of subjectivity like UI/UE/UX.

> the final word will not come from the UI designers.

I suppose that means I have to weigh in, as court of last resort in the module ownership system. This is a badly broken condition; no one should want it.

(In reply to comment #44)
> To clarify, I am completely in favor of this design.

Do you grok Rob's points about wrongful abbreviation of authoritative URI part, and presenting something not certified?

> I personally think this should be required for the overall design. I've been
> browsing with the pref set to 1 for weeks, and I really like the UI for the
> following reasons:
[snip]

This (including snipped reasons) is good stuff, but it's not responsive to the objections. It is grounds for further research for sure. It could be rescued in Firefox 3, final, maybe -- but the objections need to be dealt with. They are not overcome by pointing to unrelated qualities of the new UI, which seem to have specific visual-feedback benefits.

> Using this pref I've even found out some things I didn't realize before, like
> the fact that my bank uses a different domain name after I log in and am
> viewing my account information.

In some locales, I wonder if eTLD+1 would fail to show the difference in authority.

> >I don't think there are UI principles to back up a text box that has a moving
> >left edge.
> 
> Not moving something the user is about to interact with could be considered a
> UI principle.  This design does not do that, as the user is not likely to be in
> the process of clicking the site button at the same time as a navigation event.

Comment 45 rightly points to "wide jump" muscle memory, and perhaps some visual memory, about where to go to click and enter a URI (if you're a mouser, which many people are).

>  There are also plenty of cases in Firefox where we move something the user may
> later interact with (what we are doing here), including the scroll bar's bar,
> and tabs. It is much more likely that the user will be trying to grab the
> scroll bar as the page loads, and it will start changing size, which does break
> this ui principle. 

Yes, that bugs me too. But two wrongs don't make a right...

/be
Since I'm apparently in danger of being vetoed without asserting an opinion, I guess I'll dive in.

(In reply to comment #48)
> (In reply to comment #43)
> > The existing eTLD+1 proposal incorrectly abbreviates the authority component of
> > the URI syntax, and displays information that isn't quite verified by the
> > certificate.
> 
> This pair of points constitutes accurate criticism in my book. Anyone disagree?

The mechanics of DV-SSL are based upon control of the domain.  If you own foo.bar.com, and I control DNS for bar.com, I can set up a new foo.bar.com, redirect DNS and obtain a DV cert with ease.  The owner of bar.com is the only authority that matters in the DV-SSL case.  If you trust foo.bar.com but not bar.com, you really want something like SSH-style KCM, because we do not store or compare certs between sessions.  Its unlikely, unless you're inspecting the certs on each visit, that you have any way of knowing if foo.bar.com has moved or been taken over by the bar.com owner.

Its not perfect, but pretending that a DV cert for bar.foo.com constitutes a separate authority from foo.com is missing the part where CA policies of yesteryear have come back to haunt us with "get an SSL cert in minutes" from vendors aplenty.
>Do you grok Rob's points about wrongful abbreviation of authoritative URI part,
>and presenting something not certified?

My analysis is only from a UI perspective.  But I would still be in favor of an alternate version of the design that contains some piece of information on the site button, like a small passport icon, if there were sufficient reasons to avoid showing the user etld+1.

>But two wrongs don't make a right...

In the case of the scroll bar, the user is very likely to have it as a specific target.  I not convinced that the start of the location bar is as likely to be a specific target, especially with the behavior on windows and OS X where a click anywhere in the field selects all of the text (we can't do this on Linux due to multiple clipboards).

Additionally I don't think the size change of the scroll bar is "wrong" but is rather a well thought out balance between the benefits of presenting the user with meaningful information (how long the page is), and the clearly negative aspect of shrinking a target that the user might be trying to click.  In the case of the location bar, I believe the trade off makes sense as well, especially since the information is even more important, and the relative change in target size is considerably less.
If you want to avoid that the URL bar moves, could we place the identity area to the right of the URL?
(In reply to comment #49)
> The owner of bar.com is the only authority that matters in the DV-SSL case.
...
> If you trust foo.bar.com but not bar.com

First "security" and "identity", now "authority" and "trust". Is there anything this UI can't handle? ;)

I agree that the owner of bar.com can take steps to stop damage once a problem has occured, if they're aware. But our UI is primarily about identity (or so I thought), and this UI presents foo.bar.com as the same identity as bar.com. This is not how DNS works, and it's not how URI syntax works. We might wish that was the case, but we can't impose it.
Sorry to come up with yet another new idea this late in the discussion, but maybe it can serve as a salomonic compromise?

Feel free to ignore, if you think it's a distraction.

---------

To summarize the old proposal currently being discussed:

 [[favicon always]] [[identity information sometimes]] [[full URL]] [[search]]

Which means, because the middle part is sometimes shown, sometimes hidden, the URL is moving around.

---------

New proposal:

 [[favicon always]] [[fixed size identity status]] [[full URL]] [[search]]

The idea is to introduce a new fixed size identity status, with the following states:

- on plain http or broken security always show a neutral word like
    "connected"
  with white background (same background as url bar)

- on classic https show text
    "encrypted"
  with a gray background, or same background as url bar on https.

- on https with an EV cert show text
    "identified"
  with a green background


One could calculate the maximum required size for the longest word, and always display that area in the required size.

This solves the problem with the URL bar moving around.

However, using this new proposal, we are no longer able to show the O= (company name) in the identity area.


We could overcome this with the following additional change:

As of today, on https, we always display a lock icon in the lower right corner (and we should keep that).

However, as of today, next to the lock icon we always display the full host name.


Idea:
- for classic/basic https, continue to show the full host name
- for EV https, instead show the company name here
A bunch of this traffic happened while I was on a plane or without internet, so I apologize for not commenting sooner, though I'm not sure what I could add given the heavy analysis on all sides.

My biggest concern is actually around the timing of the change, I'm quite sensitive to that point; but beltzner, mconnor, sayrer and brendan are all release drivers iirc, so I trust that that cost is being considered.

Brendan and Rob both raise the use of eTLD+1 as a specific issue, and I agree that it will often be different, specifically, that it will be more generic, than what the cert itself claims.  One approach is to set the pref to '2' instead of '1', which uses the full hostname, another is to expose the literal CN value from the cert.  My argument in support of eTLD+1 (aside from the space-saving, which is valuable in the absence of other factors) is that in typical usage this will be more likely to add noise than signal.  A large percentage of the time, this will serve to bring things like load-balancing subdomains, locale-servers, or "www" into the button for little gain.  Not all the time, though, I agree.
(In reply to comment #52)
> (In reply to comment #49)
> > The owner of bar.com is the only authority that matters in the DV-SSL case.
> ...
> > If you trust foo.bar.com but not bar.com
> 
> First "security" and "identity", now "authority" and "trust". Is there anything
> this UI can't handle? ;)

Authority was used in the context of the URI authority brendan cited.  This UI doesn't make users more secure, but it does allow them to make decisions based on identity (as in, who you are choosing to trust).

> I agree that the owner of bar.com can take steps to stop damage once a problem
> has occured, if they're aware. But our UI is primarily about identity (or so I
> thought), and this UI presents foo.bar.com as the same identity as bar.com.
> This is not how DNS works, and it's not how URI syntax works. We might wish
> that was the case, but we can't impose it.

The point of identity is to allow users to choose to trust or not trust.  The UI is intended to give you information about who you are choosing to trust or not trust.  In the case of EV certs, there is sufficient validation that we feel confident in showing the company name.  In the case of DV certs, all we know is that the owner of bar.com is the person who has ultimate control.

In terms of whether to show bar.foo.com vs. foo.com, you can't trust bar.foo.com to prevent foo.com from doing bad things.   You can choose to trust foo.com to prevent bar.foo.com from doing bad things, because at the least foo.com has the ability to intervene.  It also feels more correct to choose to trust bar.com to trust foo.bar.com, rather than the inverse.

The point is to show you information that you can use in making a trust decision.  IMO bar.com is far more valuable to use in making that choice, vs. foo.bar.com, which is why I vastly prefer etld+1 to full domain.
It seems to me that the concerns here have distilled down to a couple of
different points:

1) The current implementation was a half-way point from the previous lock in
the URL bar to the current blue favicon for the DV-SSL and thus is not
internally consistent (paraphrasing Alex's concerns).  Thus we should do
something different for DV-SSL or roll back to where we were with the lock.

2) The URL bar is a click target and moves.  I'm amongst the folks arguing this
point and I'd like to withdraw my concerns here for two reasons a) we have this
problem with EV-SSL b) I don't think it is the most important issue here 

3) etld+1 is either misleading or doesn't convey the information we think it
does. 

4) Timing and release risk

I'd suggest that 1,2 are judgment calls that fall under the scope of the
Firefox module.   3 is something we ought to be able to common agreement on
(Sayre/Brendan?) but is at the core a security issue.  4 is a function of
release drivers - as one I'd say whatever we are going to do make it fast and
low risk.  :-)
(In reply to comment #55)
> In terms of whether to show bar.foo.com vs. foo.com, you can't trust
> bar.foo.com to prevent foo.com from doing bad things.   You can choose to trust
> foo.com to prevent bar.foo.com from doing bad things, because at the least
> foo.com has the ability to intervene.

This is not the case in the real world, unfortunately -- except of course on a case by case basis for many hosting arrangements, after there's been an attack, possibly at high cost. There are lots of mixed sources of domain authority along the DNS ancestor line after eTLD+1.

> It also feels more correct to choose to
> trust bar.com to trust foo.bar.com, rather than the inverse.

Users are generally not going to think about trust this way. Nor should they. As I noted to Mike in IRC, same-origin trust labels are not equated after eTLD+1 -- foo.bar.com and bar.com are unrelated principals.

Showing more information, especially redundant and possibly misleading info, is not an unmixed good.

I'm hoping something can be done to prod users to discover more (if they are sharp enough to notice, and can make good use of more info), but that depends on some fresh DV thinking.

/be
Brendan- I very much appreciate your putting focus back on the user and how they're expected to use this. My concern has always been that I don't think this is intuitive and I think we're simply *hoping* that the user will know how to benefit from this, rather than realistically predicting what users will do.

There's lots of talk of eTLD and moving targets, but it's not really breaking it down into a real user path with realistic discussion of where it's going to fail.

1) The stuff shown near the favicon matches part of the url.

What does this *really* mean to the user? what if it matches the wrong part of the url? Will the fact that it matches some part of it make users think it's ok?

2) The stuff shown near the favicon doesn't match part of the url.

How exactly are users supposed to know what this means?  this is the case we care about, users being able to tell that they're on a site that doesn't add up.  Even if the bit looks clickable, what is going to compel users to click on it? why won't they just ignore it?  If they see a page that looks like where they want to be and see something in the url bar that doesn't make sense, I think we're going to have many users that just ignore it.

3) there's nothing near the favicon, like bmo it's "unknown."

o.0  What exactly are users expected to do here? are we going to start saying "unknown" in place of etld+1 (whatever that means)?

4) there's nothing near the favicon because it's not an https site

How are users who don't already understand domains supposed to know the difference between ssl sites and non-ssl sites?  Even if all the other cases were predictable, once encountered enough, the fact that most sites aren't https is going to make this UI seemingly random.  From my previous comments, you can see that I thought it wasn't enabled in the builds I'm using, but I was directed to paypal.com and oh look it is!

IMO if the current implementation is going to help users at all we have to try and match up the info with the domain and use an infobar to tell them that the name doesn't match at all with the domain, and to make sure they're at the correct site for their business that they're trying to reach.

Users get to a site one of two ways, they either click a link, which they've already signified they trust as they've chosen to click it, or they type it in themselves. If they've mistyped they'll either notice that themselves, or if they end up on a visually similar site, they'll assume they're at the right place. Both ways indicate an uphill battle for convincing them they're at the wrong site, unless the phishing protection, or some other alert, pops up.

I honestly think though, this is a poor man's version of AOL keywords and is no where near as useful as the built-in google brand search for making sure you're on a legit site.
(In reply to comment #57)
> This is not the case in the real world, unfortunately -- except of course on a
> case by case basis for many hosting arrangements, after there's been an attack,
> possibly at high cost. There are lots of mixed sources of domain authority
> along the DNS ancestor line after eTLD+1.

Can you provide an example of what you mean?

To me this seems simple, so clearly I'm missing something. If I own "foo.com", I have total and ultimate ability to decide what names resolve to what. (DNS spoofing isn't an issue here, because of the use of certificates.) I am therefore responsible for all activity which goes on in my domain, and should be held accountable for that. Therefore, a web browser saying that I (foo.com) am responsible for the machine bar.foo.com is entirely reasonable, even if I've delegated day-to-day responsibility for that machine to another person or group, and even if they've sub-delegated it and so on.

The purpose of this UI is to answer the question: "If I trust this site, who am I trusting?". This is a question which previously required users to be able to manually parse URLs and/or read the certificate viewer. If there's an EV certificate, we are confident enough to show a human-readable name. If not, all we have is a domain name, and we want to show whatever enables people to make the best decision. 

Having "somecompany.com" appear consistently across all Some Company's web properties, even if they use, as a matter of practicality, loadbalance1.somecompany.com, login.somecompany.com and so on is a big win in this department. "Who am I trusting when I type in my login details here?" "somecompany.com". "Ah yes, that URL was all over their adverts."

This is still the same for somecompany.webshops.yahoo.com. Who am I ultimately trusting? Who vets applicants for this sort of domain? Who's do I complain to if somecompany rips me off? Yahoo. Having the indicator say "yahoo.com" in this case is not unreasonable.

Lucy: your option 2 is impossible, as is the "wrong part" of your option 1, because the ETLD+1 domain must match the right part of the URL (otherwise you'd get cert errors). Option 3 is what we are discussing; if we introduce ETLD+1 for DV, there will be no "unknown" SSL connections. And I think your point 4 is just as much of an issue with the Firefox 2 UI, isn't it? How do users know what any new UI indicator, such as the yellow background was in Firefox 2 (1.5?), means?

Gerv
http://www.techcrunch.com/2008/04/08/network-solutions-hijacking-unassigned-sub-domains/

Also, recall livejournal.com/.../jwz being compromised by cookie access across the lj.com domain, leading to jwz.livejournal.com -- likewise for non-premium *.ning.com, myspace.com, etc. If such use https we don't want to equate them in the UI with the eTLD+1.

Again, foo.bar.com != bar.com in the JS principals semi-lattice. This is not an accidental design decision.

/be
One more response to one of Gerv's points:

https://quux.foo.bar.com might become perverted (not necessarily by its owner). Is the user of Firefox 3 really supposed to blame bar.com? Why not foo.bar.com?

The DNS is a hierarchy but the authority for N is not eTLD+1(N) given a certified domain name N. eTLD+1 is a retrofit and incomplete, handy for many things but not for collapsing trust domains or sources of authority.

/be
I agree with Brendan that showing only the eTLD+1 is a mistake.  There been repeated arguments that it is *necessary* to trust foo.com in order to trust bar.foo.com, but no one has argued that it is *sufficient*.  I do not trust user.googlepages.com even though I do trust googlepages.com.
So if we set the default to 2, does that suffice to overcome what seems to have become the primary concern here?  Its potentially a lot more heavyweight, but if the argument is to have a noticeable and obvious UI, and the most concrete way of doing so is to show the domain, I'm ok with the added space usage, since I think showing something human-understandable is the most critical missing aspect of the current UI.
Setting the default to 2 exacerbates the 'textbox left edge moving' problem, but it does address the tld trust problem. Personally I click somewhere near the middle/end of the location bar, but I don't expect most users do the same.

I think if the default state of this pref is causing a split amongst those that are setting it, it'll be equally split amongst the end users on their opinion of the end result. Perhaps this is an indication that we need to reconsider the design produced by the pref.
Hrm, I made a few mistakes in writing my comment.  Obviously the domain is going to match the etld+1. When I was talking about matching, I was talking about it matching what the user expects to see, or whether the owning organization has references to the company they think they're on.

Gerv, you're right, I didn't express what I meant. To clarify myself

1. They're at a site that spoofs visa and has visa somewhere in the etld+1 (which is what they're looking for). Will a user think it's ok because the etld+1 matches the url? (which of course it will) 

2. Yeah I got myself confused here.  I was talking about when it's a site spoofing Visa and has Visa elsewhere in the domain, or it has it nowhere, the site just looks like visa. So the etld+1 shows them some other site name. We already know many companies will use different domains for either contests, promotions, or even for their logins. This is the case where we need users to click on the favicon to check out who owns the site.

Gerv, you're right about 4 and it not being any better than the current UI, but I think that's the problem we're trying to solve right now.  At least with the yellow bar it was consistent with https sites.  Some users actually did learn that they'd get the yellow bar when they went to paypal or their bank, or anywhere they needed to sign in. Not sure how many, or what they did with the info.

What I'm saying we need to match up here is the actual org that the site is attributed to and the domain.  So let's say the domain says v1sa or some such but the owner info is Bob.  We should indicate to users visually "this site is owned by Bob, are you sure it's ok?  This is probably fairly impossible though, and might best be done by flagging orgs who become known for hosting bad sites.

Anyway, after all that my original point still stands. I don't understand exactly how we're *expecting* users to apply the information, or to even find out what it means.
(In reply to comment #63)
> So if we set the default to 2, does that suffice to overcome what seems to have
> become the primary concern here?

No. Again, DNS does not conform to our display needs. Our display should show what the certificate verifies if it gets into this stuff.
In the case of DV (domain validation) it really just validates the cert obtainer has control of the domain in some form.  The other info is often _not_ validated, its just accepted at face value.  So what we're displaying is basically the domain name, unless you think we should show *.mozilla.org instead?
(In reply to comment #67)
> In the case of DV (domain validation) it really just validates the cert
> obtainer has control of the domain in some form.

Right, the full domain name, not eTLD+N. (not that I think that is good UI)
Didn't we have a solution for showing the users the domain that didn't cause the url bar to change sizes?
er, yeah, the pref value of 2 == full domain name, its not an int pref corresponding to eTLD + N.  A little credit please, why would eTLD+2 be magically better?
pref value 2 is better than 1. Still left-edge-jumpy and redundant and oversized as noted already. Kai's thinking seemed helpful, at least up to the point where text labels were used -- but that is just an icon design challenge. Could we use some variation on the passport icon that is both bigger and shaped differently from any possible favicon?

It sounds like IE8 will stick with making the domain name bold, although I don't have details (full domain name or eTLD+1 or ...) -- anyone know? I'm definitely not interested in cloning, just wondering what the landscape will look like this summer.

/be
(In reply to comment #71)
> It sounds like IE8 will stick with making the domain name bold, although I
> don't have details (full domain name or eTLD+1 or ...) -- anyone know? I'm
> definitely not interested in cloning, just wondering what the landscape will
> look like this summer.

They are currently using eTLD+1 on both http and https urls.

Well, of course phishing paypal.com with paypal.mumble.com would be more likely to be caught (if not by our anti-phishing code) by users who see mumble.com stand out somehow. That's no doubt why IE8 is doing what it's doing. Some folks argue this is the common case to worry about.

But we just don't know, and a survey of my non-gmail filtered Junk folder finds almost all phishes using unrelated domains, and http:, not https: -- I had a hard time finding https: although I remember seeing one in the last year. Unrelated domains standing out either via FQDN or eTLD+1 would suffice for these, but since they are http: we aren't going to do any domain name part highlighting.

/be
(In reply to comment #73)
> Well, of course phishing paypal.com with paypal.mumble.com would be more likely
> to be caught (if not by our anti-phishing code) by users who see mumble.com
> stand out somehow.

This display won't help with phishing, no matter what we choose. At best, it would be blame-the-victim security, so let's not argue its merits on that score. This should be uncontroversial, since I have been told several times that this stuff is not intended to be an anti-phishing feature.
Ah, but teaching users about identity is intended not merely to teach users about eTLD+1 as (broken but perhaps "mostly right") identity label. It is specifically intended to defeat phishes that get past the (always learning, therefore always behind) anti-phishing code. I've heard this just today, with the bank.com eTLD+1 as common case argument. So are we really agreed on the use-case and intended outcome?

Intentions aside, I believe we lack any meaningful data, and there's enough downside risk, that we should be conservative. In that light, a passport in the URL bar (on the left) as the new lock (lock = good in Firefox 1-2, passport = good in Firefox 3, hackers and fools at banks put that icon in their pages and in favicons) is less risky than setting the pref to 1. Leaving the pref at 0 is riskier by this crude measure.

/be
(In reply to comment #73)
> Well, of course phishing paypal.com with paypal.mumble.com would be more likely
> to be caught (if not by our anti-phishing code) by users who see mumble.com
> stand out somehow. That's no doubt why IE8 is doing what it's doing. 

I don't think users are going to understand why that is there when the url is there after it.  This is going to be helpful in a very select number of cases, most of which will be caught by the phishing protection - users ended up at a link that they didn't intend to get to. When we were using the spacing in the url display it at least showed that in fact this was part of the address you were at, and it did this for ALL sites, not just https ones.  The dots were at least connected. Now we're talking about doing something that isn't clear and also is going to reduce the amount of the actual address the user can see, especially if the full domain is being duplicated.  Now not only will they not know what that domain is about, they might not be able to see it's the site they're on.

At some point the user will have clicked on a link or typed in a url. The user has already made the decision to go to the site. We need to show them something compelling that tells them either it's not the site they meant to go to after all, or the site they meant to go to isn't secure enough to be trusted with their information (or it is legit and secure enough).  Much of that information is hidden behind the favicon, with no good indicator that it's even there.

If you do click on it, the pop up displayed doesn't indicate what the user should be judging by the domain and the "run by" information, though it does say that the connection is secure to prevent eavesdropping, which IMO if that's the only part of it that makes sense to the user, the user is going to see the word "secure" and the padlock.

What is displayed here is no where near as important as how the user will use the information and whether or not they can find the information they need.
(In reply to comment #75)

> Intentions aside, I believe we lack any meaningful data, and there's enough
> downside risk, that we should be conservative. In that light, a passport in the
> URL bar (on the left) as the new lock (lock = good in Firefox 1-2, passport =
> good in Firefox 3, hackers and fools at banks put that icon in their pages and
> in favicons) is less risky than setting the pref to 1. Leaving the pref at 0 is
> riskier by this crude measure.

This was actually going to be my suggestion.  Though I'd rather see the favicon move back to the url bar and larry/passport show up where the favicon is now for sites that have https info. The throbber can still live there and when larry's not showing it's a visually pleasing end cap to the bar.  When he *is* there, he'll be noticable, and look somewhat clickable

s/larry/passport indication of some sort as applicable. 

Schrep and Brendan asked me to come up with some quick mockups of design options.  After speaking with Jonathan, these are in order of preference of what we think exposes the best user interface.

http://people.mozilla.com/~faaborg/files/granParadisoUI/siteButtonFinalOptions.png

Option A: Display etld+1 on site button [set pref to 1]

Option B: Highlight full domain name in the location bar
-I am not sure of the status of locationbar^2 and if this change is feasible for launch.
-The color change is meant to visually group the highlighted information to the site button that has changed state.

Option C:  Passport Icon on the Site Button
-This option is listed last, since the passport icon effectively becomes the new padlock, where passport == good.
-The change in button size will help to capture the user's attention.
-We may see a lot of passport favicons on phishing sites with this option.

Setting the pref to 2 was ruled out because it is easy to criticize that level of redundancy in the UI, and the site button may start to get larger than the location bar.  I am personally against setting the pref to 0 for the reasons outlined in comment #33
There are 3 proposals in the mockup.

The first proposal seems identical (except color) to the proposed etld+1 display.

The second proposal might not help if phishers use the http://verylongusername@hostname/path trick, the hostname might have scrolled out of view, and user's might not notice the missing highlight.

The third proposal would open new doors for phishers, I think. I agree with the argument that phishers can start using a passport icon as the favicon. End users won't notice the missing favicon.


It seems that Brendan liked the idea from comment 53, although he did not like the idea to use text labels.

I agree that instead of using text labels one could use an identy-state-icon.

The icon could be made big, it could be three times as wide as a favicon, and always present.

In order to keep the tie between favicon-and-url, the new identity-state-icon could be placed to the left of the favicon.

The identity-state-icon could be:

- http or broken https:
  white background with wire symbol (showing connected)

- good classic https: 
  yellow or white background with an encryption symbol (lock?)

- https with EV cert:
  green background with passport symbol
Many people are against setting the pref to 1 because as Adam clearly explains:

>There been repeated arguments that it is *necessary* to trust foo.com in order to
>trust bar.foo.com, but no one has argued that it is *sufficient*.  I do not trust
>user.googlepages.com even though I do trust googlepages.com.

The logic is that if we expose the user to bad information (googlepages.com),
then we have created an suboptimal solution.  But if we show the user more
information, that is clearly a suboptimal as well:

bankofamerica.personal.home.checking.evil.com/folder/content.jsp?stuff=morestuff

we are hoping that the user correctly parses out this part:

bankofamerica.personal.home.checking.evil.com/folder/content.jsp?stuff=morestuff
--------------------------------------^

If they can't parse that correctly, well that is of course their fault and not
ours.  We trade a simple UI that sometimes fails, for a complex UI that never
fails but also doesn't help anyone.  We already have that, it's the location
bar.

So I think we should consider setting the pref to 1 based on the following
premises:

1) good.evil.com is more common than evil.good.com
2) user's don't get that URls have a hierarchy shaped like >-< as opposed to -<
3) changes are easier to spot over time when viewing less information:

bankofamerica.com
bankofamerica.com
bankofamerica.com
bankofamerica.com
bankofamerica.com
evil.com

personal.home.checking.bankofamerica.com
personal.home.checking.bankofamerica.com
personal.home.checking.bankofamerica.com
personal.home.checking.bankofamerica.com
personal.home.checking.bankofamerica.com
bankofamerica.personal.checking.evil.com

(In reply to comment #75)
> It is
> specifically intended to defeat phishes that get past the (always learning,
> therefore always behind) anti-phishing code. I've heard this just today, with
> the bank.com eTLD+1 as common case argument. So are we really agreed on the
> use-case and intended outcome?

No, we are not agreed.

> Intentions aside, I believe we lack any meaningful data, and there's enough
> downside risk, that we should be conservative. 

Yes, this discussion is still mostly speculation. We have a decent trial balloon in EV certs to see whether loud UI really helps users.

(In reply to comment #78)
> Option A: Display etld+1 on site button [set pref to 1]

This option is irrelevant, for the reasons given above. I'm not sure why it's being re-proposed with no new arguments.

...
passport
...
> -This option is listed last, since the passport icon effectively becomes the
> new padlock, where passport == good.
>
> -We may see a lot of passport favicons on phishing sites with this option.

Chrome icons aren't what makes phishing work. Whatever we decide on as "secure" will be spoofed. It won't be long before you see glowing green orbs proclaiming safety a la EV, and they just might work, because we don't even know whether users understand the difference between content and chrome.

(In reply to comment #80)
>
> bankofamerica.personal.home.checking.evil.com/folder/content.jsp

This post discusses phishing, which is not a UI problem. I'm not sure why we continue to pretend it is.
Attached image visualize comment 53 and 79 (obsolete) —
I thought I try to visualize the proposal from comment 53 and enhanced proposal from comment 79.
Please apologize the ugliness.
>This post discusses phishing, which is not a UI problem. I'm not sure why we
>continue to pretend it is.

Then let's switch the discussion to a man in the middle attack.  There is a hypothetical employee of apple working on the next ithing.  Every day they upload new patent draft documents to the server:

cupertinocampus.infiniteloop.secret.patents.apple.com

One day while at starbucks they get redirected to a slightly different SSL connection

cupertinocampus.infiniteloop.secret.patents.macrumors.com

Even though they know all about the structure of URLs, do they notice the change when redirected?  Did something catch their attention to try to help them, and then give them the single most important piece of information that they can process with a single glance?
Fixed background color for insecure connection

As said before, the EV company name would replace the host name in the lower right corner of the window.
Attachment #314753 - Attachment is obsolete: true
(In reply to comment #83)
> >This post discusses phishing, which is not a UI problem. I'm not sure why we
> >continue to pretend it is.
> 
> Then let's switch the discussion to a man in the middle attack.  There is a
> hypothetical employee of apple working on the next ithing.  Every day they
> upload new patent draft documents to the server:
> 
> cupertinocampus.infiniteloop.secret.patents.apple.com
> 
> One day while at starbucks they get redirected to a slightly different SSL
> connection
> 
> cupertinocampus.infiniteloop.secret.patents.macrumors.com
> 
> Even though they know all about the structure of URLs, do they notice the
> change when redirected?  Did something catch their attention to try to help
> them, and then give them the single most important piece of information that
> they can process with a single glance?
> 

what if they got redirected to cupertinocampus.infiniteloop.secret.patents.app1e.com

the domain isn't the part that's important with EV certs. If we want to educate users on domains we should do that in the URL bar.  The important part about EV certs is who owns the site.
(In reply to comment #80)
> So I think we should consider setting the pref to 1 based on the following
> premises:
> 
> 1) good.evil.com is more common than evil.good.com

Evidence? There's none in my Junk folder, filled from a couple of sources (POP and IMAP), none of them gmail.

I don't mean to ask for evidence that evil.good.com is more common, although I already cited examples. I'm simply asking for any evidence from real-world phish data for the "is more common."

> 2) user's don't get that URls have a hierarchy shaped like >-< as opposed to -<

That's a fact.

> 3) changes are easier to spot over time when viewing less information:
> 
> bankofamerica.com
> bankofamerica.com
> bankofamerica.com
> bankofamerica.com
> bankofamerica.com
> evil.com

This either is 1 restated with an example, or predicated on 1. I question 1 and ask for evidence. You could be right, I just don't see it among phishes that get to me.

Anyway, phishing (or MitM) protection via painting pixels based on simple rules applied to a URL is unsound as far as I know. We're experimenting in a high risk low reward space. We could try setting the pref to 1, but at the last minute for Firefox 3? How will we know if it's not working (well, or well enough)? What next?

I'm still in favor of something more conservative, but this is clearly a hard problem. My hat is off to you for stating premises (as well as for doing an intentional end-to-end design). I don't agree that teaching pigs to sing (what I call training users about identity via this UI) is worth it, though. I may be too pessimistic, but "do no harm" seems better at this endgame juncture.

/be
(In reply to comment #86)
> (In reply to comment #80)
> > So I think we should consider setting the pref to 1 based on the following
> > premises:
> > 
> > 1) good.evil.com is more common than evil.good.com
> 
> Evidence? There's none in my Junk folder, filled from a couple of sources (POP
> and IMAP), none of them gmail.

That's an interesting question, and one I didn't immediately have a reference for, although I admit to sharing Alex's instinct.  I checked phishtank.com, since they have a reasonably searchable interface.

Their "most recently reported phishes" list gave me this:

http://www.todofacultad.com.ar//modules/Forums/admin/bb&t-online.b...
http://admiservi.es//facturacion/documentos/www.PayPal.Com22/webscrcmd...
http://posteit.hyperphp.com/secure/online_form/www.irs.gov/0,,id=96596...
http://www.millennium.gr/site/email-change/login.htm?webscr=cmd_login...
http://www.we1.jp/online-update/wwww.paypal.com/update.verify=cmd8af8v...
http://www.shoe-wholesale.net/www.paypal.co.uk/www.paypal.co.uk/uk/web...
http://adwords.google.outtrust.cn/select/Login/...
http://paypalsss.dontexist.net/icons/.ws/cgi-bin/webscr/webscr.php?cmd...
http://adwords.google.badtrust.cn/select/Login/...
https://www.online.fnb.co.za/mammoth/main.jsp?url=3D0&country=3D15...
http://business.hsbc.com.vortlafcg.biz/sys_directory/isa/file.aspx?ses...
http://business.hsbc.com.oorvtat.es/sys_directory/isa/file.aspx?sessio...
http://www.voscomputers.com/hsbc.co.uk/login.php...
http://www.millennium.gr/site/email-change-request/login.htm?webscr=cm...
http://mrz2-zz3-smctt.info.p4.hostingprod.com/update/info/login.php...
http://business.hsbc.com.gorrvat.es/sys_directory/isa/file.aspx/...
http://www.unicreditbancaroma.it.wrestleyourway.com/it/privati/...
http://air931.startdedicated.com/taylorcountybank/update/index.html...
http://business.hsbc.com.oorvtat.es/sys_directory/isa/file.aspx/...
http://business.hsbc.com.for2hafc.info/sys_directory/isa/file.aspx/...

That list is obviously skewed, since several versions of the HSBC listing crop up under different domains, and is also a small sample, but does seem to show a trend like Alex describes, given:

http://adwords.google.outtrust.cn/select/Login/...[2 variants]
http://paypalsss.dontexist.net/icons/.ws/cgi-bin/webscr/webscr.php?cmd...
http://business.hsbc.com.vortlafcg.biz/ [5 variants]
http://www.unicreditbancaroma.it.wrestleyourway.com/it/privati/...

Another way to search is by targeted brand.  The search for phishes targeting facebook ( http://www.phishtank.com/target_search.php?target_id=74&valid=All&active=All&Search=Search ) is inconclusive at time of writing, with one homograph (fanebook.com) one subdomain ( www.facebook.com.profile.id.wkwagdbdh.ramboa.31c5f18a7f.com ), one subdomain/lookalike mix ( www.facebook-profile-id666420.view-facebookprofiles.com ), one "says Facebook in the directory path" and a bunch that don't use the URL as a spoof.

Virtually all the phishes for CIBC (a Canadian bank) use subpaths to look like the real thing ( http://www.phishtank.com/target_search.php?target_id=32&valid=All&active=All&Search=Search ).  The amazon list is heavy on IP addresses (http://www.phishtank.com/target_search.php?target_id=61&valid=All&active=All&Search=Search) though it too has some subdomain spoofing.

So subdomain spoofing would appear to be alive and well, but what's missing from this data is any bad.good.com examples. That may be attributable to those being used in different attacks, and hence not showing up in phishtank in the first place.

> This either is 1 restated with an example, or predicated on 1. I question 1 and
> ask for evidence. You could be right, I just don't see it among phishes that
> get to me.
> 
> Anyway, phishing (or MitM) protection via painting pixels based on simple rules
> applied to a URL is unsound as far as I know. We're experimenting in a high
> risk low reward space. We could try setting the pref to 1, but at the last
> minute for Firefox 3? How will we know if it's not working (well, or well
> enough)? What next?

Agree.  The identity UI is about giving users a chance in hell of knowing who they're talking to online, because that's a facility that all browsers have failed to provide for a long time, instead hiding it all behind a binary icon.  That may have an effect on phishing, for users who engage the UI, but we shouldn't over-rotate on that aspect of it.  My aim is to make Firefox a better agent of the user, by helping the user build a mental model that reflects reality better than the url+padlock does, because that UI is a failure and long term, regardless of what we do this week, we need to do better.
>Evidence? There's none in my Junk folder, filled from a couple of sources (POP
>and IMAP), none of them gmail.

I've found looking through phishtank that the urls that do involve subdomain spoofing will sometimes even overcompensate a little, like this:

http://wellsoffice.wellsfargo.com.greatkenny.com/portal/ceoform.jsp?

This of course doesn't really apply to the conversation since it is http.  I believe it is incredibly uncommon for phishing sites to use https, so in
that sense the padlock actually does mean secure (even if only by correlation
and not causation).

I don't have conclusive proof that good.evil.com is more common than
evil.good.com, but this premise would seem to make sense, since setting up
good.evil.com involves buying any random domain name, while setting up
evil.good.com requires either taking control of good's domain, or finding a
site with user generated content, like googlepages, livejournal, etc.  These
types of sites are also not likely to be mistaken for any of the common
phishing targets.

>> 3) changes are easier to spot over time when viewing less information:

>This either is 1 restated with an example, or predicated on 1.

As a design it is predicated on both 1 and 2, as a premise it isn't really tied
to URLs.  There are lots of fun examples
http://viscog.beckman.uiuc.edu/djs_lab/demos.html 
Any https://good.evil.com instances (httpS not http)? I don't see 'em. Since http: is untreated by setting the ssl_domain_display pref to 1, 2, or any value, why are these examples relevant?

/be
(In reply to comment #89)
>
> why are these examples relevant?

These are phishing examples. I've been told several times that this interface is not about phishing, but "identity" These latest arguments point to this bug being resolved as INVALID.
>Since http: is untreated by setting the ssl_domain_display pref to 1, 2, or any
>value, why are these examples relevant?

The fact that these sites don't use https increases the value of giving sll connections more of an ev style treatment.  If there is little difference between SSL and non-SSL (pref set to 0), these examples are now much more dangerous.  If we set the pref to 1 and the user relies of the site button for identity information (not everyone will do that, but some people will), then these examples have been countered because they won't get the blue button.  If in the future the phishing sites spend $9 to get one, it is going to say something really random, like "oorvtat.es," which is of little value.

>I've been told several times that this interface
>is not about phishing, but "identity" These latest arguments point to this bug
>being resolved as INVALID.

This UI is for allowing users quickly discern who they are connected to online.  The user might want to do that when they are typing confidential corporate secrets into an intranet blog, when they are about to make a purchase, or when they are logging into their bank.

Your position is that user's won't look to chrome for identity information, so presenting it is pointless.  By that same logic we could remove the location bar.

The vast majority of usability problems involve the user interface exposing too much of the underlying implementation, and failing to make proper abstractions.  However, every once in awhile a usability problem emerges because the interface fails to properly represent the reality of the underlining implementation.  This is one of those rare cases.  https and etld+1 are vastly more important than everything else in the location bar, but the current user interface does not give the user any indication of this fact.  Knowing how to parse URLs requires external knowledge outside of what is directly presented in the application, someone has to literally tell you how the internet works.  I'm not arguing in favor of setting the pref to 1 because I think it is the magical solution to phishing, I'm arguing in favor of it because the current UI of the location bar is tremendously bad at conveying the user's location on the internet.  The only reason we don't see how glaringly horrible the UI of the location bar is because it is hard for us to remember a time when we didn't know how it worked.
Just going to throw in my 2 cents here... it seems that the underlying problem (phishing, trust, etc.) is mostly a social/behavioral one.  And we are trying to find (and are wrangling over) a technical solution to this non-technical behavioral problem.  But there is no such solution because ultimately, the only real solution to this social/behavioral problem is a social/behavioral solution--i.e., educating the users.  So my two questions are,
1) To what extent is this UI trying to educate the users (thus facilitating a behavioral solution) and to what extent is the UI trying to act as a technical solution by acting as a proxy for a user's judgment? (IMHO, the old padlock was doing too much of the latter)
2) Is it the place of the UI to increase awareness and to help educate the user about such things?
I would note also that one reason phishers and scammers aren't using SSL is that it's not necessary yet. Enough people are clueless enough to type their credit card details into http://104.113.45.143. However, in the future, we hope, this may no longer be the case. And when people do decide to pay attention, we want to have something useful they can look at to determine identity.

sayrer said:
> I've been told several times that this interface
> is not about phishing, but "identity"

Determining identity is useful in many ways, one of which is to help people spot when they are being phished. So yes, this interface is not _just_ about phishing, but identity is one component in helping solve that problem.

I'm sure you don't want to repeat yourself, so if you could just provide a link to where you've explained what your positive position/alternative is? Do you think the user has no use for site identity information? Or do you think they do, but we should be obtaining it or displaying it in another way?

I think that identity information is important and useful, and will become more so. I can't see anywhere else we can get it securely but from an SSL certificate. Different types of certificate allow us to rely on different fields; for DV certificates, the only field we can rely on is the embedded domain name. ETLD+1 might mislead in one way (according to some). The full domain might mislead in another way (according to some). But no domain just puts people back in the position of self-parsing URLs for identity information. And that will "mislead" far more people (i.e. they can't or won't do it) than either of the other options.

Kai: I'm not sure there's a possible UI available that we could educate users _with_ for this problem. What we want is the UI which it is easiest to educate users _about_. Something sites can do in one sentence.

"Always look for "Bank of America (US)" in green in your browser location bar."
is the simple educational message for EV.

"Always look for somecompany.com" in <colour> in your browser location bar."
would be the message for ETLD+1.

"Always look for some text ending 'somecompany.com' in <colour> in your browser location bar."
would be the message for the full domain for a moderately complex site using multiple machines.

The educational difference between the last two is IMO significant.

Gerv
(In reply to comment #91)
>
>  The user might want to do that when they are typing confidential corporate
> secrets into an intranet blog, when they are about to make a purchase, or when
> they are logging into their bank.

That's phishing. This is not a phishing prevention measure. Stop with the doubletalk.

> 
> Your position is that user's won't look to chrome for identity information, so
> presenting it is pointless.  By that same logic we could remove the location
> bar.

That is not "logic".


(In reply to comment #86)
> 
> Anyway, phishing (or MitM) protection via painting pixels based on simple rules
> applied to a URL is unsound as far as I know. We're experimenting in a high
> risk low reward space. We could try setting the pref to 1, but at the last
> minute for Firefox 3? How will we know if it's not working (well, or well
> enough)? What next?

These are the right questions. We're still unproductively ratholing on setting that pref to 1, which is something that we shouldn't do, for reasons that are really sketchy.
(In reply to comment #93)
> 
> Determining identity is useful in many ways, one of which is to help people
> spot when they are being phished. So yes, this interface is not _just_ about
> phishing, but identity is one component in helping solve that problem.

My feeling is that we're putting a band-aid on a large flesh wound and calling it "part of the solution". This is looking more and more like blame-the-victim security, which plagues the browser space. In the worst case, it is security theater--something we do because Firefox is supposed to be secure, so we do things to make it look secure.

If we want to claim this helps to solve a security problem, we need to have better evidence that it does so before exposing the entire Web to it. We're already sending EV out there on a wing and a prayer, and it has better strings to display. Why not see how that value proposition works out?

Does anyone disagree with Brendan's point that this change is, low value, high risk, evidence free, and too late?

> 
> I'm sure you don't want to repeat yourself, so if you could just provide a link
> to where you've explained what your positive position/alternative is?

Phishing and other MITM attacks work because we let users submit reusable information, and the Web makes them do it often. Usernames and passwords are a common example. Phishing mitigation has two primary components:

 1) Send non-reusable data
 2) Send credentials less often

There are many ways of doing both of these things, but I freely admit we have yet to settle on a good combination. I think it would be productive to discuss on m.d.platform if you're game.
Firefox knows that the content you are currently looking at belongs to bugzilla.mozilla.org, Firefox doesn't know/care what content mozilla.org is serving, because that's not the identity of the entity serving the current content. It could (has been) argued that mozilla.org is the owner of of bugzilla.mozilla.org, and therefore the identity is one in the same, but for all I know the server at bugzilla.mozilla.org is being controlled by an entirely separate entity than the server at mozilla.org. (ignoring of course that a dns round-robin produces a similar effect, but assuming mozilla.org completely controls their own domain record)
The only thing Firefox is showing the user, that Firefox can verify as accurate information on the entire chrome is the URL, because Firefox knows that it just grabbed that resource. We allow the web page to dictate everything else, even the title of the browser on the windows chrome. 

If we are to set this pref, by all rights regarding the identity of the server serving the site, the proper setting is 2. If we wanted to somehow decorate the eTLD+1 on the identity button in addition to that then I think that's a separate bug.

I like Attachment 314754 [details], though I think EV should probably continue to show O name instead of an icon (since changing that UI so late, much like changing this pref so late is not ideal) and I like option B in the mockup on Comment #78, it's even possible to do both at the same time if we really wanted, thought that could end up looking cluttered. I do think however that those options are a little separate from this bug, or a huge bugmorph.
I'll just note that several banks login from a non-ssl page:

http://www.wamu.com/personal/default.asp

Hover over to the right.  
(In reply to comment #97)
> I'll just note that several banks login from a non-ssl page:
> 
> http://www.wamu.com/personal/default.asp
> 
> Hover over to the right.

Yes, and that's a really bad idea, because it means users are logging in from a page that isn't secure, and there's no meaningful way in the browser to know that you're submitting information to the wrong site until its already too late.  It's something we should be evangelizing against wherever we see it...
(In reply to comment #98)
> (In reply to comment #97)
> > I'll just note that several banks login from a non-ssl page:
> > 
> > http://www.wamu.com/personal/default.asp
> > 
> > Hover over to the right.
> 
> Yes, and that's a really bad idea, because it means users are logging in from a
> page that isn't secure, and there's no meaningful way in the browser to know
> that you're submitting information to the wrong site until its already too
> late.  It's something we should be evangelizing against wherever we see it...

Bug 261294 might bear on this, if we extend the warning situations to include "served from non-ssl site, and submitted to non-ssl site or site on different ETLD+1/full-domain/whatever".

For Robert and Brendan:

* High risk

Risk implies potential harm.  What harm will the proposed UI create for users?  That they'll learn to trust an imperfect representation of the site's identity, and may be victimized by that later?  Ultimately, if the option is "they won't have a UI they will interact with/trust at all" I think that's a far worst state.  It simply exacerbates the existing problem where users only look at content to make decisions.

I believe the current UI devalues SSL almost completely, unless you believe that users can distinguish SSL based on the fifth character in an opaque string.  Surely neither of you are arguing that.  The code has been in use in the alphas, and I have been using it for months now without a single issue, so I feel confident that the code risk is the absolute minimum of any solution anyone can design.

* Low value

The value here is that we are presenting a UI on SSL sites that is better than what we have.  Its like theme changes, or wording tweaks, or better spatial arrangements.  If it does a better job than the current UI at presenting information about where you are (which would be the job of a UI element called the Location Bar) then I think the value is clear to me.  I think there's been over-rotation on security by all parties, but ultimately the UI is presenting reasonably-true "you are here" information.  If that information is not important, then as Alex said we can safely remove the location bar as a permanent visual element.

Either location and identity of the site is important, and we should endeavour to enhance that information, or its not and we should remove the whole UI.  Pick a side, don't argue for the current broken state of affairs which requires that users understand URL syntax to understand where they are.

* Evidence free

I can make a pretty compelling case that the current UI is insufficient, and the old UI was harmful.  Doing nothing is not a viable answer, so even without objective evidence, we need to make a change, and in the absence of evidence we need to fall back on the collective expertise of the UX and Firefox teams to design a better experience.  I am absolutely willing to make a decision without objective evidence if I strongly believe that the change represents a clearly positive change, based on predictable human factors, and that the current UI is insufficient for users.  To not act in such a situation would be absolutely irresponsible.

* Too late

We should have made this decision a month or two ago.  I'm willing to accept blame for not pushing harder earlier, but I didn't react quickly to the shortcomings early enough.  I'm not willing to push a release out the door with poor primary UI that devalues SSL and only provides real utility for sites with EV certs.  Thus, we need to do something to rectify the problem before ship.  This is the lowest risk change we can make, and should not impact the schedule, beyond the time invested in arguing over this.

In the absence of a viable alternative, with the shared belief of the UX team, the security UI lead, and the Firefox module owner that this represents a positive change, I don't think there's any other decision I can make aside from flipping the pref, taking whatever lumps we take in the process, and keep trying to build a better UI for the next release.  The alternatives presented are "do nothing" (not acceptable to me, sorry to say) and "invent something different" (far more risky, and unlikely to be better on short notice).
(In reply to comment #93)
> I would note also that one reason phishers and scammers aren't using SSL is
> that it's not necessary yet.

If it becomes necessary and phishers get certs, there are means to revoke them, and potentially big problems for CAs who issued those certs (or [I can't resist] the CAs together with MSFT invent EV in order to upcharge for the privilege of not being phished via their cheapo certs! repeat for EV^2, EV^3 as each higher priced layer is corrupted for the inductive case :-P).

That "it's not necessary yet" for phishers to use https: is a non-argument, both because your sentences that follow (about users learning to look for the DV or EV button and therefore not be phished by http: URLs) are wishful thinking at worst, unproven research at best; and because if you follow your own premise, it leads to significant https: phishing -- which means root CA certs *will* be removed from NSS's db.

This bug is a mess (I'm partly to blame, but we are mapping messy terrain). The pref set to 1 is obviously "cleanest" in the sense of "the most designed and ship-shape", but it is under-tested to put it mildly. If we don't have a better alternative, we're poised to ship it and try to be accountable for its wins and losses.

It's not enough to object, as Rob and I (among others) are doing, since pref=0 is a loss compared to the SSL lock as mconnor notes in the last comment (blue around the favicon means nothing).

Yet it is always undesirable to be forced by lack of agreement or initiative to go with something suspect or risky. I hate being stuck in this kind of end-game. I hope others who have the skills to come up with a better (and both safely and quickly done) alternative feel the same way.

(In reply to comment #100)
Risk is probability times cost in standard risk analysis. If no phishers use https://good.evil.com/... then pref=1 does no good[*]. If eTLD+2 and higher are exploited (googlepages, ning, lj, myspace, etc.) then there could be harm (cost), possibly as high a cost as phishing.

We don't know the probabilities.

We do know https://good.evil is not used today (I welcome evidence; it's not in my Junk folders and no one cited it above), and I've just argued that our root CA certdb needs updating if that situation ever emerges.

So I still claim we're risking harm while doing no good. Why should we do that?

/be

[*] the separate argument that pref=1 trains users of, e.g. https://mumble.bankofamerica.com/barfl... to identify bankofamerica.com and look for it in the DV button, and therefore "does good", is in my opinion wishful thinking, and anyway research fodder. It's not "evidence" in favor of pref=1 at the last minute. It's a hypothesis.
If we are concerned about the loss of the lock and what that would mean, is it too late to put it back?

1) If we are concerned about the whole "lock-shaped favicon" problem, then we could just do what we did in Firefox 2: stick the icon on the right along with all the other icons. (I suspect this is why both Microsoft and Opera does their EV thing on the right instead of on the left)  So keep the site button with the favicon as-is and just revert the old FF2 lock indicator on the right.  I know it's late, but this seems simple enough...

2) If we are concerned about the whole "lock==good" thing without consideration for "identity" problem, then we could have a lock (or shield or whatever the popular meme is) for DV to indicate that you're safe from eavesdropping and MitM and then a second icon (a passport, or whatever) that appears in addition to the lock for EV.  Or if two icons is too much, then somehow modify the icon so that it appears differently for DV and EV.

So put the old security indicator back on the right, and I think setting the perf to 0 will become a little less painful of a decision.  Instead of a lock, what about a shield (the passport looks too much like a door and is not as universally recognized)?  A blue outline of a shield for DV.  A green filled-in shield for EV.
http://business.hsbc.com.for2hafc.info/sys_directory/isa/file.aspx/... and a bunch of other examples of good.com.filler.evil.com  were provided by johnath, do those not count?  Maybe I don't understand the argument?
(In reply to comment #103)
> http://business.hsbc.com.for2hafc.info/sys_directory/isa/file.aspx/... and a
> bunch of other examples of good.com.filler.evil.com  were provided by johnath,
> do those not count?  Maybe I don't understand the argument?

I pointed Mike to the http: at the front over IRC.

If this is being missed, people are not following the argument in comment 101 (and elsewhere) closely. Phishers don't use https: so they won't get the DV button.

The only argument then is the wishful/research one that training https://...bank.com users to expect that button may help trained users see the lack of it for http://bank.com.evil.net/.

/be
Ok, I got sucked into the phishing rathole again.  I know better.  Brendan makes some good points, but I think the key one is that at this point, it doesn't solve phishing at all, because no one uses https for phishing.  And that is unlikely to change as long as we don't attack on two fronts: presenting more usable http UI and reducing the dependence on reusable credentials.  We need to do both, in the short term, though I believe that the latter is the preferred longer term solution.  So let's drop phishing from the discussion, because ultimately, its not the problem we're going to solve here, and its a convenient strawman that we keep stuffing back up.

So let's consider the legitimate SSL case.  When users are entering sensitive information, the previous and current UI treatments do very little to provide users with meaningful information about what site to which you're giving your sensitive data.  The old UI was predominantly focused on a binary choice (you are secure/you are not secure).  Replacing that with a different binary option is pointless and does no one any good.  We've been arguing in public for quite some time that the issue is actually twofold: "are you connected securely?" and "who are you actually connected to?"  When I get redirected from a small e-commerce store to a third party payment processor, I should have UI that makes it reasonably clear who I am giving my credit card digits to.  DV-SSL is not a guarantee to the user beyond "you are connected to the site your browser tried to connect to."  There is no compelling case to be made that showing this information in the form of a URL is effective, the evidence is that users fail to parse it and learn to ignore it.

Domains, in comparision, are reasonably understood by users (as can be evidenced by their continued use in TV and radio ads, and in the continued value of simple domains (see: pizza.com's $2.6 million price tag).  So building a UI where the domain is the primary element is an obvious way of providing information that users actually understand.  Its not perfect, but no one has come up with something better (and the people Brendan hopes to see pull a rabbit out of the hat have been aware of the various constraints for a year).

The point of building an identity-driven UI was to eliminate the binary decision point of "am I secure or not" and provide clear cues to answer both of the questions.  The evaluation of this design should rest on whether it breaks the binary choice in a productive way or not.  Right now, we don't tell you you're secure, we leave you to distinguish based on a single letter in a URL.  Or we use a semanatically confusing color to indicate SSLness.  Yellowness to respond to blueness? :)  This is something better.  It is not perfect, but it is better, for what I believe is the primary use case.
FWIW, Brendan's comment around cross pollinating https and http is not my argument.  I would be pretty silly to argue that.  Not having a big blue piece of UI _might_ be noticeable, but the text itself won't teach users to read and parse URLs.  I don't think anyone's made that argument, but its certainly not mine.

What the site button can/will show is information based on what we reasonably believe to be true and verifiable.  In EV, that's the orgname.  In DV, that's the domain name.  In http-land, we really don't know whether foo.com is foo.com, or bar.com with DNS/MITM evil working for it, so we don't show it as verified information.  Better presentation of URI elements would help http, but those were shouted down in another bug.  We need to revisit that and gather hard evidence to better support that type of presentation, but that's way way out of scope for this release.  There isn't evidence, yet, that teaching users to make use of verified information will lead to them noting the absence of such information, so I won't argue the potential benefits.  But in the case where you are on that site, you get information that is understandable and concise.  Anecdotally, I use the site button information far more often than I ever read URLs anymore, because its simpler and all I care about when interacting with SSL sites (I don't need scheme, I don't care about path, I care only about whether I'm on the site I think I'm on).
(In reply to comment #105)
> So let's drop phishing from the discussion,
> because ultimately, its not the problem we're going to solve here, and its a
> convenient strawman that we keep stuffing back up.

Can I hear an AMEN from Alex, Mike, and Johnathan?

> There is no compelling case to be made that showing this
> information in the form of a URL is effective, the evidence is that users fail
> to parse it and learn to ignore it.

Indeed this applies to the button label too.

> Domains, in comparision, are reasonably understood by users (as can be
> evidenced by their continued use in TV and radio ads, and in the continued
> value of simple domains (see: pizza.com's $2.6 million price tag).

Sorry, you have changed terms. If you mean by "Domains" eTLD+1 instead of FQDN, which is specifically what is "validated" in the DV case (not the eTLD+1 suffix), then you are talking about bank.com or bank.co.uk. But billboards often put the www. in front.

This is not immaterial -- try going to https://amazon.com/ in Firefox 3 (is there a bug on that?).

Also, billboards are far removed from the blue button's label. Billboards are using TXT numbers in some countries in preference to URLs. Do those make good button labels? Of course not. Better to argue from direct user experience in browsing, typing in something to the awesomebar, and reading (or not) the button or bar text.

> (and the people Brendan hopes to see pull a
> rabbit out of the hat have been aware of the various constraints for a year).

Some of those people professed to be phighting phishing, even a day or two ago. Some did not advert to the https: vs. http: difference even that recently. And there's been only grudging acknowledgment of the inherent eTLD+1 risk for sub-domains of eTLD+1 where trusting the super-domain is not sufficient to trust the sub-domain.

So no, I don't think alternatives have been given a fair shot, for the record. It seems to me a particular focus on https: and bank.com use-cases, to try to train users to look for the blue button's eTLD+1 as an identity badge, hogged design attention to the exclusion of singificantly different approaches.

Again I'm not saying this approach will fail -- it may win. It's just not yet supported by evidence; the user-training scenario is a hypothetical "just-so" story in the absence of real-world testing.

> The point of building an identity-driven UI was to eliminate the binary
> decision point of "am I secure or not"

Users want that and banks cater to it by putting the lock, or whatever is used in its place, in-band in the content area -- and Gutmann shows this works. We are far from certain victory by innovating in chrome, and there's downside risk to eTLD+1.

> Right now, we don't tell you
> you're secure, we leave you to distinguish based on a single letter in a URL.

Yes, that's broken, can't ship with pref=0. I don't think anyone disagrees.
 
> Or we use a semanatically confusing color to indicate SSLness.  Yellowness to
> respond to blueness? :)  This is something better.  It is not perfect, but it
> is better, for what I believe is the primary use case.

Maybe. It's a bet at this point where the user could pay more than with the old Firefox 2 "DV-SSL" model.

Independent of that statement, this needs to be said: module owner(s) and peers standing pat on pref=1 will leave those who disagree with the design and (more important) the assumptions and methods used to develop it, who found it hard to get consistent ("not about phishing! ... oh, ok it is, sorta") or any responses to their objections until late in the game, demanding some pounds of flesh if there's blow-back. Accountability is in everyone's interest.

We must find a better evidence-based development process. Perhaps testpilot can help with at-scale testing (I don't care about selection bias at high scale or to first order -- let's get some real-world data).

Beyond that, we should work on the lower levels of the protocol stack to fix the reusable credentials problem. Patching at the wrong layer fails sooner or later. That means redistributing development effort, bulking up elsewhere.

/be
(In reply to comment #107)
> (In reply to comment #105)
> > So let's drop phishing from the discussion,
> > because ultimately, its not the problem we're going to solve here, and its a
> > convenient strawman that we keep stuffing back up.

I am happy to read this.

> 
> > The point of building an identity-driven UI was to eliminate the binary
> > decision point of "am I secure or not"
> 
> Users want that...

The elimination of this binary decision was deemed necessary to solve a problem. Since it's not phishing, what is the problem, exactly? If there's no attack going on, content does a stellar job of telling users what site they're on.

I see the value of giving users more information if they're feeling unsure, but an ever-present indicator is a high price to pay for a rare situation. For example, I'm going to be alerted the fact that mozilla.org is the last bit of bugzilla.mozilla.org every time I visit. Great.

>
> ... found it hard to get consistent ("not about phishing! ... oh, ok it is, sorta")
> or any responses to their objections until late in the game

Moving forward, the fix is simple. Don't let features land with prefs like this on release branches. I'm surprised the 4+ people working on this let this detail slip by until it was just too darn late to do anything but stick with their months-old, unchanged design.
If you guys want to decide it's not about phishing, then I'm not going to drag the argument back in that direction, but I would note that if your points about users not observing identity UI were accepted, the logical conclusion would be that both they and we are stuffed, because whatever we do, they are going to ignore it. And I think that's unnecessarily pessimistic.

If users _only_ look at the content to determine where they are, there's basically nothing we can do to help them. So some amount of user education is necessary in that case. The goal, therefore, is to make that education be as minimal as possible. (As I have argued here: http://www.gerv.net/security/stay-safe/discussion.html in support of our status bar UI in Firefox 2, which is the same as the DV indicator with pref set to 2.)

But some education is unavoidable. If we manage to create a UI consistent enough with other browsers (and there's been movement on that both from our side and from Microsoft, thanks to Johnath's liaison work) we can recruit banks, consumer groups etc. to push the simple message. But it has to be one message, it has to be consistent, it has to be built on rock rather than sand (hence EV as opposed to DV) and it has to be simple (hence, I argue in comment 93, ETLD+1 rather than full).

20 years ago in the UK, no-one wore seatbelts. After a long campaign, almost everyone now does. If you keep pushing a simple message ("Clunk. Click.") and a rationale, people will eventually get the point.

Gerv
(In reply to comment #105)

> We've been arguing in public for quite
> some time that the issue is actually twofold: "are you connected securely?" and
> "who are you actually connected to?"  When I get redirected from a small
> e-commerce store to a third party payment processor, I should have UI that
> makes it reasonably clear who I am giving my credit card digits to.

Finally getting somewhere again.  How exactly does the domain tell the user who they're connected to? If it's a third party site that they've never connected to before, all it'll do is tell them where they are. I thought this is why the current UI shows organization name.  The problem still remains though, how is the user supposed to put 2 and 2 together from the current UI?  Seems to me you're hoping the user decides to educate themselves on this new annoyance. At least if it were connected to some sort of icon that means *ID* that might help the user connect the dots, just like a lock helps users figure out that somehow these sites are safer than others.


> 
> Domains, in comparision, are reasonably understood by users (as can be
> evidenced by their continued use in TV and radio ads, and in the continued
> value of simple domains (see: pizza.com's $2.6 million price tag).  So building
> a UI where the domain is the primary element is an obvious way of providing
> information that users actually understand.

Then the best way to do this is to separate the domain within the rest of the address visually.  This leaves the domain in context and stands a chance at a) the user putting 2 and 2 together that that's the domain part of the url, and b) the user starting to learn how to find domains in the url for themselves.

> The point of building an identity-driven UI was to eliminate the binary
> decision point of "am I secure or not" and provide clear cues to answer both of
> the questions.  The evaluation of this design should rest on whether it breaks
> the binary choice in a productive way or not.  Right now, we don't tell you
> you're secure, we leave you to distinguish based on a single letter in a URL. 
> Or we use a semanatically confusing color to indicate SSLness.  

But it's predictable. If you remove it without some indicator to transition users who DID figure it out (which is probably close to the same group that will figure this out, with the current implementation) then you're putting them at risk, or they're going to lose time trying to figure out why paypal is no longer yellow.

Simply showing the domain doesn't tell the user *who* they're submitting the info to, nor does it tell them they're secure. It works in the case of phishing where a user might end up somewhere besides where they think they are, but this isn't the problem we're trying to solve, I thought.

In the current implementation there's actually quite useful information once you click on the ID button, but there's no way right now for users to figure out it's there. If there's no other way to convey to a user that when a domain shows up with the favicon it means they're connected to that domain securely,  then I don't think this *is* better.  You're *still* relying on the user to find the s and put it together themselves.

(In reply to comment #95)
> Phishing and other MITM attacks work because we let users submit reusable
> information, and the Web makes them do it often. Usernames and passwords are a
> common example. Phishing mitigation has two primary components:
> 
>  1) Send non-reusable data
>  2) Send credentials less often
> 
> There are many ways of doing both of these things, but I freely admit we have
> yet to settle on a good combination. I think it would be productive to discuss
> on m.d.platform if you're game.

Definitely game. But both of these thinks look like things that sites have to do, not us. Or is that your point?

Gerv

http://www.cs.auckland.ac.nz/~pgut001/ -- read it and weep (and laugh), including

http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf

Patching at the wrong layer, in defiance of what we know about users (not from billboard URL effectiveness!), is folly. I think that's Rob's point. Yes, you bet sites have to change.

/be
(In reply to comment #109)
> If you guys want to decide it's not about phishing, then I'm not going to drag
> the argument back in that direction, but I would note that if your points about
> users not observing identity UI were accepted, the logical conclusion would be
> that both they and we are stuffed, because whatever we do, they are going to
> ignore it. And I think that's unnecessarily pessimistic.

I will agree that it's fairly pessimistic, but this old story:
http://computerworld.co.nz/news.nsf/UNID/FCC8B6B48B24CDF2CC2570020018FF73
points towards it being true.

They even state "The main risk such a fault indicates is social and educational, not technical, Benson says."
And so we have to decide, is our UI going to start educating users? IMO the security UI gives the user the information they can utilize, and it is within our best interest to educate users about the UI. After that however, it is a little beyond the scope of the browser to start educating the users towards better security decisions.

That being said, I could see Mozilla wanting to educate users to make better security decisions, but using the browser is IMO the wrong way to do it, a better solution IMO would be something on a relevant page like (for example): "Firefox is a browser that supports the latest security tools available to us, but the end user is the most important part of security. <a>Learn More about how to protect your security on the internet</a>."
Couple points, not directly responding to a lot, need to spend some time writing a better response, but throwing ideas out there in the interest of continuing to move forward.

* I'm not standing pat on 1 vs. 2, I'm standing pat on the concept that some sort of string matters if we believe showing validated identity information is important for DV-SSL.  This is not an icon design problem, that would create a binary "you are/are not secure" indicator that will be no better than the padlock, and will just show up in content.

* The arguments used to justify the superiority of FQDN vs. eTLD+1 seem to be built on sand.  EV (and original OV-style SSL) is built on the assumption that you can trust the organization (for whatever value of trust).  You are not trusting the webmaster, or the individuals with access to the CMS for the site, you are trusting the organization who owns the site, which in turn trusts the individuals.  I don't think that's much different from a domain owner who delegates administrative authority for subdomain.domain.tld to someone else.  Brendan keeps quoting jwz.livejournal.com, but that was iirc the fix to the hack, not the domain that was hacked (see HTTPOnly cookie bug for the sordid story), so not sure that even applies.  Of course, on further thought, I think FQDN is the wrong answer for similar reasons to eTLD+1, its not what we've really verified via SSL.

In many cases, we're dealing with wildcard certs (i.e. bugzilla etc use *.mozilla.org) so we haven't verified "bugzilla.mozilla.org" we've verified "something ending in mozilla.org") so we don't really need/want to show the FQDN in that case anyway, if you want to be technically correct about what we've verified.  Whether we show *.mozilla.org or mozilla.org is really a user understanding question around whether "*." is meaningful enough and not nearly as important as whether or not to show that information.

So here's an idea, based on expressed concerns around accuracy of information.

* eTLD+1 doesn't solve the problem of evil.good.com.
* FQDN presents fudgy information in the case of wildcard certs (if evil.good.com gets to host using *.good.com's cert, well, good.com is owned anyway, since even if you inspect the cert it'll be legit, so the distinction is meaningless) so its not really useful or necessary to show the FQDN, since the cert isn't for that value.  foo.good.com and bar.good.com are one and the same, identity-wise, in the wildcard cert case, so we shouldn't make unnecessary distinctions between the two.

So we should present the Common Name (CN) that the cert provides.  If I have a cert for evil.good.com, it'll say evil.good.com.  If I have a cert for *.good.com, we show good.com (I don't believe the wildcard is meaningful).  We will show the full verified amount of the domain string in the UI, since that is what you are choosing to trust.

There's other comments I want to address, but this is a better plan, so I want to get it out there.
(In reply to comment #114)
> So we should present the Common Name (CN) that the cert provides.  If I have a
> cert for evil.good.com, it'll say evil.good.com.  If I have a cert for
> *.good.com, we show good.com (I don't believe the wildcard is meaningful).  We
> will show the full verified amount of the domain string in the UI, since that
> is what you are choosing to trust.

I think that if we're accessing foo.good.com and get a cert for *.good.com, we should show "foo.good.com" rather than the suffix (which _doesn't_ actually match *.good.com's cert info, if I recall my own experiments with wildcard certs correctly).  *.good.com is semantically equivalent to the cert listing foo.good.com, bar.good.com, evil.good.com, etc. for all the *.good.com hostnames that we find it on.

In fact, I believe that it's legal for a cert to just carry multiple site names in it, possibly entirely disjoint: http://help.godaddy.com/topic/599/article/3908 for an example, or play with openssl's subjectAltName.  If the cert carries securelolcats.com and enhancedbottomline.com, what would you show when connecting to either?  Not the list, and not "com", I'm sure.

The user doesn't and shouldn't care what text is in the cert; she should care what guarantees we can make about the site she's visiting.  In the DV case we can make a guarantee that she's at foo.good.com, whether we found "foo.good.com", "*.good.com", or ["foo.good.com", "pkimeharder.net", "www.foo.good.com"] in the cert's data itself.
(In reply to comment #114)
> * The arguments used to justify the superiority of FQDN vs. eTLD+1 seem to be
> built on sand.  EV (and original OV-style SSL) is built on the assumption that
> you can trust the organization (for whatever value of trust).

That assumption may be built on sand because of the user-generated content threat. You can't use it:

> You are not
> trusting the webmaster, or the individuals with access to the CMS for the site,
> you are trusting the organization who owns the site, which in turn trusts the
> individuals.

to justify itself. That's circular reasoning.

> I don't think that's much different from a domain owner who
> delegates administrative authority for subdomain.domain.tld to someone else.

Blame the top-level, blame the user. How about blame the browser vendor? This is shoddy arguing.
 
> Brendan keeps quoting jwz.livejournal.com,

One mention in comment 60 is not "keeps quoting". Shoddy, I say :-(.

> but that was iirc the fix to the
> hack, not the domain that was hacked (see HTTPOnly cookie bug for the sordid
> story), so not sure that even applies.

Did you read comment 60? I alluded to the history of the lj hosting debacle and how it was different, but pointed to the next threat. Think ahead for a change, and look at the other similarly hosted cases which might support SSL and where trusting eTLD+1 is not sufficient to trust eTLD+2.

> Whether we show *.mozilla.org or mozilla.org is really a user
> understanding question around whether "*." is meaningful enough and not nearly
> as important as whether or not to show that information.

This is a fair point, but it undermines your own belief that users will read eTLD+1 and expect it to reappear consistently. They might just see a blue bar shaped button with a string in it, and not read the string. They might not even notice the blue button.

BTW, I'm using reply which reloads the bug with #add_comment added on the end of the URL, and the blue button went away. Known bug?

> So we should present the Common Name (CN) that the cert provides.  If I have a
> cert for evil.good.com, it'll say evil.good.com.  If I have a cert for
> *.good.com, we show good.com (I don't believe the wildcard is meaningful).

This is an improvement as far as I can tell -- thanks for going outside the box (at the last minute).

/be
(In reply to comment #116)
> BTW, I'm using reply which reloads the bug with #add_comment added on the end
> of the URL, and the blue button went away. Known bug?

I have the pref set to 2, BTW.

> This is an improvement as far as I can tell -- thanks for going outside the box
> (at the last minute).

Damn, then shaver tore it all apart. Still, I wanted to encourage thinking outside of the narrow EV model. We're doing EV, we've swallowed libpkix, etc. For DV we need some different thinking.

/be
(In reply to comment #115)
> (In reply to comment #114)
> > So we should present the Common Name (CN) that the cert provides.  If I have a
> > cert for evil.good.com, it'll say evil.good.com.  If I have a cert for
> > *.good.com, we show good.com (I don't believe the wildcard is meaningful).  We
> > will show the full verified amount of the domain string in the UI, since that
> > is what you are choosing to trust.
> 
> I think that if we're accessing foo.good.com and get a cert for *.good.com, we
> should show "foo.good.com" rather than the suffix (which _doesn't_ actually
> match *.good.com's cert info, if I recall my own experiments with wildcard
> certs correctly).  *.good.com is semantically equivalent to the cert listing
> foo.good.com, bar.good.com, evil.good.com, etc. for all the *.good.com
> hostnames that we find it on.

That is technically correct, yes.  (Futurama bureaucrat: "you are technically correct -- the best kind of correct").  We know that *.good.com in a CN doesn't work for good.com itself, (see https://mozilla.org) since that's the way the PKI spec works, though I think that's a flawed spec.  I don't think that represents a distinction users will understand or should care about, so I honestly don't believe its necessary to reflect that technical issue in how we present the UI.  I'd rather show the wildcard

> In fact, I believe that it's legal for a cert to just carry multiple site names
> in it, possibly entirely disjoint:
> http://help.godaddy.com/topic/599/article/3908 for an example, or play with
> openssl's subjectAltName.  If the cert carries securelolcats.com and
> enhancedbottomline.com, what would you show when connecting to either?  Not the
> list, and not "com", I'm sure.

Ah, ye olde subjectAltName.  I shouldn't cross swords with you before coffee, clearly.  "If a subjectAltName extension of type dNSName is present, that MUST be used as the identity." is what RFC 2818 says (yes, its a different context for identity, but that's what we're talking about displaying), so we do that.  Thus you're on securelolcats.com, we'll display that, because that's what the cert says, so that's what we're validating against.
I would totally be in for us being ballsy and saying treating *.foo.com as matching foo.com, but we probably need to buy more laudanum for the NSS team if we tried it, and that's not a game for an RC cycle.

I don't think that showing "*.foo.com" to the user is a good idea, since asterisk more commonly means "there are details out-of-line" than "wildcard" to non-nerds.  We should show the identity of the site if we verify it, since that's the only thing that correlates with the decision we want to help the user make, right?  He doesn't want to play pattern matching games, he wants to know if he's where he thinks he is.  Making him expand a wildcard seems like nerd purity trumping whatever utility this label has in the first place.  We could put *.foo.com in larry's window if we thought that such a detail was of interest to people who aren't going to want to dig through the Details page of the cert viewer anyway.
(In reply to comment #119)
> I would totally be in for us being ballsy and saying treating *.foo.com as
> matching foo.com, but we probably need to buy more laudanum for the NSS team if
> we tried it, and that's not a game for an RC cycle.

Who said anything about NSS?  If we think its the right thing, why can't we treat them as equivalent?  In any case, if we want to be pedantic about it, foo.good.com is pretty weakly validated to be the correct foo.good.com, its not a 1:1 relationship in the wildcard cert case.  All we can validate is that the site is something.good.com which matches the wildcard, so all I think we're really validating is "its something at good.com" rather than specifically knowing that we're at the "right" place.  (I suspect this is why there's no wildcard EV certs, aside from the obvious profit motive that many point to.)

> I don't think that showing "*.foo.com" to the user is a good idea, since
> asterisk more commonly means "there are details out-of-line" than "wildcard" to
> non-nerds.  We should show the identity of the site if we verify it, since
> that's the only thing that correlates with the decision we want to help the
> user make, right?  He doesn't want to play pattern matching games, he wants to
> know if he's where he thinks he is.  Making him expand a wildcard seems like
> nerd purity trumping whatever utility this label has in the first place.  We
> could put *.foo.com in larry's window if we thought that such a detail was of
> interest to people who aren't going to want to dig through the Details page of
> the cert viewer anyway.

Agree, but I think its preferable to drawing a false distinction between foo.good.com and bar.good.com, since both are validating to the same cert.  I don't think we're far apart at this point, in any case.
(In reply to comment #120)
> (In reply to comment #119)
> > I would totally be in for us being ballsy and saying treating *.foo.com as
> > matching foo.com, but we probably need to buy more laudanum for the NSS team if
> > we tried it, and that's not a game for an RC cycle.
> 
> Who said anything about NSS?

I understood that, as part of being FIPS validated as a browser, we took all our crypto cues from NSS's interpretation of such things.  If we want to deviate here, and think that we can, that seems like a reasonable win to pursue when we have more time to get feedback on it.

> In any case, if we want to be pedantic about it,
> foo.good.com is pretty weakly validated to be the correct foo.good.com, its not
> a 1:1 relationship in the wildcard cert case.  All we can validate is that the
> site is something.good.com which matches the wildcard, so all I think we're
> really validating is "its something at good.com" rather than specifically
> knowing that we're at the "right" place.

If you're concerned about an attack whereby DNS is poisoned to redirect private.foo.com/post-comment.cgi to public.foo.com/post-comment.cgi, and relying on the wildcard nature of the cert to hide the attack, then I think you need to treat subjectAltName the same way.  I'm not concerned about that attack, and I don't want to be pedantic about it -- I want to tell the user the thing that we think is most relevant to whatever trust decision we're hoping she makes.  (That in comment 121 I still have to say "whatever trust decision" is a bigger problem than even the most bogus interpretation of wildcards or altnames, of course.)

We can't be sure that the host we're connecting to is the one that should be running the service even if there is only a single domain name that can match the cert -- an old machine taken out of the DNS round-robin could be the target of a DNS poisoning attack in order to get the user to send their data to old site code.  I don't care about that attack either, fwiw.

> Agree, but I think its preferable to drawing a false distinction between
> foo.good.com and bar.good.com, since both are validating to the same cert.

I don't suggest that we make a distinction between them; I suggest that they be treated exactly the same way, which is to say that we treat them like we did in FF2 and show lock-n-gold.

If we're not going to do what FF2 did, and roll the dice on feedback-proof timing of security UI changes, then I think that we should show the domain to which the user connected, if it matches the cert provided.  That there is cryptographic verification of the domain is what's important; how that verification is performed against different fields in the cert data is trivia.
(In reply to comment #121)
> (In reply to comment #120)
> > (In reply to comment #119)
> > > I would totally be in for us being ballsy and saying treating *.foo.com as
> > > matching foo.com, but we probably need to buy more laudanum for the NSS team if
> > > we tried it, and that's not a game for an RC cycle.
> > 
> > Who said anything about NSS?
> 
> I understood that, as part of being FIPS validated as a browser, we took all
> our crypto cues from NSS's interpretation of such things.  If we want to
> deviate here, and think that we can, that seems like a reasonable win to pursue
> when we have more time to get feedback on it.

Do our crypto cues have to be reflected in how we present identity UI derived from crypto APIs?  That doesn't actually seem quite right to me, can you point to where FIPS actually requires that any UI be based on what NSS provides?  If that's a real objection, I would like to see exactly what requirements we have in place, since I'm sure we've had FIPS certified Mozilla browsers that didn't show the domain anywhere at all in the UI.

> > In any case, if we want to be pedantic about it,
> > foo.good.com is pretty weakly validated to be the correct foo.good.com, its not
> > a 1:1 relationship in the wildcard cert case.  All we can validate is that the
> > site is something.good.com which matches the wildcard, so all I think we're
> > really validating is "its something at good.com" rather than specifically
> > knowing that we're at the "right" place.
> 
> If you're concerned about an attack whereby DNS is poisoned to redirect
> private.foo.com/post-comment.cgi to public.foo.com/post-comment.cgi, and
> relying on the wildcard nature of the cert to hide the attack, then I think you
> need to treat subjectAltName the same way.I'm not concerned about that
> attack, and I don't want to be pedantic about it -- I want to tell the user the
> thing that we think is most relevant to whatever trust decision we're hoping
> she makes.  (That in comment 121 I still have to say "whatever trust decision"
> is a bigger problem than even the most bogus interpretation of wildcards or
> altnames, of course.)

I'm not concerned about this attack.  If I was, would I be arguing for not showing public and private?

> We can't be sure that the host we're connecting to is the one that should be
> running the service even if there is only a single domain name that can match
> the cert -- an old machine taken out of the DNS round-robin could be the target
> of a DNS poisoning attack in order to get the user to send their data to old
> site code.  I don't care about that attack either, fwiw.
> 
> > Agree, but I think its preferable to drawing a false distinction between
> > foo.good.com and bar.good.com, since both are validating to the same cert.
> 
> I don't suggest that we make a distinction between them; I suggest that they be
> treated exactly the same way, which is to say that we treat them like we did in
> FF2 and show lock-n-gold.

If you're going to argue this is correct, I'm not sure you've actually absorbed why we've spent the last year evangelizing "lock == bad" to anyone who would listen.  I'd rather ship substandard UI than ship harmful UI.

> If we're not going to do what FF2 did, and roll the dice on feedback-proof
> timing of security UI changes, then I think that we should show the domain to
> which the user connected, if it matches the cert provided.  That there is
> cryptographic verification of the domain is what's important; how that
> verification is performed against different fields in the cert data is trivia.

I suggested setting the pref to 2 how many comments ago?  That was either ignored or glossed over, I guess.  The net difference between what you're asking for and what I'm suggesting is solely in the wildcard cert case, where you're arguing that foo.good.com and bar.good.com are different and should be treated as different, and I'm arguing that they're not different enough to warrant calling them out, and its more or less adding noise where there is no discernible benefit (except for your hypothetical attack case between public and private, but if you control one, you can DNS poison anyway, with no failure for crypto purposes).
(In reply to comment #122)
> 
> If you're going to argue this is correct, I'm not sure you've actually absorbed
> why we've spent the last year evangelizing "lock == bad" to anyone who would
> listen.  I'd rather ship substandard UI than ship harmful UI.

Note that Comment 108 is unanswered. It doesn't look like there is a clear problem statement. What advantage does this new UI have over the lock?
> > > Agree, but I think its preferable to drawing a false distinction between
> > > foo.good.com and bar.good.com, since both are validating to the same cert.
> > 
> > I don't suggest that we make a distinction between them; I suggest that they be
> > treated exactly the same way, which is to say that we treat them like we did in
> > FF2 and show lock-n-gold.
> 
> If you're going to argue this is correct, I'm not sure you've actually absorbed
> why we've spent the last year evangelizing "lock == bad" to anyone who would
> listen.  I'd rather ship substandard UI than ship harmful UI.

I understand that the lock is bad. I'm on a fair number of public records saying that it's harmful, and why.  If you have found that I have misrepresented our position in those cases, I welcome your feedback on how to improve.

Sometimes I have even been reckless enough to describe what the characteristics of a better replacement would be, in terms of effects on the user's decision-making and understanding of the guarantees being made.  That may have been an error, since I have not yet seen anyone be similarly reckless in this bug, other than Johnathan's allusion to -- but not actual description of -- supporting evidence in comment 5.

I do not believe that "anything that is not the lock" is necessarily better.  I do not believe that we should churn the UI for the sake of having it be "not lock", when nobody can seem to say what outcome they expect, or why they expect to get it.  It's not about phishing, so it's about...something other than phishing, notwithstanding the constant references to phishing patterns in this bug.  But what?  Are we doing this just to show motion, and take one for the team in the quest to get rid of the overloaded padlock?

Why do you think "boldness of domain suffix" is less harmful?  What is the harm that you are trying to mitigate, and how will you know if ETLD+1 or simply the gold bar or full-domain mitigate it more or less than the current lock-and-gold?  How will you know if we need to design a fourth-generation indicator for DV, when we get ready to ship FF3.next?  How will you know if we should revert to lock-and-gold, because blue-and-bold has sufficiently bad effects on ... :mystery:?  (How does this process differ from the one that got us the suboptimal FF2 warning-colour-for-increased-trust thing that we're so desperate to replace at any cost?)

If someone could say why the bolded domain suffix is better than the lock, in terms of some specific user reaction, behaviour, or decision, I might support this even though I think that ETLD+1 isn't nearly future proof enough to be teaching users to make decisions on (and that full-domain is just going to be painfully awkward UI for long domain names; and that a cue that is primarily based on colour makes me nervous given theming, personas and a11y; and that it seems that the thinking around what we're actually identifying here, cert vs. site, is still pretty unformed) -- I am willing to take pain with my gain.  If someone could even _define_ "better", without being able to explain _why_ this new model is better, it would be heartening, because then we'd have half a chance of knowing if we needed to keep working on the problem after we see actual users making decisions based on bold-and-blue.  I suspect I'll get worn down long before I actually see anything like experimental design or a clear problem statement, but maybe if I'm a really good boy and finish my vegetables someone will help me "absorb" success criteria for a major and intrusive change to a primary UI element?  We did better than this on reasoning about the size of the back button, and my perhaps-naive instinct is that we should care more about this case.
The decision for Firefox 3 is the preference will stay as it is. 
That closes this bug.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: blocking-firefox3? → blocking-firefox3-
Resolution: --- → FIXED
(Please don't read this as an attempt to reopen the debate.)

Mike: given the amount of discussion this issue has caused, and the general project tendency towards openness, it is possible to know a bit more? Did one particular factor tip the scales? Was new information involved, or just an balancing of the points put forward here? Was it a consensus decision among release drivers, or did one person make the resolving call?

Gerv
Gerv: mconnor and beltzner are Firefox module and UX owner (not a module, but delegated within Firefox), this looks like standard module owner-based decision-making. It could use more explanation (although this bug explains things enough in my book), but it's not an exceptional case of how something is decided.

/be
OK, thanks. Like I said, I'm in no way disputing the decision or the authority of those who made it; only suggesting that it would be useful to know whether there was a balance-tipping issue.

Gerv
The lateness of the hour in flipping the pref is enough in my book.

The EV-model, which is way under-tested, being extended to "DV" without evidence that it does good, and with some downside risk (sub-domain trustworthiness), is also a problem. If it were earlier we might somehow get evidence that it's not a problem. But see first paragraph.

/be
Attachment #301285 - Flags: review?(mconnor)
Attachment #301285 - Flags: review-
So the apparent lateness of this feature meant it got punted from the FF3 beta.  But I personally believe this is useful security UI mechanism and would like to see it enabled at some point.  

There are some valid concerns around hiding the hostname which might be addressable (i.e. show the host portion for several seconds then scroll it off).

But helping users parse what is otherwise an atrocious security mechanism (i.e. the URL) is a goal worth pursuing.
(In reply to comment #130)
> So the apparent lateness of this feature meant it got punted from the FF3 beta.
>  But I personally believe this is useful security UI mechanism and would like
> to see it enabled at some point.  

I personally tried this pref set as proposed for a long time, and it just moved the awesomebar click target around (but I use cmd-L, mostly, so not a big deal ergonomically -- just visually disconcerting/distracting/annoying), cost that bar some horizontal real estate (I maximize, so not a big deal again), and added redundant yet misleading information (I live in http://bugzilla.mozilla.org/).

> There are some valid concerns around hiding the hostname which might be
> addressable (i.e. show the host portion for several seconds then scroll it
> off).

Please, no more moving/jumping/twitching UI that confounds muscle memory and gives us Fitts' Law fits.

> But helping users parse what is otherwise an atrocious security mechanism (i.e.
> the URL) is a goal worth pursuing.

From comment 101:

"[*] the separate argument that pref=1 trains users of, e.g.
https://mumble.bankofamerica.com/barfl... to identify bankofamerica.com and
look for it in the DV button, and therefore "does good", is in my opinion
wishful thinking, and anyway research fodder. It's not "evidence" in favor of
pref=1 at the last minute. It's a hypothesis."

We're in no better place to do this research for Firefox 3.1b2 than we were near the end of the 3.0 cycle.

We need a better approach, including consistency about the intended purpose of the UI (train users to what end? not to defeat phishing, almost everyone agreed in this bug), what are the downsides, and how we would measure success/failure.

From comment 108:

"The elimination of this binary decision was deemed necessary to solve a
problem. Since it's not phishing, what is the problem, exactly? If there's no
attack going on, content does a stellar job of telling users what site they're
on."

Hoping to train users to understand eTLD+1 domain name text labels on blue non-traditional looking buttons in chrome but not content makes me ask: Have you read Peter Gutmann's writings? See comment 112.

/be
Actually I ran with pref=1 and then tried pref=2, which I'm still using. I don't see benefits. I've gotten used to bugzilla.mozilla.org being restated in blue to the left of the bug URL, though. Silly, but you can get used to almost anything! I'm going to try 0 for a while.

/be
I'm running with pref set to 1, once getting used to, it's alarming when it's missing at secured sites. This might prevent the simplest of MITM attacks (by rewriting to regular http).
Sorry, forgot the bug was FIXED. Let's take discussion to the newsgroup.

/be
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: