Accessing indexedDB through aragon apps

[Schwartz10]

Is your feature request related to a problem? Please describe.
Problem:

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

A naive alternative is to enable allow-same-origin in the sandbox iframes, but that seems to be a bad option given the comments in the code.

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.

[sohkai]

Will have to look into the security assumptions of allowing access to this. We've specifically taken the hardline approach where we don't want apps to have access to localstorage (and extending it, indexeddb).

[Schwartz10]

Understood. It's a bummer the storage access api isnt ready yet.

For now, I'm going to disable the setting in my local environment, so i can keep moving with the integration. I'm confident we'll find some solution for this.

[Schwartz10]

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.

[oed]

Does all aragon apps live under the same domain? To me it would be reasonable to have the apps live under different domains so that they would get their own indexedDB.

[sohkai]

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

[sohkai]

After a little experimentation after noticing https://github.com/3box/3box-js/issues/443#issuecomment-494147205:

localStorage seems to be available in the iframe (just ran a quick test on my own, and can persist a key value pair there)

localStorage is indeed available on the sandboxed iframe, but attempting to read from it (or sessionStorage) should result in an origin error:

I had hoped that the iframe would at least have access to sessionStorage, to persist values across its current session, but it falls under the same rules as localStorage. But for most intents and purposes, sessionStorage will be pretty similar to just using an in-memory cache.

Interestingly though, it appears that if the iframe was loaded from the same origin (was poking around with an example), it has access to localStorage even without the allow-same-origin flag (which to me seems to be opposite of what the spec says about sandboxing without the allow-same-origin flag).

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 data: urls, to force their origins to be opaque: #797.

Note that allowing these workers global access to indexedDB is really, really bad, as they could do anything they wanted to with another app's cache. AFAIK there's no way to isolate particular databases to specific contexts :(.

[sohkai]

Closing; with the current sandboxed model, we will not be supporting indexedDB in apps.