Slashdot Mirror
Protecting Clients: Legal Impact of Filesharing Network Design
Cryogenes writes "InfoAnarchy has posted an excellent piece on legal issues faced by participants in a P2P network. The article is written by Fred von Lohmann who was previously noted on /. for the white paper IAAL*: Peer-to-Peer File Sharing and Copyright Law after Napster
(which you can find on the EFF site here)."
I really never expected this to be worthy of Slashdot's attention.
(note: I started the email dialogue with Fred von Lohmann back on August 3rd -- I wrote the indented text in the InfoAnarchy article. Fred replied on the 8th, and I posted it on InfoAnarchy on the 9th.)
I think there are a lot of interesting ideas out there -- we have some very powerful technologies to use, but each one satisfies a different need. Someday someone much smarter than myself will find enough connections between enough individual ideas to find a way to connect them all. I think the perfect filesharing network must use lots of cool technologies -- the combined technologies of several current projects.
Fred von Lohmann wrote an excellent paper that addressed the potential legal liabilities of *developers*. In open source applications and serverless peer-to-peer networks, the developer can be invisible or anonymous. If there are no servers, the only thing left to consider is the users -- the peer nodes.
My first question to him was basically rephrasing the kind of caching and forwarding that programs like Freenet and Blocks do.
The second question was based on an idea that an InfoAnarchy user started in an article's comments. I had always assumed that index servers will be a filesharing network's weak point -- the point where index data is being traded is the point where an attacker can best censor the network.
This idea would really suck to implement. Your clients wouldn't even get to see the filenames of their search results -- they would have to trust that the hash system worked properly and that all of their search results are valid. I don't know about you, but I'd hate that. I'd be uninstalling that program in a heartbeat.
But what if that was all there was? What if every other filesharing system with an index server was whitelisted, media company controlled, or was otherwise restricting access to certain information? If a user's alternatives are either a mangled no-filename service or a whitelisted service...or no service at all...perhaps they would choose to use this idea.
Or in other words...it's technology. It's a tool. It doesn't work in all scenarios, but there may be a situation where this idea works better than any others. It's not a good Napster replacement, not by a long shot, but we should file this idea away and use it later instead of dismissing it because it isn't a magic solution.
In my experience, information security is a tradeoff: security for convenience. To gain security you usually have to lose some measure of convenience. Really smart and well-designed security solutions can give you a lot of security for very little sacrificed convenience. Some other security solutions can give you a very small increase in security for a great loss in convenience. (For example, if a bad system administrator sets his NT servers to require frequent password changes with excessively complex passwords, in an environment where users are known to write their passwords down on post-it notes anyway, you're taking a lot of convenience away from users without giving them much extra security. They'll just use more post-it notes than before.)
I have a few more ideas that may present interesting legal situations if they ever get implemented. I'll keep InfoAnarchy.org updated if Fred von Lohmann and I have any more interesting discussions.
As a parting shot: Don't blame the hackers for all of this widespread copying of copyrighted media. We aren't the ones who sold millions of *general purpose* PCs to millions of consumers. They already have the tools -- we're just helping them use their tools to maximize the rights they already have.
--Michael Spencer
blocks@mspencer.net
Performance-wise, this caching is actually one of Freenet's strengths. If a cached copy of the data you want exists on the near side of a slow link, you never have to traverse that slow link, and Freenet's caching makes this much more likely. Obviously cache hit ratios, miss penalties, etc. have a lot to do with exactly how well it works in practice, but the caching in general will help far more than it hurts.
Speed problems in Freenet are implementation artifacts, which I expect to be fixed. There is, however, a much more serious design-level problem with Freenet: its lack of reliability. Freenet drops data. While Ian Clarke always turns several pretty colors whenever someone characterizes the data loss as random, data loss that occurs in response to events or conditions that the requester cannot control or even know is just not practically any different. Even if the data exists somewhere in the system, you might not be able to find it. Search requests have a horizon, which Freenet developers in a classic instance of "Not Invented Here" syndroms call HTL (Hops To Live) instead of using the well-known term TTL (Time To Live). If you're 10 hops from where the data was inserted, and your requests use HTL=4, you'd better hope that not one but (at least) two nodes between you and the insertion point requested the data before you. One might argue that you could just use larger HTL values, but if everyone did that your overlay network would get totally clogged with everyone's search requests hitting every other node: ask the Gnutella guys how much fun that was. Freenet makes it even worse because the routing's not reliable enough to avoid loops. The basic problem is that Freenet doesn't have any solution better than HTL to prevent this sort of query-overload meltdown, and adopting HTL as your "solution" guarantees that search results will never be more than guesses.
There are other less technical problems with the Freenet project, but it's not necessary even to go into those. On the basis of technical problems alone, I think that Freenet can never be more than a mediocre niche solution. It will certainly never be the world-changing tsunami that its self-appointed PR flacks (hello IC, OS, BW) would have us believe it is.
Slashdot - News for Herds. Stuff that Splatters.
A good example of a decentralized p2p network is FastTrack; you'll find FastTrack in some of the newer p2p software like Morpheus and Kazza. FastTrack extends what the Gnutella developers have been trying to do.
1. It incorporates SuperNodes automatically. A SuperNode is a computer with the capacity to host serial other clients. Which solves the weakest-link problem with the Gnutella network; an example would be a user with a 56k connection having to relay all PING/PONG/QUERY messages for its section of the network. It also solves the problem of slow searches.
2. It uses a hashing scheme to identify files, this allows for the software to positively identify identical files for simultaneous downloads.
3. It's not file specific. Users could share anything. Or course he network is rampant with copyrighted software, pornographic material and mp3's. But at least it's not designed to do that - it's just used for that.
The central problem with FastTrack isn't the technology but in how's it's marketed. FastTrack license its technology to be marked by third party developers, these third partly developers market as the next napster. To manage there user base they have established a login system which breaks the decentralized nature of the network.
Thankfully the gnutella scene has been working on incorporating these features into the gnutella network. Namely the flagship gnutella companies, BearShare and Limewire.
Freenet IMO is broken except for the most fanatic of freedom fighters. The central problem with Freenet is its speed, which I believe is inherently broken. When a user begins a transfer of a file over the Freenet network it is copied to every node (space abiding) along the path. This is to enforce redundancy, and is central to the anonymous nature of the Freenet network as it allows users to be unaware of what they are storing; it also has a weakest link problem in that a hop from the source might be very slow. In theory if a file is popular enough it will always be close, however we have yet to see that happen.
The other problem with Freenet is that it is un-searchable; users are required to KNOW what they are looking for. I don't deem this is a death blow as other services could get around this, an indexing service for example
Some links that you might find helpful:
FastTrack
BearShare
Limewire
Gnutella Developer Forum @ Yahoo
MusicCity's Morpheus
Freenet
-Jon
this is my sig.
Well, this sounds like it's time for Freenet to reach a usable state. :)
That is the only real way we can be safe from bad laws made by people who protect business interests and don't understand technology.
An encrypted, anonymous network can completely ignore legal implications, because there is nobody directly responsible for it, or even for any single transfer.
IIRC, The DMCA makes it illegal to break encryption used as part of a copy-protection system.
But if it were illegal to circumvent Freenet's encryption for filtering purposes, and if it were also illegal to passively allow people to transfer copyrighted data through your computer, those two laws wouldn't be contradictory -- instead, they would together make it illegal to run a Freenet node.
The shareholder is always right.
From what I've read about Freenet, this is not the case at all. This is from their FAQ page:
4.3. Why hash keys and encrypt data when a node operator could identify them anyway if he tried?
Hashing the key and encrypting the data is not meant a method to keep Freenet Node operators from being able to figure out what type of information is in their nodes if they really want to (after all, they can just find the key in the same way as someone who requests the information would) but rather to keep operators from having to know what information is in their nodes if they don't want to. This distinction is more a legal one than a technical one. It is not realistic to expect a node operator to try to continually collect and/or guess possible keys and then check them against the information in his node (even if such an attack is viable from a security perspective), so a sane society is less likely to hold an operator liable for such information on the network.