436200 - No pref to turn off insecure-submit-from-secure warning dialog

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, enhancement)

Description

[Jennifer]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0

I'm seeing this issue pop up when trying to load a "frequent trip" that's already defined. I make my selection from the dropdown menu and submit, and the error pops with no way to turn it off - I've changed all the security.warn Booleans in about.config to false and unchecked all the "show this error" boxes in the security prefs UI.

Reproducible: Always

Steps to Reproduce:
1. Load sample URL above
2. Attempt to submit an item using frequent-trips dropdown menu
3. Warning appears on submission despite prefs set to NOT show any warnings



It appears that the browser checks that the submission is to an http page from an https page. I trust this domain, and perhaps a good way to maintain a balance of security and simplicity would be to add a checkbox to the error of the type "Don't show again for this domain", similar to the way the password 'keychain' can be set to never prompt on particular domains.

Why is this message defeating the "don't show warnings" selections in the config file?

Comment 1

[Daniel Veditz [:dveditz]]

Unlike the other errors which are really just telling people the way the internet works, this is considered a potential security problem. If the content of the page (or the account authentication used to load it) were important enough to secure with encryption then connecting to an insecure page could be leaking important information, cookies, or credentials. Or not (an offsite search box, for example), but there's no real way for the browser to know so it warns and gives users a chance to cancel the submit if the form contains private data.

security.warn_submit_insecure covers the fact that 10 years ago most people didn't realize every load and every form submit was by default readable by anyone. It's still an option to turn on, but by default Firefox no longer warns users about that.

I can confirm that this bug happens, but I'm pretty sure this is still a WONTFIX since I don't think we've changed our position. I'll leave that up to the security UI guys though.

Comment 2

[Jennifer]

This is not 10 years ago, and there are lots of us out there, like me, who are driven crazy by this message and want a way to remove it, even if it doesn't have a GUI and has to be done in the prefs file. 

Comment 3

[Kai Engert [:KaiE:]]

Maybe you trust the domain owner, but you don't want to trust the people who are able to sniff your network connection. When being on a secure site, submitting to an insecure site could submit session cookies, etc.

IMHO this is still WONTFIX.

Comment 4

[Jennifer]

Maybe I trust the domain owner and I know what I'm doing with setting up networks and the networks I use and I don't use Joe Sixpack's Unsecured Wifi On Bob's Road. IMHO this needs a fix. Try searching Google and you'll find a number of complaints that never got submitted as actual bugs before I got fed up.

Comment 5

[Kevin P. Rice]

Attachment: Security Warning dialog appears upon insecure form submit from HTTPS

Comment 6

[Kevin P. Rice]

Attachment: All security warning options are disabled

Comment 7

[Kevin P. Rice]

Attachment: about:config warnings are disabled

Comment 8

[Kevin P. Rice]

I have created a simple test case here:

https://camrac.com/insecure_submit.html

There MUST be a way to disable this warning! This is not a situation of untrusted or insecure web sites--many sites use HTTPS for login or shopping, but also use insecure forms for benign data.

Making this WONTFIX is stubborn--there are plenty of complaints about it. A particular vendor site I use causes this warning every time I do a part search. It makes Firefox UNUSABLE for this web site. It doesn't matter if the site is poorly designed--the entire WWW is poorly designed!

This warning needs a means to be disabled, either globally, or per site.

Comment 9

[Johnathan Nightingale [:johnath]]

So, there's no question that this situation represents a risk to users.  Jennifer may have her network set to "magically unspoofable and immune to as-yet-undisclosed DNS vulnerabilities" but there is still profoundly no assurance that an http site is who it claims to be, and the trust you have in the destination site plays absolutely no role in the threat calculation.  The otherwise-legitimate sites who code things this way are putting their users at risk and teaching them bad habits wrt security dialogs.  I'm not sure how anyone can disagree with any part of that.

BUT

