Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPC #1818

Closed
Thorin-Oakenpants opened this issue Mar 21, 2024 · 18 comments
Closed

GPC #1818

Thorin-Oakenpants opened this issue Mar 21, 2024 · 18 comments

Comments

@Thorin-Oakenpants
Copy link
Contributor

Thorin-Oakenpants commented Mar 21, 2024

what about adding it to the user.js to enforce its default value with prefscleaner (currently false)?

Originally posted by @Tiagoquix in #1542 (comment)

@Thorin-Oakenpants
Copy link
Contributor Author

IDK, my initial reaction is no (because then I will have to repeatedly defend it) .. if something isn't in the user.js then you shouldn't change it .. but I get the info factor is tempting

at the end of the day, it's really only going to help RFP users (by being enforced as off) - TB next ESR will have it too (because PB mode, assuming they don't change it and I don't see why they would) - not that we are trying to look like TB

I also need to check if setting the prefs affects PB mode

What I would like to happen is if ETP Strict then send it - this would then make Mozilla happy that it was opted in

I need to drink about it ... maybe in Portugal

@Tiagoquix
Copy link
Contributor

Epic Portuguese meeting incoming 🚀

IMO, GPC could be added to 7015 and we could justify it as "passive fingerprint, useless with dFPI, don't enable".

@xe-3
Copy link

xe-3 commented Mar 21, 2024

What I would like to happen is if ETP Strict then send it - this would then make Mozilla happy that it was opted in

Can you elaborate on this?

Am I understanding correctly that what you are saying here is that if ETP strict mode is enabled GPC would be enabled? Or have I misunderstood your meaning.

Also could you elaborate on what you alluded to with making Mozilla happy that it remains opt-in? Is this their policy/position?

@Thorin-Oakenpants
Copy link
Contributor Author

Can you elaborate on this

not really .. just musing, not really thinking about it - its not high priority for me right now. Haven't even checked anything.

Someone said it's used in PB mode ... but the default API is off ok, the API is enabled by default now, that's right, I forgot .... so anyway, it must be configurable (i.e the value sent is based on some criteria, e.e. window mode etc) - just checked a PB window and navigator.globalPrivacyControl = true, normal window = false

So the logic is this - we follow what Mozilla does. Right now your PB windows use ETP Strict and do PB mode special things (e.g. FPP if RFP is disabled, anything else they throw in like cookie banners and bounce stuff)

The same holds for ETP Strict ... we follow what Mozilla does - see these examples

/* 7015: enable the DNT (Do Not Track) HTTP header
 * [WHY] DNT is enforced with Tracking Protection which is used in ETP Strict (2701) ***/
   // user_pref("privacy.donottrackheader.enabled", true);
/* 7016: customize ETP settings
 * [NOTE] FPP (fingerprintingProtection) is ignored when RFP (4501) is enabled
 * [WHY] Arkenfox only supports strict (2701) which sets these at runtime ***/
   // user_pref("network.cookie.cookieBehavior", 5); // [DEFAULT: 5]
   // user_pref("privacy.fingerprintingProtection", true); // [FF114+] [ETP FF119+]
   // user_pref("network.http.referer.disallowCrossSiteRelaxingDefault", true);
   // user_pref("network.http.referer.disallowCrossSiteRelaxingDefault.top_navigation", true); // [FF100+]
   // user_pref("privacy.partition.network_state.ocsp_cache", true); // [DEFAULT: true FF123+]
   // user_pref("privacy.query_stripping.enabled", true); // [FF101+]
   // user_pref("privacy.trackingprotection.enabled", true);
   // user_pref("privacy.trackingprotection.socialtracking.enabled", true);
   // user_pref("privacy.trackingprotection.cryptomining.enabled", true); // [DEFAULT: true]
   // user_pref("privacy.trackingprotection.fingerprinting.enabled", true); // [DEFAULT: true]

if that's not clear ... look at doNotTrack - default is unspecified, but we return 1 (a string) .. ETP Strict already changes out fingerprint, including headers.

So if ETP Strict added GPC then it is what it is, and we look like all other ETP Strict users in this regard - rather than outliers changing their passive fingerprint on a whim

@Thorin-Oakenpants
Copy link
Contributor Author

Also could you elaborate on what you alluded to with making Mozilla happy that it remains opt-in? Is this their policy/position?

