February 20, 2018

Dissecting the (Likely) Forthcoming Repeal of the FCC’s Privacy Rulemaking

Last week, the House and Senate both passed a joint resolution that prevents the new privacy rules from the Federal Communications Commission (FCC) from taking effect; the rules were released by the FCC last November, and would have bound Internet Service Providers (ISPs) in the United States to a set of practices concerning the collection and sharing of data about consumers. The rules were widely heralded by consumer advocates, and several researchers in the computer science community, including myself , played a role in helping to shape aspects of the rules. I provided input into the rules that helped preserve the use of ISP traffic data for research and protocol development.

How much should we be concerned? Consumers have cause for concern, but almost certainly not as much as the media would have you believe. The joint resolution is expected to be signed by the President, whereupon it will go into law. Many articles in the news last week announced the joint resolution passed by Congress as a watershed moment, saying effectively that Internet service providers can “now” sell your data to the highest bidder. Yet, the first thing to realize is that Internet service providers were never prevented from doing this, and in some sense, the Congressional repeal simply preserves the status quo, with respect to ISPs and data sharing. That is, the privacy rule that was released last November, never went into effect. That said, there is one thing that consumers might be more concerned about: The resolution also prevents the FCC from making similar rules in the future, which has the effect of removing the threat of regulatory action on privacy. Previously, even though it was legal for ISPs to share your data without your consent, they might not have done so simply for fear of regulatory action from the FCC. If this resolution becomes law, there is no longer such a threat, and we will have to rely on market forces for ISPs to be good stewards of our data.

With these high-order bits in mind, the rest of this post will dissect the events over the past year or so in more detail.

Who regulates privacy? Part of the complication surrounding the debates on privacy is that there are currently two agencies in our government who are primarily responsible for protecting consumer privacy. The Federal Trade Commission (FTC) operates under the FTC Act and regulates consumer protection for businesses that are not “common carriers”; this includes most businesses, with the exception of public utilities, and—recently, with the passage of the Open Internet Order (the so-called “net neutrality” rule) in 2015—ISPs. One of the landmark decisions in the Open Internet Order was to classify ISPs under “Title II” (telecommunications providers), whereas previously they were classified under Title I. This action effectively moved the jurisdiction for regulating ISP privacy from the FTC (where Google, Facebook, and other Internet companies are regulated) to the FCC.

Essentially, there is a firewall of sorts between the two agencies when it comes to privacy rulemaking: The FTC is prohibited by federal law from regulating common carriers, and the FCC has a statutory mandate (under Section 222 of the telecommunications act) to protect customer data that is collected by common carriers.

Are the FCC’s privacy rules “fair”? Part of the debate from the ISPs surrounds whether this separation is fair: ISPs like Comcast and online service providers (so called “edge providers” in Washington) like Google are increasingly competing in the same markets, and regulating them under different rules can in some sense create an uneven playing field. Depending on your viewpoint and orientation, there is some merit to this argument: The FCC’s privacy rules are stronger than the FTC’s rules, as the FCC’s rules govern additional information that cannot be shared without user consent, such as browsing history, application usage history, and geolocation. Companies who are regulated by the FTC (Google, Facebook, etc.) have no such restrictions on sharing your data without your consent. Whether this situation is “fair” depends in some sense on your perspective about whether edge providers like Google and ISPs like Comcast should be subject to the same rules.

  • The ISP viewpoint (and the Republican rationale behind the resolution) of the joint resolution is that for the Googles and Facebooks of the world, your data is not considered sensitive; they can already gather this information about your browsing history and sell it to third-party marketers. The ISPs and Republicans view that if ISPs and edge providers are really in the same market (or should allowed to be), then they shouldn’t be subject to different rules. That sounds good, except there are a couple of hangups. The first is, as mentioned, the FTC cannot regulate ISPs; they are prohibited from doing so by federal law. Unless the ISPs are reclassified again under Title I, they may currently end up in a situation where nobody can legally regulate them, since the FTC is already prevented from doing so, and it is increasingly looking like the FCC will be prevented from doing so, as well. The charitable viewpoint to the situation is that the goal appears to be not to get rid of privacy rules entirely, but rather to shift everything concerning consumer privacy back to the FTC, where ISPs and edge providers are subject to the same rules. But, in the meantime, the situation may be suspended in a strange limbo.
  • The consumer advocate viewpoint is that, in the current market for ISPs in the United States, many consumers do not have a choice of ISP. Therefore, the ISPs are in a position of power that the edge providers do not have. In many senses, that is true: in many parts of the United States, studies from the FCC and elsewhere have shown that consumers have only one choice of broadband ISP. This places the ISP in a position of great power, because we can’t just rely on “market forces” to encourage good behavior towards consumers if consumers can’t vote with their feet. Effectively, in contrast to edge providers such as Google or Facebook, in certain markets in the US, one cannot simply “opt out” of one’s ISP. There are also some arguments that ISPs can see a lot more data than edge providers can; that point is certainly arguable, given the level of instrumentation that a company like Google has on everything from the trackers they place on just about every website on the Internet to their command over our browser, mobile operating system, etc. More likely, we should be equally concerned about both edge providers and ISPs.

