UserId module: allow to configure a transformation for the ppid

[robin-crazygames]

The user id module allows to configure to use an identity provider as ppid for GAM using the ppid property:

function getPPID(eids = getUserIdsAsEids() || []) {
  // userSync.ppid should be one of the 'source' values in getUserIdsAsEids() eg pubcid.org or id5-sync.com
  const matchingUserId = ppidSource && eids.find(userID => userID.source === ppidSource);
  if (matchingUserId && typeof matchingUserId?.uids?.[0]?.id === 'string') {
    const ppidValue = matchingUserId.uids[0].id.replace(/[\W_]/g, '');
    if (ppidValue.length >= 32 && ppidValue.length <= 150) {
      return ppidValue;
    } else {
      logWarn(`User ID - Googletag Publisher Provided ID for ${ppidSource} is not between 32 and 150 characters - ${ppidValue}`);
    }
  }
}

There is already some replacing going on to fulfill the GAM requirements for ppid:

    const ppidValue = matchingUserId.uids[0].id.replace(/[\W_]/g, '');

However, most of the ids will still fail the length check, and hence cannot and will not be used as ppid.

It also means that, even if you choose a user id provider that uses a short id, the user id provider might upgrade/change their id in the future and suddenly you're no longer sending a ppid to GAM.

Not sure what the best solution is (hence why I open an issue and not a PR):

• Have a configuration option to specify a transformation function, where the default would be the current replacement function. That way, I can for example specify to use a sha256 hashing function where I know the result will always fulfill the GAM requirements.
• Instead of specifying a full transformation function, just allow to choose from some defaults (trim, sha256, replace)?
• Something else I haven't thought of yet

The reason I want to do it through Prebid and not just set the ppid myself is that Prebid contains check on whether the user allowed enrichment. Otherwise I would have to duplicate those checks.

I'm willing to create the PR for this. Just need some guidance on what the preferred approach would be (if you think this issue is worth fixing).

[patmmccann]

I think trim may prove problematic, i'd prefer a hash to hit the length requirement, preferably hitting exactly 32 characters

ai suggests

async function get32CharHash(message) {
  const msgBuffer = new TextEncoder().encode(message);
  const hashBuffer = await crypto.subtle.digest('SHA-256', msgBuffer);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  
  // Convert bytes to hex string
  const hashHex = hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
  
  // Truncate the 64-character hash down to 32 characters
  return hashHex.substring(0, 32);
}

i'd also put it in an else statement if the length check fails, not hash everything

it also seems to length requirement and illegal characters have changed, we can drop the length requirement down to 22 but I believe if we changed the treatment of non-alphanumeric characters that would be breaking.

[dgirardi]

IMO it makes sense to allow both an arbitrary function and a canned hash function. Perhaps something like

interface UserSyncConfig {
   encodePPID?: 'sha256' | (uids: EID['uids']) => string
}

with the default being the same it is now (uids[0].id.replace(/[\W_]/g, '')).

Additionally, the current check for length between 32 and 150 should be replaced with

Publishers can check that PPIDs are correct by using the following tools with this regular expression:
^[0-9a-zA-Z+.=/_-$,{}]{22,150}$

as per GAM docs

[robin-crazygames]

I did just realize that hashing using the digest method (which was indeed one of the options I had in mind) would turn this synchronous method into an asynchronous one. So maybe it wasn't my brightest idea ever.

I could use a synchronous hashing package (like js-sha256), but adding an additional dependency just for this feels overkill.

Main reason to log this issue was that out of all the ID providers we're currently using, only sharedId resulted in an ID that I could use. Even the comments in the code base

// userSync.ppid should be one of the 'source' values in getUserIdsAsEids() eg pubcid.org or id5-sync.com

refer to id5, which wouldn't even work because it is too long.

[patmmccann]

IS async a problem if the result is being fed to an async gam function?

[robin-crazygames]

@patmmccann It is also used in the buildVideoUrl method which is a synchronous method. So yes, it is a problem.

[robin-crazygames]

Additionally, the current check for length between 32 and 150 should be replaced with

Already opened a PR for that.