I am not privy to any of Mozilla's position on this, so do not quote me. My understanding or gut feeling in reading about this in the past (all I do is read and drink and know things) is that it will unlikely ever be turned on by default for all users (but maybe that will change because shit happens, it's called the future and I have a bridge to sell people)

Brave started from a different point than FF. FF has to turn things on slowly. Brave just does things regardless, for all users - they started from a position of "hey we will do things to improve your privacy and you may experience some pain", i.e all users since day one have had this expectation. FF doesn't have that luxury with their existing user base, and only turns on features if the user OPTS IN - e.g. user chooses to use a PB window, user chooses to use ETP Strict - and even then they're cautious. Not saying GPC would break anything, but it follows the same pattern/policy

Back in the day (handy wavy not going to look anything up) doNotTrack was specified as must-be-opt-in. I think from the advertisers, because otherwise they wouldn't abide by it. So Mozilla did that, you had to opt in (e.g. via checkbox or via using pb mode). But then someone (internet explorer I think, wiki seems to suggest so) turned it on by default, and then all the advertisers who would have abided by it, said fuck this, no .. and thus it fucking died as being anything useful

anyway ... I do not know for sure if/when GPC will ever be default on for all users in FF - I wish they would purely from a FP perspective and then it (mostly) becomes a moot point, but until it does, we should just do what mozilla do

Here is the meta 1848951 .. do you see anything about turning this on by default for all users .. it's conspicuously absent

@Thorin-Oakenpants
Copy link
Contributor Author

https://bugzilla.mozilla.org/show_bug.cgi?id=1848951#c3

a large part of why DNT failed is because Microsoft unilaterally hardcoded it on in their browsers which gave the advertisers an excuse to walk away.

yup .. fucking MS .. ironic

@Tiagoquix
Copy link
Contributor

Tiagoquix commented Mar 21, 2024

Some clarification:

ETP Strict doesn't force GPC.

privacy.globalprivacycontrol.functionality.enabled (default true) enables the functionality, which allows GPC to be enabled.

privacy.globalprivacycontrol.enabled (default false) controls if the signal should be sent in regular browsing.
privacy.globalprivacycontrol.pbmode.enabled (default true) independently controls the signal for PB Mode.

If the functionality pref is disabled, then none of this works.

A UI has been exposed in a recent Firefox update in Privacy & Security -> Website Privacy Preferences, which only controls privacy.globalprivacycontrol.enabled. The functionality pref is not changed by the UI setting.

Test using https://browserleaks.com/donottrack.

The only difference that I could observe was navigator.globalPrivacyControl changing from undefined to empty according to whatever the functionality pref is enabled or not.

@Tiagoquix
Copy link
Contributor

From my point of view, I think arkenfox should enable and force it by default for all users using the base user.js.

As clarified here https://bugzilla.mozilla.org/show_bug.cgi?id=1848951#c3, GPC is something that has already involved companies in certain lawsuits, and could be benefitial for the privacy of users.

However, it would create additional fingerprinting, so I'm not sure if it would be beneficial to all.

@Thorin-Oakenpants
Copy link
Contributor Author

However, it would create additional fingerprinting, so I'm not sure if it would be beneficial to all.

I'm not going to modify passive fingerprints, so I will never turn it on. It's also not going to be beneficial if it was enabled (do I really need to explain this again)

@Tiagoquix
Copy link
Contributor

Sure. Then I would suggest to continue with my original proposal to add the 3 prefs to the user.js so the prefsclaner will take care of them.

@Thorin-Oakenpants
Copy link
Contributor Author

Epic Portuguese meeting incoming 🚀

taylor swift concert: https://www.taylorswift.com/gig/sat-may-25-2024-estadio-da-luz-lisbon-portugal/

might stay and get me some taytay and swiftie love .. y'all jelly ?

@Tiagoquix
Copy link
Contributor

Take that!
image
swift with her cat

@Thorin-Oakenpants
Copy link
Contributor Author

Thorin-Oakenpants commented Mar 21, 2024

#1542 (comment)

I still feel like you may not be appreciating the different focuses of dFPI and GPIC

I'm going to answer that here. As I said above and in the other issue, GPC for us is pretty much useless

First of all, if you don't protect your IP address, a simple few metrics and IP is all that is needed for shadow profiling. So I will assume users are protecting their IP address

