A few days ago, Ars Technica asked me to comment on a class action lawsuit against Paxfire, a company that partners with Internet Service Providers for the purpose of “monetizing Address Bar Search and DNS Error traffic.” The second half of that basically means fixing URL typos, so when you accidentally tell your ISP you want the webpage for “catoo.org,” they figure out you probably mean Cato. The more controversial part is the first half: When users type certain trademarked terms into a unified address/search bar (but not a pure search bar, or a search engine’s own home page), Paxfire directs the user to the page of paying affiliates who hold the trademark. So, for instance, if I type “apple” into the address bar, Paxfire might take me straight to Apple’s home page, even though Firefox’s default behavior would be to treat it as a search for the term “apple” via whatever search engine I’ve selected as my default.
Now I think that’s likely wrong. My mistake was in not thinking clearly enough about the mechanics. Because, of course, neither your ISP nor Paxfire see what you type into your address bar; they see specific packets transmitted to them by your browser. And it turns out that the way they pull out the terms you’ve entered in a search bar is, in effect, by opening a lot of envelopes addressed to somebody else.
Some quick Internet 101: When you type “apple.com” into your address bar, your browser first checks with your ISP (or, if you’re a techie, maybe with some other Domain Name System server you’ve specified) to look up the computer-friendly numerical address corresponding to the human-friendly URL. Then the browser sends a GET request—basically just a packet saying “give me this page please”—to the IP address of the machine where it think apple.com lives. But if you just type “apple” into a lot of modern browsers, then depending on their settings, they may not pass that on to your ISP’s DNS server at all. Instead, the browser recognizes that you’ve entered something that isn’t formatted like a URL, and sends a packet straight to your default search engine, whose content is “please give me a page of results for the search term apple.” That’s annoying to the ISP, because it means they get cut out of an opportunity to monetize your eyeballs by (for instance) charging Apple to send you straight there, or delivering you their own search results (with their own ads).
According to some network researchers who explained their findings at EFF’s site, here’s how Paxfire and some of its ISP partners have apparently solved the “problem.” When your browser goes to look up the IP address of your default search engine—that is, when it asks your ISP’s domain name server where it can find “Bing.com” or “Google.com”—the ISP just systematically lies. It tells your browser that one of Paxfire’s servers is really Google.* Paxfire then acts as an invisible proxy, or “man in the middle”: It looks at the request your browser was trying to submit to Google, and in most cases resubmits the identical request to Google itself, then passes along Google’s response without logging anything. An ordinary user wouldn’t notice that Paxfire had been involved at all. But! When their servers see a search that was both originated from a browser’s address bar (the search parameters apparently reveal this) and matches their list of trademarked terms, they’ll log the query and instead return their own page.
The crucial point here is that by the time the packet gets to Paxfire, it’s no longer ambiguous whether “apple” was supposed to be an address or a search term. By the time it gets to Paxfire, “apple” is the content of a message addressed to Google, which reads “please send me search results for apple, and by the way, I’m asking from a Firefox address bar.” The mechanics are opaque to the average user, but Paxfire is in effect combing through all these messages to find the ones that maybe, possibly, perchance the user really meant to be an address rather than a search request, because they don’t really understand how their browsers work. And thaaats kinda wiretappy.
Except, of course, it’s still complicated. If an ordinary citizen taps your phone or your Internet connection, they’re guilty of wiretapping (a felony, for those keeping score at home) the instant they “acquire” the communication, regardless of what they do with it. If I rig your computer to send me copies of all your emails (without your consent), it makes no difference whether I ever read any of them or use them for any purpose. If, for some bizarre reason, I’ve done this and then set my system set to automatically erase the e-mails upon receipt, I’m still equally guilty of illegal “interception” of your communications. (It’s a separate offense to “use” or “disclose” communications that have been illegally intercepted.) The crime occurs at the instant of acquisition.
The rules are different for telecom companies, because the only way to have communications on a packet switched network is for various intermediaries to “acquire” your communications in order to pass them along. So the Wiretap Act’s definition of “interception” explicitly excludes acquisition by a provider’s computers in the “ordinary course of business.” It’s a separate offense for the provider to “divulge” the contents of a communication to any third party, and here there’s no loose “ordinary course of business” exception. Third-party disclosure is allowed when it’s a “necessary incident” of providing the communications service, or when the contents are passed to an entity whose facilities are used to forward the communication to its intended recipient, or with the consent of one of the parties to the communication. (There are a bunch of other exceptions, but they’re not relevant here.) The interesting wrinkle here is that while for most of us, it’s simple to determine when we’ve “intercepted” a communication, for telecom providers it’s kind of complicated: Unlike the rest of us, they’re allowed to acquire and disclose other people’s communications in the ordinary course of business, so whether an illegal interception has occurred doesn’t just depend on where the data goes, but on what they’re doing with it, and why.
Unsurprisingly, Paxfire’s reply to the suit against them seeks to invoke the “ordinary course of business” exception, among other arguments. Exactly what qualifies as the “ordinary course of business” in this rapidly changing industry is an open question, and circuit court rulings are all over the map, with none directly on point. If that were what we had to assess, I might say flip a coin. But the standard for “divulging” to third parties is more stringent—which makes sense, when you think about it. The law essentially gives providers more leeway in deciding what kinds of internal monitoring or processing are necessary, but sets a higher bar for disclosure to others.
Claiming that redirection of search traffic to Paxfire is a “necessary incident” of service seems like a nonstarter. The more obvious out for the ISPs here is 18 U.S.C. 2511(3)(b)(iii), authorizing disclosure to a person whose facilities are used to forward the message. But a little common sense is needed here: Anyone eavesdropping on a realtime packet-switched communication would normally forward the intercepted packets to their intended recipients. We can’t read this as a sort of blanket loophole for wiretapping executed as a man-in-the-middle attack.
What seems dispositive here is that, while Paxfire is ultimately forwarding most query packets to their intended recipients, ISPs aren’t routing traffic through Paxfire as a means of getting it to the intended recipient, Google. The more direct way to achieve that would be not lying to our browsers when they ask for Google’s IP address, and letting our requests go through normally. Rather, the only rationale for routing the traffic to Paxfire is what they do other than the normal routing and forwarding Internet switches do. The only difference Paxfire makes is that it sometimes doesn’t just forward packets to their intended recipients in the normal way, but sends the user to some affiliate’s page instead. It would make a kind of nonsense of the statute to apply the forwarding exception to these circumstances.
Perhaps counterintuitively, it’s not nearly as clear that Paxfire itself falls on the wrong side of the law here, because a court might well regard their actions as covered by the telecom provider’s “ordinary course of business” restriction on the statutory definition on “interception.” If everyone whose traffic was routed through Paxfire had clearly given informed consent to the filtering and occasional rerouting of their search queries, what Paxfire’s doing would clearly be legal, and one could argue it’s really the ISP’s problem to ensure they’re allowed to pass along the traffic they do.
That, of course, brings us back to the crucial question of consent. All of this is moot if the ISPs had the informed consent of their subscribers to do this. Paxfire says they all did, pointing to privacy policies like this one on RCN’s website. But it’s not clear that this does or should meet the relatively high standard for consent to interception under the Wiretap Act. Congress clearly wanted to establish a pretty strong presumption against the interception of communications content. In this case, that means that when monitoring or disclosure go beyond the “ordinary course” and “necessary incident” exceptions, it seems appropriate to demand that each individual whose communications are intercepted have actual, specific, effective notice that their communications are subject to interception. In considering a case involving workplace monitoring of an employee’s personal calls, the 11th Circuit gave an indication of the stringency of the consent requirement:
It is clear, to start with, that Watkins did not actually consent to interception of this particular call. Furthermore, she did not consent to a policy of general monitoring. She consented to a policy of monitoring sales calls but not personal calls. This consent included the inadvertent interception of a personal call, but only for as long as necessary to determine the nature of the call. So, if Little’s interception went beyond the point necessary to determine the nature of the call, it went beyond the scope of Watkins’ actual consent.
Consent under title III is not to be cavalierly implied. Title III expresses a strong purpose to protect individual privacy by strictly limiting the occasions on which interception may lawfully take place.
Your mileage may differ, but that sounds hard to square with the claim that “consent” exists for each user provided that whichever member of the household pays the bills checked a box next to a link to a dozen pages of dense legal boilerplate, which studies suggest nobody actually reads. Title III, after all, is to a substantial extent a regulation of telecom operators themselves—which means it would be contrary to the purpose of the statute to let them so easily disclaim liability, and to pile broad new exceptions atop the detailed list Congress created.
The key point to bear in mind here is that the strong statutory presumption against interception is of enormous benefit to the providers. People normally don’t scrutinize the legal boilerplate on ISP privacy policies, I want to suggest, because they take for granted that wiretapping is illegal, and that ISPs will not, in fact, routinely allow marketers to sift through the contents of their private communications. If users and customers had to fear that a communications provider was likely to assert the right to do this, based on item D(3) on page 12… a lot of providers would lose a hell of a lot of business, because most people don’t want to have to get a JD in order to be able to feel confident they can communicate securely. I know some of my libertarian friends will say it would be better if everyone did have to pay close attention to all these clickwrap contracts, but in the world we currently live in, people do rely on the strong statutory default prohibiting interception and disclosure. Providers whose business depends pretty heavily on consumer expectations of a strong default shouldn’t be allowed to turn around and assert that the default is actually so weak as to be almost trivially overcome when it might permit them to rake in a few extra bucks on the side.
* Actually, they’ve apparently stopped proxying Google specifically, but roll with me for illustrative purposes.