Warnings are there as a service to the user, these users are clearly not being served, and broken sites exist out there.  I don't think that "some people complained" is a good test for things we should include and maintain in our codebase, but I also don't think this is WONTFIX, because personally, I would take a small, clean, maintainable patch that added an about:config-only option here (with appropriate tests).  I mean, done right, you'd want to think this was like, 6 lines plus tests.

I don't think exposure should be given to the pref, but just like our SSL error prefs, I think there is a case to be made for giving users a way to say "I'm a weird case here", and given the way that alert code works (IIRC), it's not the most amenable to solving in an addon, which would otherwise be my preference.

So not WONTFIX in my opinion, just patch-wanted.  Arguably a good first bug.

Dan, Kai, am I way off-base here?

Comment 10

[Jennifer]

Hey, I don't think there is any need to make fun of me and whether or not I'm sure the site in question is safe. I'm running into this when I am sure and have checked the certificate but still can't get rid of the annoying dialog.

So, I think a good way to handle it might be to put a per-site exception in -- that expires if the certificate changes. Make the user go through an extra step so that the certificate gets looked at (sort of like you do with expired certs), to make it hard to add it, but make it addeable all the same.

Then, when the certificate is changed, have the dialog come back with warning text like "You are seeing this warning because the certificate for this site has changed." and prompt to go through verification again.

If it works for self-signed etc. certs, I can't see why it can't work for this.
This is also not my first-ever bug report on this site...

Comment 11

[Johnathan Nightingale [:johnath]]

