Beaker: How do we feel about the network-access policies for dat:// apps?

[pfrazee]

Currently, dat:// sites have to ask permission to access a remote host. You can't embed assets unless they're served over dat://, and you can't Ajax to a remote host.

To relax that, you have to use the permissions API to request special access.

var res = await navigator.permissions.request({
  name: 'network',
  hostname: 'github.com'
})
res.status // => 'granted'

We're wondering if that's too much of a pain for developers? The CSP limitations can be a nasty surprise.

Arguments for "no network access by default"

Disabling embeds and connections from HTTPS makes it much harder to track users as they browse the Web. Something look Google Analytics simply doesn't work.

Further, the sandbox makes it possible to trust Dat sites that handle personal data, because it's hard for them to send the data out (exfiltrate) via Ajax.

Arguments against "no network access by default"

The P2P swarm is not exactly high-privacy right now, so perhaps stopping the trackers is more trouble than it's worth!

Also, writing a Dat app is irksome when I can't leverage resources from CDNs, or read data from HTTPS sources.

Options

I'll comment with some options, that we can then vote on

[pfrazee]

Option 1: Remove this policy so our lives can be easier as devs.

[pfrazee]

Option 2: Make this policy user-configurable. A paranoid like myself would then turn it on.

[pfrazee]

Option 3: Add a manifest.json entry for requesting permission. That way, it's simpler to write apps that access remote resources.

[pfrazee]

We can choose more than one of these. What's the community think? cc @taravancil @mafintosh @joehand @pmario @frabrunelle @jondashkyle

[joehand]

My biggest argument for "no network access by default" is that dat stuff will always work offline. It is a constraint that changes how things are built.

[pfrazee]

Good point

[pmario]

I think it's the users decision and not the developers. So a manifest seems to be OK, but the user has to have the final say. Especially with the * wildcard being a possibility. ... Which I wouldn't allow at all.

[paul90]

The following is from the perspective of a brief investigation into creating a version of Federated Wiki to make use of dat and beaker.

We're wondering if that's too much of a pain for developers? The CSP limitations can be a nasty surprise.

The permission API is not such a pain. What is that for the permission change to take effect that the page needs to be reloaded. The only practical way around this is to use the * wildcard, which is not really the best option. I would far rather ask for permission as the need to access a specific site is discovered, and for this change not to require a page reload to come into effect.

As for the CSP limitations - as far as I can see these are a work in progress, with an initial fixed default setting. As far as I can see there is currently no way to override those defaults. At this time I am specifically thinking about embedding content on a page, like a video from YouTube or the Internet Archive, so a policy needs setting to allow specific sources. _I notice that the browser console mentions frame-src was not set, but documentation elsewhere says that is depreciated and to use child-src._

I'll ignore option 1, it's a bad idea - may make life easier, in the short term, but just stores up the pain for later...

A combination of option 2 and 3, being able to request an initial set of permission requirements using a manifest.json. This is then extended dynamically using the permission API, but requests should take immediate effect, once granted by the user, without a page reload. The user should retain ultimate control, and be able to block any request. Though for this to be informed it may be desirable for the requests to have some supporting text.

With a manifest, if it has changed since it was last reviewed by the user they must be alerted to this and have the ability to review before the site is viewed.

[pfrazee]

but requests should take immediate effect, once granted by the user, without a page reload

I agree that's how it should work. We'll need somebody to dive into Electron/Chromium and make a PR to enable this.

[kazzkiq]

Option 2 all the way down.

CSP is too important to be fully ignored. But at the same time we want a software that simply "works" as "expected" out of the box.

The best approach in my opinion would be: disabling CSP, but showing a "warning" saying there are requests being made to mainstream web, giving user an immediate option of enabling CSP with a click.

Of course there should also be a option in the browser settings enabling hard users to enable/disable it at will. But I think the key feature here (both in terms of UX and functionality) is Beaker detecting a request attempt, allowing it by default, but making clear to user that it can be blocked.

[pfrazee]

Thanks everybody for the feedback. We think the UX for developers is too damaged by the current design. Almost every dev discovers, and bemoans, the lack of HTTPS availability on Dat. It sucks for us too.

We're going to do something similar to what @kazzkiq suggests, but not quite.

By default, Beaker is going to be permissive with its CSPs: a dat:// site will be allowed to access HTTP/S.

Then we're going to add an opt-in setting to use our previous, more restrictive CSP: no HTTP/S by default. When that setting is enabled, if a dat:// site tries to access HTTP/S, the user will get a prompt which can then relax the CSP for the given site. This way, users can opt in to extra security feature if they care about it.

Since that's going to take a little UI work and we've got 0.7.4 coming out on Monday, we're going to simply relax the CSP in the next release, and then add the more strict option in a future release.

[millette]

And when everything will be available over dat:// eventually (CDNs, etc.) we can revert back to strict CSP :-)

[pfrazee]

And when everything will be available over dat:// eventually (cdns, etc.) we can revert back to strict CSP :-)

Exactly! 😸

[kyleconroy]

and then add the more strict option in a future release.

Did this setting ever get added? I looked at the preferences in 7.10 and don't see an option to turn this on.

[pfrazee]

Not yet