Idea: decentralize the service.

[MikeSkril]

I love the project and I want to bring up an idea. I don’t know if that was brought up before, if so, I apologize for not reading everything. It would be cool to build a network with all servers running zerobin and keep the stored encrypted files synchronic to decentralize the service.

[ulikoehler]

@gombi123 I love the general idea, however I think (unfortunately) this would require a full reimplementation, because it would be quite hard to do with the current PHP-based approach (I might be wrong about this, however...)

[MikeSkril]

I want to explain a little more... and I see also a concern in the current implantation (correct me if I'm wrong).

The thing I don’t like is that the server knows who posted a certain encrypted text. Sure it doesn’t know the plain text content but can still link the IP address to a file. That means the server admin could be forced to provide user information, right? I mean, if you have my link and access to the server, you know that I posted it. The following is not a solution for that problem but it could be if adapted to use hidden services (TOR).

decentralize the service:

I would separate the client part and the server part. The server part must be coded; does mean a little bit of work :). It could work like that: Client runs on one machine > the browser does not save any content to the client but asks one directory server (multiple servers are needed) to get a storage server> once a valid storage has been found, the content is transferred (or the content will be downloaded, or whatever) Storage servers sync and dir servers are sync.

Now its harder to take down the content but we still have the file and IP log on the same machine. The situation might be better if the storage servers where hidden services (TOR) and dir server would just forward/fetch the content to/from the hidden service.

Bad idea?

[ulikoehler]

@gombi123 I don't think it's a bad idea at all ;-)

Regarding the concept -- especially the inability to take down files -- I do in fact fully agree that it would be better to implement it your way.

Some remarks regarding a possible implementation ontop of the current ZeroBin:

• ZB has not been designed for this particular purpose. If it was, it probably wouldn't be nearly sas usable as it is right now.
• Implementing it standalone would be a pile of work, so it'd best to implement it ontop of, say, https://github.com/cryptosphere/cryptosphere . However, I think it would be difficult anyway.
• ZB is (AFAIK) not very widely used (yet?). One would need to check if there is the possibility that by malicously adding a bunch of modified servers (e.g. servers that return random data) someone would be able to DOS-attack the entire network. Avoiding this
• Care would have to be taken in order to ensure the directory servers are not a SPOF. Instead of attacking a single ZB server, a well-equipped attack would probably try to take down or hack the directory servers. To fully solve this, you would need a full P2P network. You AFAIK can't implement this with FCGI-like PHP, because in that mode PHP doesn't run all the time (maybe you can workaround that?)
• I think directoryless operation can't be implemented with a plain JS/HTML application (e.g. same origin police). Maybe one could work around that.
• AFAIK the current implementation doesn't really scale well (file-only database, maybe reentrancy/concurrency issues).

Another approach I've seen multiple times (including Mixmaster, if I remember correctly) that solves the IP-log problem is to randomly generate entries (Mixmaster: Mails) anywhere. The log would then be IP-flooded.

However the simplest approach to solve the IP-log problem is to make people use ZB every day (just like PGP). If noone uses it, you're special if your IP shows up somewhere. This does, however not solve the ability of a server to take down or (randomly) modify data. Some kind of interface that distributes a text among multiple servers would in fact be nice.