Upstream Document-Isolation-Policy to HTML and Fetch #8

Hi @camillelamy - with WebKit's portability concerns now resolved, it seems like upstreaming is the main thing standing between DIP and broad support. I'd love to help get this moving however I can. For reference, we use DIP in WordPress to drive the new client-side media feature.

I tried proposing DIP for Interop in web-platform-tests/interop#1332 and was informed upstreaming into HTML and Fetch was the appropriate next step.

Claude gathered up the current state of things, summary below:

Where things stand:

• Chrome shipped DIP on desktop in 137 and on Android in 146: https://chromestatus.com/feature/5141940204208128
• Mozilla's position is positive: Document-Isolation-Policy mozilla/standards-positions#1074
• WebKit's only remaining concern is venue: Document-Isolation-Policy WebKit/standards-positions#399
• Tests live in https://github.com/web-platform-tests/wpt/tree/master/html/document-isolation-policy and are all .tentative for now.
• Gecko implementation bug: https://bugzilla.mozilla.org/show_bug.cgi?id=2063367 (no WebKit bug filed yet).

The spec is already written as monkey-patches over HTML (policy containers, browsing context groups, agent clusters, the headers) and Fetch (CORP checks, HTTP-network-or-cache fetch), so the upstream work looks like paired PRs to whatwg/html and whatwg/fetch, similar to how COEP credentialless landed via whatwg/html#6638 and whatwg/fetch#1229.

Open questions:

• Is Google planning to upstream this, and is there a rough timeline?
• Should the open issues here (Align definition markup with best practices #2, Document-Isolation-Policy Header via meta tag #3, What's "isolate-agent-cluster"? #5, Reporting behavior between normal vs. Report-Only #6) be resolved before upstreaming, or moved over to whatwg/html?
• Would a tracking issue on whatwg/html be helpful now, to get the upstreaming discussion started there?

One more item that might be worth covering in the spec or tests: WordPress found that when only some same-origin pages send DIP, those pages end up in different agent clusters, which broke same-origin iframe access in the admin. See WordPress/wordpress-develop#11298. The current tests don't appear to cover that partial-deployment case.

Help I can offer: opening the whatwg tracking issues, filing the WebKit bug, writing WPT tests for the partial-deployment case, and adding web-features and MDN entries. Happy to take on whatever is most useful!

cc: @annevk @zcorpan

AI Use

Summary drafted with help from 🤖 Claude Code; the intro and offer of help are mine.