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-39]

Protecting the Privacy of Customers of Broadband and Other Telecommunications Services

AGENCY:

Federal Communications Commission.

ACTION:

Proposed rule.

SUMMARY:

The Federal Communications Commission initiates a rulemaking seeking public comment on how to apply the privacy requirements of the Communications Act to broadband Internet access service (BIAS). This Notice of Proposed Rulemaking (NPRM) focuses on transparency, choice, and data security, in a manner that is consistent with the Commission's history of protecting privacy, the Federal Trade Commission's leadership, and various sector-specific statutory approaches, tailored to the particular circumstances that consumers face when they use broadband networks and with an understanding of the particular nature and technologies underlying those networks. The NPRM would recognize that consumers cannot give their permission for the use of protected data unless relevant broadband provider practices are transparent. The NPRM proposes a framework to ensure that consumers; understand what data the broadband provider is collecting and what it does with that information; can decide how their information is used; and are protected against the unauthorized disclosure of their information. The NPRM also seeks comment on a number of closely-related questions.

DATES:

Submit comments on or before May 27, 2016. Submit reply comments on or before June 27, 2016. Written comments on the Paperwork Reduction Act proposed information collection requirements must be submitted by the public, Office of Management and Budget (OMB), and other interested parties on or before June 20, 2016.

ADDRESSES:

You may submit comments, identified by WC Docket No. 16-106, by any of the following methods:

Federal Communications Commission's Web site: http://apps.fcc.gov/ecfs/.

Follow the instructions for submitting comments.

People with Disabilities:

Contact the FCC to request reasonable accommodations (accessible format documents, sign language interpreters, CART, etc.) by email:

FCC504@fcc.gov

or phone: 202-418-0530 or TTY: 202-418-0432.

For detailed instructions for submitting comments and additional information on the rulemaking process, see the

SUPPLEMENTARY INFORMATION

section of this document. In addition to filing comments with the Secretary, a copy of any comments on the Paperwork Reduction Act information collection requirements contained herein should be submitted to the Federal Communications Commission via email to

PRA@fcc.gov

and to Nicole Ongele, Federal Communications Commission, via email to

Nicole.Ongele@fcc.gov.

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:

Pursuant to Sections 1.415 and 1.419 of the Commission's rules, 47 CFR 1.415, 1.419, interested parties may file comments and reply comments on or before the dates indicated on the first page of this document. Comments may be filed using the Commission's Electronic Comment Filing System (ECFS).

See Electronic Filing of Documents in Rulemaking Proceedings,

63 FR 24121 (1998),

http://www.fcc.gov/Bureaus/OGC/Orders/1998/fcc98056.pdf.

Electronic Filers:

Comments may be filed electronically using the Internet by accessing the ECFS:

http://apps.fcc.gov/ecfs/.

Paper Filers:

Parties who choose to file by paper must file an original and one copy of each filing. If more than one docket or rulemaking number appears in the caption of this proceeding, filers must submit two additional copies for each additional docket or rulemaking number.

Filings can be sent by hand or messenger delivery, by commercial overnight courier, or by first-class or overnight U.S. Postal Service mail. All filings must be addressed to the Commission's Secretary, Office of the Secretary, Federal Communications Commission.

All hand-delivered or messenger-delivered paper filings for the Commission's Secretary must be delivered to FCC Headquarters at 445 12th St. SW., Room TW-A325, Washington, DC 20554. The filing hours are 8:00 a.m. to 7:00 p.m. All hand deliveries must be held together with rubber bands or fasteners. Any envelopes and boxes must be disposed of

before

entering the building.

Commercial overnight mail (other than U.S. Postal Service Express Mail and Priority Mail) must be sent to 9300 East Hampton Drive, Capitol Heights, MD 20743.

U.S. Postal Service first-class, Express, and Priority mail must be addressed to 445 12th Street SW., Washington, DC 20554.

People with Disabilities:

To request materials in accessible formats for people with disabilities (Braille, large print, electronic files, audio format), send an email to

fcc504@fcc.gov

or call the Consumer & Governmental Affairs Bureau at 202-418-0530 (voice), 202-418-0432 (tty).

Synopsis

In this Notice of Proposed Rulemaking (NPRM), we propose to apply the privacy requirements of the Communications Act to broadband Internet access service (BIAS) and seek comment on how best to protect the privacy of the personal information of BIAS customers.

I. Introduction

