In case you don't care about the CDN stuff, and only want to do p2p transfer from client-side JS, here's a demo app I wrote that lets you send and receive multiple images between people on the same site. http://github.com/dtrejo/peerimage
Note: it is really slow on big images. I recommend just using favicons!
Co-Author here: A cdn using peer to peer has been on a lot of people's minds for a while. There are certainly going to be lots of competing implementations, but you can already start perusing PeerKit's code on github
It wasn't launched. A video about it was launched. (Sorry, but landing page posts to collect email addresses are a pet peeve. That one was posted at least three times.)
It's actually culture-specific; some cultures have it as bad, some have it as good. In any case, it's a bad choice. From [1]:
> Symbolism can be culture-specific. The check mark means correct or OK in many countries. In some countries, however, such as Japan, it can be used to mean that something is incorrect. Japanese localizers may need to convert check marks to circles (their symbol for 'correct') as part of the localization process.
Yea, when I taught English in Japan I had a distraught parent come to me because she thought her child had got almost every question wrong because I used a tick (Checkmark)
Although to be fair, the tick (checkmark) that westerners use is not really the same as what Japanese to use to mark things as incorrect since they more closely resemble V than a tick.
I'm having a hard time to get a P2P image.
I opened the demo in one window and opened a second one. After about ten refreshes I've got an image from a peer (presumably the other window as the shared counter went up by one). I repeated a bunch of times but it seems the rate at which images are served from a peer seems very low. Could you explain why? (I'm on Chrome 26.0.1410.43 m)
>Are the user's IPs or other connection information being exposed to one another?
So what? If I wanted to get a bunch of random IPs to attack, I could host a picture of a cat on my server, log IPs, and post the link on reddit. Or I could just scan random IPs within home ISP IP ranges.
Its not just random IPs, it would be ips of people who use whatever service the website provides. If that website were to have a vulnerability, you now have immediate targets.
As for the last problem, when you load the webpage, you connect to 6 other peers - so if one peer is incredibly slow, we'll simply get the data from another peer.
We're adding functionality to rate peers by latency and bandwith, so consistently slow peers are removed from the network eventually.
We'll add IP profiling for geolocation and bandwith capability later on.
The project is flexible enough to provide support for all media types-- video is definitely where the majority of your savings will be coming from. For a first-time demo though, we decided to just transfer a small image.
My company Kontiki (http://www.kontiki.com) has been providing peer-to-peer solutions for a while now. We do require a client installation but that's not an issue in an enterprise environment (our target market) where central software distribution is the norm. Most importantly, an installed client allows us to overcome the HTML5 Web Storage limit of 5-10MB. You can't really store much video content with that limit in place.
Peerkit's caching layer hacks around the HTML5 localStorage limit by opening iFrames to multiple top-level domains. Agreed that it's a messy solution that introduces some overhead (loading iFrames), but it seems to work.
This sounds like an interesting idea but needs a fallback for mobile devices. It didn't work mobile Safari. If it had though the person at the other end of my extremely slow 3G would have been very disappointed.
Every time the donation bar for wikipedia comes up, I think about making a project like this to reduce their bandwidth and server costs. I have no idea if something ad-hoc would work for their workload (they may have way too long of tail).
On the other hand, I think a lot of people would be willing to permanently donate some upload bandwidth and processing power to wikipedia if it were feasible to take advantage of it.
Apparently this is based on WebRTC [1]. Which is apparently not affected by the same origin policy. Can anyone explain why WebRTC can't be used for DDOS attacks in the obvious way (a script on a page that can open pages to any IP address could cause every visitor to that page send/receive massive data to an unrelated website, taking the target offline and/or massively inflating their bandwidth bills)?
WebRTC cannot connect to arbitrary IP addresses, only to other browsers that have opened the same page and whose user has authorized a WebRTC connection.
Interesting idea. However, as far as I can tell, this will not work well from a security perspective; 1) No support for https (and implementing anything would be non-trivial -- either all clients would need a certificate trusted by all others (eg: cacert client certificates) -- as mixing signed and unsigned data on a page is unsafe, this would "break" ssl-enabled pages) and 2) No protection against rouge clients sending different data (from spoofing to exploits targeting image handling libraries).
33 comments
[ 2.8 ms ] story [ 83.2 ms ] threadRed means bad but checkmark means good, so red checkmark means... what?
It's using the https://developer.mozilla.org/en-US/docs/DOM/window.URL.crea... API to get data on page, so not slow and inefficient like data urls
https://peercdn.com/
https://github.com/PeerKit/peerkit
> Symbolism can be culture-specific. The check mark means correct or OK in many countries. In some countries, however, such as Japan, it can be used to mean that something is incorrect. Japanese localizers may need to convert check marks to circles (their symbol for 'correct') as part of the localization process.
[1] http://www.w3.org/standards/webdesign/i18n.html
Although to be fair, the tick (checkmark) that westerners use is not really the same as what Japanese to use to mark things as incorrect since they more closely resemble V than a tick.
Other then that, sweet proof of concept.
Are the user's IPs or other connection information being exposed to one another?
Could users fake the upstream response, sending a fake/false image instead?
If a user visits the page over a 14.4 modem, is he equally likely to have other users try to load over his connection as the Google Fiber user?
This seems really cool, but I wouldn't trust my sites with it yet ;)
I agree that there's a lot of work to be done to product-ize it-- we just couldn't wait to show off the demo!
So what? If I wanted to get a bunch of random IPs to attack, I could host a picture of a cat on my server, log IPs, and post the link on reddit. Or I could just scan random IPs within home ISP IP ranges.
All the security forces would have to do is visit the site then log all the IPs to which they send their copies of the images to.
Using this they could also narrow it down to the exact page being used rather than the IP address
We're adding functionality to rate peers by latency and bandwith, so consistently slow peers are removed from the network eventually.
We'll add IP profiling for geolocation and bandwith capability later on.
In most of the stuff I've worked on, it was either a database or an analysis backend the requests were blocking in.
More power to 'em though, love stuff like this. :)
On the other hand, I think a lot of people would be willing to permanently donate some upload bandwidth and processing power to wikipedia if it were feasible to take advantage of it.
[1] http://en.wikipedia.org/wiki/WebRTC