1590944 - Enhanced Tracking Protection interferes with Workplace.com, breaks m.facebook.com

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect)

Description

[Vladan Djeric (:vladan)]

Attachment: Blocked CDN URLs on desktop

1. A Facebook developer discovered that Firefox’s new Enhanced Tracker Protection is blocking Facebook's CDN URLs (e.g. xx.fbcdn.net) on Facebook’s workplace.com domain. Workplace is an enterprise collaboration product much like Yammer except made by Facebook (https://www.facebook.com/workplace). It seems incorrect to block Facebook content while the user is using a Facebook product.

Some of us can reproduce this on Desktop Firefox 70, but some can only reproduce it in Desktop Nightly 72.

2. The developer also reports that enhanced tracking protection in Firefox Mobile is blocking all CSS and JS on m.facebook.com for him.

Comment 1

[Vladan Djeric (:vladan)]

Attachment: Desktop configuration

Comment 2

[Vladan Djeric (:vladan)]

Attachment: m.facebook.com blocking in Firefox Mobile

Comment 3

[Daniel Lo Nigro (daniel15)]

I think this Web Compat bug is related: https://webcompat.com/issues/41132

Comment 4

[Steven Englehardt [:englehardt]]

Thanks for the report! I believe this can be fixed by adding workplace.com to the Facebook entity on Disconnect's entitylist. I've filed https://github.com/disconnectme/disconnect-tracking-protection/issues/104 for that and will update this bug with status on that.

Based on the screenshots in Comment 0 and Comment 2, the completely broken site experience (CSS/JS) is due to the STP list pulling in fbcdn.net from the Content category of the Disconnect list. This is fine when the STP list is used for cookie blocking, since we want to block cookies from the Content category by default anyway. However, it seems like a bad idea when the STP list is used for tracker blocking. That's the case for "Strict" mode of Firefox desktop and the default mode of Fenix.

Tanvi, what do you think about excluding domains from the STP list that are in the Content category? We know that blocking content from origins in those categories typically causes a ton of breakage, like we're seeing here.

Comment 5

[(no longer active)]

Thanks for the bug report, Vladan!

Steven, was there a reason why you set this bug to block bug 1501461? I don't see how this is related to blocking cookies from the level 2 list, especially given comment 4.

(BTW do we need to file another bug to track the m.facebook.com breakage since the fixes for the two issues are different?)

Comment 6

[Daniel Lo Nigro (daniel15)]

(In reply to :ehsan akhgari from comment #5)

(BTW do we need to file another bug to track the m.facebook.com breakage since the fixes for the two issues are different?)

Sorry, I think that was my fault for a lack of clarity in the info I gave to Vladan. The Facebook mobile site is only broken for Workplace instances (.m.workplace.com), regular m.facebook.com is working fine.

Comment 7

[Steven Englehardt [:englehardt]]

(In reply to :ehsan akhgari from comment #5)

Steven, was there a reason why you set this bug to block bug 1501461? I don't see how this is related to blocking cookies from the level 2 list, especially given comment 4.

I did that because of comment 2, which I took to imply that some breakage is visible when cookies are blocked. The STP list contains domains from the the level 1 and level 2 list, and I suggested in comment 4 to stop including domains from the level 2 list. But even if we do that, ETP blocking the level 2 list might re-introduce such breakage. I recognize now that we don't have enough info to determine whether that will be the case.

There are two bug reports here:

1. Breakage from blocking requests to fbcdn.net, which happens in the "Strict" mode of Firefox desktop and the default mode of Fenix. This is the same breakage we're seeing on oculus.com (Bug 1591480).
2. Breakage from blocking cookies on desktop, either to fbcdn.net or facebook.net (aka the "Standard" mode config shown in Comment 2).

vladan or daniel: would you mind to provide more detail on the type of breakage you're seeing from (2)?

Comment 8

[Daniel Lo Nigro (daniel15)]

(In reply to Steven Englehardt [:englehardt] from comment #7)

vladan or daniel: would you mind to provide more detail on the type of breakage you're seeing from (2)?

I haven't hit issues with this myself, but a few other employees reported that they encountered issues with Workplace in Firefox "standard" mode until they disabled the tracking protection on workplace.com. I'll see if I can get more details!

Comment 9

[Tanvi Vyas[:tanvi]]

From the comments here and the webcompat bug linked, it seems like the issue with workplace.com will be fixed by updating the entity list, as Steve described. That should fix the behavior in both Standard mode (cookie blocking) and Strict mode (tracker blocking) for facebook pages.

Is blocking fbcdn.net causing breakage issues on non-facebook pages?

Comment 10

[Steven Englehardt [:englehardt]]

(In reply to Tanvi Vyas[:tanvi] from comment #9)

Is blocking fbcdn.net causing breakage issues on non-facebook pages?

I haven't seen any myself.

I'm going to marked this as fixed now that workplace.com has been added to Disconnect's entity list (https://github.com/mozilla-services/shavar-prod-lists/pull/78). I've verified that the site loads correctly when Strict mode is enabled.

I've also reached out to a contact at Facebook that has been able to use workplace.com without issues in FF70 standard mode. Daniel, if you do learn of breakage from the standard mode, please file a new bug that blocks Bug 1480137. Thank you!