Every trusted signal is a potential target for forgery, and privacy consent signals are no exception. Confiant’s Privacy Team looks out for possible violations of the Interactive Advertising Bureau's (IAB) framework for the California Consumer Privacy Act of 2018 (CCPA) and IAB Europe's framework for the General Data Protection Regulation (EU) 2016/679 (GDPR), including consent string tampering. Consent tampering is when an entity operating on a page makes an unauthorized change to a consent signal or creates a fraudulent signal. Recently our analysis detected behavior by a vendor that we believe constitutes a clear incident of consent string tampering and a violation of IAB and IAB Europe policies and privacy regulations.
The publisher on whose site this vendor operates uses a Consent Management Platform (CMP) powered by Admiral, which is operating correctly. The CMP is in charge of providing a user with notice of a page's data collection practices and collecting their privacy preferences. However we detected in scans that Marfeel, a third-party vendor operating on the page and in the ad stack, had an alternative, encoded IAB Europe Transparency & Consent Framework (TCF) v2.0 consent string hardcoded and ready to use. A consent string is an encoded data structure which a CMP uses to record a data subject’s tracking preferences after they have interacted with the cookie banner, and then communicate those preferences to vendors operating on the page. Marfeel's exact hardcoded consent string was present in scans regardless of whether or not the CMP, Admiral, had already created a legitimate consent string.
Marfeel is registered with IAB Europe as a CMP (CMP ID 181). However, despite the presence of some CMP code in the file where we found the consent string, it is not acting as a CMP on this page, but rather running a client-side auction across many Supply-Side Platforms (SSP) within the ad tags. SSPs are used by a publisher to help sell ad space on their site, and Marfeel is helping the publisher to collect bids through multiple SSPs to get the best price. Despite being registered, we were unable to find any cases of Marfeel actually acting as a CMP. Therefore there is no valid reason for Marfeel to be creating consent strings on this page at all, let alone hardcoding a consent string in advance.
In the code that appears in the ad stack, Marfeel consumed the consent string from the TCF API, which is expected behavior. It then sent the consent string to the SSPs who were bidding in the auction. However, if no consent string was available, Marfeel defaulted to this hardcoded TCF v2 consent string which, when decoded, listed Marfeel’s CMP ID (181), instead of Admiral’s (9), and had all vendors, purposes, features, and legitimate interests set to true. It was essentially a generic "Accept All" consent string. Marfeel is not only a registered CMP but also a registered vendor on IAB Europe's Global Vendor List (GVL), operating under vendor IDs 270 and 943. Marfeel has two separate vendor ids because it has two separate GVL registrations covering separate products. Marfeel's Compass product covered under vendor ID 943 is actually certified by National Commission on Informatics and Liberty (CNIL) as exempt from consent because it meets the requirements of an audience measurement tool that is strictly necessary to provide a service. Marfeel's IDs were listed as having consent in the vendorConsents dictionary of the decoded string, along with hundreds of other vendors. The consent string didn’t only give consent to Marfeel but there was certainly an element of self-dealing here. If Marfeel was unable to retrieve a legitimate consent string from the TCF API, it simply sent this convenient default "Accept All" consent string to bidding SSPs instead.
Marfeel’s code also contained two hardcoded US Privacy consent strings, which are the standard defined by the IAB's CCPA Compliance Framework for collecting consent in California. The strings we found were: 1YNN, which ostensibly means that explicit notice was given and the user did not opt out of selling their data and 1YYN, which is meant to indicate that explicit notice was given and the user did opt out of selling their data. The script appears to consume the US Privacy API and then substitute one of its strings depending on the presence of a value, similar in effect if not structure to how it processes the TCF consent string.
There is no user interface (UI) within Marfeel’s code to provide notice or accept a clear affirmative action from a user. Nor does the code listen for events from a UI which could do that. Nevertheless, in each of Confiant’s scans where Marfeel was present during the time of the incident, these exact consent strings appeared in Marfeel’s code.
It does not look like these alternative consent strings would necessarily replace the existing legitimate consent strings in the auction if Marfeel was able to retrieve them. However, our page scans have shown Marfeel sending both the hardcoded TCF v2 and the 1YNN US Privacy Strings to SSPs in URL parameters (the information included in the query string after the ‘?’ in the URL) as part of a cookie sync script outside of the ad tag code, regardless of whether consent had been collected and a legitimate consent string existed.
The creation and use of these hardcoded consent strings could put Marfeel in violation of several IAB Europe CMP policies, because a CMP (Marfeel) must only generate positive signals for consent, legitimate interest, and special features on the basis of a clear affirmative action taken by a user that unambiguously signifies that user’s agreement, and on the basis of the provision of transparency by the CMP. Marfeel’s code does not allow for the provision of transparency to users or any means for a user to provide a clear affirmative action, since it provides no UI for a user to interact with. The consent strings are hardcoded and therefore already present and, in the case of the TCF v2 string, encoded, regardless of any possible user action. However, despite Marfeel using its own CMP ID to create this consent string, the fact that Marfeel is not acting as a CMP on this site (or anywhere else that we were able to find) might spare it from CMP compliance enforcement.
Marfeel is also in violation of IAB Europe vendor policies because Section 13.6 states that a “Vendor must not create Signals where no CMP has communicated a Signal, and shall only transmit Signals communicated by a CMP or received from a Vendor who forwarded a Signal originating from a CMP without extension, modification, or supplementation, except as expressly allowed for in the Policies and/or Specifications.” Not only is Marfeel in violation by creating and transmitting a consent signal where it is not the acting CMP but it is exposing the SSPs receiving those hardcoded consent strings in the cookie sync script to potential liability as well, especially if they then pass the consent string they received from Marfeel to another vendor.
According to IAB Europe's TCF Vendor Compliance Programme, "if this is the first, second or third time a breach has been identified, in each instance, the Vendor will be given 28 calendar days to remedy the issues. If, following the expiration of the 28 day period, the issues have not been resolved, the Vendor will be suspended from the Framework and removed from the Global Vendor List until all compliance failures have been remedied;" so Marfeel can have a total of three strikes before another violation would cause it to be suspended and removed from the vendor list.
Article 4 of the GDPR defines consent as “any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;” Marfeel’s hardcoded consent string does not allow for transparent, freely given consent from the data subject and does not meet the standard for GDPR consent.
The CCPA requires a Notice at Collection outlining the categories and purposes of personal information that will be collected from the consumer and, if the business sells that data, they are required “to provide a clear and conspicuous ‘Do Not Sell My Personal Information’ link on their website that allows you to submit an opt-out request.” This request is what the IAB’s US Privacy framework is meant to capture and despite containing two US Privacy consent strings, one of which does signal an opt-out, Marfeel’s code does not appear to have any means of providing notice or collecting an opt-out request from the user.
The script containing the hardcoded consents was first found in ad tag code.
In the code above, Marfeel first checks for what would likely be the legitimate TCF v2 consent string and, if it is not found, substitutes its hardcoded consent string instead.
In the above code, ‘e’ refers to a value retrieved from the US Privacy API (__uspapi). Because of the structure of this statement, a hardcoded US Privacy consent string would be used regardless of the truthiness of ‘e’, but one of the options does allow for the case where a user may have opted out of the sale of their information.
Page scans like this one show Marfeel passing the hardcoded consent strings above to SSPs through this cookie sync script.
In the above examples, even though there were two hard-coded US Privacy strings available, the one that was used was the 1YNN string indicating a user that had not opted out of the sale of data. This was the case in every payload we checked.
Oddly, the gdpr applies flag was set to true (1) and both the GDPR and US Privacy strings were present, regardless of the jurisdiction of the scan, as if to ensure all bases were covered at all times.
Below is a snippet of the decoded TCF v2 consent string that Marfeel’s code contained.
The CMP operating on the page where the incident was discovered is Admiral which has CMP ID 9. Marfeel’s CMP ID is 181, which matches the value of the cmpId key in the consent data structure. I have truncated it because the full decoded consent string is very long. The UNIX timestamps in the created and lastUpdated keys convert to Wednesday, September 22, 2021 9:25:30.700 AM GMT, which is exactly one month earlier than the first scan in which we detected this string.
"core": {
"version": 2,
"created": 1632302730700,
"lastUpdated": 1632302730700,
"cmpId": 181,
"cmpVersion": 2,
"consentScreen": 1,
"consentLanguage": "EN",
"vendorListVersion": 107,
"policyVersion": 2,
"isServiceSpecified": true,
"useNonStandardStacks": false,
"specialFeatureOptins": {
"1": true,
"2": true
},
"purposeConsents": {
"1": true,
"2": true,
"3": true,
"4": true,
"5": true,
"6": true,
"7": true,
"8": true,
"9": true,
"10": true
},
"purposeLegitimateInterests": {
"2": true,
"3": true,
"4": true,
"5": true,
"6": true,
"7": true,
"8": true,
"9": true,
"10": true
},
"purposeOneTreatment": false,
"publisherCountryCode": "AA",
Confiant immediately notified IAB Europe’s TCF Compliance Team, who investigated the issue and informed us that they would be in contact with Marfeel. It appears that as of Sunday, December 12th, 2021 Marfeel has corrected the issue as we are no longer seeing the default consent string being passed in the cookie sync script. However we have scans that show this behavior going back at least as far as October 22, 2021, which means that this hardcoded consent string was being used for months and could have gone on indefinitely had we not caught and reported it.
Marfeel is still registered with TCF as a CMP and as a Vendor, indicating that this is likely a first (but possibly as high as third) offense. According to the TCF Vendor Compliance Programme, if they have remedied the issues within 28 days, they will not be suspended from the framework or removed from the list.
The hardcoded TCF v2 consent string has been removed from Marfeel’s ad tag code, but the US Privacy strings remain. They have been updated to 1YNY and 1YYY, the final characters in both strings changed from N to Y, indicating a Limited Service Provider Agreement with the IAB.
IAB Europe’s TCF framework and the IAB's US Privacy framework are not necessarily more vulnerable to abuse than any other consent structure in use today but an inauthentic consent creates widespread potential liability for unsuspecting vendors that may consume it. Not only might they pass a fraudulent consent string further downstream, but they might be bidding for ad space based on misleading information, and inadvertently collecting consumer data without consent. The fact that we are now seeing this behavior in the wild is very alarming for publishers and vendors who could be victimized by unscrupulous actors in the chain of consent and for data subjects whose rights are being violated.