What is Digg?Sponsored by Travelzoo
Take Advantage of Ridiculously Low Holiday Airfares view!
travelzoo.com - Flights $52 and up for Thanksgiving, Christmas & New Year. But move on it now.
91 Comments
- sorenchr, on 01/15/2009, -8/+59Sounds like a nice idea for malicious script injection
- fjsferreira, on 01/15/2009, -1/+41"Update: a commenter on Reddit makes the fairly sensible suggestion that alternatively, web browsers could send a message to the web server that they will accept a torrent file instead of the original using the HTTP Accept-Encoding header."
C'mon guys, we must come out with a suggestion too! - inactive, on 01/15/2009, -2/+22The bittorrent protocol contains builtin file verification checks, I believe.
- Karai, on 01/15/2009, -0/+20These days websites are very dynamic and can change many times in a single minute. It would be hard to control file verification when websites such as cnn.com's main page changes rather often. It could work well for static or archived web pages but... Seems unlikely :\
- p2pblog, on 01/14/2009, -3/+21Interesting idea, but I think it has a fundamental flaw:
http://www.p2p-blog.com/item-948.html - Would an X-Torrent header really prevent the Digg effect? - dgendreau, on 01/15/2009, -1/+15Sure, they can spoof garbage. Good luck spoofing md5 while adding meaningful data like a virus.
- inactive, on 01/15/2009, -1/+14So some nerdy ramblings on a random blog are considered "a proposal" nowadays? I hope teh internets get to work on this right away.
- dgendreau, on 01/15/2009, -3/+15You really should learn something about Bittorrent file integrity checking...
- trollick, on 01/15/2009, -0/+11I propose X-Snail-Mail. If a document cannot be delivered over HTTP this header would indicate that the document will be delivered by an actual post man in 2-3 days.
- dgendreau, on 01/15/2009, -0/+11350Zed The server returns a torrent file containing MD5 keys for each piece of the file. For your scheme to work, you would have to:
1) Put a virus in your copy of the file
2) Modify your copy of the file further to make each piece of it return the same MD5 checksum as the original
3) Get users to download only the modified pieces of the file from you, otherwise they will just get a jumbled file.
As far as I know, 2 is virtually impossible. While it is theoretically possible to construct a random garbage file piece that has the same MD5 checksum as the original piece, the technology does not exist to put anything meaningful like a virus into one.
The best an attacker could do is poison a torrent with garbage data. - poprocksandsoda, on 01/15/2009, -4/+14This idea is to Computer Science what a science fair is to Quantum Theory: an idea that shows very litle understanding of the underlying technology. It fails to take into account that a vast majority of the web is dynamic in nature so the point is mute and that caching copies & orchestrating access would actually introduce a greater overall bandwidth drain. Not to mention the incredible security risk introduced by having multiple master copies. Regardless of what security layer you may put on cached replicas of sites like CNN, having people pull them from peers opens the door to lots of problems. The MD5 hashing algorithm used to verify correctness has already been bypassed in cases where it's validated content such as web pages ... people have found ways to inject new data without modifying the hash. It's a nice thought in theory, however in the real world if you want this type of redundancy you do it with large web farms, multiple sites, enhanced DNS, caching services and layer 7 caching servers.
- rnawky, on 01/15/2009, -1/+10It does, modifying the file would change its hash and cause it to fail the hash check.
Try downloading a file with bit torrent and changing it and trying to seed it. Your client will tell basically tell you to go ***** yourself because the file fails the hash check. - inactive, on 01/15/2009, -2/+11"You should learn something about spoofing..."
LOL, so should you :D - thejynxed, on 01/15/2009, -1/+9Don't you people use Bit Torrent at all?
Modified content from the original would fail hash checks. You wouldn't get the omgz! virus. You would get it if the ORIGINAL SOURCE content was contaminated. Every single client has hash/piece validation, and that includes the ones in Opera and the Firefox plugins.
Seriously now, use your heads before posting, kthnx. - xyllar, on 01/15/2009, -0/+8On the positive side, now Comcast won't have an ethical reason to throttle BitTorrent, although come to think of it I don't see why that would stop them.
- dregin, on 01/15/2009, -1/+9Nice thumbnail. Is that what a really torrent looks like out there in the wild????
- draculthemad, on 01/15/2009, -0/+7This would only work with static content, but that would probably be the majority of things causing load anyways.
- mmcgrath, on 01/15/2009, -0/+7Won't happen. Torrent is typically horrible for smaller file transfers. That's why applications like yum and apt-get still don't really support torrent. For large files its ok. I don't think it should be part of the standard though, interested parties should be able to plugin their browser or do as they do now, click and download a torrent.
- aladrin, on 01/15/2009, -2/+9No, it wouldn't, for the very reason stated on that page: If the server can't handle the load, it can't send out the torrent links, either.
There's another reason, too: Either the browser has to always get the torrent (to help others in need) or nobody will have the page... The only other option is to host your pages on a tracker... And if you host the tracker, it's probably on the same network as the machine that's being hit so hard anyhow. - rnawky, on 01/15/2009, -1/+8And just how is it a threat exactly? Other than possibly exposing your IP address to another person (OMG Don't HAX me PL0x) you can't get an infected file with Bit torrent unless the original file is infected. In that case, it wouldn't matter if it used bit torrent or not because the file you're download is already infected.
- dazparkour, on 01/15/2009, -1/+7The reason he has more diggs than you is because collisions can be found.
If they can find them for SSL vendors, this is toast. - dragon76, on 01/15/2009, -0/+6Yes because instead of serving pages and media it would become a tracker. What this page incorrectly assumes is that the server being hit is going to still be serving pages at the same rate AS WELL AS become a tracker. What would ideally happen is that when an HTTP server reaches a set amount of traffic it switches into tracker mode for people that support it and will throttle people that don't.
This encourages people to use a browser that supports BitTorrent and the files are served from user's cache.
Trackers send nowhere near the amount of data an HTTP server does. - totuck, on 01/16/2009, -0/+6Is it just me or is the article itself being overloaded? Oh, the irony!
- dazparkour, on 01/15/2009, -0/+6Security aside - say I am xCompany, I want to spy on yCompany.
I seed yCompanies website like mad. If I do it right, I can guess how many users they are getting and I can tell what pages they are looking at.
I may miss all dynamic data this way - but say, they keep the dynamic data server side and outsource images, CSS and javascript files, since these do not change very often. The images could be in a collection of one torrent so they can be pre-loaded, yada yada.
I'd be able to get a lot of data that would normally not be open to me. I could see what times they were busiest, when no one visited, their most popular pages (by virtue of what images where needed to load those pages). - dazparkour, on 01/15/2009, -1/+7The opposite really - they can't say all torrent traffic is malicious, save a handful of linux ISOs.
This would mean they couldn't block traffic because there is a good chance it is legitimate web traffic. - draculthemad, on 01/15/2009, -0/+5Im fairly sure as netdroid9 mentions that would just modify your 'chunk' into something meaningless since it didnt have the same hash.
If you actually used forged headers to distribute the chunk anyways, Im fairly sure you'd get flagged as a passing corrupt chunks and removed from the swarm too. - dgendreau, on 01/15/2009, -0/+5What you describe is part of how bittorrent already works. Its the whole purpose of a .torrent file.
- insanebrain, on 01/15/2009, -0/+5This is what a torrent looks like : http://nilegomez.com/wp-content/uploads/2007/08/fi ...
- PromaneX, on 01/15/2009, -3/+7The server could easily pass out a hash of the file in the headers along with the X-Torrent header. The browser would just have to check that the reconstructed file downloaded via torrent matches the hash before displaying it.
YES this would slow things down but it will only be used when a site is under huge load already so it would be a price worth paying. - z00k, on 01/15/2009, -0/+4Don't worry about your security, Just live your life like usually do. The guys in the van outside your house will take care of everything else.
- Kamujin, on 01/15/2009, -0/+4You are right, but I don't think you gave enough information to explain why.
http://www.cryptography.com/cnews/hash.html
This link should give some information on hash collisions which should help him understand why you are right. - Suricou, on 01/15/2009, -0/+4Checksums were never secure. Hashes, though, are.
MD4 is considered broken. MD5 is considered secure for now, but looks a little dubious in the future, so you shouldn't use it for anything new. The SHA family is considered to be as secure as a hash can get with current techniques. - dazparkour, on 01/15/2009, -0/+4It was done to create fake root certificates, which can further be used to create new, valid, SSL certificates.
It's not EASY or FAST, but it's definitely possible. If the gains were enough, it would be done. - PromaneX, on 01/15/2009, -0/+3If a blog post (not static) was causing high server load then a torrent could be created like a cache of that page (static). It wouldnt matter because the end user would still get to see the page they wanted instead of a could not load page error.
- Suricou, on 01/15/2009, -1/+4Welcome to the overhead.
- Suricou, on 01/15/2009, -0/+3It's only help with static, non-latency-sensetive content. Bittorrent takes a while to get going - if people arn't willing to wait at least one minute, it's not worth trying. Still, plenty of potential applications in software and video distribution. Even large image files.
You could probably achieve better savings just by very careful optimisation of cacheing. Make sure that if a file is never going to change, it's only ever downloaded once per client, and caching proxies store it indefinatly as long as space permits. - sickthoughts, on 01/15/2009, -2/+5p2p definitely needs to be leveraged somewhere along the way, in the future of the web. but this particular idea is fundamentally flawed - as others have pointed out.
- drgmdp, on 01/15/2009, -0/+3"the Internet Engineering Task Force (IETF), an anarchic nerdopoly that authoritatively defines hundreds of protocols and file formats for internet use."
lol this article shows why it should stay anarchic and nerdopolic - DeathfireD, on 01/15/2009, -0/+3Just what I was thinking draculthemad. Sites coded in PHP, Ruby or that get data from a database would have to generate static caches and make a torrent with them all in it. The other major problem with this idea is a new torrent would have to be made and uploaded to a tracker every time something new is added to your site, not to mention a torrent for each news page so that people trying to visit an article they found on digg wont get a torrent for just the home page of that site. The x-torrent header of the site would have to be dynamic to point to the correct torrent for each page. There's also the fact that if a front page is updated then a new torrent would have to be made and uploaded for it and the x-torrent header would have to be updated to point to the new torrent.
I supposed this is where swarms will come in since a tracker isn't 100% needed if your client supports swarming. - p3ngwin, on 01/15/2009, -1/+3get rid of the DNS servers. stop having specialist servers for content. use a mesh where the nodes ARE the internet.
http://freenetproject.org/
imagine a time and a place where you join your computer to the "net". your computer donates a portion of resources (cpu,ram,storage,etc) to the cloud net.
everything is connected. everything is stored EVERYWHERE.
when you upload a file, it gets spread over the cloud/mesh in many copies to make sure statistically there will always be a whole file available.
there are no DNS servers, as you are already part of the collective, so you just need to know where the file parts are.
instead of overloading servers, any content on in the collective mesh that is the cloud is downloaded acording to who is nearest and has the needed file parts.
the idea of centralised servers for DNS, file storage,etc are gone. there are only nodes now.
the more people connect, the more the collective grows like an organism. the more people improve their hardware, the collective benefits immediately.
no ISP's,no servers,no DNS., just nodes.
welcome to the collective. - PromaneX, on 01/15/2009, -0/+2Thanks, didnt know that!
- Suricou, on 01/15/2009, -0/+2You could also screw them up. The hashes would prevent insertion of fake data, but you could have your nodes download constantly while throttling uploads to under a k per second.
- chongli, on 01/15/2009, -0/+2There are pretty simple ways of getting around the issue of obscurity. Several Freenet file injection apps already implement them: monitor the files that have been injected and reinject them if need be.
- tylermenezes, on 01/15/2009, -0/+2You don't propose a HTTP header if it starts with X-. It's already in the standard that headers starting with the X- prefix are for nonstandardized headers. Rather, you'd be proposing the Torrent header, because it would be a standard.
- inactive, on 01/15/2009, -0/+2Sure, people have pointed out it's flawed, but they're so terribly wrong.
I've already seen three comments about malicious scripts.. people clearly having no idea how torrents even work.
So... doesn't count ;) - jbooth, on 01/15/2009, -0/+1Any dynamic page would be hard pressed to be torrented in this manner. Most modern websites are generated on the fly from templates including bits of personal information for any kind of site that requires you to sign in for it (amazon, gmail, whatever).
So we're stuck with loading someone's crappy html geocities website from 1997 that gets shut down every month from bandwith overuse? Count me out. - poprocksandsoda, on 01/15/2009, -0/+1Businesses care about handing off the risk of downtime to a third party who can be held accountable. Relying on static caches around the Internet provides zero control and accountability. In addition, it's 2008 and almost no one has static HTML content.
The real solution to this is scalable cloud-based servers which can rely on the service-based model provided by Amazon S3 or Microsoft Azure. The pay for scale model is the future. Not using a P2P protocol which while it seems on the surface to provide redundancy, only creates a wider attack surface. - cplusplus, on 01/15/2009, -0/+1Get ready to adapt. Wouldn't be nice if "large web farms, multiple sites, enhanced DNS, caching services and layer 7 caching servers" weren't needed?
- yurimxpxman, on 01/15/2009, -0/+1Not an original idea.
http://www.coralcdn.org/ - keegangrayson, on 01/15/2009, -1/+2http://tinyurl.com/6umcu4
-
Show 51 - 91 of 91 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is 