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.

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.

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.

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!

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.

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.

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.

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.

Setting target fix to future.

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...

lord, you thoughts here?

I would suggest "Continue Anyway" instead of "OK".

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.

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.

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

This should never have been reassigned, as I was never consulted. It is considered inconsiderate to reassign a bug without contacting the previous owner...

OK, so what's the decision? 'Continue Anyway' or 'Continue' ?

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

Note related bug 32023.

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

PDT thinks this is a P4

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

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.

Marking nsbeta3- per PDT review.

Setting milestone to future.

No time for this right now.

changing QA contact to junruh@netscape.com

nsbeta1

Enhancement and Future.

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.

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

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.

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.

At first read, it looks like an improvement. Adding Cotter to the cc list.

could we be honest and replace 'could' with 'will'?

No.

I'm working on this :-) Gerv

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

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

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

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.

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

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?

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. ***

> 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.

> 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.

> ^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

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

>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

Mass reassigning target to 2.1

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

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

> 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.

>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.

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

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

Moving all P3 and P4 bugs targetted to 2.1 to future.

removing nsenterprise keyword from PSM bugs with target milestone of future.

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

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

Doh. Gerv

Mass assigning QA to ckritzer.

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

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

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

*** 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

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

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

Reassigning to javi for checkin, as requested. patch by gerv@mozilla.org, r=javi, sr=ben. Gerv

Checked in by javi. Gerv

This caused topcrash bug 97044.

+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.

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

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

->future

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.

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.

Verified.