456790 - Improve secure URL Bar visual style possibilities by adding an attribute to the EV Toplevel state

Status: NEW

(Firefox :: General, enhancement)

Description

[Pardal Freudenthal (:ShareBird)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3pre) Gecko/2008091306 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3pre) Gecko/2008091306 Firefox/3.0.3

Firefox 2.0 had a yellow background to indicate users were at a secure URL. Firefox 3.0 removed it. Users still expecting changes on the autocomplete-textbox-container background when they are at a secure URL and indeed the other browsers use this kind of indication.

This bug is dependent from  Bug 456761 since  Bug 448939 has removed the "level" attribute.

I've already wrote an extension which does what I'm proposing here: http://www.silvermel.net/dev/colorsecureurl_0.0.1a2pre.xpi but I don't think an extension should be needed.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Pardal Freudenthal (:ShareBird)]

Attachment: Pic showing how it can look.

Comment 2

[Pardal Freudenthal (:ShareBird)]

I'm not building Firefox, so I can't write an applicable patch. I've modified at my workbench and tested. The patch could look like 

Index: chrome/content/browser/browser.js
===================================================================
--- chrome/content/browser/browser.js	(revision 43)
+++ chrome/content/browser/browser.js	(working copy)
@@ -3778,8 +3778,10 @@
                               wpl.STATE_IS_INSECURE |
                               wpl.STATE_SECURE_HIGH |
                               wpl.STATE_SECURE_MED |
-                              wpl.STATE_SECURE_LOW;
+                              wpl.STATE_SECURE_LOW |
+															wpl.STATE_IDENTITY_EV_TOPLEVEL;
     var level;
+		var toplevel = false;
     var setHost = false;
 
     switch (this._state & wpl_security_bits) {
@@ -3792,6 +3794,10 @@
         level = "low";
         setHost = true;
         break;
+			case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_HIGH | wpl.STATE_IDENTITY_EV_TOPLEVEL:
+				level = "high";
+				toplevel = true;
+				break;
       case wpl.STATE_IS_BROKEN:
         level = "broken";
         break;
@@ -3800,11 +3806,24 @@
     if (level) {
       this.securityButton.setAttribute("level", level);
       this.securityButton.hidden = false;
+			if (gURLBar)
+        gURLBar.setAttribute("level", level);  
     } else {
       this.securityButton.hidden = true;
       this.securityButton.removeAttribute("level");
+			if (gURLBar)
+        gURLBar.removeAttribute("level");
     }
+		
+		if (toplevel) { 
+      if (gURLBar)
+        gURLBar.setAttribute("toplevel", toplevel);
+    } else {
+      if (gURLBar)
+        gURLBar.removeAttribute("toplevel");
+    }
 
+
     if (setHost && this._host)
       this.securityButton.setAttribute("label", this._host);
     else
Index: chrome/skin/classic/browser/browser.css
===================================================================
--- chrome/skin/classic/browser/browser.css	(revision 43)
+++ chrome/skin/classic/browser/browser.css	(working copy)
@@ -1137,6 +1137,20 @@
   direction: ltr !important;
 }
 
+/*secure URL status colors*/
+#urlbar[level="high"] > .autocomplete-textbox-container,
+#urlbar[level="low"] > .autocomplete-textbox-container,
+#urlbar[level="high"] > .autocomplete-history-dropmarker,
+#urlbar[level="low"] > .autocomplete-history-dropmarker {
+  background-color:  #cde8f5;
+  color: #000000;
+}
+#urlbar[level="high"][toplevel] > .autocomplete-textbox-container,
+#urlbar[level="high"][toplevel] > .autocomplete-history-dropmarker {
+	background-color: #D0F2C4;
+}
+
+
 /* ::::: page proxy icon ::::: */
 
 #page-proxy-favicon,

Comment 3

[Dave Garrett]

Encrypted/secure does not mean safe. You can encrypt a connection to a scam site. Things were changed because most users just looked at the address bar and saw a lock and yellow and assumed all was good, when in reality it doesn't mean that much.  Firefox 3 fixed some old bad GUI choices, and the fact that users were used to the old system is not reason enough to undo them.

There is a background change for the favicon and a domain w/ lock in the status bar. Users should learn to expect this instead. Now, your suggestion to use blue (via screenshot) instead of yellow (i.e. continue favicon shading to address) sounds like a good accessibility idea, seeing as it's not always that noticeable with just the little background change. If you hadn't posted the pic I was going to dupe to bug 439951. I feel like this request is already in here somewhere else, though.

