Wording on security-alert dialog is confusing

VERIFIED FIXED in Future

Status

Core Graveyard
Security: UI
P1
enhancement
VERIFIED FIXED
18 years ago
a year ago

People

(Reporter: Stephen P. Morse, Assigned: Javier Delgadillo)

Tracking

({helpwanted})

1.0 Branch
Future
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

(Reporter)

Description

18 years ago
When you submit a form insecurely you get a dialog with the following wording:

   Any information you submit is insecure and could be observed by a third
   party while in transit.  If you are submitting passwords, credit card
   numbers, or other information you would like to keep private, it would
   be safer for you to cancel the transmission.

         [OK]     [Cancel]

So what does the OK and cancel mean in this situation.  The wording suggested a 
safer recourse for you to take.  So you decide you want to take the suggestion.  
It that case it seems that you should press OK because you agree with what was
being proposed to you.  But that is just the opposite of what will happen.

Comment 1

18 years ago
Well, it does say "it would be safer for you to cancel the transmission"

I do agree that something to the effect of "Continue" rather than "OK" would 
make more sense in this case.

Comment 2

18 years ago
With Navigator 4.7, the warning shows Continue and Cancel, so the same should 
appear in Mozilla. Also, the Security warning in Mozilla has a checkbox stating 
"show me this alert next time" allowing the user to stop future warnings. This 
does not appear in Navigator 4.7, so should be removed in Mozilla.
OS: Windows NT → All
Hardware: PC → All
Target Milestone: --- → M18
(Reporter)

Comment 3

18 years ago
I don't agree that the checkbox should be removed.  I for one think this dialog 
is annoying and would do anything to get rid of it in the future.  Consider the 
following scenerio:

- User fills out a login form at a website and submits it
- Dialog appears saying "Do you want to save this password".  User clicks "yes"
- Long legal disclaimer dialog appears saying "Values will be stored
     unencrypted".  User clicks "OK"
- Security alert dialog appears for legal purposes.

At this point the user is probably so frustrated he has vowed never to use this 
feature (saving of passwords) again although he only got one dialog that was 
directly related to the password saving.  The legal disclaimer dialog is a 
necessary evil that will be shown only once in the lifetime of the browser.  And 
the security alert dialog has the checkbox so that it too should never appear.

However I have found that the checkbox has no effect.  Whether I check it or 
not, I seem to keep getting this dialog in the future.  Seems like you just 
can't win!
(Reporter)

Comment 4

18 years ago
I was about to file a bug on the checkbox not working, but I just tried to 
reproduce it and was unable to do so.  So perhaps it got fixed recently (or 
perhaps I was dreaming it).  So ignore the last paragraph in my previous 
comment.

Comment 5

18 years ago
The problem with the checkbox not working is bug 39518, I believe.

I also completely disagree that the checkbox should be removed.  Something 
useful not being done in 4.7 is a good reason why it shouldn't be done in 
Mozilla?  This alert, quite frankly, is annoying as hell, and I don't see how 
we're going to get anywhere and improve the product if our attitude 
is "Netscape 4.7 didn't have it. Netscape 6 shouldn't either."
In communicator, there are two kinds of security dialogs:

1) Those that are generated by the security libraries themselves.
There is a clear spec for PSM for the dialogs of this kind.

2) Those that are generated by "netlib" code, typically having
to do with transitions between secure/insecure web pages, or 
posting form data.  I'll call those "netlib security dialogs".
There are 7 of them in Communicator.  The alert described in 
this bug report is one of them.

There is not (AFAIK) a spec that enumerates and defines the 
netlib security dialogs for Mozilla or Seamonkey.  I dont' see
how we can claim the presence or absense of a feature (e.g. 
checkbox) is a bug if there is no spec for the dialog.

In late November 1999 there was intense activity to try to define
a spec for all the "netlib security dialogs" in Mozilla.  
I will send email to the recipients of this bug report about it.
(Reporter)

Comment 7

18 years ago
This bug report is not about the presense or absense of the checkbox, or whether 
or not the checkbox is working.  It has nothing to do with the checkbox.

It is about the wording in the dialog.  The dialog is saying, in essesnce, "You 
are doing something that is insecure.  We advise you not to do it." and the user 
is supposed to respond with OK or Cancel.  Well, at a user it would seem to me 
that if I wanted to take the advise given I should press OK and that is 
incorrect.  Continue/Cancel as was done in 4.x does not have this confusion 
factor.

Updated

18 years ago
Blocks: 48444

Comment 8

18 years ago
FWIW, I think Steve's suggestion should be adopted immediately -- this is not a 
good place to confuse users. If what they can do in this context is either 
cancel or continue a transmission, then the buttons should be labeled "Cancel" 
and "Continue." Hopefully it's not difficult to get this done and close this 
bug.

Comment 9

18 years ago
Setting target fix to future.
Target Milestone: M18 → Future

Comment 10

18 years ago
er, I'm kinda curious why this was moved to Future without comment right after 
Vera said it should be fixed immediately.  So reassigning to myself...
Assignee: ddrinan → BlakeR1234

Updated

18 years ago
Keywords: nsbeta3

Comment 11

18 years ago
lord, you thoughts here?
Assignee: BlakeR1234 → lord

Comment 12

18 years ago
I would suggest "Continue Anyway" instead of "OK".

Comment 13

18 years ago
Marking nsbeta3+ as something that would be good to fix if we have time.
Leaving priority as p3.  I believe that this should fall of the radar if we
don't have time to fix before pr3. We shouldn't hold for it.