1. The intersection of privacy and technology is not new. In 1890, Samuel Warren and Louis Brandeis inaugurated the modern age of privacy protection when they warned that “numerous mechanical devices threaten to make good the prediction that `what is whispered in the closet should be proclaimed from the house-tops.' ” The new technology they had in mind? The portable camera.

2. In this Notice of Proposed Rulemaking (NPRM or Notice), we propose to apply the traditional privacy requirements of the Communications Act to the most significant communications technology of today: Broadband Internet access service (BIAS). This is important because both consumers and Internet Service Providers (ISPs) would benefit from additional, concrete guidance explaining the privacy responsibilities created by the Communications Act. To that end, our approach can be simply stated:

First,

consumers must be able to protect their privacy, which requires transparency, choice, and data security.

Second,

ISPs are the most important and extensive conduits of consumer information and thus have access to very sensitive and very personal information that could threaten a person's financial security, reveal

embarrassing or even harmful details of medical history, or disclose to prying eyes the intimate details of interests, physical presence, or fears. But,

third,

the current federal privacy regime, including the important leadership of the Federal Trade Commission (FTC) and the Administration efforts to protect consumer privacy, does not now comprehensively apply the traditional principles of privacy protection to these 21st Century telecommunications services provided by broadband networks. That is a gap that must be closed, and this NPRM proposes a way to do so by securing what Congress has commanded—the ability of every telecommunications user to protect his or her privacy.

3. Privacy protects important personal interests. Not just freedom from identity theft, financial loss, or other economic harms but also from concerns that intimate, personal details could become grist for the mills of public embarrassment or harassment or the basis for opaque, but harmful judgments, including discrimination. The power of modern broadband networks is that they allow consumers to reach from their homes (or cars or sidewalks) to the whole wide world instantaneously. The accompanying concern is that those broadband networks can now follow the activities of every subscriber who surfs the web, sends an email or text, or even walks down a street carrying a mobile device. Absent legally-binding principles, those networks have the commercial motivation to use and share extensive and personal information about their customers. The protection of privacy thus both protects individuals and encourages use of broadband networks, by building trust.

4. Today, as the FTC has explained, ISPs are “in a position to develop highly detailed and comprehensive profiles of their customers—and to do so in a manner that may be completely invisible.” This is particularly true because a consumer, once signed up for a broadband service, simply cannot avoid that network in the same manner as a consumer can instantaneously (and without penalty) switch search engines (including to ones that provide extra privacy protections), surf among competing Web sites, and select among diverse applications. Indeed, the whole purpose of the customer-provider relationship is that the network becomes an essential means of communications with destinations chosen by the customer; which means that, absent use of encryption, the broadband network has the technical capacity to monitor traffic transmitted between the consumer and each destination, including its content. Although the ability to monitor such traffic is not limitless, it is ubiquitous. Even when traffic is encrypted, the provider has access to, for example, 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. Providers of BIAS (“broadband providers”) thus have the ability to capture a breadth of data that an individual streaming video provider, search engine or even e-commerce site simply does not. And they have control of a great deal of data that must be protected against data breaches. To those who say that broadband providers and edge providers must be treated the same, this NPRM proposes rules that recognize that broadband networks are not, in fact, the same as edge providers in all relevant respects. But this NPRM looks to learnings from the FTC and other privacy regimes to provide complementary guidance.

5. The core privacy principles—transparency, choice, and security—underlie the critical steps that the federal government has taken to protect the privacy of many specific forms of data. Indeed, these three principles are the heart of the internationally recognized Fair Information Practices Principles (FIPPs) that have informed our nation's thinking on privacy best practices while providing the framework for most of our federal privacy statutes.

6. Today, the Commission is empowered to protect the private information collected by telecommunications, cable, and satellite companies in Sections 222, 631, and 338 of the Communications Act and the Commission has recognized the importance of longstanding privacy principles in adopting and refining its existing Section 222 rules and enforcing privacy requirements. Thus, from the outset of its implementation of Section 222, the Commission has focused on ensuring that consumers have the tools to give their approval for the use and sharing of protected information.

7. Meanwhile, as consumer use of the Internet exploded, the FTC, using its authority to prohibit “unfair or deceptive acts or practices in or affecting commerce,” entered into a series of precedent-setting consent orders addressing privacy practices on the Internet. Taken together, the FTC's online privacy cases focus 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. Although the application of Section 222 to BIAS has implications for the jurisdiction of the FTC, that agency's leadership is critically important in this sphere and the Commission is determined to continue its close working relationship with the FTC. Most recently, the two agencies entered into a consumer protection Memorandum of Understanding (MOU). In the MOU each agency recognizes the others' expertise and we each agreed to coordinate and consult on areas of mutual interest.

8. This NPRM supports the ability of broadband networks to be able to provide personalized services, including advertising, to consumers—while reaping the financial rewards therefrom. For example, many consumers want targeted advertising that provides very useful information in a timely (sometimes immediate) manner. Nothing in this NPRM stops consumers from receiving targeted recommendations—or any other form of content they wish to consume. But well-functioning commercial marketplaces rest on informed consent. Permission is required before purchasers can be said to agree to buy a product; permission is needed before owners of property transfer their interests in that property. This NPRM embraces the basic economic principle that informed choice is necessary to protect the fundamental interest in privacy. Thus, the consumer who possesses private information must provide the broadband provider advanced approval for the use of that data. In many instances, that approval is inherent in the use of the broadband Internet access service (for example, the routing of communications to or from the consumer), but where it is not, this NPRM proposes that separate consent must be obtained. This is good for consumers and it is good business, as the success of opt-in provisions in other contexts demonstrates.

9. In the

2015 Open Internet Order,

we concluded that Section 222 should be applied to the broadband connections consumers use to reach the Internet, the newly-reclassified Title II service defined as “Broadband Internet Access Service” (BIAS). Section 222 is a sector-specific statute that includes detailed requirements that Congress requires be applied to the provision of telecommunications services, but not to the provision of other services by broadband providers nor to information providers at the edge of the network.

Thus, this NPRM applies existing statutory authority solely to the existing class of services that Congress included within the scope of Title II, namely the delivery of telecommunications services.

II. Ensuring Privacy Protections for Customers of Broadband Services

A. Defining Key Terms

10. To provide guidance to both broadband providers and customers regarding the scope of the privacy protections we propose today, in this section we propose to define the entities to which our rules apply and the scope of information covered by such rules. We also propose to define other key terms, including what constitutes “opt-out” and “opt-in” for purposes of giving customers control over the use of their confidential information, what constitutes aggregate customer proprietary information, and what constitutes a “breach” for purposes of our proposed data security and data breach notification rules. Finally, we seek comment on whether and how we should modify any of the current Section 222 definitions, either to update those definitions or harmonize them with the rules we propose to adopt with respect to BIAS providers. We recognize there will be an interplay between commenters' proposals about what substantive rules we should adopt to protect BIAS customers' privacy interests and how we should define key terms and we invite commenters to explore in detail the relationships between the two.

1. Defining BIAS and BIAS Provider

11. We propose to apply the definition of “Broadband Internet Access Services” or “BIAS” that we used in the

2015 Open Internet Order.

In that proceeding, we defined BIAS to mean “[a] mass-market retail service by wire or radio that provides the capability to transmit data to and receive data from all or substantially all Internet endpoints, including any capabilities that are incidental to and enable the operation of the communications service, but excluding dial-up Internet access service. This term also encompasses any service that the Commission finds to be providing a functional equivalent of the service described in the previous sentence, or that is used to evade the protections set forth in this part.” We propose to define “broadband Internet access service provider” (BIAS provider) as a person or entity engaged in the provision of BIAS.

2. Defining Affiliate

12. We seek comment on how we should define “affiliate” for purposes of our proposed rules. The Act, as amended, and our current rules, define “affiliate” to mean “a person that (directly or indirectly) owns or controls, is owned or controlled by, or is under common ownership or control with, another person,” where the term “own” is defined to mean “to own an equity interest (or the equivalent thereof) of more than 10 percent.” We seek comment on whether we should adopt this definition or another definition for purposes of our proposed rules, as well as any associated benefits and burdens, particularly for small providers.

3. Defining Customer

13. We propose to define “customer” to mean (1) a current or former, paying or non-paying subscriber to broadband Internet access service; and (2) an applicant for broadband Internet access service. We seek comment on our proposal and on whether we should harmonize the existing Section 222 definition of customer with our proposed broadband definition.

14. Under our current Section 222 rules, “[a] customer of a telecommunications carrier is a person or entity to which the telecommunications carrier is currently providing service.” We believe that the existing rule's limitation to current subscribers is insufficiently narrow, perhaps particularly as applied to the broadband context. As technological capabilities have progressed, data retention and processing have increased, concomitantly increasing the incentives for retaining, using, and selling personal information of applicants and of former customers. Because BIAS providers have the ability to retain and reuse applicant and former customer proprietary information long after the application process is over, or the former customer has discontinued its subscription, we propose to define customer for BIAS purposes to include both applicants for BIAS and former BIAS customers. We recognize that not all aspects of our proposed rules will be applicable to all such customers in every situation (

e.g.,

a data breach may impact some customers but not others). For the purposes of these proposed rules we sometimes refer to “affected customers” or “existing customers” to designate a subset of customers, as appropriate.

15. In seeking comment on our proposed definition of “customer” we inquire as to whether, without the privacy protections of Section 222, consumers may be hesitant to apply for BIAS or current BIAS users may be apprehensive about switching service providers out of concern that their current provider may stop protecting their privacy after they switch providers. Could such apprehension inhibit competition and innovation in the BIAS marketplace?

16. We recognize that a single BIAS subscription is often used by multiple people. Residential fixed broadband services typically have a single subscriber, but are used by all members of a household, and often by their visitors. Some mobile BIAS providers offer friends and family plans in which multiple people are enrolled on one BIAS account, each with their own identified device(s) or user login. Should the definition of customer reflect the possibility of multiple broadband users? Should each member of a group plan or each user with a login be treated as a distinct customer who must receive individualized notices and consent requests? Is such a definition of “customer” appropriately consistent with the definition of “end user” adopted in the

2015 Open Internet Order

? Under such an interpretation, how would or should BIAS providers treat members of a group plan who are minors or are otherwise unable to understand notice and consent? How can we ensure that BIAS providers protect the information of all users of broadband Internet access service, given that the contract is between the BIAS provider and its subscriber? Should we define “subscriber” as any person about whom broadband providers hold customer information? How should we treat the interests of persons using corporate accounts, for example, including the employees of a small business? We seek comment on these issues and the benefits and burdens of any proffered alternatives.

17. At the same time, we are cognizant of the potential burdens that defining the term “customer” too broadly could place on BIAS providers, and we believe that the definition we propose today strikes the right balance between minimizing the burdens on BIAS providers and protecting customer proprietary information. We believe that our proposed definition will minimize the burden on BIAS providers by limiting the proposed notice and consent requirements to interactions with a single account holder, as opposed to every individual who connects to a broadband service over that subscription. Do commenters agree? We seek comment on the benefits and burdens associated with our proposed definition, and any alternatives,

including, in particular, burdens on small providers.

18. We also seek comment on whether we should revise the definition of “customer” in the existing CPNI rules to be consistent with our proposed definition of “customer” in the BIAS context. At least some of the concerns we identified above in regard to BIAS customers are not unique to BIAS; voice customers in today's world of big data face similar issues related to the protection of their own private information when they apply for and after they have terminated service. Given these concerns, we seek comment whether we should harmonize the definition of “customer” across voice and broadband platforms for purposes of protecting customer privacy.

19. Finally, to the extent we adopt rules that harmonize the privacy requirements under section 222 with the requirements for cable and satellite providers under Sections 631 and 338(i), should we understand the term “subscriber” in those provisions of the Act to be coextensive with the term “customer” we propose here?

4. Defining CPNI in the Broadband Context

20. As with the existing CPNI rules, we propose to adopt the statutory definition of CPNI for use in the broadband context. Section 222(h)(1) defines CPNI to mean “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” and “information contained in the bills pertaining to telephone exchange service or telephone toll service received by a customer or a carrier,” except that CPNI “does not include subscriber list information.” We seek comment on this proposal. Is there any need to include the second part of that definition in our rules regarding BIAS services, given its applicability only to telephone exchange service and telephone toll service?

21. We propose to interpret the phrase “made available to the carrier by the customer solely by virtue of the carrier-customer relationship” in the definition of CPNI to include any information falling within a CPNI category, as discussed below, that the BIAS provider collects or accesses in connection with the provision of BIAS. Consistent with the Commission's

2013 CPNI Declaratory Ruling,

this includes information that a BIAS provider causes to be collected and stored on customer premises equipment (CPE) or other devices, including mobile devices, in order to allow the carrier to collect or access the information. As the Commission held, 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.” We also recognize that a BIAS provider has the ability to create and append CPNI to a customer's Internet traffic, such as by inserting a user ID header (UIDH). We interpret any information the BIAS provider attaches to a customer's Internet traffic to be CPNI if it falls within one of the categories delineated in Section 222(h)(1)(A). We seek comment on our approach.

22. In order to provide guidance to consumers and to BIAS providers, we propose to provide specific examples of the types of information that we consider CPNI in the broadband context. In the context of the existing CPNI rules, the Commission has explicitly declined to set out a comprehensive list of data elements that do or do not satisfy the statutory definition of CPNI, and we propose to continue to follow that model in the broadband context. The Commission has, however, enumerated certain data elements that it considers to be 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 consumer, such as call waiting—and we propose to delineate similar non-exhaustive examples of the types of information that we would consider to constitute CPNI in the broadband context. We believe that such guidance will help provide direction regarding the scope of broadband providers' obligations and help to increase consumers' confidence in the security of their confidential information as technology continues to advance. We seek comment on this approach, alternatives, and any associated benefits and burdens, particularly for small providers.

a. Types of Information That Meet the Statutory Definition of CPNI

23. We propose that, at a minimum, we consider the following types of information to constitute CPNI in the broadband context: (1) Service plan information, including type of service (

e.g.,

cable, fiber, or mobile), service tier (

e.g.,

speed), pricing, and capacity (

e.g.,

information pertaining to data caps); (2) geo-location; (3) media access control (MAC) addresses and other device identifiers; (4) source and destination Internet Protocol (IP) addresses and domain name information; and (5) traffic statistics. Below we offer explanations for why we consider each of these type of data to fall within our proposed definition of CPNI with respect to BIAS. We seek comment on our proposed interpretations. We ask that commenters explain their responses to our proposed interpretations and identify any other element of the definition of CPNI which commenters believe covers any of the specific data elements described below.

24.

Broadband Service Plans.

We propose to consider information related to a customer's broadband service plan as CPNI in the broadband context. Broadband service plans are analogous to voice telephony service plans, which the Commission has long considered to be CPNI under the existing CPNI rules. We believe that information related to the telecommunications services the BIAS provider provides to the customer, including type of service (

e.g.,

fixed or mobile; cable or fiber; prepaid or term contract), speed, pricing, and capacity (including information pertaining to data caps) is information relating to the “quantity,” “technical configuration,” “type,” and “amount of use” of a telecommunications service subscribed to by a customer. We seek comment on this proposed interpretation. Are there other data elements that are analogous to those included in a voice telephony service plan that we should consider CPNI in the broadband context?

25.

Geo-Location.

We propose to consider information related to the physical or geographical location of a customer or the customer's device(s) (geo-location), regardless of the particular technological method a BIAS provider uses to obtain this information, to be CPNI in the broadband context. The statutory definition of CPNI includes information related to “location” of a telecommunications services subscribed to by a customer. The Commission has held that “[t]he location of a customer's use of a telecommunications service also clearly qualifies as CPNI.” We seek comment on this proposed interpretation.

26.

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

We propose to consider any MAC address associated with a customer's device to be CPNI in the broadband context. 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); as such, we believe it is analogous to the IMEI mobile device identifier in the

voice telephony context. Because BIAS providers use MAC addresses to route data packets to the end user, we believe that we should consider such information “destination” and “technical configuration” information under Section 222(h)(1)(A). Similarly, we propose to consider other device identifiers and other information in link layer protocol headers to be CPNI in the broadband context. We seek comment on our proposed interpretation. We also seek comment on other types of device identifiers that meet the statutory definition of CPNI. For example, our TRS rules recognize that a unique device identifier such as an “electronic serial number” is “call data information” in the TRS CPNI context.

27.

Internet Protocol (IP) Addresses and Domain Name Information.

We propose to consider both source and destination IP addresses as CPNI in the broadband context. An IP address is the 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, IP addresses are roughly analogous to telephone numbers in the voice telephony context, and 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. IP addresses are also frequently used in geo-location. As such, we believe that we should consider IP addresses to be “destination” and “location” information under Section 222(h)(1)(A). Similarly, we propose to consider other information in Internet layer protocol headers to be CPNI in the broadband context, because they may indicate the “type” and “amount of use” of a telecommunication service. We seek comment on this proposed interpretation.

28. Similarly, we propose to consider the domain names with which an end user communicates CPNI in the broadband context. Domain names (

e.g.,

“

www.fcc.gov”

) are common monikers that the end user uses to identify the endpoint to which they seek to connect. Domain names also translate into IP addresses, which we propose to consider CPNI. We therefore propose to treat domain names as destination and location information. We seek comment on this proposed interpretation.

29.

Traffic Statistics.

We propose to consider traffic statistics to be CPNI pertaining to the “type” and “amount of use” of a telecommunications service. We believe that “amount of use” encompasses quantifications of 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). We recognize that modern technology enables easily collecting and analyzing traffic statistics to draw powerful inferences that implicate customer privacy. For example, a BIAS provider could deduce the type of application (

e.g.,

VoIP or web browsing) that a customer is using, and thus the purpose of the communication. Further, traffic statistics can be used to determine the date, time, and duration of use, and deduce usage patterns such as when the customer is at home, at work, or elsewhere. We believe traffic statistics are analogous to call detail information regarding the “duration[] and timing of [phone] calls” and aggregate minutes in the voice telephony context. We seek comment on our proposed interpretation.

b. Other Broadband Data Elements That Could Meet the Statutory Definition of CPNI

30. We also seek comment on whether we should consider other types of information to fall within the statutory definition of CPNI in the broadband context, including: (1) Port information; (2) application headers; (3) application usage; and (4) CPE information.

31.

Port Information.

We seek comment on whether we should consider port information to be “technical configuration,” “type,” “destination” information, and/or any other category of CPNI under Section 222(h)(1)(A). A port is a logical endpoint of communication with the sender or receiver's application. The destination port number determines which application receives the communication. We believe that 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 or web browsing. We understand that BIAS providers sometimes configure their networks using port information for network management purposes, such as to block certain ports to ensure network security. We seek comment on whether we should consider port numbers and other information regarding port usage CPNI in the broadband context. Similarly, we seek comment on whether we should consider other information in transport layer protocol headers to be CPNI in the broadband context, for instance because it may be information that relates to the “technical configuration” or “amount of use” of a telecommunications service.

32.

Application Header.

We seek comment on whether we should consider application headers “technical configuration,” “type,” and/or “destination” information, or any other category of CPNI under Section 222(h)(1)(A). Application headers are application-specific data that assist with or otherwise relate to requesting and conveying application-specific content. The application header communicates information between the application on the end user's device and the corresponding application at the other endpoint(s) with which the user communicates. For example, application headers for web browsing typically contain the Uniform Resource Locator (URL), operating system, and web browser; application headers for email typically contain the source and destination email addresses. 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. We understand that BIAS providers sometimes configure their networks using application headers for network management purposes. We believe that access to application headers is analogous in the voice telephony context to accessing a customer's choices within telephone menus used to route calls within an organization (

e.g.,

“Push 1 for sales. Push 2 for billing.”). We seek comment on whether we should consider application headers CPNI in the broadband context. Similarly, we seek comment on whether we should consider any other application layer information to be CPNI in the broadband context.

33.

Application Usage.

We seek comment whether and under what circumstances we should consider information the broadband provider collects about the use of applications to meet the statutory definition of CPNI. As the Commission discussed in the

2013 CPNI Declaratory Ruling,

if such information meets the terms of Section 222(h)(1)(A) and the broadband provider directs the collection or storage of the information, it is CPNI. Based on this clarification, should we conclude that information the broadband provider collects about the usage of applications is CPNI in the broadband context, if the broadband provider directs such collection and the information collected falls within the statutory elements of CPNI? Based on the principles discussed in the

2013 CPNI Declaratory Ruling,

could application usage that

does not result in transmission also qualify as CPNI?

34.

Customer Premises Equipment (CPE) Information.

We seek comment whether we should consider information regarding CPE as “relat[ing] to the . . . technical configuration” and/or “type . . . of use of a telecommunication service,” or any other category under the statutory definition of CPNI. CPE is defined in the Act as “equipment employed on the premises of a person (other than a carrier) to originate, route, or terminate telecommunications.” In the broadband context, we believe CPE would include, but not be limited to, a customer's smartphone, tablet, computer, modem, router, videophone, or IP caption phone. The nature of a customer's device may impact the technical configuration of the broadband service based on the communications protocol that the device uses and may also identify the type of service to which the customer subscribes (

e.g.,

fixed vs. mobile, cable vs. fiber). We seek comment whether we should consider CPE information CPNI in the broadband context.

35.

Other.

We seek comment on what other customer information there is to which a BIAS provider has access by virtue of its provision of BIAS, whether such information should appropriately be considered CPNI, and why. We also seek comment on whether we should include any additional information in the definition of CPNI in the mobile context. If we find that any of the information discussed in this section is not CPNI, we seek comment on whether and how it should be protected.

36. We also seek comment on whether we should consider adopting a broader definition of CPNI and include additional categories of customer information into CPNI. If so, what should that definition be and what should it include? Is adopting a broader definition of CPNI the best way to provide consumers with robust privacy protections? What are the benefits and drawbacks to adopting a broader definition of CPNI?

37. Finally, we seek comment on any other issues we should address in conjunction with the definition of CPNI, as well as the benefits and burdens associated with any proposals to remedy those concerns, and in particular any associated benefits and burdens for small providers.

5. Defining Customer Proprietary Information

38. Section 222(a) imposes a general duty on telecommunications carriers “to protect the confidentiality of proprietary information of, and relating to . . . customers.” Although the Commission's previous rulemakings addressing Section 222 have been limited to CPNI, subsection (a) by its terms does not appear to be limited to protecting customer information defined as CPNI. In its initial Section 222 rulemaking, the Commission limited itself to adopting rules implementing the CPNI requirements of Sections 222(c)-(f) in response to a petition from local exchange carrier associations. More recently, however, the Commission recognized the obligation of providers to protect the confidentiality of customer proprietary information pursuant to Section 222(a) in the enforcement context. In the

TerraCom NAL

we interpreted customer “proprietary information” as “clearly encompassing private information that customers have an interest in protecting from public exposure,” including, but not limited to, “privileged information, trade secrets, and personally identifiable information.” We explained that, in 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.”

39. In keeping with that interpretation of Section 222(a), we propose to define “proprietary information of, and relating to . . . customers” to include private information that customers have an interest in protecting from public disclosure, and consider such information to fall into two categories: (1) Customer proprietary network information (CPNI); and (2) personally identifiable information (PII) the BIAS provider acquires in connection with its provision of BIAS. We refer to these two categories of data together as “customer proprietary information” or “customer PI.” We believe Section 222(a) protects CPNI because customer proprietary network information is a specific subtype of customer proprietary information generally. As described in more detail below, consistent with well-developed concepts of what constitutes personally identifiable information in the modern world, we propose to define PII to mean any information that is linked or linkable to an individual. Protecting personally identifiable information from breaches of confidentiality is a core value of most privacy regimes. We seek comment on our proposal.

40. Providing protection for PII as well as CPNI will benefit consumers, while having limited adverse impacts on BIAS providers, as both are types of information that customers reasonably expect their BIAS provider to keep secure and confidential. We expect that, for the most part, broadband providers already keep such information secure and treat it with some degree of confidentiality based on, among other things, FTC guidance that BIAS providers would have reasonably understood applied to them prior to the reclassification of broadband in the

2015 Open Internet Order.

We seek comment on whether there are other categories of information that should be treated as falling under Section 222(a) in the broadband context, and for which customers and providers expect protection. Are there any categories of information that are specific to the mobile BIAS context?

41. We also seek comment on whether we should harmonize the existing CPNI rules with our proposed rules for broadband providers by adopting one unified definition of customer PI, and on the benefits and burdens of such an approach. We recognize that because the Commission has not previously focused its attention on adopting rules defining the scope of information protected by Section 222(a), our existing Section 222 rules do not separately define customer PI. Are voice telecommunications providers' obligations to protect customer PI sufficiently clear, or would it be helpful to have a codified definition? Further, we observe that many telecommunications carriers also provide both voice and broadband services. Would a harmonized standard help reduce burdens for such companies, especially for small providers?

6. Defining Personally Identifiable Information

42. Protecting personally identifiable information is at the heart of most privacy regimes. We propose to define personally identifiable information, or PII, as any information that is linked or linkable to an individual. We recognize that, historically, legal definitions of PII adopted different approaches. Some incorporated checklists of specific types of information; others deferred to auditing controls. Advances in computer science, however, have demonstrated that seemingly anonymous information can often (and easily) be re-associated with identified individuals. Our proposal incorporates this modern understanding of data privacy, which is reflected in our recent enforcement actions, and tracks the FTC and National Institute of Standards and Technology (NIST) guidelines on PII. We propose to define PII broadly because of both the interrelated nature

of different types of personal information and the large risks posed by unauthorized uses and disclosures. We seek comment on our proposal.

43.

Linked and linkable information.

We propose that information is “linked” or “linkable” to an individual if it can be used on its own, in context, or in combination to identify an individual or to logically associate with other information about a specific individual. The “linked or linkable” standard for determining the metes and bounds of personally identifiable information is well established. In addition to NIST 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. We seek comment on our approach.

44. We propose to offer illustrative, non-exhaustive guidance regarding the types of data that are PII. In order to provide such guidance, we look to a number of sources, including our prior orders, NIST, the FTC, the White House's proposed Consumer Privacy Bill of Rights, and other federal and state statutes and regulations. We propose that types of PII include, but are not limited to: Name; Social Security number; date and place of birth; mother's maiden name; unique government identification numbers (

e.g.,

driver's license, passport, taxpayer identification); physical address; email address or other online contact information; phone numbers; MAC address or other unique device identifiers; IP addresses; persistent online identifiers (

e.g.,

unique cookies); eponymous and non-eponymous online identities; account numbers and other account information, including account login information; Internet browsing history; traffic statistics; application usage data; current or historical geo-location; financial information (

e.g.,

account numbers, credit or debit card numbers, credit history); shopping records; medical and health information; the fact of a disability and any additional information about a customer's disability; biometric information; education information; employment information; information relating to family members; race; religion; sexual identity or orientation; other demographic information; and information identifying personally owned property (

e.g.,

license plates, device serial numbers). We recognize and acknowledge that several of these data elements may overlap with our proposed interpretation of the terms of the CPNI definition. We seek comment on these examples and whether there are other categories of linked or linkable information that we should recognize.

45.

Other PII Considerations.

Consistent with a widespread understanding of what constitutes PII, we propose to consider a BIAS customer's name, postal address, and telephone number as PII and, consequently, that they are customer PI protected by Section 222(a) in the broadband context. We recognize that because of the unique history of telephone directory information, the Commission has previously treated such information as not falling within the statutory definition of CPNI in the voice telephony context. Indeed, the statutory definition of CPNI “does not include subscriber list information,” which the Act defines as information “(A) identifying the listed names of subscribers of a carrier and such subscribers' telephone numbers, addresses, or primary advertising classifications . . . and (B) that the carrier or an affiliate has published, caused to be published, or accepted for publication in any directory format.”

46. Unlike fixed voice providers in the 1990s, today's broadband providers do not publish directories of customer information. Even in the voice context, mobile providers have never published subscriber list information, and in the fixed context, customers have long had the option to request such customer information not be disclosed (

i.e.,

that the customer be “unlisted”), inherently recognizing the personal nature of such information. Further, by signing up for broadband service, customers do not think they are consenting to the public release of their name, postal address, and telephone number, none of which play the same role in the context of BIAS, as they do in the context of telephone service. As such, we propose that there is no subscriber list information in the broadband context, and therefore that BIAS customers' names, postal addresses, and telephone numbers should be treated as PII, and seek comment on our approach. We also seek comment on whether we should treat such information as CPNI. We also propose to harmonize our voice and broadband rules and treat such information as customer PI in the voice context, except where such information is published subscriber list information. We seek comment on this proposal. Do commenters agree that this approach is consistent with current customer expectations? What are the positive and negative ramifications from this proposal? Is there another approach we can take that will give consumers control over their personal information?

47. If we adopt rules harmonizing the privacy requirements of Sections 222, 631, and 338(i), how should we interpret the term “personally identifiable information” as used in Sections 631 and 338(i)? Should we use the same definition we propose here?

48. Finally, we seek comment on alternative approaches to defining PII. For example, instead of defining the term PII, what are the benefits and burdens of leaving that term undefined and simply providing guidance on what types of information qualify? What are the benefits and burdens any alternative approaches?

7. Content of Customer Communications

49. We seek comment on how we should define and treat the content of customer communications. The sensitivity and confidentiality of the content of personal communications is one of the oldest and most-established cornerstones of privacy law. Other federal and state laws, including the Electronic Communications Privacy Act (ECPA), the Communications Assistance for Law Enforcement Act (CALEA), and Section 705 of the Communications Act provide strong protections for the content of communications carried over broadband and public switched telephone networks. In light of the strong protections for the content of communications offered by other laws, we seek comment on how we should treat content under Section 222. As a threshold matter, should some or all forms of content should also be understood as customer PI under Section 222(a) or CPNI under Section 222(h)? What are the implications of considering content as being covered by Section 222(a) or (h), as well as by other relevant federal and state laws? We do not think that providers should ever use or share the content of communications that they carry on their network without having sought and received express, affirmative consent for the use and sharing of content. We therefore seek comment on whether there is a need to provide heightened privacy protections to content of communications beyond Section 705 and ECPA, and if there is, what additional protections should be provided. Given that Section 705 provides an additional basis for requiring heightened protections for content, should we consider regulations under Section 705? We invite commenters to address any legal authorities affecting commenters' conclusions regarding content, including relevant provisions of the

ECPA and Section 705 of the Communications Act.

8. Defining Opt-Out and Opt-In Approval

50. We propose to define the term “opt-out approval” as a method for obtaining customer consent to use, disclose, or permit access to the customer's proprietary information in which a customer is deemed to have consented to the use, disclosure, or access to the customer's covered information if the customer has failed to object thereto after the customer is provided appropriate notification of the BIAS provider's request for consent consistent with the proposed requirements set forth below in Section 64.7002 of the proposed rules. We base our proposal on the definition for “opt-out approval” in the Commission's existing CPNI rules. In the broadband context, we propose to expand the Commission's existing definition to encompass all customer PI (rather than limiting it to CPNI), and eliminate the existing 30-day waiting period currently required to make a voice customer's opt-out approval effective, as the existing definition of opt-out approval for voice providers requires. We believe that, given our proposed requirements that customers must be able to opt out at any time and with minimal effort, a 30-day period may prove more cumbersome than a customer's rapid expressions of preference. Since BIAS providers come into contact with many types of customer PI beyond CPNI in their provision of broadband services, we think it appropriate under Section 222(a) to include all customer PI so that customers can exercise more control over the use and sharing of all their private information.

51. We propose to define the term “opt-in approval” as a method for obtaining customer consent to use, disclose, or permit access to the customer's proprietary information that requires that the BIAS provider obtain from the customer affirmative, express consent allowing the requested usage, disclosure, or access to the covered information after the customer is provided appropriate notification of the provider's request consistent with the requirements set forth below in Section 64.7002 of the proposed rules and before any use of, disclosure of, or access to such information. We base our proposal on the definition for “opt-in approval” in the Commission's existing CPNI rules for voice providers.

52. We seek comment on these proposed definitions, and more specifically, whether there any changes to them that can be made to (1) adapt them more appropriately to the BIAS context, or (2) provide additional clarity for consumers and providers alike. We seek comment on alternative approaches to defining these terms. We invite commenters to offer real-world examples of choice-mechanisms and discuss whether they would satisfy these definitions.

9. Defining Communications-Related Services and Related Terms

53. We seek comment on how best to define “communications-related services” for purposes of our proposal to allow BIAS providers to use customer PI to market communications-related services to their subscribers, and to disclose customer PI to their communications-related affiliates for the purpose of marketing communications-related services subject to opt-out approval. Should we limit communications-related services to telecommunications, cable, and satellite services regulated by the Commission? If so, how should we treat services that compete directly with services that are subject to Commission jurisdiction? Alternatively, should we delineate other types of services that we would consider communications-related?

54. The current Section 222 rules define communications-related services to mean “telecommunications services, information services typically provided by telecommunications carriers, and services related to the provision or maintenance of customer premises equipment.” The current Section 222 rules define “information services typically provided by telecommunications carriers” to mean information services as defined in the Communication Act of 1934, as amended, that are typically provided by telecommunications carriers, such as Internet access or voice mail services. The definition further specifies that “such phrase `information services typically provided by telecommunications carriers,' as used in this subpart, shall not include retail consumer services provided using Internet Web sites (such as travel reservation services or mortgage lending services), whether or not such services may otherwise be considered to be information services.” If used in the BIAS context the combination of those definitions would include a broad array of services. We are not inclined to adopt such an expansive reading of “communications-related services,” so we seek comment on how we might amend the current definitions to narrow the scope of services we would treat as “communications-related services” in the broadband context. We also seek comment on how we can best limit the definitions of “communications-related services” and, if necessary, “information services typically provided by a telecommunications provider” to align with consumer expectations about the extent to which BIAS providers use and share customer PI with communications-related affiliates.

