Is mspa/activityControls.js sufficiently type safe?

[decaffeinatedio]

Type of issue

Bug

Description

From my read, it looks like this line in activityControls.js expects an array in every case that the parsedSections?.[api] response is not null. However, GPP documentation defines the parsedSections as an object.

As a result, on some sites that have implemented I'm seeing errors like:

WARNING: Activity control: MSPA (GPP 'usnat' for section 7) denied 'syncUser' for 'bidder.criteo': TypeError: e.reduceRight is not a function

Unsurprising, I'm seeing some inconsistency across GPP implementers, but objects appear to be common!

Steps to reproduce

I'm observing this from the outside, but it appears that the combination of object response from GPP parsedSections and usage of gppControl_usnat does the trick.

Test page

Can provide some URLs where I've observed this in a DM.

Expected results

No type errors.

Actual results

TypeError

Platform details

N/A

Other information

N/A

[patmmccann]

parsed sections should only ever be an object

[dgirardi]

The values in parsedSections are supposed to be arrays of objects:

parsedSections: Object // [...] The object contains one property for each supported API with the name of the API as the property name and the value as a parsed representation of this section (similar to getSection command). [...]

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

The parsed representation of a section is an array of objects, where each object represents one sub-section of this section in the order that is given by the section specification.

So that screenshot is actually out of spec @patmmccann ! That's an argument for supporting the de-facto standard.

[patmmccann]

Ian please dm me the test page before we merge