Amphtml: <amp-consent> inside <amp-next-page> fires twice when loaded from Google Search viewer

[oliverfernandez]

What's the issue?

I can only reproduce this in AMP documents loaded inside the Google Search results AMP viewer.

If an AMP page uses the following:

• <amp-consent> extension
• <amp-next-page> to load a second AMP document. This document also contains the <amp-consent> extension

The expected behaviour is that since the <amp-consent> has already collected user's consent in the host AMP document, the <amp-consent> component that belongs to the hosted AMP document loaded inside the <amp-next-page> is not asking for consent again.

When the AMP document is loaded from its canonical URL the behaviour is the right one, all works fine. However, when the same AMP document is loaded from the Google Search AMP viewer, the <amp-consent> appears twice: first when the user opens the page, and second when the user scrolls down and the AMP document inside the <amp-next-page> becomes active

I understand that not having the <amp-consent> component in the hosted AMP document inside the <amp-next-page> is not an option, because then other components wouldn't receive the user's consent (<amp-analytics> <amp-ad> etc.)

How do we reproduce the issue?

To reproduce this you need to load the URLs from a region where GDPR / CCPA applies (i.e EU or California)

Here you can see an AMP document loaded inside the Google AMP viewer where the issue is reproducible
https://www.google.com/amp/s/ewn.co.za/2020/07/23/economists-express-mixed-views-on-another-interest-rate-cut/amp

The same document loaded from the original URL works correctly
https://ewn.co.za/2020/07/23/economists-express-mixed-views-on-another-interest-rate-cut/amp

[Ichigo3d]

Steps to reproduce:

1. Go to https://www.google.com/amp/s/ewn.co.za/2020/07/23/economists-express-mixed-views-on-another-interest-rate-cut/amp
2. When the page is loaded, the consent is appearing
3. Tap "Ok" button. Consent is closed
4. Scroll to bottom of the page.
5. Observe result.
   Actual result: consent is appeared twice

[micajuine-ho]

/cc @zhouyx I am unable to repro this issue locally (using our viewer example). Any ideas on how to move forwards?

[zhouyx]

I think the proper fix here is

1. <amp-next-page> should remove <amp-consent> from its doc. We've agreed on this before, <amp-consent> has position:fixed, and removing the one from next page is fine provided they're guaranteed to be from the same domain.
2. When fetching the consent service from shadow doc, the parent doc's consent service should be returned instead. Note we can't register the consent service to window because of the existence of FIE.

to @wassgha.

[oliverfernandez]

@zhouyx I understand that we need to wait until this is fixed in AMP runtime, and that not rendering now an <amp-consent> when inside an <amp-next-page> is not an option?

[oliverfernandez]

@zhouyx @zhouyx BTW, will this fix also apply to AMP shadows? We are experiencing the same issue

[zhouyx]

@zhouyx I understand that we need to wait until this is fixed in AMP runtime, and that not rendering now an when inside an is not an option?

If you are utilizing the promptUISrc iframe, one potential fix would be to have the iframe return the consent information without prompt.

Ideally the fix should also apply to AMP shadows. However without the parent <amp-next-page> I need a way to remove the duplicate <amp-consent> from shadow AMP docs. @dvoytenko do you have any suggestion on how to do that? Thanks

[dvoytenko]

I'd think ideally a shadow doc embedded via amp-next-page would simply ignore its amp-consent and instead get the data from the parent doc?

[oliverfernandez]

Should the consent be a service at window level, instead of at doc level?

Edit: I'm sorry, I just saw now @zhouyx regarding that consent service cannot be registered at window level

[zhouyx]

I'd think ideally a shadow doc embedded via amp-next-page would simply ignore its amp-consent and instead get the data from the parent doc?

I agree with that approach. @wassgha @nainar to prioritize the fix on the <amp-next-page> side.
Meanwhile, @dvoytenko thoughts on shadow AMP that's not <amp-next-page>? Which service is responsible to remove duplicate <amp-consent> component?

[zhouyx]

Should the consent be a service at window level, instead of at doc level?

Actually I think we can register the consent service at window level once we have ampdoc-fie launched, because FIE will have its own window by then. @dvoytenko is that correct?

[dvoytenko]

If the moving this service to the window is the right thing to do, there's no need to wait for ampdoc-fie - the FIE already has the its own window and that wouldn't change.

[lautarorodriguezmrf]

@zhouyx @dvoytenko has this work been prioritised? is there any ETA for it?

[zhouyx]

Hi @lautarorodriguezmrf
Sorry we haven't been able to prioritize the work yet.

@nainar Who owns the <amp-next-page> today?

[oliverfernandez]

@zhouyx

We have been told that, starting in September, Ad Manager will start blocking ad requests that don't carry the appropriate consent information.

Effectively speaking, this will leave amp-next-page unusable from an amp-ad and amp-analytics perspective, leaving as only temporary fix showing the CMP twice to the users.

I don't mean to add pressure here, just inform about the situation. Do you think that this could be done by an outside collaborator, or is it a deep change that needs to be done by someone from the AMP team?

[zhouyx]

cc @nainar @alanorozco

[juanazabalmrf]

@zhouyx @dvoytenko @nainar @alanorozco This is getting more and more urgent every day as Google ad manager will cease to answer requests without consent. Is there any way in which we can get this prioritized?

[dvoytenko]

/cc @kristoferbaxter

[zhouyx]

Looks like <amp-next-page> is not actively owned by anyone. I'll sync with @nainar offline on the priority.

[zhouyx]

Discussed offline.
I can take this, but I haven't touched amp-next-page code before so I don't have an estimate on time. We will definitely prioritize this in Q4.

[Cauchon]

@zhouyx Any updates on this one? We're seeing this happen on CNET.

[vahandev]

Having the same issue. Is there any ETA on fixing this ?

[oliverfernandez]

Hello @zhouyx

Do you have any news regarding this?

[dmanek]

@oliverfernandez Hey I cannot repro this issue because next page does not have <amp-consent>. Can you please provide me with a link where I can repro? Thanks.

[vahandev]

@oliverfernandez Hey I cannot repro this issue because next page does not have <amp-consent>. Can you please provide me with a link where I can repro? Thanks.

Here is example page
https://www.searchenginejournal.com/hiring-search-agency/392516/amp/

[dmanek]

@vahandev I'm not able to repro on that link. I dont get any sort of consent UI, perhaps due to the following JS error:
[amp-consent-ui] postPromptUI element with id=postPromptUI not found

 

[vahandev]

@dmanek can you pls use proxy from Europe ?

[dmanek]

@oliverfernandez can u share the consent config from the host as well the next page from where you could repro this issue? Were they the same config or different?

[oliverfernandez]

@dmanek I've prepared you a valid AMP page whose amp-next-page also contains a amp-consent element, so you can reproduce the issue.

https://live.mrf.io/amp/www.brandeating.com/2020/10/review-wendys-sausage-egg-and-cheese-burrito.html

Remember that, in order to reproduce the issue:

1. You need to view it from a GDRP / CCPA region
2. You need to view it through Google's AMP viewer

Unfortunately, although it is a valid AMP page, I have not been able to load it inside Google's AMP Viewer, I don't know why.

I cannot give you a real AMP url because real traffic and users would be affected by the problem.

Any ideas?