55. Even if we adopt a narrower definition of communications-related services for purposes of the BIAS rules, we propose to amend the definition of “information services typically provided by telecommunications carriers” for purposes of the voice rules, in light of the reclassification of broadband Internet access service as a telecommunications service in the

2015 Open Internet Order,

and to align with current consumer expectations about the extent to which telecommunications carriers (other than BIAS providers) use and share customer PI with communications-related affiliates for purposes of marketing communications-related services. Should we harmonize the meaning of “communications-related services” across BIAS and other telecommunications services? Relatedly, we seek comment on what constitutes “marketing” for the purposes of this proposed rule.

10. Defining Aggregate Customer PI

56. We propose to define aggregate customer proprietary information as collective data that relates to a group or category of services or customers, from which individual customer identities and characteristics have been removed. We observe that our proposed definition for “aggregate customer proprietary information” mirrors the statutory definition for the term “aggregate customer information” in Section 222(h)(2). We use slightly different terminology to make clear that our proposed rules addressing the use of aggregate customer information are intended to address the use of all aggregate customer PI and not just aggregate CPNI. We seek comment on our proposal. Are there any reasons we should restrict our definition to include only aggregate CPNI, or alternatively, to mirror the statute's terminology of “aggregate customer information”? Do any additional security concerns arise from the use of aggregate customer PI, in the fixed or mobile context, that would not arise if our definition were restricted to including only CPNI? Would adopting the statutory term “aggregate customer information” lead to any enforcement concerns regarding what information is covered? Should our proposed definition of aggregate

customer PI apply to both voice telephony and BIAS services? Are there any reasons that the same definition of aggregate customer PI should not be used for both of these types of services?

11. Defining Breach

57. For purposes of our proposed data breach notification requirements, we propose to define “breach” as any instance in which “a person, without authorization or exceeding authorization, has gained access to, used, or disclosed customer proprietary information.” Unlike the “breach” definition in our current Section 222 rules, our proposal does not include an intent element, and it covers all customer PI, not just CPNI. In defining breach we also look to state data breach notification laws, many of which do not include an intent requirement. We seek comment on this approach.

58. Not including a requirement that the unauthorized access be intentional in the definition of “breach” will ensure data breach notification in the case of inadvertent breaches that have potentially negative consequences for customers. We seek comment on this approach. Do commenters believe it is appropriate to require customer notification of all breaches, whether inadvertent or intentional? What are the burdens and benefits associated with this proposal? Should we retain the intentionality requirement in certain contexts? If so, what contexts and why? State statutes often include a provision exempting from the definition of breach a good-faith acquisition of covered data by an employee or agent of the company where such information is not used improperly or further disclosed. Should we include such an exemption in our definition of “breach” or is such a provision unnecessary or otherwise unadvisable? Are there any alternative proposals we should consider for the definition of breach?

59. We propose to include customer PI within the definition of breach, which will have the effect of applying our data breach notification requirements to breaches of customer proprietary information. Although CPNI covers many categories of confidential information, we believe that it is equally important that customers, the Commission, and other law enforcement (in certain circumstances) receive notice of a breach of other customer PI from or about the customer. Section 222(a) requires carriers to protect the confidentiality of “proprietary information” of and relating to customers. As such, we believe we have authority to extend our proposed breach reporting requirements to breaches of all customer PI, to ensure that customers receive critical protection for this broader subset of information. We seek comment on our proposal and on our authority to require breach reporting for breaches of all customer PI. What are the burdens and benefits of our proposed expansion of our requirements? How will our proposal affect small businesses?

