Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Node dependencies of `safe_app_nodejs` can alter the Browser's `window` object #625
Example: when running SAFE Browser 0.11.2 with experimental APIs enabled (not sure if that is necessary),
This raises two issues:
This issue will be visible to anyone using the
SAFE Browser 0.11.2 (dev build)
Clone solid-auth-lib, and run demo app with:
In SAFE Browser (dev build) visit the demo app (e.g. at http://localhost:8080)
If you open the same URI in Firefox or Chrome this is absent because only the web app is loading
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.
At the moment it's not feasible for these dependencies (or anything coming with
'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.