Daniel Veditz [:dveditz] Assignee
	Description • 16 years ago

The positive indications of SSL are too subtle in the non-EV case, we need to change the default pref browser.identity.ssl_domain_display to the value "1".

This bug is not about improving SSL indication in general, that debate is carried on elsewhere (newsgroups, bug 430790). This is not even a bug to debate this change; that, too, has already taken place elsewhere. This bug is strictly a placeholder for the mechanical code change described in the summary, to be approved or not.

If people are worried about the redundancy of having SSL indicators also appear in the status bar they should file a separate bug to remove the status bar info. Burying the SSL indicator in the easily-missed status bar was already acknowledged as a problem when Firefox made the much-lauded change to add SSL indication to the url bar (adding the lock and yellow highlight). That was the right move, we should not regress. Whether or not we keep the status bar info for lock fetishists is separate from this bug about improving SSL discovery in the location-bar area where people are looking.

	Mike Connor [:mconnor]
	Comment 1 • 16 years ago

Comment on attachment 364344 [details] [diff] [review]
pref change

I think we should try this in a beta and see what the feedback is like.  It's pretty easy to revert/disable depending on the feedback, but we've been talking about this on and off and it seems worth trying in a major release.

	maix
	Comment 2 • 16 years ago

-1. The domain name is already contained in the url, so why should one waste more space for that?

	Eddy Nigg (StartCom)
	Comment 3 • 16 years ago

Consider this:

https://www.paypal.com.cgi-bin.webscr/?cmd=_login-run.some.tld/more?giberrish&and&more&strings&to&come

	maix
	Comment 4 • 16 years ago

Hm that's a problem. But I think if you want to be sure you can click on the icon. I think it would be ok as default if there was an option in the preferences where one can turn it off easily.

	Eddy Nigg (StartCom)
	Comment 5 • 16 years ago

Yes, browser.identity.ssl_domain_display = 0 would revert that. I'm browsing with the pref set to 1 for about a year now, it's extremely useful IMO. The eye gets trained to look for the positive indicator and domain in question.

	Daniel Veditz [:dveditz] Assignee
	Comment 6 • 16 years ago

Fixed:
http://hg.mozilla.org/mozilla-central/rev/98de82962026
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/aa384f615961

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 7 • 16 years ago

Verified fixed with builds on OS X and Windows:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090301 Minefield/3.2a1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090301 Shiretoko/3.1b3pre ID:20090301020400

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 8 • 16 years ago

Tracy, any existing (?) Litmus case should be updated to cover this change.

	Tracy Walker [:tracy]
	Comment 9 • 16 years ago

(In reply to comment #8)
> Tracy, any existing (?) Litmus case should be updated to cover this change.

RSS has never been one of my coverage areas.  It may be unowned. However, it looks like you're interested in the state of RSS test cases.  You have Litmus admin rights, hint hint.

	Robert Sayre
	Comment 10 • 16 years ago

(In reply to comment #10)
> (In reply to comment #8)
> > Tracy, any existing (?) Litmus case should be updated to cover this change.
> 
> RSS has never been one of my coverage areas. 

This patch is about SSL display.

	Tracy Walker [:tracy]
	Comment 11 • 16 years ago

wow! synapse collapse. :-)  I'll give the Litmus test cases a once over to make updates where needed.  sorry, and thanks.

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 12 • 16 years ago

Tracy, after reading comment 0 again I don't know if we should update the tests immediately or not. If we will go back to the older behavior we have to update the tests again.

	Marcia Knous [:marcia]
	Comment 13 • 16 years ago

I vote for updating the tests especially given the fact we will be running BFTs/FFTs and the people running the tests may not understand the behavior change if it is not referenced in some way. You can always add a notation to the existing tests and remove it if the behavior changes.

(In reply to comment #13)
> Tracy, after reading comment 0 again I don't know if we should update the tests
> immediately or not. If we will go back to the older behavior we have to update
> the tests again.

	Stephen Donner [:stephend] Not actively reading bugmail
	Comment 14 • 16 years ago

I have updated https://litmus.mozilla.org/show_test.cgi?id=6872 (included in both the BFT/FFT for 3.1/.x) to reflect that the domain appears for non EV-cert-issued sites.

There might be more testcases that need updating, though I searched for "Larry" and "blue" (since I wrote all the testcases for this), which I think is the only case in which we display the TLD+host.

	u279076
	Comment 15 • 16 years ago

Test case added.  Marking in-litmus+

https://litmus.mozilla.org/show_test.cgi?id=7728

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 16 • 16 years ago

(In reply to comment #16)
> Test case added.  Marking in-litmus+
> 
> https://litmus.mozilla.org/show_test.cgi?id=7728

Anthony, we should avoid to create litmus tests where users have to check/set hidden preferences. Please modify the test so it explains which UI has to be displayed.

But finally it should be an automated test. Can we please get one which checks for the domain name inside the DV button?

	u279076
	Comment 17 • 16 years ago

There is no UI for this.  It is a pref in about:config.  If we don't want testers checking in about:config, I vote for in-litmus-

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 18 • 16 years ago

As I said in my last comment we have an UI. Check for the domain name inside the blue DV button. Just in turn you are not familiar with this pref set it to 0 and check a bugzilla page afterward.

	u279076
	Comment 19 • 16 years ago

(In reply to comment #19)
> As I said in my last comment we have an UI. Check for the domain name inside
> the blue DV button. Just in turn you are not familiar with this pref set it to
> 0 and check a bugzilla page afterward.

We actually already have tests to verify that Larry behaves properly for SSL sites (blue).  Would this not suffice?

	u279076
	Comment 20 • 16 years ago

Test case 7728 disabled.

See https://litmus.mozilla.org/show_test.cgi?id=6872

	Henrik Skupin [:whimboo][⌚️UTC+2]
	Comment 21 • 16 years ago

(In reply to comment #21)
> See https://litmus.mozilla.org/show_test.cgi?id=6872

Yes, that one is already perfect. Please delete #7728.

	u279076
	Comment 22 • 16 years ago

Updated URL to reflect test case 6872.  Marking in-litmus+.

	Anquietas
	Comment 23 • 13 years ago

Hello, I have another ideea...

The blue zone must remain with a decent amount of width to be observed as a Secure Site.
That is for sure...

But both the "1" and "2" values repeat what is in the URL. 1 - domain , 2. - full domain
Practically, is the CN of the certificate.

Why can't we change that to the Organization Field (O) of the Certificate ?...
This way we will have a decent width of the blue zone and not a clone of the URL.... just as in the case of EV Certs where we have the Identity Name... 

I've been discussing this with many people and many of them agree and do not consider this a security problem.
Why should the non-ev certs be denied a decent Organization name on the blue zone of Larry  instead of just copying the URL ?...