Protecting the Privacy of Customers of Broadband and Other Telecommunications Services

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Part 64

[WC Docket No. 16-106; FCC 16-148]

Protecting the Privacy of Customers of Broadband and Other Telecommunications Services

AGENCY:

Federal Communications Commission.

ACTION:

Final rule.

SUMMARY:

In this document, the Federal Communications Commission (Commission) adopts final rules based on public comments applying the privacy requirements of the Communications Act of 1934, as amended, to broadband Internet access service (BIAS) and other telecommunications services. In adopting these rules the Commission implements the statutory requirement that telecommunications carriers protect the confidentiality of customer proprietary information. The privacy framework in these rules focuses on transparency, choice, and data security, and provides heightened protection for sensitive customer information, consistent with customer expectations. The rules require carriers to provide privacy notices that clearly and accurately inform customers; obtain opt-in or opt-out customer approval to use and share sensitive or non-sensitive customer proprietary information, respectively; take reasonable measures to secure customer proprietary information; provide notification to customers, the Commission, and law enforcement in the event of data breaches that could result in harm; not condition provision of service on the surrender of privacy rights; and provide heightened notice and obtain affirmative consent when offering financial incentives in exchange for the right to use a customer's confidential information. The Commission also revises its current telecommunications privacy rules to harmonize today's privacy rules for all telecommunications carriers, and provides a tailored exemption from these rules for enterprise customers of telecommunications services other than BIAS.

DATES:

Effective January 3, 2017, except for §§ 64.2003, 64.2004, 64.2006, and 64.2011(b) which contain information collection requirements that have not yet been approved by OMB. The Federal Communications Commission will publish a document in the

Federal Register

announcing the effective date of these rules upon approval. Section 64.2005 is effective March 2, 2017.

FOR FURTHER INFORMATION CONTACT:

For further information about this proceeding, please contact Sherwin Siy, FCC Wireline Competition Bureau, Competition Policy Division, Room 5-C225, 445 12th St. SW., Washington, DC 20554, (202) 418-2783,

sherwin.siy@fcc.gov.

For additional information concerning the Paperwork Reduction Act information collection requirements contained in this document, send an email to

PRA@fcc.gov

or contact Nicole Ongele at (202) 418-2991.

SUPPLEMENTARY INFORMATION:

This is a summary of the Commission's Report and Order in WC Docket No. 16-106, FCC 16-148, adopted October 27, 2016 and released November 2, 2016. The full text of this document is available for public inspection during regular business hours in the FCC Reference Information Center, Portals II, 445 12th Street SW., Room CY-A257, Washington DC 20554. It is available on the Commission's Web site at

https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-148A1.pdf.

The Commission will send a copy of this Report and Order in a report to be sent to Congress and the Government Accountability Office pursuant to the Congressional Review Act,

see

5 U.S.C. 801(a)(1)(A).

Synopsis

I. Introduction

1. In this Report and Order (Order), we apply the privacy requirements of the Communications Act of 1934, as amended (the Act) to the most significant communications technology of today—broadband Internet access service (BIAS). Privacy rights are fundamental because they protect important personal interests—freedom from identity theft, financial loss, or other economic harms, as well as concerns that intimate, personal details could become the grist for the mills of public embarrassment or harassment or the basis for opaque, but harmful judgments, including discrimination. In adopting section 222 of the Communications Act, Congress recognized the importance of protecting the privacy of customers using telecommunications networks. Section 222 requires telecommunications carriers to protect the confidentiality of customer proprietary information. By reclassifying BIAS as telecommunications service, we have an obligation to make certain that BIAS providers are protecting their customers' privacy while encouraging the technological and business innovation that help drive the many benefits of our increasingly Internet-based economy.

2. Internet access is a critical tool for consumers—it expands our access to vast amounts of information and countless new services. It allows us to seek jobs and expand our career horizons; find and take advantage of educational opportunities; communicate with our health care providers; engage with our government; create and deepen our ties with family, friends and communities; participate in online commerce; and otherwise receive the benefits of being digital citizens. Broadband providers provide the “on ramp” to the Internet. These providers therefore have access to vast amounts of information about their customers including when we are online, where we are physically located when we are online, how long we stay online, what devices we use to access the Internet, what Web sites we visit, and what applications we use.

3. Without appropriate privacy protections, use or disclosure of information that our broadband providers collect about us would be at odds with our privacy interests. Through this Order, we therefore adopt rules that give broadband customers the tools they need to make informed choices about the use and sharing of their confidential information by their broadband providers, and we adopt clear, flexible, and enforceable data security and data breach notification requirements. We also revise our existing rules to provide harmonized privacy protections for voice and broadband customers—bringing privacy protections for voice telephony and other telecommunications services into the modern framework we adopt today.

4. In response to the Notice of Proposed Rulemaking (

NPRM),

we received more than 275,000 submissions in the record of this proceeding, including comments, reply comments, and

ex parte

communications from consumers; broadband and voice providers and their associations; public interest groups; academics; federal, state, and local governmental entities; and others. We have listened and learned from the record. In adopting final rules, we rely on that record and in particular we look to the privacy and data security work done by the Federal Trade Commission (FTC), as well as our own work adopting and revising rules under section 222. We have also taken into account the concepts that animate the Administration's Consumer Privacy Bill of Rights (CPBR), and existing privacy and data security best practices.

5. The privacy framework we adopt today focuses on transparency, choice,

and data security, and provides heightened protection for sensitive customer information, consistent with customer expectations. In adopting these rules we honor customer's privacy rights and implement the statutory requirement that carriers protect the confidentiality of customer proprietary information. These rules do not prohibit broadband providers from using or sharing customer information, but rather are designed to protect consumer choice while giving broadband providers the flexibility they need to continue to innovate. By bolstering customer confidence in broadband providers' treatment of confidential customer information, we also promote the virtuous cycle of innovation in which new uses of the network lead to increased end-user demand for broadband, which drives network improvements, which in turn lead to further innovative network uses, business growth, and innovation.

II. Executive Summary

6. Today we adopt rules protecting the privacy of broadband customers. We also revise our current rules to harmonize our rules for all telecommunications carriers. In this Order, we first offer some background, explaining the need for these rules, and then discuss the scope of the rules we adopt. In discussing the scope of the rules, we define “telecommunications carriers” that are subject to our rules and the “customers” those rules are designed to protect. We also define the information protected under section 222 as customer proprietary information (customer PI). We include within the definition of customer PI three types of information collected by telecommunications carriers through their provision of broadband or other telecommunications services that are not mutually exclusive: (i) Individually identifiable Customer Proprietary Network Information (CPNI) as defined in section 222(h); (ii) personally identifiable information (PII); and (iii) content of communications. We also adopt and explain our multi-part approach to determining whether data has been properly de-identified and is therefore not subject to the customer choice regime we adopt for customer PI.

7. We next adopt rules protecting consumer privacy using the three foundations of privacy—transparency, choice, and security:

8.

Transparency.

Recognizing the fundamental importance of transparency to enable consumers to make informed purchasing decisions, we require carriers to provide privacy notices that clearly and accurately inform customers about what confidential information the carriers collect, how they use it, under what circumstances they share it, and the categories of entities with which they will share it. We also require that carriers inform their customers about customers' rights to opt in to or opt out (as the case may be) of the use or sharing of their confidential information. We require that carriers present their privacy notice to customers at the point of sale, and that they make their privacy policies persistently available and easily accessible on their Web sites, applications, and the functional equivalents thereof. Finally, consistent with FTC best practices and with the requirements in the CPBR, we require carriers to give their customers advance notice of material changes to their privacy policies.

9.

Choice.

We find that because broadband providers are able to view vast swathes of customer data, customers must be empowered to decide how broadband providers may use and share their data. In this section, we adopt rules that give customers of BIAS and other telecommunications services the tools they need to make choices about the use and sharing of customer PI, and to easily adjust those choices over the course of time. Section 222 addresses the conditions under which carriers may “use, disclose, or permit access to” customer information. For simplicity throughout this document we sometimes use the terms “disclose” or “share” in place of “disclose or permit access to.” In adopting rules governing customer choice, we look to the best practices framework recommended by the FTC in its 2012 Privacy Report as well as the choice framework in the Administration's CPBR and adopt a framework that provides heightened protections for sensitive customer information. For purposes of the sensitivity-based customer choice framework we adopt today, we find that sensitive customer PI includes financial information, health information, Social Security numbers, precise geo-location information, information pertaining to children, content of communications, web browsing history, application usage history, and the functional equivalents of web browsing history or application usage history. With respect to voice services, we also find that call detail information is sensitive information. We also adopt a tiered approach to choice, by reference to consumer expectations and context that recognizes three categories of approval with respect to use of customer PI obtained by virtue of providing the telecommunications service:

•

Opt-in Approval.

We adopt rules requiring carriers to obtain customers' opt-in approval for use and sharing of sensitive customer PI (and for material retroactive changes to carriers' privacy policies). A familiar example of opt-in practices appears when a mobile application asks for permission to use geo-location information.

•

Opt-out Approval.

Balancing important governmental interests in protecting consumer privacy and the potential benefits that may result from the use of non-sensitive customer PI, we adopt rules requiring carriers to obtain customers' opt-out approval for the use and sharing of non-sensitive customer PI.

•

Congressionally-Recognized Exceptions to Customer Approval Requirements.

Consistent with the statute, we adopt rules that always allow broadband providers to use and share customer data in order to provide broadband services (for example to ensure that a communication destined for a particular person reaches that destination), and for certain other purposes.

10.

Data Security and Breach Notification.

At its most fundamental, the duty to protect the confidentiality of customer PI requires telecommunications carriers to protect the customer PI they collect and maintain. We encourage all carriers to consider data minimization strategies and to embrace the principle of privacy by design. To the extent carriers collect and maintain customer PI, we require BIAS providers and other telecommunications carriers to take reasonable measures to secure customer PI. To comply with this requirement, a carrier must adopt security practices appropriately calibrated to the nature and scope of its activities, the sensitivity of the underlying data, the size of the provider, and technical feasibility. We decline to mandate specific activities that carriers must undertake in order to meet the reasonable data security requirement. We do, however, offer guidance on the types of data security practices we recommend providers strongly consider as they seek to comply with our data security requirement, while recognizing that what constitutes “reasonable” data security evolves over time.

11. We also adopt data breach notification requirements. In order to ensure that affected customers and the appropriate federal agencies receive notice of data breaches that could result in harm, we adopt rules requiring BIAS

providers and other telecommunications carriers to notify affected customers, the Commission, and the FBI and Secret Service unless the carrier is able to reasonably determine that a data breach poses no reasonable risk of harm to the affected customers. In the interest of expedient law enforcement response, such notice must be provided to the Commission, the FBI, and Secret Service within seven business days of when a carrier reasonably determines that a breach has occurred if the breach impacts 5,000 or more customers; and must be provided to the applicable federal agencies at least three days before notice to customers. For breaches affecting fewer than 5,000 customers, carriers must notify the Commission without unreasonable delay and no later than thirty (30) calendar days following the carrier's reasonable determination that a breach has occurred. In order to allow carriers more time to determine the specifics of a data breach, carriers must provide notice to affected customers without unreasonable delay, but within no more than 30 days.

12.

Particular Practices that Raise Privacy Concerns.

Next, we find that take-it-or-leave-it offerings of broadband service contingent on surrendering privacy rights are contrary to the requirements of sections 222 and 201 of the Act, and therefore prohibit that practice. We also adopt heightened disclosure and affirmative consent requirements for BIAS providers that offer customers financial incentives, such as lower monthly rates, in exchange for the right to use the customers' confidential information. Because the record contains very little about financial incentive practices of voice providers, this section of the Order is limited to BIAS providers.

13. Next we address several other issues raised in our rulemaking, including dispute resolution; the request for an exemption for enterprise customers of telecommunications services other than BIAS; federal preemption; and the timeline for implementation.

14.

Dispute Resolution.

We reaffirm customers' right to use the Commission's existing dispute resolution procedures and commit to initiating a rulemaking on the use of mandatory arbitration requirements in consumer contracts for broadband and other communications services, acting on a notice of proposed rulemaking in February 2017.

15.

Exemption for Enterprise Customers of Telecommunications Services other than BIAS.

Recognizing that enterprise customers of telecommunications services other than BIAS have different privacy concerns and the capacity to protect their own interests, we find that a carrier that contracts with an enterprise customer for telecommunications services other than BIAS need not comply with the privacy and data security rules we adopt today if the carrier's contract with that customer specifically addresses the issues of transparency, choice, data security, and data breach and provides a mechanism for the customer to communicate with the carrier about privacy and data security concerns. As with the existing, more limited business customer exemption from our existing authentication rules, carriers will continue to be subject to the statutory requirements of section 222 even where this exemption applies.

16.

Preemption.

In this section, we adopt the proposal in the

NPRM

and announce our intent to continue to preempt state privacy laws, including data security and data breach laws,

only

to the extent that they are inconsistent with any rules adopted by the Commission. This limited application of our preemption authority is consistent with our precedent in this area and with our long appreciation for the valuable role the states play in protecting consumer privacy.

17.

Implementation Timeline.

The Order provides a timeline for orderly transition to the new rules with additional time given for small carriers to the extent that they may need to change their practices.

18.

Legal Authority.

Finally, the Order closes by discussing our legal authority to adopt the rules.

III. Establishing Baseline Privacy Protections for Customers of Telecommunications Services

19. In this section, we adopt a set of rules designed to protect the privacy of customers of BIAS and other telecommunications services. The rules we adopt today find broad support in the record, and are consistent with and build on existing regulatory and stakeholder-driven frameworks, including the Commission's prior decisions and existing section 222 rules, other federal privacy laws, state privacy laws, and recognized best practices. The framework for our baseline privacy protections focuses on providing transparency of carriers' privacy practices; ensuring customers have meaningful choice about the use and disclosure of their private information; and requiring carriers to adopt robust data security practices for customer information. In this section, we explain the rules we adopt to protect the privacy of customers of BIAS and other telecommunications services.

A. Background and Need for the Rules

