Restricting the paths an applet can read and write to

[sgwilym]

What's the problem you want solved?

@AljoschaMeyer raised the idea of being able to specify which paths an applet is permitted to read and write to. I like this idea of having permissions like this in the context of applets, but I'm wondering how it could practically be enforced. Any solution would always be more of a guard rail rather than an actual barrier, as all the data is right there on disk/IndexedDB and can be accessed via other APIs.

The policy for which paths an applet could read and write from would also have to exist outside of regular JS usage, otherwise it would be trivial to write applets which simply sidestepped any stated access limits. But I'm not really sure how to do that. I want to recreate something like how browsers enforce Content Security Policy, but in userland.

Is there a solution you'd like to recommend?

Not yet!

[chrisdevereux]

You could restrict access to IndexedDB by running the applet in a sandboxed iframe. Maybe you could have a special replica driver for applets that communicates with the parent page (which has full access to the replica and storage API) via postMessage. I guess that would mean applets all have to use this replica driver, though...

[sgwilym]

I guess that would mean applets all have to use this replica driver, though...

@chrisdevereux Yeah! there's an element of asking the pirates to please exchange their cutlasses for foam ones upon boarding. At the very least getting around this system would have to be a total hassle.

Realistically I think the best we can do is work out a system to grant knowledge of certain shares from the SharedSettings, rather than give full access right away.