The repeal, and the status quo. In essence, the repeal that is likely to come in the coming weeks should cause concern, but it is not quite as simple as “ISPs can now sell your data to the highest bidder”. Keep in mind that ISPs have always legally been able to do so, and they haven’t done so yet. In fact, on Friday, Comcast just committed to not selling your data to third-party marketers, which provides some hope that the market will, in fact, induce behavior that is good for consumers. In some sense, the repeal will do nothing except to preserve the status quo. Ultimately, time will tell. I do expect that increasingly ISPs may look increasingly like advertisers—after all, they have been trying to get into the business of advertising for years. Without the threat of regulatory enforcement that has existed until now, ISPs may be more likely to enter these markets (or at least try to do so). In the coming years, there may not be much we can do about this except hope that the market enforces good behavior. It should be noted that, despite the widespread attention to Virtual Private Networks as a possible defense against ISP data collection over the past week, these offer scant protection against the kinds of data that would or could be collected about you, as I and others have previously explained.

Privacy is a red herring. The real problem is lack of competition. The prospect of relying on the market brings me to a final point. One of the oft-forgotten provisions of the Open Internet Order’s reclassification of the ISPs under Title II is that the FCC can compel the ISPs to “unbundle the local loop”—a technical term for letting competing ISPs share the underlying physical infrastructure. We used to have this situation in the United States (older readers probably remember the days of “mom and pop” DSL providers who leased infrastructure from the telcos), and many countries in Europe still have competitive markets by virtue of this structure. One possible path forward that could give more leverage to market forces would be to unbundle the local loop under Title II. This outcome is widely viewed to be highly unlikely.

Part of the reason this might be unlikely is that if Title II reclassification is walked back and ISPs end up in the Title I regime once again. Oddly, though we are likely to hear much uproar over the “repeal” of the net neutrality rules, one silver lining will be that if and when such a rollback occurs, the ISPs will be bound by some privacy rules. If the current resolution passes, they’ll be bound by none at all.

Finally, it is worth remembering that there are other uses of customer data besides selling it to advertisers. My biggest role in helping shape the FCC’s original privacy rules was to help preserve the use of this data for Internet engineers and researchers who continue to develop new algorithms and protocols to help the Internet perform better, and to keep us safe from attacks ranging from denial of service to phishing. While none of us may be excited at the prospect of having our data shared with advertisers without our consent, we all benefit from other operational uses of this data, and those uses should certainly be preserved.

Mitigating the Increasing Risks of an Insecure Internet of Things

The emergence and proliferation of Internet of Things (IoT) devices on industrial, enterprise, and home networks brings with it unprecedented risk. The potential magnitude of this risk was made concrete in October 2016, when insecure Internet-connected cameras launched a distributed denial of service (DDoS) attack on Dyn, a provider of DNS service for many large online service providers (e.g., Twitter, Reddit). Although this incident caused large-scale disruption, it is noteworthy that the attack involved only a few hundred thousand endpoints and a traffic rate of about 1.2 terabits per second. With predictions of upwards of a billion IoT devices within the next five to ten years, the risk of similar, yet much larger attacks, is imminent.

