The Add Security Exception dialog text is misleading

RESOLVED FIXED

Status

Core Graveyard
Security: UI
RESOLVED FIXED
10 years ago
a year ago

People

(Reporter: jwatt, Assigned: jwatt)

Tracking

({late-l10n})

Trunk
late-l10n
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Created attachment 303502 [details] [diff] [review]
patch

When trying to add a security exception for one particular site, I discovered that the Add Security Exception dialog starts with the sentence:

  You are about to override how Minefield identifies sites.

By saying "how Minefield identifies sites", it makes it sound like I'm going to be lowering the security for any and all sites that I might visit (turn off some generic checking perhaps). The dialog should be clear that the effect only applies to the current site. I'd suggest replacing the text "sites" with "this site".
Flags: blocking1.9?
Attachment #303502 - Flags: review?(kengert)

Updated

10 years ago
Keywords: late-l10n

Comment 1

10 years ago
The proposed string change sounds reasonable.

If we take it, would we need a new string ID?
(Note this string is new in Firefox 3, but we are after string freeze already.)
(In reply to comment #1)
> The proposed string change sounds reasonable.
> 
> If we take it, would we need a new string ID?
> (Note this string is new in Firefox 3, but we are after string freeze already.)

I think this would require an entity rev, yes, since the stated purpose of the bug is to change the meaning of the string (to more accurately reflect reality). 

FWIW, I don't think this is blocking - if anything, the current text is over-scary which is the right mistake to make, in this case - but it's also a low risk patch outside of the late-l10n hit and jwatt's string is more correct.

Comment 3

10 years ago
Axel, do you want to take this change?
If yes, we'll need a new patch which updates the string ID, too.
Flags: blocking1.9? → blocking1.9-
(Assignee)

Comment 4

10 years ago
Johnathan, it might be "over-scary", but it's also confusing, and that's a bad user experience to have. Especially when it comes to security where we should be doing our best not to confuse.
(Assignee)

Comment 5

10 years ago
Created attachment 304610 [details] [diff] [review]
patch with new name
Attachment #303502 - Attachment is obsolete: true
Attachment #304610 - Flags: review?(kengert)
Attachment #303502 - Flags: review?(kengert)
(In reply to comment #4)
> Johnathan, it might be "over-scary", but it's also confusing, and that's a bad
> user experience to have. Especially when it comes to security where we should
> be doing our best not to confuse.
 
I suspect that this is more likely to confuse experts than novices, who are unlikely to have a sufficiently rich mental model of certificate validation to make the distinction.

I also agree though (wholeheartedly!) that your text is better.  I was making the point above that I don't think this is a blocker, because the text is unlikely to lead people to do a bad thing (whereas "under-scary" text might).  I am absolutely in favour of fixing it, though.

I also want us both to prepare for the day, after this has landed, when someone opens a bug suggesting we should changes "this site" back to "sites" because an exception allows other sites to source images or script from the exception site without warning or mixed-mode complaints, and hence impacts them too.  I hope I am kidding here, but I still have the fear.  :)
(Assignee)

Comment 7

10 years ago
Fair enought. What does your fear mean? Should we leave both strings in?
(In reply to comment #7)
> Fair enought. What does your fear mean? Should we leave both strings in?

Nah.  I was thinking out loud mostly, but your text is more correct than the original on the whole.  We care about communicating clearly in the 99% case more than we care about communicating confusingly, but technologically perfectly, in the edges.  Your patch looks good to me.

If someone ever opens that other bug, I'll race you to the WONTFIX button.

Comment 9

10 years ago
Comment on attachment 304610 [details] [diff] [review]
patch with new name

r=kengert
Attachment #304610 - Flags: review?(kengert) → review+
(Assignee)

Comment 10

10 years ago
Thanks Kai. What's next? Do I need review from Axel?
(In reply to comment #10)
> Thanks Kai. What's next? Do I need review from Axel?

Nope, just nominate the patch for approval and hope it hurries along, because today at midnight is string freeze.  :)
(Assignee)

Comment 12

10 years ago
Comment on attachment 304610 [details] [diff] [review]
patch with new name

Thanks Johnathan.
Attachment #304610 - Flags: approval1.9?
Comment on attachment 304610 [details] [diff] [review]
patch with new name

a=beltzner for 1.9
Attachment #304610 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 14

10 years ago
Checked in.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.