Slashdot Mirror
P2P Meets Push
meonkeys writes "What if you could securely subscribe to a trusted P2P file broadcaster? Check out konspire! An interesting concept; implemented in C++ and controllable via a cool Web interface ala Mutella."
← Back to Stories (view on slashdot.org)
...when it was called IRC. Seriously, this sounds like a traditional IRC channel with XDCC bots. Decentralized (many servers on the same net comprising a single channel) and varied (you can have many varied channels). I mean, it sounds like a cool idea, and a neat proof-of-concept, but is it really needed or useful?
I think that web based interfaces are severly underrated in their potential because of the reason mentioned. I love the new thinking being employed throughout this project.
Cheap $3 hosting plans
Am I to understand you start it up, go to bed, and wakeup to having a buncha unknown files on your computer? And this is a good thing?
I've often wished that the "genre" search in the various filesharing apps would work better (or in some cases, exist). Personally, I've had a lot better luck finding music I like by searching by genre on mp3.com etc than downloading mainstream crap from Kazaa, etc.
This sounds like a great tool to cut down on mouseclicks and leave me with a nice shiney playlist to listen to in the morning.
It looks like they're providing the interface but are trying to avoid any legal repercussions by placing all legal responsibility for those items transmitted on the owner of the "channel".
Step 6 of their P2P path to success is: build trust for a channel owner's tastes over time (owners are completely responsible for what goes out on their channels)
I wonder how effective this will be when the RIAA and the other big dogs come after them.
I'm gonna try it now!
Luck favors the prepared, darling.
But for server apps, I think it's the wrong choice. Let's face it, languages with security features are more suitable for servers. Bittorrent is in python. mldonkey is in objective-caml. And I'm sure there's something in java out there somewhere. No, I haven't seen any really professonal looking GUIs written in any of these languages, but I'd rather have the added security any day when it comes to promiscuous networking.
Uh..sorry, but for Napster it had everything to do with the software being used, or more specifically the design of the software. It may make no difference to the RIAA, MPAA, or any of those agencies, but it sure as hell makes a difference to the courts, and this is where the battle is fought.
Everyone is entitled to their own opinion. It's just that yours is stupid.
Especially since in this network, whoever distributes a given file also requested it (at least that's what I am reading out of the documentation), in contrast to other networks, eg. freenet where the fact that you have data on your HD and distribute it to other people does not imply that you requested that data to be there yourself.
(Note: I still think this is a pretty neat concept, though!)
Switch back to Slashdot's D1 system.
Hmmm, sounds exactly like Windows Update.
Hell, with push technology, they could just create pirates on the fly as needed.
This is a retrograde step.
It turns p2p file downloading into a "tv-like" experience where you have to be online at the right time to get the file.
Sure, you could probably script it so you get the files, but that makes it like tivo where you can watch programmes when you want but you have to remember to set it up so it records it in the first place.
We have evolved beyond that. Now, with p2p you can search for and download whatever you want, when you want. OK, so someone still has to be sharing it, which is less likely with older stuff, but there are starting to be Farenheit-451-like sharers out there (myself included) who are keeping one thing (e.g. a favourite anime series) alive by always sharing it.
Also, there is a significant barrier to adoption of a new p2p-like app. You have your p2p working fine, and downloading well, then you are expected to start using a new one. You don't know how it works yet, let alone how to optimize it or where to get what you want; you know that everyone else faces the same hurdles so there won't be much content for a while, if at all.
This wouldn't be so bad if you could try out a new p2p app while using an old one, but you really need to dedicate all your bandwidth to a program to make the most of it.
At the moment emule is where it's at (at least for me), and I won't stop using it unless everyone else does and the sources dry up.
graspee
IANAL
Queston for any reader who is: might this not excuse the computer owner from legal culpability, if it turns out he has recieved mp3s the RIAA don't like? He could just say "Hey, I subbed to the channel, but I don't control what goes out over it".
sounds like an even more illegal way to get MP3s, since now they're making money off it instead of simply sharing.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
Security features in a language attempt (poorly in most cases) to substitute for the programmer having an adequate security mindset. If you rely on the security features of a language, then you're screwed if they're broken. You're relying on the security auditing that has been performed on that language's features, and committing yourself to live or die by it. Have you personally verified that that language's seecurity features are designed well, and strong enough to meet your security requirements? Has someone you trust done so and published the results? If not, why are you relying on it?
My advice is go the opposite direction. Learn about security from a programmer perspective. Accept only libraries and components that have been extensively audited by knowledgeable, trusted sources. Then build your server on top of them in a lower level language that affords you the ability to take direct charge of everything else. Make your server secure by thinking about security in every line you code.
I use C, but the exact choice of language isn't important; the mindset and approach is. This advice applies equally to any other language: Check the return value from EVERY system call, EVERY resource allocation, and EVERY library call. Verify ALL inputs before using them, both for length and for sanity of contents. Before EACH time you write something to any kind of buffer, check that you won't write past the end FIRST. Do all of these things in every function of every module of every application. And if you rely on a language or library feature instead of doing it yourself, you'd better be damn sure that the language or library feature is doing it correctly and completely -- VERIFY this before you deploy your program.
Some may call writing in C a security risk. Inherently, it isn't. C just gives the programmer more rope to either make a better knot or make a better noose, as they see fit. The first ten to twenty lines of nearly every C function I write go like this: return failure if this parameter isn't sane; return failure if that parameter isn't sane; return failure if any persistent context isn't consistent with how we were called; try to allocate all resources required for the function and return failure if any of those allocations failed. Some other languages may automate some of that. But as a security auditor, I'm going to want to see all that. If I can't see it, I'm going to want to examine in detail the implementation of the language features that do it implicitly. If I can't do that, then I can't consider the program secure. Using C helps me audit my code because it forces all security measures to be explicit and spelled out in detail. Yes, that's more work for the programmer. But it's less work and more certainty for the security auditor. That's a tradeoff I'm willing to make.
-----Chaz