Earmark signs an AI preference into the content, and prevents no use

Why a preference written at the perimeter stops applying

The draft's introduction states the problem in two sentences that are worth quoting exactly, because the whole design follows from them. It observes that publishers today express usage preferences at the perimeter, naming a robots.txt file, an HTTP response header, or a well-known URI as the mechanisms that describe what automated clients may do with content served from one location. Then it names the consequence: perimeter signals share one failure mode, the preference attaches to the location rather than to the content, so the moment content is copied, scraped, syndicated, or aggregated, the preference stays behind and the content travels on unencumbered.

That is a precise description of something the corpus of AI crawler research keeps running into from the other direction. The mechanism that governs a fetch is RFC 9309, which standardised the robots exclusion protocol, and it governs exactly one thing, which is whether a compliant automated client should request a URL from your origin. It has nothing to say about the second, third or fortieth party to hold the bytes afterwards. Researchers have already measured what that boundary costs in practice: a canary token study found that a robots.txt block did not stop 12 of 18 AI chatbots from reaching content, because the path from a page to an answer runs through intermediaries that never made the original request.

It is also the reason so many recent proposals in this space read as variations on one theme. RSL writes a licence directive into robots.txt and states that it changes no access. Content signals ask rather than block. TDMRep is not named in any crawler's own documentation. Each adds expressiveness at the perimeter, and each inherits the perimeter's boundary. Earmark's contribution is to accept that boundary as fixed and move the artifact instead, which is a different bet rather than a better version of the same one.

The draft is careful not to claim it replaces anything. Its Relationship to Existing Mechanisms section states that robots.txt and the aipref attachment mechanisms govern the fetch, and remain the right tools for the perimeter. It positions itself as filling a specific hole: what the ecosystem lacks, in its words, is the portable, signed, offline-verifiable carrier for text and other formats outside the C2PA family, under one Mark Object shared across all content types. C2PA and the CAWG training and data mining assertion already do this for media, and the draft says the media binding rides them rather than duplicating them. Those two specifications live at c2pa.org and cawg.io, neither of which this site links to. For anyone thinking about generative engine optimisation, the practical reading is that the fetch layer and the provenance layer are now being standardised by different groups with different assumptions about who is holding the file.

What a Mark actually contains

The unit of the mechanism is a Mark, and the draft is careful about the naming: an individual signed statement is a Mark, while the mechanism as a whole is Earmark. A Mark Object is JSON with six required members and three optional ones, and the list is short enough to read in full.

The required members are v, the Mark format version, which this document defines as version 1; holder, an object containing a key, which is a JWK or key thumbprint, plus optional name, uri and domain members; content, an object containing digests, an array of digest entries each carrying alg, form and hash; pref, the asserted preferences, using the category identifiers and values of the AI Preference vocabulary; iat, an issuance timestamp; and sig, a JWS signature by the holder key over the JCS-canonicalized Mark Object. The optional members are license, a URI of terms under which reserved uses may be granted, exp, an expiry after which the Mark asserts nothing, and pref_v, which pins a vocabulary version.

Two of those lean on existing standards rather than inventing anything, which is consistent with the abstract's stated approach of defining new machinery only where none exists. The signature format is JSON Web Signature, RFC 7515, a Standards Track document published in May 2015, which represents content secured with digital signatures or Message Authentication Codes using JSON-based data structures. The canonicalisation is the JSON Canonicalization Scheme, RFC 8785, an Informational Independent Submission published in August 2020, whose abstract opens by noting that cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. Canonicalisation matters here for an unglamorous reason: two JSON serialisations of the same object with keys in a different order would hash differently, and a signature over the raw bytes would then break for no semantic reason.

