Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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/*

- 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.



>- 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: