267245 - Checkbox "Alert me whenever I submit information that's not encrypted." is not checked by default

Status: RESOLVED WONTFIX

(Firefox :: Settings UI, defect)

Description

[Constantine A. Murenin]

In the "Security Warning" dialogue, the checkbox "Alert me whenever I submit
information that's not encrypted." is unchecked by default.

This is inappropriate behaviour, which is not consistent with any other
well-written application, even with MS IE (AFAIA). In any case, user inaction
should not trigger such effects that could not be changed later, undermining
user's awareness of submitting information over unencrypted form. And as far as
I am aware, in Firefox there is no user interface that allows one to change the
behaviour back to status quo. 

This behaviour of not letting me know when I submit an unencrypted form
undermines my security, as in every new installation, should I forget to change
the checkbox to "always alert me" the first time, the checkbox is lost forever
from my UI, and there is no way for me, as the end user, to find it and change
it back to normal. 

Please, consider this bug seriously. Attempts to make Firefox more user-friendly
should know its limits, and such features, which even Microsoft does not employ
(AFAIA), will not do any good to mozilla.org products in the long run. A few
months from now, and MS IE is going to be a much more secure browser than
Firefox is, should we continue in this way of making the browser for dummies who
do not care about security. 

(Tested with Firefox 1.0RC1. )

Solution: to solve the problem, one must change the default value of
"security.warn_submit_insecure.show_once" and such to false (and leave
"security.warn_submit_insecure" and such as true, just as they are now).

Comment 1

[Mike Connor [:mconnor]]

The missing UI to re-enable this is a known issue, but didn't get fixed for 1.0.
 It should be in for 1.1.

This isn't a "polish" bug really, nor is it really a regression, since this
behaviour was implemented quite deliberately.  See Bug 172091 for more details.

Changing the user experience at this point is simply not going to happen, in any
case, at this extremely late juncture.  In the absence of any substantive
feedback from 0.8, 0.9.x, and 1.0PR/RC1, there simply is no justification for
doing so.  All of the issues you have raised were discussed when the change was
made, and we came to the current UI.

Since there is nothing new being raised here, and this behaviour is desired and
deliberate on our part, marking WONTFIX.

Comment 2

[Constantine A. Murenin]

Bug 172091 does not contain a thorough discussion on the advantages and
disadvantages of the mentioned behaviour. Contrariwise, most participants of the
mentioned bug express their concern of not having a warning message. 

I suggest setting the ".show_once" preferences to false, at least until there is
a proper UI to re-enable the warnings (as you, mconnor, suggested in the
mentioned bug, but the issue was never discussed). Although, I still think that
no UI can replace the acceptable and safe defaults, and I see no reason of not
having the checkbox checked on the appearing messages. 

Let us consider the problems two users face:

If the "alert me" is checked: 
 * User who does not want to see the message just unchecks the checkbox at any
time and holds responsible for any submission of unencrypted forms. He is given
time to decide for himself if he does not want the secure default. 
 * Responsible user is happy as the messages always appear. 