The pref member is where this connects to work already under way. It reuses the IETF vocabulary for expressing AI usage preferences, which as of 13 August 2026 stands at draft-ietf-aipref-vocab-06, submitted on 28 April 2026, an active working group document with an intended status of Proposed Standard. That vocabulary defines two categories: AI model training, which it describes as the act of using an asset in the production or refinement of an AI model that can generate content in one or more modalities, and search, which it describes as use of an asset in an application whose primary purpose is to select assets and direct users to their location. It is also blunt about its own reach, stating that preferences do not themselves create rights, obligations, or prohibitions, and that the specification only seeks to ensure that preferences can be understood rather than to provide a means of ensuring that preferences are respected. We wrote about the state of that work in the AI preferences standard you cannot deploy yet, and the situation it described still holds: the companion draft defining where to attach a preference over HTTP, draft-ietf-aipref-attach, is recorded on the datatracker as expired and archived at revision 04.

Where a Mark is written, and what actually gets hashed

Four bindings are defined, one per content shape, and the HTML one is the only one most site owners would ever touch. A Mark is carried in a link element with rel set to earmark, referencing an external Mark, or inline in a script element with a type of application/earmark+json. That is a familiar pattern to anyone who has added structured data to a page, and it has the same property: it is inert markup that a parser either understands or ignores.

The HTTP binding is a response header named Earmark, which the draft says carries the Mark Object or its URI, providing the perimeter form of the same assertion for direct fetches. It is worth noticing what that concedes. A header is a perimeter signal by construction, so the HTTP binding is the mechanism admitting that for a direct fetch the old shape is still the convenient one, and the embedded bindings are for everything that happens afterwards. The media binding rides C2PA manifests as described above, and a plain text binding uses a trailer line carrying an Earmark label.

The part that repays attention is the digest, because it is what ties a signature to a specific piece of content rather than to a claim in general. Two digest forms are defined: exact, the digest of the content octets as published, and canonical, the digest of the content in the canonical form defined by the binding. For HTML, the canonical digest covers the text content of the element identified by the optional content.scope member, after Unicode NFC normalisation and whitespace collapse. That is a deliberate choice with a real consequence: it means a Mark can survive a template change, an ad insertion or a CSS rewrite that leaves the article text alone, because none of those alter the normalised text of the scoped element. It also means the Mark covers the words and not the page.

The verification procedure is five steps and the draft states them plainly. A detector extracts candidate Marks from each supported binding, verifies the signature over the canonicalized Mark Object, computes the applicable digest per the binding's rules and compares against content.digests, may corroborate the key via DNS where holder.domain is present, and interprets pref per the AI Preference vocabulary. The most instructive line is the one covering the mismatch case: a valid signature with no digest match means the content was modified after marking, and detectors must treat it as exactly that, an assertion about different content, rather than as verification of the content in hand. That is an unusually disciplined piece of specification writing, and it is the same instinct that runs through what Web Bot Auth actually specifies: a cryptographic mechanism is only useful when it is explicit about the case where the check fails.

There is one further idea in the draft that does more work than its length suggests. A rights holder may register a Mark at publication by submitting the Mark Object and content digests to an append-only, publicly verifiable transparency log, following the pattern established for certificates and supply-chain statements. The draft calls registration among the highest-value options in the document, because it turns stripping into evidence and survives total removal of every circulating copy: any party holding any copy can compute its digest and query the log. The section also says log formats and inclusion-proof mechanics are out of scope, and that the section is a concept-level description and a candidate for a companion document, which is the draft marking its own unfinished edge.

What the draft refuses to claim for itself

The most useful thing about this document is how much of it is spent narrowing what it asserts, and any honest write-up has to lead with that rather than bury it. A Mark asserts, verifiably, that this key holder stated these preferences over content with these digests at this time. The draft then adds four words that decide everything downstream: it asserts nothing else.

