I am trying to integrate the stub and cmpapi modules into our CMP, but I am not able to access those modules from javascript. I get a "module not found" error.

This package seems to only be available as "iabgpp" and can be installed by running "npm i iabgpp". I was expecting to be able to install @iabgpp/cmpapi and @iabgpp/stub as individual packages, similarly to the @iabtcf modules.

Is this not being published to npm correctly?

The spec specifies that the getGPPData command should respond with a pingData property. That appears to be missing here

The test for this library are missing test cases for the commands.

Here are some of the things I'm seeing that cause me to believe this command is not fully implemented. Please let me know if I'm missing something.

• I'm seeing a return value from __gpp('addEventHandler') of {param: undefined, next: undefined, callback: ƒ}, which does not match the IAB spec.
• Only the stub code includes an eventName property in the response
• I am unable to trigger an event to fire. After the CMP has loaded, I tried calling cmpApi.setGppString() then cmpApi.fireUpdate().

The stub command queue is getting processed during object initiation of CmpAPI class. As the result, all stub commands coming from the queue are getting processed without user consent. The queue was processed when cmpStatus was loading.

Hi all,

Would you mind clarifying whether https://iabgpp.com is considered as up-to-date?
If yes, should we report bugs on the present issue tracker?
If no, maybe better disable it or at least add a warning banner? Some companies are using it and getting into issues.

Thanks!

When using getSection to retrieve a section, the data comes back as an object rather than an array containing an object. This same problem exists for the pingData.

See the specification:

• https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/CMP%20API%20Specification.md#getsection-
• https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/CMP%20API%20Specification.md#pingreturn-

As far as I can tell, this library doesn't implement the policy rules that are built into iabtcf-es's SemanticPreEncoder and applied when the TC String is created. The result is that this library and the other won't always produce identical TC Strings.

It seems Edge iOS does not supports Sets as iterable. This results in the script error

Uncaught TypeError: Set is not a function or its return value is not iterable
    at s.setValue (cmp.js:2:32561)
    at new s (cmp.js:2:32147)
    at new a (cmp.js:2:61891)
    at t.GppModel.decode (cmp.js:2:27797)
    at t.CmpApi.setGppString (cmp.js:2:6667)
    ....

This limitation appears to be undocumented, at least not something you'll find on MDN or caniuse.com.

A potential fix would be to create a utility function to support this

function setToArray<T>(set: Set<T>): T[] {
  const arr: T[] = [];
  set.forEach(item => arr.push(item));
  return arr;
}

Opened a PR here #6 to illustrate a few cases of the new TCF EU v2 encoder is not able to decode some existing consent strings which work fine with the old encoder.

Prefixes for US National approach sections in this project are uspnat, but per the specification, shouldn't they be usnat?

The spec for the US National section says: "The core segment must always be present". But I'm able to decode GPP strings that don't explicitly include data for the core segment. Is this expected/desired?

Here are some examples...

DBABLA~ decodes as:

{"uspnatv1":{"Version":1,"SharingNotice":0,"SaleOptOutNotice":0,"SharingOptOutNotice":0,"TargetedAdvertisingOptOutNotice":0,"SensitiveDataProcessingOptOutNotice":0,"SensitiveDataLimitUseNotice":0,"SaleOptOut":0,"SharingOptOut":0,"TargetedAdvertisingOptOut":0,"SensitiveDataProcessing":[0,0,0,0,0,0,0,0,0,0,0,0],"KnownChildSensitiveDataConsents":[0,0],"PersonalDataConsents":0,"MspaCoveredTransaction":0,"MspaOptOutOptionMode":0,"MspaServiceProviderMode":0,"GpcSegmentType":1,"Gpc":false}}

DBABLA~YA decodes as:

{"uspnatv1":{"Version":1,"SharingNotice":0,"SaleOptOutNotice":0,"SharingOptOutNotice":0,"TargetedAdvertisingOptOutNotice":0,"SensitiveDataProcessingOptOutNotice":0,"SensitiveDataLimitUseNotice":0,"SaleOptOut":0,"SharingOptOut":0,"TargetedAdvertisingOptOut":0,"SensitiveDataProcessing":[0,0,0,0,0,0,0,0,0,0,0,0],"KnownChildSensitiveDataConsents":[0,0],"PersonalDataConsents":0,"MspaCoveredTransaction":0,"MspaOptOutOptionMode":0,"MspaServiceProviderMode":0,"GpcSegmentType":1,"Gpc":true}}

