This bug is to discuss what to do about "insecure form submission" dialogs / whether to do anything. Pros of warnings: - security-conscious users can use them to decide whether the information they are submitting is OK to send in cleartext. Cons: - most users do not know enough to make informed security decisions and will either be scared by the dialogs into never submitting, not using the web, or at least not using the browser or the sites where the dialogs come up. - the dialogs come up on search engines where the data you are sending is no more sensitive than any other click - the dialogs are ineffective at preventing sending of sensitive data to a non-secure spoofed site (bug 153875) Options: - disable form submission warnings by default (my preferred option) - remove form submission warnings altogether (bad because security-conscious users who disable JS can use the warnings effectively) - make the different form submission warnings keyed off of a single checkbox instead of multiple ("hey, I thought I clicked that warning off already?!!") - only send a form submission warning when there is a certain amount of data (this fixes "dialogs come up on search engines," which is a large part of the issue for me
Anecdote: a friend of mine (an engineering major at HMC) was searching Google with Mozilla while I was in her room. She told me the dialog was annoying, and that it came up whenever she tried to search Google. I asked her if she knew what the dialog said or meant, and she did another search to make the dialog appear again in order to read it. She misunderstood the part of the dialog that referrered a "third party", thinking it meant Google could see what she was searching for. After I explained what "third party" meant (approximate response: "so what?") and asked her to read the dialog again, she finally noticed the checkbox to make the dialog go away forever and unchecked it. What I got out of this incident: - The use of the term "third party" in the dialog text is questionable. - This dialog annoys people who are trying to search Google. They're in the middle of doing something, so at least some don't read the dialog and continue to be annoyed by it because they don't notice the checkbox. - Dialogs like this one might slow down users from switching to Mozilla, even if IE has a similar dialogs, because many users figured out how to make IE's dialog go away at some point. Here's a related thread from a few months ago: http://groups.google.com/groups?threadm=3D1BD7E2.4040805%40netscape.com In that thread, mpt suggested text for a one-time dialog that would appear the first time you tried to submit a form insecurely: "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?" I dislike the idea of keying all form-submit warnings off one checkbox. I think only one warning, the insecure-to-insecure warning, is common and annoying. The secure-to-insecure warning is much less common, and it can be useful because a user on a secure site probably expects the form to be secure as well. I'd like to eliminate the warning completely, or at least make it only appear once. The idea of limiting the warning to large forms is interesting.
Another anecdote A few years ago, while open source mozilla was still in its infancy, certain popular web server products could simultaneously be an http server and an https server for the same document tree in the same process. When a server administrator turned on SSL (https) access on one of these servers, http access to the same document tree was not automatically disabled. The result was that quite a few sites that used these servers were simultaneously serving the very same content securely on port 443 and insecurely on port 80. Some administrators of those servers began to complain to Netscape that Communicator users who used their sites were frequently getting warnings that IE users didn't get; namely, the warnings about posting insecurely from a secure page. The question being asked by those webmasters was "Why does Communicator think that the post is insecure? I'm sure it's posting securely. The form is on a secure page." (The most commonly held but mistaken belief about secure pages, held by users and server administrators alike, is that the security begins just before the page is sent to the browser and ends after the browser's response is sent back to the server. The truth is that the security begins before the https request for the secure page is sent to the server and ends when the server has sent the secure page back to the browser. The lock at the bottom of the window means only that the data now being displayed was all received over secure connections from authenticated servers. It does not mean that the data that may be sent from this page will be sent securely. The warning about insecure posts from a secure page exists to protect people with this expectation.) A brief investigation revealed that these webmasters had put http (not https) form actions into their web pages. Many of them believed, incorrectly, that putting an http action in a form on a secure page meant that the form data would be posted securely, but the page returned by the server in response to that post would be sent insecurely. They weren't being malicious. They were merely mistaken, and oblivious to their mistakes. Regardless of why they had put http actions into their forms, their users were posting their sensitive form data insecurely. IE didn't warn users about posting insecurely from secure pages, and these administrators' servers accepted the form posts both securely and insecurely. An IE user's session with that server would silently change from a sequence of secure pages to a sequence of insecure pages on the same server. A user's supposedly secure session silently became insecure. Almost nobody noticed. The webmasters were oblivious to their mistakes - EXCEPT for the complaints from Communicator users. Fortunately for those webmasters, the Communicator users complained to them about these warnings. When those webmasters learned of their form construction mistake, and learned how to correct it so that the form posts really were secure, most were grateful for the warnings that alerted them to their mistakes. You can find examples of this in google's usenet archive. Here are a few: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=c4a36e97527e54b&rnum=1 http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=c7ba9196d8bb4a21&rnum=4 http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=179d5ca25098ce6f&rnum=11 I do not know whether the current versions of those server products still behave that way, or not. But as long as the affected versions of those server products continue to exist, and server administrators continue to misunderstand the scope of https security, and users continue to expect that data posted from a secure page is posted securely, I think browsers should continune to warn users of insecure posts from secure pages. Disclaimer: I speak only for myself, not for netscape/AOL.
See also bug 154706 (reword these warnings) and bug 46590 (use heuristics to warn about credit card number submissions to insecure sites).
Nelson: I can almost see the usefulness of warnings from http to https or https to http. http to http though?
I'd like to get this in soon. Here's the compromise I can see: Disable by default for http to http, and http to https. Leave enabled for https to http since some users might care that they are sending that information cleartext and they have no other way of knowing that this will happen. This deals with Google and Hotmail and most other sites.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3beta
I recommend disabling http-to-https, but leave http-to-http form submit and https-to-http enabled. A warning that http submits can be eavesdropped is a good thing, even if many users don't read it, and it's easy enough to turn off.
I agree with Mitchell. (Sound the trumpets! :-) I continue to believe the https-to-http post warning should not be able to be disabled. (Is there a better way to say that?)
http-to-http is the major issue in the bug. https-to-http is just fine to leave around as a warning; it happens seldom and there is no other way to warn of that kind of thing. But perhaps there is a way to compromise on http-to-http too. As Mitch says, the point is to inform the user that some forms can be eavesdropped on. (Though if you really think about this, we should be popping up this dialog anytime you attempt to go to an http URL.) So let's make it so the first time you bring up the dialog (for a new user) it comes up with the value unchecked. Thus the many (I say most) users who do not read or understand the dialog will never be bothered with it again; and those who do, have a nice chance turn them on. And we have done our duty in warning the user that some forms they enter on the web can be eavesdropped on.
Can't selection of 'waring' 'no-warning' be combined with the security/privacy selections of popup/image/cookie? Then they can be turned on on a per-site basis
I agree with Ronald - being able to control this on a per-site basis would be best. I dont need the warnings for localhost or search engines, but there are sites which I use - such as some computer support sites - which have identical secure and insecure versions. If I am entering sensitive information into those sites then the warning reminds me that I need to go to the secure version of the site. This is similar to the case Nelson mentioned, but not really a bug as such in that often the information in a bug report is not that sensitive, but in some cases it might be. I would go for an extra checkbox on the dialog which says 'Never show this warning again for this site'. There should probably also be an extra tab on the Form Manager which allows form security warnings to be enabled again on a per site basis.
You need to log in before you can comment on or make changes to this bug.