search

arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
9.45k stars 505 forks source link

sanitizing and dFPI use the same site exception [1767271] #1448

Open privacyguy123 opened 2 years ago

privacyguy123 commented 2 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=1767271

🟥 https://github.com/arkenfox/user.js/wiki/5.2-Troubleshooting

🟪 REQUIRED INFO

image

Thorin-Oakenpants commented 2 years ago

not seeing it - give me actual links

I can't see anything on FB because I don;t have an account, but I can load facebook.com and click all items in the footer and get a bunch of fb cookies. And I took a link from there to instagram. Not seeing anything - provide LINKs

Thorin-Oakenpants commented 2 years ago

Are you allowing a site exception for facebook in clear cookies + site data?

privacyguy123 commented 2 years ago

Any link on a FB new feed: https://l.facebook.com/l.php?u=https%3A%2F%2Fwww.ultimate-guitar.com%2Fnews%2Fgeneral_music_news%2Fgwar_singer_calls_iron_maiden_a_bunch_of_british_old_women_explains_why_steve_harris_bothers_him.html%3Ffbclid%3DIwAR2IZshDEkOk8_7jdRPSyMvYnwclDJMoEj6F-Jvn9CgDaVqqSn_MzyvHz4s&h=AT0KorToAv7ls8MZXgWaMymoj3PSRyT8FeWMiNS4reGSeTImnej-O_usSucMIXJ_O3L_rzk3-ZqCqBlfk32VqAnjObxo6tGpArWy_1FrbJvhs9QJPVHu2OgMLu1f2vhvSQ&__tn__=H-R&c[0]=AT1Kf7HxMy5Igj4cwUMXqYUsPDCnPmcDmLw2Eg1ns9fgIuHV1PVREowMw5UG7662HqF4nTC9jMlKDO5V1TXyy_1ykF_vsp-VDU_T7sg7WEd6SEoEpOMx3HDqii_4-Z-2f3NuNdT8YoCabyNpn9iXjTRzic5OvLD6c_gIud4ASlMxBMvzHgkSymONpSCrxylNZV0Vm3XVDSkiW3nN

privacyguy123 commented 2 years ago

Are you allowing a site exception for facebook in clear cookies + site data?

Yes to save log in - is there a way to do this without allowing automatic cross site tracking?

Thorin-Oakenpants commented 2 years ago

I'll @wisniewskit just FYI, no need to do anything unless you want to confirm that l.facebook.com tracker being allowed is because of a sanitizing exception - I suspect it is because it's listed in the panel as an exception

i.e a case of 1767271

I bounced around FB a lot more, got to see a heap of groups and local and services and live feeds and videos and all sorts (nightly with no extensions, sanitized on previous close, no site exceptions for anything, not cookies, not ETP, nada) and got 5 fb cookies (see manage site data: the earlier attempt gave me six)

then I took your link, and I'm not seeing anything

See 1767271

I was thinking about this just this morning. We currently have network.cookie.thirdparty.sessionOnly = true, but in the next release I'm commenting that out - IDK if the site exception to keep conflicts with that, it's a footgun and will probably be removed upstream. I was thinking about how we we-work the user.js in #1441 for 101, before the upstream migration in likely 102, and the UI changes which won't apply in 101 but would in 102, and those UI changes are messy'ish

The other thing is, one assumes you are using uBO - add some rules to block some of these on third party sites globally. Personally, I have uBO set to block ALL 3p by default, so I'm sweet for my 4 exceptions, of which only github would possible ever be used as third party (and only on SSO login pages)

Also see https://github.com/privacyguides/privacyguides.org/discussions/941

Thorin-Oakenpants commented 2 years ago

hmm ... so is this two edged? If you allow a dFPI exception, does it then refuse to sanitize them?

anyway, I'll try remember to add something to #1441 about being selective about dFPI and sanitizing exceptions, but I'm hoping mozilla fix that bug ASAP, so I don;t have to.

Personally I think it should be top priority, because rolling out TCP for everyone might benefit the majority, but the UI actually makes this bug/hole very easy to replicate, and like I said elsewhere, imagine the most common dFPI exceptions = the biggest trackers on the internet, so well .. it won't look pretty as a bug AFTER the rollout

remyabel2 commented 2 years ago

https://support.mozilla.org/en-US/kb/third-party-trackers?as=u&utm_source=inproduct#w_managing-cross-site-cookies

While cross-site cookies from trackers are blocked in Firefox by default, a site may signal to the browser that it needs to use them for important functionality. In this case, Firefox will allow a third-party website to use cross-site cookies the first five times (or up to 1% of the number of unique sites you visit in a session, whichever is larger) without prompting you. After that, Firefox will prompt you to block these cookies. Without your consent, Firefox blocks these cookies from that point because a site requesting access that many times may be a tracker.

