Closed Bug 402650 Opened 17 years ago Closed 1 month ago

make secure location bar (https) background something other than yellow

Categories

(Camino Graveyard :: Location Bar & Autocomplete, enhancement)

Product:
Camino Graveyard
Component:
Location Bar & Autocomplete
Platform:
All
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: froodian, Unassigned)

Details

We've tossed this around a few times - filing to keep on the radar.

We should consider making the background color for the location bar something other than yellow at secure sites.

a secure site -> be confident
yellow -> be cautious
This is completely different from bug 286516.  That would kill consistency - this is a one-time change to make it better.  We shouldn't be stuck with something bad just because "we've always done it like that"
Yeah, I filed that bug primarily as an a11y issue for colour-blind people (and because that yellow can be really hard to see). I'm about 99% certain we decided to do this at the meet-up, so I'm gonna confirm it.

We just need to discuss what we'll change it to, and I don't think that we should necessarily do what Firefox does, either. If Firefox decides something sane, fine, but if they don't, I still think we need to change to something greenish or bluish.
Status: UNCONFIRMED → NEW
Ever confirmed: true
What does Safari on 10.5 do ? (on 10.4, they don't change the background-colour for https).

IE 7 uses green for fully secure, and yellow for partly secure (some resources not served over https). If I understood correctly, additionally they use some logic based on certificates.
Based on the tools I have to test colours for colour-blindness problems, that green works pretty well.

I'm not sure what Firefox is trying. Right now, they only managed to make a mess (imho).
I was thinking about this while finishing up the new location bar partition code. Firefox moved away from this, Safari still doesn't do this on 10.6, and Chrome doesn't do this.

The argument, and I think it's a good one, is that "secure" is actually a pretty crappy single bit of information, since secure != safe or non-malicious, so we shouldn't be trumpeting it so much.

Given that everyone else has decided this isn't a good idea, we should probably stop too.
Hardware: PowerPC → All
Putting on the 2.1 list to make sure we don't forget to consider it.
Target Milestone: --- → Camino2.1
I find it far more useful (and much easier to use) as an indicator of an encrypted connection than the lock icon, and I miss it all the time in other browsers.  It's the simplest (and largest, and most obvious) visual clue available that the page I'm on was served over SSL.

Yes, it doesn't tell me that bank.com is really owned by $bank and commercesite.com is really operated by $commercecompany (the EV nonsense would tell me that), or that the site is not serving malware to me or phishing my credentials (thankfully, we do have other services that do that for us), but it does tells me that if I trust bank.com and commercesite.com to be who they say they are, no one else is going to look at my account number or my credit card while I'm using the site.

(Our documentation on this stresses pretty strongly that this means encryption of traffic, not outright or complete safety.)
I know you know what it means, and I know what it means, but if we surveyed Camino users about what the yellow bar conceptually means to them, what percent would give the right answer? I bet the breakdown would be:
- majority: don't know
- majority of the rest: "safe"
- small minority: encrypted

My fear is that more users are being misled by its prominence than are being helped.
(In reply to comment #7)
> It's the simplest (and largest, and most obvious) visual clue
> available that the page I'm on was served over SSL.

Yeah, I *hate* Safari's nearly invisible icon in the corner of that giant mass of...whatever UI metaphor Apple is calling it these days. It's a quick and easy reference that I've got a good HTTPS connection.

In light of the other comments, I agree doing what IE does is probably a bad idea unless we're also going to add logic that makes the green depend on the presence of an EV certificate (and thus the site is truly "safe").

I'm not sure how the argument against this works, though. By making it harder for users to see indications that a site is using HTTPS, we're going to save them from assuming that the *other* indications of an HTTPS connection, which will continue to exist (and which people who know the difference will then have to expend extra effort finding), are a valid proxy for a "safe" site? Why don't we just do away with any obvious indicators of an HTTPS connection entirely and simply let the "https" protocol in the location bar be the only indication, then?

I'm not trying to be argumentative; I genuinely don't see how this is going to help, and I think it's a big loss for the people who know what it does mean.
> By making it harder for users to see indications that a site is using HTTPS,
> we're going to save them from assuming that the *other* indications of an
> HTTPS connection, which will continue to exist (and which people who
> know the difference will then have to expend extra effort finding), are a
> valid proxy for a "safe" site?

No, by not shoving a gigantic indicator of encryption at users, we stop sending the message that it means something wildly important--so important that it warrants using about 1/3 of the whole toolbar to communicate it.

> Why don't we just do away with any obvious indicators of an HTTPS connection entirely

Because it's still useful information. Let's not pretend that black and white are the only options.

Also, because we need to provide a place for people to click to learn more.

(In reply to comment #7)
> but it does tells me that if I trust bank.com and commercesite.com to be who
> they say they are, no one else is going to look at my account number

Right--it's useful information *in conjunction with checking the domain name*, which is something most users don't know how to do accurately, and which we do *nothing* to help with. Of the two equally important pieces of information, we make absolutely no effort to highlight one, and we shout the other at the top of our lungs. That sends the wrong message to users.
(In reply to comment #7)
> I find it far more useful (and much easier to use) as an indicator of an
> encrypted connection than the lock icon, and I miss it all the time in other
> browsers.  It's the simplest (and largest, and most obvious) visual clue
> available that the page I'm on was served over SSL.

It is a much easier to see visual clue, sure. The tiny icon in Safari's implementation is way too easy to miss, Camino's small icon isn't highly visible either (having it in a separate partition makes it more easy to notice in a quick scanning). But at the same time it feels a bit like shouting, while at the same time masking the really important information as Stuart points out in the last paragraph of comment 10.

I'm personally not at all opposed to remove the yellow background. If at the same time there is a quick and easy way to highlight the domain name…

while double checking what other browsers do:  Opera 11's implementation is quite attractive & visible without being heavy-handed and Google Chrome's implementation (lock icon on the left, where I think the average user starts scanning for info) is also reasonably effective while remaining minimal.
Lock on the left has advantages, but also opens a can of worms related to consistency of favicons in Camino, drag affordances, etc. That should be discussed in a different bug.
I like Firefox's implementation (both 3.6 and 4.0). For HTTPS connections, Firefox displays a dark blue box highlighting the authenticated site's domain name (e.g. "google.com") to the left of (and separate from) the Location Bar. I think this design is good for user education, because Firefox's UI reinforces the site's identify without pretending "SSL means Totally Secure". Firefox does not even display an SSL lock icon!

Compare these flavors of HTTPS pages:
* Fully encrypted: https://encrypted.google.com/
* Partially encrypted: https://news.google.com/
* Not encrypted: http://www.google.com/
Also consider that Camino has a long precedent (since at least 1.0 AFAIK) of displaying a yellow location bar for HTTPS connections. Will long-time Camino users become confused/concerned if (suddenly and inexplicably) their bank's website no longer has a yellow location bar?
If we accept (at least for the sake of argument, but I think there was some consensus in the previous comments on this) that there are three elements to "security" of a website, encryption, identity, and non-maliciousness, I think we shout at the top of our lungs (or nearly so) in all three cases right now.

1) For encryption (SSL), obviously it's the yellow bar (and the lock, which is a whisper).  In some ways the yellow location bar is less prominent than than the indicators for the other elements.

2) For identity, we currently have prominent, browsing-stopping UI on SSL certificate mismatches, self-signed certs, and other certificate-related errors (we had UI for this before, but it was more confusing and easier to ignore).  EV would add a bit of additional "volume" (Sam and I started brainstorming EV UI ages ago: http://wiki.caminobrowser.org/User:Sardisson/EV) to the shouting here, certainly.

3) For non-maliciousness, we currently have prominent, browsing-stopping UI for sites known to be or suspected of being malicious (phishing and malware).  There's always a chance that there's a malicious site out there that's not caught (so we're not so much shouting "safe" here on good sites as shouting "unsafe" on bad ones), but that's no different than anyone else.

So I think it's wrong to say that we're emphasizing (shouting at the top of our lungs) one element of "security" and ignoring the others.  There's certainly a bit more we could do to emphasize identity (hook up EV with all that Gecko fun), but otherwise I think we're treating the various elements roughly equally.

(In reply to comment #14)
> Also consider that Camino has a long precedent (since at least 1.0 AFAIK) of
> displaying a yellow location bar for HTTPS connections. Will long-time Camino
> users become confused/concerned if (suddenly and inexplicably) their bank's
> website no longer has a yellow location bar?

Since 0.8.3 (and since November 2004 on the trunk).

I think if we're not going to do any EV-related changes for 2.1, we should continue to leave the location bar color alone.  If we have some sort of new model with equivalent visibility we can transition users to looking for, it's less problematic to make a disruptive change like this, because we can message "instead of looking for prominent item foo, now look for prominent item bar".  But if we don't have that new model, it's hard to effectively message "the (prominent) thing you used to rely upon is gone, so now look for "hidden" item baz" and it otherwise feels like "we believe our current solution is not comprehensive enough, so we're going to get rid of it entirely and leave you on your own, rather than keeping what we have until we have something even better to replace it."

Without (hopefully) getting into discussions of the specifics of everyone's implementations, a couple of brief comments on cpeterso's comments on Firefox:

(In reply to comment #13)
> Firefox displays a dark blue box highlighting the authenticated site's domain
> name (e.g. "google.com") to the left of (and separate from) the Location Bar. 

This is certainly better than just a lock, but 1) it's still not as prominent (easy to see) as the entire colored bar, IMO, and 2) it is, in fact, part of (enclosed by) the location bar (and the typeable part of the bar jumps around depending on the site).

> Firefox does not even display an SSL lock icon!

FWIW, some senior Gecko security developers, such as dveditz, were opposed to (and upset by) this move.
> For identity, we currently have prominent, browsing-stopping UI on SSL
> certificate mismatches, self-signed certs, and other certificate-related errors

Agreed, but this isn't "identity" in a broad sense, just protection against a specific kind of impersonation. It does nothing to address the last paragraph of comment 10, which is where I see the really problematic imbalance.

EV is an attempt to address what I'm talking about--as are some of the url highlighting schemes, although I don't know if those are at all effective. We do neither.

Your point about safe browsing is a good one though; I hadn't been considering that. If one assumes that safe browsing is doing a reasonably good job, I agree that the imbalance is much less severe than I was making it out to be (since that leaves the http/https distinction primarily useful for anti-eavesdropping, which is fine).

So given that let's push out until we look at EV at least as you suggest.
Target Milestone: Camino2.1 → ---
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.