Closed Bug 341472 Opened 15 years ago Closed 14 years ago
ship with fewer security warnings showing by default
30.45 KB, image/png
30.08 KB, image/png
2.57 KB, patch
|Details | Diff | Splinter Review|
The initial experience with Firefox - and indeed any new browser - is often encumbered with security warning dialogs which have one of two effects: 1. experienced web users click through them as quickly as possible 2. inexperience web users get scared by them, and ask a friend, who tells them to ignore them Perhaps counter-intuitively, reducing the set of actions that produce warnings to ensure that they're only shown for truly risky behaviour might yield results closer to the actual intent of these warnings, which is to say, that people read them and heed their advice. I suggest that out of the box, we only show warnings for: - I am about to view a page that uses low-grade encryption - I'm about to view an encrypted page that contains some unencrypted information These warnings should also be re-worded, and I'll file more bugs about that a little later tonight to try and get better wording in before string freeze. (Targeting at beta 2 since I think this is a decision we make for the user that doesn't need as much testing feedback, and it's pretty low risk in terms of patching.)
I agree with the premise of this bug. Limiting the dialogs to the most critical and least commonly occuring cases should help encourage people to actually take notice of them when they matter most.
I'm fine with these changes. The warnings for entering/leaving https were silly. The warning for submitting forms over http is misplaced -- I think that information should be part of a "staying secure on the Web" page that we encourage users to read, not squeezed into a dialog that gets in your way the first time you do a Google search. (We could link to that page from the first-start page, the Help menu, and/or the Security panel of the Options dialog.) We should consider making the other two currently-optional warnings (http content within https page, low-grade encryption) default-deny instead of default-ask. I hear IE7 is going to do that with a lot of crypto-related warnings. Btw, is this window under "options > security", under "options > advanced > encryption", or somewhere else?
(In reply to comment #4) > Btw, is this window under "options > security", under "options > advanced > > encryption", or somewhere else? Options > Advanced > Security > Configure Security Warnings (only in 1.8.1 branch and higher)
That's where it is now, but bug 340677 has it moved to Options > Security, which seems strange.
The "Configure Security Warnings" button is planned to move to a new top level "Security" pane that will be used to house options about browser functions that are meant to protect a user while browsing the web; encryption options are left in advanced as they are about the technical underpinnings of the HTTP security model than the warnings and user-facing features we ship with. Any discussion about this, though, should be made on bug 340577, really :)
I brought that up because if all 5 warnings go away by default (3 default-accept, 2 default-deny), those warnings are suddenly a lot less "user-facing" ;)
Comment on attachment 229054 [details] [diff] [review] patch per beltzner's comments I think this is the right thing to do, since the messages are pretty useless and aren't actually educating users to the potential security problems. An even better solution would be to make the messages useful, and help users understand how to maintain their personal safely on the web. Chris Beard worries that by turning them off by default, it will be harder to ever turn them back on. I'm going to cc him on the bug and get final word from him, but I do firmly believe that this is better than what we've got at the moment.
Attachment #229054 - Flags: ui-review?(beltzner) → ui-review+
Comment on attachment 229054 [details] [diff] [review] patch per beltzner's comments -pref("security.warn_submit_insecure", true); +pref("security.warn_submit_insecure", false); This change worries me a bit. I think the browser should help protect me against sending sensitive information in plaintext. I agree that the current security dialog for submitting a form over an insecure channel is the wrong solution, but given that it is the only way we have to inform users about the dangers of doing so, I worry about removing it. Can we do something better for FF2?
Attachment #229054 - Flags: review?(darin) → review+
What's the word on this, beltzner? Should I make a new patch that leaves on warning users when they submit an insecure form? This change was targeted at FF2, so..
> -pref("security.warn_submit_insecure", true); > +pref("security.warn_submit_insecure", false); > > This change worries me a bit. I think the browser should help protect me > against sending sensitive information in plaintext. I agree that the current > security dialog for submitting a form over an insecure channel is the wrong > solution, but given that it is the only way we have to inform users about the > dangers of doing so, I worry about removing it. The insecure-submit-from-secure confirm cannot be turned off, this is the generic "The web is insecure" warning people get on their first Start Page (Google) submit.
So it sounds like we want to keep the "warn when submitting an insecure form" warning enabled by default. If I make a new patch is this something we're willing to take for Firefox 2?
> keep the "warn when submitting an insecure form" > warning enabled by default. If you do make sure you keep the corresponding "show once" pref set to true so we don't annoy people to death. I'm personally fine with the current patch since it doesn't turn off the warning that really matters (secure page submits to insecure URL), and despite misgivings Darin gave this a plus also.
This probably should be a separate bug report, but: A better approach for non-secure submissions would be a non-modal warning when you *start* entering data in the form, not when you've finished. (For example, a panel sliding up from the bottom of the viewport: "Just in case you didn't know: Anything you enter in a non-secure Web site, like this one, could be spied on. So don't enter private information (like your credit card number) here, only on other Web sites where Firefox shows a padlock in the toolbar.")
ispiked: think you can attach a patch for this without the warn_submit_insecure change?
Here's a patch that's updated to everyone's comments. It boils down to one change: people are no longer warned when entering or leaving a secure site.
Target Milestone: Firefox 2 beta2 → Firefox 3 alpha6
Version: 2.0 Branch → Trunk
Flags: blocking-firefox3? → blocking-firefox3-
Comment on attachment 266556 [details] [diff] [review] patch per beltzner's comments v1.1 beltzner, gavin says that he's OK with this as long as you are.
Attachment #266556 - Flags: review?(gavin.sharp) → ui-review?(beltzner)
Comment on attachment 266556 [details] [diff] [review] patch per beltzner's comments v1.1 I agree with Dan that this makes for a crappy first experience with Firefox. We need to also disable the "submitting information to an insecure page" warning by default. I like MPT's suggested solution in comment #16, and indeed, we could probably use that in other areas of the UI to make good practise statements about privacy (and perhaps even anti-phishing, like "This is the first time you've ever submitted data to this website, are you sure you trust it?") But that is a separate bug, indeed. I'll loop back and file it before closing this tab.
Attachment #266556 - Flags: ui-review?(beltzner) → ui-review-
The first patch, attachment 229054 [details] [diff] [review], addresses beltzner's comments, and has the necessary reviews. I also brought it up with him again today (since I was in the process of filing an identical bug, not knowing about this one) and we both agree that it's a good way to go. Dialog'ng on http-to-http submit is pretty heavy over-warning, and while I agree that there's risk there, I think it's outweighed by the risk of continuing to encourage user dialog apathy. As dveditz points out, the https-to-http submit warning isn't impacted by this change. With all that said, can we land the original patch? Note: This also speaks to SPI-001h from the Firefox 3 PRD (P2 - Improve security warnings/dialogs)
I don't mind the warnings and security training. I do mind the redundancy. Every firefox installation defaults these questions to NOT ANSWERED. So the first time the situation arises I have to set it to SELECTED. Then the next time I usually UNSELECT. I would prefer you default these items to SELECTED so I can UNSELECT if I choose to. Thanks for listening to my thoughts!
Can we get entirely rid of the "about to view an encrypted page" warning? (the http->https transition warning)? It's not clear why we ever need to "warn" the user about become MORE secure.
(In reply to comment #24) > Can we get entirely rid of the "about to view an encrypted page" warning? > (the http->https transition warning)? > > It's not clear why we ever need to "warn" the user about become MORE secure. I use it in my slide decks as an example of what not to do. :) Nevertheless, I think we have a simple, approved patch here that makes things better, so I'm resistant to scope-creeping it. Nelson: Any chance I can convince you to file a follow-up bug to either rework the language (so that it's not a warning, it's a "hey, you asked for flashing lights and dancing bananas whenever you land somewhere SSL" message) and/or remove it - so that the discussion happens there, and doesn't stop this one from landing? I think you'd agree that the change this bug makes is worthwhile on its own?
Attachment #229054 - Attachment is obsolete: false
Attachment #266556 - Attachment is obsolete: true
Checking in netwerk/base/public/security-prefs.js; /cvsroot/mozilla/netwerk/base/public/security-prefs.js,v <-- security-prefs.js new revision: 1.19; previous revision: 1.18 done Checking in browser/app/profile/firefox.js; /cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js new revision: 1.196; previous revision: 1.195 done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: Firefox 3 alpha6 → Firefox 3 M8
Uh.... so this changed the security warning prefs for all Gecko apps and only changed the show-once prefs for Firefox? That seems very odd to me. If you make a core change that breaks apps, either fix them or file bugs on them to deal. Neither has happened here.
The only other app in our tree with non-default show_once values is Calendar. Did we "break" apps? Does SeaMonkey or Calendar really want to continue pestering users with these warnings? If so we could easily just override these values in firefox.js, but I thought the consensus was that this lead to dialog fatigue. (I guess this _is_ a Firefox bug; I thought it was Core-Security.)
> The only other app in our tree with non-default show_once values is Calendar. But since the default values of the core prefs changed, the show_once values might need to change too. They certainly did for Firefox. > Did we "break" apps? You changed their UI behavior without review, certainly. I agree that the main change is for the better; it's the details that I'm not sure about. Even just ccing the relevant module owners on this bug would have been a good idea; then they could decide whether their code needs any changes in response to this core change. ccing Neil, but not sure who the right person for Camino is.
> since the default values of the core prefs changed, the show_once values > might need to change too. They certainly did for Firefox. I'm not sure they did need to change. The default value of a checkbox on a dialog that now doesn't appear doesn't matter all that much. I guess people figured that if someone did manually change the pref to show the dialog maybe they really meant it. In any case the change restores Firefox to using the same show_once default value as other apps -- ispiked could have (should have?) simply deleted the firefox.js overrides rather than set them explicitly false. Firefox's use of non-default values were an earlier attempt to reduce the dialog annoyance without going all the way and suppressing them as this patch does. > You changed their UI behavior without review, certainly. I agree that the > main change is for the better; it's the details that I'm not sure about. CC'ing ss and Stuart Morgan for Camino. You're right that we should have made sure all the Mozilla apps knew about the change so they have a chance to override the changed defaults, but changing this globally as the preferred "Mozilla default" was the right thing to do. We don't want to scare and confuse users with "warnings" about normal web behavior, and we don't want the end result being they ignore the warnings that do matter as just more of the same. "SSL error pages" (in another bug) is another core security-UI global change that will affect all apps.
> but changing this globally as the preferred "Mozilla default" was the right > thing to do. Oh, definitely.
One of our devs saw this go by at the time, and we looked over (and agreed with) all the changes, but thanks for looping us in to check.
Whiteboard: [wanted-firefox3] → [wanted-firefox3] relnote-seamonkey2.0a relnote-seamonkey2.0
Possibly a new message would be good for sending information to a non-encrypted page using a form on an encrypted one. That one should definitely on by default.
We already have that dialog. It's on by default and doesn't contain a checkbox for turning it off. To see it, go to https://www.squarefree.com/start/ and search using the Google box.
Litmus Triage Team: Tomcat will handle the Litmus test case for this bug.
(In reply to comment #35) > Litmus Triage Team: Tomcat will handle the Litmus test case for this bug. > Created a Litmus Testcase for this Bug.
Flags: in-litmus? → in-litmus+
verified fixed Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a9pre) Gecko/2007101504 Minefield/3.0a9pre ID:2007101504 also on Mac -> verified fixed
Status: RESOLVED → VERIFIED
Whiteboard: [wanted-firefox3] relnote-seamonkey2.0a relnote-seamonkey2.0 → relnote-seamonkey2.0a relnote-seamonkey2.0
You need to log in before you can comment on or make changes to this bug.