Amphtml: Set CID Cookie before promptUiSrc loads

[vyoungnyc]

What's the issue?

We are using google's CLIENT_ID to sync up with our internal consent uuids to make sure we can properly persist the users consent preferences in the absence of cookies. I seem to be running into a problem with CLIENT_ID being different when the amp page is hosted off the publisher website vs. off the google.com TLD.

How do we reproduce the issue?

we pass the CLIENT_ID macro in the promptUISrc url

the results:
e.g.
https://www.google.com/amp/s/www.publisher.com/amp/en-us/content-video-123

has a client id of something like: SPB8rlQkK8dFUnpCGjto31NL7P5g-j06ZJAn8tOoWv3G4oZdpw-deDoCn9YTiqhJ

but when you go to the publishers amp page of that same content in that same browser without clearing any cookies/local storage:
https://www.publisher.com/amp/en-us/content-video-123
the client id is something like amp-nOpe-wXCUM1STTYOlYuSqg

i think the expected behavior would be that the client id's would be the same, so we can properly sync up the client id with our user consent uuid. but because it is different, the consent preferences of the user does not persist.

What is the best way to resolve this? because when amp pages are served off the google.com TLD, the cookies arent accessible when they go to a publishers page, so we are relying on google to provide a consistent CLIENT_ID

What browsers are affected?

all

Which AMP version is affected?

all AFAIK

_Originally posted by @vyoungnyc in https://github.com/ampproject/amphtml/issues/26229#issuecomment-698679599_

[micajuine-ho]

Hi @vyoungnyc , thanks for your issue.

We made the decision back in 2018 to not have AMP support syncing consent out of the box. However, you should be able to use the Linker feature to forward the CID from the proxy origin to the non-proxy origin in order to have a consistent CID.

[a-straus]

Hi @micajuine-ho

I'm working with @vyoungnyc on this issue. We're able to use the linker feature to forward the CID from proxy origin to non-proxy origin. Thank you! I've confirmed that we have the CID in the url.

The plan is to then use the cookies feature to receive the CID and save it to a cookie, then pass that cookie to our consent platform to keep a consistent consent state for our users between proxy and non-proxy origins.
Linker:
{ "linkers" : { "authId": { "ids": { "_a": "CLIENT_ID(_a)" }, "enabled": true, "proxyOnly": false } } }
And Cookies:
{ "cookies": { "enabled": true, "authId": { "value": "QUERY_PARAM(authId)" } }
The cookie is eventually getting set as authId=CID

We are using a third party consent platform, and the consent platform's iframe (promptUiSrc) is loading BEFORE the authId cookie holding the CID is set. This means that the consent platform is unable to read the cookie set through the query param

Is there a way to have the analytics platform set the cookie BEFORE the consent iframe loads? Or perhaps have the amp-consent platform read the url parameter?

Thank you in advance!

[micajuine-ho]

Hmmm maybe we could do something like this:

When CLIENT_ID is triggered by runtime, check to see if we have amp-analytics + CookieWriter.
If so, then have analytics return a promise (with an arbitrary timeout) that resolves when the CookieWriter finishes.

As long as the CookieWriter finishes writing before the timeout, the CID will be correct when the promptUiSrc iframe loads.

Thoughts @zhouyx ?

[a-straus]

Thanks @micajuine-ho for quick responses.
Are you aware of any ways to communicate the query params from the parent to the consent iframe? Perhaps in an exposed postMessage() or something similar?
I'm not sure that it is possible out of the box for the iframe to access the parent's url through things like window.parent or document.referrer because they are on different domains.

The other solution I can consider without this feature is to have our publishers read the url params and set the cookie themselves. Then might the iframe be able to read it on the publisher page? On the other hand, it seems that AMP restricts the ability for Javascript to be able to set/read cookies.

[micajuine-ho]

@a-straus I will first need to check if this is race with CookieWriter is a problem on in this use case of amp-consent or if the CookieWriter is not overriding the newly generated CID at all.

If it's the former, then we can explore relatively simple solutions for passing the incoming CID to the iframe or pausing the CLINET_ID macro in this case (non-proxy origin, CID requested by amp-consent, etc..).

[a-straus]

Hi @micajuine-ho, any updates here? I believe the issue is the race between the CookieWriter and the amp-consent, because after a user consents when changing pages the cookie is properly set by the cookie Writer. Hoping that this can be an easy fix :)

[micajuine-ho]

Hi @a-straus, we have identified the issue as a race between those two features, however a proper fix will take some time. With the holidays coming up (along with a release freeze), would a Q1 target date be acceptable for longer lasting fix?

[a-straus]

Understood @micajuine-ho thank you for confirming the issue. Yes after the holidays will be acceptable, I'll check back in then to see the status. Thank you again!

[vyoungnyc]

@micajuine-ho Just wanted to ping you and see if we are still on track for a Q1 fix? is there an eta?

[micajuine-ho]

Hi @vyoungnyc, I think our proposed solution we will be working towards is adding the CookieWriter module into amp-consent. We will expose the API in the same way it is exposed in amp-analytics.

<amp-analytics> {linkers: authId: { ids: { _a: CLIENT_ID(AMP-CONSENT)}} } </amp-analytics>
<amp-consent>
{
   "promptUISrc": "...CLIENT_ID...",
   "checkConsentHref": "...CLIENT_ID...",
   "cookies": {
      "AMP-CONSENT": {
         "value": "LINKER_PARAM(authId, _a)" 
      }
   }
}
</amp-consent>

This cookieWriter will not be able to expand all variables, as it will not have the amp-analytics variable source. Since this is the case, it should only be used for reading LINKER_PARAM values (which in turn only allows QUERY_PARAM and CLIENT_ID).

The flow is this:
On proxy-origin, CLIENT_ID is created by amp-consent and stored under the AMP-CONSENT scope. The amp-consent CID is then forwarded on navigation via Linker module of amp-analytics.

On the origin, if the Cookie API is enabled in amp-consent, before amp-consent makes any endpoint requests, it will use the LINKER_PARAM macro to read the URL parameter and store the passed in amp-consent CID as a cookie under AMP-CONSENT. Then when amp-consent hits the checkConsentHref or promptUISrc endpoints with the CLIENT_ID macro, the forwarded CID will be used.

As a CMP you have to as the publisher to include an analytics tag that uses the linker feature to forward the amp-consent CID with a unique linker name (as the amp-consent cookie writer will clean and parse the parameter from the URL).

How does this sound?

[vyoungnyc]

LGTM