Third-parties will only be able to prompt you if you interact with the website you are on. For example, if you visit dogs.com and select the payment field, Amazon Pay cross-site cookies may be allowed to facilitate that transaction. After that, Firefox will ask you if you want to keep allowing them.

privacyguy123 commented 2 years ago

A lot of this is whooshing way over my head. Yes I use UBO, no it's not in block and break everything mode.

Manually clicking the X on "Allow" doesn't break functionality on the website linked from Facebook, I believe these are purely used for tracking your clicks and thats all - what I can't understand is why they are "allowed" by default with no prompt. I'll ask again: is there a way to save a login (FB or other) without also giving the go ahead to these cross site cookies?

privacyguy123 commented 2 years ago

Oh - toggling this fixes it, mentioned in the other thread.

https://github.com/arkenfox/user.js/blob/ea139e3ef8810149d90df8637984f2444282745e/user.js#L773-L779

1355

user_pref("privacy.antitracking.enableWebcompat", false);

Cross site Facebook shit not auto allowed any more after clicking above link while logged in to Facebook with site exception to keep log in.

Thorin-Oakenpants commented 2 years ago

Oh - toggling this fixes it, mentioned in the other thread.

it does not fix it, it removes the d part of dFPI, and fucks everyone's dFPI exceptions. The solution is the bugzilla

privacyguy123 commented 2 years ago

Oh - toggling this fixes it, mentioned in the other thread.

it does not fix it, it removes the d part of dFPI, and fucks everyone's dFPI exceptions. The solution is the bugzilla

With all due respect, the bugzilla you linked is 1 comment that doesn't offer any solution? (https://bugzilla.mozilla.org/show_bug.cgi?id=1767271) Do you mean when Mozilla get around to addressing and fixing it?

Thorin-Oakenpants commented 2 years ago

with all due respect, it is a BUG and fixing that BUG solves the issue - that's what bug fixing means

edit: the number of comments on a bug does not signify anything (severity, priority, type of issue, complexity, etc) - it's meaningless for all intents and purposes

ghost commented 1 year ago

How do you guys currently recommend to proceed with this problem? I can only see 3 ways:

-Renounce to keep cookies.

-Cover the error with temporary-containers and multi-account-containers. Very tedious, but safe, right?

-Renounce dFPI, use FPI. This has the advantage of being able to manage them with more user-friendly tools such as Cookie-AutoDelete. I find no mention of it having any other notable advantages or disadvantages, but I have misgivings.

Thorin-Oakenpants commented 1 year ago

How do you guys currently recommend to proceed with this problem

FPI is not supported except for Tor Browser - example, we are not in PB mode and we have service workers which FPI doesn't cover. And if you were using FPI, CAD is still pointless

s-rog commented 1 year ago

Until that bug is fixed perhaps disabling sanitize on shutdown (just the cookies?) is an appropriate workaround?

Thorin-Oakenpants commented 1 year ago

And you would need to remove keep cookie + site data exceptions because the site exception is the issue

Never sanitizing onShutdown cookies (and sitedata which hand in hand with retaining logins: depends on the login flow) means the 99.99% of sites users don't want to be remembered between sessions, they are

Depends on your view of 1st party. dFPI protects from cross-party. Sanitizing per session protects from 1st party. But remember that 1st parties also have 3rd parties isolated to the 1st party. So not sanitizing means that 3rd party gets the 1st party info (IIUIC)

The better solution is to be judicious and use containers, until the bug is fixed

s-rog commented 1 year ago

And you would need to remove keep cookie + site data exceptions because the site exception is the issue

Ah yes forgot to mention that part.

Depends on your view of 1st party.

I'm more concerned about cross party myself so I see this as a compromise and not a solution, hopefully the bug can be fixed soon (even though it's labeled as a feature on bugzilla).

Thanks for verifying my understanding!

Thorin-Oakenpants commented 1 year ago

for those not paying attention, it sounds like this is slated to be addressed

Still confuses me how in settings when you open ETP>Exceptions it is blank (for me), but when you open Cookie+SiteData>Exceptions is is populated (for me with 5 entries) . Maybe ETP>Exceptions is something slightly different?

Thorin-Oakenpants commented 1 year ago

Also, ETP>Exceptions is getting an Add ability - landed in Nightly

fxbrit commented 1 year ago

after reading this documentation I get the impression that ETP exceptions only control the "block trackers" aspect of ETP. I tried to get a better understanding by looking at the source code but in all honesty I couldn't wrap my head around the permissions' code further than below notes:

so:

Thorin-Oakenpants commented 1 year ago

OK, I confused this with dFPI vs ETP ... which are different

ghost commented 1 year ago

I understand that FPI is now deprecated, but until this is fixed, how would FPI and dFPI work together?

Thorin-Oakenpants commented 1 year ago

https://github.com/arkenfox/user.js/blob/b117916207862d4785f6da32d48cbe4420372434/user.js#L1009-L1012

repeat .. enabling FPI disables all network partitioning and TCP