377076 - Enhance Security tab in Page Info

Status: VERIFIED FIXED

(Firefox :: Page Info Window, defect)

Description

[Johnathan Nightingale [:johnath]]

Attachment: Screencap of current work

The security tab currently displays very technical information, and concerns itself only with SSL concepts.  This page should provide richer information for users who bother to investigate a site (see attachment).  

This would help speak to Firefox 3 PRD items SPI-001a, 001c, 001d, and 001e.

Comment 1

[Johnathan Nightingale [:johnath]]

Attachment: First patch for enhanced page info

Note that this patch, in addition to rewiring the security page, also removes the security info blurb from the General page.  Judging from the history of Florian's bug, I suspect that section was only added in the first place because the security tab info was so sparse.  

I think Florian's intent was to cram the two sentences of useful text into the general page and hence drop the security tab.  With the security tab back in, though, and with more content now being presented, I don't think the blurb on General makes sense.

Comment 2

[Michael Ventnor]

+    // Domain cookies just need to end with our target hostname
+    if(cookie.isDomain && new RegExp(cookie.host + "$").test(hostName)) {

Say I go to ask.com and it sets a cookie, won't this return true when I bring up this dialog on flask.com or foo-ask.com? (it still matches the regexp AFAICT)

Also, hosts contain . and thats a special character.

Comment 3

[Michael Ventnor]

I'm also going to play the annoying word-smith now :-)

+<!ENTITY  securityView.privacy.cookies                  "Does this website store information (cookies) on my machine?">

This really needs a more "current" tense, since you're checking the cookie database each time. A website may delete all its cookies at one moment and this would come out "No", but the wording implies that the No means cookies are never stored by this website. I hope this makes sense.

I suggest: "Is this web site storing information (cookies) on my computer?"

+<!ENTITY  securityView.privacy.passwords                "Do I have any saved passwords for this website?">

How about this: "Have I saved any passwords for this web site?"

Comment 4

[Asaf Romano (gone)]

Comment on attachment 261725 [details] [diff] [review]
First patch for enhanced page info

First scan, I didn't review the behavior yet.

>Index: base/content/pageinfo/pageInfo.xul
>===================================================================
>+        <!-- Security & Privacy -->
>     <vbox id="securityPanel">
>-      <textbox id="security-identity" readonly="true" class="header"/>
>-      <description id="security-identity-text" control="security-identity" flex="1"/>
>-      <hbox align="center">
>+      <!-- Identity Section -->
>+      <label id="security-identity" class="header" value="&securityView.identity.header;"/>
>+      <hbox>
>+        <vbox>
>+          <label id="security-identity-domain-label"
>+             class="fieldLabel"
>+             value="&securityView.identity.domain;" />
>+          <label id="security-identity-owner-label"
>+             class="fieldLabel"
>+             value="&securityView.identity.owner;"/>
>+          <label id="security-identity-verifier-label"
>+             class="fieldLabel"
>+             value="&securityView.identity.verifier;"/>
>+        </vbox>
>+        <vbox flex="1">
>+          <description id="security-identity-domain-value"
>+             class="fieldValue" />
>+          <description id="security-identity-owner-value"
>+             class="fieldValue" />
>+          <description id="security-identity-verifier-value"
>+             class="fieldValue" />
>+        </vbox>

Could you structure this as a xul grid (see other tabs). I would rather use read-only
textfields here to be consistend with all other pageinfo fields. Then you could
also easily set the control attribte on the label elements for defining the
fields purposes (for the use of screen readers).

>+      <!-- Privacy & History section -->
>+      <label id="security-privacy" class="header" value="&securityView.privacy.header;" />
>+      <grid>
>+        <columns>
>+          <column flex="1"/>
>+          <column flex="10"/>
>+          <column/>
>+        </columns>
>+        
>+        <rows>
>+          <row><!-- History -->
>+            <description id="security-privacy-history-label"
>+              class="fieldLabel">&securityView.privacy.history;</description>
>+            <label id="security-privacy-history-value" class="fieldValue" value="&securityView.unknown;" />

ditto for textfields/"control" relationships.

>+          </row>
>+          <row><!-- Cookies -->
>+            <description id="security-privacy-cookies-label"
>+              class="fieldLabel">&securityView.privacy.cookies;</description>
>+            <label id="security-privacy-cookies-value" class="fieldValue" value="&securityView.unknown;" />
>+            <button id="security-view-cookies" label="&securityView.privacy.viewCookies;"
>+              accesskey="&securityView.privacy.viewCookies.accessKey;"
>+              oncommand="security.viewCookies();"/>

general nit: line up the attributes properly.
      
>Index: base/content/pageinfo/security.js
>===================================================================
>+  
>+  /**
>+   * Open the cookie manager window
>+   */
>+  viewCookies : function()
>+  {
>+    window.openDialog(
>+      "chrome://browser/content/preferences/cookies.xul",
>+      "Browser:Cookies", "");

This can open multiple cookie manager windows, you need to first check if
the cookie manager is already opened and focus it is so, see http://lxr.mozilla.org/seamonkey/source/browser/base/content/utilityOverlay.js#378
for example.

>+    
>+  },
>+  
>+  /**
>+   * Open the password manager window
>+   */
>+  viewPasswords : function()
>+  {
>+    window.openDialog(
>+      "chrome://passwordmgr/content/passwordManager.xul",
>+      "Toolkit:PasswordManager", "");

ditto.

>+  },
> 
>   _cert : null
> };
> 
> function securityOnLoad() {
>   var bundle = srGetStrBundle("chrome://pippki/locale/pippki.properties");
>+  var pageInfoBundle = srGetStrBundle("chrome://browser/locale/pageInfo.properties");

There's a <xul:stringbundle> for it.

> 
>-  var idHdr;
>-  var message1;
>-  var message2;
>+  /* Set Identity section text */
>+  setText("security-identity-domain-value", info.hostName);
>+  
>+  // FIXME - Should only be showing the next two if the cert is EV.  Waiting on
>+  // bug 374336
>+  var owner, verifier;
>+  if(info.cert && !info.isBroken) {
>+    // Try to pull out meaningful values.  Technically these fields are optional
>+    // so we'll employ fallbacks where appropriate.  The EV spec states that Org
>+    // fields must be specified for subject and issuer so when 374336 lands, this
>+    // code can be simplified.
>+    owner = info.cert.organization;
>+    if(!owner) {
>+      owner = info.cert.commonName;
>+      if(!owner)
>+        owner = info.cert.subjectName;
>+    }

This could be simplified to:
owner = info.cert.organization || info.cert.commonName ||
        info.cert.subjectName;
    
> 
>-  /* Set the identification messages */
>-  if (info.cert) {
>-    idHdr = bundle.GetStringFromName("pageInfo_WebSiteVerified");
>+    verifier = info.cAName;
>+    if(!verifier) {
>+      verifier = info.cert.issuerCommonName;
>+      if(!verifier)
>+        verifier = info.cert.issuerName;
>+    }
>+    verifier = security.mapIssuerOrganization(verifier);

ditto (and generally please try to avoid using the same variable for different purposes)

>+    
>+  } else {

nit: no |} else [if] {| code style in new code please.
 
>-    message1 = bundle.formatStringFromName("pageInfo_Identity_Verified",
>-                            [ info.hostName, info.cAName ],
>-                            2);
>-    setText("security-identity-text", message1);
>+  setText("security-identity-owner-value", owner);
>+  setText("security-identity-verifier-value", verifier);
> 
>+  /* Manage the View Cert button*/
>+  if (info.cert) {
>     var viewText = bundle.GetStringFromName("pageInfo_ViewCertificate");
>     setText("security-view-text", viewText);
>     security._cert = info.cert;
>   }
>   else {
>-    idHdr = bundle.GetStringFromName("pageInfo_SiteNotVerified");
>     var viewCert = document.getElementById("security-view-cert");
>     viewCert.collapsed = true;
>   }
>-  setText("general-security-identity", idHdr);
>-  setText("security-identity", idHdr);
> 
>+  /* Set Privacy & History section text */
>+  var yesStr = pageInfoBundle.GetStringFromName("yes");
>+  var noStr = pageInfoBundle.GetStringFromName("no");
>+
>+  setText("security-privacy-cookies-value",
>+    hostHasCookies(info.hostName) ? yesStr : noStr);
>+  setText("security-privacy-passwords-value",
>+    realmHasPasswords(info.fullLocation) ? yesStr : noStr);
>+  setText("security-privacy-history-value",
>+    hostIsPreviouslyVisited(info.hostName) ? yesStr : noStr);
>+
>+  /* Set the Technical Detail section messages */


> function setText(id, value)
> {
>   var element = document.getElementById(id);
>   if (!element)
>     return;
>-  if (element.localName == "textbox")
>+  if (element.localName == "textbox" || element.localName == "label") {
>     element.value = value;
>-  else {
>+  } else {

do not that yet.

> 
> function viewCertHelper(parent, cert)
> {
>   if (!cert)
>     return;
> 
>   var cd = Components.classes[CERTIFICATEDIALOGS_CONTRACTID].getService(nsICertificateDialogs);
>   cd.viewCert(parent, cert);
> }
>+
>+/**
>+ * Return true iff we have cookies for hostName
>+ */
>+function hostHasCookies(hostName) {
>+  if(!hostName)

general nit: missing space between the if keyword to the parenthesis.

>+    return false;
>+

nit: trailing spaces.

>+  var cookieManager = Components.classes["@mozilla.org/cookiemanager;1"]
>+    .getService(Components.interfaces.nsICookieManager);

nit: line this up please.

>+  
>+  var iter = cookieManager.enumerator;
>+  while (iter.hasMoreElements()){
>+    var cookie = iter.getNext().QueryInterface(Components.interfaces.nsICookie);
>+    if(!cookie)
>+      continue;
>+    
>+    // Non-domain cookies must match exactly to be counted here
>+    if(!cookie.isDomain && cookie.host == hostName) {
>+      return true;
>+    }
>+    
>+    // Domain cookies just need to end with our target hostname
>+    if(cookie.isDomain && new RegExp(cookie.host + "$").test(hostName)) {
>+      return true;
>+    }
>+  }

nit: avoid braces around single-line blocks.

>+function realmHasPasswords(location) {
>+  if(!location) 
>+    return false;
>+  
>+  var realm = location.protocol + "//" + location.host;

Er...  Don't construct uris manually, you can use makeURI(location).prePath here.

>Index: locales/en-US/chrome/browser/pageInfo.dtd
>===================================================================
>@@ -117,8 +117,28 @@
> <!ENTITY  permCookie            "Set Cookies">
> <!ENTITY  permInstall           "Install Extensions or Themes">
> 
> <!ENTITY  securityTab           "Security">
> <!ENTITY  securityTab.accesskey "S">
> <!ENTITY  securityHeader        "Security information for this page">
> <!ENTITY  securityView.label    "View">
> <!ENTITY  securityView.accesskey "V">
>+<!ENTITY  securityView.yes       "Yes">
>+<!ENTITY  securityView.no        "No">

not used.

Comment 5

[Florian Quèze [:florian] (on leave until October 9)]

(In reply to comment #1)
> Judging from the history of Florian's bug, I suspect 
> that section was only added in the first place because
> the security tab info was so sparse.  
>
> I think Florian's intent was to cram the two sentences of useful text into the
> general page and hence drop the security tab.  With the security tab back in,
> though, and with more content now being presented, I don't think the blurb on
> General makes sense.
> 

My first idea was to remove the Security tab and to put the info which used to be there in the General tab.
The result was something like that:
http://mozilla.queze.net/soc/progress/2006-08-25/pageinfo-soc-2006-08-25-1.png

When I knew that the Security tab was going to be improved, then my idea changed. On the General tab, I wanted a summary of the security info, because the General tab is the first thing you see when you open Page Info and security is sufficiently important to be something good to see at first glance.

I thought that something like the padlock in the location bar (but with a bigger icon) with one or two line of text could do it. I didn't spend time on that because I knew someone was going to change security info. The thing currently on the General tab can be considered as a FIXME ;-).

Anyway, if you decide to remove that part of the General tab, you should also remove the function onClickMore of pageInfo.js.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 261725 [details] [diff] [review]
First patch for enhanced page info

I agree with Florian, here. The General Tab should be an overview of the page, and contain a quick statement about the page's security that links off to the more detailed security information.

Comment 7

[Johnathan Nightingale [:johnath]]

Attachment: Updated patch

New patch with review comments addressed.  Also re-adds the security section of the general tab but:

a) With identity information when available
b) Without a twistie for collapsing.  Now that there is relevant content in here, it makes sense to separate it from the other content with a group box, but less sense to me to collapse it.

I'll attach new screencaps as well.

Comment 8

[Johnathan Nightingale [:johnath]]

Attachment: Updated screenshots of page info

Comment 9

[Florian Quèze [:florian] (on leave until October 9)]

(In reply to comment #7)
> b) Without a twistie for collapsing.  Now that there is relevant content in
> here, it makes sense to separate it from the other content with a group box,
> but less sense to me to collapse it.
> 

Collapsing makes sense when there are lots of meta tags and you want to see them correctly without making the window fullscreen. I agree with you that when there are few meta tags (or none), it doesn't make sense to collapse the security groupbox.

Comment 10

[Johnathan Nightingale [:johnath]]

(In reply to comment #9)

> Collapsing makes sense when there are lots of meta tags and you want to see
> them correctly without making the window fullscreen. I agree with you that when
> there are few meta tags (or none), it doesn't make sense to collapse the
> security groupbox.

Yes, but collapsing only gets you ~3-4 lines of space in that case, meaning that you're probably going to be growing the window anyhow.  It's a trade-off, I agree, I just think that having always-available, at-a-glance security info will be the more-useful of the two.

Comment 11

[Florian Quèze [:florian] (on leave until October 9)]

(In reply to comment #10)
> Yes, but collapsing only gets you ~3-4 lines of space in that case, meaning
> that you're probably going to be growing the window anyhow.  It's a trade-off,
> I agree, I just think that having always-available, at-a-glance security info
> will be the more-useful of the two.
> 

I didn't make the closed attributes persist so security info is always available when the window is opened, even if you keep the twistie.

About making the security part visible: is it more visible at the bottom of the tab or would it be better to swap the meta and the security groupboxes?

Comment 12

[Michael Ventnor]

Comment on attachment 261827 [details] [diff] [review]
Updated patch

My 2c:

>+<!ENTITY  securityView.privacy.history                  "Have I visited this website before today?">

This is pretty ambiguous wording. This could also mean "have you previously visited this website today?". Also space between web and site. Maybe "Have I visited this website earlier than today?" but I'm having trouble thinking of clear wording myself. :-)

>+<!ENTITY  securityView.technical.header                 "Technical Details">

You only talk about encryption here. "Encryption Details"?

>+securityNoIdentity=This web site does not supply identity information.

"This web site has not supplied identity information" since the information is given to the browser before the page loads, and also since the web site may start to supply information later. Also, no period for consistency.

Comment 13

[Michael Ventnor]

> Maybe "Have I visited this website earlier than today?"

Oops ;-)
"Have I visited this web site earlier than today?"

Comment 14

[Michael Ventnor]

(In reply to comment #12)
> This is pretty ambiguous wording. This could also mean "have you previously
> visited this website today?".

On second thought after scanning the code again, this may actually be what you mean. If so, the wording mentioned above is much more clear. I'll shut up now.

Comment 15

[Michael Ventnor]

Comment on attachment 261827 [details] [diff] [review]
Updated patch

OK, ignore my previous comment. I know what it does now. I just have only one more thing, I promise:

>+  var query = historyService.getNewQuery();
>+  query.endTimeReference = query.TIME_RELATIVE_NOW;
>+  query.endTime = -24 * 60 * 60 * 1000000;  // 24 Hours ago in microseconds

Use

query.endTimeReference = query.TIME_RELATIVE_TODAY;
query.endTime = 0;

so the query ends at the very beginning (midnight) of the current day, not 24 hours ago which goes into yesterday. That way the query doesn't miss out on some of yesterday's visits.

Comment 16

[Johnathan Nightingale [:johnath]]

Attachment: Patch v3 (diff only on history query)

Changed places query per Michael's suggestion.

Comment 17

[Alfred Kayser]

A request: 
Please use groupbox/caption instead of vbox/label/groove for the grouping and captioning of the items?
It is best to use the most semantical correct widgets in the XUL, and let the theme make it nice.

Comment 19

[Johnathan Nightingale [:johnath]]

Comment on attachment 261942 [details] [diff] [review]
Patch v3 (diff only on history query)

Changing reviewer to mconnor since he offered so nicely.

Comment 20

[Mike Connor [:mconnor]]

Comment on attachment 261942 [details] [diff] [review]
Patch v3 (diff only on history query)


+          <row><!-- Cert button -->
+            <button id="security-view-cert" label="&securityView.label;"
+                    accesskey="&securityView.accesskey;"
+                    oncommand="security.viewCert();"/>
+            <label id="security-view-text" class="fieldLabel"
+                   control="security-view-cert" flex="1"/>
+          </row>

This is basically what we have, but I think its kinda crappy.  File a followup to clean this up, it sticks out a lot.

+      <separator class="groove"/>

there's a general stylistic issue between the prefwindow and page info (less noticeable on Mac than on Windows) with groupbox vs. separator, please file a followup on that as well

+  // FIXME - Should only be showing the next two if the cert is EV.  Waiting on
+  // bug 374336

is there a bug tracking this FIXME and the below comments?


+function hostHasCookies(hostName) {

this makes me sad, cookies needs a new backend for Moz2.

+function realmHasPasswords(location) {

file a followup on dolske to make this happier in the pwmgr trunk rewrite.

+/**
+ * Return true iff we have visited host before today.
+ */
+function hostIsPreviouslyVisited(host) {

iirc, we had a plan to show the visit count, maybe just return the length, and since > 0 evals to true, just fudge it for now, rather than rewriting this later.


+<!ENTITY  securityView.privacy.header                   "Privacy &amp; History">
+<!ENTITY  securityView.privacy.history                  "Have I visited this website before today?">
+<!ENTITY  securityView.privacy.cookies                  "Is this web site storing information (cookies) on my computer?">
+<!ENTITY  securityView.privacy.viewCookies              "View Cookies">
+<!ENTITY  securityView.privacy.viewCookies.accessKey    "K">
+<!ENTITY  securityView.privacy.passwords                "Have I saved any passwords for this web site?">
+<!ENTITY  securityView.privacy.viewPasswords            "View Saved Passwords">
+<!ENTITY  securityView.privacy.viewPasswords.accessKey  "W">
+
+<!ENTITY  securityView.technical.header                 "Technical Details">

really nitpicky, but a good practice:

Accesskey code looks to make the same case, then tries the opposite case, in the above you should use k and w instead of K and W.

overall, looks good, r=mconnor with the above fixed.

Comment 21

[Johnathan Nightingale [:johnath]]

Attachment: Updated patch with mconnor's review comments.

Includes minor fixes and change of history field to "Yes, 14 times" instead of just "Yes".

Comment 22

[Johnathan Nightingale [:johnath]]

Attachment: Fix collisions with Trunk

Comment 23

[Johnathan Nightingale [:johnath]]

Attachment: OMG - Fix trunk collisions AND remove collision cruft.

Sorry Gavin.  :\

Comment 24

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

mozilla/browser/locales/en-US/chrome/browser/pageInfo.dtd 	1.12
mozilla/browser/locales/en-US/chrome/browser/pageInfo.properties 	1.8
mozilla/browser/themes/winstripe/browser/pageInfo.css 	1.8
mozilla/browser/themes/pinstripe/browser/pageInfo.css 	1.8
mozilla/browser/base/content/pageinfo/pageInfo.xul 	1.3
mozilla/browser/base/content/pageinfo/security.js 	1.2

Comment 25

[Michael Ventnor]

Attachment: Windows oogliness

The Page Info default window size on Windows isn't as large as on Mac (or maybe its because I'm on 1024x768?). I get this.

Maybe its best to remove the spaces between Website, Owner and Verifier? As it is those three are very space inefficient. Also, The labels with Yes or No definitely don't need as much space as they get. The buttons shouldn't get fat either.

Comment 26

[Michael Ventnor]

Attachment: Fix Winstripe

This fixes Windows issues with the new dialog. I think you're the best person to ask for review on this since you made the code.

Comment 27

[Michael Ventnor]

Attachment: Follow up fixes #2

Hehe, you forgot to put the readonly attribute on the textfields in the privacy section ;-)

Comment 28

[Michael Ventnor]

Attachment: Follow up fixes #3

Handle i18n of the visit count better. That'll be all from me, I know I've been involved this bug way more than I should.

Comment 29

[Alfred Kayser]

Note: I still don't like the vbox&label construct used instead of the normal groupbox&caption...

See also https://bugzilla.mozilla.org/attachment.cgi?id=262704

The Labels and Groove are not the standard way to make labeled groups.
Groupbox/Caption is intended for that purpose.

Comment 30

[Wesley Johnston (:wesj)]

Sorry if this is bugspam. I know this is resolved now, but the wording in this dialog is weird. Why is it asking itself questions? "Have I previously visited this site?" "Have I saved any passwords for this site?" No other place does the dialog (or any dialog in FF) ask questions like this unless it wants the user to answer.

Seems like it would be much simpler just to write, "Previously Visited on: <date>", or "Previously Visited <num> times" (add a button to open the site's history in places?) and have buttons labeled "Stored Information" and "Stored Passwords" that when disabled read "No Stored Information" and "No Stored Passwords".

Comment 31

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

(In reply to comment #30)
> Sorry if this is bugspam. I know this is resolved now, but the wording in this
> dialog is weird. Why is it asking itself questions? "Have I previously visited
> this site?" "Have I saved any passwords for this site?" No other place does the
> dialog (or any dialog in FF) ask questions like this unless it wants the user
> to answer.

That's not true - have you looked through the preferences panel lately? :)

Comment 32

[Johnathan Nightingale [:johnath]]

(In reply to comment #28)
> Created an attachment (id=262735) [details]
> Follow up fixes #3
> 
> Handle i18n of the visit count better. That'll be all from me, I know I've been
> involved this bug way more than I should.

Not at all, Michael, it's appreciated.  I have created bug 378770 for following up on your issues and a couple other UI fixes.  Would you please move the patch there for proper tracking?

Comment 33

[Johnathan Nightingale [:johnath]]

(In reply to comment #29)
> Note: I still don't like the vbox&label construct used instead of the normal
> groupbox&caption...
> 
> See also https://bugzilla.mozilla.org/attachment.cgi?id=262704
> 
> The Labels and Groove are not the standard way to make labeled groups.
> Groupbox/Caption is intended for that purpose.

I actually agree, Alfred, but I would like to track this change as an independent bug.  I have opened bug 378770 to track these issues, if you're interested.

Comment 34

[Wesley Johnston (:wesj)]

(In reply to comment #31)
> 
> That's not true - have you looked through the preferences panel lately? :)
> 

I don't see anything in there with a question mark in it, and its a different situation anyway. The prefs panel is asking for user input (i.e. "Where do you want to save downloaded files?" etc). Not, "Have you viewed this page before?" which is rhetorical. I'm not gonna argue in the bug. I figured "Enhance Security Tab" was a general enough subject that it would fit. I offered my complaint and a possible solution. Ignore it if you want. I'm used to it.

Comment 35

[Carsten Book [:Tomcat]]

the enhanced security tab is now covered in litmus tests

Comment 36

[eli]

Jonathan (and any other interested parties):

A team of four masters and PhD students (including myself!) at the University of Washington plan to design, execute and report results of a usability study of this revised security interface in Firefox 3.0, as a graduate course project. (The study may extend into broader FF security + usability issues, time and scope permitting.)

So that the results may be of most value for you, may we ask if there were specific end-user concerns that this change sought to address, beyond a general simplification of the interface? e.g. 

- were certain segments of the FF user base encountering any *particular* types of confusion from the previous security tab, which are now hoped to be addressed?

- are there particular security decisions that users are believed to be making upon particular types of web pages which are intended to be better informed through this change? What would these decisions be?

- (etc)

Finally, if there is anyone interested in providing input on particular areas of concern that you'd like to see fall into the usability study -- or be forwarded test planning docs for your input in the next few weeks -- please let me know. We would very much welcome your input.

Thanks in advance on behalf of our research group, 

- Eli (masters student in Technical Communication, University of Washington
...and Moz QA guy way back when. ;-)

Comment 37

[Johnathan Nightingale [:johnath]]

(In reply to comment #36)
> Jonathan (and any other interested parties):
> 
> A team of four masters and PhD students (including myself!) at the University
> of Washington plan to design, execute and report results of a usability study
> of this revised security interface in Firefox 3.0, as a graduate course
> project. (The study may extend into broader FF security + usability issues,
> time and scope permitting.)

Heh - "broader FF security and usability issues" and "time and scope permitting" are funny things to see in the same sentence!  :)

I think it's great news, though, that your group is looking at this as a project, and am happy to help out where I can.

> So that the results may be of most value for you, may we ask if there were
> specific end-user concerns that this change sought to address, beyond a general
> simplification of the interface? e.g. 
> 
> - were certain segments of the FF user base encountering any *particular* types
> of confusion from the previous security tab, which are now hoped to be
> addressed?
> 
> - are there particular security decisions that users are believed to be making
> upon particular types of web pages which are intended to be better informed
> through this change? What would these decisions be?
> 
> - (etc)

So I suspect we all know the real reason here: the old page sucked.  :)

I don't mean to be glib, but the reason for the re-write did not come from specific user data as much as it came from general design instinct that a better job could be done here.  Indeed, I suspect very few FF1 or FF2 users interacting with the security tab of page info, precisely because of its nearly content-free design (content-free for mortals, anyhow).

As such, success criteria include "is it more comprehensible to non-technical users?" "does it allow them to answer the questions they might have about the site's security?" and "is it sufficiently valuable that they might integrate it into their browsing habits more regularly?"  

Of course, the last question there relies a great deal on discoverability, which is something that is virtually absent for Page Info in general.  As you know, there are a couple ways into Page Info in general (right-click menu in content, Tools menu item, accel-I keyboard shortcut) and for security in particular (clicking the padlock when available, or using the "Tell me more about this site" text in the "Larry" patch over in bug 383183).  Nevertheless, it is my suspicion, unfounded except for the anecdotal "Ooh - neat" reactions when I point it out to non-technical users, that none of these access methods bubble up to where users notice and interact with the dialog. 

It would be very valuable indeed to know whether the new Page Info does a better job of informing users about the sites with which they interact, once they are made aware of its existence.  It will not, of course, be a solution to the broader question of whether and how to make the information more discoverable in the first place.  What was that about "time and scope"?  :)

> Thanks in advance on behalf of our research group, 
> 
> - Eli (masters student in Technical Communication, University of Washington
> ...and Moz QA guy way back when. ;-)

Thanks for the interest and welcome back into the fold - I've already seen a couple people paste this comment link in IRC with "Eli's back!"  :)

This bug is marked resolved, and I don't want to spam people too much with activity on dead bugs, but I wanted to reply here so that your comment didn't appear to go unanswered.  If you have more questions, I'm happy to take them to email; or to a newsgroup, if you'd like to continue soliciting broader input.

Comment 38

[Carsten Book [:Tomcat]]

verified fixed with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a9pre) Gecko/2007101504 Minefield/3.0a9pre ID:2007101504