On 8 Feb 2002, jon schatz wrote: > On Thu, 2002-02-07 at 20:33, J Edgar Hoover wrote: > > This allows them to not only log all http requests, but to also log the > > response. Apparently they aren't using it to maximize bandwidth, because it's not > > configured to serve cached data. > > How do you know that it's not configured to serve up cached content? Aside from the fact that it was turned off on the server, it was easily documented by fetching urls on a machine you control, and seeing if you get served fresh or cached content. As a side note, at around 10AM EST today they turned caching on. Shortly after they became aware this thread. > > And yes, they have purchased a lot of the specific, unique hardware that > > is required to do all this logging. > > Once again, where's your inside knowledge of this? This isn't the appropriate venue to discuss how I found that out. I'll refrain from responding until comcast comments on this. > This is standard behavior for a transparent web proxy. Nothing new here. > These have been around for a while, and Inktomi is not the only company > to deploy one. Hell, you can do this with squid and ipchains: > > http://www.linuxpowered.com/archive/mini/TransparentProxy.html#toc5 Whether the device is performing correctly is not the question. The question is whether the device is appropriate at all in this context. > > This allows them to monitor and change (or insert ads into) what > > you read. > > It most certainly does. How do you know that they aren't already? They > probably aren't though, because as of 6 months ago, none of the major > players had the ability to insert content into requests. (more on this > later). > > > Interestingly, regardless of what IP you address the packet to, the > > Inktomi Traffic-Server reads the Host: field to determine where to send > > the packet. > > Once again, standard behavior for a proxy request. Most (if not all) > proxies are dependant on a partial HTTP/1.1. implementation, and without > the host header, all would be lost... It may be "standard behavior", but it is incorrect behavior. If I send a packet to my office, I expect it to go to my office, not comcast's. > > US Code TITLE 18, PART I, CHAPTER 119, Sec. 2511. (2) (a) (i) > > "...a provider of wire communication service to the public shall not > > utilize service observing or random monitoring except for mechanical or > > service quality control checks." > > AFAIK, this isn't snooping. I don't see the big deal. Most dialup users > are surfing transparently through a cache; the next big thing is > supposedly edge appliances that do this as a feature. They log the requested URL, and the response. They log it to a network storage device, that is simultaneously accessed by datamining software. This gets passwords, contents of webmail, web bbs posts, news you read, etc.. What part of this is *not* snooping? > Disclaimer: I do have inside knowledge. Not of Inktomi, but of a former > employer who manufactured a multi protocol transparent proxy capable of > real-time modification of content. It was pretty sweet technology. Used appropriately proxies are great tools. This just isn't the appropriate place to use one. > > Does federal law only apply when a little guy snoops on a big > > corporation? Where are the feds now? > > They're monitoring this whole exchange through the carnivore they > installed at mae-[east|central|west] :-) The logs of carnivore aren't like to end up in the hands of telemarketers. Carnivore won't likely be used to censor press or sites offensive to comcast. Incidently, the IP of one of the machines I used to test the evil proxy this week is now blocked. This isn't speculation, they've already started censoring. > -jon > > -- > jonat_private || www.divisionbyzero.com > gpg key: www.divisionbyzero.com/pubkey.asc > think i have a virus?: www.divisionbyzero.com/pgp.html > "You are in a twisty little maze of Sendmail rules, all confusing." >
This archive was generated by hypermail 2b30 : Fri Feb 08 2002 - 15:42:55 PST