A4A is exhibiting apparently non-determinist behavior in creative crypto signature validation. The symptom is that correctly signed, valid creatives are sometimes being rendered in friendly iframe (as intended) and sometimes in cross-domain iframe (broken behavior). We suspect a race condition in the crypto verification promise... Graph.

How do we reproduce the issue?

The following is how we reproduced. It may also happen in production -- not yet verified.

1. Start gulp to serve local dev code.
2. Load a local AMP page that contains the following ad code:

<amp-ad width=300 height=250
type="adsense"
data-ad-client="ca-pub-2005682797531342"
data-ad-slot="7046626912">

Use &exp=a4a:-1&force_a4a_ctypes=1 in the local page URL params. E.g., http://localhost:8000/examples/a4a.amp.max.html?exp=a4a:-1&force_a4a_ctypes=1.
3. Examine ad request response (Chrome debug -> Network -> search for ads?). If it has an X-ampadsignature header then it's a valid creative. If not, retry until you get one.
4. Examine the DOM. If the ad creative is rendered via friendly iframe (srcdoc=), then reload until it ends up in a cross-domain iframe (src=). In our experience, this is happening ~30% of the time.

It appears that the verification chain is being executed multiple times. That's expected when it fails the first time, because it can re-fetch the keys in that case. But it shouldn't ever fail in the case of a valid creative.

What browsers are affected?

Observed so far on Chrome 55.

Which AMP version is affected?

1482332119512, but that's a local dev version. We suspect this is active in prod, but are still verifying.