Disable form submission warnings by default

Assigned to



16 years ago
9 years ago


(Reporter: john, Assigned: john)



Firefox Tracking Flags

(Not tracked)




16 years ago
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.

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

- 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

Comment 1

16 years ago
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:

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

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:


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.

Comment 3

16 years ago
See also bug 154706 (reword these warnings) and bug 46590 (use heuristics to
warn about credit card number submissions to insecure sites).

Comment 4

16 years ago
Nelson: I can almost see the usefulness of warnings from http to https or https
to http.  http to http though?

Comment 5

16 years ago
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.
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?)

Comment 8

16 years ago
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.

Comment 9

16 years ago
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

Comment 10

15 years ago
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.
QA Contact: bsharma → toolkit
You need to log in before you can comment on or make changes to this bug.