(In reply to comment #10)
> Hey, I don't think there is any need to make fun of me and whether or not I'm
> sure the site in question is safe.

I'm sorry if it came off that way, but when you responded to Kai with:

> I don't use Joe Sixpack's Unsecured Wifi On Bob's Road.

...you seemed to be advancing the opinion that your network's safety was sufficient to obviate the risk here.  My response was intended to communicate that you could have your network set up with genuine certified magic and still not be safe here, since the spoofing issue is not localized to your network.  If it communicated any derision, please accept my apologies.  I think you'll agree that the rest of my comment was about the fact that your concern may be legitimate, despite the fact that you're still at risk. 

 
> I'm running into this when I am sure and
> have checked the certificate but still can't get rid of the annoying dialog.
>
> So, I think a good way to handle it might be to put a per-site exception in --
> that expires if the certificate changes. Make the user go through an extra step
> so that the certificate gets looked at (sort of like you do with expired
> certs), to make it hard to add it, but make it addeable all the same.

The problem here is not tied to the certificate, though.  Everything's fine when they are presenting the certificate, the problem is when you submit information to a site without a certificate (http).  So I don't think verifying the certificate buys you anything, your gmail login/shopping cart/tax information is still free for the taking/modification the instant that the form submission travels over unencrypted wires.

> If it works for self-signed etc. certs, I can't see why it can't work for this.

I hope I might have made that clearer above - if there was any kind of certificate at all at the end of this connection, what you describe would be part of the solution, but the risk here is that your information is being passed off to a page with no encryption, identity verification, or tamper-proofing.

> This is also not my first-ever bug report on this site...

Then I definitely don't want you leaving with the impression that people here are making fun of you - people reporting bugs and earnestly trying to find solutions are an important part of what makes mozilla great, and I appreciate your efforts here.

Comment 12

[Jennifer]

No offense was intended, apologies all around to anyone who took any. I must have had a bad day, which isn't intended as an excuse, when I posted that... bah.

Anyway, you have a point about the certificate not making a difference here -- oops, what a basic mistake to make. Since that isn't a factor, what about the possibility of clearly displaying in the dialog where the submission is going, and making any exceptions last only for that submission location/method on that given server? that is, if there is any change in where the data goes, re-warn.

Comment 13

[Kai Engert [:KaiE:]]

In my opinion the current behavior should be kept.

A site that identifies itself as secure, and then submits data from that page to an insecure site seems a very dangerous flaw in a site's design. Giving the user an impression of being secure, and then not using any security for form data, sounds very bad to me.

In my opinion this bug is wontfix.

In my opinion it should not be possible to turn this off globally.
Maybe one user is fed up because one site they visit is broken, and has good reasons to turn it off for that site.

But turning it off globally, and losing this warning for other sites seems problematic to me. A site specific override, ok, but not a global one.

Please. if you get such a warning, put pressure on the people who operate the site, and make them aware how badly broken their site is.

Comment 14

[Jennifer]

(In reply to comment #9)

I also don't think this is WONTFIX, because personally, I would
> take a small, clean, maintainable patch that added an about:config-only option
> here (with appropriate tests).  I mean, done right, you'd want to think this
> was like, 6 lines plus tests.
> 
> I don't think exposure should be given to the pref, but just like our SSL error
> prefs, I think there is a case to be made for giving users a way to say "I'm a
> weird case here", and given the way that alert code works (IIRC), it's not the
> most amenable to solving in an addon, which would otherwise be my preference.
> 
> So not WONTFIX in my opinion, just patch-wanted.  Arguably a good first bug.

I agree 100% with fixing it this way. Some sites aren't going to change no matter what, and keeping the pref unpublished will make power users (who are the least likely to have problems) happy while most people will still get the warnings.

Comment 15

[Kai Engert [:KaiE:]]

The problem is that often HOWTO sites publish information like "in order to avoid this warning, change this pref", and annoyed users might find and use this hint, not understanding that they lose their protection on all sites.

Comment 16

[Johnathan Nightingale [:johnath]]

(In reply to comment #15)
> The problem is that often HOWTO sites publish information like "in order to
> avoid this warning, change this pref", and annoyed users might find and use
> this hint, not understanding that they lose their protection on all sites.

I agree, they do.  I think I'd be just fine to see this warning be site-specific, but I think we should be careful about assuming that we can fix behaviour with technology.  What we want is for Firefox to protect users as much as possible without their involvement.  If they choose to get involved, go to undocumented config panels to switch cryptic-sounding toggles in order to turn off a dialog, it's pretty clear to me that they weren't benefitting from the dialog in the first place.

Again, I don't like the idea of turning it off, I wouldn't turn it off, I would advise other people not to turn it off, but I think those are not the same discussion as whether turning it off should be an option in the first place. And as I said above, I think this would be an easier WONTFIX if the code that displays that dialog was more amenable to modification in extensions, but I don't believe that it is.

Comment 17

[Jennifer]

I don't think the average user is saavy enough to think to look for a hint, and might be deterred by the hassle of editing the config file... especially if the override was required specifically for each site.

Also ... We want the browser to protect the user, not bog them down in annoying dialogs or cause the user pain when it's the site owner who's at fault. "Bug site designers to fix their site" works in an ideal world, but sometimes all the nagging in the world does nothing, and the user is still paying the price with annoying dialogs that -- as has been shown by Vista's endless nagging dialogs -- just wind up being clicked to make the system shut up and just do what the user asked in the first place. I, and everyone else here (most likely) know when a site is likely trustworthy, know how to secure their networks to prevent MITM attacks, etc. etc., but the average user may just wind up thinking the software just gets in their way and just clicks OK.

There has got to be a compromise that keeps power users happy but does something to protect average users, and saying "not gonna do anything about it" to an issue with numerous complaints doesn't really address that, I think...

Comment 18

[Johnathan Nightingale [:johnath]]

(In reply to comment #17)
> Also ... We want the browser to protect the user, not bog them down in annoying
> dialogs or cause the user pain when it's the site owner who's at fault. "Bug
> site designers to fix their site" works in an ideal world, but sometimes all
> the nagging in the world does nothing, and the user is still paying the price
> with annoying dialogs that -- as has been shown by Vista's endless nagging
> dialogs -- just wind up being clicked to make the system shut up and just do
> what the user asked in the first place. I, and everyone else here (most likely)
> know when a site is likely trustworthy, know how to secure their networks to
> prevent MITM attacks, etc. etc., but the average user may just wind up thinking
> the software just gets in their way and just clicks OK.
> 
> There has got to be a compromise that keeps power users happy but does
> something to protect average users, and saying "not gonna do anything about it"
> to an issue with numerous complaints doesn't really address that, I think...

Well now, having said that, we should be clear on a couple of points.  First off, Kai is a guy who is incredibly responsive to difficulties users have with our security code, so I wouldn't want you to leave with the impression that he is just not caring, or resisting change on principle.

His objection, which I totally understand, is that users who turn this off might not understand what downstream effects it has, and that letting them do so encourages them to make a decision they are likely ill-equipped to make.  When you talk about "knowing how to secure their networks to prevent MITM attacks" I think you hit something interesting.  No one I know knows how to secure their network against MITM attacks on http sites (the issue in question here).  If you're connecting to the open web and a secure site is downgrading from https to http through bad site design, your information is likely at risk.  The annoyance the dialog poses is the kind of thing that might warn a site designer to clean up their act.

So yeah, I still think that a mechanism for this is not implicitly WONTFIX, but neither am I in any rush to expose it.  If someone comes along and attaches a patch it can go through the motions.  I am unlikely to personally write it any time soon though, as I'm afraid there are other things vying for my cycles, such as they are.  I suspect Kai is similarly over-committed already.

Comment 19

[Kevin P. Rice]

Please let me chime in again-- Please know that I understand the security concerns. I would not be in favor of a global exception if there was time to develop a better (site specific) solution. But without either, I simply must use IE where this problem occurs (see below).

For ease of development, what about a checkbox in the error message: "Do not notify me again for this tab." This way, a full-featured exception list for a site-specific solution would not need to be developed. I could deal with seeing the message only once per session. OPTIONALLY: A change in domain (FQDN, or possibly TLD) in that tab could possibly also reactivate the warnings.

The site I have this problem with is a very large computer parts distributor. As their customer, I log in on an https form. However, after loggin in, my part inquiries are submitted via http which return parts inventory lists. EVERY part inquiry causes the warning (very annoying, so I use IE on that site). The data being passed is by no means sensitive like a password, thus, there is no real sense to me that the site is "broken". Truly sensitive data is handled entirely via https.

Of course the browser can't tell what data is appropriately sensitive or not, and https signals everything is secure, thus users SHOULD BE WARNED when http submissions are made from a secure page (although, honestly, I don't think my mom would recognize a non-secure page anyway so you could argue a warning should occur for ANY data submission). I don't feel that protecting your product's users from themselves is a fully valid argument because you simply cannot hand-hold everyone through the wild WWW via dialogs and warnings each and every click.

BOTTOM LINE: There are site designs that trigger this warning that I really wouldn't consider "broken" but the end-user should definitely be warned when it occurs so they can make a choice. There are enough complaints to validate that Firefox significantly impairs usability for many users in regards to this, and that the only solution for sites where this is pervasive and repetitive is to not use Firefox--IE doesn't warn, and Chrome presents a red "https" with a slash through it in the URL.

SOLUTIONS:

(1) A full-featured per-site or per-URL exception list.
(2) Display a red tool-tip, balloon, background or "open lock" icon over or near an offending form submit button and/or data fields contained.
(3) Add a checkbox to the warning to disable further warnings for this session/tab/domain.
(4) Consider what Chrome is doing for the same situation (red, slashed-out "https")
(5) Global about:config disable option.

Thank you all for looking at this usability issue.

Comment 20

[Johnathan Nightingale [:johnath]]

(In reply to comment #19)
> Please let me chime in again-- Please know that I understand the security
> concerns. I would not be in favor of a global exception if there was time to
> develop a better (site specific) solution. But without either, I simply must
> use IE where this problem occurs (see below).
...
> The site I have this problem with is a very large computer parts distributor.
> As their customer, I log in on an https form. However, after loggin in, my part
> inquiries are submitted via http which return parts inventory lists. EVERY part
> inquiry causes the warning (very annoying, so I use IE on that site). The data
> being passed is by no means sensitive like a password, thus, there is no real
> sense to me that the site is "broken". Truly sensitive data is handled entirely
> via https.

I don't think more examples will make things go any more quickly here, but fwiw, the type of bad site design you describe here probably IS leaking sensitive data, in that it's probably not using HTTPS-only cookies, and hence every insecure part search is leaking your logged in session cookie, letting anyone else pretend to be you, access past orders, maybe even place new orders. They should fix their site, they are likely putting their users at risk.

In any event, the specifics are not really at issue here. As has been mentioned above, most of the sites that cause Firefox to display these dialogs are a genuine risk to their users.  That's not really the question.  The question is whether users in the edge cases should be able to volunteer to not be told about this legitimate, non-theoretical risk because their usage habits involve sites that, for some reason, cannot be repaired.  It sounds like you're agreeing with that sentiment, which is great, but more advocacy isn't what is required here.  A tightly written, well-unit-tested patch is.

Comment 22

[Daniel Veditz [:dveditz]]

Pretty sure Kai isn't going to do this so resetting the assignee.

One legitimate use for an insecure form on a secure page is sometimes something like a 3rd-party search form where the data really doesn't matter. The problem is that Gecko can't tell the difference when such a form from a secure site may or may not be leaking information so it always warns. One option would be to limit the warning to password forms (always wrong), but it might be a purchase form with credit card info. Best to make this a no-UI option that users who are really, really bothered can set, and let the vast majority of people who use the default setting provide a kind of "herd immunity" against stupid bank sites and hope the remaining sites are less consequential.

Comment 23

[Mike G]

I don't know which is more annoying: broken software, or deliberately dense developers.

Reading some of the comments on here makes me want to throw my monitor out the window.  Users are *ANGRY* about this issue.  Just read some of the discussions that many have made regarding this topic.

I understand why the message appears, however, we are not asking to remove the message in the default view, we are asking for the ABILITY to disable the messages if we want to.  There are many sites out there that bring about this message.  Many of which we need to use daily, and it is out of our hands to ensure that the web developers design the sites to avoid this message from appearing.

Clearly something is broken, as this is a security type of message.  Yet, the options which control security messages do *NOT* contain a way to disable it.

Firefox is the ONLY web browser out there that has this problem.  Not IE, not Chrome, not Safari, not Opera, JUST Firefox.  That is most definitely a YP, a "Your Problem" Firefox developers.  We the users, are asking, no BEGGING you to fix this bug.  It IS enough to drive us to use other browsers.

Just fix it already.

Comment 24

[Kevin P. Rice]

Ditto.

Ideally there would be warning with a "per site" disable. Less ideally, a "per session" disable.

Until that can be written, PLEASE provide a global disable.

Thank you.

Comment 25

[Johnathan Nightingale [:johnath]]

(In reply to comment #23)
> I don't know which is more annoying: broken software, or deliberately dense
> developers.
...
> Just fix it already.

Patches accepted. Discussion of alternative technical approaches to resolving the difficulty would also be welcome.  Tantrums and ultimatums can go somewhere else.

We're an open source project with a lot of bugs that need attention - and we work on as many of them as we can because we want Firefox to be a great browser and we want the internet to be a great place. It's helpful to have people help us when we don't understand a problem they're encountering, but that's not the case here. So pick up a text editor and write a patch, or find someone who can, or understand that we are a resource-constrained community, and that yelling at people results in us having less time available for working on things, not more.

Comment 26

[Mike G]

^I understand that, however, the suggestions made by several posts in this discussion to not fix this problem creates a major reason for concern for those (and there are many) who are annoyed by this bug.

The ultimate solution to this problem is to approach it the way other browsers do.  They all provide a way to prevent future occurrences of this message from appearing.  Adding a toggle in the UI would work.  At the very least, adding an entry in the about:config to allow advanced users the ability to disable this warning would be sufficient as well.

Comment 27

[Kevin P. Rice]

It's the equivalent of Vista's UAC. I do hope the resources to address it will become available.

Comment 28

[Mike G]

Has there been any update regarding this issue?

Comment 29

[Patrick Lightbody]

A quick note on this whole debate: it appears that this prompt still cannot be
disabled by even a setting in about:config. I know there are some here that
think there should be no reason to ever disable this warning, and perhaps they
are right for normal human users.

However, the work I do is with browser automation (see http://seleniumhq.org
and http://browsermob.com) and this issue is a real pain in the butt. I
strongly urge the powers that be to add an option to suppress ALL modal dialog
boxes, if only for the sake of testing and automation purposes.

Comment 31

[Phil Parker]

I keep getting this popup:

 Although this page is encrypted, the information you have entered is to be 
 sent over an unencrypted connection and could easily be read by a third 
 party.

 Are you sure you want to continue sending this information?

Moreover, it occurs ONLY for ONE page in ONE site, namely the status
confirmation page in my university's off-site logon security verification,
which merely says "You've been verified. Click to proceed." NO information is entered, or can be entered, on that page!

How is this a WONTFIX security problem? Nonstandard certificates make sense, but this one is insane.

How can I turn it *OFF*? Permanently!

It's annoying as hell since I have to click on it many times daily.

How about a new category of bug: annoying as all hell but not critical; browser works but user is infuriated, destroys machine, commits suicide.

Comment 32

[Sash]

I get the same message with a specific website with Firefox and Camino, so it must be in the common code.
Neither Safari nor Google Chrome browser show the message with the same site.

Comment 34

[Josh Triplett]

For the benefit of anyone currently bothered by this issue: you might find HTTPS Everywhere useful as a means of fixing the problem.  You could create rules which force all requests to a domain to go through https, which should then prevent the warning (and also improve your security).

Comment 35

[Christian Kujau]

While HTTPS Everywhere is great, the original report asked for a pref to turn off the "Although this page is encrypted..." message. I too want to disable the message, for the following reasons:

* Currently trying to login to https://wordpress.org/support/ - while the URL says
  "https" we can see that they're loading plenty of stuff over http. Yet I *really*
  want to login. And I also want to have my password stored with Firefox. But a
  splitsecond after the "Remember password?" dialog appears, it vanishes to make
  room for the "Although this page is encrypted..." overlay. There's no chance for
  me to agree to both: "yes, submit my information insecurely" and "yes, store my
  password".

* While the "Although this page is encrypted..." dialog is very prone to click
  fatigue (user will just click "continue" anyway or file bugs like bug 654914),
  it also defaults to "continue". Accidently hitting ENTER twice to submit 
  the login credentials will make Firefox submit information over an 
  insecure channel.

Changing the default to "cancel" could be handled in another bug. But I am _really_ aware that wordpress.org (or any other site) does things wrong but I still want to login and store the password with Firefox.

Please reconsider and make this a (hidden) preference.

Thanks.

Comment 36

[John]

My story:
I'm visiting cisco website over https and then I get redirected to pages with some information about networking (just study materials). And firefox complains at this point about materials going to me unencrypted. I DO NOT CARE. nor does cisco that wikipedia-like pages that i'm viewing may be seen by someone else.

I have to close this error message every time after login. sometimes several times a day.

Solution:
We just need a whitelist with wildcard symbols supported to be able to define URLs for exception.
exception rule like this would work for me:
https://*.netacad.com/courses/*
------
off-topic:
this reminds me off microsoft non-signed video card drivers that I got for Win7 with the purchase of my PC. signed ones on the internet didn't work for me. and because i can't just tell windows that "i know what i'm doing, just be quiet and trust these drivers" i'm forced to start my pc with F8 pressed for the rest of my life, just to select "disable driver signature enforcement" option.

Firefox is already on 19 version... oh firefox, you have made a level up again. but the nanny feature is still there.

Comment 37

[Bruno]

I am currently working in a big international company using an intranet tool made by HP company. Firefox is 10 times faster than IE or Google Chrome with this website.  Unfortunately I have constant warnings popping up all the time because the so-called security risk.

It is an intranet, nobody can access the network from outside of my company. More, we have dozen of firewalls protecting it.

The only solution I have for the moment is to use another browser and there is no way for me to have any chance to promote the use of Firefox inside of my company if I cannot deactivate the warnings.

Comment 38

[Kai]

I see this is listed as "wont fix" but wondering if an exception can be put in for intranet sites or a trusted site.

My intranet has a self-signed certificate that then gives the annoying pop-up warning before I switch to our ERP application (AMS Advantage) which is also on our intranet.

So, far, FF is the only browser on my system (Win 10) that actually works with the application - I've tried IE, Chrome, and Edge.

Comment 39

[McCoy]

Still getting   "The information you have entered on this page will be sent over an insecure connection and could be read by a third party".

Comment 40

[Roger]

Still getting:

"The information you have entered on this page will be sent over an insecure connection and could be read by a third party.
Are you sure you want to send this information?
Continue Cancel"

Stupid warning.
Nobody wants it.
Nobody clicks "Cancel", other than to Google what the hell this message is about.
After that, everyone thinks: "What a bloody waste of time."

I just switched to Windows 10 and Firefox.
Now back to Chrome.

Comment 41

[Mike Kaply [:mkaply]]

I'm going to add a preference for this. The world is different now, most sites are https and the people that need this, still need this.

It will be in about:config only.

Comment 42

[Josh Triplett]

The world is also different now in that there's a much stronger need to avoid insecure sites, and there are more security threats caused by XSRF, and specifically things like posting forms from the web to intranet services. Is there some way that, rather than the preference disabling the prompt entirely, it could list either specific sites or specific ranges of addresses to allow submits from/to, to address the specific use case people have for it?

Comment 43

[Mike Kaply [:mkaply]]

Attachment: Bug 436200 - Add a pref to turn off warning submitting secure to insecure. r?dveditz,pbz

Comment 44

[Daniel Veditz [:dveditz]]

Back when https was only used by important sites like banks a full modal dialog block made a lot of sense. That's not the internet of today. If a lot of people were hitting this modal dialog it might be worth the effort to craft a better warning that didn't block submission. Chrome's "degraded lock" that treats it like a mixed image is too subtle; maybe something in the style of the warning we show for passwords on insecure pages would work.

In practice this pref is currently useful mostly for intranet sites. Anyone with a public site will still need to make their site work for the vast majority of Firefox users who won't flip this pref. The users who do flip the pref will be at increased risk on public sites without a warning, but can somewhat rely on "herd immunity" of site authors not doing it if it's going to annoy most Firefox users. Would be nice to have some telemetry on how many people flip this pref because if a lot of people are doing it then it definitely becomes worth the effort to develop a better warning.

I was initially concerned that the patch moved the pref check and bail-out to the top of the check, because then we can't even post a warning to the web console. But on further reflection who would such a warning serve? Users aren't going to look, especially if the pages are "working". Developers are most likely using a Firefox with default values and won't need the warning because they'll see the modal block.

Comment 45

[Daniel Veditz [:dveditz]]

Filed an enhancement bug 1654046 on changing the modal block to an in-page warning by default. We'll see if anyone wants to run with that.

Comment 46

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ddeba39cb6da
Add a pref to turn off warning submitting secure to insecure. r=dveditz,pbz

Comment 47

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/ddeba39cb6da

Comment 48

[Mike Kaply [:mkaply]]

Comment on attachment 9164187 [details]
Bug 436200 - Add a pref to turn off warning submitting secure to insecure. r?dveditz,pbz

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Enterprise specific usecase.
• User impact if declined: No impact to users, admins unable to turn off prompt.
• Fix Landed on Version: 80
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Automated tests.
• String or UUID changes made by this patch:

Comment 49

[Julien Cristau [:jcristau]]

Comment on attachment 9164187 [details]
Bug 436200 - Add a pref to turn off warning submitting secure to insecure. r?dveditz,pbz

approved for 78.2esr

Comment 50

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/48174c4ae8ee