Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Accessing indexedDB through aragon apps #702
Is your feature request related to a problem? Please describe.
I'm working on integration between orbitdb (through 3box) and an aragon-app - in order to work properly, orbitdb needs to store private keys in indexedDB.
Currently the sandbox settings restrict access to indexeddb from within an aragon app, and I'm wondering if there's a way around this, so we can continue forward with this 3box integration.
indexedDB is a helpful tool for building dapps, so I feel like giving apps access to it will only help create better apps
Describe the solution you'd like
A PR that gives approved applications a looser sandbox setting
We could sense that the profile app is being loaded and render an iframe with a different sandbox.
One thing I'm not sure about is how we block imitation attacks where malicious developers mimic a profile application and get by this check, with looser sandboxing in their mimicked profile application.
Describe alternatives you've considered
One alternative is to make the profiles application part of
A naive alternative is to enable
A (potential) future alternative is use the storage access api, where storage access can be granted from within an iframe sandbox. However, this api is not supported on chrome yet, is not production ready, and may require changes to orbitdb.
Thinking out loud here - it seems like we should be able to give each iframe its own sandboxed instance of indexedDB (is this possible?). There's no reason each individual iframe needs to access any parent or sibling's localStorage, everything can be contained within that iframe.
Indeed, that is essentially what the origin sandboxing should be doing; living in isolated domains.
Haven't looked to see if there's a way to enable it separately inside the sandbox though. To achieve the sandboxing the browser is essentially assigning them to "null" domains and I assume this doesn't play well with the storage APIs (how would the browser know if the next session is the same as a prior one?).
Perhaps sessionStorage is accessible, but it likely isn't a great place to store private keys for orbitdb's usecase (which I assume requires persistence?).
After a little experimentation after noticing https://github.com/3box/3box-js/issues/443#issuecomment-494147205:
I had hoped that the iframe would at least have access to
Interestingly though, it appears that if the iframe was loaded from the same origin (was poking around with an example), it has access to
This will present a security problem if someone loads the client through an ipfs gateway (rather than our web2 origin).
This is likely what you saw @Schwartz10, while testing with localhost (I imagine both aragon/aragon and the custom app were served from the same localhost origin).
During this exploration though, I did notice that the WebWorkers we currently create (through blob urls) can actually access the top level indexedDB, and that they were not created in opaque origins. I've now changed them to use
Note that allowing these workers global access to