Whiteboard: [nsbeta3+]

Comment 14

18 years ago
Rob Lord: Are you monitoring this bug? It's now marked nsbeta3+. It would be 
really nice to fix it and reduce the list of nsbeta3+ bugs. Every little bit 
helps.

I consider this to be one of the most important UI text changes that I'm 
watching. As Steve Morse pointed out in his original summary, if the user clicks 
OK then it's highly probably that what happens will be the precise opposite of 
what he/she had intended. We don't want to confuse users here. Let's make this 
small change and close this.

Comment 15

18 years ago
Sorry... *Bob Lord*  (Rob Lord was the guy I went to high school with)

Comment 16

18 years ago
This should never have been reassigned, as I was never consulted.  It is 
considered inconsiderate to reassign a bug without contacting the previous 
owner...
Assignee: lord → BlakeR1234

Updated

18 years ago
Status: NEW → ASSIGNED
Priority: P3 → P1

Comment 17

18 years ago
OK, so what's the decision?  'Continue Anyway' or 'Continue' ?
Target Milestone: Future → M18
(Reporter)

Comment 18

18 years ago
Let's just go with "Continue" (as was done in 4.x) and close this out.

Comment 19

18 years ago
Note related bug 32023.

Comment 20

18 years ago
I agree with Steve Morse; "Continue" by itself is fine.

Comment 21

18 years ago
PDT thinks this is a P4
Priority: P1 → P4
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP4]

Comment 22

18 years ago
Complications with the fix are making this look less likely for beta3.  Sorry.

Comment 23

18 years ago
This will not be done in the beta3 timeframe, sorry.  The fix involves more 
than just a simple text string and might introduce other 
problems...renominating for reconsideration.
Whiteboard: [nsbeta3+][PDTP4]

Comment 24

18 years ago
Marking nsbeta3- per PDT review.
Whiteboard: {nsbeta3-]

Updated

18 years ago
Whiteboard: {nsbeta3-] → [nsbeta3-]

Comment 25

17 years ago
Setting milestone to future.
Target Milestone: M18 → Future

Comment 26

17 years ago
No time for this right now.
Assignee: blakeross → ddrinan
Status: ASSIGNED → NEW
Priority: P4 → P3
QA Contact: junruh → nitinp
Target Milestone: Future → ---

Comment 27

17 years ago
changing QA contact to junruh@netscape.com
QA Contact: nitinp → junruh

Comment 28

17 years ago
nsbeta1
Keywords: nsbeta1

Comment 29

17 years ago
Enhancement and Future.
Severity: normal → enhancement
Target Milestone: --- → Future

Comment 30

