On p2p: Adobe Says I Am Wrong. I Say... We'll See.

In a prior post I wrote that the new p2p functionality in Flash Player 10 would be a major threat to the CDN market. I still believe this is true, though I think it will play out differently than I imagined.

Adobe (finally) says I am wrong and there will be no p2p file sharing, and therefore no CDN killing, because Flash 10 will not be able to write files to the hard disk without direct user intervention.

Specifically this is what Justin Everett-Church, Sr. Product Manager for flash player had to say:

Will RTMFP enable massive file-sharing applications through Flash Player 10 beta?
No. Large-scale file-sharing network applications rely on the ability to read from and write to the hard drive constantly to only load parts of files into memory when needed. In Flash Player 10 beta you can load files from the desktop to the Flash Player runtime, but the file would need to be loaded manually by the end-user and remain in memory for the entire time the file would be needed. The drain on system resources would make this style of application impractical.

I had anticipated some user activity requirement being a potential tool Adobe might use for preventing good p2p, but not this one. If I had read the Flash 10 release more closely I would have caught this.

That said, I have two points.

First, as far as I can tell, this means that Adobe AIR applications should be fully able to create p2p apps in just the way I imagined, since they have full access to the file system. This in and of itself is a big deal because AIR applications are now deliverable through Adobe's one click AIR installer through Flash. It means that p2p applications are now trivial to write, and trivial to install. But it does mean pure Flash browser applications will have a harder time participating in such a network.

So the point is every stand-alone app that wants p2p will be able to have it. Of course doing an illegal Limewire will be harder because it will need to work like the original Napster, which had a central hub of control. Legally this killed Napster and would make it problematic for any would be pirate networks, which I think is as it should be.

So given that the only impediment for making a real CDN killing browser-based network is actually saving and reading files, the question is, why have such a limitation?

As I see it there are two potential reasons. I suspect one is the real reason and one is a fig leaf. The first potential reason is to protect CDNs who are major customers of Flash Media Server. This seems incredibly likely given how freaked out Adobe was about my initial article on this subject. The second potential reason, and I believe it is a fig leaf, is security. Clearly if you allow a browser app to write indiscriminately to the hard disk, you are opening the door to potential security breaches and this would indeed be bad.

As I see it, the answer to the security question is to allow every website that wishes, with permission of the user, to create a file system sandbox on the users hard drive. This area would not be accessible by other browser apps, and browser apps would not be able to write outside their own specific sandbox, potentially writing to other dangerous areas.

I am not a security expert, but it seems to me this sandboxing would prevent security breaches while allowing for lots of incredibly powerful data driven browser applications along with allowing real new forms of content distribution.

Why is this important? Because if we actually expect to build the Internet into a place that can do everything that television does and more, p2p must be a part of the equation. CDNs currently deliver one percent of the viewing audience of television in America. This is, of course tiny. I do not believe, using a CDN strategy, we will ever be able to deliver serious TV like experiences to the majority of the net. The math on that becomes problematic very quickly. But there is no reason we cannot move to a largely video based Internet once we have a secure, ubiquitous p2p architecture and move away from the centralized delivery model.

So I do hope that Adobe will tear down the artificial wall they have erected to keep browser based p2p at bay. Since everything is dependent of Flash Media Server they will still be able to monetize their work, but FMS will become much more broadly useful than it is today.

But even if Adobe doesn't do what I suggest, it just means smart entrepreneurs will make new AIR based environments or browser plugins that will allow people to write web apps that can deliver video via p2p.

As I see it the next layer here is tools that allow people to totally abstract the p2p functionality for use in content delivery. This is not too hard and I would imagine we will see at least one open source framework for the task not long after these tools all launch.

In any case it will be fascinating to see how this all plays out. The future is indeed ahead of us!