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 
emoji (:white_check_mark:). that’s what the Discourse team is doing 
3 Likes
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 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.
5 Likes
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
4 Likes
Looks like a polyfill issue. Was missing 
New npm package coming your way!
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] (http://electron.atom.io/docs/api/web-view-tag/). 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).
6 Likes
0.3.3
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?
Download
1 Like
Is there a way to check the version in Beaker? If not can you add it. Thanks
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…
3 Likes
That would be great, but I was meaning in the UI 
Yeh, good ideas. I’ll get this worked in 
Hi is this version just a test version perhaps?
I’m having lots of trouble working on my SAFE web apps with it. SafeEditor doesn’t work, many of my bigbang sites don’t, and the only page I can really get working is my APP ZERO (all on alpha).
Really wanted to give a shot at working on a web-app version of the email software, but the firefox proxy was taken down and I can’t get anything to work right in the SAFE Browser so I’m feeling kind of stuck? (win/lin)
@WhiteOutMashups have you converted to using the version of safe-js bundled into the window object in the safe browser? or are you still trying to get calls to localhost to work?
The latter will not work on live safe: sites. You should be moving towards accessing the safe-js methods such as window.safeAuth.authorise().
You can test these against a localhost test site in the current 0.3.3 version of beaker (as noted here)
1 Like