Node dependencies of safe_app_nodejs can alter the Browser's window object

[happybeing]

Example: when running SAFE Browser 0.11.2 with experimental APIs enabled (not sure if that is necessary), solid-auth-lib, a dependency of rdflib modifies the window object.

This raises two issues:

1. If the web application wishes to use those same modules (e.g rdflib) the window object gets modified twice. - first by the modules loaded by solid_nodejs_app and then by the modules loaded by the web app. I suspect that the application loaded modules will do this after the safe_nodejs_app modules, so the web app may still function as expected. So not sure if this is a 'real' problem or not, but...
2. There is a potential security issue here (and more generally with npm module dependencies) because a dependency used by something in safe_nodejs_app could be modified to create unwanted or malicious side-effects, or sabotage functionality, in ways that might not be apparent, or which are even targetted at particular apps (such as a SAFE web wallet).

This issue will be visible to anyone using the rdflib (and therefore its depedency solid-auth-client) in a SAFE Web App.

Prerequisites

SAFE Browser 0.11.2 (dev build)
solid-auth-client 2.3.0

Current Behavior

Clone solid-auth-lib, and run demo app with:

$ git clone https://github.com/solid/solid-auth-client.git
$ cd solid-auth-client
$ npm install
$ POPUP_URI='http://localhost:8606/popup-template.html' npm run start:demo

In SAFE Browser (dev build) visit the demo app (e.g. at http://localhost:8080)
Open the web app browser console.
You should see messages including:

Caution: multiple versions of solid-auth-client active.

If you open the same URI in Firefox or Chrome this is absent because only the web app is loading solid-auth-client.

There's a brief discussion of this on the SAFE dev forum (here).

Expected Behaviour / Possible Solution

Ideally you won't see the 'multiple versions of solid-auth-client' message. Ideally safe_nodejs_app would prevent this, e.g. by shielding the real window object while dependecies are loading, but I don't know if that is feasible or desirable.

[joshuef]

At the moment it's not feasible for these dependencies (or anything coming with safe_app_nodejs / loaded in the preload scripts of the browser).

'Trust', I'm aware not being super desirable here, but with anything (at least in the JS realm), a certain trust of dependencies is needed (any dep imported by a webapp dev can have the same issues, eg).

That said, we should certainly audit safe_app_nodejs/the browser, and it should ship with as few dependencies as possible to limit this surface.

Good news here is that being open source, we benefit from github's dep tracking/security warnings, and we're scrutable, which should help keep things on the right track (I'd hope!).

---

An alternative solution is to move nodejs deps loaded into the DOM into a separate process. This currently would be a big shake up of APIs, it would mean complex handles being needed etc. Definitely undesirable. (And to note, on a security front, only protecting the DOM... the browser is only as secure as it's code/deps in general).

That said, a future wrapped lib of the APIs could abstract a lot of this away, and perhaps could provide a nicer API and the ability to move it to another process so we can better secure the DOM at least from the browser side.

---

So: TL;DR, As far as I can think, there's no one stop solution I can think of at the moment. But this is certainly something we should keep in mind and see what solutions might be available.