20. The Commission has a long history of protecting customer privacy in the telecommunications sector. Section 705 of the Communications Act, for example, is one of the most fundamental and oldest sector-specific privacy requirements, and protects the privacy of information carried by communications service providers. As early as the 1960s the Commission began to wrestle with the privacy implications of the use of communications networks to provide shared access to computers and the sensitive, personal data they often contained. Throughout the 1980s and 1990s, the Commission imposed limitations on incumbent telephone companies' use and sharing of customer information.

21. Then, in 1996, Congress enacted Section 222 of the Communications Act providing statutory protections to the privacy of the data that all telecommunications carriers collect from their customers. Congress recognized that telecommunications networks have the ability to collect information from consumers who are merely using networks as conduits to move information from one place to another “without change in the form or content” of the communications. Specifically, Congress sought to ensure “(1) the right of consumers to know the specific information that is being collected about them; (2) the right of consumers to have proper notice that such information is being used for other purposes; and (3) the right of consumers to stop the reuse or sale of that information.”

22. Section 222(a) imposes a duty on all telecommunications carriers to protect the confidentiality of their customers' “proprietary information,” or PI. Section 222(c) imposes restrictions on telecommunications carriers' use and sharing of customer proprietary network information (CPNI) without customer approval, subject to certain exceptions including as necessary to provide the telecommunications service (or services necessary to or used in providing that telecommunications service), and as otherwise provided for by law. While we recognize, applaud, and encourage existing and continued marketplace self-regulation and privacy innovations, Congress has made clear that telecommunications carriers' privacy practices must comply with the obligations imposed by section 222. We

therefore reject arguments that we rely entirely on self-regulatory mechanisms.

23. Over the last two decades, the Commission has promulgated, revised, and enforced privacy rules for telecommunications carriers that are focused on implementing the CPNI requirements of Section 222. As practices have changed, the Commission has refined its section 222 rules. For example, after the emergence and growth of an industry made possible by “pretexting”—the practice of improperly accessing and selling details of residential telephone calls—the Commission strengthened its section 222 rules to add customer authentication and data breach notification requirements. The current section 222 rules focus on transparency, choice, data security, and data breach notification.

24. Meanwhile, as consumer use of the Internet exploded, the FTC, using its authority under section 5 of the FTC Act to prohibit “unfair or deceptive acts or practices in or affecting commerce,” has entered into a series of precedent-setting consent orders addressing privacy practices on the Internet, held workshops and conferences, and issued influential reports about privacy. Taken together, the FTC's privacy work has focused on the importance of transparency; honoring consumers' expectations about the use of their personal information and the choices they have made about sharing that information; and the obligation of companies that collect personal information to adopt reasonable data security practices. Because common carriers subject to the Communications Act are exempt from the FTC's section 5 authority, the responsibility falls to this Commission to oversee their privacy practices consistent with the Communications Act.

25. Last year the Administration proposed a Consumer Privacy Bill of Rights. The goal of the CPBR is to “establish baseline protections for individual privacy in the commercial arena and to foster timely, flexible implementations of these protections through enforceable codes of conduct developed by diverse stakeholders.” It recognizes that Americans “cherish privacy as an element of their individual freedom,” and that “[p]reserving individuals' trust and confidence that personal data will be protected appropriately, while supporting flexibility and the free flow of information, will promote continued innovation and economic growth in the networked economy.”

26. Prior to 2015, BIAS was classified as an information service, which excluded such services from the ambit of Title II of the Act, including section 222, and the Commission's CPNI rules. Instead, broadband providers were subject to the FTC's unfair and deceptive acts and practices authority. In the

2015 Open Internet Order,

we reclassified BIAS as a telecommunications service subject to Title II of the Act, an action upheld by the D.C. Circuit in

United States Telecom Ass'n

v.

FCC.

While we granted BIAS forbearance from many Title II provisions, we concluded that application and enforcement of the privacy protections in section 222 to BIAS is in the public interest and necessary for the protection of consumers. However, we questioned whether “the Commission's current rules implementing section 222 necessarily would be well suited to broadband Internet access service,” and forbore from the application of these rules to broadband service, “pending the adoption of rules to govern broadband Internet access service in a separate rulemaking proceeding.”

27. In March 2016, we adopted the

Broadband Privacy NPRM,

which proposed a framework for applying the longstanding privacy requirements of the Act to BIAS. In the

NPRM,

we proposed rules protecting customer privacy using the three foundations of privacy—transparency, choice, and security—and also sought comment on, among other things, whether we should update rules that govern the application of section 222 to traditional telephone service and interconnected VoIP service in order to harmonize them with the results of this proceeding.

28. A number of broadband providers, their associations, as well as some other commenters argue that because broadband providers are part of a larger online eco-system that includes edge providers, they should not be subject to a different set of regulations. These arguments ignore the particular role of network providers and the context of the consumer/BIAS provider relationship, and the sector specific privacy statute that governs the use and sharing of information by providers of telecommunications services. Based on our review of the record, we reaffirm our earlier finding that a broadband provider “sits at a privileged place in the network, the bottleneck between the customer and the rest of the Internet”—a position that we have referred to as a gatekeeper. As such, BIAS providers can collect “an unprecedented breadth” of electronic personal information.

29. We disagree with commenters that argue that BIAS providers' insight into customer online activity is no greater than large edge providers because customers' Internet activity is “fractured” between devices, multiple Wi-Fi hotspots, and different providers at home and at work. As commenters have explained, “customers who hop between ISPs on a daily basis often connect to the same networks routinely,” and as such, over time, “each ISP can see a substantial amount of that user's Internet traffic.”

30. While we recognize that there are other participants in the Internet ecosystem that can also see and collect consumer data, the record is clear that BIAS providers' gatekeeper position allows them to see every packet that a consumer sends and receives over the Internet while on the network, including, absent encryption, its contents. By contrast, edge providers only see a slice of any given consumers Internet traffic. As explained in the record, edge providers' visibility into consumers' web browsing activity is necessarily limited. According to the record, only three companies (Google, Facebook, and Twitter) have third party tracking capabilities across more than 10 percent of the top one million Web sites, and none of those have access to more than approximately 25 percent of Web pages. By “third party tracking capability,” we mean any method by which one party injects a tracking mechanism into a customer's traffic in order to monitor the customer's activity when the customer interacts with other parties. Cookies are a common third party tracker, but there are many other methods. In contrast, a BIAS provider sees 100 percent of a customer's unencrypted Internet traffic.

31. At the same time, users have much more control over tracking by web third parties than over tracking by BIAS providers. A range of browser extensions are largely effective at blocking prominent third parties, “but these tools do nothing to stop data collection on the wire.” Further, Professor Nick Feamster explains that unlike other Internet participants that see Domain Name System (DNS) lookups only to their own domains (

e.g., google.com, facebook.com, netflix.com

), BIAS providers can see DNS lookups every time a customer uses the service to go to a new site.

32. Return Path explains additional unique data to which only BIAS providers have access:

