Update the base64 encoder padding to match the spec#86
Conversation
| while (bitString.length % 8 > 0) { | ||
| bitString += "0"; | ||
| } |
There was a problem hiding this comment.
This is needed for spec compatibility because one base64 character represents 8-bits of data.
There was a problem hiding this comment.
What you say is to not do this change (PR) at all. This is the only change to code. All other changes update the test cases.
There was a problem hiding this comment.
Please tell my why this change is necessary.
If you start encoding using only % 6 for padding, you will create a misaligned byte string upon decoding when you use this for TCF strings (which GPP is also responsible for).
This is fine if you are reading/writing using ONLY this library, but you are creating a GPP string that is going to be read and decoded by multiple third party decoders that expect a valid byte[]. Using only % 6 creates a misaligned byte array that would be considered invalid by many other decoders.
GPP requires alignment on 6 bits:
https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/Consent%20String%20Specification.md#creating-a-gpp-string
TCF requires alignment on 8 bits. This requirement has never been altered since v1.1 and there has been no reference to a change in any TCF updates:
https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/10b489eae0d5328e07241001520d984e15afb59a/Consent%20string%20and%20vendor%20list%20formats%20v1.1%20Final.md?plain=1#L316
Therefore, padding to the LCM of 8 and 6 is necessary (LCM=24 because 6*4=24 and 8*3=24).
Since this is a common encoder/decoder, it is used for both TCF and other GPP represented strings. Simply forwarding the TCF portion of the string to a TCF decoder would produce an error if the encoder only padded using 6 bits.
There was a problem hiding this comment.
EU TCF strings don't actually use this class. They use TraditionalBase64UrlEncoder instead so they will be unaffected by this change.
Having said that, your point is valid regarding compatibility. The current implementation is incompatible with the current version of the spec. This change is to make it conform to the spec version that was released Dec 2022.
| while (bitString.length % 8 > 0) { | ||
| bitString += "0"; | ||
| } |
There was a problem hiding this comment.
What you say is to not do this change (PR) at all. This is the only change to code. All other changes update the test cases.
# Conflicts: # modules/cmpapi/test/GppModel.test.ts
The other two TCF CA v1 segments (Core, PublisherPurposes) already use CompressedBase64UrlEncoder, matching the GPP spec's pad-to-6 rule for sections using the recommended base64-websafe encoding. The DisclosedVendors segment was an outlier, using TraditionalBase64UrlEncoder (pad-to-24) — likely a copy-paste from the TCF EU equivalent. The Java sibling library has always used CompressedBase64UrlEncoder for this segment; this brings the TS implementation into agreement.
3 participants
No description provided.