3 ms·

I've long wished for something like OpenBSDs pledge to be available in browsers, ideally both through meta tags and through JS APIs. Once a pledge is made, the

by Timon3 2y ago

I've long wished for something like OpenBSDs pledge to be available in browsers, ideally both through meta tags and through JS APIs. Once a pledge is made, the resource will be unavailable to the page until it's closed, like: - I pledge to only make network connections to X, Y and Z - I pledge to only make GET requests to http://example.com/foo/ http://example.com/foo/* - I pledge not to use canvas, iFrames or storage APIs This info wouldn't be immediately useful to most users, but it could massively help experienced users with trusting local utilities.

gwervc 2y ago
>- I pledge to only make GET requests to http://example.com/foo/ 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.
- Timon3 2y ago
  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).
ilrwbwrkhv 2y ago
Serenity OS also makes use of pledge. The episode in which Andreas kicks it off was delightful to watch.
Tajnymag 2y ago
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
- Timon3 2y ago
  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.

by Timon3 2y ago

gwervc 2y ago

>- I pledge to only make GET requests to http://example.com/foo/ 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.

Timon3 2y ago
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).

ilrwbwrkhv 2y ago

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

Tajnymag 2y ago

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

Timon3 2y ago
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.