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.
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.
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:
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
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.
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.
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.
BroadcastChannelis 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.