1899092 - tracking protection blocks CMP CookieBot in private windows

Status: NEW

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

Description

[Sören Hentzschel]

Firefox blocks https://consent.cookiebot.com/uc.js in private windows. Please note that this issue is not about the cookie banner blocker. It also happens with disabled cookie banner blocker, and even if the cookie banner blocker is enabled, it still allows to manually open the consent dialog.

In this case, CookieBot is blocked by the Enhanced Tracking Protection, probably due to https://github.com/mozilla-services/shavar-prod-lists/commit/5395b57a69f431fd550530ad385107870cfc40c2. This is a serious issue as it blocks the access to the cookie consent dialog (you even can't manually open the dialog) and therefore potentially causes website breakage without user choice (except by disabling the tracking protection - but that's neither obvious nor desirable).

CookieBot is a very popular Consent Management Platform, it's not a tracking tool and should therefore not be blocked by the tracking protection.

As an example, you could load https://www.wellnesshotel.com/en in a private window and click the "Privacy Settings" link in the footer. Instead of opening the consent dialog, an error appears in the console: Uncaught TypeError: Cookiebot.show is not a function

Comment 1

[Pascal Chevrel:pascalc]

Tim is that a regression? Could you prioritize this bug? Thanks

Comment 2

[Paul Zühlcke [:pbz]]

A sensible workaround for this could be to offer users to temporarily relax protections from "strict" to "standard". We could support that in both normal and private browsing windows.

Comment 3

[Tim Huang[:timhuang]]

Technically, this is not a regression. As comment 0 mentioned, this is because of a recent update from the Disconnect list. There are several approaches to tackle this issue.

1. Request a reclassification on Disconnect side to reclassify cookiebot.com as a content tracker
2. Develop a shim script to replace the blocked script to fix the page
3. Temporarily relax protections as Paul suggests
4. Disable ETP protection for the affected site via the shield panel.

Comment 4

[Sören Hentzschel]

Whatever the solution is, I hope this can be resolved as soon as possible.

Please note that this issue affects website functionality on a lot of websites, like embedded maps, videos, and more that can no longer be loaded at all in private mode or even in regular mode with strict tracking protection. It may not be a regression from the Firefox POV, but from the user's POV it's a regression, as it's a recent and undocumented change in behavior.