AF uses dFPI. This partitioning across the board means any state is isolated per eTLD+1, per scheme, and per window (normal, pb mode ... and per container I think, it's been a while). So any assigned uuid in state can't be used to cross track. This is 3rd party tracking.

AF sanitizes. Sessions are not meant to be isolated. Even TB doesn't do that. For us in normal windows, you can use containers [1] or flick open a new PB window. This is first party tracking. We sanitize. Closing all PB windows sanitizes PB. In future PB windows will even have a 🔥 button. Closing FF sanitizes FF. This removes first party tracking (IP address + fingerprinting aside)

But .. we use dFPI, not FPI. And we can exceptions to sanitizing. So we can have long-lived state data, basically for us it's just storage quota items such as cookies, IDB, localStorage. But you opt into those, and they are, or should be, limited to logins.

When you login, you are already giving away a uuid, so this non-sanitizing, becomes a moot point. And your ToS per that site likely (I honestly don't care) dictate your privacy and make GPC obsolete (again, IDF care)

So yes, I fully appreciate understand what is going on. Sites can do whatever the fuck they like and waste time and resources collecting extra shit and clogging up their systems and wasting their resources, because it makes no difference

[1] or even temporary containers - although I think that very risky these days given it's no longer developed and has for a long time exhibited signs of neglect (issues growing, etc) ... and I have never really endorsed it because it's not a universal solution (IP address) - it's a gimmick


AF is not interested in wonky misconceived band-aids. It is interested in universal solutions. IDF care about the EU, I care about universal solutions. I don't care what companies or websites or trackers do, I only care that we control it clientside and make their efforts useless. Read this paragraph again

To give you an example: We used FPI. There was an effort amongst browsers (at least Brave, and Mozilla had a ticket) to limit the life of cookies. The idea was say a life-span of 15 days. From memory: Brave went with 7 days, but it only covered one type of cookie (set via header, not when set by JS) and totally ignored the fact that prolongation attacks were a (very simple) thing, let alone resurrecting ids via other means. After a few ums and ahhs, Mozilla closed the ticket as wontfix because it was, to be as blunt as possible here - fucking stupid and coming from a flawed premise.

Instead, Mozilla said the proper solution was partitioning, and this maybe helped spark partitioning into all browsers (there was certainly cross browser collaboration on how to do it, maybe even a spec) - see https://privacytests.org/ . So thanks Tor Browser. This is the evolution of FPI (as a universal solution) making it's way into mainstream. And thus we were able to move from FPI to dFPI.

Thanks Tor Project - Donate to Tor Project now so I can have a beer in Portugal

@xe-3
Copy link

xe-3 commented Mar 23, 2024

I prefer universal technical solutions as well. But I do not believe there is a universal technical solution that addresses the same scope of problems GPC seeks to address. dFPI (unless I misunderstand its capabilities) is an exceptional universal solution to a different problem.

So yes, I fully appreciate understand what is going on

Respectfully, I do still feel there are things you are misundersting in the specific case of GPC. I respect and defer to your expertise on technical matters or anything related to FF, AF, TBB etc, I have learned much from things you've written, and you have vastly more expertise than I do. But in this specific case, it feels like you are jumping to conclusions about GPC based on a slight misunderstanding of what GPC is and what problems it is trying to solve (your primary criticism that it is irrelevant or ineffective due to dFPI etc, seems more applicable to DNT than GPC).

GPC's primary utility is not in preventing cross site tracking. It's primary purpose as I understand it is to signal a preference that you do not want your personal data to be sold or shared, and that preference is legally enforceable in a growing number of jurisdictions. If respected, GPC addresses things that dFPI and sanitizing between sessions cannot. Particularly in the context of services and websites you log in to (because there are no fully effective technical solutions to data collection in this context). (Just because you log in to a service, doesn't mean you deserve to have your info sold/shared)

GPC isn't a replacement for dFPI or other technical solutions, but it is complementary, and it addresses a different scope of problems than dFPI does.

When you login, you are already giving away a uuid, so this non-sanitizing, becomes a moot point. And your ToS per that site likely (I honestly don't care) dictate your privacy and make GPC obsolete (again, IDF care)

I disagree. This is precisely a scenario where I think GPC has value. And one where I don't see how technical "universal solutions" could solve the problem. (can you?)

Like you say, once you are using a 1st party service, logged in, ToS (and legal limits) apply, and the GPC is an efficient way to take advantage of rights that many companies now include in their ToS and rights that some jurisdictions mandate and enforce. Users still deserve privacy, still deserve a say over what happens with their personal information, even with first party services and user accounts. The EU recognizes this right by default, in California, Colorado, and other jurisdictions, users must opt-out if they want these sames rights, and the GPC is currently the most efficient, and universal way to do so.

Don't feel obligated to respond to this comment (I don't want to distract you from Taylor and her kitty), I can see that your opinion on enabling GPC has not changed, and I respect that, so I will let it go (it'd be better to address this upstream if possible anyway, (e.g. toggling GPC on when ETP strict is enabled)).

But I'd humbly encourage you to revisit the GPC with fresh eyes when you have time, because I think you might be slightly but meaningfully misunderstanding one of the primary problems it intends to solve, that to my knowledge has not been solved by technical universal solutions.

As always, I appreciate your time, thoughts, and this project.

@Tiagoquix
Copy link
Contributor

I think Thorin's idea is the fact that this is just a signal and that the signal by itself doesn't guarantee anything on the technical side.

Even if a website resides in a jurisdiction that legally respects and enforces the GPC signal, this is not guaranteed on the technical side. Meanwhile, for example, we have the RFP, which in effect guarantees that factors will be changed in such a way as to "fool" the website you visit.

In my opinion, as much as the GPC idea is good and I agree with its adoption, I think that something this important should not be decided by the arkenfox user.js, but rather by Mozilla at a more central/universal level (similar to Brave, which adopted for everyone forcibly).

@xe-3
Copy link

xe-3 commented Mar 23, 2024

I think Thorin's idea is the fact that this is just a signal and that the signal by itself doesn't guarantee anything on the technical side.

I don't dispute that. If a technical solution existed, or could theoretically exist, I agree that it would be preferable. But as I understand it, there is no technical solution.

Meanwhile, for example, we have the RFP, which in effect guarantees that factors will be changed in such a way as to "fool" the website you visit.

except for any website where you identify yourself (intentionally or accidentally), login, etc. <-- this, is the primary value I see in GPC. First party services you choose to use, or are forced to use, with an account or with your real identity. E.g. your insurance company, your mobile carrier, a newspaper subscritpion etc. These are not cases, where dFPI or RFP can do much for you. GPC, is imperfect, legal solutions are imperfect, but in this context, I don't see any better alternative. And both the EU and California have shown a willingness to prosecute violators.

In my opinion, as much as the GPC idea is good and I agree with its adoption, I think that something this important should not be decided by the arkenfox user.js, but rather by Mozilla at a more central/universal level (similar to Brave, which adopted for everyone forcibly).

That is a reasonable point of view. I'm not sure I agree or not, but I am sympathetic to it, and respect it. And I accept this as reasonable reason to reject the proposal, even if I am personally disappointed by that decision.

Thorin-Oakenpants added a commit that referenced this issue Apr 25, 2024
@Thorin-Oakenpants
Copy link
Contributor Author

GPC's primary utility is not in preventing cross site tracking. It's primary purpose as I understand it is to signal a preference that you do not want your personal data to be sold or shared

what personal data? Let me explain it yet again - every time you visit the site has no (easily available on-tap) record of you - it keeps creating new shadow profiles and assigning new uuids - big fucking deal (again, excluding IP address and fingerprinting, excluding sites you log into, where you are gifting them an id to reused) - in other words partitioning and sanitizing removes this

maybe now you understand

@qupig
Copy link

qupig commented May 11, 2024

Can GPC be enabled by default?

The GPC preference expression should accurately reflect the users’ privacy preferences. The threshold for obtaining user consent differs between jurisdictions. GPC strives to honor those differences while still providing users with choice about how businesses use their data. In some jurisdictions, the presence of GPC in a user’s browser may constitute an adequate signal to not sell their data, while regulations in another jurisdiction may require the user’s explicit consent in order to send a GPC signal.

What constitutes a deliberate choice may differ between regional regulations. For example, regulations in one jurisdiction may consider the use of a privacy-focused browser to imply a GPC preference, such as under the CCPA Final Statement of Reasons - Appendix E #73 ("The consumer exercises their choice by affirmatively choosing the privacy control […] including when utilizing privacy-by-design products or services"), while regulations in another jurisdiction may require explicit consent from the user to send a GPC signal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants