Closed Bug 480357 Opened 14 years ago Closed 14 years ago

Change browser.identity.ssl_domain_display pref default to 1

Categories

(Firefox :: Security, enhancement)

enhancement
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: dveditz, Assigned: dveditz)

References

(Depends on 1 open bug, )

Details

(Keywords: user-doc-needed, verified1.9.1)

Attachments

(1 file)

Attached patch pref changeSplinter Review
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.
Attachment #364344 - Flags: ui-review?(johnath)
Attachment #364344 - Flags: review?(mconnor)
Attachment #364344 - Flags: approval1.9.1?
Flags: wanted1.9.0.x+
Flags: wanted-firefox3.1?
Attachment #364344 - Flags: ui-review?(johnath)
Attachment #364344 - Flags: ui-review+
Attachment #364344 - Flags: review?(mconnor)
Attachment #364344 - Flags: review+
Attachment #364344 - Flags: approval1.9.1?
Attachment #364344 - Flags: approval1.9.1+
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.
-1. The domain name is already contained in the url, so why should one waste more space for that?
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.
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.
Fixed:
http://hg.mozilla.org/mozilla-central/rev/98de82962026
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/aa384f615961
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Attachment #364344 - Flags: approval1.9.0.8?
Attachment #364344 - Flags: approval1.9.0.8?
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
Status: RESOLVED → VERIFIED
Flags: wanted-firefox3.1?
Target Milestone: --- → Firefox 3.2a1
Tracy, any existing (?) Litmus case should be updated to cover this change.
Flags: in-litmus?
Depends on: 480903
(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.
(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.
wow! synapse collapse. :-)  I'll give the Litmus test cases a once over to make updates where needed.  sorry, and thanks.
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.
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.
Depends on: 481248
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.
Depends on: 481560
Depends on: 481571
No longer depends on: 481560
Depends on: 471802
Depends on: 483178
Blocks: 430790
Test case added.  Marking in-litmus+

https://litmus.mozilla.org/show_test.cgi?id=7728
Flags: in-litmus? → in-litmus+
(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?
Flags: in-testsuite?
Flags: in-litmus?
Flags: in-litmus+
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-
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.
(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?
Test case 7728 disabled.

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

Yes, that one is already perfect. Please delete #7728.
Updated URL to reflect test case 6872.  Marking in-litmus+.
Flags: in-testsuite?
Flags: in-testsuite+
Flags: in-litmus?
Flags: in-litmus+
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 ?...
You need to log in before you can comment on or make changes to this bug.