Amphtml: Blocking 3rd party cookies breaks www.google.com/amp/s/ but works on cdn.ampproject.org/c/s

[archon810]

Hi all, I don't understand why 3rd-party cookie blocking

affects

https://www.google.com/amp/s/www.androidpolice.com/2019/09/10/opinion-the-apple-watch-series-5-embarrasses-wear-os-yet-again-its-time-for-changes/%3famp

but doesn't affect

https://www-androidpolice-com.cdn.ampproject.org/c/s/www.androidpolice.com/2019/09/10/opinion-the-apple-watch-series-5-embarrasses-wear-os-yet-again-its-time-for-changes/?amp

If you block 3rd party cookies, the ampproject link loads fine, but google.com/amp fails to load everything (and eventually triggers our custom overlay to alert the user stuff's broken):

Behind the banner, the page looks like this:

Why can't google.com/amp use the same tech as ampproject.org? Or is there a way to fix it for us by changing some settings?

Thank you.

[cramforce]

CC @lannka For potential inabox impact.

Reopening until fix has landed in prod.

[archon810]

Thanks for what seems to be a fix in the works, but can someone knowledgeable please explain the root cause of the issue and the fix as well as its expected timeline?

Thank you.

[cramforce]

It was a relatively complex chain of circumstances:

• an experiment was added to switch to a new custom element polyfill
• it being a polyfill the check whether to use the new or old has to happen
  very early in program init
• the experiment code reads from localStorage to see if the experiment is on
• this read fails in 3p context if 3p cookies are disabled
• the failure is caught and an error is logged. The program is supposed to
  continue as normal
• unfortunately, the logging system hadn't been initialized yet because
  this read happens to early that init depends on code order that the
  compiler determined
• fail

There are some obvious systemic failures that enabled this chain of
circumstances to happen and get through testing. Details will be discussed
in a postmortem.

[cramforce]

Thanks for the original report. It should now be fixed in production.

On Sat, Sep 14, 2019, 10:15 AM Malte Ubl [e-mail] wrote:

It was a relatively complex chain of circumstances:

• an experiment was added to switch to a new custom element polyfill
• it being a polyfill the check whether to use the new or old has to
  happen very early in program init
• the experiment code reads from localStorage to see if the experiment is
  on
• this read fails in 3p context if 3p cookies are disabled
• the failure is caught and an error is logged. The program is supposed to
  continue as normal
• unfortunately, the logging system hadn't been initialized yet because
  this read happens to early that init depends on code order that the
  compiler determined
• fail

There are some obvious systemic failures that enabled this chain of
circumstances to happen and get through testing. Details will be discussed
in a postmortem.

On Sat, Sep 14, 2019, 9:35 AM Artem Russakovskii [e-mail]
wrote:

Thanks for what seems to be a fix in the works, but can someone
knowledgeable please explain the issue and the fix?

Thank you.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/24499?email_source=notifications&email_token=AAAV4T7UHYXWVQPOE2M5HYLQJUHE7A5CNFSM4IWJBP5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6W7HWY#issuecomment-531493851,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAV4T6OLES6E6YZGBYKGKDQJUHE7ANCNFSM4IWJBP5A
.

[archon810]

Awesome, thank you. Please post the post-mortem if you're able to once it happens.