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
Todo
Here’s the general todolist, vaguely in the order in which I’ll attack them:
SAFE Mode Toggle button/indicator. So you know you’re safe. Straighten out Appveyor deployfor naming and to only have one link. safe: protocol integration, so safe: links will (optionally) load the browser. (Applied where possible for windows/osx) Investigate localhost development… what can we do here to facilitate this Add launcher detection (helper in safe-js), and appropriate notification Safe network sync for browser data.
Add ‘You can access the resternet’ type screen when in SAFE mode. Instead of ugly broken screen. 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. update package naming to match maidsafe standards rename unpack folder ensure production environment used for builds & remove BeakerDev menu
safejs specifics
improve safejs promise error rejection for DNS/NFS/Auth
improve safejs promise error rejection for new APIs
improve safejs test coverage improve safejs response parsing improve safejs handling of streaming APIs and html5 streaming
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 window.safe 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.
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.
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.
Questions:
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?
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…
SAFE Mode Toggle button/indicator. So you know you’re safe.
showing that you are on the safe network exclusively. This can be toggled by clicking the icon, or going into the 
New npm package coming your way!
