Closed
Bug 1433870
Opened 6 years ago
Closed 6 years ago
Policy: enable tracking protection
Categories
(Firefox :: Enterprise Policies, defect, P1)
Firefox
Enterprise Policies
Tracking
()
VERIFIED
FIXED
Firefox 61
People
(Reporter: RT, Assigned: mkaply)
References
Details
Attachments
(1 file)
59 bytes,
text/x-review-board-request
|
Felipe
:
review+
bytesized
:
review+
jcristau
:
approval-mozilla-beta+
|
Details |
Policy request to always enable tracking protection. The policy engine could set privacy.trackingprotection.enabled to true.
Reporter | ||
Updated•6 years ago
|
Blocks: policies-mvp
Reporter | ||
Comment 1•6 years ago
|
||
As discussed this is a nice to have for 60 so I'm setting this as a P2.
Priority: -- → P2
Assignee | ||
Comment 2•6 years ago
|
||
Marketing really wants this and it should be easy (pref flip) I'll take.
Assignee: nobody → mozilla
Priority: P2 → P1
Comment 3•6 years ago
|
||
What about the checkbox in preferences? Does that need to be disabled when this policy is in place?
Flags: needinfo?(mozilla)
Assignee | ||
Comment 4•6 years ago
|
||
> What about the checkbox in preferences? Does that need to be disabled when this policy is in place?
That should happen automatically when we set and lock the preference.
The preferences infrastructure supports disabling things when we lock a preference.
Flags: needinfo?(mozilla)
Comment 5•6 years ago
|
||
One problem with policy is that Tracking Protection is something that can break websites, and the Private Browsing entry point makes that clear, whereas something Always On like this will be a lot harder for users to figure out what is happening. One question: when Tracking Protection is set to "Always", can the user still temporarily disable it for the current tab, through the Identity/Permissions panel?
Assignee | ||
Comment 6•6 years ago
|
||
> One question: when Tracking Protection is set to "Always", can the user still temporarily disable it for the current tab, through the Identity/Permissions panel?
Yes, i think so. This would really be about just setting the preference. And we can decide if we want it locked or to just set the default.
Comment 7•6 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #6) > > One question: when Tracking Protection is set to "Always", can the user still temporarily disable it for the current tab, through the Identity/Permissions panel? > > Yes, i think so. This would really be about just setting the preference. Ok cool :)
Status: NEW → ASSIGNED
Comment 8•6 years ago
|
||
(In reply to :Felipe Gomes (needinfo me!) from comment #5) > One question: when Tracking Protection is set to "Always", can the user > still temporarily disable it for the current tab, through the > Identity/Permissions panel? Yes, it can always be disabled by users. We'd have to add another pref to lock the override ability.
Comment 9•6 years ago
|
||
Ok cool. To be clear, I was looking to making sure that is still possible, and not to lock that down too.. So that a broken site can be worked around by the user. Having the setting locked as "Always" is probably protection enough for a sysadmin.
Comment hidden (mozreview-request) |
Comment 11•6 years ago
|
||
mozreview-review |
Comment on attachment 8959686 [details] Bug 1433870 - Tracking protection policy. https://reviewboard.mozilla.org/r/228516/#review234352 This looks good to me. Since there is only one value taken by the policy to set tracking protection for both "regular" mode and private browsing mode, I would expect the documentation that we eventually make to reflect that. I like the addition of `setDefaultPref`. I think I will file a bug to change the "Homepage" policy to use that when the "Locked" parameter is not `true`. I think it does make more sense to set pref values as the defaults rather than just setting the prefs.
Attachment #8959686 -
Flags: review?(ksteuber) → review+
Comment 12•6 years ago
|
||
Comment on attachment 8959686 [details] Bug 1433870 - Tracking protection policy. Looks good to me too, and I like this setDefaultPref function, and agree we should use it more. When I implemented the original setAndLockPref function, I had found a potential problem with it. See https://bugzilla.mozilla.org/show_bug.cgi?id=1428923#c1 But I think we should go ahead with it and find a solution for that problem as a separate bug. Let me handle landing this patch through inbound because there are other things I am about to land which might conflict if they are not rebased.
Attachment #8959686 -
Flags: review?(felipc) → review+
Comment 13•6 years ago
|
||
mozreview-review |
Comment on attachment 8959686 [details] Bug 1433870 - Tracking protection policy. https://reviewboard.mozilla.org/r/228516/#review234376
Comment 14•6 years ago
|
||
Pushed by felipc@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/6b82b05b0d38 Policy: Tracking protection. r=felipe,bytesized
Comment 15•6 years ago
|
||
[Tracking Requested - why for this release]: Enterprise Policies for ESR
status-firefox60:
--- → affected
tracking-firefox60:
--- → ?
Comment 16•6 years ago
|
||
Pushed by felipc@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/3ab4dce21458 Policy: Tracking protection. test follow-up. r=me
Comment 17•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6b82b05b0d38 https://hg.mozilla.org/mozilla-central/rev/3ab4dce21458
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox61:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
Updated•6 years ago
|
Comment 18•6 years ago
|
||
We tested this on nightly with JSON policy format and it is verified as fixed. We will retest it when admx format is available.
Comment 19•6 years ago
|
||
Comment on attachment 8959686 [details] Bug 1433870 - Tracking protection policy. Approval Request Comment [Feature/Bug causing the regression]: Policy to Enable tracking protection [User impact if declined]: - [Is this code covered by automated tests?]: yes [Has the fix been verified in Nightly?]: yes [Needs manual test from QE? If yes, steps to reproduce]: QA has verified it [List of other uplifts needed for the feature/fix]: bug 1447353 (already approved) [Is the change risky?]: no [Why is the change risky/not risky?]: limited to the use of this policy [String changes made/needed]: none
Attachment #8959686 -
Flags: approval-mozilla-beta?
Comment 20•6 years ago
|
||
Comment on attachment 8959686 [details] Bug 1433870 - Tracking protection policy. enterprise policy, beta60+
Attachment #8959686 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 21•6 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/117ae537ef0d
Flags: in-testsuite+
Comment 22•6 years ago
|
||
This is also tested with admx file and it is verified as fixed. Test cases and runs are here- https://testrail.stage.mozaws.net/index.php?/plans/view/8760
Comment 23•6 years ago
|
||
We retested this on beta builds[FX60] with ADM and JSON policy formats and it is verified as fixed. Test cases and runs are here- https://testrail.stage.mozaws.net/index.php?/plans/view/8760
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•