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

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

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

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?

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

• if you remove your clear cookies and site data exception for facebook (meaning you will have to login each time), does this still happen (might get slightly tricky to debug if you don't need a dFPI exception to login, IDK cuz I never use FB)

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

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

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.

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?

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

user.js/user.js

Lines 773 to 779 in ea139e3

	/* 2702: disable ETP web compat features [FF93+]
	* [SETUP-HARDEN] Includes skip lists, heuristics (SmartBlock) and automatic grants
	* Opener Heuristics are granted for 30 days and Redirect Heuristics for 15 minutes, see [3]
	* [1] https://blog.mozilla.org/security/2021/07/13/smartblock-v2/
	* [2] https://hg.mozilla.org/mozilla-central/rev/e5483fd469ab#l4.12
	* [3] https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning#storage_access_heuristics ***/
	// user_pref("privacy.antitracking.enableWebcompat", false);

#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.

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

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?

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

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.

How do you guys currently recommend to proceed with this problem

• resolve the bugzilla
• be judicious in what you keep - e.g. I only have six of which only one is used on other domains for SSO (github) - none are content providers like youtube - so if I really wanted to, I could use uBO to globally block those six domains except first party
• use containers/TC I guess, I have never bothered with them
• use a secondary browser for entertainment

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

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

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

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!

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?

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

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:

• ETP exceptions fall under the trackingprotection type -> https://searchfox.org/mozilla-central/source/browser/components/preferences/dialogs/permissions.js#325-334
• there's also a cookie type in the same file
• trackingprotection is used in ContentBlockingAllowList.cpp

so:

• pretty sure ETP exceptions don't overlap with cookie exceptions: if you whitelist a website from ETP, its cookies are not kept on close; according to 1767271 cookie exceptions overlap with Total Cookie Protection instead (and we already knew this).
• TCP had overlap with ETP but now it kinda doesn't since it's enabled in all modes. additionally, in the code ETP strict only flipped the cookieBehaviour pref with no other interaction with isolation, so I don't think the two are tightly coupled which would explain why their permissions don't overlap.

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

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

repeat .. enabling FPI disables all network partitioning and TCP