Closed Bug 1278582 Opened 3 years ago Closed 3 years ago
After update to latest FF version - the Microsoft Family Safety is imported when the Child Mode feature is disabled
[Note]: This issue is shown only if the user updates after he had the child account set and running before Bug 1265113. [Affected versions]: - Nightly 50.0a1 - Aurora 49.0a2 [Affected platforms]: - Windows 8.1 [Prerequisites]: - Install a Nightly 49.0a1 version before the patch from Bug 1265113 (for e.g the Nightly version from May 26th) [Steps to reproduce]: 1. Open Nightly 49.0a1 2. Go to about:config and add the preference "security.family_safety.mode"=2 3. Check the preference "security.family_safety.imported_root.db_key" exists and is something like "AAAAAAASomebiglongbase64thing.." 4. Update to the latest Nightly 5. Go to about:preference#advanced -> Certificates -> View Certificates and look for the Microsoft Family Safety certificate 6. Go to about:config and set preference "security.family_safety.mode" to 0 7. Check for the Microsoft Family Safety certificate in the Certificate Manager. [Expected result]: After disabling the Child mode feature in step 6 - the preference "security.family_safety.imported_root.db_key" should be cleared from about:config. The Microsoft Family Safety certificate should not be imported after disabling the Child Mode feature in step 6. [Actual result]: The preference "security.family_safety.imported_root.db_key" is not cleared. The Microsoft Family Safety certificate is displayed in the Certificate Manager. [Regression range]: - I'll investigate and add the regression range as soon as possible. [Additional notes]: Reproducible also when updating to the latest Firefox Developer Edition 49.0a2 (Build ID: 20160607004038).
After setting "security.family_safety.mode" to 0, is the Microsoft Family Safety root still trusted? (If you double-click on it in the certificate manager, what does it say right under "General"? Alternatively, what check-boxes are checked if you select it and click "Edit Trust..."?)
(In reply to David Keeler [:keeler] (use needinfo?) from comment #1) > After setting "security.family_safety.mode" to 0, is the Microsoft Family > Safety root still trusted? (If you double-click on it in the certificate > manager, what does it say right under "General"? The following message is displayed under General: "Could not verify this certificate because the issuer is unknown". Please see the attached screenshot for more details. Alternatively, what > check-boxes are checked if you select it and click "Edit Trust..."?) None of the check-boxes are checked. Moreover, If I navigate to a HTTPS website (e.g to Yahoo), the Insecure Connection message is displayed and if I click on the Advanced button I get the following message: "www.yahoo.com uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported. Error code: SEC_ERROR_UNKNOWN_ISSUER"
Ok - thanks. This is sort-of expected, since the previous implementation permanently imported the Family Safety root and the code that would permanently remove it doesn't exist any more. Unfortunately it's not clear what a good solution would be. It may be the case that the user has manually imported the root, and it would be surprising if we deleted it. Then again, we are modifying its trust, which would be unexpected in that case as well. In any case, I don't think this is a blocker, but it would be good to think about what to do here.
I think our options here are: * Implement some sort of upgrade detection logic that will do the right thing here (difficult) * Disable the Family Safety functionality on 48 (fairly easy but unfortunate in that it delays the feature (does require changes to 48, which is in Beta)) * Don't evangelize the feature so nobody uses it until 49 is released (again delays the feature, but requires no code changes) * Uplift the changes in 49 that caused this to 48 (48 is in Beta, so this is unlikely to happen) * Close this as wontfix (unfortunate but since this bug doesn't break the feature, it's not too concerning) Due to limited resources, I'm leaning towards wontfix.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.