Page 1 of 1

Issue #1721 - Global Privacy Control Support

Posted: 2021-09-11, 13:14
by RealityRipple
Figured I'd throw together the changes for Sec-GPC. Not sure the mochitest and telemetry stuff is still necessary, but I figured I wouldn't break parity with the DNT implementation. If/when I get a repo account, I'll make it into a PR.
If naming the pref "privacy.globalprivacyheader.enabled" isn't quite specific enough, it can be changed to "privacy.globalprivacycontrolheader.enabled", "privacy.globalcontrolheader.enabled", "privacy.gpcheader.enabled" or whatever you prefer. It's also set not to sync the pref, and to follow the "UseTrackingProtection" check which DNT uses.
Also, I'm not certain how clean my implementation of the Navigator variable is - the Navigator.doNotTrack variable is a string, whereas this is supposed to be a boolean, so I copied the way onLine works, with a "NavigatorGlobalPrivacyControl" interface that Navigator implements, rather than the partial interface methodology, so that a straight boolean-returning function could take care of it instead of a "Get*" function with a by-ref string parameter. It should also be accessible to worker and chrome-context Navigator objects, just in case. My test compile worked, but if I missed something elsewhere in the code that's required for this methodology, please let me know!

Re: Issue #1721 - Global Privacy Control Support

Posted: 2021-09-11, 14:34
by New Tobin Paradigm
r-

Re: Issue #1721 - Global Privacy Control Support

Posted: 2021-09-11, 19:51
by RealityRipple
Sorry, missed a function declaration in WorkerNavigator.h. Dunno why my compile didn't catch it the first time.

Also, see the commit note regarding the direct use of prefs. If a generalized (non-window-context) or Worker-context function to do the tracking protection check already exists (to future-proof such checks against possible additional preferences, compile flags, bug #1320796, and the like), please let me know. I didn't see one, though.
And if there's a header that WorkerNavigator.h has access to where I should put the gpc pref check rather than doing it directly in the function, lemme know about that too.

Re: Issue #1721 - Global Privacy Control Support

Posted: 2021-09-11, 21:09
by New Tobin Paradigm
New Tobin Paradigm wrote:
2021-09-11, 14:34
r-

Re: Issue #1721 - Global Privacy Control Support

Posted: 2021-09-12, 00:21
by Moonchild
To elaborate on the r-: we discussed this (a while back, prior to the issue being created in fact) and the straight up Mozilla port you seem to have done here is not what we want to do in this case.
What needs to happen is a direct replacement of the defunct and pointless DNT with the GPC equivalent, carrying over user preference since the intent of a user explicitly checking it has largely been the same, and for starters you really shouldn't include anything that's irrelevant to our development like automated test cases or telemetry BS.

Re: Issue #1721 - Global Privacy Control Support

Posted: 2021-09-12, 00:38
by RealityRipple

Re: Issue #1721 - Global Privacy Control Support

Posted: 2021-09-14, 22:27
by RealityRipple
Fixed Comparison URL - UXP: Replace DNT with Sec-GPC

Re: Issue #1721 - Global Privacy Control Support

Posted: 2021-09-15, 03:29
by New Tobin Paradigm
Frankly, I don't want your contributions in our collective codebases. You will almost certainly turn around and join the other fuckin freaks against us. You are already on high level probation as it is.

Re: Issue #1721 - Global Privacy Control Support

Posted: 2022-03-18, 11:02
by RealityRipple
Slight bug in the implementation of this feature:
Service.prefs should be Services.prefs. This prevents the GPC header preference from being carried across from DNT.

Re: Issue #1721 - Global Privacy Control Support

Posted: 2022-03-18, 11:09
by Moonchild
Well, dang

Updated release notes to inform people.

Re: Issue #1721 - Global Privacy Control Support

Posted: 2022-03-18, 21:43
by Moonchild
RealityRipple wrote:
2022-03-18, 11:02
Slight bug in the implementation of this feature:
Seems it's not the only bug.
It does seem that your proposed code changes that I used to make these changes have a strange side-effect for password storage. Can you please have a look at what might be going on there? Did you miss a callsite or something?

Re: Issue #1721 - Global Privacy Control Support

Posted: 2022-03-18, 23:52
by RealityRipple
Pretty sure everything I proposed was strictly related to headers. However, that typo probably stopped all execution of nsBrowserGlue.js, which also includes the _promptForMasterPassword() function. With a self-compiled version with "Services" instead of "Service", the login autocompletes do seem to work. When Services.prefs.prefHasUserValue("privacy.donottrackheader.enabled") returns false, line 1535 isn't called and nsBrowserGlue.js doesn't abort execution.

Re: Issue #1721 - Global Privacy Control Support

Posted: 2022-03-19, 00:05
by Moonchild
ah, of course. Remind me to move these migration steps to a safer location, sometime.

Well, dang, again. How one letter can throw a spanner in the works, eh?