How to supply "web site identity information" - as

[wgianopoulos]

I agree. The wording is really confusing, misleading and inaccurate. A more correct wording would be. "The identity of this website has not been verified by a trusted source".

[Bluefang]

Personally, I think that 'this website doesn't supply identity information' is 100% correct... because it doesn't! However, I do agree that something along the lines of 'This website is not secure' would be more user friendly.

[BvdB]

"This is a http website and thus it is not secure."

[teoli2003]

Http is already too technical for most user.

[BvdB]

Hmm, so then how about:
"Life is not secure, neither is this website."

[teoli2003]

I prefer: "This site does not supply identity information. The connection to this website is not encrypted." Complete, correct without technical speaking.

With a DV certificate, we can precise that the site is guaranteed to be on that domain, and the connection is encrypted.
With an EV certificate, we can give the company name, and the connection is encrypted.

Complete and coherent.

[BvdB]

"The connection to this website is not encrypted. So this site does not supply identity information."

Otherwise it could be (mis-) understood that the site has _two_ deficiencies.

[teoli2003]

So what you are asking is that the current sentences are switched?

[vodhner]

Trying to see this from a non-technical point of view, I'd say the message should state the issue in terms that most users might actually care about. Security for most people is just an annoying obstacle to productivity. To get the user's attention you have to indicate why they should care. So I'd suggest something like "Warning: Do not supply private information on this web site; the site is not certified so its identity can not be confirmed."

I should also point out that I got into this conversation due to attempts to drag the URL onto the links line; I would never have thought to click on the favicon to check identity, so I suspect many users would never see the message. Really, when users should see a message is the first time they put the cursor into a text box on a form. But I gather that W3C has some sort of standard prescribing the alert we're discussing.

[BvdB]

To restate the point I made in the beginning:
I don't see why the browser should irritate the user in this way at all.

There are better times and better places to teach him security.

[teoli2003]

Anyway, we can continue to argue one way or the other here. But this conversation will lead nowhere: there is no dev reading this, there is no consensus, and won't be one...

If you think of a better wording, just make an entry in bugzilla.

[BvdB]

The idea to say something about security at this place is wrong in the first place.
There is no developer reading this? Really? Good to know after 6 months and > 40 posts ...

So then, on to bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=465584

[Johnath]

BvdB,

Several people on this board know where to find me when they need to, but I suspect many of them realize that this is not a new conversation, nor does it have the characteristics of a productive one. I see some attempts at reaching consensus and some brainstorming, but mostly I see entrenching, and repeating of the same arguments by assertion.

I hope you won't think it is drastically misrepresenting the stance you're advocating to summarize it as:

1. http sites can't provide identity information, and hence Firefox shouldn't require them to.
2. Warning users away from sites that don't supply identity information is misleading.
3. (Maybe, not clear on this one) It doesn't matter for most sites whether identity information has been supplied or not, so again, Firefox shouldn't be aggressively scaring people away from them.

Do I have that basically right? Because if so, they're all non-sequiturs.

1. We don't require sites to do anything - run an http site, fine by us. We love http sites! But when a user asks Firefox, using parts of our User Interface devoted to identity information, about an http site, we will absolutely continue to tell them that the site doesn't supply that information. Not that we couldn't verify it, there was simply nothing to supplied for us to verify. Nothing about DNS or web page content on an http connection is identity information we can rely on, they are trivially subvertible.

2. No one is warning anyone - this is an on-demand request that explicitly does not include language warning users or suggesting they are unsafe. We don't use language about "security" or "safety" in this UI precisely because those topics are so loaded and prone to misinterpretation. We have looped back multiple times here to make sure that the language restricted itself to the information we were directly concerned with: is the owner of the site something we can know (to detect active attack), and is the connection encrypted to prevent eavesdropping (passive attack). So I hope you can understand that polemic mud-slinging like this:

If there was a thorough discussion on this and what we see is the result - then the discussion could not have been based on logic reasoning.

Suggests very strongly that you aren't interested in reaching a mutually acceptable outcome, but instead are looking to set yourself above the others who have worked on these features, and diminish the work they have done. That in turn, I hope you'll understand, leads to me not feeling particularly compelled to engage you in discourse, since it seems there will be little benefit for me or the project to doing so.

3. Whether or not it matters to our users that sites identify themselves in a verifiable way is a decision we let them make, using a user interface they have to interact with, in order to garner information in any event. We aren't trying to scare, we are trying to inform. Not because we are trying to teach our users how PKI works, but because we are trying to give them some richer tools for understanding their connections with other websites than a little all-or-nothing padlock that they're just supposed to intuit correct meanings out of.

There seems to be some kind of underlying premise here that an http site is an immovable object; that a site can't transition between the two. There are certainly good performance reasons for keeping sites that don't need https on http, but those sites oughtn't have any particular need for identity information either. Paypal is one of the busiest sites in the world, and it succeeds fine in an all https infrastructure, as does addons.mozilla.org, another site with massive levels of traffic. Those sites pay money for that ability, but for small sites, the cost of offering https is very low.

If your site doesn't need to supply identity information, don't supply it. If it does, do. I am certainly open to thoughtful adjustments to the wording, but whether we change it over time or not, we're going to keep telling users about the information sites are or are not choosing to supply, when we think it can help them situate themselves better on the web.

There is no developer reading this? Really? Good to know after 6 months and > 40 posts ...

Do you see what I mean when I say that your attitude does not sound like you are interested in understanding the current state of affairs or making meaningful contributions to its improvement? These snide comments diminish your arguments and make me really reluctant to involve myself in the conversation at all. There are other people in this thread who are trying more earnestly to make progress, though, and I don't want them to feel left out in the cold. We're an open source project built by a community, anyone genuinely trying to help is very welcome.

But I have very little time for us to sit here throwing feces at one another.

[BvdB]

Johnathan, thanks for your comments about my attitude, but forgive me - I'm not asking for your daughter's hand, neither your cousin's hand.
Instead, believe me, I'm honestly trying to improve a software that I consider important; so do you.

You have set the bug-status on bugzilla to "RESOLVED" "WONTFIX".
Anyhow, some future generation of UI designers might read this and get .. inspired.
So, allow me to continue the argumentation:

1. Hovering over one part of an UI is not a gesture I'd consider as "asking".
Asking would imply, at least, a click. But maybe I misunderstood Alan Kay.

2. So whatever happens then is not happening "on demand".

3. "we are trying to give them some richer tools for understanding their connections" - fine, produce a button "Click here to get more information about this connection".
So if the user clicks, that's "invoking a tool". And then he'd be willing to read more than one short line, so there'd be more room for explanation about possible and missing information.

Conclusion: What happens on the click is perfectly ok, the line that appears on the hovering is superfluous and possibly misleading.

[BvdB]

Folks, everyone who is interested in this issue please subscribe the bugzilla thread.
https://bugzilla.mozilla.org/show_bug.cgi?id=465584

Two new IMHO interesting arguments have appeared there:
- No other browser follows the policy of Mozilla of warning about missing identity
- Even with a valid SSL cert the warning appears - one has to buy an expensive EV (extended validation, from 500$ p.a.) cert to avoid it.

Maybe we can build up some momentum to change the status from VERIFIED WONTFIX to something else ...