12. Other Definitions

60. We seek comment on whether there are other terms we should define as part of adopting rules to protect the privacy of BIAS customers' proprietary information, or voice telecommunications definitions that we should revise in light of our proposals today.

61. For example, the existing CPNI rules define the term “customer premises equipment” (CPE) to mean “equipment employed on the premises of a person (other than a carrier) to originate, route, or terminate telecommunications.” We seek comment whether we should adopt this definition for purposes of the proposed broadband privacy rules. What would be the scope of covered devices under the statutory definition or any alternatives? Would “premises of a person” include Internet-connected devices carried outside one's home or office? With large numbers of consumer products becoming networked devices (

e.g.,

thermostats, cars, home appliances, and others), are there particular types of uses, activities, or devices that operate over broadband Internet access service that we should or should not include within the definition of CPE? Are there other terms the Commission should define for the broadband privacy context?

62. We also seek comment on whether there are any other terms from the existing CPNI rules that we need to revise, either to differentiate them or to harmonize them with our proposed broadband privacy rules, and to address the existing forbearance for BIAS. We propose to revise the existing rules to make clear that they apply only to telecommunications services other than BIAS, by revising the definition of “telecommunications carrier” to exclude a provider of BIAS for purposes of the existing rules. We seek comment on this approach, as well as alternative approaches for doing so. Are any other changes to the definitions necessary to preserve the existing voice CPNI rules following the reclassification of broadband Internet access service? What are the benefits and burdens of updating or not updating any of these definitions, particularly for small providers? With regard to all of the current definitions, should we merely update them and keep them applicable solely to voice services, or should we craft one uniform set of definitions for both voice and broadband CPNI? Is there any reason not to harmonize these or other definitions as applied to voice and broadband providers? What are the benefits and burdens of harmonizing versus not harmonizing the definitions, particularly for small providers?

63. We recognize that if we do update any definitions, we may need to revise other aspects of the current CPNI rules to align with any revised definitions. Likewise, if we revise any of the current substantive rules we may need to revise additional definitions. Below, we seek comment on harmonizing the current rules with our proposed rules. Here we also seek comment on what other provisions of the current CPNI rules we should revise and why. For example, our current rules permit wireless providers to “use, disclose, or permit access to CPNI derived from its provision of CMRS, without customer approval, for the provision of CPE and information service(s).” At the time of adoption, BIAS was classified as an “information service,” and as such, this rule was intended to cover such services. We seek comment on how we should revise this rule to reflect our reclassification of BIAS as a telecommunications service.

B. Providing Meaningful Notice of Privacy Policies

64. Transparency is one of the core fair information practice principles. Indeed, there is widespread agreement that companies should provide customers with clear, conspicuous, and understandable information about their privacy practices. There is also widespread agreement about the challenge of providing useful and accessible privacy disclosures to consumers. In recognition of the importance of transparency, we propose rules requiring BIAS providers to provide customers with clear and conspicuous notice of their privacy practices at the point of sale and on an on-going basis through a link on the provider's homepage, mobile application, and any functional equivalent. In order to ensure customers have the information they need about BIAS providers' privacy practices, we propose to provide specific direction about what information must be provided in BIAS providers' privacy notices, and we propose to require BIAS providers to provide existing customers with advanced notice of material changes in their privacy policies. To

ensure that the information that BIAS providers provide about their privacy policies is accessible to consumers, we seek comment on standardizing the formatting of broadband privacy notices and of notices regarding material changes to privacy policies. We also seek comment on ways to harmonize our proposed notice requirements with privacy notice requirements for providers of voice and video services.

1. Privacy Notice Requirements

65. In proposing specific disclosure requirements for BIAS providers' privacy and security policies, we look to the Commission's open Internet transparency rule and the existing notice obligations for traditional telecommunications carriers under Section 64.2008 of the Commission's rules, as well as the notice provisions of the Cable Privacy Act. We also look to the California Online Privacy Protection Act, which establishes privacy policy requirements for online services, and to numerous best practices regimes, including those proposed by the FTC and the National Telecommunications and Information Administration (NTIA). We also find various trade association recommendations informative, including those adopted by the Digital Advertising Alliance and the Network Advertising Initiative. In so doing, we propose rules that would impose the following notice requirements with respect to BIAS providers' privacy policies:

•

Types of Customer PI Collected and How They Are Used and Disclosed.

The notice must specify and describe:

○ The types of customer PI that the BIAS provider collects by virtue of its provision of broadband service;

○ How the BIAS provider uses, and under what circumstances it discloses, each type of customer PI that it collects; and

○ The categories of entities that will receive the customer PI from the BIAS provider and the purposes for which the customer PI will be used by each category of entities.

•

Customers' Rights With Respect to Their PI.

The notice must:

○ Advise customers of their opt-in and opt-out rights with respect to their own PI, and provide access to a simple, easy-to-access method for customers to provide or withdraw consent to use, disclose, or provide access to customer PI for purposes other than the provision of broadband services. Such method shall be persistently available and made available at no additional cost to the customer.

○ Explain that a denial of approval to use, disclose, or permit access to customer PI for purposes other than providing BIAS will not affect the provision of any services to which the customer subscribes. However, the provider may provide a brief description, in clear and neutral language, describing any consequences directly resulting from the lack of access to the customer PI.

○ Explain that any approval, denial, or withdrawal of approval for the use of the customer PI for any purposes other than providing BIAS is valid until the customer affirmatively revokes such approval or denial, and inform the customer of his or her right to deny or withdraw access to such PI at any time. However, the notification must also explain that the provider may be compelled to disclose a customer's PI, when such disclosure is provided for by other laws.

•

Requirements Intended to Increase Transparency of Privacy Notices.

To ensure customers can understand BIAS privacy notices, such notices must:

○ Be comprehensible and not misleading;

○ Be clearly legible, use sufficiently large type, and be displayed in an area so as to be readily apparent to the customer; and

○ Be completely translated into another language if any portion of the notice is translated into that language.

•

Timing of Notice.

To ensure customers receive timely and persistent notice of a BIAS provider's privacy policies, the notice must:

○ Be made available to prospective customers at the point of sale, prior to the purchase of BIAS, whether such purchase is being made in person, online, over the telephone, or via some other means;

○ Be made persistently available:

Via a link on the BIAS provider's homepage;

Through the BIAS provider's mobile application; and

Through any functional equivalent to the provider's homepage or mobile application.

66. We seek comment on these proposed notice requirements. To what extent are these practices already being followed by some or most BIAS providers? To what extent are these practices consistent with the best practices of other industries? Will the proposed requirements provide BIAS customers with (1) clear and adequate notice of their BIAS provider's privacy policies, and (2) sufficient information to enable them to make informed decisions about their use and purchase of BIAS services? Will the proposed requirements ensure that BIAS customers receive sufficient information to give them confidence that their broadband provider is protecting the confidentiality of their proprietary information and providing them with sufficient ability to decide whether and when to opt in to the sharing of data with third parties? Are there additional specific requirements that we should adopt so that privacy policy information is accessible to customers with a disability, such as, for example, a link to a video of the notice conveyed in American Sign Language (ASL)?

67.

Required Disclosures.

We seek comment whether there are other types of information that we should require BIAS providers to include in the notices of their privacy policies, or if there are any categories of information we propose including that should not be required. For example, should we require BIAS providers to provide customers with information concerning their data security practices or their policies concerning the retention and deletion of customer PI? Further, to the extent that we determine that the content of customer communications is covered by the transparency requirements we propose to adopt, how can we ensure that customers have adequate notice concerning how BIAS providers treat such information? In addition, would it be technically and/or practically feasible to require that BIAS providers provide consumers with notice of the specific entities with which they intend to share their customer PI, rather than the categories of entities, as we propose above? We note that California's Shine the Light law requires businesses, upon request, to provide to their customers, free of charge and within 30 days: (1) A list of the categories of personal information disclosed by the business to third parties for the third parties' marketing purposes; (2) the names and addresses of all the third parties that received personal information from the business in the preceding calendar year; and (3) if the nature of the third parties' business cannot be reasonably determined by the third parties' name, examples of the products or services marketed by the third party. We seek comment on whether we should adopt a similar requirement. Would such a requirement place too onerous a burden on BIAS providers? What are the estimated costs of compliance associated with such a requirement, if any? Are these costs outweighed by the potential benefit to customers of disclosing this information?

68. Although our current Section 222 rules do not require voice providers to have privacy notices, many of the categories of information we propose to

require in BIAS providers' privacy notices are required as part of the current Section 222 requirements for notice before seeking approval for using or sharing CPNI. We seek comment from providers and other stakeholders on their experience with privacy disclosures in that context and on how those experiences should inform the privacy notice rules we propose to adopt for BIAS providers.

69.

Timing and Placement of Privacy Notices.

We seek comment on our proposal regarding the timing and placement of privacy notices. We believe that by requiring point-of-sale notices and requiring that notices of a BIAS provider's privacy policies be persistently available through a link on the provider's homepage and through its mobile application, gives providers two existing, user-friendly avenues for providing customers with notice of their privacy policies, while also leaving open a technology-neutral, “functional equivalent” option in the event that future innovations in technology offer new and innovative ways to provide customers with transparency. Do commenters agree? Are homepages and mobile applications two platforms through which customers are likely to interface with privacy policies? Are there any other times and points at which providers should provide customers with notice of their privacy practices, other than those we discuss above? If so, how should such notice be delivered? Should it be provided through email or another agreed-upon means of electronic communication, or should it perhaps be included regularly on customers' bills for BIAS? What would be the cost of compliance, if any, of supplying customers with privacy practice notifications via email or as part of the customer's regular bill? Are there technical means of conveying privacy notices that we might adopt?

70. Some rules and laws require annual or bi-annual notification of privacy rights. The Commission's existing voice notification rules require carriers using the opt-out mechanism to provide notices to their customers every two years. Because we require BIAS providers to have easy-to-access links to their privacy notices that are persistently available on their homepage, through their mobile applications, and through any functional equivalent, we do not think it is a good use of resources to require BIAS providers to periodically provide their privacy notices to their customers. We invite comment on that approach. When customers receive regular privacy notices, do they typically review and understand such annual notices? Do customers typically take any action in regard to such notices? Would the administrative costs of providing such annual notices outweigh the benefits to the customer of receiving annual notices? If we do adopt a regular privacy notice requirement, how should the notice be sent to BIAS customers? Would email notice to the customer's email address of record be sufficient? Should we require that any such annual notices be sent by mail to the address of record? Is there another, more effective way of providing annual notices to BIAS customers?

71.

Compliance Burden.

We seek comment on the burdens associated with complying with our proposed privacy notice framework for BIAS providers. What are the estimated costs of compliance, if any, that this notice framework will impose on providers, given that they are already obligated to provide notice of their privacy policies to customers under the open Internet transparency rule? We believe that the benefits to customer privacy of providing end users, edge providers, and the general public with meaningful information about the privacy policies of BIAS providers outweigh the administrative and regulatory costs of the proposed notice requirements. We seek comment on this conclusion. Are there any alternatives that would reduce the burdens on BIAS providers, particularly small providers, while still ensuring that BIAS providers' privacy practices are sufficiently transparent?

72.

Standardization of Privacy Notices.

We also seek comment on whether BIAS providers' privacy policy notices should be standardized to enable better comprehension and comparison of privacy practices by customers and to reduce the burden of regulatory compliance on BIAS providers. There is broad recognition of the importance of simplifying and standardizing privacy notices to make them more accessible to consumers. In its 2012 Privacy Report, for example, the FTC recognized that privacy policies in different industries would need to reflect those differences, but called for the standardization of some elements of privacy policies, including formatting and terminology “to allow consumers to compare the privacy practices of different companies and to encourage companies to compete on privacy.” The following year, NTIA released a voluntary code of conduct detailing a uniform set of guidelines for mobile application providers to use in crafting short form privacy notices. In drafting the code, NTIA acknowledged that the “transparency created by displaying information about application practices in a consistent way . . . is intended to help consumers compare and contrast data practices of apps.”

73. We seek comment on whether we should adopt a standardized approach for BIAS providers' privacy notices in this proceeding. Would a one-size-fits-all approach provide clear, conspicuous, and understandable information? Are there models we should look to in crafting our privacy notice requirements? For example, in the

2015 Open Internet Order,

we directed the Consumer Advisory Committee (CAC), composed of both industry and consumer interests, to formulate and submit to the Commission a proposed consumer-facing disclosure for purposes of complying with the transparency rule. Should we follow a similar approach? In a recent study of online privacy notices, researchers at Carnegie Mellon University found that certain, specific discrepancies exist between companies' actual privacy practices and users' expectations of how their information is being used or shared. The study concluded by suggesting that companies could develop shorter, user-facing privacy notices that specifically emphasize those practices where mismatches exist between a company's actual use and disclosure policies and consumers' expectations. By using models of people's privacy expectations, the study's authors suggest that companies could selectively highlight or display those elements of privacy policies that are likely to be most relevant to users. We seek comment on whether we should use such a model in developing a standardized template for privacy notices. Would such a model, or one similar to it, lessen the burden on providers of providing privacy notices while also ensuring that customers are kept adequately informed as to how their BIAS providers use and share their information? Or, should we consider multiple but structurally similar privacy policy disclosures?

74. In addition, we seek comment on whether such a standardized disclosure should be adopted as a voluntary safe harbor for any adopted privacy notice requirements. Would a safe harbor ease the regulatory burden on BIAS providers, particularly small providers? How could we ensure that a notice provided under such a safe harbor provision still allows consumers adequate opportunity to consider and comprehend the privacy policies of their respective BIAS providers?

75. We recognize that not all privacy policies may conform to a uniform template. Is there a risk that using a uniform template for privacy notices may result in the omission of crucial

