Use 3p path instead of fast fetch if site is on HTTP

[jasti]

For an AMP ad to be signed, the host page must be on HTTPS. We should optimize to fallback to 3P path if we recognize that the site is HTTP.
CC @lannka @ampproject/a4a

[dknecht]

Isn't this going to be a mixed content issue and blocked by the browser?

[michaelkleber]

For AdSense and DoubleClick, this is automatically handled by isGoogleAdsA4AValidEnvironment (in amphtml/ads/google/a4a/utils.js), where we check the browser for supportsNativeCrypto. Probably this should be part of AmpAd's upgradeCallback instead, since the crypto requirement is an AMP dependency, not a decision made by each individual ad network. (Also, should this call isCryptoAvailable from crypto-verifier.js, rather than have the logic in a second place?)

I would expect that if crypto is unavailable at a4a response handling time, then we treat it the same as an unsigned response, and fall back to cross-domain iframe rendering, but I haven't verified that behavior.

[taymonbeal]

@michaelkleber is correct; browsers without Web Crypto can use Fast Fetch if the ad network permits it (AdSense and DoubleClick currently don't), but the creative will be rendered using delayed rendering regardless of its signature status.

@dknecht, unless my knowledge of browser security policies is rusty, HTTP pages can make AJAX requests to HTTPS URLs just fine (and all A4A Fast Fetch ad networks use HTTPS); only the reverse situation would result in a mixed content problem.

@jasti, what exactly is problematic about the current behavior?

[dknecht]

Makes sense. I was thinking more of amp only context where pages were https only.

[taymonbeal]

AMP isn't HTTPS-only; AMP Caches are (or at least should be), but A4A Fast Fetch works fine on AMP pages served directly from the publisher domain if the ad network permits it (again, AdSense and DoubleClick currently do not, though it seems TripleLift does). That said, we don't intend to allow ad networks to serve Fast Fetch ads over insecure HTTP (a network impl that built non-HTTPS URLs would be rejected in code review), so there aren't going to be mixed content problems from that end.

[jasti]

I'm closing this issue because the ad network could simply take advantage of fast fetch on non-HTTPS pages even though the ads themselves might render into cross domain iframe.
@taymonbeal Favor please? Could you point to this documentation if available, if not, mind adding it on GH?
@bradfrizzell did we make the ' A4A network implementation guide' public yet?

[taymonbeal]

This isn't currently documented anywhere. The place to put it would be either Brad's implementation guide or the A4A spec for ad networks (which is still in the works). Unless there should be an additional source of A4A documentation apart from those?

[bradfrizzell]

That guide is not public yet, no. I can add this to the guide. I would like to go through it again before it becomes public and make sure that all of the terminology matches the terminology guide now that it is nailed down.

[jasti]

@bradfrizzell Unless I'm missing it, would you be able to add to this information to https://github.com/ampproject/amphtml/blob/master/ads/google/a4a/docs/Network-Impl-Guide.md
Thanks.