The Growing Risks of Insecure IoT Devices

One of the biggest contributors to the risk of future attack is the fact that many IoT devices have long-standing, widely known software vulnerabilities that make them vulnerable to exploit and control by remote attackers. Worse yet, the vendors of these IoT devices often have provenance in the hardware industry, but they may lack expertise or resources in software development and systems security. As a result, IoT device manufacturers may ship devices that are extremely difficult, if not practically impossible, to secure. The large number of insecure IoT devices connected to the Internet poses unprecedented risks to consumer privacy, as well as threats to the underlying physical infrastructure and the global Internet at large:

  • Data privacy risks. Internet-connected devices increasingly collect data about the physical world, including information about the functioning of infrastructure such as the power grid and transportation systems, as well as personal or private data on individual consumers. At present, many IoT devices either do not encrypt their communications or use a form of encrypted transport that is vulnerable to attack. Many of these devices also store the data they collect in cloud-hosted services, which may be the target of data breaches or other attack.
  • Risks to availability of critical infrastructure and the Internet at large. As the Mirai botnet attack of October 2016 demonstrated, Internet services often share underlying dependencies on the underlying infrastructure: crippling many websites offline did not require direct attacks on these services, but rather a targeted attack on the underlying infrastructure on which many of these services depend (i.e., the Domain Name System). More broadly, one might expect future attacks that target not just the Internet infrastructure but also physical infrastructure that is increasingly Internet- connected (e.g., power and water systems). The dependencies that are inherent in the current Internet architecture create immediate threats to resilience.

    The large magnitude and broad scope of these risks implore us to seek solutions that will improve infrastructure resilience in the face of Internet-connected devices that are extremely difficult to secure. A central question in this problem area concerns the responsibility that each stakeholder in this ecosystem should bear, and the respective roles of technology and regulation (whether via industry self-regulation or otherwise) in securing both the Internet and associated physical infrastructure against these increased risks.

Risk Mitigation and Management

One possible lever for either government or self-regulation is the IoT device manufacturers. One possibility, for example, might be a device certification program for manufacturers that could attest to adherence to best common practice for device and software security. A well-known (and oft-used) analogy is the UL certification process for electrical devices and appliances.

Despite its conceptual appeal, however, a certification approach poses several practical challenges. One challenge is outlining and prescribing best common practices in the first place, particularly due to the rate at which technology (and attacks) progress. Any specific set of prescriptions runs the risk of falling out of date as technology advances; similarly, certification can readily devolve into a checklist of attributes that vendors satisfy, without necessarily adhering to the process by which these devices are secured over time. As daunting as challenges of specifying a certification program may seem, enforcing adherence to a certification program may prove even more challenging. Specifically, consumers may not appreciate the value of certification, particularly if meeting the requirements of certification increases the cost of a device. This concern may be particularly acute for consumer IoT, where consumers may not bear the direct costs of connecting insecure devices to their home networks.

The consumer is another stakeholder who could be incentivized to improve the security of the devices that they connect to their networks (in addition to more effectively securing the networks to which they connect these devices). As the entity who purchases and ultimately connects IoT devices to the network, the consumer appears well-situated to ensure the security of the IoT devices on their respective networks. Unfortunately, the picture is a bit more nuanced. First, consumers typically lack either the aptitude or interest (or both!) to secure either their own networks or the devices that they connect to them. Home broadband Internet access users have generally proved to be poor at applying software updates in a timely fashion, for example, and have been equally delinquent in securing their home networks. Even skilled network administrators regularly face network misconfigurations, attacks, and data breaches. Second, in many cases, users may lack the incentives to ensure that their devices are secure. In the case of the Mirai botnet, for example, consumers did not directly face the brunt of the attack; rather, the ultimate victims of the attack were DNS service providers and, indirectly, online service providers such as Twitter. To the first order, consumers suffered little direct consequence as a result of insecure devices on their networks.

