Alternative SAFE Browser Proof-of-Concept

I implemented a simple little proof-of-concept of building a SAFE browser inside of Electron at https://github.com/cretz/safe-poc-browser. The instructions to run are in the README there.

The code is ugly and it’s kind of a hackjob just to prove it could be done. After writing it I am not convinced it is a reasonable way to browse SAFE, but it does offer some benefits over the proxy. Namely:

  • Uses a safe:// protocol instead of HTTP. It is backwards compatible with the current web proxy, so http://foo.bar.safenet/baz becomes safe://foo.bar/baz (but you might have to remove the PAC file from your internet settings to use it, I forget)
  • Blocks access to all HTTP content (but has a special hook to handle *.safenet URLs to work with the proxy)
  • Upon request to click any HTTP link, it offers users the choice to open in their browser
  • Don’t have to fork an entire browser and get to stay out of the public internet at the same time

Some other things:

  • Even though I don’t even use the API, I still coded it to register w/ the launcher, so it shows how to do that (basically the same as the demo app)
  • Although I didn’t implement it, it would be trivial to support injecting a JS API usable from the pages

Again, the impl is really crappy. I don’t even have a way to close tabs, heh. I do not consider the app to be worthy and would not really recommend its use. But I was able to understand the details of the nacl handshake to register and some of the other features for my future apps. If someone really does think it’s worthy they can fork it, but there are two major downsides to this approach: basically none of the browser UI features (I don’t even have copy paste support), and no auto updating (though Electron has support for it).

Having said that, I don’t believe the proxy is the right idea either. I know it’s easiest for everyone to just upload a website in HTML/JS/CSS but the best approach one day in the future might be an app that lets users build things that give them utmost flexibility while not relying on web technologies. Like traveling back in time to how people built MySpace pages :slight_smile:

Finally, I am going to use this opportunity to drop a little wishlist on the launcher stuff here. My wishlist:

  • Swagger/OpenAPI spec for launcher rest service
  • Get the proxy out of the launcher and instead make it an app
  • More things exposed via launcher rest service such as (it would be nice if safe_ffi exposed all of this too):
    • Direct structured data rw access
    • Direct immutable data access
    • Direct self_encryptor write access (please use multipart file on this, and of course return datamap on success)
    • Instead of having the app chunk the contents itself as is done via modifyFileContent, support multipart form file uploads over HTTP
    • Same deal with getFile. Instead of a method that buries the data, use normal HTTP for what it’s good for. Specifically, please support things like content-range HTTP headers instead of a call with headers
    • If you want to be awesome, support webdav (if you don’t, I’ll likely make my own with https://github.com/mikedeboer/jsDAV that just proxies to safe launcher APIs)
  • Or instead of the above, just add a GPL linking exception to safe_* libraries and others can build things like the safe launcher without being infected by the license
  • With the safe_launcher dist, distribute all safe_* libs as shared libs instead of statically compiling them in (or putting them all in safe_ffi)
  • Installer for safe launcher and make a way for the path to be programmatically discovered (via rest is fine). Also make the safe_* lib versions programmatically discoverable. This helps apps dyamically load the latest safe_* libs from there instead of deploying their software with their own (or worse, statically compiling them) while also checking compatibility

Feel free to hit me up with questions (sleeping now, but will answer later). But don’t even bother filing bugs :-), it really is just a little sample project…

29 Likes

Very nice job…this proofs that SAFE can of a huge difference in the future. The future is bright and i hope SAFE got what it deserves and that’s respect.

3 Likes

Very interesting @Krishna_Kumar and @Viv will like this and appreciate the effort and experimentation.

7 Likes

My hero you are amazing I love this

5 Likes

Yesterday I was reading http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprinting.html. It should be noted that SAFE currently, due to the fact that it loads static info and has no callback mechanism (at least right now, and it should be opt in), it does not suffer from those fingerprinting attacks (though it might from others) :slight_smile: Lots of people at https://news.ycombinator.com/item?id=11235537 saying to disable JS…you don’t have to disable JS, you just have to keep it from phoning home.

6 Likes

Legend!
Well done bro!

3 Likes

Just FYI, the POC works as is with the new launcher

4 Likes

Brave browser has a sandbox mode to prevent script hijacking. Does yours have this same feature?

More info.

2 Likes

Mine is better :slight_smile: By default the <webview> in Electron doesn’t support node (you have to opt in via nodeintegration, see http://electron.atom.io/docs/v0.36.8/api/web-view-tag/#nodeintegration). I don’t support “content” or “preload” scripts or plugins so I don’t have to worry like Brave does (but they’re gonna upstream to Node anyways probably). But I go one further and prevent all HTTP(S) traffic (well except *.safenet to preserve compat) which helps prevent fingerprinting and encourages anonymity. I need to do some things like disable WebRTC of course (https://github.com/atom/electron/issues/4174) but in general it’s safer than the current proxy approach (it could at least use CSP headers, but I am not sure they mind mixed content).

6 Likes

Great! Anything to remove clearnet stuff is +1 on my books.

Another question, what does POC stands for?

1 Like

Proof of Concept. It means the app works but sucks. I don’t have all (or hardly any) of the features that are present in a browser beyond the renderer.

5 Likes

FYI, the proof of concept works with the new version (I’ll stop updating this thread saying it henceforth). Also be on the lookout for two things I have coming (I’ll make announcements)… first, a CLI app and Golang lib for using safenet at https://github.com/cretz/go-safeclient/ and second, a more refined approach to this proof of concept: a browser that supports direct safe access via an embedded JS lib (and maybe an abstraction over ipfs and storj too) at https://github.com/cretz/shrewd …neither are ready yet of course, but anyone can follow the development if they want.

9 Likes