3 ms·

> 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just run

by zapita 9y ago

> 1) Someone accesses your "site" directly on your computer via ipfs/dat whatever it is. This is static content I guess? And it's like your computer is just running a static webserver (kinda/sorta? It's like static content served by bittorrent. The content might be served directly by your computer, or by other nodes in the ipfs/dat network which are caching your content. > So, are there security implications here? Is there an attack surface that a client/viewer of your content could leverage? An attacker could try to exploit vulnerabilities in the IPFS/DAT network. This would be similar to exploiting vulnerabilities in bittorrent. Or they could try to steal the private key used to publish your content, and publish malicious updates. If access to your content is restricted (ie with a secret hash or url), an attacker might try to get access to it. Overall the security model is quite straightforward, with a smaller attack surface than typical dynamic web stacks. > 2) Sort of opposite question as in 1. You are the client/viewer of the "site," directly connected to some dude's computer via ipfs/dat or whatever. Obviously I should use standard security measures and not just go clickity on anything/everything I see, but beyond that, are there any other security implications for the client? I could download a virus I'm sure by clicking or downloading a malicious file, but beyond that, could I get hacked by the target in a more dynamic way than that? It's pretty much the same security model as regular web content, as you mention. The only exception might be a vulnerability in the ipfs/dat code, since your computer might be running a local node. > 3) How do I "navigate" in ipfs/dat-land? How do I know what URL to go to, and if this "URL" might be a safe site, or like what the hell is this URL if it's just some kind of hash? Is there a "google" of ipfs/dat sites/content? IPFS has a naming system called IPNS, where addresses are based on a unique crypto keypair. Addresses look like `/ipns/<hash>`. You can use specialized ipfs software, like the `ipfs` cli, or navigate your regular browser to an http gateway. For example, with the official gateway you can navigate to `https://ipfs.io/ipns/<hash>` https://ipfs.io/ipns/<hash>`. Ipfs also has a facility to easily alias a DNS domain to an ipns key, so you can navigate to `/ipns/<mydomain.com>` Dat I believe has a similar system. The main difference is that, thanks to Beaker, you can bypass the gateway system - just navigate to `mydomain.com` and, if it's dat-enabled, the browser will lookup the corresponding key and fetch the content via dat instead of http. There's no reason IPFS couldn't work the same way - you just need a browser to implement iofs support directly in the same way. Personally I hope Beaker will find the time to support both! > Is there a "google" of ipfs/dat sites/content? Not that I know of. But I think it's inevitable!

carussell 9y ago
> It's pretty much the same security model as regular web content, as you mention. I can't say much about IPFS, but this is not quite true of Dat. The Beaker team is working on a complementary set of APIs to read and write to Dat archives, so you could have, say, a TiddlyWiki-like site that can update itself. It's always been a big problem that the security of file:// URIs is unstandardized. I can publish a repo, for example, that includes some tests/runner.html. You could open it Firefox to run the automated tests, but Chrome will choke on it because Chrome doesn't allow XHR for file:// URIs. The only way around this is to either put it online or run a local webserver (e.g., `python -m SimpleHTTPServer`) and access it through localhost. This is perverse. Dat is solving this in a way that's very similar to what would happen if file:// got first-class attention from the browser makers. If it's in a Dat, it doesn't actually matter if it's on your computer or hosted somewhere. All that matters is that you have the content. This might not be exciting to HN types who are comfortable and willing to go rent some DigitalOcean instance and put up with administering it, but this will have a huge impact on the long tail of businesses—both small and large—that are quietly chugging along on little more than Excel and email (maybe the odd SharePoint installation). On the other hand, developers should be excited about this, too, because it means they can start building apps that are _actually_ serverless (compared to Amazon and Google's definition). We're back to where we were in the 90s: you can go write some neat client software and share it with me, without having to think about the headache of needing to run a server in perpetuity just so that it can continue being useful.
- zapita 9y ago
  I completely agree that the file access APIs in Beaker are extremely cool, and solve a real developer problem. From a security point of view, it does slightly expand the attack surface, since there could be a vulnerability in that code which isn't present in other browsers. But given the simplicity of the APIs, I think it's a very acceptable risk given the benefits. The biggest downside IMO of these additional APIs is that they only work in Beaker. If I were the Beaker team I would prioritize making them available to mainstream browsers in some way: javascript library, browser extension, webassembly... It would really help adoption if they found a way to do that.
- 9y ago

by zapita 9y ago

carussell 9y ago

> It's pretty much the same security model as regular web content, as you mention. I can't say much about IPFS, but this is not quite true of Dat. The Beaker team is working on a complementary set of APIs to read and write to Dat archives, so you could have, say, a TiddlyWiki-like site that can update itself. It's always been a big problem that the security of file:// URIs is unstandardized. I can publish a repo, for example, that includes some tests/runner.html. You could open it Firefox to run the automated tests, but Chrome will choke on it because Chrome doesn't allow XHR for file:// URIs. The only way around this is to either put it online or run a local webserver (e.g., `python -m SimpleHTTPServer`) and access it through localhost. This is perverse. Dat is solving this in a way that's very similar to what would happen if file:// got first-class attention from the browser makers. If it's in a Dat, it doesn't actually matter if it's on your computer or hosted somewhere. All that matters is that you have the content. This might not be exciting to HN types who are comfortable and willing to go rent some DigitalOcean instance and put up with administering it, but this will have a huge impact on the long tail of businesses—both small and large—that are quietly chugging along on little more than Excel and email (maybe the odd SharePoint installation). On the other hand, developers should be excited about this, too, because it means they can start building apps that are _actually_ serverless (compared to Amazon and Google's definition). We're back to where we were in the 90s: you can go write some neat client software and share it with me, without having to think about the headache of needing to run a server in perpetuity just so that it can continue being useful.

zapita 9y ago
I completely agree that the file access APIs in Beaker are extremely cool, and solve a real developer problem. From a security point of view, it does slightly expand the attack surface, since there could be a vulnerability in that code which isn't present in other browsers. But given the simplicity of the APIs, I think it's a very acceptable risk given the benefits. The biggest downside IMO of these additional APIs is that they only work in Beaker. If I were the Beaker team I would prioritize making them available to mainstream browsers in some way: javascript library, browser extension, webassembly... It would really help adoption if they found a way to do that.
9y ago