Normally, website developers implement an opt-in that users see instead of the embedded thing so that they can give the consent by demand, but that's broken as well due to this issue. There is no indication to the user that it's caused by the tracking protection (apart from a console warning, where the regular user usually can't see a relation to the problem), and it just makes no sense that a CMP is blocked by the tracking protection.

This is not only an issue for users of the affected websites. I integrated CookieBot for several hotel websites in the last few months, and for hotel websites it can have a real impact on their revenue if potential guests can't see the location on a map, or the embedded videos that presents the destination because these things can influence the decision to book or not to book.

Comment 5

[Daniel Holbert [:dholbert]]

[Ran across this in regression triage]

(In reply to Tim Huang[:timhuang] from comment #3)

1. Request a reclassification on Disconnect side to reclassify cookiebot.com as a content tracker

What's the process for this? Given the pervasiveness of CookieBot for cookie-consent-management, we probably need to take some sort of action here, lest this end up effectively shipping as a regression in Firefox 128 from users' perspectives.

(I'm not sure option 2, developing a shim, is tractable here; and options 3-4 seem to be workarounds on the user side which we perhaps don't want to lean too heavily on users figuring-out-how-to-do when we're essentially shipping a behavior change)

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Also, can we set a severity on this bug? Sounds S2-ish to me.

Comment 7

[Tim Huang[:timhuang]]

To request a reclassification, an issue needs to be filed against Disconnect's repo. After that, Disconnect will take a deeper look into the site for the reclassificaiton. The site can either stay at the same category or be moved to the new category. We don't have control on the result.

I've filed an issue: https://github.com/disconnectme/disconnect-tracking-protection/issues/353

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

For now the workaround would be to disable strict mode for that site.
This may affect Nightly users more strongly since strict mode is enabled by default there, and people who use private browsing by default.
Disconnect closed the issue already but reported it to Usercentrics.
Tim, what do you think the next steps should be?
And, can you set a severity and priority for the bug?

Comment 9

[hyebahi]

There have been different requests to allow CMP vendors to load. Following the thread below, it seems that Disconnect is planning to create a separate categorization for CMPs like OneTrust, TrustArc, Quantcast, CookieBot, etc.
https://github.com/disconnectme/disconnect-tracking-protection/issues/354

Comment 10

[Tim Huang[:timhuang]]

We have discussed this internally. We conclude that blocking CookieBot matches privacy expectations in ETP strict mode and private windows. Given the assessment from Disconnect, blocking cookieBot as a tracker protects users from tracking and improves privacy. Even though blocking CookieBot could cause website breakage, it's a trade-off for providing a more private browsing experience in ETP strict and private windows.

The breakages mentioned in the bug are typical tracking protection breakages, and we haven't seen many because of this. So, we think this is not that severe, given that users can still disable ETP protection to make the site work. In the short term, we don't have the proper tool to fix the issue here. However, we would love to see more related reports to keep track of the issues closely and figure out a more general solution in the future.

Note that this doesn't strongly impact the Nightly channel because ETP strict is not the default setting there.

Comment 11

[Sören Hentzschel]

We conclude that blocking CookieBot matches privacy expectations in ETP strict mode and private windows. Given the assessment from Disconnect, blocking cookieBot as a tracker protects users from tracking and improves privacy.

I disagree with that assessment. To protect the privacy is the task of the CMP, which website operators in the European Union are legally obliged to do. Disconnect's reasoning ("several portions of the Usercentrics/Cookiebot policy and website marketing seem to support the current classification" and the following quotes) sounds as if Disconnect has not understood what the whole point of a CMP is - to give the user a choice. Things like personalization are okay if the user explicitly requests this. A CMP could even block things that are not on Disconnect's list and therefore be better for privacy. This certainly does not apply in every case. But to say that blocking the CMP is always better for privacy does not apply either.

The breakages mentioned in the bug are typical tracking protection breakages

I have to disagree here as well. It's not "typical tracking protection breakage" as with a CMP, you usually implement fallback screens to give the user a choice so that they can opt-in by demand. For me, that's totally different from "typical tracking protection breakage" where something is broken for non-obvious reasons due to hidden tracker.

and we haven't seen many because of this

I can give you more examples for websites breakage. As part of my work for an agency, I implemented CookieBot on several websites, so it's not difficult for me to show you breakage on more websites. According to CookieBot, it's used on 2.2 million websites, and I am sure you will find breakage on many of them, as the whole point of a CMP is to provide an alternative experience for disabled trackers and still give the user an option to accept a tradeoff for specific cases, like watching a video or viewing a map.

given that users can still disable ETP protection to make the site work

Okay. But how is the user supposed to know that? It's not obvious at all that the tracking protection causes the CMP to break. CMPs are primarily a thing in the European Union. And users in the European Union are used to see CMPs as a measure introduced by the legislator to improve privacy. And therefore, it's unexpected for us to see the CMP blocked by the tracking protection.

Comment 12

[Paul Zühlcke [:pbz]]

To protect the privacy is the task of the CMP, which website operators in the European Union are legally obliged to do.

There is a difference between legal obligation and technical enforcement.

[...] sounds as if Disconnect has not understood what the whole point of a CMP is - to give the user a choice

A CMP may enable user choice, but that doesn't technically prevent the CMP from doing tracking themselves.

A CMP could even block things that are not on Disconnect's list and therefore be better for privacy.

Yes, possibly. How does this block mechanism work? From what I've seen from CMP libraries they communicate with external scripts in the page once the user submits their consent choice. If we block the CMP from loading this consent choice / callback is never submitted and thus the tracker / third party script never fully inits / loads. Is that assessment correct?

[...] with a CMP, you usually implement fallback screens to give the user a choice so that they can opt-in by demand

You can still give users that fallback screen by checking if loading a third-party resource, say an Instagram embed loaded successfully. That seems like a more robust way of doing this anyway which would also help for other load issues.

Okay. But how is the user supposed to know that? It's not obvious at all that the tracking protection causes the CMP to break

Agreed! This can be really confusing for users. This is a common scenario in ETP "strict" though. This mode is a tradeoff and users should choose it if they want increased privacy at the cost of reduced web compatibility. That's why it's not our default mode. We talk about that in about:preferences but we could still do a better job at communicating that to users and reminding them in-context that a site may be partially broken. Detecting webcompat issues heuristically isn't trivial though.

Edit:
While it's nice that we mostly aligned ETP "strict" mode with private browsing now, it can lead to issues. Some users expect higher privacy protections in PBM, i.e. they expect a "strict" mode, while others don't use PBM for privacy protections but rather for the ephemeral state, e.g. "secretly shopping for gifts that shouldn't end up in their browser history". For the latter case users may still want a higher degree of webcompat. It would be good if we could find a way to accommodate both of these use cases. Perhaps with a simple toggle in PBM to turn "strict" behaviour on and off.