6 ms·
Haven't looked at Freenet in many years. Maybe it's time to take it for a spin again. It's an extremely interesting project that tries to implement secure and a
by Renaud 12y ago
Haven't looked at Freenet in many years. Maybe it's time to take it for a spin again. It's an extremely interesting project that tries to implement secure and anonymous communications with completely different objectives than Tor and other P2P networks like I2P.
The fact that the network itself also contains all its content in an anonymous, distributed way it a very interesting approach since no one knows what encrypted fragment they hold and there are no central servers.
I remember that since each resource in a website could be scattered across many many nodes, any webpage that loaded external resources would take a very long time to load, and many of the resources would have disappeared after a while, especially when considering that a lot of people would not stay connected to the network continuously or allocate much storage for their node.
One solution would be to load all resources as part of a single page site that would contain HTML, CSS and base64 encoding of the images. It would take a long time to get all the blocks for a large page/site, but nothing would be lost.
Enabling Javascript is probably a bad idea when browsing Freenet, but using it would open a lot more possibilities (like using the newfangled BGP image[] format to significantly reduce the payload).
[]:http://bellard.org/bpg/ http://bellard.org/bpg/
- doublec 12y agoSone works around the lack of JavaScript by being a plugin rather than a site. This requires you to trust the plugin code of course. An interesting project would be to come up with a sandboxed safe scripting system that allowed dynamic sites. This could remove some of the need for plugins. I'm not sure how possible it would be to do this without also enabling tracking or information leakage.
- concerned_user 12y ago>>The fact that the network itself also contains all its content That is simply not true. Website in i2p is just same as your normal www site, just that you get different route every dozen requests, therefore you can not reliably determine site location, not because "network itself contains all its content".
- nhaehnle 12y agoWith "the network", Renaud was referring to Freenet, not i2p.
- concerned_user 12y agoYep, sorry, I somehow mixed those up.. my bad.
- ArneBab 12y agoFreenet has the concept of containers which contain multiple files (essentially just tar files with extended index and optional redirection to external files). These still get spread through the network in chunks, but with 100% redundancy, and when the site loads, all the content is there. There’s a development version of freesitemgr which allows you to harness that: https://github.com/freenet/lib-pyFreenet/tree/files-in-manifest https://github.com/freenet/lib-pyFreenet/tree/files-in-manif...
- Renaud 12y agoI didn't know that. Looks like this could take care of the issue of avoiding broken resources.
- okasaki 12y ago> since no one knows what encrypted fragment they hold But they do, since they have the key to it. The encryption is just feel-good obfuscation.
- icebraining 12y agoNo, they only have they key if they have the address of the content, which may not even be publicly known. https://wiki.freenetproject.org/Plausible_deniability https://wiki.freenetproject.org/Plausible_deniability
- okasaki 12y agoI guess it was changed. When I ran a node a years ago the only option was to encrypt the entire store with one key.
- sanity31415 12y agoI think you're referring to something different. The "request key" is what you request from Freenet, but it transformed into a "store key" (not official Freenet terminology) before the request is sent out over the network. If you have the encrypted content you only see the "store key", but the "request key" is required if you actually want to decrypt it. This means that, to see what content you're actually storing, you'd need to go to a lot of trouble (basically a dictionary attack on the store key). Not impossible, but enough for plausible deniability.
- pgeorgi 12y agothe data within the store is encrypted separately. (depending on the scheme used,) The URIs consist of an ID and the key, but the store only knows the locator. So you might know you have CHK@???,ID in your store, but to understand what it is you're hosting, you need to be aware of its full URI CHK@key,ID. (some details left out on purpose)