Object Isolation

###### tags: `Waku Objects` # Object Isolation In this document, two paradigms are discussed regarding object isolation. In both cases, some API interface is required between the Chat App and the Waku Object. ## Sandboxed (full flexibility) The Waku Object is a JavaScript library that can do whatever it wants in a sandboxed context. Technically, this could be done with a sandboxed `<iframe>`. ### Pros #### Flexible For example, it can: - Connect to any blockchain using any library - Connect to Waku - Connect to centralized services - Run arbitrary code in its context This flexibility could also be somewhat restricted by using [`Content-Security-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP). Alternatively, the Waku Object could export CSPs enforced by the Chat App, which results in a tradeoff between flexibility and reviewability, as the Chat App could chose the integrated Waku Objects based on the CSPs (i.e. external services) they use. However, CSPs might be difficult to implement for two reasons: - We can't inject CSPs as we can inject code in frames ([`<iframe srcdoc>`](https://caniuse.com/?search=srcdoc) or `<iframe src="data:text/html;charset=utf-8,<html>...</html>">`), which would be optimal and not rely on external servers. > Actually, maybe we can with a combination of `src` and `<meta http-equiv="Content-Security-Policy" content="...">`. Although, is it possible to break out of this? > A proof of concept is needed to test this out. The idea would be to inject a basic app shell using `srcdoc` with a CSP and one script that renders the whole app in the `iframe`, similar to a React or Svelte `index.html`. - Decentralized storage might not allow us to set custom HTTP headers and there's no other way to inject them into iframes from the parent application as far as I have found. Using centralized servers would obviously be suboptimal. > Sources: > - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/sandbox > - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe > - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#using_the_html_meta_element > - https://stackoverflow.com/questions/19739001/what-is-the-difference-between-srcdoc-and-src-datatext-html-in-an ### Cons #### Too flexible - It would be hard to enforce design or quality guidelines - It might do things we don't want it to - Tracking - Malware - Censorship? - Leaking information / privacy #### Reviews would be more complicated As the app could connect to external services, it could also allow for arbitrary code execution that can change over time, rather than on updates. This means that the behavior of the app could technically change to add nefarious code if it were to be written that way. #### Applications might be more fragile - If they're using their own RPC, it might go down or some API key might get invalidated > A middleground to this might be to inject the main networks into Waku Objects (providing stability for those) while still allowing unsupported ones externally. - Waku Objects would have to pay for the RPC traffic coming from Chat Apps > This is not necessarily bad as the Waku Object can price that into their fees. - If they're using external services, they might require updated to stay compatible with the latest versions - For example older `js-waku` versions might lost compatibily with latest `nim-waku` nodes > The alternative to this is to abstract all the Waku / decentralized messaging away, which makes the SDK quite a bit more complicated as well. - All in all, these apps would likely require more maintenance ## Restricted SDK In this case, Waku Objects would have a predefined SDK they can use, but nothing more. They're not allowed to interact with external services that are not exported by the SDK, or to choose their RPC nodes for example. This would require much more work on the SDK layer and could potentially cause more work to be required on the Chat App Apps as well. > I'm not quite sure how this could be implemented in a way that prevents app developers from using `fetch` or any other tool that could "break sandoxing". > For now, we could just define the SDK and just filter Waku Objects out based on their code (i.e. review them before allowing them). If they call external services, they're considered unsafe. This would require code analysis of each object for the time being. ### Pros #### Less flexibility This directly results in more control for Waku Objects, preventing them from executing nefarious code. - Blocks loss of privacy #### Easy prototype if disregarding sandboxing We can just simply create Svelte components that do their own thing and interface with an API passed as a prop, which would be super easy to implement. This would completely disregard sandboxing though, and the objects could actually do whatever they want, potentially even accessing other messages or chats. ### Cons #### Limits innovation If the SDK doesn't export what the application needs, it could become impossible to implement some types of dapps. For example: - If the SDK doesn't have an endpoint for a chain I want to use - If the SDK doesn't export a wallet / account for a chain I want to use - If the SDK doesn't allow access to some popular external services - The Graph - Waku - Decentralized storage #### Requires more work on the Chat App front For every additional feature Waku Objects want to support, more work is required on the Chat App part, which in the end might make Waku Objects completely unusable. If a Waku Object wants to communicate with Polygon, the Chat App needs an RPC and potentially keys for that. Some primitives would also need to be implemented for accession decentralized storage for example. #### Dependency hell In the future, Waku Objects might need to define precisely which dependencies they need, and the Chat Apps would only be able to use Waku Objects if they can provide all of these dependencies. Different SDK versions might also make this more complicated. For example, a Chat App with SDK version 1.2.3 might not work with a Waku Object that requires SDK version 2.3.4. A Chat App that injects an Ethereum HTTP RPC provider might not work with a Waku Object that injects an Ethereum WS RPC provider. #### Complex SDK There's a lot more work to make the SDK work. - Do we inject an RPC address (fairly flexible) or an actual `ethers` instance? - If `ethers`, why not `web3`? Should it be `v5` or `v6`? To maintain compatibility in the long run, Attila proposed to abstract all communications away, so there would be an API to send a transaction, one to read something from a contract, one to send Waku messages, etc. This becomes complex extremely quickly though. In comparison to the flexible version where individual Waku Objects might break if they're not kept up to date, having this interface would actually break all the Waku Objects if the SDK is not kept up to date. #### Is it actually possible? I don't really see how we could enforce the use of our SDK and limit Waku Objects from using any external tools without complex sandboxing that would also be used in the flexible solution. In this case, the flexible sandboxed version actually covers all of this already with the CSP restrictions. ### Variations (todo) - Free design - Theming system