The disclaimers are explicit and they are not hedged. A Mark does not prove copyright ownership; it proves who made the assertion. Earmarks make preferences portable, attributable, and verifiable, and they do not make preferences self-enforcing. A mark is removable by a sufficiently motivated party, and no mark prevents any use. Earmark encrypts nothing, controls no player, and prevents no use. Enforcement remains with law, contract, and the market, and enforcement is out of scope for the protocol. The security considerations go further and concede the obvious attacks: marks are removable and the economics of removal matter, key compromise allows false assertion in the holder's name until expiry, and false Marks over content the asserter holds no rights to are possible.

This is the same distinction we drew about the crawler-side proposal in the same working group's orbit. An IETF draft makes an AI crawler's compliance claim falsifiable, not true, and Earmark is that argument pointed the other way: the publisher signs rather than the crawler, and what the signature buys is that a later dispute has an artifact in it. Neither mechanism makes anything happen at fetch time. Both make a later argument cheaper to have.

The legal section is careful in the same way and says so at the top, recording context rather than making legal claims. It observes that in several jurisdictions, removal or alteration of rights management information carries independent legal significance, and that text-and-data-mining reservation regimes require preferences to be expressed by machine-readable means. It then draws the line: the mark supplies the artifact those regimes reference, and the regimes supply the consequences the document deliberately does not. The privacy section is equally direct, noting that Marks identify rights holders by design, that the identification is durable and travels with the content, and that pseudonymous keys are supported at the cost of the assertion's utility in disputes, which it calls the honest trade.

One piece of provenance belongs in any account of this draft, and it is easy to get wrong. The document header carries an intended status of Standards Track and an expiry of 13 February 2027, but the datatracker record for it shows an Active Internet-Draft filed as an individual submission, with no stream assigned and both the type and intended RFC status recorded as none, alongside the standard statement that it is not endorsed by the IETF and has no formal standing in the IETF standards process. Anyone can file an Internet-Draft. This one is an idea with a signature scheme attached, published two days ago, and treating it as a standard because the header says Standards Track would be reading the wrong field.

What this changes for whether an AI crawler can read your site

Nothing, and the reason is worth being precise about rather than dismissive. Earmark operates on the permission layer, and it operates on the part of that layer which applies after the content has already been obtained. A scan operates on the access and content layers, and both of those are decided before anyone has the bytes at all.

That separation is the thing this site was built around, because two separate layers decide whether AI can read your site and they fail independently. Access is whether a named crawler token is allowed by your robots.txt and whether your CDN answers its request with a 200 rather than a 403, which you can resolve per token with the robots.txt tester and check against the published token list on the AI crawlers reference. Content is whether the text a person reads in a browser is present in the raw HTML response, which is what prose parity scores and what what GPTBot sees shows for a single URL. A page that fails either of those fails it whether or not a Mark is embedded in it, and a Mark embedded in a page that no crawler can fetch is a signed statement nobody will ever read.

The order of operations also matters for anyone tempted to add a link element and consider the matter handled. A Mark is markup. Markup is subject to exactly the same delivery question as every other element on the page, which means a Mark injected by client-side JavaScript is invisible to any client that does not run JavaScript, and a Mark on a page behind an aggressive bot rule is never delivered. The mechanism assumes the content reached the reader. Everything this site measures is about whether it did.

There is also a plain question of whether anyone reads a Mark, and today the honest answer is that no published crawler documentation says so. The draft is two days old. The crawler tokens that AI vendors document and the behaviours they commit to are the material we track on the Lantad bot page and in the AI visibility work more broadly, and a mechanism becomes measurable when a vendor writes down that it honours it. Until then a Mark is an assertion made into a room that may be empty, which is a reasonable thing to publish and not a thing to score.

So the practical advice is unchanged and slightly boring. Fix the layer that decides whether the text exists for a machine before spending effort on the layer that describes what a machine may do with text it has already got. If you want a specific ordering, our scoring method sets out what gets weighted and why, and the reference material on answer engine optimisation and llms.txt covers the adjacent files people usually reach for first. Earmark is a serious answer to a real gap, and it is a gap that opens after the crawl, not before it. Both problems are worth solving. Only one of them is yours to fix in your own HTML today.