Also note that I tried your extension out in a new profile (3.0.2 on Linux) and got zero effect. It doesn't work for some reason.

Comment 4

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #3)

> Also note that I tried your extension out in a new profile (3.0.2 on Linux) and
> got zero effect. It doesn't work for some reason.

I guess it doesn't work because this function I have in the extension:
	applyStyle: function() {
		//only apply styles for the default theme
		if (colorSecure.getThemeName() == "classic/1.0") {
			colorSecure.addCSS("chrome://colorsecureurl/skin/colorSecureURL.css")
		}
		window.removeEventListener("load", function() {colorSecure.applyStyle()}, false);
	},

I wanted that the style would only apply for the default theme (I don't know, but I think the default theme for Linux is not called "classic/1.0", so I would need to include both other themes...)

Anyway, the "level" and "toplevel" attribute should be there. That's the most important, because this will able the possibilities shown on the pic.

Comment 5

[Dave Garrett]

Even if your extension only works on WinXP, the implementation of this suggestion itself would need to be cross-platform in some way.  ->  All-All, enhancement

Comment 6

[Johnathan Nightingale [:johnath]]

Hi Pardal, 

I appreciate you filing the bug and putting together the extension to illustrate your point.  As Dave mentions, part of the reason we moved away from highlighting the whole location bar (besides the unfortunate situation where yellow meant SSL for us, and meant "warning" for IE) was that URLs are not particularly trustworthy things.  Drawing extra attention to the url field when it says something confusing like:

https://www.news.com/?id={96ce3103-0311-4094-986c-1d0b3d5ca313}

doesn't really help users, and while most users don't look at URLs anyhow (since they're so often impenetrable) it certainly wouldn't help to draw extra attention to a URL like:

https://evil.com/paypal/paypal/paypal

and suggest that that URL had been "verified".

Instead, we moved to the identity button on the left, which speaks only about the identity of the site, as humanely as we can, and not about the URL in general.  I think what you're keying off is that, particularly in the case of DV SSL, the blue icon is difficult to notice.  I agree.  I think we should revisit the question raised in bug 414627 around making that UI more discoverable, or find other ways to draw attention to the parts of the site's identity that we *want* to emphasize.  But I don't think we should draw extra attention to the entire URL like other browsers are doing, I don't think it helps our users understand who they're dealing with.

Do you disagree, Pardal?

Comment 7

[Pardal Freudenthal (:ShareBird)]

Hi Johnathan, no I don't disagree at all. I also agree we do have a problem with the blue icon for DV SSL. One solution for this could be turning browser.identity.ssl_domain_display to 1 or 2 by default, but this could minimize the indication for "verified" domains and makes more confusion. I also agree with you about the issues concerning the old yellow background, but the changes I propose on the screenshot could solve the problem with the blue icon and could give a bit support to the "Larry" button.

Comment 8

[Pardal Freudenthal (:ShareBird)]

Jonathan, 

now that Bug 456761 is going to be fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=456761#c7 

What do you think about adding a "toplevel" attribute as at https://bugzilla.mozilla.org/show_bug.cgi?id=456790#c2 ? This would open more possibilities for users (through userChrome.css or Stylish) and third-party themes to style the levels.

Comment 9

[Przemyslaw Bialik]

(In reply to comment #2)
> I'm not building Firefox, so I can't write an applicable patch. I've modified
> at my workbench and tested. The patch could look like 
the changes you proposed only require to repackage Firefox and so recompilation is not needed
you just need to apply the same changes to the "real" source files and attach the diffs
https://developer.mozilla.org/En/Creating_a_patch (follow the Mercurial route)

if you would have questions feel free to e-mail me

Comment 10

[Pardal Freudenthal (:ShareBird)]

Attachment: patch

This patch doesn't modify the UI as showed on 340152. It just adds the attribute "toplevel" for being used from users customizations or third party themes.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 349059 [details] [diff] [review]
patch

I considered asking you to consolidate this code with the similar code in gIdentityHandler.checkIdentity, but that's probably more trouble than it's worth at the moment (especially if you want this on 1.9.1).

>diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js

>     switch (this._state & wpl_security_bits) {
>       case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_HIGH:
>         level = "high";
>         setHost = true;
>         break;
>       case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_MED:
>       case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_LOW:
>         level = "low";
>         setHost = true;
>         break;
>+        case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_HIGH | wpl.STATE_IDENTITY_EV_TOPLEVEL:
>+        level = "high";
>+        toplevel = true;

You're not setting setHost here, so this regresses the host display in the status bar for EV sites. This should just be put above the SECURE_HIGH case, and you can fall through it to set level and setHost after setting toplevel (and add a comment indicating the falling through is intentional).

(Indentation of the case statement is a bit off too.)

>+    if (toplevel) { 
>+      if (gURLBar)
>+        gURLBar.setAttribute("toplevel", toplevel);
>+    } else {
>+      if (gURLBar)
>+        gURLBar.removeAttribute("toplevel");

I'd put the gURLBar check outside to avoid duplicating it.

I'm a bit conflicted about the attribute, though. It seems like "toplevel" should just be another possible value for the "level" attribute (hopefully we won't ever have to add another level!), but that potentially has an impact on existing extensions/themes that depend on its value being "high" for both EV and normal DV certs (and would require changes to our themes as well). I guess the new attribute is the way to go, but I'm a little bit sad that we're going to be stuck with supporting these two different attributes forever.

Comment 12

[Dão Gottwald [:dao]]

We could stick with "high" and "low" and make all of non-EV "low", right?

Comment 13

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #12)
> We could stick with "high" and "low" and make all of non-EV "low", right?

But this would remove the ability to distinguish between SECURE_HIGH and EV_TOPLEVEL, as showed on https://bugzilla.mozilla.org/attachment.cgi?id=340152

Comment 14

[Pardal Freudenthal (:ShareBird)]

Attachment: patch v1.1

Made the suggested modifications. Thanks.

Comment 15

[Dão Gottwald [:dao]]

(In reply to comment #13)
> (In reply to comment #12)
> > We could stick with "high" and "low" and make all of non-EV "low", right?
> 
> But this would remove the ability to distinguish between SECURE_HIGH and
> EV_TOPLEVEL, as showed on https://bugzilla.mozilla.org/attachment.cgi?id=340152

No, SECURE_LOW/MED/HIGH would be "low", IDENTITY_EV_TOPLEVEL would be "high".

Comment 16

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #15)
> No, SECURE_LOW/MED/HIGH would be "low", IDENTITY_EV_TOPLEVEL would be "high".

Sorry, actually I mean the ability to distinguish between SECURE_LOW/MED, SECURE_HIGH and EV_TOPLEVEL, what I'm proposing.

Comment 17

[Dão Gottwald [:dao]]

(In reply to comment #16)
> (In reply to comment #15)
> > No, SECURE_LOW/MED/HIGH would be "low", IDENTITY_EV_TOPLEVEL would be "high".
> 
> Sorry, actually I mean the ability to distinguish between SECURE_LOW/MED,
> SECURE_HIGH and EV_TOPLEVEL, what I'm proposing.

Right. We used [level="high"] and [level="low"] synonymously for the location bar and still do it in the status bar. Effectively, there is/was no distinction between SECURE_LOW/MED and SECURE_HIGH.

Alternatively, we could drop SECURE_LOW/MED altogether, similar to gIdentityHandler.

Comment 18

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #17)

> We used [level="high"] and [level="low"] synonymously for the location
> bar and still do it in the status bar. Effectively, there is/was no distinction
> between SECURE_LOW/MED and SECURE_HIGH.
> 
> Alternatively, we could drop SECURE_LOW/MED altogether, similar to
> gIdentityHandler.

You're right. We could use just one level="low" for the three cases SECURE_LOW/MED/HIGH and level="high" for the IDENTITY_EV_TOPLEVEL, but this would maybe impact themes and extensions as pointed on comment #11. But extensions and themes have to make changes anyway for 3.1... So, should I go in this way?

Comment 19

[Dão Gottwald [:dao]]

(In reply to comment #18)
> (In reply to comment #17)
> 
> > We used [level="high"] and [level="low"] synonymously for the location
> > bar and still do it in the status bar. Effectively, there is/was no distinction
> > between SECURE_LOW/MED and SECURE_HIGH.
> > 
> > Alternatively, we could drop SECURE_LOW/MED altogether, similar to
> > gIdentityHandler.
> 
> You're right. We could use just one level="low" for the three cases
> SECURE_LOW/MED/HIGH and level="high" for the IDENTITY_EV_TOPLEVEL, but this
> would maybe impact themes and extensions as pointed on comment #11.

Comment 11 refers to a new value rather than adjusting low/high, so I don't see that problem in this case.

Comment 20

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #19)
> 
> Comment 11 refers to a new value rather than adjusting low/high, so I don't see
> that problem in this case.

I guess themers using this attribute are using both for the same rule (like [level="high"], [level="low"] {}). I also don't think we'll have a problem on this. So, attaching a new patch.

Comment 21

[Pardal Freudenthal (:ShareBird)]

Attachment: patch v1.2

patch adjusting low/high values

Comment 22

[Pardal Freudenthal (:ShareBird)]

Attachment: patch v1.3

removed empty line

Comment 23

[Pardal Freudenthal (:ShareBird)]

I'm unsure if we should change the meanings from the level attribute in this way and I also don't really know how extensions and themes are handling these values at all, so I'm thinking the "no risk" way is going with a new attribute (toplevel) as proposed before.

Just to remember: actually the "level" and "toplevel" attributes are only necessary because of Bug 436170 - CSS:Adjacent sibling selectors don't work on elements added via bindings.

I could file a new bug depending on Bug 436170 to remove these attributes after that bug get fixed.

Comment 24

[Pardal Freudenthal (:ShareBird)]

Attachment: patch v1.4

patch with "toplevel" attribute

Comment 25

[Dão Gottwald [:dao]]

Comment on attachment 353916 [details] [diff] [review]
patch v1.4

toplevel is confusing, as there's already a level attribute.

Comment 26

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #25)
> (From update of attachment 353916 [details] [diff] [review])
> toplevel is confusing, as there's already a level attribute.
Some suggestion? "topIdentity" maybe?

Comment 27

[Dão Gottwald [:dao]]

Attachment 352097 [details] [diff] is fine from my perspective. An open question is whether SECURE_LOW/MED should still get the "low" level or be dropped (see gIdentityHandler).

Comment 28

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #27)
> Attachment 352097 [details] [diff] is fine from my perspective. An open question is whether
> SECURE_LOW/MED should still get the "low" level or be dropped (see
> gIdentityHandler).
I guess it can be dropped. The SECURE_HIGH will be then "low" (sic). I'm just trying to figure out how this change will impact third party addons... Themes using backgrounds for the url according these states use AFAIK the same style for both (see comment #20), but I don't know how extensions handle this.

Comment 29

[Dão Gottwald [:dao]]

I doubt that a significant number of extensions handle this at all, but in any case we're only raising the bar in a fairly backward compatible way. Most of what an extension could realistically do for SECURE_HIGH (based on level="high") should still work for SECURE_HIGH with EV, and most of what an extension could do for SECURE_LOW should still work for SECURE_HIGH sans EV. The likeliest outcome seems to be that we'd update some extensions to be consistent with the rest of the UI for free, which is good.

Comment 30

[Pardal Freudenthal (:ShareBird)]

OK. I'll work on another patch dropping those states.

Comment 31

[Pardal Freudenthal (:ShareBird)]

Attachment: patch v1.5

patch without SECURE_LOW/MED getting the "level" attribute

Comment 32

[Dão Gottwald [:dao]]

Comment on attachment 387125 [details] [diff] [review]
patch v1.5

>     const wpl_security_bits = wpl.STATE_IS_SECURE |
>                               wpl.STATE_IS_BROKEN |
>                               wpl.STATE_IS_INSECURE |
>                               wpl.STATE_SECURE_HIGH |
>                               wpl.STATE_SECURE_MED |
>-                              wpl.STATE_SECURE_LOW;
>+                              wpl.STATE_SECURE_LOW |
>+                              wpl.STATE_IDENTITY_EV_TOPLEVEL;

MED and LOW can be removed now.

>     switch (this._state & wpl_security_bits) {
>-      case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_HIGH:
>+      case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_HIGH
>+                               | wpl.STATE_IDENTITY_EV_TOPLEVEL:

nit: The indentation is slightly strange, I'd suggest this:

>      case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_HIGH |
>           wpl.STATE_IDENTITY_EV_TOPLEVEL:

Or this:

>      case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_HIGH
>             | wpl.STATE_IDENTITY_EV_TOPLEVEL:

Comment 33

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #32)
> (From update of attachment 387125 [details] [diff] [review])
> >     const wpl_security_bits = wpl.STATE_IS_SECURE |
> >                               wpl.STATE_IS_BROKEN |
> >                               wpl.STATE_IS_INSECURE |
> >                               wpl.STATE_SECURE_HIGH |
> >                               wpl.STATE_SECURE_MED |
> >-                              wpl.STATE_SECURE_LOW;
> >+                              wpl.STATE_SECURE_LOW |
> >+                              wpl.STATE_IDENTITY_EV_TOPLEVEL;
> 
> MED and LOW can be removed now.

I thought to drop them also here, but what about the INSECURE state? It's also not being used... That's why I choose to maintain. Should I remove it too? Or let all of them listed to remember they exist at all?


> nit: The indentation is slightly strange, I'd suggest this:
> 
> >      case wpl.STATE_IS_SECURE | wpl.STATE_SECURE_HIGH |
> >           wpl.STATE_IDENTITY_EV_TOPLEVEL:
> 

I'll do in this way.

Comment 34

[Dão Gottwald [:dao]]

You can remove INSECURE as well. There's an interface for remembering that they exist ;)

Comment 35

[Pardal Freudenthal (:ShareBird)]

Attachment: patch v1.6

dropped unused states

Comment 36

[Dão Gottwald [:dao]]

The patch doesn't apply anymore on latest trunk.

Comment 37

[Pardal Freudenthal (:ShareBird)]

Attachment: patch v1.7

new patch

Comment 38

[Dão Gottwald [:dao]]

Comment on attachment 388159 [details] [diff] [review]
patch v1.7

Pardal, nobody looks at blank review requests...

Comment 39

[:Gavin Sharp [email: [e-mail]]]

Johnathan and I discussed this a few days ago, but I forget exactly what we concluded :(

I don't really like the idea of changing the meaning of "low" - it used to not actually occur very much in practice, so given the following options:

1) ignoring it
2) use it to present different styling that gives the user the impression of an less common/"safe" connection
3) treat it the same as level="high" (like we do)

for theme authors, 1) or 3) are probably most likely. This patch would have no effect on 1), would negatively affect 2), and would be slightly beneficial to 3) (themes wouldn't need updating to show styling in the EV case).

I'm not convinced the benefit to case 3) would outweigh the potential cost of 2) combined with the fact that it's kind of confusing to change semantics this way.

I think the counter proposal we settled on was adding level="ev" for TOPLEVEL, and leaving the others as-is. Is there a downside to that that I'm missing?

Comment 40

[Dão Gottwald [:dao]]

(In reply to comment #39)
> 2) use it to present different styling that gives the user the impression of an
> less common/"safe" connection

I'm not sure what "less common connection" could mean with regards to styling. "Safe connection" would still apply with the current patch.

> I think the counter proposal we settled on was adding level="ev" for TOPLEVEL,
> and leaving the others as-is. Is there a downside to that that I'm missing?

It's not backward compatible, and it leaves us with three states, while we use two elsewhere (identity handler).

Comment 41

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #40)
> I'm not sure what "less common connection" could mean with regards to styling.
> "Safe connection" would still apply with the current patch.

I meant "less common"/"less safe". Either would be misleading for HIGH.

> It's not backward compatible, and it leaves us with three states, while we use
> two elsewhere (identity handler).

What do you mean by "backwards compatible"?

gIdentityHandler also have three states (nothing, HIGH, TOPLEVEL/EV).

Comment 42

[Dão Gottwald [:dao]]

(In reply to comment #41)
> > I'm not sure what "less common connection" could mean with regards to styling.
> > "Safe connection" would still apply with the current patch.
> 
> I meant "less common"/"less safe". Either would be misleading for HIGH.

I don't think it would be more misleading than the identity handler's distinction between HIGH and EV and the styling this implies in the default theme. But I also don't think that themes have actually made such a distinction between level="low" and "high". I'm still unsure which styling "less common" could imply, other none at all or the same as for the more common connection.

> > It's not backward compatible, and it leaves us with three states, while we use
> > two elsewhere (identity handler).
> 
> What do you mean by "backwards compatible"?

I mean that if a theme uses level="high" to style the location bar, that styling would be lacking with level="ev", making the connection look unencrypted.

> gIdentityHandler also have three states (nothing, HIGH, TOPLEVEL/EV).

In that case level="ev" would be the fourth state here, because "nothing" exists as well.

Comment 43

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #42)
> (In reply to comment #41)

> > > It's not backward compatible, and it leaves us with three states, while we use
> > > two elsewhere (identity handler).
> > 
> > What do you mean by "backwards compatible"?
> 
> I mean that if a theme uses level="high" to style the location bar, that
> styling would be lacking with level="ev", making the connection look
> unencrypted.

I don't think so. Everything is still the same since the most top level will have both "level" *and* "toplevel" attributes. See attachment 353916 [details] [diff] [review].

Comment 44

[Dão Gottwald [:dao]]

We weren't talking about attachment 353916 [details] [diff] [review].

Comment 45

[:Gavin Sharp [email: [e-mail]]]

I meant "less common form of SSL", i.e. an indication of a lower level of encryption/"safety". But that's not really an important point.

I still think that the simplicity/consistency of introducing a new value rather than trying to shoehorn the current values into a new model is the best way forward. Some themes will need to be adjusted, but there's no risk that we'll break someone, and the adjustment is relatively simple. We can phase out the use of "low" eventually (or perhaps even immediately), and then we're left with a more intuitive set of choices: null/high/ev.

Comment 46

[Mike Connor [:mconnor]]

Comment on attachment 388159 [details] [diff] [review]
patch v1.7

This will mean that anyone who styled "low" in a way that would indicate weaker encryption would now have that style applied for high security encryption.  That's the very opposite of backwards compatibility.  Low is "this is encrypted, but not in a way that's especially great" and I don't know why it would be preferable to change this.

The most backwards-compatible way of fixing this is to set an additional value, as I think an earlier patch rev had.

That said, I'm not really worried about backwards compatibility here, so I'd lean towards just adding a new value for level, for simplicity going forward.  Themes don't have a fantastic backwards compat story anyway, so I'd rather notify via AMO and dev-themes and be done with it.

Comment 47

[Dão Gottwald [:dao]]

(In reply to comment #46)
> anyone who styled "low" in a way that would indicate weaker
> encryption

That is a highly hypothetical case, I think.

> Low is "this is
> encrypted, but not in a way that's especially great"

I thought that's our message for verified domain versus verified identity, except that the former is not especially great in a different way: you know where you're sending the encrypted information to, but not who runs that place.

Comment 48

[Pardal Freudenthal (:ShareBird)]

(In reply to comment #46)
> 
> That said, I'm not really worried about backwards compatibility here, so I'd
> lean towards just adding a new value for level, for simplicity going forward. 
> Themes don't have a fantastic backwards compat story anyway, so I'd rather
> notify via AMO and dev-themes and be done with it.

Hmmm... One of my primary concerns is giving backwards compatibility... I have been working very hard for it and my theme is just one file for Firefox 1.5 - 3.6a1pre and Thunderbird 1.5 - 3.1a1pre. I know other themes that have also a wide range of compatibility.

Comment 50

[Ian Moody [:Kwan] (UTC+1)]

Attachment: Alternate approach adding the identity classes to the urlbar

Patch implementing the idea I outlined in bug 652465, which takes the classes that are currently applied to the identity box and also adds them to the urlbar itself, making it easy to style it along the same lines as the ident. box.
Sorry if I've done anything wrong here, first patch (hell, first time using any sort of revision control system).

Comment 51

[Asa Dotzler [:asa]]

Would be nice to get a UI review on this and either get it into the plan or wontfix it.

Comment 52

[:Gavin Sharp [email: [e-mail]]]

This doesn't need ui-review, since it has no direct UX impact (just provides extra flexibility for theme authors, hence "possibilities" in the summary).

Comment 53

[Alex Faaborg [:faaborg] (Firefox UX)]

I ui-review+ the notion of possibilities :)

Comment 54

[Dão Gottwald [:dao]]

Comment on attachment 528057 [details] [diff] [review]
Alternate approach adding the identity classes to the urlbar

I'm not convinced anymore that we should encourage themes to style the whole location bar rather than the identity block. However this patch is trivial enough that I would still accept it, except that there's one problem: Setting gURLBar.className = newMode; blows away any CSS classes that add-ons may have set on the location bar.

Comment 55

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:mossop, could you have a look please?
For more information, please visit auto_nag documentation.