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