17 years ago
I also vote for "Continue" (though people like me who skim might catch "continue
anyway" and re-read the warning...).  

ddrinan is up to his eyeballs in work.  If someone else feels comfortable taking
the bug and getting it in, that would be cool.

Updated

17 years ago
Keywords: nsbeta3 → helpwanted
Whiteboard: [nsbeta3-]

Comment 31

17 years ago
Blake, what is involved in fixing this bug, other than a string change? Could 
stephend or Gerv or someone do it?

Comment 32

17 years ago
If I recall correctly, the security alert dialog is just a standard alert 
(common dialog), and so the text of the buttons can't be changed (maybe that's 
changed recently; cc'ing Conrad).  We probably need another bug on having that 
capability, if it doesn't exist already...
I'll have to dig a bit and find the code which puts up this dialog. I would
think that it uses (or could use) the new confirmEx method on nsIPrompt. Then,
it could specify the text of the buttons. "Continue" is a such a common button
title, it probably deserves to be represented as a constant (which, ugh, I
didn't provide). Even though we don't have a constant for it, it can still be
done with confirmEx as-is. If it's not obvious how to do this, I failed to
design a clear iface and you can re-assign this to me. See nsIPromptService.idl.
That's where the comments are.

Updated

17 years ago
Component: Security: Crypto → Client Library
Product: Browser → PSM
Target Milestone: Future → ---
Version: other → 2.0

Updated

17 years ago
Target Milestone: --- → 2.0

Comment 34

17 years ago
Given its potential frequency, this alert is one which the user is only going 
to see until the first possible moment when they work out how to turn it off. 
Because of this, I think the alert should put more emphasis on the dangers of 
insecure forms in general, and less emphasis on this insecure transmission in 
particular.

Thus:
+------------------------------------------------------------+
|::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
+------------------------------------------------------------+
|  .   On an insecure site such as this one, any information |
| /!\  you send could be read by a third party. You should   |
| """  avoid entering private information such as credit     |
|      card numbers or important passwords.                  |
|                                                            |
|      Are you sure you want to submit this form?            |
|                                                            |
|                                                            |
|      [/] Alert me whenever I submit an insecure form       |
|                                                            |
|                                  ( Cancel ) (( Continue )) |
+------------------------------------------------------------+

Shaving off a couple of words (42 instead of 44), avoiding unnecessarily 
complex words like `observed' and `transit', and putting the question itself in 
a separate paragraph, will help the user to read and understand the alert -- 
which in turn will improve security.

Comment 35

17 years ago
At first read, it looks like an improvement.  

Adding Cotter to the cc list.

Comment 36

17 years ago
could we be honest and replace 'could' with 'will'?

Comment 37

17 years ago
No.
I'm working on this :-)

Gerv
Assignee: ddrinan → gervase.markham

Comment 39

17 years ago
mpt's suggested new text is definitely an improvement over the original. I think
it can be improved further however. My main problem is the vagueness of the term
"insecure." If we're going to define a term for people and ask them to remember
it, we might as well use a term that already has a specific and widely accepted
meaning.

Here's my suggestion:

---
Because this site does not support encryption, any information you send can be
read by a third party. You should avoid sending private information such as
credit card numbers or important passwords.

Are you sure you want to submit this form?

[/] Alert me whenever I submit forms that a third party can read.
---

I agree with the Cancel and Continue buttons as described by mpt.

One question: are we sure that this dialog pops up only for something
identifiable as a form? If not, perhaps the word "form/forms" above should be
"information".

I'm not sure if I can do it or not, but nitinp and verah should be removed from
the cc list for this bug.

mpt has, in fact, rewritten the text for all of these dialogs. I personally 
think the results are a great improvement. I will attach the file.

Secondly, as part of my work on tidying up this dialog, I have split the "Alert 
me on submitting an insecure form" into two parts - "Alert me when I submit an 
insecure form from a secure page" (rare, and one most people will want to leave 
turned on) and "Alert me when submitted an insecure form from an insecure page" 
(very common, and one everyone will want to turn off.) The old pref name remains 
for the second of these.

I had a patch for this ready but, after modifying the code to accommodate mpt's 
recent set of changes, it all mysteriously stopped working and Mozilla started 
eating the prefs out of the file on startup. (Put them in prefs.js, run, close, 
look at prefs.js - they've gone.) I'm still working out why.

I will, however, attach mpt's new security.properties file for debate. It 
includes this alert and several others.

Gerv
Created attachment 33672 [details]
mpt's new sec props file

Comment 42

17 years ago
Some questions:

What's wrong with my suggested text?

Are you planning to submit C++ code required to add these proposed prefs to the
Prefs dialog? Or am I missing something?

The other strings in your attachment could be modified along the same lines I'm
suggesting, but first I want to find out what's wrong with the text I've already
proposed.

I'm the Netscape writer working on PSM 2.0 help and (to some degree) UI text. I
do appreciate having these alerts brought to my attention, they definitely need
improvement.
> What's wrong with my suggested text?

Nothing's particularly wrong with it as far as I can see. It's just that, having 
looked at and reworded all the security prefs at once, perhaps mpt's set might 
all gel together consistently quite well. That's why I attached the file to this 
bug - for review. All comments welcome :-)

> Are you planning to submit C++ code required to add these proposed prefs to
> the Prefs dialog? Or am I missing something?

Currently, two different branches in the code are controlled via the same pref 
string. I merely changed one of them to use a new pref string. All I then have 
to do is add a default value for that pref name to all.js - the prefs subsystem 
takes care of the rest. The file is nsNSSDialogs.cpp. This is where all the 
other tidy up is also taking place.

> I'm the Netscape writer working on PSM 2.0 help and (to some degree) UI text.
> I do appreciate having these alerts brought to my attention, they definitely 
> need improvement.

Ah, I see :-) mpt is Mozilla's chief overall UI design person. I'm sure the two 
of you can come to some agreement on what text Mozilla should be using :-)

Gerv

Comment 44

17 years ago
post-to-insecure-from-secure is no longer controlled by a pref per bug 50168. 
Please do not regress this.
Ah. Just got a heads-up from mpt about that. I'll make sure I don't regress it. 
Thanks :-)

Gerv
Created attachment 33771 [details] [diff] [review]
Patch v1 - new dialogs, better text

Comment 47

17 years ago
Comments on the proposed text:

MixedContentMessage:

Mozilla does not give the user a choice of not loading the insecure
items.  Doing so would be difficult to implement.

The "items" that are insecure are typically images, but they could be
frames.  In an extreme case, it could be that none of the information
displayed was obtained securely.  Usually, what this alert really
means is that the site developer screwed up their implementation of
security.  (Or there is a bug in Mozilla.) Some of the information the
user sees and sends back could be observed by a third party.  I don't
think it is reasonable to say the items may pose a security
risk--there is no extra risk of buffer overflows, viruses, etc.  At
worst the risk is the same as for normal non-SSL network content:
eavesdropping and impersonation.

WeakSecureMessage:

I think the word "rather" is unnecessary.  The first sentence sends a
mixed message.  The site is secure, but it is not secure.  Many users
will not read past the first comma.

I prefer the phrase "weak encryption" to "weak security" as the latter
incorrectly implies that the site's server and buisiness practices are
particularly vulnerable to penetration.

I believe the second sentence of this message should be the same as
the second sentence of LeaveSecureMessage.  The reason one should
"avoid sending private information" is that there is inadequate
protection against the information being read by a third party.  Any
difference in the wording between these two sentences should reflect
differences in the risk, not inconsistencies in the way these risks
are communicated to the user.

WeakSecureMessage and WeakSecureShowAgain are inconsistent as the
former states the security is weak whereas the latter states the
encryption is weak.

PostToInsecureFromSecureMessage:

I prefer using "Although" phrasing, as the proposed phrasing
appears to send a mixed message.  The document is secure, but the
information will be insecure.

Consider "will be sent insecurely" instead of "will be insecure".

Continue:

Consider "Continue anyway" for the ConfirmDialog()s to reinforce that
the user is being asked to evaluate a risk.

Comment 48

17 years ago
Didn't mean to reopen the "continue" versus "continue anyway" issue.  Please 
ignore that one comment.

Comment 49

17 years ago
Sean and John, thanks for your comments. A couple of responses:

> Because this site does not support encryption,

From a comprehension point of view, I think more people know about `secure 
sites' than know about `encryption'.

And from an accuracy point of view, saying `does not support encryption' is 
just plain wrong. For example, the e-mail service I use has a Webmail site 
which supports encryption, but its `secure mode' (note the use of the word 
`secure', rather than `encrypted') is optional. If I used the `normal mode' 
with this alert turned on, Mozilla would tell me that the site `does not 
support encryption', and it would be wrong.

>                                                any information you send can

I used `could' instead of `can' because the information has not been sent yet.

> be read by a third party. You should avoid sending private information such
> as credit card numbers or important passwords.
>
> Are you sure you want to submit this form?

You're correct that the page might not be recognizable as a form, which is why 
I changed `submit this form' to `send this information' in my proposed changes. 
(In his first attachment, Gerv accidentally attached the original version 
instead of my revised version.)

> [/] Alert me whenever I submit forms that a third party can read.

Firstly I think this is overly general, because it wouldn't be clear what the 
distinction would be between this situation and submitting a form which gets 
redirected to an insecure site. Secondly we alert the user once for each 
individual form, not for forms plural. And thirdly, checkbox text shouldn't end 
with a full stop.

> Mozilla does not give the user a choice of not loading the insecure items.
> Doing so would be difficult to implement.

That would be a shame, because it would just about prevent deployment of any
Mozilla-based browser at the Internet cafe where I work. Hotmail's `sorry, your 
account cannot be accessed at this time' error message, which we see 
frequently, :-) is secure but the graphics on it are not. I can't imagine MSN 
changing their configuration just because Mozilla browsers can't load the page 
/sans/ graphics, when Internet Explorer (which we use currently) can do this 
just fine.

> I don't think it is reasonable to say the items may pose a security risk --
> there is no extra risk of buffer overflows, viruses, etc.

I thought the main reason for showing this alert was because there was a risk 
of the insecure content getting access to the secure content via the DOM. Is 
that not possible?

Comment 50

17 years ago
Some responses to mpt's most recent comments.

> From a comprehension point of view, I think more people know about `secure
> sites' than know about `encryption'.

Re the merits of "insecure/secure" vs. "unencrypted/encrypted", I can think of
reasonable arguments for both.

"insecure/secure" is vaguer, but maybe that's OK. You're right, "secure site" is
in common use, even if most people have only a fuzzy idea of what it means.
Maybe users really only need to know that in some mysterious way things are
"more secure" one way and "less secure" or "insecure" another way.

"unencrypted/encrypted" is more specific. And "encryption" does have an everday
meaning outside of computer science. As any Star Trek fan can tell you,
encrypted messages can be decrypted if one is smart enough or has the necessary
magic powers/numbers/etc. The fact that a page is encrypted doesn't necessarily
mean it's "secure". For example, it may be using 40-bit, which is easily broken.
We have got into trouble in the past by trying to dumb down security issues for
users.

I would like to see more discussion of this. I can see going either way (despite
the fact that "insecure site" always suggests "neurotic" to me).

> And from an accuracy point of view, saying `does not support encryption' is
> just plain wrong. For example, the e-mail service I use has a Webmail site
> which supports encryption, but its `secure mode' (note the use of the word
> `secure', rather than `encrypted') is optional. If I used the `normal mode'
> with this alert turned on, Mozilla would tell me that the site `does not
> support encryption', and it would be wrong.

I agree. How about something like "Because this web page does not support
encryption . . ."

>> any information you send can

> I used `could' instead of `can' because the information has not been sent yet.

If you feel this distinction is important, it might be better to say "the
information you are about to send" or something to that effect. To my ear,
"could" sounds odd--not wrong, just a bit awkward. The whole dialog, as well as
the sentence, implies that we're in a pause here where you get to reconsider
your action.

> be read by a third party. You should avoid sending private information such
> as credit card numbers or important passwords.

>> Are you sure you want to submit this form?

> You're correct that the page might not be recognizable as a form, which is why
> I changed `submit this form' to `send this information' in my proposed
> changes. (In his first attachment, Gerv accidentally attached the original
> version instead of my revised version.)

>> [/] Alert me whenever I submit forms that a third party can read.

> Firstly I think this is overly general, because it wouldn't be clear what the
> distinction would be between this situation and submitting a form which gets
> redirected to an insecure site. Secondly we alert the user once for each
> individual form, not for forms plural. And thirdly, checkbox text shouldn't
> end with a full stop.

I don't understand the distinction you're making re redirection. Doesn't the
same issue re the word "form" vs. "information" apply here? To my ear "insecure
form" or "insecure information" grates on the blackboard even worse than
"insecure site." The danger is that a third party may be able to read it, and
that's why one might want to be warned.

I can't speak to the technical issues you raised. 
*** Bug 64362 has been marked as a duplicate of this bug. ***

Comment 52

17 years ago
> Mozilla does not give the user a choice of not loading the insecure items.
> Doing so would be difficult to implement.

Actually, if the user doesn't have a choice of loading the insecure items, why
are you asking them anything at all? By the time you come across <img
src="http://insecure.foo.bar/hum.gif"> at the end of an encrypted HTML file,
you've already loaded the HTML file. You can't ask the user whether they want to
cancel that loading, it's too late. All you can ask is whether they want to
cancel loading the insecure stuff you've found references to.

> I can see going either way (despite the fact that "insecure site" always
> suggests "neurotic" to me).

Which is why I carefully avoided that phrase.

> I don't understand the distinction you're making re redirection.

Just saying `Alert me whenever I submit forms that a third party can read' would
give the impression that the checkbox would set both the
PostToInsecureFromSecure and the PostToInsecureFromInsecure prefs at the same
time, when this is not in fact the case. (If it was, that would be a serious
security problem in itself.)

> Doesn't the same issue re the word "form" vs. "information" apply here?

Perhaps -- but if we can use slightly more informative wording in the checkbox,
while still obviously referring to the situation described in the alert text,
then the user will have a greater chance of understanding what is going on.
Created attachment 36008 [details]
mpt's security properties, V.2 - feedback, please.

Comment 54

17 years ago
> Title=
^no title? odd.
> MixedContentMessage=This is a secure document,
> but some items in it are not secure
^sorry, this doesn't mean much to me, so let's try some more real life 
examples.

I go to a fast food chain.  I order the top secret ultra burger.  The clerk 
gives me a sealed package and assures me it contains one roll and one patty 
(probably fish, but I don't know).  No one watching us knows what's in the 
package because I ordered through some means that is not easily observable 
(perhaps the drive thru?).  I then ask him for condiments.  Someone listens to 
_this_ conversation and finds out that I don't like malt vinegar but do like 
ketchup and pepper.

The ketchup and pepper I get from the clerk aren't really insecure, what's 
insecure is the content of my request (can I please have some ketchup, pepper 
and no malt vinegar).

Let's look at this in https context: I submit a secure document ordering the 
[super fish|v] w/ [ ] malt vinegar [x] ketchup [ ] salt [x] pepper.

The server responds w/ https://topsecret/super-fish.jpg 
http://opencondiments/ketchup.jpg http://opencondiements/nosalt.gif 
http://opencondiments/pepper.png http://opencondiments/nomaltvinegar.xbm

Someone sniffing the conversation figures out that I ordered a fish sandwich.
-end wacky order conversation-
> and could be read by a third party if loaded.
> \nDo you want to load the insecure items?
> MixedContentShowAgain=Alert me whenever an secure document contains
> insecure items
> LeaveSecureMessage=You are no longer in a secure site.
> Information you send or receive from now on could be read by a third party.
I'm sitting at a computer temrinal. Usually when I browse away from a secure 
site no one kicks me off a physical military base.  'in' =bad. (oddly) 'at' 
might be ok.

> LeaveSecureShowAgain=Alert me whenever I leave a secure site
why whenever and not when? [note that it doesn't say Alter me whenever i make 
myself no longer in a secure site]
> EnterSecureMessage=You are entering a secure site.
'Entering' is yucky you aren't physically entering a site, you are connecting 
(or talking) to it and perhaps visiting it.  Physical rules say an object will 
only be in one place at a time [well erm, maybe subatomics don't have this 
restriction].  It's ok to talk to multiple people at once, but it isn't ok to 
be in california, washington, london and tokyo at once.
 Information you send and receive is being encrypted for privacy while in 
transit.

For the backend string please use SecureConnectMessage.  I won't push the user 
visible string but let's keep the internals accurate.
> EnterSecureShowAgain=Alert me whenever I enter a secure site
ibid.
> WeakSecureMessage=Although this is a secure site,
> the security is rather weak.
rather? yuck yuck yuck. 'the security is not great' would be better [not 
ideal, just better]

'Weak Secure' would make an awful fragment. please consider WeakSecurity*

Weak isn't great, for the backend I think 'Low' is better.
> You should avoid sending private information such as credit card numbers
> or important passwords.

> WeakSecureShowAgain=Alert me whenever a site uses weak encryption
ibid where relevant. whenever _ a site uses ... ? did we miss something 
important? should the browser constantly alert the user about the billions of 
sites that aren't using strong security every second?  when _connecting to_ 
(fix sentence for grammar as needed ... site [that] ...)

> PostToInsecureFromSecureMessage=Although this document is secure,
Post? does this apply to Get? perhaps Send.
> the information you have entered is to be
is to be == Bad. perhaps is about to be [only slightly better].
> sent to an insecure site and could be read by a third party.
.
> You should avoid sending private information such as credit card numbers or 
important passwords.
> \nAre you sure you want to continue sending this information?
^these two lines are a repeat. please don't do that. Recycle the string 
somehow.

> PostToInsecureFromSecureShowAgain=Alert me whenever a secure form submits to 
an insecure site
Is submit a well defined term?  Perhaps Send or [re]directs or refers?
> PostToInsecureFromInsecureMessage=On an insecure site such as this one,
> any information you send could be read by a third party.
.
> You should avoid sending private information such as credit card numbers or 
important passwords.
> \nDo you want to continue sending this information?
same string again. me->recycle().

> PostToInsecureFromInsecureShowAgain=Alert me whenever I submit an insecure 
form
why not AlwaysWarnOnSendInsecureForm ?
> FindText=Please find the Personal Security Manager application so Mozilla can 
use it.
FindText is a bad name.  FindPSMText would be slightly better. However i'm not 
sure mozilla even supports out of process PSM anymore so this might be nukable.
> SecurityButtonTooltipText=Displays security information about the current 
document
^ s/Text//
Displays information about the security of the current document.

Comment 55

17 years ago
> ^no title? odd.

A deliberate workaround for one of the bugs in the nsIPrompt API -- alerts 
shouldn't have titles. (On Windows they should be titled with the name of the 
app, i.e. `Mozilla', but that should be done automatically by XP Toolkit and is 
a Different Bug.)

>...
> -end wacky order conversation-

I think what you're trying to say is that insecure items on a mixed-content 
page might give a clue as to the purpose of the secure items. That's true, but 
I think it's a nuance which can't be explained in an alert short enough for 
people to bother to read. Get thee to the online help.

>...
> > LeaveSecureMessage=You are no longer in a secure site.
> > Information you send or receive from now on could be read by a third party.
>
> I'm sitting at a computer temrinal. Usually when I browse away from a secure
> site no one kicks me off a physical military base.  'in' =bad. (oddly) 'at'
> might be ok.

No. You are in trouble, you are in pain, you are in the telephone directory, 
you are in a secure site. Occasionally customers asking for help at the cafe 
refer to themselves as being `on' a Web page or site, but usually it's `in'. 
Certainly never `at'.

> > LeaveSecureShowAgain=Alert me whenever I leave a secure site
>
> why whenever and not when?

Because `when' implies just a single occasion, `at what time', which is not 
what we want. `Whenever' implies multiple occasions, `at every time that', 
which is what we want. Repeat this explanation *whenever* you said `ibid'. (By 
the way, you mean `ditto', not `ibid'; `ibid' is for citations.)

>                            [note that it doesn't say Alter me whenever i make
> myself no longer in a secure site]

I don't think even Mozilla has the power to do that.

> > EnterSecureMessage=You are entering a secure site.
>
> 'Entering' is yucky you aren't physically entering a site, you are connecting
> (or talking) to it and perhaps visiting it.  Physical rules say an object
> will only be in one place at a time [well erm, maybe subatomics don't have
> this restriction].  It's ok to talk to multiple people at once, but it isn't
> ok to be in california, washington, london and tokyo at once.

No. But it is ok to be in multiple secure sites at once, via multiple browser 
windows. And `entering' and `leaving' is such a well-established metaphor in 
relation to Web sites that I'm surprised even you complained about it.

>...
> > WeakSecureMessage=Although this is a secure site, the security is rather
> > weak.
>
> rather? yuck yuck yuck. 'the security is not great' would be better [not
> ideal, just better]

I know `rather weak' is rather weak, but `not great' is not great either. It 
just seems like unnecessary inversion, making the user do more work in order to 
understand the message.

> Weak isn't great, for the backend I think 'Low' is better.

Low security to me implies lack of diligence, rather than (weak security) lack 
of encryption.

>...
> > WeakSecureShowAgain=Alert me whenever a site uses weak encryption
>...
> ibid where relevant. whenever _ a site uses ... ? did we miss something
> important?

No.

>            should the browser constantly alert the user about the billions of 
> sites that aren't using strong security every second?

No. That's why the checkbox doesn't say `Alert me whenever a site doesn't use 
strong encryption'.

>                                                        when _connecting to_
> (fix sentence for grammar as needed ... site [that] ...)

No. `Site that' would imply that some sites *always* use strong encryption, 
some *always* use weak encryption, and some *always* use no encryption. As my 
Webmail example shows, that's not correct. As for `connecting to', Mozilla does 
that for every single page, but we don't show this alert for every single page.

>...
> > the information you have entered is to be
>
> is to be == Bad. perhaps is about to be [only slightly better].

No. `Is about to be' would give the misleading impression that the transmission  
could not be cancelled.

> > sent to an insecure site and could be read by a third party. You should
> > avoid sending private information such as credit card numbers or important
> > passwords.\n\nAre you sure you want to continue sending this information?
>
> ^these two lines are a repeat. please don't do that. Recycle the string 
> somehow.

I think that's a worthwhile counteraction for the risk that the user won't read 
the explanatory text above the question at all.

> > PostToInsecureFromSecureShowAgain=Alert me whenever a secure form submits
> > to an insecure site
>
> Is submit a well defined term?  Perhaps Send or [re]directs or refers?

No. `Send' and `direct' can't be used as intransitive verbs, whereas `submit' 
can; `redirect' is usually not true; and `refer' has too many possible 
meanings.

>...
> \nDo you want to continue sending this information?
same string again. me->recycle().

Ditto.

>...
> FindText is a bad name.  FindPSMText would be slightly better. However i'm
> not sure mozilla even supports out of process PSM anymore so this might be
> nukable.

Yes. Someone please tell me where this text is used, if indeed it is used 
anywhere. Currently I'm assuming it's the help text printed under the file 
browser listbox in the filepicker, but I'm probably wrong.

> Displays information about the security of the current document.

Yes. That's better than what I had.
For future reference, the way to find whether an identifier is used is to use 
lxr.mozilla.org to search for it, and see if any of the hits are what you want. 
http://lxr.mozilla.org/seamonkey/search?string=FindText
For a start, anything in a directory called "test" can be excluded, and none of 
the remaining hits are correct so this identifier is no longer used.

Gerv

Comment 57

17 years ago
Created attachment 36678 [details]
Sean's revision of security.properties

Comment 58

17 years ago
I've discussed these alerts with thayes, lord, and other members of the PSM
team. With respect to the wording, the consensus (for now) is as follows:

- In most cases, what's currently called "secure" is really "encrypted and
authenticated." In the case of EnterSecureMessage and WeakSecureMessage, it's
important that the alert and other places this comes up (e.g. Page Info and
help) be explicit about both. In other cases, such as LeaveSecureMessage, it's a
reasonable tradeoff to talk about encryption only, even though authentication is
also involved.
- "Secure" is vague and potentially misleading. An encrypted page is not
necessarily secure, and "secure" does not necessarily imply encrypted and
authenticated. "Secure/insecure" should not be used in these alerts.
- The decision has been made to change "weak encryption" wheverever it occurs to
"low-grade encryption," which is clearly defined in help.

On the technical side:
- The proposed changes include splitting the old identifier DontShowAgain into
six "ShowAgain" identifiers that correspond to more precisely worded messages (a
good idea). In addition, the other identifiers have been changed. This requires
changes to the underlying C code.
- The identifier FindText is no longer used.

Given the number of other PSM bugs currently being triaged and fixed, the new
text needs to nailed down in the next few days to have any chance of getting
fixed soon. The C work required is not difficult, but the most practical way to
get this bug onto the train and fixed is to assign it to javi@netscape.com. That
will ensure it gets onto the team's radar and into the builds sooner rather than
later.

Based on the above, I've rewritten the alerts as shown in my attachment. I've
tried to incorporate mpt's and other people's suggestions to the extent possible
within the team's guidelines. In particular, I've tried to implement John Myer's
suggestion that we describe similar situations with similar language--while
keeping them as short as possible. As always this involves tradeoffs. For
example, mpt had a phrase about not sending credit card info etc. as part of
PostToInsecureFromSecureMessage, WeakSecureMessage, and
PostToInsecureFromSecureMessage. I agree that these are the logical mesages to
include this warning, if it appears at all. For now I've eliminated it to keep
the length down, on the (possibly dubious) assumption that "can easily be read
by a third party" is sufficient warning. If other people feel strongly that the
additional warning is needed despite the length, perhaps we should add the
slightly shorter sentence "You should avoid sending private information such as
credit card numbers" to these three messages only.

I'd like feedback on the new messages, preferably within the next few days and
within the guidelines described above. I'm most concerned about corner cases
that might make a message untrue or misleading under some circumstances. Also,
note that if we stick to this use of "encrypted," we will need to change the
labels for the SSL Warnings preferences to match (they currently use
secure/insecure). I will file a separate bug for that once this one is in the
pipe to get fixed.

We need to get this show on the road. Whatever defects the new text may still
have, it will be useful to see it in action in a beta before it gets finalized.
> This requires changes to the underlying C code.

It's C++, not C. You realise, of course, that these changes have already been
made, and are included in the patch attached to this bug?

> The C work required is not difficult,

I know. I've done it.

> to the extent possible within the team's guidelines.

> I'd like feedback... within the guidelines described above

Without wanting to antagonise, and hopefully as a purely academic point, I would
politely point out that the Netscape PSM team's guidelines on anything are not
necessarily the final word on any matter concerning Mozilla :-)

Gerv

Comment 60

17 years ago
>It's C++, not C. You realise, of course, that these changes have already been
>made, and are included in the patch attached to this bug?

No, I didn't realize this. I suggest you ask Javi for review so that things can
get moving.

>Without wanting to antagonise, and hopefully as a purely academic point, I
>would politely point out that the Netscape PSM team's guidelines on anything
>are not necessarily the final word on any matter concerning Mozilla :-)

I understand--no antagonism generated. However, the PSM team is the PSM module
owner. Regardless of where this particular file lives, as a practical matter the
PSM team must be on board for these changes to get approved. Perhaps you can
change their minds about the details, but the security buck for Mozilla
ultimately stops with Bob Lord.

There's no point in getting Javi to review until the patch is stable, and it
won't be until we get this text (or, at the very least, the internal names)
locked down. And that requires signoff from some UI people - probably mpt.

Gerv

Comment 62

17 years ago
Mass reassigning target to 2.1
Target Milestone: 2.0 → 2.1

Updated

17 years ago
Keywords: nsenterprise
Could sean and mpt please put their heads together and come up with an agreed
set of strings? Yet again, we have missed doing anything. While searching for
the elusive perfect set of messages, we are stuck with the old, pants set.

I'd very much like to fix this bug.

Gerv

Comment 64

17 years ago
Would anyone object to fixing Continue now while sean and mpt are busy making 
something which the rest of us will object to later? gerv: can you do that?
timeless: I don't quite understand what you mean. This bug is a) about the text 
strings and b) about making the current simple dialog into the more complex one 
specced by mpt. What's this "Continue" stuff? (Yes, I have reread the bug, and 
I'm still confused.)

Are you asking me to check in the C++ parts of the patch and fix the text 
strings later? It's hardly worth it, as the two are closely linked. Read the 
patch to see.

Gerv
(Reporter)

Comment 66

17 years ago
> This bug is a) about the text strings and b) about making the current
> simple dialog into the more complex one specced by mpt. What's this
> "Continue" stuff?

The bug is about the choices "OK" and "Cancel".  In 4.x the choices were 
"Continue" and "Cancel" and there was no confusion.  So that's what the 
"Continue stuff" is all about.

Comment 67

17 years ago
>I'd very much like to fix this bug.

What are you waiting for?

Unless mpt or somebody else has something further to say, I believe it's ready
to go. The text in the most recent patch reflects the direction of the interface
elsewhere toward the use of encrypt and encryption and has the support of the
module owner. For example, see 75906. Doubtless the wording can be improved
upon; let's get it into the builds and see what people say.

Note also that this bug now overlaps with 87134. The wording and identifier
changes in this bug are more consistent in terms of avoiding the vagueries of
"secure" and "insecure." Probably that bug should be marked as a duplicate of
this one.

Next step is submit your final patches for r, for example to javi@netscape.com.

Comment 68

17 years ago
All we are waiting for, and what we have been waiting for since 2001-05-20, is
an explanation from somebody of what MixedContentMessage is for. Could we have
that fairly soon, please? Javi? Lord?

By the time Mozilla discovers that an <img .../> element at the end of an
encrypted page is actually pointing to an unencrypted URL, most of the page has
already been loaded. However, John G. Myers said in his 2001-05-09 comment that
Mozilla does not currently give the user the choice of whether to load the
unencrypted items. So what, then, is the point of putting up that alert? What
are the user's choices?
On the subject of MixedContentMessage:
http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsSecureBrowserUIImpl.cpp#580
has, in function:

543 nsresult
544 nsSecureBrowserUIImpl::CheckMixedContext(nsISecurityEventSink *eventSink,
545                                          nsIRequest* aRequest, nsIChannel*
aChannel)

the following code:

575     // Show alert to user (first time only)
576     // NOTE: doesn't mSecurityState provide the correct
577     // one-time checking?? Why have mMixContentAlertShown
578     // as well?
579     if (!mMixContentAlertShown) {
580       AlertMixedMode();
581       mMixContentAlertShown = PR_TRUE;

So it seems others doubt whether we need this as well :-)

The current patch doesn't change the behaviour, so it can't make things worse.
It's fine for review.

javi? Could you review this, please?

Gerv
(Assignee)

Comment 71

17 years ago
r=javi.

Once you get a super-review, you can re-assign to me for check-in.

Comment 72

17 years ago
Moving all P3 and P4 bugs targetted to 2.1 to future.
Target Milestone: 2.1 → Future

Comment 73

17 years ago
removing nsenterprise keyword from PSM bugs with target milestone of future.
Keywords: nsenterprise
This bug is assigned to me, and I'll decide how quickly I'm going to fix it, 
thanks :-)

A mail was sent a while back requesting SR for this bug.

BTW, javi: I can check in my own code - I have CVS access.

Gerv
Target Milestone: Future → 2.1

Comment 75

17 years ago
Gerv, /security is a CVS module with restricted access. Only a few people, the
security people, have access to it.
Doh.

Gerv

Comment 77

17 years ago
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer

Comment 78

17 years ago
*** Bug 94731 has been marked as a duplicate of this bug. ***

Comment 79

17 years ago
adding patch, review to keywords. This only needs an sr and we should be able to
check it in.  UI freeze is coming up.
Keywords: patch, review

Comment 80

17 years ago
properties files support unicode encoding, a la \uXXXX. So instead of replacing
"#" with "\n", why not do it properly in the properties file?

Comment 81

17 years ago
*** Bug 95061 has been marked as a duplicate of this bug. ***
No-one seems to know which \u to use, and the Netscape UI freeze is coming up
so, out of politeness, we should try and get this in first.

I've pinged blake again about sr.

Gerv

Comment 83

17 years ago
\u000a or \u000d look promising. try both :-)

Comment 84

17 years ago
... or just CC yourself on bug 95697 and pray. ;)

Updated

17 years ago
Depends on: 95697

Updated

17 years ago
Assignee: gerv → javi
Priority: P3 → P1
Reassigning to javi for checkin, as requested.

patch by gerv@mozilla.org, r=javi, sr=ben.

Gerv
Checked in by javi.

Gerv
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
This caused topcrash bug 97044.

Comment 89

17 years ago
+Title=


Why?  Granted, Security Warning wasn't the greatest, but no title at all
certainly isn't an improvement.  Alerts should probably have a default of
brandShortName, but they don't yet, so please add a title.  It currently just
looks broken.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
blake:

mpt says, further up:

> ^no title? odd.

A deliberate workaround for one of the bugs in the nsIPrompt API -- alerts 
shouldn't have titles. (On Windows they should be titled with the name of the 
app, i.e. `Mozilla', but that should be done automatically by XP Toolkit and is 
a Different Bug.)

Gerv

Comment 91

17 years ago
Our toolkit isn't finished yet, and it doesn't yet do a lot of stuff that it
should.  That doesn't mean its bugs shouldn't be worked around (if it did, I can
assure you that some of our UI wouldn't be pretty).  So it can be handled in
this bug, or it can be handled in another bug, but this titleless alert is a
regression that needs to be fixed.
mpt: &brandShortName; or "Security Alert"? No, you can't have different things
on different platforms.

Gerv

Comment 93

17 years ago
->future
Target Milestone: 2.1 → Future

Updated

17 years ago
QA Contact: ckritzer → junruh

Updated

17 years ago
Blocks: 104166

Comment 94

16 years ago
Blake, you reopened this bug on 2001-09-01, but you didn't comment why.
Is this still an issue?
If it is, we should summarize what needs to be done.

Comment 95

16 years ago
Reading the comments more, Blake, I believe you disliked the fact that the
latest patch used an empty title. However, if I look at the current contents of
bug mozilla/netwerk/resources/locale/en-US/security.properties, the title is no
longer empty. So it seems, this bug is now fixed. Please reopen, if the reason
to reopen was something different.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 96

16 years ago
Verified.
Status: RESOLVED → VERIFIED

Updated

13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

10 years ago
Version: psm2.0 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.