Show HN: Load this image from a peer rather than from a web server (open source) | Hacker News Reader

Show HN: Load this image from a peer rather than from a web server (open source)

demo.peerkit.com

65 pointsDTrejo33 comments

My inner-Sysadmin loves it (reduce ALL the load), but my inner Security-nut worries-

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 ;)

File chunks in the upstream response are hashed, and we're working on delivering "good" peers to connect to.

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!

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

Would suck if you were, for example, a "web dissident" in China and visited an HTTPS site that uses this tech.

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

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.

My (Windows 7) firewall immediately popped up. Good firewall! Have a cookie.

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!

a red checkmark is bad to indicate failing, you should use a red X instead..

Oh, that meant "failed"? That explains why my extended wait on the page was unfruitful.

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.

[1] http://www.w3.org/standards/webdesign/i18n.html

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.

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

[1] http://en.wikipedia.org/wiki/WebRTC

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.

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.

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)

Other then that, sweet proof of concept.

Thanks! One possible explanation is that the coordination server, which tells you who has what files, is being slow. We're working on it.

Does this use data: URLs to get data from JS into the page?

Red means bad but checkmark means good, so red checkmark means... what?

Check mark means image loaded. Color indicates source. Sorry for bad UX. I was lazy and didn't find a good UTF symbol for X.

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

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.

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

Wow, this is great. I feel like stuff like this can change the web. Have you thought about building a CDN with it?

http://peerkit.com/

It's not April 7th.

This was launched just yesterday. Written in pure Javascript.

https://peercdn.com/

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

https://github.com/PeerKit/peerkit

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

So unless you're imgur, whose load has substantially to do with images?

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. :)

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.

Can Firefox Nightly be supported too? I couldn't tell if it worked.

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.

Reply on news.ycombinator.com