DBABLA~YA.YA decodes as:

{"uspnatv1":{"Version":1,"SharingNotice":0,"SaleOptOutNotice":0,"SharingOptOutNotice":0,"TargetedAdvertisingOptOutNotice":0,"SensitiveDataProcessingOptOutNotice":0,"SensitiveDataLimitUseNotice":0,"SaleOptOut":0,"SharingOptOut":0,"TargetedAdvertisingOptOut":0,"SensitiveDataProcessing":[0,0,0,0,0,0,0,0,0,0,0,0],"KnownChildSensitiveDataConsents":[0,0],"PersonalDataConsents":0,"MspaCoveredTransaction":0,"MspaOptOutOptionMode":0,"MspaServiceProviderMode":0,"GpcSegmentType":1,"Gpc":true}}

DBABLA~YA.QA decodes as:

{"uspnatv1":{"Version":1,"SharingNotice":0,"SaleOptOutNotice":0,"SharingOptOutNotice":0,"TargetedAdvertisingOptOutNotice":0,"SensitiveDataProcessingOptOutNotice":0,"SensitiveDataLimitUseNotice":0,"SaleOptOut":0,"SharingOptOut":0,"TargetedAdvertisingOptOut":0,"SensitiveDataProcessing":[0,0,0,0,0,0,0,0,0,0,0,0],"KnownChildSensitiveDataConsents":[0,0],"PersonalDataConsents":0,"MspaCoveredTransaction":0,"MspaOptOutOptionMode":0,"MspaServiceProviderMode":0,"GpcSegmentType":1,"Gpc":false}}

The code just uses default values if the string doesn't have any data for the core segment. And if any segment is specified more than once, the last value wins (e.g. in the string "YA.QA", Gpc is false because "QA"--which corresponds to the bit string "010000000000"--comes after "YA"--which corresponds to the bit string "011000000000").

My initial expectation based on the spec was that these strings would be rejected as invalid, but that might just be me. If this is deemed to be undesirable/unexpected behavior, it's worth noting that other sections besides the US National section have the same behavior.

Looks like the spec dictates a value of [0] during loading for applicableSections. The stub here has []

Are we going to support GVLs for different regulations in the library? For example IAB Canada GVL for tcfca ?

