This patch adds an event telemetry for fingerprinting protection
checkbox and fingerprinting protection prefs into the telemetry environment prefs.
Differential Revision: https://phabricator.services.mozilla.com/D186024
This patch implements a checkbox in ETP Custom usbpanel. It's for the
configuration of the fingerprinting protection. Similar to the tracking
protection checkbox, it has a dropdown list to select which window to
enable the protection, private windows or all windows.
In addition, we update the existing copy for fingerprinters to reflect
the newly added fingerprinting protectoin checkbox.
Differential Revision: https://phabricator.services.mozilla.com/D186023
Do not isolate `https-only-load-insecure` by origin attributes. This way the HTTPS-Only exceptions will behave similar to the `cookie` permission. This means that exceptions set in the system settings will also apply to private windows, but exceptions set in private windows via the identity pane will be reset after closing the browser.
Depends on D182761
Differential Revision: https://phabricator.services.mozilla.com/D183745
- Update the HTTPS-Only dropdown in the site identity pane to always set exceptions for the http version of the current origin.
- Add new parameter `forcedHTTP` to `gPermissionManager`, in order to only allow origins with a http scheme to be added in the HTTPS-Only section of the settings. This means when a https URL is added as an exeption, it will automatically be converted into a http one.
- Add a migration to convert all existing HTTPS-Only exceptions with a https scheme to a http scheme.
- Update `browser_https_only_exceptions.js` and `browser_identityPopup_HttpsOnlyMode.js` to account for this new behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D182761
This should be seen as a temporary change since the UI probably needs a slightly bigger update if it should manage both HTTPS-Only and HTTPS-First.
Depends on D179424
Differential Revision: https://phabricator.services.mozilla.com/D179425
We surface the email tracking protection using the existing tracking
protection UI on the protection panel, but we don't disable email
tracking protection if tracking protection is disabled. So, users will
still see blocked trackers if tracking protection is disabled for
private windows. To provide a way to disable email tracking protection
in private windows, we also use the existing tracking protection checkbox
UI to disable the email tracking protection.
This patch implements that disabling the tracking protection via the
tracking protection checkbox also disables email tracking protection.
Differential Revision: https://phabricator.services.mozilla.com/D177520
This adapts previous test cases from the connection UI to the privacy UI.
Additional improvements:
- Set the ROLLOUT_URI_Pref to empty string to avoid DoHConfig reset setting it to undefined.
- Always set network.trr.uri even if it matches the default_provider_uri if it's a user choice.
- If the value of network.trr.uri doesn't match any of the providers, then set custom_uri so
it shows up in the input text field. This can happen when it's set by a policy.
Differential Revision: https://phabricator.services.mozilla.com/D174876
- Patch changes TRRService::MaybeSetPrivateURI so that it doesn't bail
if the URL is invalid. That could lead us into a state where the
network.trr.uri pref has been set to some invalid URL, but we continue
using the previous domain (or even the default TRR provider) instead.
- Updates the DoH settings UI to not set the network.trr.uri pref to "",
as that will cause the TRRService to use the value of
the network.trr.default_provider_uri pref instead.
Differential Revision: https://phabricator.services.mozilla.com/D174111
- The patch saves the confirmation channel's status and skipReason in the TRR Service
- The UI queries the status and displays the stringified version in the Not Available (reason) label
- Introduces doh-status-label CSS rule so the Learn-More link isn't off center
Differential Revision: https://phabricator.services.mozilla.com/D174110
- Patch changes TRRService::MaybeSetPrivateURI so that it doesn't bail
if the URL is invalid. That could lead us into a state where the
network.trr.uri pref has been set to some invalid URL, but we continue
using the previous domain (or even the default TRR provider) instead.
- Updates the DoH settings UI to not set the network.trr.uri pref to "",
as that will cause the TRRService to use the value of
the network.trr.default_provider_uri pref instead.
Differential Revision: https://phabricator.services.mozilla.com/D174111
- The patch saves the confirmation channel's status and skipReason in the TRR Service
- The UI queries the status and displays the stringified version in the Not Available (reason) label
- Introduces doh-status-label CSS rule so the Learn-More link isn't off center
Differential Revision: https://phabricator.services.mozilla.com/D174110
- Patch changes TRRService::MaybeSetPrivateURI so that it doesn't bail
if the URL is invalid. That could lead us into a state where the
network.trr.uri pref has been set to some invalid URL, but we continue
using the previous domain (or even the default TRR provider) instead.
- Updates the DoH settings UI to not set the network.trr.uri pref to "",
as that will cause the TRRService to use the value of
the network.trr.default_provider_uri pref instead.
Differential Revision: https://phabricator.services.mozilla.com/D174111
- The patch saves the confirmation channel's status and skipReason in the TRR Service
- The UI queries the status and displays the stringified version in the Not Available (reason) label
- Introduces doh-status-label CSS rule so the Learn-More link isn't off center
Differential Revision: https://phabricator.services.mozilla.com/D174110
This patch adds support only for BLOCK permissions because ALLOW permissions
are double-keyed and will be included via a subsequent patch.
Support for a global BLOCK permission is not added here because of
inconsistencies in the way this interacts with device-specific ALLOW
permissions.
Differential Revision: https://phabricator.services.mozilla.com/D170303
It turns out the detect-only pref must be unset for cookie banner
handling to actually work, and while the onboarding doorhanger does
disable this pref, the about:preferences checkbox does not. This patch
corrects the issue, disabling the detect-only pref when the checkbox is
checked, so that users who discover the feature in about:preferences can
successfully enable it.
Differential Revision: https://phabricator.services.mozilla.com/D169645
