v141 · security

Signature-based Integrity

This feature provides web developers with a mechanism to verify the provenance of resources they depend upon, creating a technical foundation for trust in a site's dependencies. In short: servers can sign responses with a Ed25519 key pair, and web developers can require the user agent to verify the signature using a specific public key. This offers a helpful

concepts

  1. Signature Integrity

    Subresource Integrity learns Ed25519 signature verification on top of digest matching. Lets sites lock to a publisher key rather than a specific build hash.

  2. Key Rotation

    Generate a real Ed25519 keypair, sign a payload, mutate it, re-sign. Watch verification flip in real time — the same primitive Chrome runs at network layer.

  3. SRI: hash vs signature

    Four publisher events — legit update, transit tampering, origin compromise, CDN takeover — checked against both mechanisms. Side-by-side verdicts make the tradeoff explicit.

  4. Integrity Checker

    Paste any script URL: the tool computes its sha384 SRI hash for the traditional integrity attribute, then generates a simulated Ed25519 key pair and shows the integrity="ed25519-…" attribute. A mutation panel replaces one byte and re-verifies — watch both checks flip red.

why it shipped

To protect themselves from code injection, developers can restrict themselves to loading script from certain URLs and certain `<script>` elements (through Content Security Policy), and to loading script whose content is well-known (through Subresource Integrity). These satisfy a large number of use case, but fail to satisfy others (particularly supply chain integrity for dynamic resources). Signatures reasonably address this hole, nicely complementing the existing mechanisms.

references