I’m working on adding a backend to RS.js so users can connect to and store data on SAFEnetwork. I have several RS.js apps working (myfavoritedrinks, litewrite and taskrs) and have identified problems due to the way SAFEnetwork supports legacy browsers such as Firefox. A SAFE specific browser is being developed that will avoid these issues, but they are likely to persist as I think legacy browser support will remain important for the foreseeable future.
How Firefox / Chrome etc Access SAFE Network
To access SAFE network with a non-SAFE specific browser (detailed instructions here for the Alpha1 release):
- Install and run a program called SAFE Launcher
- Set up your browser or system to use the proxy that is run by SAFE Launcher
- Type a SAFE URL into your browser address bar, such as
http://dir.yvette.safenet
If you did that right now you would be able to view websites created by the community, and the one referenced above is a simple automatically generated directory of websites on the current (alpha1) network. These are decentralised/serverless websites, and the only place that HTTP is involved, is between your browser and the SAFE Launcher. After that, everything is on SAFE Network (end to end encrypted, routed between anonymous nodes that constitute the SAFE Network).
Background: Users can browse the network without an account, just by following the steps above. To store data and publish web content, users create an account in the SAFE Launcher and can then connect to and use other apps that store data, publish a website etc.
Content Security Policy in the Web Proxy Breaks RS.js Apps
This applies only to legacy browsers, but for the time being I think we have to assume this will be widespread and so relevant to anyone publishing sites and web apps on SAFE Network.
As noted, a web proxy is used to enable users to type a SAFE Network website address into their browser and visit it just like any other website. Since SAFE Network is intended to provide unprecedented security, it is important that sites they visit can’t easily expose them to vulnerabilities that could identify them, allow them to be tracked, install malware and so on. For this reason, the proxy inserts Content Security Policy headers and CORS headers into websites accessed by a legacy browser. You can see this in safe_launcher/app/server/web_proxy.js
Some of these cause RS.js apps to not work. Some just cause CORS/pre-flight errors that don’t seem to break anything (but that might be I’ve just not discovered what they break). Almost all of the one’s I’ve seen relate to the RS.js widget code.
My guess is that if we can find workarounds for the RS.js code, website authors using RS.js will have no problem with the web proxy inserting these headers, once they realise the restrictions that are imposed. Porting existng apps may well be troublesome because of this, although so far I’ve only found this to be an issue in the RS.js code itself and not the RS app examples I have working.
Summary of RS.js Issues with SAFE Launcher CSP
-
With the existing CSP settings any RS.js app loaded by a none-SAFE browser from SAFE Network will find the widget doesn’t display properly. The connect images don’t load, and all the HTML appears grotesquely down the page, without the benefit of any styling to hide elements and lay them out.
-
Clicking to connect causes a CORS error due to a form action restriction, though from memory I think the operation still worked.
-
I may have forgotten something!
I managed to clear all these by modifying the CSP headers in the SAFE web proxy (not the app!) to allow things that are off by default because of the default-src setting. Some of these might be adopted by the SAFE project, but possibly not. I don’t understand the issues well enough to guess really. However, one looks unlikely to be accepted because a bit of research suggests to me it leaves a sizeable security hole. I don’t think we’ll be able to allow style-src 'unsafe-inline' because I believe that to allow inline CSS is likely to be too big a risk.
To enable the RS.js widget to display and avoid CORS errors in the console, I added the following (looser settings) to the CSP header:
img-src 'self' data:;
form-action 'self' http://api.safenet;
style-src 'self' 'unsafe-inline';
I do still get one CORS error in the console on load of RS.js but haven’t figured out what that is yet.
I think the first two above stand a good chance of being accepted and included in the proxy, but 'unsafe-inline' probably won’t. So I’m looking for a way of handling this so that users of SAFE Network will be able to make use of RS.js based apps hosted on it. The advantages of this are completely anonymous self hosting on a very cheap (no hosting fees - only a one-off upload fee), plus all the benefits of RS.js apps, particularly offline first functionality as well as access from anywhere.
Any thoughts?! Is it conceivable to implement the widget in a way that would work without opening up style-src 'unsafe-inline'?
