A publisher whose pages forbid third-party scripts cannot put a Google tag on the page #1288

The problem

A publisher whose page templates forbid third-party scripts cannot put Google's tags on the page, so they have to come from the proxy. Nothing does that. The Tag Manager module re-serves a tag the page already carries, which needs a page that already loads Google, and a page that loads Google's tags itself sends measurement data before any consent default has been set, which Google's consent guide forbids.

The change

A module, [tag] modules = ["google-tag"] with [tag.google-tag], from crates/tag/google-tag, writes Google's own snippets from the settings. At the start of head, the consent mode defaults, then Tag Manager's container script, then the gtag.js snippet, then the AdSense loader. Immediately after the opening body tag, Tag Manager's noscript iframe. Each snippet is copied from Google's documentation rather than paraphrased and carries the page it came from, so a reader can compare the two.

Consent defaults come first because Google's consent guide requires the default command before anything that sends measurement data, and all four consent types default to denied, because no Google identifier may be stored before a permission signal has been processed.

Core gains one thing, a place for a middleware to write immediately after the opening body tag, beside the head and body-close places it has. A deployment running no module that uses it registers no handler for it.

Where the Tag Manager module serves the same tag or container, the loader names the first-party path, otherwise Google's own address. A page that also loads gtag.js for the same tag has that duplicate loader removed. An inline configuration call in the publisher's own page is not removed and still sends a second page view, which the guide says plainly, because removing it would mean buffering every response.

Where it is

Draft on the fork, jwrosewell#25, on top of sizes by viewport width (fork pull request 24).