information and ensuing consumer confusion or mistake? What is the best way to ensure that BIAS providers are able to convey this privacy policy information in accessible formats, like ASL? Are more general guidelines that allow for flexibility preferable to the creation of a uniform template? Should we, for example, look to the model code of conduct for mobile application short-form privacy notices that came out of the multi-stakeholder process convened by the NTIA at the Department of Commerce in 2012 and 2013? If so, what elements from that model will work well in the BIAS context and which will need to be adjusted?

76. Are there other approaches we can take to simplifying privacy notices? For example, should we require a layered privacy notice that includes a plain-language disclosure policy in addition to a more in-depth disclosure? If so, what should go into the different layers of such privacy notices?

77. In addition to simplifying and standardizing privacy notices, we seek comment on whether we should take further steps to ensure (1) that customers have access to sufficient information regarding their BIAS provider's privacy policies, and (2) that such information is presented in a form that is both palatable and easily comprehensible for customers. In particular, we seek comment on whether the Commission should require BIAS providers to create a consumer-facing privacy dashboard that would allow customers to: (1) See the types and categories of customer PI collected by BIAS providers; (2) see the categories of entities with whom that customer PI is shared; (3) grant or deny approval for the use or disclosure of customer PI; (4) see what privacy selection the customer has made (

i.e.,

whether the customer has chosen to opt in, opt out, or take no action at all with regards to the use or disclosure of her PI), and the consequences of this selection, including a description of what types and categories of customer PI may or may not be used or disclosed by a provider depending on the customer's privacy selection; (5) request correction of inaccurate customer PI; and (6) request deletion of any categories of customer PI that the customer no longer wants the BIAS provider to maintain (

e.g.,

online activity data), so long as such data is not necessary to provide the underlying broadband service or needed for purposes of law enforcement. We seek comment on the costs and benefits of requiring the creation of such a dashboard, and any alternatives the Commission should consider to minimize the burdens of such a program on small providers.

2. Providing Notice of Material Changes in BIAS Providers' Privacy Policies

78. In order to ensure that BIAS customers are fully informed of their providers' privacy policies, and can exercise informed decisions about consenting to the use or sharing of customer PI, we propose to require BIAS providers to (1) notify their existing customers in advance of any material changes in the BIAS provider's privacy policies, and (2) include specific types of information within these notices of material changes. Our proposal is consistent with, but more extensive than, the requirement we adopted in the

2015 Open Internet Order

that BIAS providers update the disclosure of their network practices, performance characteristics, and commercial terms (including privacy practices) whenever there is a material change in that disclosure. More specifically, we propose that a notice of material changes must:

• Be clearly and conspicuously provided through (1) email or another electronic means of communication agreed upon by the customer and BIAS provider, (2) on customers' bills for BIAS, and (3) via a link on the BIAS provider's homepage, mobile application, and any functional equivalent.

• Provide a clear, conspicuous, and comprehensible explanation of:

○ The changes made to the BIAS provider's privacy policies, including any changes to what customer PI the BIAS provider collects, and how it uses, discloses, or permits access to such information;

○ The extent to which the customer has a right to disapprove such uses, disclosures, or access to such information and to deny or withdraw access to the customer PI at any time; and

○ The precise steps the customer must take in order to grant or deny access to the customer's PI. The notice must clearly explain that a denial of approval will not affect the provision of any services to which the customer subscribes. However, the provider may provide a brief statement, in clear and neutral language, describing consequences directly resulting from the lack of access to the customer's PI. If accurate, a provider may also explain in the notice that the customer's approval to use the customer's PI may enhance the provider's ability to offer products and services tailored to the customer's needs.

• Explain that any approval or denial of approval for the use of customer PI for purposes other than providing BIAS is valid until the customer affirmatively revokes such approval or denial.

• Be comprehensible and not misleading.

• Be clearly legible, use sufficiently large type, and be placed in an area so as to be readily apparent to customers.

• Have all portions of the notice translated into another language if any portion of the notice is translated into that language.

79. We seek comment on our proposal. In particular, we seek comment on whether the elements and disclosures that we propose to require as part of the notification of material changes are sufficient to provide customers with adequate and comprehensible notice of any material changes in their BIAS providers' privacy policies. Are there any additional disclosures not included in this proposed framework that might be helpful to consumers? Are any of the proposed requirements unnecessary or potentially unhelpful to consumers? Should we require that the notification triggered by this proposed provision occur within a specified timeframe in advance of the effectiveness of the provider's material change? If so, what is an appropriate timeframe during which BIAS providers should provide the notification? The

2015 Open Internet Order

defined a “material” change as “any change that a reasonable consumer or edge provider would consider important to their decisions on their choice of provider, service, or application.” Do we need to update this definition to more clearly address privacy concerns raised by material changes?

80. Our proposal is consistent with industry guidelines and other standards regarding customer notice of material changes to privacy policies. Our proposed rules build on these existing regulatory frameworks and our own existing material change disclosure requirement in an attempt to ensure that customers receive proper notice of any material changes in their BIAS providers' privacy policies that may affect how those customers' PI is used or disseminated,

before

such material changes are made. We believe that by requiring BIAS providers to furnish their customers with advance notice of material changes to their privacy policies, our proposed requirement will help to ensure that the manner in which customer PI is being used and disclosed will remain transparent to customers, and will also enable customers to make informed decisions about whether to

approve or disapprove any new uses or disclosures of their PI.

81. We believe that our proposal will also help to ensure that BIAS providers cannot materially alter their privacy practices and use or share customer PI in a way in which customers may not approve or may not envision prior to customers even being made aware of such an alteration in the first place. Further, our proposed requirements that notices of material changes be clearly legible, placed in an area so as to be readily apparent to customers, and be provided through email or another electronic means of communication agreed upon by the customer and BIAS provider—as well as on customers' bills for BIAS services and through a link on the BIAS provider's homepage, mobile app, and any functional equivalent—will help ensure that customers have ample opportunity to learn of any material changes in their BIAS providers' privacy practices. This will also have the added benefit of informing interested members of the public, including privacy advocates, of any such material changes.

82. We are particularly concerned about material changes to privacy policies that BIAS providers seek to make retroactive. Our sister agency, the FTC, has also long held as a “bedrock principle” that companies should obtain affirmative express consent before making material retroactive changes to their privacy policies. This principle is echoed in the Organization for Economic Cooperation and Development's privacy guidelines, which require that data controllers specify the purpose of data use whenever those purposes change. We seek comment on whether our proposed rules are sufficient to ensure that providers seeking to retroactively change their privacy policies obtain consent to any new or newly disclosed use or sharing of customer PI, and that they honor consumers' decisions.

83. Finally, we seek comment on the burden that our proposed material change notice requirements will place on BIAS providers, particularly small providers. What are the estimated costs of compliance, if any, that this framework will impose on BIAS providers? Is there any way to modify our proposed material change rules so as to lessen the burden of these requirements on small providers while still achieving the Commission's stated goals of increasing transparency in the BIAS market and keeping consumers well-informed of their BIAS providers' privacy practices?

3. Mobile-Specific Considerations

84. As a general matter, we do not see a justification for treating fixed and mobile BIAS differently. However, we understand that there are fundamental differences between the two technologies: Specifically, their mobility. We therefore seek comment on whether there are any mobile-specific considerations to the notice requirements we have proposed above. Given the increasing ubiquity of mobile devices in today's society, we recognize that many consumers may utilize BIAS via a mobile platform—some to the exclusion of fixed devices. We seek comment on the technical feasibility of our proposed notice requirements for mobile BIAS providers. Are there any practical difficulties for providers of mobile BIAS in providing customers with adequate notice? For instance, are there any ways in which our existing and proposed notice requirements can or should be tailored to the unique characteristics of mobile services and smaller screens? Are our existing and proposed methods of notice adequate to ensure that mobile customers, specifically, are kept well-informed of their providers' respective privacy policies, as well as any material changes to such policies? What other types of notice, if any, should be required, specific to mobile BIAS providers? Is there any reason to hold mobile BIAS providers to different notice requirements, or should they be obligated to comply with the same framework as non-mobile BIAS providers? Why or why not? How would any such mobile-specific requirements benefit users of mobile BIAS? What would be the effect, if any, on broadband competition from having a different set of notice requirements applicable to mobile versus fixed BIAS providers?

4. Harmonizing Notices for Voice, Video, and Broadband Services

85. We seek comment on whether the Commission should harmonize required privacy notices regarding the use of customer information for voice, video, and broadband services. Section 64.2008 of the Commission's rules requires telecommunications carriers to provide individual notice to customers when soliciting approval to use, disclose, or permit access to customers' CPNI. Additionally, Sections 631 and 338(i) of the Act require cable operators and satellite carriers to provide notice to their subscribers of the collection, use, and disclosure of subscribers' personally identifiable information. This notice must be provided at the point of sale and at least once a year thereafter. We seek comment on the best way to harmonize privacy notice requirements for providers of voice, video, and broadband Internet access services.

86. We observe that in today's market of bundled communications services, many voice, broadband, and video providers offer multiple services. Indeed, many companies currently offer double or triple play packages that typically include both BIAS and video services, or BIAS, video, and voice services, respectively. In a variety of proceedings, the Commission has recognized the nexus between providing broadband and “triple play” packages that include other services such as video programming, and we have acknowledged that “ `a provider's ability to offer video service and to deploy broadband networks are linked intrinsically, and the federal goals of enhanced cable competition and rapid broadband deployment are interrelated.' ” In light of the pre-existing notice requirements for providers of voice and video services, we seek comment on how we can minimize the burden of the notification processes proposed in this NPRM on BIAS providers.

87. We observe that some BIAS providers already provide one privacy notice for all of their bundled services on their Web sites. Given that many providers are already providing a single notice of their privacy policies on their Web sites to all their voice, video, and BIAS customers, we seek comment on whether harmonizing the privacy notice requirements for these various types of services could lessen the burden imposed on providers. More specifically, if a BIAS provider also provides privacy notices to customers under our voice rules and/or cable and satellite statutory requirements, should we allow that provider to combine the notices so that their customers only receive one notice as opposed to two or three? Should we reconcile the types of information that are required to be in consumer privacy notices across voice, video, and broadband Internet access platforms so that a provider of these services need only send a single notice to customers regarding its privacy practices? Is combining such notices likely to confuse customers? Will requiring separate privacy notices for voice, video, and broadband Internet access services be more easily understood by customers? Do the administrative costs of providing separate notices under the proposed rules as well as our voice and video rules outweigh any benefits to

consumers of receiving these notices separately?

C. Customer Approval Requirements for the Use and Disclosure of Customer PI

88. In this section, we propose a framework that empowers customers to make informed decisions about the extent to which they will allow their BIAS providers to use, disclose, or permit access to customer proprietary information for purposes other than providing BIAS. Choice is a critical component of protecting the confidentiality of customer proprietary information. When armed with clear, truthful, and complete notice of how their information is being used, customers can still only protect their privacy if they have the ability to exercise their privacy choices in a meaningful way. Empowering customers with control over their information does not, however, mean prohibiting all uses of their information, or bombarding them with constant solicitations for approval. BIAS providers may make many beneficial uses and disclosures of customer PI, and we do not propose to prevent these, so long as customers can exercise their choice in the matter. We therefore offer a proposed consumer choice framework that allows BIAS providers to engage in certain necessary and beneficial uses and sharing of information without the need for additional customer approval (such as providing service itself, or facilitating emergency response to 911 calls), as well as an efficient means of facilitating customer decisions regarding BIAS provider use and sharing of customer PI.

89. We begin this section by addressing the types of customer approval we propose to require for BIAS providers to use customer PI, and for BIAS providers to disclose customer PI to their affiliates and third parties. Section 222 and our current CPNI rules provide different levels of customer approval depending on the type of uses and the user, and we propose to do the same here. Specifically, we propose to require BIAS providers to give a customer the opportunity to opt out of the use or sharing of her customer PI prior to the BIAS provider (1) using the customer's PI to market other communications-related services to the customer; or (2) sharing the customer's PI with affiliates that provide communications-related services, in order to market those communications-related services to the customer. We also propose to require BIAS providers to solicit and receive opt-in approval from a customer before using customer PI for other purposes and before disclosing customer PI to (1) affiliates that do not provide communications-related services and (2) all non-affiliate third parties. We also seek comment on other approaches to seeking customer approval.

90. Second, we propose and seek comment on when BIAS providers should notify customers of their opportunities to approve or disapprove the use or disclosure of their information; the forms that such notification and solicitation should take, including how customers should be able to exercise their approval or disapproval; and how and when customers' choices take effect. Third, we propose and seek comment on how BIAS providers should document their compliance with the proposed rules. Fourth, we seek comment on the applicability of these proposals to small BIAS providers. Fifth, recognizing that the framework proposed here differs from the current framework in place for voice providers, we seek comment on whether we should harmonize the two frameworks, or otherwise revise and modernize the existing voice framework. We also seek comment on harmonizing the approval requirements for cable and satellite providers under Sections 631 and 338(i) of the Act with those we propose for BIAS providers.

1. Types of Approval Required for Use and Disclosure of Customer PI

91. In this section, we propose rules addressing the type of customer approval required for the use and sharing of customer PI. Customers' privacy is affected differently depending upon the entity using or accessing their private information and the purposes for which that information is being used. Each of these factors can independently affect the privacy impact of a given practice. For instance, customers who would not object to their BIAS provider using information about their bandwidth use to market a different monthly plan may object to that same information being disclosed to third parties. Meanwhile, customers may object even to uses of the same information for unexpected purposes, such as marketing wholly unrelated services to the customer. We therefore propose a framework to take these factors into account. We welcome comment on this approach.

92. Below, we first address uses and disclosure that do not require approval, or for which we propose to treat customer approval as implied. We then address the circumstances under which we propose to require customer opt-out and opt-in approval for the use and disclosure of customer PI. Finally, we seek comment on alternative frameworks for customer choice.

