testing on "majortest" channel with 188.8.131.52 -> 3.0 STR: 1) in 184.108.40.206 ensure all five preferences for Security Warnings are set ON (checked) 2) perform MU 3) Check Security Warning settings tested results: only pref 2 and 5 are still on, the other 3 are turned off (this is the default for Fx3) expected results: All 5 prefs are still on after MU.
Those prefs are stored in the profile and software update doesn't touch profiles. Perhaps the pref names changed and aren't migrated?
The default prefs for those three changed from true to false between 2 and 3. In order to migrate those faithfully we need to distinguish a new profile that hasn't made a choice and someone who really wants to be annoyed on every new page. We can use the associated show_once prefs: if those have non-default "false" values then the Firefox 2 user really wanted the annoying dialogs. FF2 defaults security.warn_* true security.warn_*.show_once true FF3 defaults as above for "2 and 5" (low-grade encryption, mixed content) security.warn_* false security.warn_*.show_once false FF2 user who liked the dialogs security.warn_* true security.warn_*.show_once false ** this is the clue ** Maybe this is a WONTFIX anyway, not sure how many users really keep those dialogs and if we care to do the extra migration work just for them. The unencrypted page and form ones are just how the web works normally (unfortunate as it is). I do know of at least one security guy who keeps the "warn when leaving encrypted" warning on to catch supposedly secure sites who redirect through insecure URI's. That is admittedly an edge-case and he'd probably figure out the pref change when he stops getting harassed when he knowingly leaves a secure page.
Confirmed on XP MU 220.127.116.11 -> 3.0
Caused by Bug 341472
Component: Software Update → Security
QA Contact: software.update → firefox
11 years ago
(In reply to comment #2) > I do know of at least one security guy who keeps the "warn when leaving > encrypted" warning on to catch supposedly secure sites who redirect through > insecure URI's. Apparently one source of amusement is that AMO (used to) redirect to http for platform/language detection, so that you could hit AMO with http, get redirected to https, get redirected to http for language, get redirected to https, get redirected to http for platform, get redirected to https.
Connor: advice/guidance here? I seem to recall that we've encountered this sort of thing before. I agree that this blocks, though the decision might end up being that this is INVALID or WONTFIX if we decide that (as I think we've decided before) when we change the default value, we assume that a profile with an unchanged default should be changed as well.
Whiteboard: [MU?] → [MU+]
The pref API kinda sucks for stuff like this, our historical position has been that default settings are not preserved if we change the default. Part of the problem is that the older impl was kinda wacky with the one time prefs, so there's no good way of detecting this vs. a very new user. Users with new profiles will not have these prefs set, and we changed the defaults because 99% of users do not understand or care about these warnings, except to make them go away. Going to mark this WONTFIX, the value of preserving this setting in the edge case just isn't there, people can change the prefs if they want the warnings.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
removing MU+ whiteboard since this is wontfix
You need to log in before you can comment on or make changes to this bug.