Version
1.1.0-2
Module (core, cmpapi, cli, stub, or testing)
@iabtcf/core
Describe with reproduction steps – What is the expected behavior?
The publisherTC string will always be included in a service-specific consent string, regardless of whether the TCObject contains any data on publisher specific settings and although it should be handled as optional. This results in the decode function not being a proper inverse of the encode function.
The results are seen all over the place, almost 100% of TCStrings that we receive within our network include the publisherTC part set to zero/no consent. We assume this is due to this issue.
In particular:
- start from a TCObject which is service-specific but with empty publisherConsent and empty publisherLegitimateInterest fields
- encode into TCString, the PublisherTC string will be set to YAAAAAAAAAAA, i.e. all bits set to 0
- decode the resulting TCString again
- compare bitLengths of fields publisherConsent and publisherLegitimateInterest in original TCObject and decoded TCObject, in the first, bitLength should be 0, in the latter it will be 24
The expected behavior would be to skip the PublisherTC string during encoding if there is no data set inside of the publisherConsents and publisherLegitimateInterests fields of the TCObject, as inclusion of the PublisherTC string is marked as optional.
some code to reproduce
// Some stub data.
const originalTcModel = new TCModel(new GVL());
originalTcModel.cmpId = 7
originalTcModel.cmpVersion = 15
originalTcModel.consentScreen = 2
originalTcModel.purposeConsents.set(1)
originalTcModel.purposeConsents.set(2)
originalTcModel.purposeConsents.set(3)
/*
Encoding / Decoding part.
*/
originalTcModel.isServiceSpecific = true; // A part of a CORE string.
const originalEncodedString = TCString.encode(originalTcModel);
console.log("Encoded string:" + originalEncodedString);
// Output here is: CO4BOOFO4BOOFAHAPCENAXCgAOAAAAAAAAAAAAAAAAAA.YAAAAAAAAAAA
// YAAAAAAAAAAA - is the publisherTC part, it wasn't set explicitly but automatically.
// And here comes the problem, because the generated string, once decoded,
// generates a different tcModel object, not the same one it was encoded from.
// Original model tells us that there is no publisherTC purposes set.
console.log("Original publisher purposes bits length:" + originalTcModel.publisherConsents.bitLength);
console.log("Original publisher LI bits length:" + originalTcModel.publisherLegitimateInterests.bitLength);
// Outputs: 0
// No bits set.
// Lets decode that string back.
const decodedTCModel = TCString.decode(originalEncodedString);
console.log("Decoded publisher purposes bits length:" + decodedTCModel.publisherConsents.bitLength);
console.log("Decoded publisher LI bits length:" + decodedTCModel.publisherLegitimateInterests.bitLength);
// Outputs: 24
// Now all bits are set to 0, which means no consent/user objection on all purposes.
Version
1.1.0-2
Module (core, cmpapi, cli, stub, or testing)
@iabtcf/core
Describe with reproduction steps – What is the expected behavior?
The publisherTC string will always be included in a service-specific consent string, regardless of whether the TCObject contains any data on publisher specific settings and although it should be handled as optional. This results in the decode function not being a proper inverse of the encode function.
The results are seen all over the place, almost 100% of TCStrings that we receive within our network include the publisherTC part set to zero/no consent. We assume this is due to this issue.
In particular:
The expected behavior would be to skip the PublisherTC string during encoding if there is no data set inside of the publisherConsents and publisherLegitimateInterests fields of the TCObject, as inclusion of the PublisherTC string is marked as optional.
some code to reproduce