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."

Comments

I liked it better...

[Spazholio]

...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?

What?

[BHearsum]

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?

Well, I think the idea might be

[Nijika]

in this case that the files are distributed via P2P rather than from "bots". So content would assumably make it's way to you the same way you might download something from KaZaA, but you can verify the contents with a "trusted" signature. So you can download the file from multiple independant sources, but it's still valid at the end of the DL.

I'm gonna try it now!

"potential for anonymity"

[moonbender]

The background page notes on the topic of anonymity:

anonymity of channel owners is possible even at a technical level, since it is difficult for a receiver in the network to tell which node originated a broadcast. Nodes cannot easily tell the difference between a node that originates a broadcast and a node that is simply passing on the broadcast originated by another node.

So to any given node it is unknown whether the node it's receiving a transmission is the original distributor. But still, the node it is receiving from is a distributor - that's just as illegal, at least in the context of copyright protected works.
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!)

Re:Screw multimedia; how about software?

[micromoog]

...imagine having your Gentoo packages already pre-fetched for you, whenever there's an update? Emerge and it just starts compiling w/out the download step.

Hmmm, sounds exactly like Windows Update.

Re:C++?

[Mr_Silver]

First off, let me state that I am a rather devout C++ developer with about 8 years experience developing in the language.

But for server apps, I think it's the wrong choice.

Maybe, but my personal opinion is that in the end it's better to write an application in a language you know really well (but might not be the best thing) than write some hacky fudge job (which will no doubt be really flakey and possibly even more insecure) in a language you don't know just because it's the best one to use.

Re:Oh, nice...

[micromoog]

Hell, with push technology, they could just create pirates on the fly as needed.

Security features in a language?

[Chazman]

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.