Consumers’ misaligned incentives suggest several possible courses of action. One approach might involve placing some responsibility or liability on consumers for the devices that they connect to the network, in the same way that a citizen might be fined for other transgressions that have externalities (e.g., fines for noise or environmental pollution). Alternatively, Internet service providers (or another entity) might offer users a credit for purchasing and connecting only devices that it pass certification; another variation of this approach might require users to purchase ”Internet insurance” from their Internet service providers that could help offset the cost of future attacks. Consumers might receive credits or lower premiums based on the risk associated with their behavior (i.e., their software update practices, results from security audits of devices that they connect to the network).

A third stakeholder to consider is the Internet service provider (ISP), who provides Internet connectivity to the consumer. The ISP has considerable incentives to ensure that the devices that its customer connects to the network are secure: insecure devices increase the presence of attack traffic and may ultimately degrade Internet service or performance for the rest of the ISPs’ customers. From a technical perspective, the ISP is also in a uniquely effective position to detect and squelch attack traffic coming from IoT devices. Yet, relying on the ISP alone to protect the network against insecure IoT devices is fraught with non-technical complications. Specifically, while the ISP could technically defend against an attack by disconnecting or firewalling consumer devices that are launching attacks, such an approach will certainly result in increased complaints and technical support calls from customers, who connect devices to the network and simply expect them to work. Second, many of the technical capabilities that an ISP might have at its disposal (e.g., the ability to identify attack traffic coming from a specific device) introduce serious privacy concerns. For example, being able to alert a customer to (say) a compromised baby monitor requires the ISP to know (and document) that a consumer has such a device in the first place.

Ultimately, managing the increased risks associated with insecure IoT devices may require action from all three stakeholders. Some of the salient questions will concern how the risks can be best balanced against the higher operational costs that will be associated with improving security, as well as who will ultimately bear these responsibilities and costs.

Improving Infrastructure Resilience

In addition to improving defenses against the insecure devices themselves, it is also critical to determine how to better build resilience into the underlying Internet infrastructure to cope with these attacks. If one views the occasional IoT-based attack inevitable to some degree, one major concern is ensuring that the Internet Infrastructure (and the associated cyberphysical infrastructure) remains both secure and available in the face of attack. In the case of the Mirai attack on Dyn, for example, the severity of the attack was exacerbated by the fact that many online services depended on the infrastructure that was attacked. Computer scientists and Internet engineers should be thinking about technologies that can both potentially decouple these underlying dependencies and ensure that the infrastructure itself remains secure even in the event that regulatory or legal levers fail to prevent every attack. One possibility that we are exploring, for example, is the role that an automated home network firewall could play in (1) help- ing users keep better inventory of connected IoT devices; (2) providing users both visibility into and control over the traffic flows that these devices send.


Improving the resilience of the Internet and cyberphysical infrastructure in the face of insecure IoT devices will require a combination of technical and regulatory mechanisms. Engineers and regulators will need to work together to improve security and privacy of the Internet of Things. Engineers must continue to advance the state of the art in technologies ranging from lightweight encryption to statistical network anomaly detection to help reduce risk; similarly, engineers must design the network to improve resilience in the face of the increased risk of attack. On the other hand, realizing these advances in deployment will require the appropriate alignment of incentives, so that the parties that introduce risks are more aligned with those who bear the costs of the resulting attacks.

The Effects of the Forthcoming FCC Privacy Rules on Internet Security

Last week, the Federal Communications Commission (FCC) announced new privacy rules that govern how Internet service providers can share information about consumers with third parties.  One focus of this rulemaking has been on the use and sharing of so-called “Consumer Proprietary Network Information (CPNI)”—information about subscribers—for advertising. The Center for Information Technology Policy and the Center for Democracy and Technology jointly hosted a panel exploring this topic last May, and I have previously written on certain aspects of this issue, including what ISPs might be able to infer about user behavior, even if network traffic were encrypted.

