Major update fx2 -> Fx3: Security Warning prefs are overwritten to default Fx3

RESOLVED WONTFIX

Status

()

--
major
RESOLVED WONTFIX
10 years ago
10 years ago

People

(Reporter: tracy, Unassigned)

Tracking

({regression})

3.0 Branch
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
testing on "majortest" channel with 2.0.0.14 -> 3.0

STR: 
1) in 2.0.0.14 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.

Updated

10 years ago
Whiteboard: [MU?]

Comment 3

10 years ago
Confirmed on XP MU 2.0.0.14 -> 3.0
Caused by Bug 341472
Component: Software Update → Security
Keywords: regression
QA Contact: software.update → firefox

Comment 5

10 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.
Flags: blocking1.9.0.2+
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: 10 years ago
Resolution: --- → WONTFIX
Flags: blocking1.9.0.2+

Comment 8

10 years ago
removing MU+ whiteboard since this is wontfix
Whiteboard: [MU+]
You need to log in before you can comment on or make changes to this bug.