If the "alert me" is not checked:
 * User who does not want to see the message will never see it again. ("If you
are not paranoid, it does not mean that they are not watching you." :-) )
 * Responsible user new to Firefox may just assume that the message will always
appear (no-one reads the messages that they expect), and click continue.
However, the message will never appear again, and the user will never have a
chance to be warned about the submission of forms. User is not given much time
or options to correct his actions. He is only warned once, and should he miss
the warning, he will not be able to recover it. Clearly, that should not be
desirable nor expected. Moreover, this user is not going to be happy, and his
unhappiness will be of a greater quantity and extent than that of the first user
from the first case, as the first user is able to recover and this one is not.
Also, consider the unhappiness and security together: I think it is much better
to have a little bit unhappy but a secure user, than a very unhappy and insecure
user. 

I think that most people should agree with this argument. And the case that you
are not aware of any complains of the misbehaviour does not mean that there were
no such complains -- I filed this bug only a few months after I noticed the bug
(I assumed that it was already known and someone was going to fix it), I believe
others may hold the same position due to the nature of this bug. 

Thanks,
Constantine.

UPDATE: on the trunk (2004-11-03 mac build), the dialogue has no checkbox at
all, and because it is not checked and there is no way to check it, the dialogue
never appears again, after you click on Continue the first time. This behaviour
is surely not desired. Reopening the bug due to this and the previous argument. 

Comment 3

[Boris Zbarsky [:bzbarsky]]

> UPDATE: on the trunk (2004-11-03 mac build)

That's probably bug 267498.  Please update.

Comment 4

[Mike Connor [:mconnor]]

The bug actually fixed the fact that it ALWAYS was unchecked, and didn't
remember being checked, at least since around Phoenix 0.2.  Yes, a lot of people
weighed in to express their desire that we force users to uncheck the dialog,
those on the other side didn't care enough to argue the point since we were
going ahead with the plan.  The aviary peers were all strongly in agreement on
the point, so extended discussion and consensus was not looked for in the bug.

The key flaw in your argument is that you want to keep prompting the user until
they actually read the dialog in enough detail to uncheck the box.  The main
point is that if they're not going to read the dialog the first time, they're
not going to read it in the future either.  Thus, the repetitive dialogs are
actually rather irritating to users who don't read dialogs anyway (i.e. most
users).  The warnings in question are, IMO, less effective than clear
indications that the site is secure or not.  The yellow URL bar is a much better
reminder whether I'm on a secure site or not, which makes the dialogs unnecessary.

Keep in mind that the less we prompt the user, the more likely it is that
they're read a prompt if its really something important.

I also completely disagree with your conception of users who don't enable the
dialogs as irresponsible.  Just because I choose to be less paranoid doesn't
make me irresponsible.  You're also asserting that people should think like you,
which is a pretty bad way of arguing a point.

Again, nothing you're saying wasn't considered at the time, this was an ongoing
argument, in and out of the bug, and we reached a conclusion that we're happy
with.  Not everyone was, obviously, but the people making the decision were. 
Just because you don't feel like we made the right decision doesn't mean you
should reopen the bug.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> The warnings in question are, IMO, less effective than clear indications that
> the site is secure or not.

This particular warning lets you cancel the form submission before any form data
is sent to the site.  So it's a heck of a lot more useful than the other SSL
dialogs (on which I agree with your point).

Just wanted to make it clear that that's a key difference with this particular
dialog.  This is your call, and I'm not advocating that this needs to be
reopened or any thing.  ;)

Comment 6

[Mike Connor [:mconnor]]

That is certainly valid a point.  

The counter to that, which I wasn't particularly clear on, is that if I'm
concerned about submitting forms on insecure sites, I'm not going to even start
filling out the form if I'm not on a secure site.  If you wait until after to
realize its an insecure site, you've just wasted a fair bit of time, especially
on biggish forms.  

"Oh, by the way, this isn't a secure site, you still want to submit this,
right?" seems like a pretty poor concept overall, its better to present an
obvious indication whether or not a site is secure, and let the user choose the
actions to take based on that.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Mike, the point of this dialog, if implemented correctly, is to catch cases when
the site the _form_ is on is secure but the form's _action_ is insecure. There
is no way the user can catch this short of reading page source or something.

At the moment, we put up that dialog if either one is insecure.  Perhaps we need
to change that behavior such that the dialog would only come up when going from
a secure site to an insecure one?  Or perhaps we should put up a dialog in that
case no question asked, without the possibility to disable?  I can't think of a
reasonable situation in which that would happen...

Comment 8

[Boris Zbarsky [:bzbarsky]]

Ok, nevermind.  I just did some testing, and we do have a separate
(non-disableable) dialog for the secure-submits-to-insecure case.  So everything
is ok.

Comment 9

[Constantine A. Murenin]

