|
|
|
Greetings. Allow me to channel the late Bob Keeshan for a few minutes. How might Captain Kangaroo have explained the "file sharing" controversy? Setting aside the technical details and application specifics, what P2P really is of course is ... sharing. Sharing is good. Though if you share something that you do not have the right to share, you risk a visit by the RIAA, MPAA, and similar parties, along with their handcuff-toting cohorts. But sharing materials to which you have the right to share is legal, period. And remember, sharing is good. There is no requirement in logic or law that the originator of material to be shared must personally distribute it everywhere, or bear the cost of distributing that material to the world. Once a shared item is in the possession of others, they are usually free to independently decide with whom they'd like to further share it. It's theirs to share now. And sharing remains good. There are many ways to share. Before "formal" P2P ever existed, computer-based sharing took place via BBS systems, UUCP, and even e-mail list server responders. FTP and HTTP are other ways to share, but of course most ISPs at least in theory forbid the running of servers by most consumers, and sometimes enforce this by blocking. They don't want you to share. Even when there's lots of bandwidth, even when you pay for a big upstream pipe, they really would prefer that you stick with the conventional "broadcast" model. They don't seem to like sharing, do they? But people still want to share. They want to share ideas, they want to share files, they want to share resources, they want to share CPU cycles. Who knows, someday there may be search engines that operate as vast shared applications rather than concentrated at massive data centers! "Google" running on the Treasure House PC! Wouldn't that be fun? An earlier poster implied that a possible response to encrypted sharing might be banning encryption except for really, truly important things, like dealing with ... money. The Captain doesn't think that idea is going to fly farther than a water-filled ping pon... uh, the little white balls that get paddled back and forth across a Net. There will always be technologies that disrupt existing methodologies and upset ongoing business plans. We can argue specifics of protocols and topologies, and try to tune our applications to be as efficient and yes, technologically "polite" as possible. But if there's one lesson that history teaches us on this score, it's that trying to suppress the march of such technologies is as futile as trying to stop the Earth from turning by blowing really, really hard. And now, it's time for Tom Terrific. Today's episode: "Crabby Appleton Starts an ISP!" --Lauren-- |
|
Greetings. Over at the Network Neutrality Squad, the issue of ISPs intercepting and/or diverting DNS (Domain Name Service) lookups has recently risen to the surface. Some tests that you can perform to investigate this for yourself on your ISP are described below. Increasingly, ISPs have been attempting to monetize users' Web browsing in various ways, and steering them to ISP-partnered search engines in cases of mistyped domain names and the like is just one example of this activity. There is a great deal of variation in how this is accomplished; whether or not effective opt-outs are available; and how forthright, opaque, or simply confused ISPs' tech support pages and people may be regarding this matter. Beyond the issue of shunting users to search engines of the ISPs' own choosing, diversion of DNS requests can have significant negative impacts on various applications, especially non-browsing (non-http) applications. In some cases, ISP DNS diversion can be bypassed simply by changing router and/or client DNS settings to those of your own choosing. But a particularly devious practice involves ISPs actually intercepting "port 53" UDP and/or TCP DNS traffic and rerouting it to their selected servers, making the most straightforward bypass techniques ineffective. This appears to be the situation disclosed today on the NNSquad Discussion List regarding HughesNet. Testing for DNS interception can be somewhat tricky, but last night I set up a quick hack involving a "dummy" DNS test zone on an NNSquad server to make it a bit easier to accomplish, if you access to either the dig or nslookup utilities on your system. On Linux, for example, you would enter the dig or nslookup commands directly on your normal shell command line. Under Windows XP you can run nslookup via: Start->Run, then enter the word nslookup in the Run box, then click OK. For Vista, use Start->All Programs->Accessories->Command Prompt to open a command window, then at the prompt enter nslookup followed by newline. Under Mac OS-X (to use dig) first navigate to the Applications/Utilities folder, then launch Terminal.app, then enter the dig command. Now for the actual tests. You want to run both TCP (zone transfer) and UDP (regular DNS lookup) tests, since it is quite possible that even when diversion is in place, it may not affect both UDP and TCP, though UDP diversion will be the typical focal point. The correct zone output for the DNS test zone -- control.hq -- is available right here. These data entries (including the test zone name itself) are subject to change at intervals to discourage copying of this data into other servers in an attempt to dilute this test. The tests involve doing DNS lookups and comparing the results with the official zone ip address entries (note the trailing "." following the "hq" in the entries below). Using dig: TCP: dig @dns-test.nnsquad.org control.hq. axfr UDP: dig @dns-test.nnsquad.org control.hq. Using nslookup ([enter] means the "enter" or "return" key): nslookup [enter] These are only examples of the possible tests -- feel free to run other combinations on the test zone as you wish. If you get back results that show the same ip addresses as the official test zone output (remember to verify these at the link since they're subject to change) then your DNS is probably not being diverted. If you get nothing back or in particular if you get different ip addresses back (as in that HughesNet example mentioned above), then that's a smoking gun for low-level DNS diversion. Please report instances of suspected diversions -- in as much detail as possible -- directly to me. Thanks very much! --Lauren-- |
|
Greetings. The Pentagon abruptly canceled plans to post online a new report (and also canceled a related background briefing) that concludes the lack of a link between Saddam Hussein's Iraq and al Qaeda. DOD is also now refusing to e-mail out copies of the report, and is only making it available in physically mailed CD-ROM form upon request. In an age when any "good news" about the war in Iraq goes online immediately from the Pentagon's PR machine, the word is that DOD decided that this report was too politically sensitive to be made easily and widely available via the Internet. Fascinating. Nevertheless, redacted (obviously scanned) versions of the executive summary and the main body of this report are already circulating, and I've saved copies for your edification if you so desire: Executive Summary (~3.4 MB) Main Report (~11.7 MB) --Lauren-- |
|
Greetings. Given the CCTV surveillance fetish in the UK these days, it seems somehow sickly appropriate that British ISPs are in the forefront when it comes to spying on the content of their subscribers' Web browsing -- and it appears that Google users are in the bull's-eye. Most of the related media attention so far has revolved around the manner in which the three largest UK ISPs have gone to bed with Phorm, toward the goal of monetizing Web browsing habits of subscribers and providing targeted ads. Of course, there's a lot "soothing" promotional blather on the BT site claiming that the data collected regarding the sites that you visit is quickly deleted or anonymized. And while officially the ISPs claim that they haven't made a decision about opt-out vs. opt-in, the current British Telecom limited deployment (they call the "service" Webwise and promote it as mainly an anti-phishing system) appears to be opt-out (requiring either maintaining a special cookie in your browser or blocking all cookies from a particular site). Third-party tracking of the Web sites that you visit is bad enough, but Webwise (and presumably the other incarnations of the Phorm system) go one big step farther -- they actually spy on your Web content and extract for their own use the search terms that you enter into search engines: We [Webwise] use the website address, keywords and search terms from the page viewed to match a category or area of interest (e.g., travel or finance). Given that the vast majority of searches these days are conducted with Google, it's obvious that this ISP-based system will be attempting to monetize the vast number of search transactions between users and Google, in a technical manner that seems eerily similar to wiretapping. This is unbelievably intrusive and unacceptable, except perhaps on a fully-informed opt-in basis. When I use a search engine -- let's say Google -- I am expressing an implicit belief that my search data will not be abused or misused by Google. I have made no such determinations regarding any use in any manner of this search query data by ISPs or their partners. I'm communicating with Google. Period. I don't care if the ISPs claim that the data is quickly discarded, or anonymized so well that it looks like an iPhone that's been put through a blender, nobody but Google and I have any rights to those search terms! And we all know that search keywords can be very sensitive. Names, addresses, social security numbers (sloppy, but people do it), searches for new words to be used for domains or product names -- all manner of personally and commercially sensitive information can be found in search query data. Anyone who tried this stunt on such a basis with physical mail or phone calls they'd probably land in prison. But ISPs are increasingly pushing the envelope in terms of spying on and even altering subscriber Web traffic. This latest example is utterly beyond the pale, and it's hard to see how such abusive behavior can continue to pass legal muster indefinitely. If subscribers wish to opt-in to such systems with a full understanding of what's involved -- well, I wouldn't recommend it but that's their choice. However, if these systems are fully deployed in a manner that requires subscribers to opt-out to avoid having their communications with Google and other search engines being intercepted, then I foresee some very angry subscribers, and a particular search services giant who will likely be anything but amused. --Lauren-- |
