1735372 - Consider to expose GPC preference to extensions within privacy.network

Status: RESOLVED FIXED

(WebExtensions :: General, task, P1)

Description

[Christoph Kerschbaumer [:ckerschb]]

We added support for Global Privacy Control (GPC) within Bug 1670058. It probably makes sense to allow extensions to observe if the preference is set within privacy.network (probably a read only exposure is fine here).

Comment 1

[June Wilde (she/her) [:jewilde]]

Attachment: Bug 1735372 - Expose GPC pref to extensions; r=mixedpuppy

Comment 2

[June Wilde (she/her) [:jewilde]]

Comment on attachment 9247218 [details]
Bug 1735372 - Expose GPC pref to extensions; r=mixedpuppy

Beta/Release Uplift Approval Request

• User impact if declined: Extensions would be unable to properly set GPC navigator property and HTTP header due to being unable to detect if the browser is already setting them. This would cause GPC signals to become invalid or mismatched when sent to a server.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce: N/A
• List of other uplifts needed: N/A
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This change is low risk as it is only creating a readonly boolean value visible to extensions.
• String changes made/needed: N/A

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3afb6be57739
Expose GPC pref to extensions; r=mixedpuppy

Comment 4

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/3afb6be57739

Comment 5

[Pascal Chevrel (relman team) -> :pascalc]

Comment on attachment 9247218 [details]
Bug 1735372 - Expose GPC pref to extensions; r=mixedpuppy

Low risk early in the beta cycle, approved for 95 beta 4, thanks.

Comment 6

[Peter Saint-Andre [:stpeter]]

How should extension developers understand the implications of these settings? Here is one interpretation:

1. If privacy.globalprivacycontrol.functionality.enabled is set to TRUE and privacy.globalprivacycontrol.enabled is also set to TRUE, then an extension should avoid double-sending the GPC header since Firefox will already do so.

2. If privacy.globalprivacycontrol.functionality.enabled is set to TRUE but privacy.globalprivacycontrol.enabled is set to FALSE, then an extension should avoid sending a conflicting GPC header (Firefox will sent GPC FALSE and the extension shouldn't send GPC TRUE).

3. If privacy.globalprivacycontrol.functionality.enabled is set to FALSE, then an extension should avoid sending the GPC header.

4. If neither parameter is set, then an extension should feel free to send GPC TRUE.

Is this accurate?

Comment 7

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Peter Saint-Andre [:stpeter] from comment #6)

Is this accurate?

This seems like an accurate interpretation - June are we missing anything?

Comment 8

[Ryan VanderMeulen [:RyanVM]]

This was landed for 95.0b4.
https://hg.mozilla.org/releases/mozilla-beta/rev/50244767a433

Comment 9

[June Wilde (she/her) [:jewilde]]

I would say that any situation where the browser isn't setting the GPC signals (navigator property + http header) to true (whenever privacy.globalprivacycontrol.enabled is FALSE) then the extension should feel free to set/overwrite the GPC signals. The privacy.globalprivacycontrol.enabled pref will be reflected in the network.globalPrivacyControl read only property. I'm assuming that a user either installing/telling an extension to set the GPC signals is the user intending to opt-out of having their information sold/shared so in that case if the browser is not going to be sending the signals then the extension should.

1. If privacy.globalprivacycontrol.enabled is FALSE then the extension should feel free to overwrite what the browser has set in the navigator property and append the http header.

2. If privacy.globalprivacycontrol.enabled is TRUE then the extension shouldn't set the GPC signals as the browser is already setting them.

3. Extensions should still be able to set the GPC signals regardless of what privacy.globalprivacycontrol.functionality.enabled is set to as they had been doing previously, so they won't have to worry about what that preference is set to.

Comment 10

[June Wilde (she/her) [:jewilde]]

One thing I forgot to mention was that for the case that privacy.globalprivacycontrol.enabled isn't set and therefore network.globalPrivacyControl isn't set (which would be in any version of Firefox older than 95) then the extensions should feel free to set the GPC signals there as well.

Comment 11

[Andrey Meshkov]

I'd agree with June here. Let's take Firefox tracking protection as an example. A user may choose to disable it for a website, but it does not mean that content blocking extensions should automatically stop doing their job on that website. The example is a bit of a stretch, but I hope it helps understand the logic.