a. Permissible Uses and Disclosures of Customer PI for Which Customer Approval Is Implied or Unnecessary

93. In this section, we seek comment on how to implement Section 222(c)(1)'s direction that broadband providers may use, disclose, or permit access to individually identifiable CPNI without customer approval in their provision of BIAS or “services necessary to, or used in, the provision” of BIAS. We also propose to implement the goals of the statutory exceptions found in Section 222(d)—which permit BIAS providers to use, disclose, or permit access to CPNI without customer approval in specifically enumerated circumstances—to all customer PI in the broadband context, and below, propose rules that adapt those provisions to BIAS. We believe that our proposed implementation of these provisions in the broadband context is consistent with customer expectations, necessary for the efficient delivery of BIAS, and essential to allow emergency and law enforcement personnel to respond quickly and effectively during those times when their services are needed the most.

94.

Services for Which Consent to the Use of Customer PI Is Implied.

Section 222(c)(1) permits a BIAS provider to “use, disclose, or permit access to individually identifiable [CPNI] in its provision of (A) the telecommunications service from which such information is derived, or (B) services necessary to, or used in, the provision of such telecommunications service.” We seek comment on how to apply this in the broadband context. In particular, how should we interpret the scope of activities that are “in the provision” of BIAS? We also seek comment on how we should interpret the clause “services necessary to, or used in, the provision” of broadband service in the BIAS context.

95. We propose to allow BIAS providers to use any customer PI, and not only CPNI, for the purpose of providing BIAS or services necessary to, or used in, the provision of BIAS. Is such a permissive expansion consistent with Congress' direction that telecommunications carriers “protect the confidentiality of proprietary information of, and relating to . . . customers”? Why or why not? Is it necessary for BIAS providers to use customer PI other than CPNI to provide BIAS? We also note that Section 222(c)(1) does not restrict uses or disclosures of CPNI that are “required by law,” and seek comment whether our

rules need to explicitly recognize that BIAS providers may disclose any customer PI as required by law, including information that is not specifically CPNI.

96. We also propose to adopt rules permitting BIAS providers to use customer PI for the purpose of marketing additional BIAS offerings in the same category of service (

e.g.,

fixed or mobile BIAS) to the customer, when the customer already subscribes to that category of service from the same provider without providing the opportunity to provide opt-out or opt-in consent. We observe that the current Section 222 rules permit carriers to “use, disclose, or permit access to CPNI for the purpose of . . . marketing service offerings among the categories of service (

i.e.,

local, interexchange, and commercial mobile radio service (CMRS)) to which the customer already subscribes from the same carrier, without customer approval.” Given the additional types of customer PI and CPNI available to BIAS providers today, and the ways such information may impact the privacy of customers, will permitting BIAS providers to use customer PI for their own BIAS marketing purposes without explicit customer approval adequately protect customer privacy in the broadband context? Are there some forms of customer PI that a BIAS provider should not be permitted to use in this context without receiving additional consent from its subscribers? As discussed above, if we find that Section 222 provides protections for the content of communications, we think that use of content should be subject to heightened approval requirements. What sort of requirements should we apply to a provider's use of content for purposes of marketing BIAS to an existing BIAS customer? We also seek comment whether (1) permitting broadband providers to use customer PI to market broadband services to the customers in this manner is within the bounds of authority contemplated by the statute, and (2) whether we should revise our existing Section 222 rules to limit the exception to “use” of CPNI, or otherwise revise our rules.

97.

Statutory Exceptions.

Under Section 222(d) of the Act, providers may use, disclose, or permit access to CPNI, without customer notice or approval, to: (1) Initiate, render, bill, and collect for broadband services; (2) protect the rights or property of the provider, or to protect users and other providers from fraudulent, abusive, or unlawful use of, or subscription to, broadband services; (3) provide any inbound telemarketing, referral, or administrative services to the customer for the duration of a call, if such call was initiated by the customer and the customer approves of the use of such information to provide service; and (4) provide call location information concerning the user of a commercial mobile radio service or an IP-enabled voice service in certain specified emergency situations. We propose to adopt these exceptions, tailored to the broadband context, to the use or disclosure of all customer PI. We seek comment on our proposal and on potential alternatives.

98. Section 222(d)(4) permits providers to use and disclose CPNI to provide “call location information” concerning the user of a commercial mobile service for public safety. We believe that the critical public safety purposes that underlie this provision counsel in favor of applying a similar rule in the broadband context, and that providing customer PI to emergency services, to immediate family members in case of emergency, or to providers of information or database management services for the delivery of emergency services, are uses for which customer approval is implied. We therefore propose to allow BIAS providers to use or disclose any geo-location information, or other customer PI, for these purposes. We also propose to permit BIAS providers to use or disclose location information to support Public Safety Answering Point (PSAP) queries pursuant to the full range of next generation 911 (NG911) calling alternatives, including voice, text, video, and data, in addition to the circumstances delineated by statute. Our proposal will help ensure that PSAPs and emergency personnel have timely access to the full set of information they may need to respond quickly and effectively to locate and aid not only users of legacy voice services, but users of data, video, and text services as well. We also seek comment whether BIAS providers must support automated requests from PSAPs, to ensure that emergency response is not hampered by time-consuming or inefficient processes for necessary information. We seek comment on our proposed application of this statutory provision in the broadband context and on potential alternative approaches to the Section 222(d)(4) exception. Alternatively, we seek comment whether we could directly apply the provisions of Section 222(d)(4) to BIAS, by interpreting “call location information” to mean “broadband usage location information.”

99. In addition, we propose to interpret Section 222(d)(2) to permit BIAS providers to use or disclose CPNI whenever reasonably necessary to protect themselves or others from cyber security threats or vulnerabilities. Section 222(d)(2) permits providers to use CPNI to protect the rights or property of the carrier, or to protect users of those services and other carriers from fraudulent, abusive, or unlawful use of, or subscription to, such services. We believe that this proposal comports with the statute, because cyber security threats and vulnerabilities frequently harm the rights or property of providers, and typically harm users of those services and other carriers through the fraudulent, abusive, or unlawful use of, or subscription to, such services. Furthermore, we note that other statutes explicitly permit particular types of disclosure, which may encompass customer PI. We seek comment on this proposal. Should we extend this exception to include all customer PI? What, if any, guidance should we provide about what constitutes a cybersecurity threat entitled to this exception?

100. We also propose to interpret Section 222(d)(2) to allow telecommunications carriers to use or disclose calling party phone numbers, including phone numbers being spoofed by callers, without additional customer consent when doing so will help protect customers from abusive, fraudulent or unlawful robocalls. Month after month, unwanted voice robocalls and texts (together, “robocalls”) top the list of consumer complaints we receive at the Commission. At best, robocalls represent an annoyance; at worst they can lead to abuse and fraud. All concerned parties—regulators, providers, and consumer advocates—agree that better call blocking and filtering solutions are critical to helping consumers. To that end, we recently clarified that voice providers may offer their customers call blocking solutions without violating their call completion requirements, and encouraged providers to offer those solutions. We expect that sharing of calling party information to prevent robocalls will benefit consumers. We seek comment on this proposal, and on how well it fits within the framework of 222(d)(2). Is it consistent with customer expectations?

101. We also seek comment on what other customer PI telecommunications carriers, including interconnected VoIP providers, should be allowed to use or share without additional consumer consent pursuant to Section 222(d)(2) in order to prevent abusive, fraudulent, or unlawful robocalls. What other types of customer PI could help prevent robocalls, if shared with other providers and third party robocall solution

providers? Are BIAS or other providers already using or sharing some types of customer PI to mitigate the propagation of traffic that is fraudulent, abusive, or unlawful? If so, are there lessons that can be learned about the use or sharing of information that will assist in the fight against robocalls?

102. We also seek comment on whether we should expand the exceptions in Section 222(d) in the broadband context to permit broadband providers to use all customer PI for these delineated purposes. Is there any reason why providers would need to use customer PI that is not CPNI for the purposes Congress enumerated? If so, would such needs be outweighed by the countervailing interest in protecting the privacy of customer information?

103. Finally, consistent with our findings in the voice context, we propose to permit broadband providers to use CPNI without customer approval in the provision of inside wiring installation, maintenance, and repair services. We seek comment on this proposal, and specifically whether commenters believe there is any reason not to apply this provision in the broadband context. We also seek comment whether we should establish any other exceptions to our proposed framework. For instance, the existing CPNI rules permit providers to use or disclose information for the limited purpose of conducting research on the health effects of CMRS. Should a similar exception apply in the BIAS context? We encourage commenters to identify why any such exceptions would be consistent with Section 222 or other applicable laws.

b. Customer Approval Required for Use and Disclosure of Customer PI for Marketing Communications-Related Services

104. FTC best practices counsel that consumer choice turns on the extent to which the practice is consistent with the context of the transaction or the consumer's existing relationship with the business. Consistent with this and our existing rules, we propose that, except as permitted above in Part III.C.1.a, BIAS providers must provide a customer with notice and the opportunity to opt out before they may use that customer's PI, or share such information with an affiliate that provides communications-related services, to market communications-related services to that customer. We seek comment on this proposal.

105. This approach is similar to the approach taken by our current Section 222 rules, and we believe it is consistent with customers' expectations. However, we invite comment on this approach, specifically on customers' expectations and preferences regarding how their broadband provider may itself use customer PI; and for what purposes it should be allowed to share information with its affiliates subject to opt-out approval. Given the prevalence of bundled service offerings, do customers expect that their broadband providers could or should themselves use or share the customers' proprietary information with affiliates to market voice, video, or any types of communications-related services tailored to their needs and preferences without their express or implied approval? Or would customers prefer and expect to have their customer PI used or shared with affiliates only after the customers have affirmatively consented to such use or sharing? Do customers' expectations depend as much on the type of customer PI that is being shared as with the purpose of the sharing or the parties with whom the information is being shared? For example, below, we seek comment on whether we should require heightened consent obligations for highly sensitive information, including geo-location information.

106. We are mindful that in adopting a framework for customer approval for use by and disclosure to affiliates of customer PI, we do not want to inadvertently encourage corporate restructuring or gamesmanship driven by an interest in enabling use or sharing of customer PI subject to less stringent customer approval requirements. We believe that we can discourage such gamesmanship by treating use by an affiliate as subject to the same limits as use by a BIAS provider. We seek comment on this proposal. We also seek comment on what effect our proposed choice requirements will have on marketing of broadband and related services, as well as on the digital advertising industry. What effect will they have on competition between BIAS providers and over-the-top (OTT) service providers that offer services that may be a competitive threat or a potential competitor to separate voice, video, or information services offered by broadband providers, and which are not subject to our rules?

107. We also observe that in adopting the existing Section 222 rules for the sharing of CPNI with affiliates, the Commission concluded that because principles of agency law hold carriers responsible for their agents' improper uses or disclosures of CPNI, carriers have greater incentives to maintain appropriate control of CPNI disclosed to agents. The Commission concluded that an opt-out regime for the sharing of CPNI with affiliates that offer communications-related services for purposes of marketing such services would adequately protect consumers' privacy because a carrier's need to maintain a continuing relationship with its customer, and the risk of being held responsible for the misuse of customer information by an affiliate, would incentivize the carrier to prevent privacy harms. We believe such findings to be relevant in the broadband context as well, and seek comment on whether such findings are applicable to BIAS. Do consumers have a different expectation of privacy when it comes to BIAS, as opposed to voice, affiliates? Does the changing nature of affiliate relationships require more caution in the BIAS context than the voice context?

108. Alternatively, we seek comment whether we should require BIAS providers to obtain customer opt-in approval for the use and sharing of all customer PI, except as described in Part III.C.1.a. Would such an approach be “narrowly tailored” to materially advance the government's interest under

Central Hudson

? Conversely, would a requirement of opt-out approval be more appropriate for

all

BIAS provider uses of customer PI and sharing with affiliates? Should we adopt the FTC's recommendation that affiliates generally be treated as “third parties . . . unless the affiliate relationship is clear to consumers”? If so, how would we determine if the relationship is clear to consumers? Would co-branding suffice? We also seek comment on whether we should treat all affiliates as third parties, that is, requiring opt-in consent from customers for any sharing with any affiliates. Would such a rule be properly tailored to meet the substantial interest in protecting customer privacy? Would it promote gamesmanship in the corporate structure of BIAS providers? We also seek comment on how we should treat third parties acting as contractors and performing functions for or on behalf of a BIAS provider. Should they be treated differently than other types of third parties?

c. Customer Approval Required for Use and Disclosure of Customer PI for All Other Purposes

109. Consistent with the existing voice rules and other privacy frameworks, we propose to require BIAS providers to seek and receive opt-in approval from their customers before using or sharing customer PI for all uses and sharing other than those described above in Parts III.C.1.a and III.C.1.b. Specifically, we propose to require BIAS providers to obtain customer opt-in approval before (1) using customer PI

for purposes other than marketing communications-related service; (2) sharing customer PI with affiliates providing communications-related services for purposes other than marketing those communications-related services; and (3) sharing customer PI with all other affiliates and third parties. Consistent with the Commission's existing rules, we include joint venture partners and independent contractors within the category of “third parties” for purposes of our proposed rules. We believe that customers desire and expect the opportunity to affirmatively choose how their information is used for purposes other than marketing communications-related services by their provider and its affiliates. We seek comment on this proposal and on potential alternatives to these requirements.

110.

BIAS Providers and Affiliates.

