Thanks to Ed and his fellow bloggers for welcoming me to the blog. I’m thrilled to have this opportunity, because as a law professor who writes about software as a regulator of behavior (most often through the substantive lenses of information privacy, computer crime, and criminal procedure), I often need to vet my theories and test my technical understanding with computer scientists and other techies, and this will be a great place to do it.
This past summer, I wrote an article (available for download online) about ISP surveillance, arguing that recent moves by NebuAd/Charter, Phorm, AT&T, and Comcast augur a coming wave of unprecedented, invasive deep-packet inspection. I won’t reargue the entire paper here (the thesis is no doubt much less surprising to the average Freedom to Tinker reader than to the average lawyer) but you can read two bloggy summaries I wrote here and here or listen to a summary I gave in a radio interview. (For summaries by others, see [1] [2] [3] [4]).
Two weeks ago, Verizon and AT&T told Congress that they would monitor for marketing purposes only users who had opted in. According to Verizon VP Tom Tauke, “[B]efore a company captures certain Internet-usage data for targeted or customized advertising purposes, it should obtain meaningful, affirmative consent from consumers.”
I applaud this announcement, but I’m curious how the ISPs will implement this promise. It seems like there are two architectural puzzles here: how does the user convey consent, and how does the provider distinguish between the packets of consenting and nonconsenting users? For an ISP, neither step is nearly as straightforward as it is for a web provider like Google, which can simply set and check cookies. For the first piece, I suppose a user can click a check box on a web-based form or respond to an e-mail, letting the ISP know he would like to opt in. These solutions seem clumsy, however, and ISPs probably want a system that is as seamless and easy to use as possible, to maximize the number of people opting in.
Once ISPs have a “white list” of users who have opted in, how do they turn this into on-the-fly discretionary packet sniffing? Do they map white-listed users to IP addresses and add these to a filter, or is there a risk that things will get out of sync during dhcp lease renewals? Can they use cookies, perhaps redirecting every http session to an ISP-run web server first using 301 http status codes? (This seems to be the way Phorm implements opt-out, according to Richard Clayton’s illuminating analysis.) Do any of these solutions scale for an ISP with hundreds of thousands of users?
And are things any easier if the ISP adopts an opt-out system instead?
This can’t be solely about targeted web advertising. If it were, wouldn’t they do the obvious: have the ISP provide an HTTP proxy that tracks HTTP activity and substitutes Phorm/NebuAd ads, and customers would “opt in” by using the proxy and “opt out” by not using any proxy to surf? (Obviously, there’d have to be some other benefit to using the proxy. A discount on each month’s bill if the proxy was used enough that month; useful information or services provided by the proxy, such as site safety information and phish protection, that might be provided relatively easily and scalably to a customer base via web proxy and otherwise would be difficult to implement; etc.)
Customer identification would be simple: the first line of routers would put MAC address information in a packet header that the proxy would see (and discard; this would not be in the packets the proxy sent forward to the net; the main outbound gateway would also drop this header on traffic that went out directly without going through the proxy).
opt in
Comment by joe malley on October 8th, 2008 at 11:39 am.
In review of paul’s blog, and the posted comments, I’m lost! It appears that there does not exist a common and effective system that would allow isp’s the ability to process their subscriber’s preferences to opt out/opt in as it relates to OBA ;morevover if this group doesn’t know of one, then there probably exists none at this time. It appears that there are some systems that allow limited ability to complete this task, but they are flawed and provide no assurances.
How can companies promote a system to complete a task, with technology that does not complete it’s task, and use such claims to obtain consent?
How then can nebuad and their isp’s say that one exists that allows user’s this ability?
how then can the isp’s tell the senate that opt in should be the new protocol when one doesn’t exist.?
feel free to comment here, or drop me a note at …….. , in confidence.Always interested in discussing legal options!
joe malley
Client-side software is a wretchedly bad idea. In addition to what Pete said, there are also compatibility issues — In order to paint a valid picture, it would have to run on every network device, not just a Windows PC, but also a Mac, Linux, BSD, Solaris, other UNIX of choice, other OS of choice, plus every game console, wireless and wired network device . . . it just becomes a huge mess very quickly.
I have a better option.
I mentioned before the idea of getting people to opt in by offering them something in return. You could kill two birds with one stone here — offer the user a free router, as a premium for opting in. The router then handles the monitoring. Problem solved.
(this is by one of the commenters formerly known as paul, who is barred by the comment system from using that name now that there’s an official FTT blogger using it)
if you just rewrite the terms of service making the accountholder responsible for the opting status of everyone who uses that account. Since a lot of TOS clauses already forbid sharing and multiple machines, this just pushes it back on the customer until someone’s congressional representative gets on the case again.
Even more complicated, of course, is how this is going to interact with COPPA, because the ISP per se has access to preteens’ home addresses, but can’t help tracking their actions if their parents opt in.
The solution is easy.
Install client side software.
But wait, the marketing industry tried that idea before.
It was labelled spyware and rookits, and got uninstalled by people who didn’t want their communications scammed by the marketing industry.
And how do web sites indicate opt in? Again very straightforward.
The ISP writes to the copyright holder/web site and asks for permission to intercept their private communications, and pays for a copyright licence toexploit the content.
Not so difficult after all eh?
I recently received an email from verizon that thanked me for opting in to a program in which I will no longer receive mail bills, just direct charges to my credit card.
I have not given them permission to do this. To stop them, will have to figure out how to opt out. (They included “opt out” instructions in their email that were incomplete and frustrating.)
At this time, I do not believe that Verizon can fairly administer an “opt in” program.
-tobias robison, author of the fantasy novel, “Raven’s gift”
I don’t understand how the ISP can use cookies to determine this consent. Account-level consent is appropriate; for a shared account the users should agree among themselves, just like they have to agree on the choice of ISP or the amount of bandwidth they buy.
Using cookies to check for consent simply doesn’t make sense: you can’t send several HTTP packets to read a cookie for every packet you are looking at. You must have a mechanism to tell that his particular connection is subject to surveillance. Worse, how do you read the cookie? Forge a packet from the destination? Even worse, there may be no browser running at all on the user’s machine (perhaps he’s only running BitTorrent, ftpd, and outoing ssh right now?) So, let’s assume that account gets a fixed IP address and the ISP can examine all outgoing packets from that IP address without further consent.
Now we reach the thorny issue: what about the other side of the connection. Should they get to have a say in this? I guess not — but people won’t be happy with it.
Using IP addresses for opt-in is perilous. Using cookies is problematic.
Let’s look a fairly typical example. A house with perhaps more than one computer. On at least one of the computers, there are multiple users. At least one of the users (let’s call him “Fred”) at times uses more than one browser (say, IE and Chrome on a PC, or Safari and Firefox on a Mac). Let’s say that Fred may be fine with *some* of his traffic being opted-in, but his housemate “Pat” is not so willing.
You can instantly see the problems.
First, Fred may be willing to opt-in some of his traffic but not al. There is not a good mechanism to handle this, other than perhaps if cookies are the mechanism and he is savvy enough to opt-in one of his browsers but not the other (or use some other way to force some traffic outside of the opt-in scheme, e.g., Chrome Incognito mode).
Second, there is no way on an IP level to allow Fred to opt-in, and protect Pat from data collection.
Third, even assuming that cookies are the mechanism, not all multi-user setups use separate logins. fred and Pat may use the same login and the same browser, effectively rendering their differing choices moot.
ISPs are not likely to pursue a cookie approach, as it’s too fragile. Many actions can cause a user’s cookies to be reset, leaving the ISP with the problem of re-soliciting opt-in (and how do they even distinguish between no traffic and cleared cookies without breaching privacy?)
Cookies aren’t that great a solution either: those concerned about privacy tend to clear their cookies often, which removes the “don’t track me” cookies set by the ad networks. Opting-out becomes a regular process rather than a single choice. The same mechanism is rarely used to opt in.
They may say “user” but they mean “account”. If I opt in, my wife and children and visitors using our shared computer will be observed too. Surely that has some legal implication.
The obvious problem of getting the users’ consent is in getting the user’s attention to ask it. One must first find a propagation vector for the message that permission is being asked.
The obvious propagation vector is the bill which the ISP must send on some sort of regular basis. An enclosure in the bill, which can be either a business reply card or can be enclosed with the bill payment (for those customers who still pay by cheque) giving permission to include the customer.
Of course, you have to get the customer to pay attention. The way you do that is to offer a discount of some sort. Perhaps, for instance, $5.00 off for three months would do it.
Finally, on sorting out the traffic, it should be noted that the ISP also controls the physical layer and link layer in most broadband deployments. As such, the MAC address of the broadband modem would probably suffice for reliably sorting the opted-in from the opted-out. Similar things are already in place to allow/deny a given modem access to the network (and thereby providing a means to disconnect a deadbeat customer).
Another option would be to have the DHCP servers assign IP addresses in different ranges for opted-in versus opted out, again, using the MAC address to determine ownership. This would require the opted-in customers to register the MAC addresses of their machines, though, since the addresses of the modems aren’t involved in the DHCP requests. The advantage of this, however, would be that opted in/out status would propagate further into the network, not just to the first switch, and this would help to centralize the monitoring equipment.
. . . as long as I can opt out, of course.