Will this package be updated to support v1.1 of the GPP API (changes outlined in this pr - InteractiveAdvertisingBureau/Global-Privacy-Platform#70)

I see that this is not yet released as an npm module, and that there have not been any updates in a couple weeks. Will this code be released as an npm module? If so, what is the anticipated timeline for that release?

The callback in the setTimeout call has a typo. It is calling __gppaddFrame, but should be __gpp_addFrame

I'm trying to understand why CompressedBase64UrlEncoder is written the way it is. More specifically, I'm not sure what this while loop is doing and it seems to me like it can be removed:

    while (bitString.length % 8 > 0) {
      bitString += "0";
    }

Imagine the bitString is 6 bits long. That could be represented as a single base64 digit, but this while loop will add two 0's at the end so that the length of the bitString is 8. Then the subsequent while loop will add four more 0's to get the length of the bitString back to a multiple of 6 (i.e. 12). That is 6 bits of padding and it means that the encoded value in this case has a seemingly unnecessary "A" at the end.

For a more concrete example, consider this test case for the Header section:

  it("should encode section ids [2] to DBABMA", (): void => {
    let headerV1 = new HeaderV1();
    headerV1.setFieldValue("SectionIds", [2]);
    expect(headerV1.encode()).to.eql("DBABMA");
  });

The six bits represented by the "A" at the end of "DBABMA" are unnecessary and the Header can be decoded just fine without it. DBABM~ decodes without issue as:

{"tcfeuv2":{"Version":2,"Created":"Fri Jun 02 2023 15:19:38 GMT-0700 (Pacific Daylight Time)","LastUpdated":"Fri Jun 02 2023 15:19:38 GMT-0700 (Pacific Daylight Time)","CmpId":0,"CmpVersion":0,"ConsentScreen":0,"ConsentLanguage":"EN","VendorListVersion":0,"PolicyVersion":2,"IsServiceSpecific":false,"UseNonStandardStacks":false,"SpecialFeatureOptins":[false,false,false,false,false,false,false,false,false,false,false,false],"PurposeConsents":[false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false],"PurposeLegitimateInterests":[false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false],"PurposeOneTreatment":false,"PublisherCountryCode":"AA","VendorConsents":[],"VendorLegitimateInterests":[],"PublisherRestrictions":[],"PublisherPurposesSegmentType":3,"PublisherConsents":[false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false],"PublisherLegitimateInterests":[false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false],"NumCustomPurposes":0,"PublisherCustomConsents":[],"PublisherCustomLegitimateInterests":[],"VendorsAllowedSegmentType":2,"VendorsAllowed":[],"VendorsDisclosedSegmentType":1,"VendorsDisclosed":[]}}

EDIT/UPDATE: On closer inspection, I see line 272 of the spec actually states that the Header should be encoded as DBABM. But then down below on line 603 it states the same Header should be encoded as DBABMA.

SIDENOTE: this might be obvious to folks who are already experts in Base64 encoding, but the traditional (i.e. non-compressed) base64 encoded string for a Header with a single section ID of 2 (i.e. the same example we used previously) would be DBABMAAA (e.g. see this test). If we drop that padding in order to compress the encoded GPP string as much as possible, then other utilities/libraries that expect traditional Base64 encoding may not be happy. I ran into this when trying to come up with a one-liner on my Mac to convert a base64 string to a bit string. This command produces no output:

echo -n "DBABM" | base64 -d | xxd -b -g0

But adding the full/traditional padding to the end makes the base64 command happy again:

$ echo -n "DBABMAAA" | base64 -d | xxd -b -g0
00000000: 000011000001000000000001001100000000000000000000  ...0..

It might be worth explicitly mentioning somewhere in the spec that if folks, for some reason, want to decode a base64 encoded values from a GPP string using a standard Base64 utility/library, they might need to add "A" to the end of the string until the overall length of the encoded string is a multiple of 4. Or at least that is my current impression based on the example above. Folks with more Base64 knowledge/expertise should feel free to correct me.

The GPP reference library will need to be update to support the TCF v2.2 changes. I also discovered that the TCF section implementation is missing the special policy rules handling (force LI 0 for P1, 2- 6 and syncing the timestamp.)

Same (potential) issue as IABTechLab/iabgpp-java#29

See:

The property named "applicableSections" in the spec is implemented as "applicableSection" in this library

When setting section value with string section value (cmpApi.setSectionString(sectionName, sectionValue)), gppString is unchanged in PingData object.

Here's the reproducible case where you can see that after setting the UspV1 section value, the gppString in the PingData of the event is still set to "DBAA":

import {CmpApi,CmpDisplayStatus,CmpStatus,SignalStatus,UspV1} from "@iabgpp/cmpapi";
import "@iabgpp/stub";

window.__gpp("addEventListener", (e) => console.log(e));

const cmpApi = new CmpApi(-1, 1);
cmpApi.setApplicableSections([6]);
cmpApi.setCmpStatus(CmpStatus.LOADED);
cmpApi.setSignalStatus(SignalStatus.NOT_READY);
cmpApi.setCmpDisplayStatus(CmpDisplayStatus.VISIBLE);
cmpApi.setSectionString(UspV1.NAME, "1YYY");
cmpApi.setCmpDisplayStatus(CmpDisplayStatus.HIDDEN);
cmpApi.setSignalStatus(SignalStatus.READY);

This happens because the "dirty" boolean flag inside gppModel is not set to true when this method is used (only when fields are updated). I think the case above should be supported. Changes to sections via setSectionString should be reflected in gppString in PingData.

Hello -

So we've been tracking the progress of privacy legislation here...

https://iapp.org/resources/article/us-state-privacy-legislation-tracker/

...and noted Oregon and Texas had July 2024 implementation dates coming up, plus Montana coming in October. This is followed up with a whole slew in January 2025 (Delaware, Iowa, New Jersey and Tennessee).

Are GPP section definitions and encoder/decoder implementations in the pipeline for these states?

Many thanks,

Jim