We seek comment whether BIAS providers need or benefit from using customer PI for purposes other than marketing communications-related services. If so, what are those uses, and are they consistent with customer expectations? What are the privacy risks for customers from those additional uses? We observe that many companies can meet the Act's definition of “affiliate” while bearing little resemblance—in the services offered, or even in their name—to what customers recognize as their provider. This, combined with lack of competition between BIAS providers and with high switching costs, could negatively impact BIAS providers' incentives in protecting the customer-carrier relationship with respect to use and disclosure of customer PI to affiliates. Does obtaining opt-in permission for these uses or disclosures prevent BIAS providers or consumers from making valuable use of this information? Does our proposed approach align with customer expectations of how their PI should be treated by their BIAS provider and the provider's affiliates? Should opt-in consent be required for disclosure or use of certain customer PI in the mobile context? Most notably, should we require opt-in consent in the mobile context for sharing geo-location data with affiliates, regardless of whether it is required in the fixed context? Does this proposal accommodate the expanded scope of uses and services now provided by BIAS affiliates and others, particularly given the above-noted concerns about the breadth of affiliates in today's BIAS environment?

111.

Third Parties.

The Commission has a substantial government interest in protecting the privacy of customer information, and our proposal is designed to materially advance that interest. Research demonstrates that customers view the use of their personal information by their broadband provider differently than disclosure to or use by a third party for a variety of reasons. More recently, studies from the Pew Research Center show that the vast majority of adults deem it important to control who can get information about them. Increasing the number of entities that have access to customer PI logically increases the risk of unauthorized disclosure by both insiders and computer intrusion. Risk of harm to the customer is exacerbated by the fact that third-party entities receiving customer information have no direct business relationship with the consumer and, hence, a reduced or absent incentive to honor the privacy expectations of those customers. As the Commission has found in the voice context, once confidential customer information “enters the stream of commerce, consumers are without meaningful recourse to limit further access to, or disclosure of, that personal information.” We anticipate that this is equally true for other forms of customer PI.

112. For these reasons, and because the use of customers' personal information might fall outside the protections of Section 222 once that information is disclosed to third parties, we believe that the threat to broadband customers' privacy interest from having their personal information disclosed to such entities without their affirmative approval is a substantial one, and there is a greater need to ensure express consent from an approval mechanism for third party disclosure. We seek comment on this analysis, and in particular, the threat to broadband customers' privacy stemming from disclosure of customer information to third parties.

113. We seek comment on the burdens that the proposed opt-in framework for disclosure to third parties would impose on broadband providers. Are such costs outweighed by the providers' duty to protect their customers' private information and customers' interest in maintaining control over their private information? We note that our current voice rules require opt-in approval for disclosure to most third parties. Further, some state laws also require customer permission for ISPs to disclose information if the disclosure is not in the ordinary course of the ISP's business. We also seek comment on the effect that our proposal will have on small providers.

114. We seek comment on what effect, if any, our proposed opt-in approval framework will have on marketing in the broadband ecosystem, over-the-top providers of competing services, the larger Internet ecosystem, and the digital advertising industry. We recognize that edge providers, who may have access to some similar customer PI, are not subject to the same regulatory framework, and that this regulatory disparity could have competitive ripple effects. However, we believe this circumstance is mitigated by three important factors. First, the FTC actively enforces the prohibitions in its organic statute against unfair and deceptive practices against companies in the broadband ecosystem that are within its jurisdiction and that are engaged in practices that violate customers' privacy expectations. We have no doubt that the FTC will continue its robust privacy enforcement practice. Second, the industry has developed guidelines recommending obtaining express consent before sharing some sensitive information, particularly geo-location information, with third parties, and large edge providers are increasingly adopting opt-in regimes for sharing of some types of sensitive information. Third, edge providers only have direct access to the information that customers choose to share with them by virtue of engaging their services; in contrast, broadband providers have direct access to potentially

all

customer information, including such information that is not directed at the broadband provider itself to enable use of the service. We seek comment on these expectations. Do commenters agree that these factors mitigate any potential competitive effects that might result from our proposed opt-in framework for disclosure of customer PI to third parties? What other factors counsel for or against it?

115.

Alternatives.

In the alternative, we seek comment whether an opt-out approval framework would be more appropriate for BIAS providers' (and their affiliates') use of customer PI for purposes other than marketing communications-related services, and for disclosure of customer PI to third parties, or for some subset of such activities. Are there reasons why such uses and disclosures of customer PI—or some subset of disclosures—should be subject to a more lenient standard of consent, such as opt-out approval? Why or why not? Would opt-out approval be an effective means of protecting customers from the harms that are attendant upon unknowing and unwanted third party disclosures, or from unexpected uses of their customer PI by their broadband providers? If so,

are there particular types of uses, data, or third parties for which a heightened standard of approval should be required?

d. Other Choice Frameworks

116. We have sought comment on one framework for approaching the types of control to give consumers over their customer PI. We also invite commenters to propose other frameworks for ensuring that broadband customers are given the ability to control the use and disclosure of their confidential information.

117. Are there other ways of differentiating between expected and unexpected uses and contexts for BIAS provider use of customers' PI that would be more useful? How should different types and contexts of information and usage be assigned different levels of required approval? Given the various types of information at issue, is there the risk that customers could be overwhelmed by choice and allow default options to stand? Would this militate towards requiring opt-in approval for more types of information? What approach, if any, best balances consumer benefits with minimizing regulatory burdens on broadband providers?

118. In particular, we seek comment whether certain types of “highly sensitive” customer information should be used by BIAS providers, even for the provision of the service, or shared with their affiliates offering communications-related services, only after receiving opt-in approval from customers. For example, the FTC has recognized certain types of information as particularly sensitive, including Social Security numbers and financial information, geo-location information, children's information, and health information. Given the highly sensitive nature of such information, customers may have an interest in ensuring that such data is not used without their prior, affirmative authorization. We seek comment on these issues. For example, location-based information—particularly mobile geo-location data—that reveals a customer's residence or current location is particularly sensitive in nature, and consumers may have a keen interest in safeguarding such data out of concerns for both safety and basic privacy. In the voice context, Congress recognized that use of “call location information” should not be used or disclosed without the “express prior authorization of the customer.” How should we consider treatment of location information in the broadband context? Likewise, we seek comment on what steps we could take to ensure knowing consent regarding the customer PI of children. Are there other types of information that we should treat as highly-sensitive and subject to opt-in protection? For example, should practices that involve using or sharing a customer's race or ethnicity, or other demographic information about a customer be subject to heightened privacy protections? Are there any types of information that BIAS providers should never use for purposes other than providing BIAS services?

119. We also seek comment on how to treat the content of communication, if we determine that it is covered by Section 222. The content of communications contain a wide variety of highly personal and sensitive information. Congress has also recognized that content of communications should be protected in all but the most exceptional circumstances. In addition to personal privacy implications, provider use of communications content raises competitive issues. A broadband provider may be able to glean competitively sensitive information from the contents of customers' communications. Would such conduct be prohibited under the Commission's general conduct rule prohibiting carriers from unreasonably interfering with or unreasonably disadvantaging end users' ability to select, access, and use broadband Internet access service or the lawful Internet content applications, services, or devices of their choice? We seek comment on whether the use or sharing, including with affiliates, of the content of customer communications should be subject to opt-in approval. We also seek comment on other approaches to the use of the content of customer communications, including how such approaches interact with our treatment of other types of information covered by Section 222.

120. Finally, we seek comment whether customers expect their BIAS providers to treat their PI differently depending on how the provider acquires it, and whether BIAS providers do and should treat such information differently. Should a broadband provider obtain some form of consumer consent before combining data acquired from third-parties with information it obtained by virtue of providing the broadband service?

2. Requirements for Soliciting Customer Opt-Out and Opt-In Approval

121. In this section, we seek comment on the appropriate procedures and practices for BIAS providers to obtain meaningful customer approval for the use or disclosure of customer PI. To that end, we first propose to require BIAS providers to solicit customer approval the first time that a BIAS provider intends to use or disclose the customer's PI in a manner that requires customer approval under our proposed rules. Second, we seek comment on the format of BIAS provider solicitations for customer approval, as well as the methods and formats by which customers may exercise their privacy choices. Specifically, we propose that BIAS providers must give customers a convenient and persistent ability to express their approval or disapproval of the use or disclosure of their information, at no cost to the customer. Third, we propose that a customer's choice must persist until it is altered by the customer, and that it should take effect promptly after the customer's expression of her choice. Fourth, we seek comment whether to apply the voice notice requirements specific to one-time usage of CPNI to BIAS providers' one-time usage of customer PI. We seek comment on these proposals, and reasonable alternatives thereto.

122.

Notice and Solicitation of Customer Approval Required Prior to Use or Disclosure of Customer PI.

To ensure that customers provide meaningful approval, we propose to require BIAS providers to solicit customer approval—subsequent to the point-of-sale—when a BIAS provider first intends to use or disclose the customer's proprietary information in a manner that requires customer approval. To ensure that customers' approval is fully informed, we propose to require BIAS providers to notify customers of the types of customer PI for which the provider is seeking customer approval to use, disclose or permit access to; the purposes for which such customer PI will be used; and the entity or types of entities with which such customer PI will be shared. We seek comment on this approach. Is there other information that a provider should be required to share as part of receiving opt-out or opt-in consent for the use or disclosure of customer information? For example, should a provider be required to share information about the arrangements it has made with third parties for the use of customer PI? If so, what information should they be required to share? We also seek comment on whether providers should be required to provide a link to the provider's privacy policy notice or other information when seeking approval for the use or sharing of customer PI. We are cognizant of the risk of information-overload if consumers are given more information than they need to make an informed

decision. We believe that our proposal, combined with the requirement to have a persistent and easily available longer privacy policy notice strikes the right balance, but we invite comment on whether there is other or different information that BIAS customers will need to make well informed opt-in and opt-out decisions. Also, while we believe that notice of a BIAS provider's privacy policies and customers' approval rights at the time of sale is necessary to help customers make an informed decision on which broadband service to purchase, such notice can often be too remote in time from when the information is actually used to give customers meaningful choice. Therefore, we believe that customers' informed approval requires notification and solicitation the first time that a BIAS provider will actually use or disclose a customer's PI. We seek comment on our proposal.

123. As the FTC has concluded, in order to be most effective, choice mechanisms that allow consumers control over how their data is used should be provided “at a time and in a context that is relevant to consumers.” We believe that providing notice and soliciting customer choice at this time may give customers useful information when it is most relevant to them, offsetting the risk that customers will be presented with so much information at the point of sale that they will not be able to meaningfully read and understand the privacy policies. Further, providing notice and soliciting choice before a provider wishes to use or disclose customer PI may also reduce the need for annual or other periodic notices. We seek comment on our proposal. Could notices upon use or disclosure contribute to “notice fatigue” over time, instead of lessening its impact at point of sale?

124. We also seek comment whether we should require BIAS providers to notify customers of their privacy choices and solicit customer approval at other prominent points in time. For example, should broadband providers be required to solicit customers' “just-in-time” approval whenever the relevant customer PI is collected or each time the broadband provider intends to use or disclose the relevant customer PI? What are the practical and technical realities of any such approaches? Are there any mobile-specific considerations that the Commission should consider in determining when the opportunity to provide customer approval should be given?

125.

Notice and Solicitation Methods.

We seek comment on how BIAS providers should notify customers of upcoming uses and disclosures of their PI, and solicit customer approval for those uses and disclosures. Should we permit each BIAS provider to determine the best method for soliciting customer approval, such as through email or another agreed upon means of electronic communication; separately by postal mail to the customer address of record; included on customer bills; or through some other method? Are there other technological solutions to providing customers notice that would minimize the burden on providers, and that would be equally or more efficient than these methods, such as, for example, a “notification” on the customer's device that accesses the broadband service? Alternatively, should we require BIAS providers to use a specific method or methods? We seek comment on any particular requirements that should apply for any of the above methods of soliciting approval.

126.

Customer Approval Methods.

We propose to require BIAS providers to make available to customers a clearly disclosed, easy-to-use method for the customer to deny or grant approval, such as through a dashboard or other user interface that is readily apparent and easy to comprehend, and be made available at no cost to the customer. We propose that such approval method should be persistently available to customers, such as via a link on a BIAS provider's homepage and mobile application, as well as any functional equivalents to them. We believe that this proposed requirement will directly and materially protect customer privacy by ensuring that customers have the ample opportunity to exercise their approval rights. Customers cannot effectively exercise their approval if the interface for expressing that choice is difficult to use, or if it is only rarely or sporadically available.

127. We seek comment on our proposal, and on any further requirements we should impose on the opportunity to grant or deny approval that may enhance customer comprehension. Should customers be given the ability to approve or disapprove uses within the text of the notice or solicitation, in addition to a dashboard or other persistent mechanism? And, given that some customers are unaccustomed to interacting with their provider via applications or the provider's homepage, should we require broadband providers to provide customers with the ability to provide customer approval via other written, electronic, or oral means,

e.g.,

through written correspondence, a toll-free number, or dedicated email address? How would such a requirement affect provider burdens?

128. We also seek comment on whether there are any mobile-specific considerations that we should consider in determining how the opportunity to provide customer approval should be given. For example, since mobile BIAS may be more accessible to children beyond parental supervision, are different approval methods necessary regarding consent of minors on mobile devices? Finally, we seek comment whether any of our proposed requirements are unnecessary or unlikely to aid customers.

129.

Effectiveness of Customer Choice.

We propose that approval or disapproval to use, disclose, or permit access to customer PI obtained by a broadband provider must remain in effect until the customer revokes or limits such approval or disapproval, and seek comment on this proposal. Are there particular considerations (for instance, with already-collected information) when customers disapprove of uses that they have previously approved, or vice versa? We also propose that BIAS providers must act upon customers' privacy choices “promptly” after customers provide or withdraw consent for the use or disclosure of their information. We seek comment whether it is necessary for the Commission to establish guidelines for what “promptly” means in this context. Why or why not? If so, we seek comment on what the guidelines and time frame might be. If a customer later reconsiders and changes his approval, how long should the provider be given to update this consent choice? Should the two lengths of time be the same? How does this proposal affect potential rules limiting data retention and requiring disposal of customer data? Would a customer's withdrawal of consent require disposal of her already-collected data immediately, after a period of time, or not at all?

130.

Notice Requirements for One-Time Usage of Customer PI.