Many BIAS customers are assigned a dynamic (`changing') IP address when they connect to their provider. In these cases, each time a consumer's computer (or router) is rebooted, the ISP dynamically assigns a new IP address to the networking device. While the BIAS provider will have a record of

precisely which user was connected to an IP address at a specific point in time, any third party will not, unless they subpoena the BIAS provider for data.

Furthermore, as Mozilla explains, “[b]ecause these are paid services, [the broadband provider has] the subscriber's name, address, phone number and billing history. The combination gives ISPs a very unique, detailed and comprehensive view of their users that can be used to profile them in ways that are commercially lucrative.”

33. We agree with commenters that point out that encryption can significantly help protect the privacy of consumer content from BIAS providers. However, even with encryption, by virtue of providing BIAS, BIAS providers maintain access to a significant amount of private information about their customers' online activity, including what Web sites a customer has visited, how long and during what hours of the day the customer visited various Web sites, the customer's location, and what mobile device the customer used to access those Web sites. Moreover, research shows that encrypted web traffic can be used to infer the pages within an encrypted site that a customer visits, and that the amount of data transmitted over encrypted connections can also be used to infer the pages a customer visits.

34. The record also indicates that truly pervasive encryption on the Internet is still a long way off, and that many sites still do not encrypt. We observe that several commenters rely on projections that 70 percent of Internet traffic will be encrypted by the end of 2016. However, a significant amount of this encrypted data is video traffic from Netflix, which, according to commenters, accounts for 35 percent of North American Internet traffic. Moreover, “raw packets make for a misleading metric.” As further explained by one commenter “watching the full Ultra HD stream of The

Amazing Spider-Man

could generate more than 40GB of traffic, while retrieving the WebMD page for `pancreatic cancer' generates less than 2MB.” What's more, research shows that approximately 84 percent of health Web sites, 86 percent of shopping Web sites, and 97 percent of news Web sites remain unencrypted. These types of Web sites generate less Internet traffic but contain “much more personalized data.” We encourage continued efforts to encrypt personal information both in transit and at rest. At the same time, our policy must account for the fact that encryption is not yet ubiquitous and, in any event, does not preclude BIAS providers from having unique access to customer data.

35. Thus, the record reflects that BIAS providers are not, in fact, the same as edge providers in all relevant respects. In addition to having access to all unencrypted traffic that passes between the user and edge services while on the network, customers' relationships with their broadband provider is different from those with various edge providers, and their expectations concomitantly differ. For example, customers generally pay a fee for their broadband service, and therefore do not have reason to expect that their broadband service is being subsidized by advertising revenues as they do with other Internet ecosystem participants. In addition, consumers have a choice in deciding each time whether to use—and thus reveal information—to an edge provider, such as a social network or a search engine, whereas that is not an option with respect to their BIAS provider when using the service.

36. While some customers can switch BIAS providers, others do not have the benefit of robust competition, particularly in the fixed broadband market. Moreover, we have previously observed that “[b]roadband providers have the ability to act as gatekeepers even in the absence of `the sort of market concentration that would enable them to impose substantial price increases on end users.' ” Their position is strengthened by the high switching costs customers face when seeking a new service, which could deter customers from changing BIAS providers if they are unsatisfied the providers' privacy policies. Moreover, even if a customer was willing to switch to a new broadband provider, the record shows consumers often have limited options. We note, as stated in the 2016

Broadband Progress Report,

approximately 51 percent of Americans still have only one option for a provider of fixed broadband at speeds of 25 Mbps download/3 Mbps upload. Given all of these factors, we conclude that, contrary to assertions in the record, BIAS providers hold a unique position in the Internet ecosystem, and disagree with commenters that assert that rules to protect the privacy of broadband customers are unnecessary.

37. As discussed above and throughout this Order, our sector-specific privacy rules are necessary to address the distinct characteristics of telecommunications services. The record demonstrates that strong customer privacy protections will encourage broadband usage and, in turn investment. We further find that when consumers are confident that their privacy is protected, they will be more likely to adopt and use broadband services. As aptly explained by Mozilla, “[t]he strength of the Web and its economy rests on a number of core building blocks that make up its foundational DNA. When these building blocks are threatened, the overall health and well-being of the Web are put at risk. Privacy is one of these building blocks.” The privacy framework we adopt today will bolster consumer trust in the broadband ecosystem, which is essential for business growth and innovation.

B. Scope of Privacy Protections Under Section 222

38. In adopting rules to protect the privacy of customers of BIAS and other telecommunications services, we must begin by specifying the entities and information at issue. We look to the language of the statute to determine the appropriate scope of our implementing rules. As discussed above, section 222(a) specifies that telecommunications carriers have a duty to protect the confidentiality of proprietary information of and relating to their customers, while section 222(c) provides direction about protections to be accorded “customer proprietary network information.” We therefore first adopt rules identifying the set of “telecommunications carriers” that are subject to our rules and define the “customers” these rules protect. Next we define “customer proprietary information” and include within that definition “individually identifiable customer proprietary network information,” “personally identifiable information,” and content of communications.

1. The Rules Apply to Telecommunications Carriers and Interconnected VoIP Providers

39. For purposes of the rules we adopt today to implement section 222, we adopt a definition of “telecommunications carrier” that includes all telecommunications carriers providing telecommunications services subject to Title II, including broadband Internet access service (BIAS). We also include interconnected VoIP services, which have been covered since 2007. Although not limited to voice services, our existing rules have been focused on voice services. When we reclassified BIAS as a telecommunications service, we recognized that our existing CPNI rules were not necessarily well suited to the broadband context, and we therefore forbore from applying the existing section 222 rules to BIAS. As part of this

rulemaking we have explored what privacy and data security rules we should adopt for BIAS and whether we can harmonize our rules for voice and BIAS. Throughout this Order we find that it is in the interests of consumers and providers to harmonize our voice and broadband privacy rules. We therefore adopt a single definition of telecommunications carrier for purposes of these rules, and except as otherwise provided, adopt harmonized rules governing the privacy and data security practices of all such telecommunications carriers.

40. Because we adopt a single definition of telecommunications carrier we need not change the definitions of “telecommunications carrier or carrier” currently in our rules implementing section 222. In accordance with these definitions, we continue to consider entities providing interconnected VoIP service to be telecommunications carriers for the purposes of these rules. The Commission has not classified interconnected VoIP service as telecommunications service or information service as those terms are defined in the Act, and we need not and do not make such a determination today. We do amend the definition of telecommunications service to conform to the definition of telecommunications carrier. We also observe that because BIAS is now a telecommunications service, BIAS providers are now telecommunications carriers within the meaning of those rules. To remove any doubt as to the scope of these rules, we define BIAS for purposes of our rules pursuant to section 222 identically to our definition in the

2015 Open Internet Order.

We define “broadband Internet access service provider” or “BIAS provider” to mean a person engaged in the provision of BIAS. As used in the foregoing sentence and in the definition of “customer” below, a “person” includes any individual, group of individuals, corporation, partnership, association, unit of government, or legal entity, however organized. Under the

2015 Open Internet Order'

s definition of BIAS, the term BIAS provider does not include “premises operators—such as coffee shops, bookstores, airlines, private end-user networks (

e.g.,

libraries and universities), and other businesses that acquire broadband Internet access service from a broadband provider to enable patrons to access the Internet from their respective establishments.” Moreover, consistent with the

2015 Open Internet Order,

our rules do not govern information that BIAS providers obtain by virtue of providing other non-telecommunications services, such as edge services that the BIAS provider may offer like email, Web sites, cloud storage services, social media sites, music streaming services, and video streaming services (to name a few).

2. The Rules Protect Customers' Confidential Information

41. Section 222 governs how telecommunications carriers treat the “proprietary” and “proprietary network” information of their “customers.” For purposes of the rules we adopt today implementing section 222, we define “customer” as (1) a current or former subscriber to a telecommunications service; or (2) an applicant for a telecommunications service. We adopt a single definition of customer, because we agree with those commenters that argue that harmonizing the definition of “customer” for both BIAS and other telecommunications services will ease consumer expectations, reduce confusion, and streamline compliance costs for BIAS providers, especially small providers. We also find that voice and BIAS customers face similar issues related to the protection of their private information when they apply for, subscribe to, and terminate their telecommunications services.

42. In adopting this definition of customer, we find that BIAS providers' and other telecommunications carriers' duty to protect customer proprietary information under section 222 begins when a person applies for service and continues after a subscriber terminates his or her service. Our existing rules for voice services apply only to current customers. We are, however, persuaded by commenters that argue that the existing rule's limitation to current subscribers is too narrow. As data storage costs decrease and computing power increases, previous barriers to data analysis based on cost, time, or feasibility are receding. BIAS providers and other telecommunications carriers have the technical ability to retain and use applicant and customer information long after the application process or termination of service. If our rules do not protect applicants, consumers would lack basic privacy protections when they share any confidential information in order to apply for a telecommunications service. Similarly, current customers would be penalized for switching providers given that the “losing” carrier would be free to stop protecting the confidentiality of any private information it retains. These outcomes would run counter to our firm commitment to promote broadband adoption, competition, and innovation. Making this change is consistent with the 2014 Notice of Apparent Liability issued in

TerraCom,

in which we explained that that “the carrier/customer relationship commences when a consumer applies for service.”

43. We disagree with commenters that assert that including prospective and former customers within the definition of customer could unduly burden providers. If carriers want to limit their obligations with respect to applicants and former customers, they can and should adopt data minimization practices and destroy applicants' and former customers' confidential information as soon as practicable, in a manner consistent with any other applicable legal obligations.

44. In addition, for purposes of these rules, we find it appropriate to attribute all activity on a subscription to the subscriber. We recognize that multiple people often use the BIAS or voice services purchased by a single subscriber. For example, residential fixed broadband and voice services often have a single named account holder, but all household members and their guests may use the Internet connection and voice service purchased by that subscriber. Likewise, enterprise customers may have many users on the same account. And, for mobile services, multiple users using separate devices may share one account. However, treating each individual user as a separate customer would be burdensome because the provider does not have a separate relationship with each of those users, outside of the relationship with the subscriber. To minimize burdens on both providers and customers, we find it is reasonable to define “customer” to include users of the subscription (such as household members and their guests), but treat the subscriber as the person with authority to make privacy choices for all of the users of the service. As such, we disagree with commenters who argue that every individual using a BIAS subscription should qualify as a distinct customer with separate privacy controls.

45. We recognize that some BIAS or voice subscriptions identify multiple users. For example, some mobile BIAS providers offer group plans in which each person has their own identified device, user ID, and/or telephone number. If a BIAS or other telecommunications provider is already treating each user as distinct and the subscriber authorizes the other users to control their account settings, we encourage carriers to give these users individualized privacy controls.

3. Scope of Customer Information Covered by These Rules

46. In this section, we define the scope of information covered by the rules implementing section 222. Specifically, we import the statutory definition of customer proprietary network information (CPNI) into our implementing rules, and define customer proprietary information (customer PI) as including individually identifiable CPNI, personally identifiable information (PII), and content of communications. We recognize that these categories are not mutually exclusive, but taken together they identify the types of confidential customer information BIAS providers and other telecommunications carriers may collect or access in connection with their provision of service. Below, we provide additional guidance on the scope of these categories of customer information in the telecommunications context.

a. Customer Proprietary Network Information

47. Consistent with the preexisting voice rules, we adopt the statutory definition of customer proprietary network information (CPNI) for all telecommunications services, including BIAS. Since this is our first opportunity to address this definition's application to BIAS, to offer clarity we provide guidance on the meaning of CPNI as it applies to BIAS. We focus on section 222(h)(1), which defines CPNI as information that relates to the quantity, technical configuration, type, destination, location, and amount of use of a telecommunications service subscribed to by any customer of a telecommunications carrier, and that is made available to the carrier by the customer solely by virtue of the carrier-customer relationship; as well as information contained in the bills pertaining to telephone exchange service or telephone toll service received by a customer of a carrier, but does not include subscriber list information. We agree with commenters that, due to its explicit focus on telephone exchange and telephone toll service, section 222(h)(1)(B) is not relevant to BIAS.

48. We interpret the phrase “made available to the carrier by the customer solely by virtue of the carrier-customer relationship” in section 222(h)(1)(A) to include any information falling within a CPNI category that the BIAS provider collects or accesses in connection with the provision of BIAS. This includes information that may also be available to other entities. We disagree with commenters who propose that the phrase “made available to the carrier by the customer solely by virtue of the carrier-customer relationship” means that

only

information that is

uniquely

available to the BIAS provider may satisfy the definition of CPNI. These commenters contend that if a customer's information is available to a third party, it cannot qualify as CPNI, focusing on the term “solely” in the clause. However, the term “solely” modifies the phrase “by virtue of,”

not

the phrase “made available to the carrier.” We therefore conclude that “solely by virtue of the carrier-customer relationship” means that information constitutes CPNI under section 222(h)(1)(A) if the provider acquires the information as a product of the relationship and not through an independent means. We note, for clarity, that both inbound and outbound traffic are made available to the carrier by the customer solely by virtue of the carrier-customer relationship. The directionality of the traffic is irrelevant as to whether it satisfies the statutory definition of CPNI.

49. We also agree with the Center for Democracy and Technology that the fact that third-parties might gain access to the same data when a consumer uses their services “does not negate the fact that the BIAS provider has gained access to the data only because the customer elected to use the BIAS provider's telecommunications service.” The statute is silent as to whether such information might be available to other parties, which indicates that Congress did not intend for the definition of CPNI to hinge on such information being solely available to the customers' carrier. Indeed, in the voice context, CPNI certainly is available to other parties besides the customer's carrier and section 222 protects that data. For example, when a customer calls someone else, CPNI is also made available to the recipient's carrier and intermediaries facilitating the completion of the call. Furthermore, we find that commenters' narrow definition of CPNI is inconsistent with the privacy-protective purpose of the statute. We agree with some commenters' assertions that when a BIAS provider acquires information wholly apart from the carrier-customer relationship, such as purchasing public records from a third party, that information is not CPNI.

50. However, consistent with the Commission's

2013 CPNI Declaratory Ruling,

we find that information that a BIAS provider causes to be collected or stored on a customer's device, including customer premises equipment (CPE) and mobile stations, also meets the statutory definition of CPNI. The “fact that CPNI is on a device and has not yet been transmitted to the carrier's own servers also does not remove the data from the definition of CPNI, if the collection has been done at the carrier's direction.”

51. BIAS providers also have the ability, by virtue of the customer-carrier relationship, to create and append CPNI to a customer's Internet traffic. For example, if a carrier inserts a unique identifier header (UIDH), that UIDH is CPNI because, as we will discuss in greater detail below, it is information in the application layer header that relates to the technical configuration, type, destination, and amount of use of a telecommunications service.

52. We do not believe it is necessary to categorize all personally identifiable information (PII) as CPNI, as suggested by Public Knowledge. While we agree with Public Knowledge's sentiment that PII is confidential information that deserves protection under the Act, and we agree that some information is both PII and CPNI, we find that the Act categorizes and protects all PII as proprietary information, under section 222(a), as discussed below.

(i) Guidance Regarding Information That Meets the Statutory Definition of CPNI in the Broadband Context

53. In keeping with the Commission's past practice, we decline to set out a comprehensive list of data elements that do or do not satisfy the statutory definition of CPNI in the broadband context. We agree with commenters that “no definition of CPNI should purport or aim to be comprehensive and exhaustive, as technology changes quickly and business models continually seek new ways to monetize and market user data.” In the past, the Commission has enumerated certain data elements that it considers to be voice CPNI—including call detail records (including caller and recipient phone numbers, and the frequency, duration, and timing of calls) and any services purchased by the customer, such as call waiting; these data continue to be voice CPNI going forward. Similarly, we follow past practice and identify a non-exhaustive list of the types of information that we consider to constitute CPNI in the BIAS context. We find that such guidance will help provide direction regarding the scope of providers' obligations and help to increase customers' confidence in the security of their confidential information as technology continues to advance. We find that the following types of information relate to the quantity, technical configuration, type, destination, location, and amount of use of a telecommunications service

subscribed to by any customer of a telecommunications carrier, and as such constitute CPNI when a BIAS provider acquires or accesses them in connection with its provision of service:

• Broadband Service Plans

• Geo-location

• MAC Addresses and Other Device Identifiers

• IP Addresses and Domain Name Information

• Traffic Statistics

• Port Information

• Application Header

• Application Usage

• Application Payload

• Customer Premises Equipment and Device Information

54. We will first give a brief overview of the structure of Internet communications, to help put these terms in context, and then discuss why each of these types of information, and other related components of Internet Protocol packets, qualify as CPNI.

(a) Background—Components of an Internet Protocol Packet

55. The layered architecture of Internet communications informs our analysis of CPNI in the broadband context. While the concept of layering is not unique to the Internet, layering plays a uniquely prominent role for Internet-based communications and devices. For that reason, we begin with a brief technical overview of the layered structure of Internet communications.

56. Multiple layers—often represented as a vertical stack—comprise every Internet communication. Each layer in the stack serves a particular logical function and uses a network protocol that standardizes communication between systems, enabling rapid innovation in Internet-based protocols and applications. Within one device, information is typically transmitted vertically through the various layers. Across all devices, equivalent layers perform the equivalent functions. This compatibility and interoperability is typically represented as horizontal relationships. When an application sends data over the Internet, the process begins with application data moving downwards through the layers. Each layer adds additional networking information and functionality, wrapping the output of the layers above it with a “header.” The communication sent out over the Internet—consisting of the application data wrapped in headers from each layer—is called a “packet.” When a device receives data over the Internet, the reverse process occurs. Data moves upwards through the layers; each layer unwraps its associated information and passes the output upward, until the application on the recipient's device recovers the original application data. As a component of their provision of service, BIAS providers may analyze each of these layers for reasonable network management.

57. Common representations of the Internet's architecture range from four to seven layers. To highlight design properties relevant to the broadband CPNI analysis, we describe a five-layer model in this explanation. From top to bottom, the layers are: Application payload, application header, transport, network, and link. We will briefly describe each of the five layers, from top to bottom:

58.

Application Payload.

The information transmitted to and from each application a customer runs is commonly referred to as the application layer payload. The application payload is the substance of the communication between the customer and the entity with which she is communicating. Examples of application payloads include the body of a Web page, the text of an email or instant message, the video served by a streaming service, the audiovisual stream in a video chat, or the maps served by a turn-by-turn navigation app.

59.

Application Header.

The application will usually append one or more headers to the payload; these headers contain information

about

the application payload that the application is sending or requesting. For example, in web browsing, the Uniform Resource Locator (URL) of a Web page constitutes application header information. In a conversation via email, instant message, or video chat, an application header may disclose the parties to the conversation.

60.

Transport Layer.

Below the application header layer is the transport layer, which forwards data to the intended application on each device and can manage the flow of communications from one device to another device. Two transport protocols are widely deployed on the Internet: the Transmission Control Protocol (TCP), which ensures that data arrives intact, and the User Datagram Protocol (UDP), which provides fewer guarantees about data integrity. Port numbers are an example of data within the transport layer header; a port number specifies which application on a device should handle a network communication.

61.

Network Layer.

The network layer is below the transport layer, and contains information used to route packets across the Internet from one device to another device. Almost all Internet traffic uses the Internet Protocol (IP) at the network layer. IP addresses are the most common example of data at the network layer; an IP address in a network header indicates the sender or recipient of an Internet packet.

62.

Link Layer.

The final layer is the link layer, which is below the network layer. Link layer protocols route data between devices on the same local network. For example, devices on the same wired or wireless network can usually communicate directly with each other at the link layer. MAC addresses are an example of data at the link layer, and a wide range of link technologies (Ethernet, DOCSIS, Wi-Fi, and Bluetooth, among others) use them. A MAC address functions as a globally unique device identifier, ensuring that every device on a local network has a distinct address for sending and receiving data.

(b) Specific Examples of CPNI in the BIAS Context

63. With this understanding of the architecture of Internet communications, we can now examine how the components of an IP data packet map to the statutory definition of CPNI. In this section, we provide guidance on what data elements constitute CPNI; this is distinct from the question of whether a data element constitutes

individually identifiable

CPNI and is thus “customer proprietary information.” Below, we provide guidance addressing how various data elements constitute CPNI under section 222.

64.

Broadband Service Plans.

We find that broadband service plans meet the statutory definition of CPNI in the broadband context because they relate to the quantity, type, amount of use, location, and technical configuration of a telecommunications service. We agree with NTCA that “information related to a customer's broadband service plan can be viewed as analogous to voice telephony service plans,” which the Commission has long considered to be CPNI in the voice context. These plans detail subscription information, including the type of service (

e.g.,

fixed or mobile; cable or fiber; prepaid or term contract), speed, pricing, and capacity (

e.g.,

data caps). These data relate to the “type” of telecommunications service to which the customer subscribes, as well as how the BIAS provider will adjust the “technical configuration” of their network to serve that customer. Information pertaining to subscribed capacity and speed relate to the “quantity” of services the customer purchases, as well as the “amount” of services the customer consumes. Service plans often include the customer's

address (for billing purposes or to identify the address of service), which relates to the location of use of the service.

65.

Geo-location.

Geo-location is information related to the physical or geographical location of a customer or the customer's device(s), regardless of the particular technological method used to obtain this information. Providers often need to know where their customers are so that they can route communications to the proper network endpoints. The Commission has already held that geo-location is CPNI, and Congress emphasized the importance of geo-location data by adding Section 222(f).

66. We disagree with commenters who ask us to draw technology-based distinctions for what types of location information are sufficiently precise to qualify as geo-location CPNI. BIAS providers can use many types of data—either individually or in combination—to locate a customer, including but not limited to GPS, address of service, nearby Wi-Fi networks, nearby cell towers, and radio-frequency beacons. We caution that these and other forms of location information in place now or developed in the future constitute geo-location CPNI when made available to the BIAS provider solely by virtue of the carrier-customer relationship.

67.

Media Access Control (MAC) Addresses and Other Device Identifiers.

We conclude that device identifiers, such as MAC addresses, are CPNI in the broadband context because they relate to the technical configuration and destination of use of a telecommunications service. Link layer protocol headers convey MAC addresses, along with other link layer protocol information. A MAC address uniquely identifies the network interface on a device, and thus uniquely identifies the device itself (including the device manufacturer and often the model). MAC addresses relate to the technical configuration and destination of communications because BIAS providers use them to manage their networks and route data packets to the appropriate network device. We disagree with Sandvine, which argues that link layer information such as MAC addresses do not relate to the technical configuration of network traffic or the destination of packets. For the same reasons, we conclude that other device identifiers and other information in link layer protocol headers are CPNI in the broadband context because they relate to the technical configuration and destination of use of a telecommunications service.

68.

Internet Protocol (IP) Addresses and Domain Name Information.

We conclude that source and destination IP addresses constitute CPNI in the broadband context because they relate to the destination, technical configuration, and/or location of a telecommunications service. An IP address is a routable address for each device on an IP network, and BIAS providers use the end user's and edge provider's IP addresses to route data traffic between them. As such, source and destination IP addresses are roughly analogous to telephone numbers in the voice telephony context. The Commission has previously held telephone numbers dialed to be CPNI. Further, our CPNI rules for TRS providers recognize IP addresses as call data information. By this analogy, we mean only that both are “roughly similar numerical identifiers” used to route telecommunications. We do not intend to imply that IP addresses are or should be administered in the same manner as telephone numbers. This definitional change to our regulations in no way asserts Commission jurisdiction over the assignment or management of IP addressing.

69. We agree with those commenters that argue that the IP addresses a customer uses and those with which she exchanges packets constitute CPNI because both source and destination IP addresses relate to the destination of use of a telecommunications service; one links to the destination for inbound traffic while the other links to the destination for outbound traffic. IP addresses are also frequently used in geo-location. A BIAS provider is uniquely capable of geo-locating an IP address. Most notably, in the case of mobile broadband Internet access service, the provider knows the geo-location of the cell towers to which the customer's device connects and can use this to determine the customer's device location. As Public Knowledge explains, “IP addresses can easily be mapped to geographic locations, meaning that both the subscriber and the service can be located.” IP addresses relate to technical configuration because BIAS providers configure their systems to use IP addresses in the network layer to communicate data packets between senders and receivers.

70. We disagree with commenters who argue that a customer's IP address is not CPNI. Some commenters argue that a customer's IP address is not CPNI because the BIAS provider assigns the IP address to the customer, and thus it is not “made available to the carrier by the customer solely by virtue of the carrier-customer relationship.” This reading of the text undermines the privacy-protective purpose of the statute. First, as the Commission has previously held, information that the provider causes to be generated by a customer's device or appended to a customer's traffic, in order to allow the provider to collect, access, or use that information, can qualify as CPNI if it falls within one of the statutory categories. Second, while the provider generates and assigns the number that will become the customer's IP address, that number is ultimately just a proxy for the customer, translated into a language that Internet Protocol understands. But for the carrier-customer relationship, the customer would not have an IP address. Other commenters argue that IP addresses should not qualify as CPNI because “this information is necessarily sent onto the open Internet in order to make the service work.” However, as discussed above, whether information is available to third parties does not affect whether it meets the statutory definition of CPNI.

71. We also disagree with commenters who assert that dynamic IP addresses do not meet the statutory definition of CPNI. A dynamic IP address is one that the BIAS provider can change. As Return Path explains, “[w]hile the BIAS provider will have a record of precisely which user was connected to [a dynamic] IP address at a specific point in time, any third party will not.” A dynamic IP address may be used for a shorter period of time than a static IP address. We note that these potential privacy benefits of dynamic IP addresses depend upon the specific network configuration and practices of the BIAS provider. For example, a provider may assign a dynamic IP address to a customer for a long period of time, such that it is effectively equivalent to a static IP address. In certain configurations (

e.g.,

IPv6 without privacy extensions), a dynamic IP address can be

more

revealing than a static IP address, because it includes other network identifiers (such as a MAC address). But a dynamic IP address still meets the statutory definition of CPNI because it relates to the technical configuration, type, destination, and/or location of use of a telecommunications service, for the reasons discussed above.

72. We also conclude that information about the domain names visited by a customer constitute CPNI in the broadband context. Domain names (

e.g.,

“fcc.gov”) are common monikers that the customer uses to identify the end point to which they seek to connect. Whether or not the customer uses the

BIAS provider's in-house DNS lookup service is irrelevant to whether domain names satisfy the statutory definition of CPNI. Domain names also translate directly into IP addresses. Because of this easy translation, domain names relate to the destination and technical configuration of a telecommunications service.

73. As discussed above, Internet traffic is communicated through a layered architecture, including a network layer that uses protocol headers containing IP addresses to route communications to the intended devices. Similar to IP addresses, other information in the network layer protocol headers is CPNI in the broadband context. BIAS providers configure their networks to use this information for routing, network management, and security purposes. These headers will also indicate the total size of the packet. As such, other information in the network layer protocol headers relates to the technical configuration and amount of use of a telecommunications service.

74.

Traffic Statistics.

We conclude that traffic statistics meet the statutory definition of CPNI in the broadband context because they relate to the amount of use, destination, and type of a telecommunications service. We use the technology-neutral term “traffic statistics” to encompass any quantification of the communications traffic, including short-term measurements (

e.g.,

packet sizes and spacing) and long-term measurements (

e.g.,

monthly data consumption, average speed, or frequency of contact with particular domains and IP addresses). There are many common forms of traffic statistics, such as IPFIX, and we believe it is important to focus on how BIAS providers use these data, rather than single out particular technologies. We believe that traffic statistics are analogous to call detail information regarding the “duration[] and timing of [phone] calls” and aggregate minutes used in the voice telephony context, both of which are CPNI. BIAS providers use traffic statistics to optimize the efficiency of their networks and protect against cyber threats, but can also use this data to draw inferences that implicate the amount of use, destination, and type of a telecommunications service. For example, BIAS providers can use traffic statistics to determine the amount of use (

e.g.,

date, time, and duration), and to identify patterns such as when the customer is at home, at work, or elsewhere, or reveal other highly personal information. Traffic statistics related to browsing history and other usage can reveal the “destination” of customer communications. Further, a BIAS provider could deduce the “type” of application (

e.g.,

VoIP or web browsing) that a customer is using based on traffic patterns, and thus the purpose of the communication.

75.

Port Information.

We conclude that port information is CPNI in the broadband context because it relates to the destination, type, and technical configuration, of a telecommunications service. A port is a logical endpoint of communication with the sender or receiver's application, and consequently relates to the “destination” of a communication. The transport layer protocol header of a data packet contains the destination port number, which determines which application receives the communication. Port destinations are analogous to telephone extensions in the voice context. Port numbers identify or at least provide a strong indication of the type of application used, and thus the purpose of the communication, such as email, web browsing, or other activities. Though sometimes port numbers may not reveal anything of significance, they often do, and therefore we conclude that they relate to the destination, type, or technical configuration of the service. BIAS providers configure their networks using port information for network management purposes, such as to block certain ports to ensure network security. As such, these practices relate to the “technical configuration” of the telecommunications service. We agree with commenters that other transport layer protocol header information is CPNI in the broadband context because it relates to the technical configuration and amount of use of a telecommunications service. BIAS providers use other header information in this layer to configure their networks and monitor for security threats. For example, because UDP headers indicate packet size, they can reveal the amount of data the customer is consuming, and because TCP headers include sequence numbers, they can reveal information about a customer's device configuration.

76.

Application Header.

We conclude that application header information is CPNI in the broadband context because it relates to the destination, type, technical configuration, and amount of use of a telecommunications service. As discussed above, the top-most layer of network architecture is the application layer; IP data packets contain application headers to instruct the recipient application on how to process the communication. Application headers contain data for application-specific protocols to help request and convey application-specific content. Application headers are analogous in the voice telephony context to a customer's choices within telephone menus used to route calls within an organization (

e.g.,

“Push 1 for sales. Push 2 for billing.”). The application header communicates information between the application on the end user's device and the corresponding application at the other endpoint of the communication. For example, application headers for web browsing typically use the Hypertext Transfer Protocol (HTTP) and contain the Uniform Record Locator (URL), operating system, and web browser; application headers for email typically contain the source and destination email addresses. Application headers may also include information relating to persistent identifiers, use of encryption, and virtual private networks (VPNs). Email headers may also include the subject line. The type of applications used, the URLs requested, and the email destination all convey information intended for use by the edge provider to render its service. Application headers can also reveal information about the amount of data being conveyed in the packet. BIAS providers may configure their networks using application headers for network management or security purposes.

77. Consistent with our decision in the

2013 CPNI Declaratory Ruling,

we agree with commenters that any information that the BIAS provider injects into the application header, such as a unique identifier header (UIDH), is also CPNI in the broadband context. BIAS providers sometimes append information to application headers, in particular HTTP headers, in order to uniquely tag communications with a specific subscriber account. Like other application header information, these data relate to the technical configuration, type, destination, and amount of use of a telecommunications service.

78.

Application Usage.

We conclude that information detailing the customer's use of applications is CPNI in the broadband context because it relates to the type and destination of a telecommunications service. Unlike an application payload, which contains the substance of a communication in an IP packet, application usage information is data that reveals the customer's use of an application more generally. A BIAS provider often collects application usage information through its provision of service. Sometimes application usage information is quantified—similar to traffic statistics—into short-term or long-term measurements. Such

information can reveal the type of applications the customer uses and with whom she communicates. As such, to the extent that the BIAS provider directs the collection or storage of such information, we conclude that it is CPNI. For the reasons discussed above, we disagree with commenters who contend that we should not consider such information to be CPNI because it is also available to other parties.

79.

Application Payload.

We conclude that the application payload, which is the part of the IP packet containing the substance of the communication between the customer and entity with which the customer is communicating, can be considered CPNI. Examples of application payloads include the body of a Web page, the text of an email or instant message, the video shared by a streaming service, the audiovisual stream in a video chat, or the maps served by a ride-sharing app. It is available to the carrier only because of the customer-carrier relationship and can relate to technical configuration, type, destination and amount of the use of the telecommunications service. BIAS providers are technically capable of configuring their networks to scan all parts of the data packet, including the payload, to detect security threats and block malicious packets. BIAS providers also use various network management techniques to minimize network congestion while transmitting application payloads. The application payload can help identify the parties to the communication (

e.g.,

the online streaming video distributor of a streaming video, or the homepage of a news Web site), and thus the communication's destination. The payload's size and substance can also indicate the amount of data the customer is using, the type of communication, and the duration of the use of the service. Another way to think of the application payload is as the “content of the communication.” Because of the importance given to protecting content of communications in our legal system, we also discuss content separately as its own element of customer proprietary information.

80.

Customer Premises Equipment (CPE) and other Customer Device Information.

Information pertaining to customer premises equipment (CPE) and other customer device information, such as that relating to mobile stations, is CPNI in the broadband context because it relates to the technical configuration, type, and destination of a telecommunications service. The Act defines CPE as “equipment employed on the premises of a person (other than a carrier) to originate, route, or terminate telecommunications.” The Commission has long-understood CPE to include customers' mobile devices, such as cell phones. Given this precedent, we believe that other consumer devices capable of being connected to broadband services, such as smartphones and tablets, also fall under the rubric of CPE, along with more traditional CPE such as a customer's computer, modem, router, videophone, or IP caption phone. However, we also observe that such devices would be considered “mobile stations,” which the Act defines as “a radio-communication station capable of being moved and which ordinarily does move.” We disagree with commenters that argue that only devices furnished by the BIAS provider can qualify as CPE; there is no such limitation in the statutory language.

81. We find that the traits of CPE and other customer devices (

e.g.,

model, operating system, software, and/or settings) a customer uses relates to the technical configuration and communications protocols the BIAS provider uses to interface that device with its network, as well as the type of service to which the customer subscribes (

e.g.,

fixed or mobile, cable or fiber). CPE and mobile station information relates to the destination of the use of BIAS because it can identify the endpoint for inbound communications.

82. We disagree with commenters who argue that we should not consider CPE and by extension other customer device information to be CPNI because CPE and other customer devices are also used for purposes other than BIAS, or because such information may be available to other parties. As discussed above, what matters is the nature of the information made available to the BIAS provider through its provision of service.

83. We disagree with NTCA, which misinterprets the Bureau-level

1998 CPNI Clarification Order

to argue that the Commission has previously found that CPE is not covered by section 222. In the

1998 CPNI Clarification Order,

the Bureau addressed the issue of “customer information independently derived from the carrier's prior sale of CPE to the customer or the customer's subscription to a particular information service offered by the carrier in its marketing of new CPE[.]” By contrast, here we are addressing information about the CPE itself that is made available to the carrier by the customer solely by virtue of the carrier-customer relationship,

i.e.,

information derived in the course of providing BIAS or another telecommunications service.

84.

Other Types of CPNI.

We reiterate that the examples of CPNI discussed above are illustrative, not exhaustive. To the extent that other types of information satisfy the statutory definition of CPNI, those data may also be CPNI, either in the BIAS context or in the context of other telecommunications services.

b. Customer Proprietary Information (Customer PI)

85. Section 222(a) imposes a general duty on all telecommunications carriers “to protect the confidentiality of proprietary information of, and relating to, . . . customers.” “[P]roprietary information of, and relating to, . . . customers” is information that BIAS providers and other telecommunications carriers acquire in connection with their provision of service, which customers have an interest in protecting from disclosure. We call this information “customer proprietary information” or “customer PI.” Customer PI consists of three non-mutually-exclusive categories: (1) Individually identifiable customer proprietary network information (CPNI), (2) personally identifiable information (PII), and (3) content of communications. This interpretation of section 222(a) is consistent with other provisions of the Communications Act that use the term “proprietary information,” and with the Commission's use of that term before enactment of Section 222. As we discuss in more detail below, protecting PII and content is at the heart of most privacy regimes and we recognized in

TerraCom

that the Communications Act protects them as customer PI because it “clearly encompasses private information that customers have an interest in protecting from public exposure.”

86. As we previously explained, “[i]n the context of section 222, it is clear that Congress used the term `proprietary information' broadly to encompass all types of information that should not be exposed widely to the public, whether because that information is sensitive for economic reasons or for reasons of personal privacy. We reaffirm our conclusion that `proprietary information' in section 222(a), as applied to customers . . . clearly encompass[es] private information that customers have an interest in protecting from public exposure.” As such, we disagree with commenters that argue that the word “proprietary” in section 222(a) means the statute only protects information the customer keeps secret from any other party. If only secret information qualified as private information, then not even Social Security numbers would be

“proprietary” and subject to the protections of section 222 and our implementing rules. People regularly give their Social Security numbers to banks, doctors, utility companies, telecommunications carriers, employers, schools, and other parties in order to obtain various services—but this does not mean the information is not “proprietary” to them. To define “proprietary” as these commenters propose would render section 222(a) at worst meaningless and at best leaving a gap whereby sensitive proprietary information like a Social Security number would be unprotected.

87. We disagree with commenters that assert that defining the category of customer PI in this way would dramatically expand the scope of providers' duties to protect private customer information. Based on the record before us, we find that BIAS providers—like other telecommunications carriers—are already on notice that they have a duty to keep such information secure and confidential based on, among other things, FTC guidance that applied to them prior to the reclassification of broadband in the

2015 Open Internet Order.

According to FTC staff, “[t]o date, the FTC has brought over 500 cases protecting the privacy and security of consumer information.” We have held providers responsible for protecting these private data under section 222(a). In

TerraCom,

we also found that the failure to protect customer's private information was an unjust and unreasonable practice under section 201(b). Likewise, providers have been required to protect the content of communications for decades. Moreover, customers reasonably expect and want their providers to keep these data secure and confidential. Surveys reflect that 74 percent of Americans believe it is “very important” to be in control over their own information; as a Pew study found, “[i]f the traditional American view of privacy is the `right to be left alone,' the 21st-century refinement of that idea is the right to control their identity and information.” We agree with the Center for Democracy & Technology that “[e]xcluding PII from the proposed rules would be contrary to decades of U.S. privacy regulation and public policy.” We also observe that omitting PII from the scope of these rules would result in a gap in protection for PII under the Act's primary privacy regime for telecommunications services. Thus, were PII not included within the scope of customer PI, sensitive PII like Social Security numbers or private medical records would receive fewer protections than a broadband plan's monthly data allowance, a result we do not think intended by Congress. We discuss and define PII below.

c. Personally Identifiable Information (PII)

88. Protecting personally identifiable information is at the heart of most privacy regimes. Historically, legal definitions of PII have varied. Some incorporated checklists of specific types of information; others deferred to auditing controls. Privacy protections must evolve and improve as technology—and our understanding of its potential—evolves and improves. Our definition incorporates this modern understanding of data privacy and tracks the FTC, the Administration's proposed CPBR, and National Institute of Standards and Technology (NIST) guidelines on PII.

89. We define personally identifiable information, or PII, as any information that is linked or reasonably linkable to an individual or device. Information is linked or reasonably linkable to an individual or device if it can reasonably be used on its own, in context, or in combination to identify an individual or device, or to logically associate with other information about a specific individual or device. The “linked or reasonably linkable” standard for determining the metes and bounds of personally identifiable information is well established and finds strong support in the record. In addition to NIST, CPBR, and the FTC, the Department of Education, the Securities and Exchange Commission, the Department of Defense, the Department of Homeland Security, the Department of Health and Human Services, and the Office of Management and Budget all use a version of this standard in their regulations and policies.

90. We agree with the FTC staff that “[w]hile almost any piece of data

could

be linked to a consumer, it is appropriate to consider whether such a link is practical or likely in light of current technology.” While we recognize that “ `[i]dentifiable' information is increasingly contextual”—especially when a provider can cross-reference multiple types and sources of information—anchoring the standard to a mere “possibility of logical association” could result in “an overly-expansive definition.” Thus, we adopt the recommendation of the FTC staff and others to add the term “reasonably” to our proposed “linked or linkable” definition of PII. This conclusion has broad support in the record.

91. We also adopt the FTC staff recommendation that PII should include information that is linked or reasonably linkable to a customer device. As discussed above, devices in the BIAS context include a customer's smartphone, tablet, computer, modem, router, videophone, IP caption phone, and other consumer devices capable of connecting to broadband services. We agree with the FTC staff that “[a]s consumer devices become more personal and associated with individual users, the distinction between a device and its user continues to blur.” The Digital Advertising Alliance likewise recognizes the connection between individuals and devices, stating in its guidance that information “connected to or associated with a particular computer or device” is identifiable. While some commenters argue that we should not include information linkable to a device in the definition of PII, we find that such identifiers are often and easily linkable to an individual, as we discussed above.

92. We disagree with commenters that argue that PII should only include information that is sensitive or capable of causing harm if disclosed. The ability of information to identify an individual defines the scope of PII. Whether or not any particular PII is sensitive or capable of causing harm if disclosed is a separate question from the definitional question of identifiability. We address the treatment of sensitive versus non-sensitive information below.

93. We agree with commenters that we should offer illustrative, non-exhaustive examples of PII. We have analyzed descriptions of PII in the record, our prior orders, NIST, the FTC, the Administration's proposed CPBR, and other federal and state statutes and regulations. We find that examples of PII include, but are not limited to: Name; Social Security number; date of birth; mother's maiden name; government-issued identifiers (

e.g.,

driver's license number); physical address; email address or other online contact information; phone numbers; MAC addresses or other unique device identifiers; IP addresses; and persistent online or unique advertising identifiers. Several of these data elements may also be CPNI. OTI asks us to clarify the meaning of “other online contact information.” The term is meant to be technology neutral and encompass other methods of BIAS-enabled direct messaging.

94. We disagree with commenters that argue that we should not consider MAC addresses, IP addresses, or device identifiers to be PII. First, as discussed above, a customer's IP address and MAC

address each identify a discrete customer and/or customer device by routing communications to a specific endpoint linked to the customer. Information does not need to reveal an individual's name to be linked or reasonably linkable to that person. A unique number designating a discrete individual—such as a Social Security number or persistent identifier—is at least as specific as a name. In many cases, a unique numerical identifier will be

more

specific than the person's actual name. Second, MAC addresses, IP addresses, and other examples of PII do not need to be able to identify an individual in a vacuum to be linked or reasonably linkable. BIAS providers can combine this information with other information to identify an individual (

e.g.,

the BIAS provider's records of which IP addresses were assigned to which customers, or traffic statistics linking MAC addresses with other data). In situations where the BIAS provider sold or leased a device to a customer—such as a smartphone, modem, or router—the provider could associate device identifiers with the customer from its records. As the Supreme Court has observed, “[w]hat may seem trivial to the uninformed, may appear of great moment to one who has a broad view of the scene and may put the questioned item of information in its proper context.”

95.

Customer Contact Information—Names, Addresses, and Phone Numbers of Individuals.

Names, addresses, telephone numbers, and other information that is used to contact an individual are classic PII because they are linked or reasonably linkable to an individual or device. Some commenters argue that contact information is not protected under section 222 because “Subscriber list information” is exempt from the choice requirements for CPNI under section 222(e). However, subscriber list information, a relatively small subset of customer contact information, was subject to other considerations at the time of enactment.

96. Subscriber list information is defined in the statute as “any information (A) identifying the listed names of subscribers of a carrier and such subscribers' telephone numbers, addresses, or primary advertising classifications (as such classifications are assigned at the time of the establishment of such service), or any combination of such listed names, numbers, addresses, or classifications; and (B) that the carrier or an affiliate has published, caused to be published, or accepted for publication in any directory format.” Through this definition, Congress recognized that a dispositive factor is whether the information has been published or accepted for publication in a directory format.

97. The legislative history shows that Congress created a narrow carve out from the definition of CPNI for subscriber list information in order to protect the longstanding practice of publishing telephone books and to promote competition in telephone book publishing. The legislative history is clear that Congress did not intend for subscriber list information “to include any information identifying subscribers that is prepared or distributed within a company or between affiliates or that is provided to any person in a non-public manner.” Instead, Congress intended subscriber list information to be “data that local exchange carriers traditionally and routinely make public. Subscribers have little expectation of privacy in this information because, by agreeing to be listed, they have declined the opportunity to limit its disclosure.” Based on this legislative history, we find that the phrase “published, caused to be published, or accepted for publication in any directory format” is best read as limited to publicly available telephone books of the type that were published when Congress enacted the statute, or their direct equivalent in another medium, such as a Web site republishing the contents of a publicly available telephone book.

98. Unlike landline voice carriers, neither mobile voice carriers nor broadband providers publish publicly-available directories of customer information. Nor does the record reflect more than speculation about any future interest in publishing directories. Because publishing of broadband customer directories is neither a common nor a long-standing practice, we find that broadband customers have no expectation that that they are consenting to the public release of their name, postal address, or telephone number when they subscribe to BIAS. We therefore conclude that a directory of BIAS customers' names, addresses, and phone numbers would not constitute information published in a “directory format” within the meaning of the statute, and therefore there is no “subscriber list information” in the broadband context. As such, we disagree with commenters who ask us to ignore the publication requirement in order to exempt names, addresses, telephone numbers, and IP addresses from these rules.

99. We recognize that the Commission has previously found that names, addresses, and telephone numbers are not CPNI, even when not published as subscriber list information. However, the Commission has not analyzed whether such customer contact information is PII, and therefore subject to protections under section 222(a). As discussed above, we make clear today that it is PII. As PII, this information is subject to our customer choice rules, discussed in detail below. Our customer choice rules will continue to allow this information to be used to publish publicly available telephone directories, consistent with the current practice of allowing customers to keep their information unlisted.

100.

Harmonization.

We agree with the American Cable Association and various small providers who urge us to harmonize our BIAS and voice definitions under Section 222. Having one uniform set of definitions will simplify compliance and reduce consumer confusion. This is especially true for small providers who collect less customer information, use it for narrower purposes, and do not have the resources to maintain a bifurcated system. Consequently, we extend this definition of PII to all section 222 contexts.

d. Content of Communications

101. We find that the Act protects the content of communications as customer PI. Content is a quintessential example of a type of “information that should not be exposed widely to the public . . . [and] that customers expect their carriers to keep private.” Content is highly individualistic, private, and sensitive. Except in limited circumstances where savvy customers deploy protective tools, BIAS providers often have access to at least some, if not most, content through their provision of service. BIAS providers' inability to access encrypted content is irrelevant; what matters is the information the BIAS providers

can

access. Moreover, even when traffic is encrypted, some content may remain visible or inferable to the provider. We agree with FTC staff that “[c]ontent data can be highly personalized and granular, allowing analyses that would not be possible with less rich data sets.” In recognition of its importance, Congress has repeatedly and emphatically protected the privacy of communications content in various legal contexts, expressly prohibiting service providers from disclosing the contents of communications they carry, subject to statutorily enumerated exceptions, since at least 1912. We agree with commenters that “Americans do not expect their broadband providers to be reading their electronic communications any more than they expect them to be

keeping a list of their correspondents.” The same rationale that supports the treatment of the content of BIAS communications as customer PI supports the treatment of the content carried through other telecommunications services as customer PI.

102.

Definition of Content.

At the outset, we define content as any part of the substance, purport, or meaning of a communication or any other part of a communication that is highly suggestive of the substance, purpose, or meaning of a communication. We sought comment on how to define content in the

NPRM,

but received no substantive recommendations; consequently we base our definition on the long-established terminology of ECPA and Section 705. We recognize that sophisticated monitoring techniques have blurred the line between content and metadata, with metadata increasingly being used to make valuable determinations about users previously only possible with content. This has complicated traditional notions of how to define and treat content. We intend our definition to be flexible enough to encompass any element of the BIAS communication that conveys or implies any part of its substance, purport, or meaning. As a definitional matter, content in an inbound communication is no different from content in an outbound communication. As discussed above, because the categories of customer PI are not mutually exclusive, some content may also satisfy the definitions of CPNI and/or PII. Because we conclude that section 222(a) protects content as its own category of customer PI, we need not determine which types of content are also CPNI or PII.

103. Multiple components of an IP data packet may constitute or contain BIAS content. First and foremost, we agree with commenters that the application payload is always content. As discussed above, the application payload is the part of the IP packet containing the substance of the communication between the customer and the entity with which she is communicating. Examples of application payloads include the body of a Web page, the text of an email or instant message, the video served by a streaming service, the audiovisual stream in a video chat, or the maps served by a ride-sharing app. BIAS providers' use of application payloads for network management is also one reason why BIAS content is not wholly equivalent to telephone conversations. Voice carriers do not scan a phone conversation to secure the network or reduce congestion. Application payloads in the broadband Internet context are far more sophisticated and complex than mere audio transmissions over a telephone line. However, other portions of the packet also may contain content. For example, as discussed above, the application header may reveal aspects of the application payload from which the content may be easily inferred—such as source and destination email addresses or Web site URLs. Application usage information may also reveal content by disclosing the applications customers use or the substance of how they use them. We agree with FTC Staff that BIAS content includes, but is not limited to, the “contents of emails; communications on social media; search terms; Web site comments; items in shopping carts; inputs on web-based forms; and consumers' documents, photos, videos, books read, [and] movies watched[.]” We emphasize that our examples of BIAS content are not exhaustive and others may manifest over time as analytical techniques improve.

104. We reject arguments that protecting BIAS content under section 222 is unnecessary or unlawful because section 705 of the Act, and the Electronic Communications Privacy Act (ECPA) or the Communications Assistance for Law Enforcement Act (CALEA), already protect content. Commenters do not claim that these various other laws are mutually exclusive with each other, belying the notion that the existence of multiple sources of authority in this area is inherently a problem. Instead, we find that section 222 complements these other laws in establishing a framework for protecting the content carried by telecommunications carriers. Given the importance of protecting content, it is reasonable to interpret section 222 as creating additional, complementary protection. Similarly, for example, both the Children's Online Privacy Protection Act and the Video Privacy Protection Act may protect videos that young children watch online.

105. We also disagree with the argument that because the data protected by section 705 “bear scant resemblance” to content or other forms of customer PI, our interpretation of section 222 is erroneous. Congress can enact two statutory provisions that contain different scopes, and it is a cardinal principle of statutory construction that we should attempt to give meaning to both. Any incongruity between the scope of sections 222 and 705 only demonstrates that the statutes are complementary and part of Congress's broad scheme to protect customer privacy. Sections 222 and 705 independently require telecommunications carriers to protect communications content.

4. De-Identified Data

106. In this section we describe a corollary regarding the circumstances in which information that constituted customer PI (

i.e.,

PII, content, or individually identifiable CPNI) can comfortably be said to have been de-identified. As discussed below, based on the record we are concerned that carriers not be allowed to skirt the protections of our rules by making unsupported assertions that customer PI has been “de-identified” and thus is not subject to our consent regime, when in fact the information remains reasonably linkable to an individual or device. As 38 public interest organizations pointed out in a joint letter, “[i]t is often trivial to re-identify data that has supposedly been de-identified.” We accordingly adopt a strong, multi-part approach regarding the circumstances under which carriers can properly consider data to be de-identified, using the three part test for de-identification articulated by the FTC in 2012. The Administration's CPBR also uses this standard. Specifically, we find that customer proprietary information is de-identified if the carrier (1) determines that the information is not reasonably linkable to an individual or device; (2) publicly commits to maintain and use the data in a non-individually identifiable fashion and to not attempt to re-identify the data; and (3) contractually prohibits any entity to which it discloses or permits access to the de-identified data from attempting to re-identify the data. As discussed in greater detail below, this third part of the test applies to entities with which the provider contracts to share de-identified customer information. It does not apply to the general disclosure or publication of highly aggregated summary statistics that cannot be disaggregated—for example, the use of statistics in advertisements (

e.g.,

“We offer great coverage in rural areas, because that is where 70% of our customers live.”) We apply these requirements to both BIAS and other telecommunications services. The record does not demonstrate a need to treat de-identified information differently in the voice context versus the BIAS context. We agree with the Greenlining Institute and other commenters that a uniform regime, “is easier for the carriers, easier [for] enforcement, and easier for customers to understand[.]”

a. Adoption of the FTC's Multi-Part Test

107. The record reflects that advances in technology and data analytics make it increasingly difficult to de-identify information such that it is not re-identifiable. The Administration's 2014 Big Data Report observed that “[m]any technologists are of the view that de-identification of data as a means of protecting individual privacy is, at best, a limited proposition.” As the Electronic Privacy Information Center notes, “[w]idely-publicized anonymization failures have shown that even relatively sophisticated techniques have still permitted researchers to identify particular individuals in large data sets.” We also agree with the FTC's conclusion in its 2012 Privacy Report that “not only is it possible to re-identify non-PII data through various means, businesses have strong incentives to actually do so.”

108. For these reasons, our approach to de-identification establishes a strong, technology-neutral standard as well as safeguards to mitigate the incentives to re-identify customers' proprietary information. Furthermore, because companies, including BIAS providers, have incentives to re-identify customer information so that it can be further monetized, we agree with Privacy Rights Clearinghouse that the burden of proving that individual customer identities and characteristics have been removed from the data must rest with the provider. Taking this burden assignment into account, we find that our multi-part approach, grounded in FTC guidance, will ensure that as technology changes, customer information is protected, while at the same time minimizing burdens and maintaining the utility of de-identified customer information.

109. As such, we disagree with those commenters who urge us to use a different de-identification framework, such as that used in the HIPAA safe harbor context. We find that the framework we adopt enables flexibility to accommodate evolving technology and statistical methods. In contrast, we find that developing a list of identifiers that must be removed from data to render such data de-identified is not feasible given the breadth of data to which BIAS providers have access, and would also rapidly become obsolete in the evolving broadband context.

110. The three-part test we adopt today for de-identification also contemplates the statutory exception for “aggregate customer information,” as it defines the circumstances in which the Commission will find that “individual customer identities and characteristics have been removed” from collective data. Likewise, our approach addresses arguments in the record that the Commission must give meaning to the fact that the customer approval requirement of section 222(c)(1) applies to “individually identifiable” CPNI, as our test for de-identification addresses whether an individual's CPNI or PII will not be deemed to be individually identifiable in practice due to steps taken by the carrier prior to using or sharing the data.

(i) Part One—Not Reasonably Linkable

111. First, for information to be de-identified under our rules, we require providers to determine that the information is not linked or reasonably linkable to an individual or device. Because we are describing the scope of what is identifiable, we think it is appropriate to use the same standard that we use to define personally identifiable information (PII). Above we define PII as information that is linked or reasonably linkable to an individual or device, and conversely we find it appropriate to limit de-identified information to information that is

not

linked or reasonably linkable to an individual or device. As we discussed above in our definition of PII, we agree with commenters that the “linked or reasonably linkable” standard—used by the FTC in its Privacy Report—provides useful guidance on what it means for information to be individually identifiable without being either overly rigid or vague. As we discussed above, information is linked or reasonably linkable to an individual or device if it can reasonably be used on its own, in context, or in combination (1) to identify an individual or device, or (2) to logically associate with other information about a specific individual or device. New methods are increasingly capable of re-identifying information previously thought to be sufficiently anonymized. For these reasons, we will not specify an exhaustive list of identifiers, nor will we declare certain techniques to be

per se

sufficient or insufficient to achieve de-identification. The test instead focuses on the outcome required, that is, that to be de-identified, the data must no longer be linked or reasonably linkable to an individual or device. We also agree with AT&T that we should not “dictate specific approaches to de-identifying data” because “[a]ny Commission-mandated approach would quickly become obsolete as new de-identification techniques are developed.”

112. We make clear that reasonableness depends on ease of

re

-identification, not the cost of

de

-identification. As discussed above, customers' privacy interests include many noncommercial values, such as avoidance of embarrassment, concern for one's reputation, and control over the context of disclosure of one's information. The decisive question here is not how difficult it is to de-identify the information, but rather the ease with which the information could be re-identified. The FTC's linkability standard aligns with our approach: “[W]hat qualifies as a reasonable level of [de-identification] depends upon the particular circumstances, including the available methods and technologies. In addition, the nature of the data at issue and the purposes for which it will be used are also relevant.”

113. Consistent with the FTC's guidance and the carrier's burden to prove that information is in fact de-identified, if carriers choose to maintain customer PI in both identifiable and de-identified formats, they must silo the data so that one dataset is not reasonably linkable to the other. Cross-referencing the datasets links the de-identified information with an identified customer, thus rendering the de-identified information linked or reasonably linkable. We agree with Verizon that “providers should not be allowed to use de-identification and re-identification to circumvent consumers' privacy choices.”

114. We disagree with commenters who argue that the linkability standard should apply only to individuals and should not extend to devices. As explained above, we agree with the FTC staff that “[a]s consumer devices become more personal and associated with individual users, the distinction between a device and its user continues to blur.” This is not an uncommon conclusion in the Internet ecosystem; the Digital Advertising Alliance also recognizes the connection between individuals and devices in its definition of de-identification, stating that “[d]ata has been De-Identified when . . . the data cannot reasonably . . . be connected to or associated with a particular computer or device.”

115. Similarly, for the reasons discussed above, we disagree with commenters who argue that IP addresses and MAC addresses should not be considered reasonably linkable to an individual or device on the theory that “[t]hey only identify Internet endpoints, each of which, in turn, may reach multiple people or devices.” The question in this test is whether the information in question is reasonably linkable to an individual or device. Consider, for example, a typical fixed residential customer. The BIAS provider

assigns that customer an IP address, and associates that customer with that IP address in its records. It is difficult to portray that scenario as not involving PII. On the other hand, if the BIAS provider shares the IP address with a third party without other identifying information, it may well be the case that the provider has not shared information that is “reasonably linkable” to an individual or device. Again, when confronted with the question, the Commission will look at all facts available and make a pragmatic determination of whether the information in question is “reasonably linkable” to an individual or device. NCTA expresses concern that finding that IP addresses can constitute PII will undermine judicial precedent under the Video Privacy Protection Act. As noted, we are not making categorical findings, but rather are looking to the “reasonably linkable” standard in finding whether information constitutes PII. We also observe that we are confronted with interpreting section 222 of the Communications Act and its requirements concerning the protection of “proprietary information of, and relating to, . . . customers.” This is distinct from the language of the VPPA, which more specifically defines PII as “information which identifies a person as having requested or obtained specific video materials or services from a video tape service provider.” Accordingly, a Commission finding that certain information is or is not PII for purposes of section 222 of the Communications Act does not answer the question of whether or not a court should consider that information to be PII under the VPPA or any other statutory provision.

(ii) Part Two—Public Commitments

116. Second, for information to meet our definition of de-identified, carriers must publicly commit to maintain and use de-identified information in a de-identified fashion and to not attempt to re-identify the data. Such public commitments inform customers of their legal rights and the provider's practices, and “promot[e] accountability.” As we discussed above, this level of transparency is a cornerstone of privacy best practices generally and these rules specifically. As such, we disagree with commenters who argue that such public commitments are unnecessary. This part of the test is consistent with FTC guidance—which has broad support in the record—and the CPBR. We agree that “[c]ompanies that can demonstrate that they live up to their privacy commitments have powerful means of maintaining and strengthening consumer trust.” Further, we find that this requirement will impose a minimal burden on providers, as a carrier can satisfy this requirement with a statement in its privacy policy.

(iii) Part Three—Contractual Limits on Other Entities

117. Third, for information to meet our definition of de-identified, we require telecommunications carriers to contractually prohibit recipients of de-identified information from attempting to re-identify it. This requirement is consistent with the FTC's de-identification guidelines and the Administration's CPBR, as well as industry best practices. The DAA guidance also requires that these commitments from recipients of the data be passed along to any further downstream recipients as well, which we support.

118. Businesses are often in the best position to control each other's practices. For example, AT&T's Privacy FAQ explains, “When we provide individual anonymous information to businesses, we require that they only use it to compile aggregate reports, and for no other purpose. We also require businesses to agree they will not attempt to identify any person using this information . . . .” The record demonstrates that such contractual prohibitions are an important part of protecting consumer privacy because re-identification science is rapidly evolving. We agree with Verizon and other commenters that “anyone with whom the provider shares such de-identified data should be prohibited from trying to re-identify it.” It is our expectation that carriers will need to monitor their contracts to maintain the carriers' continued adherence to these requirements. Consequently, we need not adopt a separate part of the test to delineate monitoring requirements. Further, we observe that third parties will have every incentive to comply with their contractual obligations to avoid both civil liability and enforcement actions by the FTC or the Commission (depending on the agency with authority over the third party). If violations occur, we expect carriers to take steps to protect the confidentiality of customer's proprietary information.

119. We agree with commenters who recommend a narrow clarification to the third part of the de-identification framework in situations involving disclosure of highly abstract statistical information. These situations include, for example, mass market advertisements or annual reports that reference the total number of subscribers or the percentage of customers at certain speed thresholds. AT&T explains that these scenarios can involve customer information that is so “highly abstract[ed]” that it is, “in many circumstances, simply impossible” to re-identify the data. Professor Narayanan concurs, noting that when statistical data is highly abstract, there is minimal risk of re-identification. We agree. Consequently, we will not require contractual commitments when the de-identified customer information is so highly abstracted that a reasonable data science expert would not consider it possible to re-identify it.

120. A number of commenters also ask for a narrow exception to this part of the de-identification test for the purposes of various types of cybersecurity or de-identification research. As explained below, we find that certain uses and disclosures of customer PI for the purpose of conducting research to improve and protect networks and/or services are part of the telecommunications service or “necessary to, or used in” the provision of the telecommunications service for the purposes of these rules. Since telecommunications carriers must be able to provide secure networks to their customers, we include security research within the scope of research allowed under this limitation. Security research also falls under the exception covered in Part III.D.2.b,

infra,

regarding uses of customer PI to protect the rights and property of a carrier, or to protect users from fraud, abuse, or unlawful use of the networks.

(iv) Case-by-Case Application

121. In adopting a technology-neutral standard to determine whether otherwise personally identifiable customer PI has been de-identified, we have eschewed an approach that finds particular techniques to be

per se

acceptable or unacceptable. We accordingly need not resolve the longstanding debate in the broader privacy literature concerning the circumstances under which data may be said to be reasonably de-identified, including the specific debate in the record concerning the appropriate role of aggregation. That said, by adopting the three-part test, we have made clear that a carrier cannot “make an end-run around privacy rules simply by removing certain identifiers from data, while leaving vast swaths of customer details largely intact.” As Professor Ohm has stated, the FTC guidance on which we pattern our standard is “a very aggressive and appropriately strong form of de-identification” and it is one that requires strong technological protections as well as business processes in its implementation. The

Commission will carefully monitor carriers' practices in this area. We emphasize that carriers relying on de-identification for use and sharing of customer proprietary information should employ well-accepted, technological best practices in order to meet the three-part test described above—and employ practices that keep pace with evolving technology and privacy science.

C. Providing Meaningful Notice of Privacy Policies

122. In this section, we adopt privacy policy notice requirements for providers of broadband Internet access services and other telecommunications services. There is broad recognition of the importance of transparency as one of the core fair information practice principles (FIPPs), and it is an essential component of many privacy laws and regulations, including the Satellite and Cable Privacy Acts. Customer notification is also among the least intrusive and most effective measures at our disposal for giving consumers tools to make informed privacy decisions. In fact, it is only possible for customers to give informed consent to the use of their confidential information if telecommunications carriers give their customers easy access to clear and conspicuous, comprehensible, and not misleading information about what customer data the carriers collect; how they use it; who it is shared with and for what purposes; and how customers can exercise their privacy choices. Therefore, we adopt rules to ensure that BIAS providers' and other telecommunications carriers' privacy notices meet these essential criteria, which provide transparency and enable the exercise of choice.

123. In adopting these transparency requirements, we build on and harmonize our existing section 222 rules for voice providers with BIAS providers' existing requirement to disclose their privacy policy under the 2010 and 2015

Open Internet Orders.

For today's rules, we look to the record in this proceeding, which includes submissions from providers, consumer advocates, other government agencies, and others about what does and does not work with respect to privacy policies. We observe in particular that notice is fundamental to the FTC's privacy regime, acting as a basis for its implementation of FIPPs and forming required components of their enforcement proceedings. Based on that record, we adopt rules that require providers to disclose their privacy practices, but decline to be prescriptive about either the format or specific content of privacy policy notices in order to provide flexibility to providers and to minimize the burden of compliance levied by this requirement. Moreover, the record reflects that many BIAS providers and other telecommunications carriers already provide thorough notice of their privacy practices. In the interest of further minimizing the burden of transparency, particularly for small providers, we also direct the Consumer Advisory Committee to convene a multi-stakeholder process to develop a model privacy policy notice that will serve as a safe harbor for our notice requirements.

124. We recognize that some commenters have criticized privacy notice requirements as providing incomplete protections for consumers. Notices by themselves do not give consumers the power to control their information; notices are not always read or understood, and newer developments in tracking and analytics can reveal more about consumers than most people realize. However, none of these criticisms eliminates the fundamental need for and benefit of privacy notices. If consumers do not have access to the information they need to understand what personal data is being collected and how their data is being used and shared, they cannot make choices about those practices. The fact that poorly written or poorly distributed notices can confound consumer understanding does not make well-formed notices useless, and while one consumer may ignore a notice, another who has a compelling desire to protect her privacy will benefit substantially from it. Notice also remains an essential part of today's privacy frameworks, even as big data analysis creates new privacy challenges. As the recent Administration Big Data Report explains, notice and choice structures may not be sufficient to account for all privacy effects of “big data,” but such frameworks are necessary to protect consumers from a range of active privacy threats.

125. Below we lay out the specific transparency requirements we adopt today. First, we require that those privacy notices inform customers about what confidential information the providers collect, how they use it, and under what circumstances they share it. We also require that providers inform their customers about customers' rights to opt in to or out of (as the case may be) the use or sharing of their confidential information. This information must be presented in a way that is clear and conspicuous, in language that is comprehensible and not misleading. We will consider information to be misleading if it includes material misrepresentations or omissions. Second, we require that providers present their privacy notice to customers at the point of sale prior to the purchase of service, and that they make their privacy policies persistently available and easily accessible on their Web sites, apps, and the functional equivalents thereof. Finally, we require providers to give their customers advance notice of material changes to their privacy policies. In adopting these transparency rules, we are implementing, in part, sections 222(a) and 222(c)(1), under which we find that supplying customers with the information they need to make informed decisions about the use and sharing of their personal information is an element of “informed” approval within the meaning of section 222, as well as necessary to protecting the confidentiality of customer proprietary information.

1. Required Privacy Disclosures

126. Customers must have access to information about the personal data that a BIAS provider or other telecommunications carrier collects, uses, and shares, in order to make decisions about whether to do business with that provider, and in order to exercise their own privacy decisions. Absent such notice, the broad range of data that a provider is capable of gathering by virtue of providing service could leave customers with only a vague concept of how their privacy is affected by their service provider. We also agree with the FTC that disclosing this information “provides an important accountability function,” as disclosure of this information “constitute[s] public commitments regarding companies' data practices.” To enable customers to exercise informed choice, and to reduce the potential for confusion, misunderstanding, and carrier abuse, we find that a carrier's privacy notices must accurately describe the carrier's privacy policies with regard to its collection, use, and sharing of its customers' data. Therefore, we adopt rules that require each telecommunications carrier's notice of privacy policies to accurately specify and describe:

• The types of customer PI that the carrier collects by virtue of its provision of service, and how the carrier uses that information;

• Under what circumstances a carrier discloses or permits access to each type of customer PI that it collects, including the categories of entities to which the carrier discloses or permits access to customer PI and the purposes for which the customer PI will be used by each category of entities; and

• How customers can exercise their privacy choices.

We address each of these requirements in turn.

127.

Types of Customer PI Collected, and How It Is Used.

In order to make informed decisions about their privacy, customers must first know

what types

of their information their provider collects through the customers' use of the service. Therefore, we require BIAS providers and other telecommunications carriers to specify the types of customer PI that they collect by virtue of provision of the telecommunications service, and how they use that information. Pursuant to the voice rules and the

2010 Open Internet Order,

all BIAS providers already provide customers with information about their privacy policies. As such, we find that this requirement will not impose a significant burden on providers, and in some cases will decrease existing burdens.

128. Likewise, customers have a right to know

how

their information is being used and under what circumstances it is being disclosed in order to make informed privacy choices. Notices that omit these explanations fail to provide the context that customers need to exercise their choices. We emphasize that the notice must be sufficiently detailed to enable a reasonable consumer to make an informed choice

129. We do not require providers to divulge the inner workings of their data use programs. Instead, we find that to the extent that the notice requires providers to divulge the existence of such programs, the benefits to the market of more complete information, as well as the benefits to customers in knowing how their information is used, outweighs any individual advantage gained by any one competitor in keeping the existence of the programs secret. We therefore disagree with commenters that argue that these descriptions of how consumers' information will be used unduly jeopardize their competitive efforts.

130.

Sharing of Customer PI with Affiliates and Third Parties.

We also require that providers' privacy policies notify customers about the types of affiliates and third parties with which they share customer information, and the purposes for which the affiliates and third parties will use that information. A critical part of deciding whether to approve of the sharing of information is knowing

who

is receiving that information and for what purposes. This information will allow customers to gauge their comfort with the privacy practices and incentives of those other entities, whether they are affiliates or third parties. It will also promote customer confidence in their telecommunications service by providing concrete information and reducing uncertainty as to how their information is being used by the various parties in the data-sharing and marketing ecosystems. While our existing CPNI rules are more specific in requiring that individual entities be disclosed, we seek to minimize customer confusion and provider burden by adopting an approach used by the FTC by allowing disclosure of categories of entities. We also encourage carriers to make these categories of entities as useful and understandable to customers as possible. By way of example, the FTC's regulations implementing the GLBA privacy rules will find a covered institution in compliance with its rules if it lists particular categories of third party entities that it shares information with, distinguishing, for instance, between financial services providers, other companies, and other entities. The FTC's rules further specify that institutions should provide examples of businesses in those categories. In the context of communications customers' information, relevant categories might include providers of communications and communications-related services, customer-facing sellers of other goods and services, marketing and advertising companies, research and development, and nonprofit organizations.

131. We find that requiring providers to disclose categories of entities with which they share customer information and the purposes for which the customer PI will be used by each category of entities balances customers' rights to meaningful transparency with the reality of changing circumstances and the need to avoid overlong or over-frequent notifications. Because we harmonize these rules across BIAS and other telecommunications services, we eliminate the requirement that telecommunications services specify the “specific entities” that receive customer information in their notices of privacy policies accompanying solicitations for customer approval. We therefore reject calls to mandate disclosure of a list of the specific entities that receive customer PI. While some customers may benefit from receiving such detailed information, we are persuaded by commenters who assert that requiring such granularity would be unduly burdensome on carriers and induce notice fatigue in many customers. For instance, carriers would be faced with the near-continuous need to provide new notices every time contracts with particular vendors change or if third parties alter their corporate structure—and customers, in turn, would be inconvenienced with an overabundance of notices. Furthermore, a list of specific entities may not in itself aid the average consumer in making a privacy decision more than the requirement that we adopt, which ensures that consumers understand what third parties that receive their information do as a general matter. We therefore adopt the requirement that carriers need only provide categories of entities with whom customer PI is shared, minimizing the burden on telecommunications carriers. If a provider finds that providing notice of the specific entities with which it shares customer PI would increase customer confidence, nothing prevents a provider from doing so, and we would encourage notices to include as much useful information to customers as possible, while maintaining their clarity, concision, and comprehensibility, as discussed in Part III.C.3, below. Doing so does not require bombarding customers with pages of dense legal language; providers may make use of layered privacy notices or other techniques to ease comprehension and readability as necessary.

132.

Customers' Rights with Respect to Their PI.

We also adopt our

NPRM

proposal to require BIAS provider and other telecommunications carrier privacy notices to provide certain minimum information. Carriers need not, however, repeat any of these “rights” statements verbatim, and we encourage carriers to adapt these statements in manners that will be most effective based on their extensive experience with their customer base. Specifically, carriers' privacy notices must:

• Specify and describe customers' opt-in and opt-out rights with respect to their own PI. This includes explaining that:

○ A denial of approval to use, disclose, or permit access to customer PI for purposes other than providing telecommunications service will not affect the provision of the telecommunications services of which they are a customer.

○ any approval, denial, or withdrawal of approval for use of the customer PI for any purposes other than providing telecommunications service is valid until the customer affirmatively revokes such approval or denial, and that the customer has the right to deny or withdraw access to such PI at any time. However, the notice should also explain that the carrier may be compelled, or permitted, to disclose a customer's PI

when such disclosure is provided for by other laws.

• Provide access to a simple, easy-to-use mechanism for customers to provide or withdraw their consent to use, disclose, or permit access to customer PI as required by these rules.

133. These notice requirements are intended to ensure that providers inform their customers that they have the right to opt into or out of the use and sharing of their information, as well as how to make those choices known to the provider. We discuss the choice mechanism itself in Part III.D.4,

infra.

Requiring providers to describe in a single place how information is collected, used, and shared, as well as what the consumers' rights are to control that collection, use, and sharing, enhances the opportunity for customers to make informed decisions. Likewise, requiring the notice to provide access to the choice mechanism ensures that the mechanism is easily available and accessible as soon as the customer receives the necessary privacy information. This is important, since studies have shown that “adding just a 15-second delay between the notice and the loading of [a] Web page where subjects choose whether to reveal their information eliminates the privacy-protective effect of the notice.” As discussed further below, we decline to specify particular formats for carriers to provide access to their choice mechanisms, recognizing that different forms of access to the choice mechanism (

e.g.,

a link to a Web site, a mobile dashboard, or a toll-free number) may be more appropriate depending on the context in which the notice may be given (

e.g.,

on a provider's Web site, in a provider's app, or in a paper disclosure presented in a provider's store).

134. Studies have shown that customers are often resigned to an inability to control their information, and may be under a mistaken impression that exercising their rights may result in degraded service. Thus, we require providers' notice of privacy policies to also inform customers that denying a provider the ability to use or share customer PI will not affect their ability to receive service. As noted below, this provision does not mean that carriers categorically cannot engage in financial incentive practices. This parallels the existing section 222 rules, which require carriers to “clearly state that a denial of approval will not affect the provision of any services to which the customer subscribes.” Since providers drafting their notices have clear incentives to encourage customers to permit the use and sharing of customer PI, it can be easy for customers to misconstrue exactly what is conditioned upon their permission. These provisions are intended to make customers aware that the offer of choice is not merely

pro forma.

135. We permit providers to make clear and neutral statements about potential consequences when customers decline to allow the use or sharing of their personal information. We require that any such statements be clear and neutral in order to prevent them from obscuring the basic fact of the customer's right to prevent the use of her information without loss of service. Allowing difficult-to-read or biased statements would run counter to our goal of ensuring that notices overall are clear and conspicuous, comprehensible, and not misleading. NTCA recommends that we remove or modify from the

NPRM'

s proposal the requirement that the explanation be brief. In the interest of allowing more flexibility, we remove this requirement, with the understanding that brevity is often, but not always, a component of clarity.

136. We require providers to inform customers that their privacy choices will remain in effect until the customers change them, and that customers have the right to change them at any time. We acknowledge that “[c]ustomers may make hasty decisions in the moment simply to obtain Internet access . . . [and] therefore appreciate the reminder that they have the opportunity to change their mind.” We expect carriers' privacy promises to customers and the privacy choices customers make to be honored, including, for example, in connection with a carrier's bankruptcy. As the FTC has done in its groundbreaking work in this area, the FCC will be vocal in support of customer privacy interests that a carrier's bankruptcy may raise.

2. Timing and Placement of Notices

137. There is broad agreement that, in order to be useful, privacy policy notices must be clearly, conspicuously, and persistently available, and not overly burdensome to the carrier or fatiguing to the customer. We therefore require telecommunications carriers to provide notices of privacy policies at the point of sale prior to the purchase of service, and also to make them clearly, conspicuously, and persistently available on carriers' Web sites and via carriers' apps that are used to manage service, if any. We also eliminate periodic notice requirements from the voice CPNI rules.

138.

Point of Sale.

We agree with commenters that requiring notices at the point of sale ensures that notices are relevant in the context in which they are given, since this is a time when a customer can still decide whether or not to acquire or commit to paying for service, and it also allows customers to exercise their privacy choices when the carrier begins to collect information from them. In this, we agree with the FTC, which finds that the most relevant time is when consumers sign up for service. The proximity in time between sale and use of information means that a point-of-sale notice, in many if not most instances, serves the same function as a just-in-time notice—that of providing information at the most relevant point in time. Consumer groups such as the Center for Digital Democracy and providers such as Sprint also appear to agree on this point. The point-of-sale requirement is also consistent with the transparency requirements of the

2010 Open Internet Order,

which requires disclosure of privacy policies at the point of sale. As such, we find that this requirement will impose a minimal incremental burden on BIAS providers. The record further indicates that providing notice at the point of sale can be less burdensome for a carrier, in part because it allows the provider to walk a customer through the terms of the agreement. Providing notice at the point of sale, and not after a customer has committed to a subscription, can also allow carriers to compete on privacy.

139. We clarify that a “point of sale” need not be a physical location. Where the point of sale is over voice communications, we require providers to give customers a means to access the notice, either by directing them to an easily-findable Web site, or, if the customer lacks Internet access, providing the text of the notice of privacy policies in print or some other way agreed upon by the customer. We find that this requirement adequately addresses record concerns about the burdens associated with communicating polices orally to customers.

140.

Clear, Conspicuous, and Persistent Notice.

We also require telecommunications carriers to make their notices persistently available through a clear and conspicuous link on the carrier's homepage, through the provider's application (if it provides one for account management purposes), and any functional equivalents of the homepage or application. This requirement also reflects the transparency requirements in the

2010 Open Internet Order,

which mandate “at a minimum, the prominent display of disclosures on a publicly available . . . Web site,” and as such, should add a minimal burden for BIAS providers. Persistent and visible availability is critical; customers must be able to

review the notice and understand the carrier's privacy practices at any time since they may wish to reevaluate their privacy choices as their use of services change, as their personal circumstances change, or as they evaluate and learn about the programs offered by the provider. Persistent access to the notice of privacy policies also ensures that customers need not rely upon their memory of the notice that they viewed at the point of sale; so long as they have access to the provider's Web site, app, or equivalent, they can review the notice. As such, we require providers to at least provide a link to the web-hosted notice in a clear and conspicuous location on its homepage, to ensure that customers who visit the homepage may easily find it.

141. We require the notice of privacy policies to be clearly and conspicuously present not only on the provider's Web site, but to be accessible via any application (“app”) supplied to customers by the provider that serves as a means of managing their subscription to the telecommunications service. As more consumers rely upon mobile devices to access online information, a provider's Web site may become less of a central resource for information about the provider's policies and practices. Certain mobile apps serve much the same function as a mobile Web site interface, giving customers tools to manage their accounts with their providers. As a significant point of contact with the customer, such apps are an ideal place for customers to be able to find the notice of privacy policies. We do not, however, expect that every app supplied by a provider must carry the notice of privacy policies for the entire service—for instance, a mobile broadband provider that bundles a sports news app or a mobile game with its phones and services would not need to provide the privacy notice we require here with those apps. Nor do we require providers who lack an app to develop one. However, we require carriers that provide apps that manage a customer's billing or data usage, or otherwise serve as a functional equivalent to a provider's Web site, to ensure that those apps provide at least a link to a viewable notice of privacy policies.

142. Providing the notice both via the app and on the provider's Web site increases customers' ability to access and find the policy regardless of their primary point of contact with the provider. We do, however, wish to ensure that customers can still reach notices even as providers may develop other channels of contact with their customers, and thus require that the notice be made available on any functional equivalents of the Web site or app that may be developed. While we anticipate that all BIAS providers and most other telecommunications providers have a Web site, those that do not may provide their notices to customers in paper form or some other format agreed upon by the customer.

143.

No Periodic Notice Requirement.

We decline to require periodic notice on an annual or bi-annual basis. While periodic notices might serve to remind customers of their ability to exercise privacy choices, we remain mindful of the potential for notice fatigue and find that notices at the point of sale, supplemented by persistently available notices on providers' Web sites, and notices of material change to privacy policies, is sufficient to keep customers informed. Additionally, we believe that periodic notices might distract from notices of material changes, reducing the amount of customer attention to such changes. We find that annual or periodic notices are unnecessary or even counterproductive in this context, and we reduce burdens on all telecommunications carriers—including smaller carriers—by eliminating the pre-existing every-two-year notice requirement from our section 222 rules.

3. Form and Format of Privacy Notices

144. Recognizing the importance of flexibility in finding successful ways to communicate privacy policies to consumers, we decline to adopt any specific form or format for privacy notices. We agree with commenters that, in addition to running the risk of providing insufficient flexibility, mandated standardized requirements may unnecessarily increase burdens on providers, and prevent consumers from benefitting from notices tailored to a specific provider's practices. For example, the record reflects concerns that mandated standardized requirements can increase burdens on providers, and can also create a number of problems, including a lack of flexibility to account for the fact that different carriers may have different needs, such as creating comprehensive policies across different services. This concern is especially prevalent for smaller carriers. At the same time, we agree with commenters that whatever form of privacy notices a provider adopts, in order to adequately inform customers of their privacy rights, such privacy notices must clearly and conspicuously provide information in language that is comprehensible and not misleading, and be provided in the language used by the carrier to transact business with its customer. We therefore require providers to implement these general principles in formatting their privacy policy notices.

145. These basic requirements for the form and format of privacy policies build on existing Commission precedent regarding notice requirements for voice providers and open Internet transparency requirements for BIAS providers, and incorporate FTC guidance on customer notice standards. These basic principles are well suited to accommodating providers' and customers' changing needs as new business models develop or as providers develop and refine new ways to convey complex information to customers. Within these basic guidelines, providers may use any format that conveys the required information, including layering and adopting alternative methods of structuring the notice or highlighting its provisions. We note that as standard business practices for conveying complex information improve, we expect notices of providers' privacy policies to keep pace. We encourage innovative approaches to educating customers about privacy practices and choices.

146. While we decline to mandate a standardized notice at this time, the record demonstrates that voluntary standardization can benefit both customers and providers. As such, as described below, we adopt a voluntary safe harbor for a disclosure format that carriers may use in meeting the rules' standards for being clear and conspicuous, comprehensible, and not misleading.

147.

Clear, Conspicuous, Comprehensible and Not Misleading.

Consistent with existing best practices, we require providers' privacy notices to be readily available and written and formatted in ways that ensure the material information in them is comprehensible and easily understood. The record reflects broad agreement that providers' privacy practices “should be easily available [and] written in a clear way.” A number of commenters noted that certain practices frustrate the ability of customers to find and identify the important parts of privacy notices, observing, for example, that notices could be presented among or alongside distracting material, use unclear or obscure language, presented with significant delays in ability for consumers to act, or be placed only at the bottom of “endless scrolling” pages. By mandating that notices be clear, conspicuous, comprehensible, and not misleading, we prohibit such practices and others that render notices unclear, illegible, inaccessible, or needlessly obtuse.

148. The

NPRM

framed these requirements in several ways, including that notices be “clear and conspicuous,” as well as “clearly legible, use sufficiently large type, and be displayed in an area so as to be readily apparent to the consumer.” In adopting these rules, we streamline these requirements by interpreting “conspicuous” to include requirements for prominent display, and eliminate the requirement for “sufficiently large type,” based upon the understanding that insufficiently large type would not be “comprehensible” or “clear and conspicuous.” Removing this specific requirement also preserves the ability for providers who may be able to convey the necessary information through images or other non-textual means.

149. We agree with the FTC's observation that existing notices of privacy policies are frequently too long and unclear; overlong notices are often inherently less comprehensible. As T-Mobile states, “today's busy consumers often have limited ability to fully review the hundreds of privacy policies that apply to the apps, Web sites, and services they use, and prefer simpler notices that provide meaningful information.” We recognize that providers must balance conveying the required information in a comprehensive and comprehensible manner, and therefore encourage, but do not require, providers to make their notices as concise as possible while conveying the necessary information. Layered notices, lauded by a few commenters, may be one of several ways to achieve these parallel objectives.

150. The record also reflects that transparency is only effective in preventing deception when the information shared is meaningful to the recipient. We agree with the California Attorney General that companies should “alert consumers to potentially unexpected data practices,” and as such require that providers' notices not be misleading in addition to being comprehensible. This requirement is also consistent with FTC precedent.

151.

Other Languages.

We agree with the FTC that providers should convey notices to their customers in a language that the customers can understand. We therefore require providers to convey their entire notices of privacy policies to customers in another language, if the telecommunications carrier transacts business with the customer in that other language. This requirement ensures that customers who are advertised to in a particular language may also understand their privacy rights in that same language. We note that for the purposes of this rule, “language” also includes American Sign Language, meaning that if the customer transacts business with the carrier in American Sign Language, the notice would need to be made available in that language. We conclude that this obligation appropriately balances accommodating customers who primarily use languages other than English and reducing the burden on providers, especially small providers, to translate notices into languages that are unused by their particular customers.

152.

Mobile-Specific Considerations.

We decline to mandate any additional requirements for notices displayed on mobile devices. The record indicates that providers desire flexibility to adapt notices to be usable in the mobile environment for their customers, while consumer advocates stress that the requirements for usability must be met in some way, regardless of the specific formatting. So long as notices on mobile devices meet the above guidelines and convey the necessary information, they will comply with the rules. Providers are free to experiment within those broad guidelines and the capabilities of mobile display technology to find the best solution for their customers.

153.

Safe Harbor for Standardized Privacy Notices.

To encourage adoption of standardized privacy notices without mandating a particular form, we direct the Consumer Advisory Committee, which is composed of both industry and consumer interests, to formulate a proposed standardized notice format, based on input from a broad range of stakeholders, within six months of the time that its new membership is reconstituted, but, in any event, no later than June 1, 2017. There is strong support in the record for creation of standardized notice, and for use of multi-stakeholder processes. Standardized notices can assist consumers in interpreting privacy policies, and allow them to better compare the privacy policies of different providers, allowing increased competition in privacy protections. Standardized notices can also reduce compliance costs for providers, especially small providers, by ensuring they can easily adopt a compliant form and format for their notices.

154. The CAC has significant expertise in developing standard broadband disclosures and other consumer disclosure issues. We find that the Committee's experience makes it an ideal body to recommend a notice format that will be sufficiently clear and easy to read to allow consumers to easily understand and compare the privacy practices of different providers. To ensure that the notice will be clear and easy to read for all customers, it must also be accessible to persons with disabilities. We delegate authority to the Wireline Competition Bureau, Wireless Telecommunications Bureau, and Consumer & Governmental Affairs Bureau to work with the CAC on the draft standardized notice. If the CAC recommends a form or format that do not meet the Bureaus expectations, the Bureaus may ask the CAC to consider changes and submit a revised proposal for the Bureaus' review within 90 days of the Bureaus' request. The Bureaus may also seek public comment, as they deem appropriate, on any standardized notice the CAC recommends. We also delegate authority to the Bureaus to issue a Public Notice announcing any proposed format or formats that they conclude meet our expectations for the safe harbor for making consumer-facing disclosures.

155. Providers that voluntarily adopt a privacy notice format developed by the CAC and approved by the Bureaus will be deemed to be in compliance with the rules' requirements that notices be clear, conspicuous, comprehensible, and not misleading. As with the

Open Internet

BIAS transparency rules, use of the safe harbor notice is a safe harbor with respect to the format of the required disclosure to consumers. A provider meeting the safe harbor could still be found to be in violation of the rules, for example, if the content of that notice is misleading, otherwise inaccurate, or fails to include all mandated information.

4. Advance Notice of Material Changes to Privacy Policies

156. We require telecommunications carriers to provide advance notice of material changes to their privacy policies to their existing customers, via email or other means of active communication agreed upon by the customer. As with our requirements for the notice of privacy policy, if a carrier does not have a Web site, it may provide notices of material change notices to customers in paper form or some other format agreed upon by the customer. As with a provider's privacy policy notice, any advance notice of material changes to a privacy policy must be clear, conspicuous, comprehensible, and not misleading. The notice also must be completely translated into a language other than English if the telecommunications carrier transacts business with the customer in that language. This notice must inform customers of both (1) the changes being made; and (2) customers' rights with respect to the material change as it relates to their customer PI. In doing so, we follow our own precedent and that

of the FTC in recognizing the need for consumers to have up-to-date and relevant information upon which to base their choices. This requirement to notify customers of material change finds strong support in the record.

157. The record reflects strong justifications for requiring providers to give customers advance notice of material changes to their privacy policies. In order to ensure that customer approval to use or share customer PI is “informed” consent, customers must have accurate and up-to-date information of what they are agreeing to in privacy policies. The notice of material change requirement that we adopt is consistent with the transparency requirements of the

2015 Open Internet Order,

which require providers to disclose material changes in, among other things, “commercial terms,” which includes privacy policies. Notices of material change are essential to respecting customers' informed privacy choices; if a provider substantially changes its privacy practices after a customer has agreed to a different set of practices, the customer cannot be said to have given informed consent, consistent with Section 222. This is particularly important when providers are seeking a customer's opt-out consent, since the customer's privacy rights could change whether or not they had actual knowledge of the change in policy. We therefore disagree that such a requirement is outweighed by the risk of notice fatigue; to the extent that providers are frequently changing their policies materially, they should alert their customers to that fact, or risk rendering their earlier efforts at transparency fruitless.

158. For the purposes of this rule, we consider a “material change” to be any change that a reasonable customer would consider important to her decisions on her privacy. This parallels the consumer interest-focused definition of “material change” used in the

2015 Open Internet Order.

The definition differs from that in the

2015 Open Internet Order

in two respects: the customer's interest is defined by the customer's decisions on privacy, and not choice of provider, service, or application; and the reference to edge providers, which are not relevant to the material changes at issue, has been removed. Such changes would primarily include any changes to the types of customer PI at issue, how each type of customer PI is used or shared and for what purpose, or the categories of entities with which the customer PI is shared. To provide guidance on the standard above, at minimum, if any of the required information in the initial privacy notification changes, then the carrier must provide the required update notice. We adopt this guidance because the initial notice contains the information on which customers are making their privacy decisions, and changes to that information may alter how consumers grant permissions to their carriers. We also limit carriers' requirements under this

This text is long and has been trimmed here. Open the source document for the complete record.