Safe Browser Dev Updates (@v0.4.2)




  • Now history/favourites/sitedata and settings APIs from beaker all save to the safeNetwork (when the browser is authorised).
  • Should authentication fail, or you not be logged into the launcher, there’s a ‘Reauthenticate’ button on the safe status page to enable reauth without rebooting the browser.
  • SafeStatus page on load shows whether you are authenticated on the network or displays common error issues.
  • BeakerDev menu is now gone for all production builds (so to develop/enable localhost tabs etc, you’ll need to download and build the app.
  • sqlite is gone, making for a smaller app package :thumbsup:


Here’s the general todolist, vaguely in the order in which I’ll attack them:

:white_check_mark: SAFE Mode Toggle button/indicator. So you know you’re safe.
:white_check_mark: Straighten out Appveyor deployfor naming and to only have one link.
:white_check_mark: safe: protocol integration, so safe: links will (optionally) load the browser. (Applied where possible for windows/osx)
:white_check_mark: Investigate localhost development… what can we do here to facilitate this
:white_check_mark: Add launcher detection (helper in safe-js), and appropriate notification
:white_check_mark: Safe network sync for browser data.

  • Add ‘You can access the resternet’ type screen when in SAFE mode. Instead of ugly broken screen.
    :white_check_mark: Setup some helpful default ‘favourites’ for safe (suggestions welcome, I’d probably start with email [as per @polpolrene’s suggestion] and a site list )
  • Investigate beaker shortcut issues.
    :white_check_mark: update package naming to match maidsafe standards
    :white_check_mark: rename unpack folder
    :white_check_mark: ensure production environment used for builds & remove BeakerDev menu

safejs specifics

:white_check_mark: improve safejs promise error rejection for DNS/NFS/Auth

  • improve safejs promise error rejection for new APIs
  • improve safejs test coverage
    :white_check_mark: improve safejs response parsing
    :white_check_mark: improve safejs handling of streaming APIs and html5 streaming

Awesome todo list @joshuef, looking forward to these! Keep up the good work!

1 Like

I may have already asked this somewhere, apologies if so, but any chance of keyboard shortcuts?

My favorites:
Ctrl-TAB / Ctrl-Shift-TAB

I find a browser without these very slow!

And of course:
Ctrl-C / Ctrl-X / Ctrl-V


And the usual right click menu too (copy, paste, delete,…). In a browser is something basic.

1 Like

Hmmm, these should be in there in. (They are at least programmed into beaker)… Which mean’s there’s some bugging somewhere.

I wasn’t aware of this, so I’ll scope out and PR any fix I find. I’m assuming you’re on linux @happybeing, aye? And @digipl , too?

1 Like

On another note… is it possible to checkbox in discourse (a la github? ) Anyone know?

you can use the :white_check_mark: emoji (:white_check_mark:). that’s what the Discourse team is doing :slight_smile:


I’m check in Windows (7 and 8.1)…

Update to 0.3.2:

This features a more robust ‘safemode’ toggle, including a navbar icon showing that you are on the safe network exclusively. This can be toggled by clicking the icon, or going into the File menu. This will reload all tabs upon toggle, blocking/enabling insecure (non safe) content.

Other minor changes include improved appveyor builds (only one link needed now!) and improved file naming.

Local Development

To aid local development the safejs now contains a polyfill for window.safeXXX methods found in beaker, so you can more easily develop on localhost or file urls in the browser (where beaker’s safejs methods are not available.). These methods will trigger calls to localhost:8100 in the browser, but allow you to use the same interface as if you were developing with the browser’s safe API methods.

This leads onto another problem, of cross-origin requests. For now you can also disable CORS checks via the Beaker Dev Menu, this is an advanced feature that disables security checks on new tabs, so be aware you’re no longer safe if you use this. (This feature will only be available in dev mode once I’ve got the build scripts adapted.)

It’s worth noting though, that the best way to access the network is via the methods (via the polyfill), as any cross origin ‘localhost’ calls will be blocked by the browser for users. Disabling security checks is purely a convenience for local development, do not rely on this for anything in production on the network.


10 posts were split to a new topic: Beaker v0.3.2. + SAFE-JS’s NFS: Unexpected token a in JSON at position 0

Um, not sure if this is me but Beaker doesn’t seem to have injected the NFS portion of safe-js onto the window object:

EDIT: I’m using polyfill.js


Looks like a polyfill issue. Was missing :expressionless: New npm package coming your way! updated with nfs.


Hey @joshuef, question like that if you got some time. How well is the code of the browser isolated against the code from a web page? Is there any way a web page can compromise the javascript that runs the browser? Would it be theoretically possible to run two webpages side by side and block them from seeing each others?

In electron there’s a background process and the main process, which are separated, but can communicate if needs be. The main process in beaker is the ‘window’, which manages all the pages. The pages themselves are isolate using webview elements, which are discrete chromium processes and the js cannot interact.

You can read more about [electron webview elements here] ( Electron documentation is really very good, although a bit of a rabbit hole.

But in short, two webpages cannot communicate through the browser, outwith of standard web interfaces, or the SAFE API (they could both write to a file to exchange data, for example).



This is a development release which addresses, @Krishna’s notes from the feedback thread about spoofing token’s in memory in beaker.

Now beaker/safe-js derives it’s token and storage from the host name automatically, meaning no two sites should be able to access the other’s data via supplying the same token.

This is implemented via a small check in safe-js. The token param of authorise is not needed for beaker, but mandatory for other js environments.


Right now, in 0.3.3 safe browser is overwriting the vendor portion of the app packageData object. I think this is useful as the launcher displays the URL which made the request. Avoiding, perhaps, a site that pretends in the packageData to be another app.

This is certainly not ideal for cross-device apps (browser vs desktop vs mobile), so I was wondering, @Krishna, @frabrunelle do you think we can have an optional field for host to be displayed in the launcher, to clarify for ‘browser situations’ where exactly the request originates? (which could be optional for apps, but not for safe-browser sites?) Or is this, perhaps, overkill? Or even, moot, given the latest launcher discussions?


1 Like

Is there a way to check the version in Beaker? If not can you add it. Thanks :slight_smile:

1 Like

I wanted to propose a window.SAFE.version, too. (just an array of the semver in use. like [0, 3, 3, 'dev'] – with the last optional of course, or an object {'major': 0, 'minor': 3, 'patch': 3, 'pre': 'dev'}) I think that’d be very helpful for ensuring you are using them right for multiple version…


That would be great, but I was meaning in the UI :smile:

In “Settings” you can see the version of Beaker:

1 Like