Proposal: Ensuring CMP cross-context consistency with Broadcast Channel API

[Leedehai]

This issue proposes a way to deal with CMP inconsistencies across browsing contexts (e.g. tabs or iframes) from the same origin.

Problem

Currently, the spec cannot guarantee the consent states’ consistency across multiple browsing contexts in the same client. For example, a user might be perplexed by this situation:

• User has tab 1 and tab 2 open on the same website and have the same consent states.
• User changes their consent in tab 1.
• Now, the user reasonably expects whatever choice they changed in tab 1 will be synchronized to tab 2–after all, they are on the same website. But the reality is the consent state queried from tab 2 is still the original one, different from tab 1.

The cause of this situation is that the CMPs running in multiple tabs’ JS contexts don’t have a way to synchronize their states.

Idea

The spec shall add in the CMP implementation guideline doc that

• A CMP shall ensure that the consent state it surfaces to calling scripts in a publisher window must be consistent with other browsing contexts of the same publisher origin. Once the consent state changes, this change shall be synchronized to other said browsing contexts as well.
• Suggested implementation: to achieve this consistency, a CMP shall create and maintain a BroadcastChannel object.

  • The name of this object shall be unique among different CMP vendors, so that the CMPs from different vendors don’t cross-talk with each other, e.g.

    const channel = new BroadcastChannel("ExampleCmpVendor");

    • This naming scheme is not intended to prevent tampering or eavesdropping. That is, an attacker could create a broadcast channel using the same name and then send or receive messages on this channel.
    • The Broadcast Channel API guarantees that broadcast channels of the same name but in contexts of different origins are isolated from each other; therefore, it is not necessary to include the publisher origin in the broadcast channel name.

  • Whenever a consent state changes internally, it shall post a message to this channel object, notifying peer CMP instances in other browsing contexts.

    channel.postMessage(messageData);

    • Though the message data type is up to CMP implementations, the type must be serializable using the structured clone algorithm.

  • The CMP instance shall add a listener on the channel object so as to receive notifications from peer CMP instances from other browsing contexts.

    channel.onmessage = (event) => { useMessageData(event.data); };

• The usage of BroadcastChannel is a CMP internal detail, and therefore completely transparent to the calling scripts that communicate with the CMP. In other words, the API shall remain the same and the calling scripts shall be agnostic of this synchronization feature.

[anderagakura]

Linked to the following issues USPrivacy issue 20 and GPP issue 34

Just wondering : No matter if the consent is different between Tab 1 and Tab 2 from this visitor, the negative consent is not supposed to be superior to a positive consent? Which means that the vendors behind will have to monitor

cc @dmdabbs @janwinkler

[Leedehai]

Re: the negative consent is not supposed to be superior to a positive consent?
I don't have a definite answer for this, but I think my proposal does not affect this.

The proposal is that the CMP should ensure it gets the most up-to-date state from all browsing contexts (e.g. tabs). That is, if a state changes in one tab, CMPs running in all browsing contexts shall know, and the CMP shall surface that up-to-date state to client scripts (e.g. via getTCData() or a listener installed by addEventListener).

Re: the vendors behind will have to monitor
Yes, the CMPs need to monitor the channel using an event listener.

[HeinzBaumann]

The TCF Framework Signal Working Group reviewed this issue today. It was determined that the TCF Policy Working Group has to review this to determine whether this use case is important enough to find a resolution for.