Additionally, we seek comment on whether to apply or adapt the current voice notice requirements specific to one-time usage of CPNI to BIAS providers' one-time usage of customer PI. The current voice rules allow a more flexible process for providing notice and accepting consent, so long as the approval granted is for the limited purposes of the particular interaction, such as during the duration of a customer service call or during a real-time chat. Do these or some other requirements make sense in the broadband context? Do they make sense

as extended to all customer proprietary information?

3. Documenting Compliance With Proposed Customer Consent Requirements

131. In order to ensure that the requisite approval is clearly established before the use or disclosure of customer PI, and also that the approval can be demonstrated after the use or disclosure, we propose to require BIAS providers to document the status of a customer's approval for the use and disclosure of customer PI, and we seek comment on that proposal. We base our proposal on the existing rules governing safeguards on the use and disclosure of customer PI for voice telecommunications services. Specifically, we propose requiring BIAS providers to (1) maintain records on customer PI disclosure to third parties for at least one year, (2) maintain records of customer notices and approval for at least one year, (3) adequately train and supervise their personnel on customer PI access, (4) establish supervisory review processes, and (5) provide prompt notice to the Commission of unauthorized uses or disclosures. With these proposed rules, we seek to promote consumer confidence that BIAS providers are adequately protecting customers' PI, to provide clear rules of the road to BIAS providers about their obligations, and to maintain consistency with existing legal requirements and customer expectations. Are there any other or different requirements that we should adopt in order to ensure that providers document their compliance with our customer consent requirements? Should we require BIAS providers to file an annual compliance certification with the Commission, as is required under the current Section 222 rules? Are there alternative approaches to safeguard customers' proprietary information and boost customer confidence in the privacy of their customer PI that we should consider?

132. Finally, in addition to the above proposals, we seek comment on any other mechanisms or alternatives that would help document compliance with our proposed customer approval framework, boost customer confidence in BIAS provider safeguards of customer PI, and harmonize the proposed rules with existing legal requirements and customer expectations.

4. Small BIAS Providers

133. We seek comment on ways to minimize the burden of our proposed customer choice framework on small BIAS providers. In particular, we seek comment on whether there are any small-provider-specific exemptions that we might build into our proposed approval framework. For example, should we allow small providers who have already obtained customer approval to use their customers' proprietary information to grandfather in those approvals? Should this be allowed for disclosure to third parties? Should we exempt providers that collect data from fewer than 5,000 customers a year, provided they do not share customer data with third parties? Are there other such policies that would minimize the burden of our proposed rules on small providers? If so, would the benefits to small providers of any suggested exemptions outweigh the potential negative impact of such an exemption on the privacy interests of the customers who contract for the provision of BIAS with small providers? Further, were we to adopt an exemption, how would we define what constitutes a “small provider” for purposes of that exemption?

5. Harmonizing Customer Approval Requirements

134. We seek comment on whether we should take steps to harmonize the existing customer approval requirements for voice services with those requirements we have proposed for broadband providers to ensure that the privacy of customers' PI is protected, and that our regulations are competitively neutral, across all platforms. Are there aspects of the existing rules that should be more explicitly incorporated into our proposal, or eliminated to better comport with our proposal? Are there aspects of the proposed rules that should be applied in the voice context? Would harmonizing these rules benefit traditional voice subscribers? Would harmonizing our existing and proposed rules benefit providers who offer both services by clarifying and streamlining the customer approval requirements applicable to both types of services? In harmonizing the existing voice rules with our proposed rules for BIAS providers, how should we address voice services provided to large enterprise customers, which are currently not subject to the voice rules? Are there other changes that can be made to our rules that govern the marketing of service offerings that might improve them in the voice context? We also seek comment on how our reclassification of BIAS as a telecommunications service affects the obligations of voice carriers under our rules.

135. We also seek comment on whether we should adopt rules harmonizing the approval requirements we propose for BIAS customers with the approval requirements for use of subscriber information in Sections 631 and 338(i). We note that those provisions of the Act prohibit the use of the cable or satellite system to collect, use, or share personally identifiable information for purposes other than provision of the underlying services and other very limited purposes, absent the express written or electronic consent of the subscriber, except to provide the underlying service and for certain other very limited purposes.

D. Use and Disclosure of Aggregate Customer PI

136. Because of the complexity of the issues surrounding aggregation, de-identification, and re-identification of the data that BIAS providers collect about their customers, we propose to address separately the use of, disclosure of, and access to aggregate customer information. Consistent with reasonable consumer expectations, existing best practices guidance from the FTC and NIST, and Section 222(c)(3)'s treatment of aggregate CPNI, we propose to allow BIAS providers to use, disclose, and permit access to aggregate customer PI if the provider (1) determines that the aggregated customer PI is not reasonably linkable to a specific individual or device; (2) publicly commits to maintain and use the aggregate data in a non-individually identifiable fashion and to not attempt to re-identify the data; (3) contractually prohibits any entity to which it discloses or permits access to the aggregate data from attempting to re-identify the data; and (4) exercises reasonable monitoring to ensure that those contracts are not violated. We also propose that the burden of proving that individual customer identities and characteristics have been removed from aggregate customer PI rests with the BIAS provider.

137. Recognizing that aggregate, non-identifiable customer information can be useful to BIAS providers and the companies they do business with, and not pose a risk to the privacy of consumers, Section 222(c)(3) permits telecommunications carriers to use, disclose, or permit access to aggregate customer information—collective data that relates to a group or category of services or customers, from which individual customer identities and characteristics have been removed—without seeking customer approval. Our proposed rule expands this concept to include all customer PI, and imposes safeguards to ensure that such information is in fact aggregated and non-identifiable, and that safeguards

have been put in place to prevent re-identification of this information.

138. We believe our multi-pronged proposal, grounded in FTC guidance, will give providers enough flexibility to ensure that as technology changes, customer information is protected, while at the same time minimizing burdens and maintaining the utility of aggregate customer information. Below we discuss and seek comment on each of the prongs of our proposed rule regarding the use and disclosure of aggregate customer PI. We also seek comment on whether we should extend our proposed rule to providers of voice telecommunications services. To the greatest extent possible, we ask that commenters ground their comments in practical examples: What kinds of aggregate, non-identifiable information do or can BIAS providers use and share?

139.

Not Reasonably Linkable.

In order to protect the confidentiality of individual customers' proprietary information, the first prong of our approach would require providers to ensure the aggregated customer PI is not reasonably linkable to a specific individual or device. Our proposal recognizes that techniques that once appeared to prevent re-identification of aggregate information have increasingly become less effective. It is also consistent with FTC guidance which recommends that companies take reasonable measures to ensure that the data is de-identified, and recommends that this determination should be based on the particular circumstances, including the available methods and technologies, the nature of the data at issue, and the purposes for which it will be used.

140. We seek comment on this proposal. Are the factors identified by the FTC well-suited to determining whether a BIAS provider has taken reasonable measures to de-identify data? Are there other factors that we should expect providers to take into account? Should we provide guidance on what we mean by linked and linkable information? NIST defines linked information as “information about or related to an individual that is logically associated with other information about the individual,” and linkable information as “information about or related to an individual for which there is a possibility of logical association with other information about the individual.” Should we adopt either or both of these standards? Are there other approaches we should use to decide whether information is reasonably linkable? For example, HIPAA permits covered entities to de-identify data through statistical de-identification, whereby a properly qualified statistician, using accepted analytic techniques, concludes that the risk is substantially limited that the information might be used, alone or in combination with other reasonably available information, to identify the subject of the information.

141. We seek comment on alternative approaches to this prong and the comparative merits of each possible approach. We also seek comment whether we should require BIAS providers to retain documentation that outlines the methods and results of the analysis showing that information that it has treated as aggregate information has been rendered not reasonably linkable.

142.

Public Commitments.

Prong two of our proposal would require BIAS providers to publicly commit to maintain and use aggregate customer PI in a non-individually identifiable fashion and to not attempt to re-identify the data. Such public commitments would help ensure transparency and accountability, and accommodate new developments in the rapidly evolving field of privacy science. This prong and the next are consistent with FTC guidance and the Administration's draft privacy bill recommending that companies publicly commit not to re-identify data and contractually prohibit any entity with which a company shares customer data from attempting to re-identify it. We seek comment on this proposal. Would this requirement help ensure that providers are protecting the confidentiality of customer PI? How could or should a BIAS provider satisfy the requirement to make a public commitment not to re-identify aggregate customer PI? For example, would a statement in a BIAS provider's privacy policy be sufficient?

143.

Limits on Other Entities.

The third prong of our proposal would require providers to contractually prohibit any entity to which the BIAS provider discloses or permits access to the aggregate customer data from attempting to re-identify the data. This proposal presents a modern approach to the difficulties of ensuring the privacy of aggregate information, recognizing that businesses are often in the best position to control each other's practices. Researchers have argued that such contractual prohibitions are an important part of protecting consumers' privacy, because making data completely non-individually identifiable may not be possible or even desirable. We recognize that the categories of what can potentially be reasonably linkable information will continue to evolve, and we believe these contractual provisions provide a critical layer of privacy protection that remains constant regardless of changes in the technology.

144.

Reasonable Monitoring.

Related to the requirements for prong three, the fourth prong of our approach requires BIAS providers to exercise reasonable monitoring of the contractual obligations relating to aggregate information and to take reasonable steps to ensure that if compliance problems arise they are immediately resolved. This prong is a logical outgrowth of the previous prongs, and it is consistent with the 2012 FTC Privacy Report. We seek comment regarding the types of monitoring and remediation steps BIAS providers should be required to take to ensure that entities with which they have shared aggregate customer PI are not attempting to re-identify the data. What potential burdens and benefits would arise from this proposal?

145.

Alternatives.

Alternatively, we seek comment whether we should develop a list of identifiers that must be removed from data in order to determine that “individual customer identities and characteristics have been removed.” If we take such an approach, should it replace all, a portion of, or be in addition to our current proposal? HIPAA incorporates such a standard, and under this approach, a covered entity or its business associate may de-identify information by removing 18 specific identifiers. Under HIPAA, the covered entity must also lack actual knowledge that the information could be used alone or in combination with other information to identify an individual who is a subject of the information. We are aware of criticisms that the approach taken by HIPAA no longer provides the levels of protection previously assumed. One legal scholar, for example, argues that “[t]he idea that we can single out fields of information that are more linkable to identity than others has lost its scientific basis and must be abandoned.” Are such concerns valid? Were we to adopt a similar standard to that in HIPAA, what categories of identifiers would be relevant in the broadband context? And, given the wide variety of customer data to which BIAS providers have access by virtue of their provision of BIAS, is such a list even feasible? Is it likely that any list developed would be rendered obsolete by technological developments in the data re-identification field? How could we best ensure that the categories we identify remain adequate to prevent aggregate customer PI from being re-identified? Should we adopt a catch-all to address evolving methods of de-identification and re-identification of aggregate customer PI, and if so, how

would such a process work? We also seek comment whether, if we were to pursue such an approach, we should also adopt an “actual knowledge” standard, as HIPAA includes. How would the Commission enforce such a standard, and would it encourage willful ignorance on the part of broadband providers?

146. Are there any additional or alternative requirements we should adopt that might make aggregate customer information less susceptible to re-identification? If so, what are they, and why would they be preferable to the procedures we have proposed above? As commenters consider whether we should adopt each of the prongs of our proposed rule, and any proposed alternatives, we welcome comment on how providers would demonstrate compliance with each prong of the proposal, and of any alternative proposals. Are there specific record keeping requirements we should impose on providers to demonstrate compliance? We also seek comment on the costs and benefits of each prong and of all of them collectively. We invite proposals on how we could limit any burdens associated with compliance, particularly for smaller providers.

147. We also seek comment on how de-identified, but non-collective data should be treated under Section 222 and our rules. We note that there is an existing petition before the Commission that may address some of these issues.

See

Petition of Public Knowledge et al. for Declaratory Ruling Stating that the Sale of Non-Aggregate Call Records by Telecommunications Providers without Customers' Consent Violates Section 222 of the Communications Act, WC Docket No. 13-306 (filed Dec. 11, 2013). We do not believe that the use and disclosure of such information would fall under the exception for use and disclosure of aggregate customer data enumerated in Section 222(c)(3), because by definition aggregate data must be collective data. Do commenters agree? Does Section 222 require us to conclude that all CPNI should be considered individually identifiable unless it meets the definition of aggregate,

i.e.,

is both de-identified and collective? Does the use and disclosure of such information then fall under the general use and disclosure prohibitions of Section 222(c)(1)? Does Section 222(a) provide the Commission authority to adopt privacy protections regarding all such data that is customer PI? We seek comment whether de-identified but non-collective data should be subject to the proposed opt-out and opt-in customer consent requirements described above.

148. We seek comment on whether we should, for the sake of harmonization, apply our proposed rules for BIAS providers' use and disclosure of, and access to, aggregate customer proprietary information to all other telecommunications carriers. Likewise, should we adopt rules harmonizing the treatment of aggregate information by cable and satellite providers with the treatment of aggregate information by telecommunications carriers? We note that neither Section 222 nor the Commission's currently existing implementing rules explicitly restrict carriers' use of aggregate customer PI. However, as noted above, as technology has evolved, information that previously appeared to be aggregate may no longer be. We think this is true whether a company offers voice telephony or BIAS. Providers, researchers, and others make valuable use of aggregate customer information, but this use must comport with contemporary understandings of how to ensure the information is aggregate information and not re-identifiable. Accordingly, we ask commenters to explain whether our proposed rules should apply to all providers regardless of the technology used to provide service.

E. Securing Customer Proprietary Information

149. Strong data security protections are crucial to protecting the confidentiality of customer PI. As the FTC has observed, there is “widespread evidence of data breaches and vulnerabilities related to consumer information,” and such incidents “undermine consumer trust, which is essential for business growth and innovation.” Therefore, to protect confidential customer information from misappropriation, breach, and unlawful disclosure, we prop

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