beakerbrowser / beaker Goto Github PK

Maybe integrate firefox sync (bookmarks, passwords, history, ...)? That would be massive in terms of enabling users to switch seamlessly back and forth.

Should be able to delete files that have been added to dats

Thanks to @mixmix we now have the core of an adblocker. Here's what's still todo:

• Filter requests by a blocklist
• Do in-page DOM filtering
• Provide a UI for enabling/disabling it
• Move the blocklist into the repo so we can keep it up-to-date (currently we're using https://github.com/Jense5/is-ad)

The Chromium sandbox was basically ripped out of electron. Is this a security concern to beaker?

Ref: http://blog.scottlogic.com/2016/03/09/As-It-Stands-Electron-Security.html

I was at a coffeeshop with bad wifi, and started to get application-wide freezes. Are there blocking actions that depend on the network?

Overview

Sites can be served in Beaker using dat://. Some facts about the protocol:

• Beaker supports DNS lookup for dat links. So, you can have dat://{dns_name} or dat://{hash}.
• On load, if there is an index.html in the dat archive, it will be displayed.
• The URL scheme will support versions: dat://{hash_or_name}/{path}@{version}#{...}
  • Example: dat://pauls-js.com/[email protected]
  • 3 kinds of version tags:
    • The change version, which is hyperdrive's internal version counter. That looks like @c{num}.
    • The hash of a version, which looks like @{hash}
    • A semver, which looks like @{maj}.{min}.{patch}.

dat:// will be a "hostless app protocol" for Beaker. Hostless apps will work differently than hosted apps, and get more privileges. Only hostless apps will get access to the client-side protocols which Beaker is adding.

The intent of hostless apps

Hostless apps are self-contained programs. Their assets are served by peer-to-peer networks, instead of by hosts, and they are integrity- and signature-checked for security. User data is stored on-device, by default, and confidential information should be encrypted end-to-end. Ideally, any point-to-point communication should occur between devices, without servers. Services, however, may be used with permission.

Security basics

The dat URL has an authority tuple of ["dat:", hash]. The policies and sandboxes will be applied to that authority. If the dat is loaded with a DNS name, the name will be resolved to a hash prior to setting policies.

Hostless apps are expected to handle secrets and privileged resources. They will be served with strict CSPs to prevent injections. A hostless app has to ask permission for new Beaker APIs and for the network; by default, an app can only access sandboxed JS APIs, and the assets within its own archive.

App updates

By default, updates to the dat will be automatically installed. The user can view the version history, and choose to revert to a past version. The user can also choose to be prompted before running updates.

New APIs

Hostless apps should be self-sufficient, and capable of (almost) anything an electron-based desktop app can do. They wont be able to bundle native modules, so Beaker will need to provide their platform of APIs.

Beaker's first 5 APIs will be:

• sqlite3
• fs
• libsodium
• secret/key storage
• dat

These 5 will handle data-modeling, data-storage, p2p data-publishing, and all basic cryptography. In the future, we'll explore integrating APIs for an identity system, payments, async push-messaging, and async push-mail.

TODOs and open questions

App update events

Should there be a JS API for the application to handle upgrades and downgrades to the application? For instance, suppose the user moves from 2.0.0 to 3.0.0 -- or 3.0.0 to 2.0.0. There may be data schemas to change. And, if handled poorly, there could be data loss. Applications may benefit from builtin migration events, to handle this.

User data control

The dat apps will create files, SQLite databases, dat archives, and other artifacts, which the user may want to export and share within other contexts. How should we handle this? Should the browser/apps have a toolset for users to configure the paths of an app?

FS api

The node community has had a lot of time to consider how a browser-based fs api should work. What are those thoughts now?

DNS changes

If the dat app is loaded via a DNS name, and the registered hash is changed, how should Beaker react to this? Should it alert the user, that a wholly new app has been put there? How can the user get back to their old app?

cc @mafintosh @maxogden @Karissa

There are now events in Electron that can handle this. We don't need the webview-preload injection to do it.

Using npm to install plugins is only semi-convenient. Like the Beaker binary itself, the plugins should auto-update. There should also be a nice screen for viewing the installed plugins, and installing new ones.

This has previously occurred because an error-event was misinterpretted by shell-window. It's probably the same thing, but with a different set of trigger conditions.

It occurred for me on http://torchystacos.com/ after clicking a subpage, then pressing back to go to the homepage.

I did quite a bit of research into databases for the browser and ultimately settled on pouchdb. It works in the browser, has gracefull fallback to whichever database the browser supports. It also has lots of plugins and is couch DB compatible. I was even table to make a serializer to convert my entire database into a json object and encrypt and export / import. You can see it in action here: http://wallet.ribbit.me/app

New accounts are disabled but if you do an import and fail to import, refresh the page and you will be logged in to a brand new account. Use the email/password you started with to "unlock it"

You can take a look at the database stuff by typing me.data into the console.

The P2P Networks maintain a folder of downloaded sites. Some of these need to be kept (eg they are created by the local user, or they've been bookmarked). The rest need to be deleted after some period. A background process should regularly clean old items from the local cache.

currently the way several decentralized systems (ethereum, ipfs) work with browser is to expose an RPC that is running locally. The problem with this a currently implemented is that any page could access those RPCs and do malicious things (ex. a page could access ipfs's rpc and pin)

I don't know the best way to secure this. But it would be nice to have some way to selectively expose RPCs to the pages.

Maybe I am missing something, or doing it wrong, but IPNS integration does not work (yet?). For instance, an URL like: ipfs://ipns/dist.ipfs.io

Service Workers will allow unhosted applications in plugin-protocols to serve pages dynamically. To support them, we need:

• A mechanism for plugin protocols to register support for Service Workers (this is disabled by default)
• A way to inject Web APIs into Service Workers. It's currently not possible, AFAIK, to inject custom APIs into iframes or workers using Electron.

There are a couple bugs that I'll need upstream help solving. They are:

• holepunchto/hyperdrive#87. This issue keeps beaker from being able to open archives created by dat.land.
• holepunchto/hyperdrive#93. This issue keeps beaker from opening static dats.
• dat-ecosystem/dat#503. Dat stops sharing after a period

The view-dat:// UI should:

• use the archive's dns name, if available
• show item sizes
• render README.md ?

Easy way to test this: try to sign into GitHub, or submit an issue.

I suspect something like a redirect is being misintrepreted as an error condition.

This is currently waiting on upstream (hyperdrive) to implement deletion.

Would be great if the application self-updated

Last week added a Files API for Dat and IPFS apps. Documentation is available here. Tests will be written this week, as well as the browsing history and URL-bar autocomplete.

Beaker will have an API for installing persistent background scripts. A section of the start screen will show active and halted BGs. The BGs will provide services, via IPC, to applications.

More lowlevel application APIs will be added, with appropriate permission schemes. This will include node's net module, parts of libsodium, Sqlite, Dat, IPFS, possibly node's DNS, and possibly node's UDP.

The userland BG scripts and lowlevel APIs will give more freedom to userland to extend the platform. All new APIs, including the BG scripts, will be restricted to Dat and IPFS apps.

Sometimes I'll go to the URL bar and ctrl+c, and the autocomplete shows up. It's weird.

The CSPs should disable any unsafe-* policies, and restrict requests to the current archive's origin.

Currently, the protocols are handled using Electron's registerBufferProtocol. Because registerBufferProtocol cant set the response headers, this change will require a change to registerHttpProtocol, and an internal HTTP server.

The HTTP server will be given a random port. To make sure no other process can access it, a nonce will be used in the requests.

• dat://
• view-dat://
• ipfs:/

When a new tab is created, the URL bar should be focused, and fully selected, so that the user can immediately enter their destination URL.

Clicking back/forward should scroll you to your last position.

When a tab is made active, its webview should immediately receive focus. This will cause keyboard shortcuts in the webview to work, without having to click within the webview first.

It would be nice to have ethereum integration.

Ethereum "Dapps" use web3 which just talk to the JSON RPC.

When talking to certain RPC endpoint the user should be notified with a pop approve or disapprove the communication

And that's pretty much it. After wallets and dapps should be able to run in beaker.

Sites can request permission to use Web APIs. Electron exposes this with http://electron.atom.io/docs/api/session/#sessetpermissionrequesthandlerhandler.

Beaker is currently denying all requests. This should be replaced with a prompt to let the user decide.

Would it be nice to be able to fetch the beaker binary from fetch it from IPFS (or DAT, but I'm unfamiliar with it), next to the S3 option, utilising the automatic integrity checks?

Browsing tabs should support:

• reordering
• animations
• pinning
• ctrl+tab keyboard shortcut

When a closed tab is restored, the navigation history should be restored.

Ideally, the webview would have the history imported, so that its navigation methods would work as usually. This is currently not supported (see electron/electron#5885).

If the history API is used to create pages, they should be added to the history

Hi @pfraze, it was great to chat at the #DWebSummit and getting to know about beaker.

Opening this issue so that we can continue our convo about IPFS integration and also invite other people in the community that might want to participate :)

Since beaker is an electron app, we can integrate either go-ipfs or js-ipfs, which in the short term, will give beaker's IPFS integration different properties, namely:

• Peer Routing + Content Routing (DHT) with go-ipfs
• WebRTC with js-ipfs.

Either way, we are standardizing the js-ipfs-api (HTTP-API client library) and js-ipfs core APi to expose the same calls, so that devs don't have to change any code when using a remote daemon or a in process daemon.

I still need to look into beaker code to get familiar with it, but meanwhile if you can give some lights on the integration should be done, it would be great.

Meanwhile, here is a short list of things that we will be doing in our side:

• upgrade ipfsd to use bin-wrapper ipfs/js-ipfsd-ctl#78 so that it can be added to any electron app independently of the architecture.
• finalize interface-ipfs-core https://github.com/ipfs/interface-ipfs-core

Anywhere Sqlite is used in the background process, the DB operations need to be delayed until the migrations complete.

I've recently been working on this thing https://github.com/dominictarr/web-bootloader

Which uses an idea called a secure url. A secure url is just a url with a base64 encoded hash in it.
it just detects {base64}.sha256. This is similar to https://en.wikipedia.org/wiki/Subresource_Integrity except subresource integrity only applies to scripts and stylesheets. 😢 so you can't use to to have secure XHR for example.

You could also do {alg}-{base64} like in SRI, or enforce that the hash is at the end of the url (right before the ?)

content-addressed data means you have caching that is easy to reason about (finally). If you already have an object with that hash, just don't do the request.

The best part is that it's dead easy to implement.
you can implement a content addressable store in 100 lines in any language.

This makes it very good for bootstrapping other protocols, etc.

what do you think about having first class support for secure urls in beaker?

Bookmarks in the start-page should:

• render favicons
• have editable titles and urls

If inpage search is active, pressing escape should always turn it off.

Currently, the inpage search has to be focused for the escape key to take effect.

GMail is popping up notifications without asking permission first. Rude.

There should be a permission prompt, and rights should be saved in the SiteData DB.

The README says:

keybase (discussion)

But links to a non-discussion. Was that meant to be an issue or a gist?

Also, my two cents: can't seriously call this "decentralization tech" if you're relying on a centralized service for your identity.

Various issues with Keybase:

• It's centralized, and there's no need for it to be
• Verification is very slow
• There are plenty of far better choices, including DPKI-type solutions and CONIKS

Emacs shortcuts, to go up/down

Currently, applications can write freely to the Application Folder, using beaker.fs. This should be modified to a default limit (100mb?), which can be increased or decreased by the user.

In darwin, the tabs are offset to the right, to give space to the traffic lights. In fullscreen, this offset should be turned off.

ZeroNet - Decentralized websites using Bitcoin crypto and BitTorrent network
http://zeronet.io

I particularly like it because it has a clever JavaScript layer to allow you to build sites with data storage that give the impression of centralised hosting, but in fact store all the backend data in the same P2P manner as the site HTML.

I've opened a ticket over there too: HelloZeroNet/ZeroNet#530