Although the forthcoming rulemaking targets the collection, use, and sharing of customer data with “third parties”, an important—and oft-forgotten—facet of this discussion is that (1) ISPs rely on the collection, use, and sharing of CPNI to operate and secure their networks and (2) network researchers (myself included) rely on this data to conduct our research.  As one example of our work that is discussed today in the Wall Street Journal, we used DNS domain registration data to identify cybercriminals before they launch attacks. Performing this research required access to all .com domain registrations. We have also developed algorithms that detect the misuse of DNS domain names by analyzing the DNS lookups themselves. We have also worked with ISPs to explore the relationship between Internet speeds and usage, which required access to byte-level usage data from individual customers. ISPs also rely on third parties, including Verisign and Arbor Networks, to detect and mitigating attacks; network equipment vendors also use traffic traces from ISPs to test new products and protocols. In summary, although the goal of the FCC’s rulemaking is to protect the use of consumer data, the rulemaking could have had unintended negative consequences for the stability and security of the Internet, as well as for Internet innovation.

In response to the potential negative effects this rule could have created for Internet security and networking researchers, I filed comment with the FCC highlighting how network operators researchers depend on data to keep the network operating well, to keep it secure, and to foster continued innovation.  My comment in May highlights the type of data that Internet service providers (ISPs) collect, how they use it for operational and research purposes, and potential privacy concerns with each of these datasets.  In my comment, I exhaustively enumerate the types of data that ISPs collect; the following data types are particularly interesting because ISPs and researchers rely on them heavily, yet they also introduce certain privacy concerns:

  • IPFIX (“NetFlow”) data, which is the Internet traffic equivalent of call data records. IPFIX data is collected at a router and contains statistics about each traffic flow that traverses the router. It contains information about the “metadata” of each flow (e.g., the source and destination IP address, the start and end time of the flow). This data doesn’t contain “payload” information, but as previous research on information like telephone metadata has shown, a lot can be learned about a user from this kind of information. Nonetheless, this data has been used in research and security for many purposes, including (among other things) detecting botnets and denial of service attacks.
  • DNS Query data, which contains information about the domain names that each IP address (i.e., customer) is looking up (i.e., from a Web browser, from an IoT device, etc.). DNS query data can be highly revealing, as we have shown in previous work. Yet, at the same time, DNS query data is also incredibly valuable for detecting Internet abuse, including botnets and malware.

Over the summer, I gave a follow-up a presentation and filed follow-up comments (several of which were jointly authored with members of the networking and security research community) to help draw attention to how much Internet research depends on access to this type of data.  In early August, a group of us filed a comment with proposed wording for the upcoming rule. In this comment, we delineated the types of work that should be exempt from the upcoming rules. We argue that research should be exempt from the rulemaking if the research: (1) aims to promote security, stability, and reliability of networks, (2) does not have the end-goal of violating user privacy; (3) has benefits that outweigh the privacy risks; (4) takes steps to mitigate privacy risks; (5) would be enhanced by access to the ISP data.  In delineating this type of research, our goal was to explicitly “carve out” researchers at universities and research labs without opening a loophole for third-party advertisers.

Of course, the exception notwithstanding, researchers also should be mindful of user privacy when conducting research. Just because a researcher is “allowed” to receive a particular data trace from an ISP does not mean that such data should be shared. For example, much network and security research is possible with de-identified network traffic data (e.g., data with anonymized IP addresses), or without packet “payloads” (i.e., the kind of traffic data collected with Deep Packet Inspection). Researchers and ISPs should always take care to apply data minimization techniques that limit the disclosure of private information to only the granularity that is necessary to perform the research. Various practices for minimization exist, such as hashing or removing IP addresses, aggregating statistics over longer time windows, and so forth. The network and security research communities should continue developing norms and standard practices for deciding when, how, and to what degree private data from ISPs can be minimized when it is shared.

The FCC, ISPs, customers, and researchers should all care about the security, operation, and performance of the Internet.  Achieving these goals often involves sharing customer data with third-parties, such as the network and security research community. As a member of the research community, I am looking forward to reading the text of the rule, which, if our comments are incorporated, will help preserve both customer privacy and the research that keeps the Internet secure and performing well.