> 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.
Bug 1899092 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> 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.