This obvious limits some of the concerns...but it's the number (and bandwidth) of guards and exits that is much more a problem in Tor than the number of relay-only nodes.
There *is* real privacy concern if many Tor nodes move to one cloud provider, and particularly if the Tor nodes are the first and last hop of the chain. In fact, we have a project called "Cloud-based Onion Routing" (COR) that looks at this problem.
COR discusses some policy approaches to make deployment on *multiple* cloud providers safer, as well as introducing another layer of indirection that makes Tor/COR market-friendly: We can sell (or give away) access to this higher-performance COR network, while still protecting end-user anonymity.
The nice thing is that our implementation mostly just uses the local tor controller to enforce access to the tor proxy based on the presence of anonymity-preserving tokens sent during connection setup, while "Anonymity Service Providers" running Tor nodes on cloud providers (EC2, Rackspace, etc.) is just starting a VM and running a node.
Sure, it's a great idea, but it has a lot of implications. For example, commercial sites rely on their banner ads to generate revenue. If I cache one of their pages, this will mess with their statistics, and mess with their banner ads. In other words, this will piss them off.
Commercial sites almost exclusively use absolute URLs when linking to banner ads, which are often even served via different TLDs (i.e., doubleclick.com). This is one reason why CoralCDN doesn't not modify data in transit to automatically rewrite non-Coralized links. So, I don't think that the argument that CoralCDN will reduce ad revenue is actually the main reason why Slashdot doesn't auto-include links.
On a related note, server operators should be aware that Google AdSense does works with CoralCDN.
If users are interested themselves of accessing most Slashdot links via CoralCDN, I suggest checking out some of the greasemonkey scripts that are available for FireFox:
http://userscripts.org/tag/coral
An increasing number of countries and companies routinely block or monitor access to parts of the Internet. To counteract these measures, we propose Infranet, a system that enables clients to surreptitiously retrieve sensitive content via cooperating Web servers distributed across the global Internet. These Infranet servers provide clients access to censored sites while continuing to host normal uncensored content. Infranet uses a tunnel protocol that provides a covert communication channel between its clients and servers, modulated over standard HTTP transactions that resemble innocuous Web browsing. In the upstream direction, Infranet clients send covert messages to Infranet servers by associating meaning to the sequence of HTTP requests being made. In the downstream direction, Infranet servers return content by hiding censored data in uncensored images using steganographic techniques. We describe the design, a prototype implementation, security properties, and performance of Infranet. Our security analysis shows that Infranet can successfully circumvent several sophisticated censoring techniques.
nyud.net refers to a semi-open, peer-to-peer content distribution network called CoralCDN that is essentially a distributed web cache. We serve > 10 M requests daily for 100,000s of clients. For more information about this research project, please see:
http://www.coralcdn.org/
Basically, when you see a URL like you reported, it means that the content is actually from (stripping out the.nyud.net:8090):
http://minigirls.biz/
Thus, if you think you've seen evidence of child abuse, you should get in touch with the operators of minigirls.biz.
> whois minigirls.biz
Domain Name: MINIGIRLS.BIZ
Domain ID: D8278609-BIZ
Sponsoring Registrar: DIRECT INFORMATION PVT. LTD.,
Sponsoring Registrar IANA ID: 303
Registrant ID: DI_356733
Registrant Name: Michael Pirson
Registrant Organization: Megaaliance Inc
Registrant Address1: 386 West Side St.
Registrant City: Chicago
Registrant State/Province: Il
Registrant Postal Code: 26549
Registrant Country: United States
Registrant Phone Number: +91.226370256
Registrant Email: mr.b_m@rambler.ru
Note that CoralCDN does not provide archival storage of content, like google.com's cache or archive.org. Much like a web cache or "content accelerator" at ISPs, CoralCDN only keeps data temporarily in its file caches, either until the data expires or the is evicted (as may occur for unpopular data).
If the origin site is no longer online or the particular content returns some HTTP error message, CoralCDN will only serve the old data for at most a short time (24 hours). Thus, if you believe that a website is making infringing/illegal content available, please direct any notices to that particular website. When that origin site complies with the notice, the content in question will naturally be removed from CoralCDN's caches through purely automated technical means in at most 24 hours.
If you've watched tsunami videos in the past month, there's a good chance you've probably accessed Coral at one point without knowing it. (Coral currently handles about 5-8 million requests a day for several TB of data.)
It's strange that their site would return a 409 message, which doesn't seem appropriate for the type of error that the web page shows. A forbidden code (403) I could understand, but not a conflict code.
Although it doesn't appear this is what occurred here, I wanted to note that if Coral has an object cached (after receiving an HTTP OK - 200), then the site starts returning 404s or 503s (and some other error conditions) after the cached object expires, Coral will continue to serve the stale objects out of its cached for another day or so.
Unfortunately, some sites do not play well with HTTP response codes. For example, a few days ago, instead of issuing a 503 message saying "user exceeded bandwidth", one of the ISPs of a slashdotted page issued instead a redirct (302) to a well-formed page (200) happily reporting this error condition. Correctly, Coral happily replaced the cached object with this page.
As an aside, if people have comments, questions, suggestions, etc. about Coral, please feel free check out our various mailing lists here. Your input is appreciated.
Actually, we'd welcome the opportunity to help Slashdot and other portals out in such a capacity. That's what Coral was designed for. So, it would go over well...
Coral is certainly designed as a scalable system to handle high traffic loads, and we've managed to weather recent slashdotting fairly well.
Coral is currently running on 80-100 well-distributed servers. Expect around 300 servers within the next couple months. For deployment pictures, see here.
In the next couple weeks and months, we should be rolling out some technological changes to improve response time and cache utilization. An active client and server-operator community for the project is certainly welcome.
It appears that the Windows 2000 DNS server you are using is not aware of DNAME records (RFC 2672):
Name "[C019](4)nyud(3)net(0)" TYPE 39 (39) CLASS 1 TTL 1333 DLEN 25 DATA Unknown resource record type 39 at 012DBC41.
We use these types of records to aid in redirecting resolvers to nearby Coral proxies (by mapping nyud.net to a "hierarchical" name http.l2.l1.l0.nyucd.net. The goal is that once you find a "nearby" server, you should remain nearby.
Given that the DNAME RFC is from 1999, it appears that some old DNS servers do not handle this record type well. We'll look into some alternatives or work-arounds. (Perhaps you can contact me directly to see if subsequent changes can fix your problem.)
The central idea of MojoNation is a service that emphasizes distributed storage/CPU/bandwidth sharing. This is different than setting up a micropayment scheme for viewing web pages. Generally, one might consider this as some client paying a server for hosting a web page -- micropayments can either be in the form of per time interval (a la paying for storage) -or- per page served (a la paying for bandwidth). Think distributed.net for sharing CPU cycles.
PayPal.com and other solutions are not as well-suited for such distributed systems for a number of reasons. First of all, it places some dependence on a centralized, commercial service, requiring people to upload credit card information and such.
I spoke with Jim McCay for a while at the recent Berkeley conference on Anonymity and Unobservability, most of our discussion centered around the anonymity aspects of MojoNation. The micropayment scheme utilized is based on Chaumian ecash, which has the nice properties of being fairly small and straightforward.
User anonymity is ensured by the cryptographic blinding of ecash tokens during the withdrawal (issuing) stage of the protcol. Therefore, the issuing authority (MojoNation until some different infrastructure is set up) is not able to link payments received by "merchants" and the customers that used these tokens. The downside of Chaumian cash (as opposed to that of Stefan Brands) is that all verification to prevent double spending needs to occur on-line. This requires some central MojoNation issuing authority (or some distributed subset of varying authorities) that needs to be contacted for the verfication.
One main aspect of MojoNation that still lacks anonymity is actual peer-to-peer operations. Currently, these just have IP-layer connectivity for usability reasons...but this is hardly anonymous.
Jim pointed out that nothing prevents the eventual "plug-and-play" functionality of some anonymous channel - such as a mixnet (ZKS Freedom, Onion-Routing, etc.) - to be used between peer connections. While speed might be affected, the anonymous micropayments scheme fits right into a future addition of anonymous links.
It's going to be interesting to see MojoNation and other such systems develop.
Slashdot Mirror
I was pointed to the fact that Tor Cloud nodes are only relays, rather than guard (first) or exit (last) nodes in the Tor circuit.
http://news.ycombinator.com/item?id=3236580
This obvious limits some of the concerns...but it's the number (and bandwidth) of guards and exits that is much more a problem in Tor than the number of relay-only nodes.
There *is* real privacy concern if many Tor nodes move to one cloud provider, and particularly if the Tor nodes are the first and last hop of the chain. In fact, we have a project called "Cloud-based Onion Routing" (COR) that looks at this problem.
COR discusses some policy approaches to make deployment on *multiple* cloud providers safer, as well as introducing another layer of indirection that makes Tor/COR market-friendly: We can sell (or give away) access to this higher-performance COR network, while still protecting end-user anonymity.
http://sns.cs.princeton.edu/projects/cor/
The nice thing is that our implementation mostly just uses the local tor controller to enforce access to the tor proxy based on the presence of anonymity-preserving tokens sent during connection setup, while "Anonymity Service Providers" running Tor nodes on cloud providers (EC2, Rackspace, etc.) is just starting a VM and running a node.
On a related note, server operators should be aware that Google AdSense does works with CoralCDN.
If users are interested themselves of accessing most Slashdot links via CoralCDN, I suggest checking out some of the greasemonkey scripts that are available for FireFox: http://userscripts.org/tag/coral
Coral synthesizes robots.txt files to disable search-engine caching.
Requests for anything.nyud.net:8090/robots.txt returns:
User-Agent: * Disallow: /
I'm not sure what might be going on with Google.
http://nms.csail.mit.edu/projects/infranet/
Technical paper (pdf)
An increasing number of countries and companies routinely block or monitor access to parts of the Internet. To counteract these measures, we propose Infranet, a system that enables clients to surreptitiously retrieve sensitive content via cooperating Web servers distributed across the global Internet. These Infranet servers provide clients access to censored sites while continuing to host normal uncensored content. Infranet uses a tunnel protocol that provides a covert communication channel between its clients and servers, modulated over standard HTTP transactions that resemble innocuous Web browsing. In the upstream direction, Infranet clients send covert messages to Infranet servers by associating meaning to the sequence of HTTP requests being made. In the downstream direction, Infranet servers return content by hiding censored data in uncensored images using steganographic techniques. We describe the design, a prototype implementation, security properties, and performance of Infranet. Our security analysis shows that Infranet can successfully circumvent several sophisticated censoring techniques.
nyud.net refers to a semi-open, peer-to-peer content distribution network called CoralCDN that is essentially a distributed web cache. We serve > 10 M requests daily for 100,000s of clients. For more information about this research project, please see:
.nyud.net:8090):
http://www.coralcdn.org/
Basically, when you see a URL like you reported, it means that the content is actually from (stripping out the
http://minigirls.biz/
Thus, if you think you've seen evidence of child abuse, you should get in touch with the operators of minigirls.biz.
> whois minigirls.biz
Domain Name: MINIGIRLS.BIZ
Domain ID: D8278609-BIZ
Sponsoring Registrar: DIRECT INFORMATION PVT. LTD.,
Sponsoring Registrar IANA ID: 303
Registrant ID: DI_356733
Registrant Name: Michael Pirson
Registrant Organization: Megaaliance Inc
Registrant Address1: 386 West Side St.
Registrant City: Chicago
Registrant State/Province: Il
Registrant Postal Code: 26549
Registrant Country: United States
Registrant Phone Number: +91.226370256
Registrant Email: mr.b_m@rambler.ru
Note that CoralCDN does not provide archival storage of content, like google.com's cache or archive.org. Much like a web cache or "content accelerator" at ISPs, CoralCDN only keeps data temporarily in its file caches, either until the data expires or the is evicted (as may occur for unpopular data).
If the origin site is no longer online or the particular content returns some HTTP error message, CoralCDN will only serve the old data for at most a short time (24 hours). Thus, if you believe that a website is making infringing/illegal content available, please direct any notices to that particular website. When that origin site complies with the notice, the content in question will naturally be removed from CoralCDN's caches through purely automated technical means in at most 24 hours.
This type of problem is exactly that for which Coral was created -- to help publishers who otherwise cannot handle their bandwidth requirements.
l s
As an example, you can find a partial list of sites which regularly use Coral at our Wiki:
http://wiki.coralcdn.org/wiki.php/Main/Testimonia
If you've watched tsunami videos in the past month, there's a good chance you've probably accessed Coral at one point without knowing it.
(Coral currently handles about 5-8 million requests a day for several TB of data.)
It's strange that their site would return a 409 message, which doesn't seem appropriate for the type of error that the web page shows. A forbidden code (403) I could understand, but not a conflict code.
Although it doesn't appear this is what occurred here, I wanted to note that if Coral has an object cached (after receiving an HTTP OK - 200), then the site starts returning 404s or 503s (and some other error conditions) after the cached object expires, Coral will continue to serve the stale objects out of its cached for another day or so.
Unfortunately, some sites do not play well with HTTP response codes. For example, a few days ago, instead of issuing a 503 message saying "user exceeded bandwidth", one of the ISPs of a slashdotted page issued instead a redirct (302) to a well-formed page (200) happily reporting this error condition. Correctly, Coral happily replaced the cached object with this page.
As an aside, if people have comments, questions, suggestions, etc. about Coral, please feel free check out our various mailing lists here. Your input is appreciated.
Actually, we'd welcome the opportunity to help Slashdot and other portals out in such a capacity. That's what Coral was designed for. So, it would go over well...
Coral is certainly designed as a scalable system to handle high traffic loads, and we've managed to weather recent slashdotting fairly well. Coral is currently running on 80-100 well-distributed servers. Expect around 300 servers within the next couple months. For deployment pictures, see here.
In the next couple weeks and months, we should be rolling out some technological changes to improve response time and cache utilization. An active client and server-operator community for the project is certainly welcome.
Given that the DNAME RFC is from 1999, it appears that some old DNS servers do not handle this record type well. We'll look into some alternatives or work-arounds. (Perhaps you can contact me directly to see if subsequent changes can fix your problem.)
Thanks for the detailed report!
--mike
PayPal.com and other solutions are not as well-suited for such distributed systems for a number of reasons. First of all, it places some dependence on a centralized, commercial service, requiring people to upload credit card information and such.
I spoke with Jim McCay for a while at the recent Berkeley conference on Anonymity and Unobservability, most of our discussion centered around the anonymity aspects of MojoNation. The micropayment scheme utilized is based on Chaumian ecash, which has the nice properties of being fairly small and straightforward.
User anonymity is ensured by the cryptographic blinding of ecash tokens during the withdrawal (issuing) stage of the protcol. Therefore, the issuing authority (MojoNation until some different infrastructure is set up) is not able to link payments received by "merchants" and the customers that used these tokens. The downside of Chaumian cash (as opposed to that of Stefan Brands) is that all verification to prevent double spending needs to occur on-line. This requires some central MojoNation issuing authority (or some distributed subset of varying authorities) that needs to be contacted for the verfication.
One main aspect of MojoNation that still lacks anonymity is actual peer-to-peer operations. Currently, these just have IP-layer connectivity for usability reasons...but this is hardly anonymous.
Jim pointed out that nothing prevents the eventual "plug-and-play" functionality of some anonymous channel - such as a mixnet (ZKS Freedom, Onion-Routing, etc.) - to be used between peer connections. While speed might be affected, the anonymous micropayments scheme fits right into a future addition of anonymous links.
It's going to be interesting to see MojoNation and other such systems develop.