>- I pledge to only make GET requests to http://example.com/foo/*

Doesn't solve any trust issue since data can be send as part of the URL, and the backend response can change at will.

That was just an example - it fully solves trust issues if the pledge is "only make GET requests to exactly example.com/favicon.ico or example.com/style.css". This way you can't send any data (as there's no body, and encoded data wouldn't match the URLs).

What you are describing are essentially an extended version of various security http headers.

* first requirement can already be done using Content-Security-Policy header

* haven't found a suitable header for the second requirement

* third requirement can be done with Permissions-Policy header

That's partially true, but it would be important for this to both work without a server, and at runtime.

Not relying on a server makes this functionality available for downloaded sites. I'm a big fan of offering single file builds for web utilities, and the pledge should be part of that build instead of something the user supplies.

Having this as a runtime API would enable easier integration - say I'm developing a video editor that needs some WASM blobs. It might be a lot easier to load the blobs and pledge no further network access than having the URLs known on the server-side.

Serenity OS also makes use of pledge. The episode in which Andreas kicks it off was delightful to watch.