(In reply to comment #4)
> The bug actually fixed the fact that it ALWAYS was unchecked, and didn't
> remember being checked, at least since around Phoenix 0.2.  Yes, a lot of people
> weighed in to express their desire that we force users to uncheck the dialog,
> those on the other side didn't care enough to argue the point since we were
> going ahead with the plan.  The aviary peers were all strongly in agreement on
> the point, so extended discussion and consensus was not looked for in the bug.

First, the end-user does not always know what he wants. Today he asks you not to
give him the warning dialogue, tomorrow he will blame you that someone stole his
credit card and he saw no warnings when he typed his card number on some web-site. 

Please, consider the following question from PuTTY FAQ
<URL:http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#QA.2.9>, "Is
there an option to turn off the annoying host key prompts?". I believe that the
problem is similar, and as you see, quite a few users have asked for a dodgy
solution, which the authors of PuTTY promised to never implement nor accept any
patches of the implementation. 

> The key flaw in your argument is that you want to keep prompting the user until
> they actually read the dialog in enough detail to uncheck the box.  The main
> point is that if they're not going to read the dialog the first time, they're
> not going to read it in the future either.  Thus, the repetitive dialogs are
> actually rather irritating to users who don't read dialogs anyway (i.e. most
> users).  The warnings in question are, IMO, less effective than clear
> indications that the site is secure or not.  The yellow URL bar is a much better
> reminder whether I'm on a secure site or not, which makes the dialogs unnecessary.

I thought about the yellow URL bar. The concept of the bar is quite new. Not
every user remembers or takes it for granted that if there is no yellow bar then
the form is most likely insecure. 

Please note, that the security/insecurity of the form does not directly follow
from the colour of the bar itself -- if one visits some online portal, let us
say yahoo, then the page itself is insecure, and all the forms on the page are
insecure, except for the login form -- the login form is in fact secure
(action="https://..."). Assuming that you don't show an alert dialogue, how
would the user know whether the action of the form is secure or not, on an
insecure page? He would know that only by viewing the source code, which is not
a very decent option for the end-user. 

> Keep in mind that the less we prompt the user, the more likely it is that
> they're read a prompt if its really something important.

Every programme in windows xp prompts the user with something not so important.
Some programmes (windows media player) prompt the user every time he minimises
the window, others do so every time the user tries to close the window. What
reasons do you have to believe that Firefox should be any different from the
standard programmes that come with the OS and/or other programmes that can be
downloaded for the OS?

In unix-like systems, KDE/Konqueror, lynx and other browsers always prompt one
if one wants to accept the cookie that a web-site provides. Alongside such
applications, firefox looks plain insecure and awkward by not letting the user
know that the form is submitted over an insecure connection. 

This causes firefox to be inconsistent with other applications in both windows
world and very clearly in unix world, which is never good. 

May I at least suggest to check the box by default on "alert me" dialogues in
unix builds (as opposed to windows builds, where an aggressive competition for
market shares exist)? 

> I also completely disagree with your conception of users who don't enable the
> dialogs as irresponsible.  Just because I choose to be less paranoid doesn't
> make me irresponsible.  You're also asserting that people should think like you,
> which is a pretty bad way of arguing a point.

In my examples, I never explicitly referred to any specific user as irresponsible. 

> Again, nothing you're saying wasn't considered at the time, this was an ongoing
> argument, in and out of the bug, and we reached a conclusion that we're happy
> with.  Not everyone was, obviously, but the people making the decision were. 
> Just because you don't feel like we made the right decision doesn't mean you
> should reopen the bug.

As you keep closing this bug, could you please inform us of the bug# for the
missing UI that is to be in for 1.1? Thanks. 

Comment 10

[Mike Connor [:mconnor]]

arguing that because we don't bombard users with dialogs we're perceived as
insecure is a pretty flawed piece of logic.  Note that the GNOME and Apple HIGs
expressly try to limit warning dialogs to the most extreme cases, which this
isn't.  The only truly useful warning is the "secure site submitting to an
insecure action" which cannot be disabled at all.

Just because dozens of Windows/UNIX apps have horrible UI does not mean we have
to follow suit.

I went to yahoo, and they have a "standard" and "secure" login page, and the
secure is an https:// site.  Having a secure login on an insecure page isn't my
idea of good site design.  In that case, would the dialog even fire since its a
"secure" action and therefore not something that can be easily seen?  A
concrete, real-world example would be good if you're going to use it as an example.

Ideally, secure forms should be on secure pages, not just work with a secure
action.  So if the page is secure, feel safe that its a secure form, and there
is a prompt that cannot be disabled if its an insecure action.  insecure->secure
is an iffy concept that good site design will avoid.  Plus, the warning only
happens AFTER you submit, so the only way to find out, from a user perspective,
is to fill out a form on a secure site, and submit it, and if they get a
warning, abort?  That's a terrible burden for a user and a huge timewaster.

Comment 11

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change