ampproject / ampproject/amphtml

I2I: AMP Inabox friendly frame rendering

Open
#21,682 7 comments 0 reactions 1 assignee Claimed by @jeffkaufman View on GitHub
Component: AMPHTML ads INTENT TO IMPLEMENT P2: Soon Stale Type: Feature Request WG: monetization
Dominant language
JavaScript
Stars
14.9k
Forks
4.1k
PR merge metrics
No merged PRs in 30d

Description

## Summary

An ad network may want to protect publishers from potentially malicious creatives, and so render third party ads in cross-domain iframes. Validated AMP creatives shouldn't allow the kind of malicious behaviors that cross domaining protects against, so AMP should (a) explicitly support rendering friendly to the page and (b) include documentation on how to do this safely.

This behavior has been live in Google Ad Manager for several months on an experimental basis, and we propose standardizing it.

## Motivation

For a regular HTML creative from an untrusted source, cross-domain rendering is essential for protecting the publisher and users from the ads. For example, creatives could:

* Copy the page's cookies (if not marked http-only) and allow user impersonation
* Modify page content, enabling phishing or other fraud
* Exfiltrate page content
* Do anything else an XSS attack would allow

AMP creatives can't run custom JS, and the AMP JS doesn't (and shouldn't) allow any of these things, so this protection shouldn't be needed. Since cross-domain iframes are less performant than same domain ones (for example, because of [site isolation](https://www.chromium.org/Home/chromium-security/site-isolation) in Chrome) rendering AMP creatives in same-domain iframes improves both page and ad performance.

## Recommendations

We should offer a recommended configuration for serving AMP Inabox creatives friendly to the containing page. As a first cut, we propose:

* Limiting friendly rendering to validated, transformed, AMP creatives.
* Injecting a CSP (see https://github.com/ampproject/amphtml/issues/21681).
* Injecting a referrer-policy like `` at the beginning of the creative `` to avoid accidental referrer leaks. Intentionally sending referrers is already possible in both AMP and non-AMP creatives.
* Including a `sandbox` attribute on the iframe. We would need to agree what specifically to recommend here.
* Only using friendly frame rendering in cases where you want to protect the publisher from the ad. AMP does nothing to protect the ad from the publisher.

/cc @ampproject/wg-approvers

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.