Freedom to Tinker

This week I signed the Electronic Frontier Foundation’s amicus (friend-of-the-court) brief in the Apple/FBI  iPhone-unlocking lawsuit.  Many prominent computer scientists and cryptographers signed: Josh Aas, Hal Abelson, Judy Anderson, Andrew Appel, Tom Ball (the Google one, not the Microsoft one), Boaz Barak, Brian Behlendorf, Rich Belgard, Dan Bernstein, Matt Bishop, Josh Bloch, Fred Brooks, Mark Davis, Jeff Dean, Peter Deutsch, David Dill, Les Earnest, Brendan Eich, David Farber, Joan Feigenbaum, Michael Fischer, Bryan Ford, Matt Franklin, Matt Green, Alex Halderman, Martin Hellman, Nadia Heninger, Miguel de Icaza, Tanja Lange, Ed Lazowska, George Ledin, Patrick McDaniel, David Patterson, Vern Paxson, Thomas Ristenpart, Ron Rivest, Phillip Rogaway, Greg Rose, Guido van Rossum, Tom Shrimpton, Barbara Simons, Gene Spafford, Dan Wallach, Nickolai Zeldovich, Yan Zhu, Phil Zimmerman. (See also the EFF’s blog post.)

The technical and legal argument is based on the First Amendment: (1) Computer programs are a form of speech; (2) the Government cannot compel you to “say” something any more than it can prohibit you from expressing something.  Also, (3) digital signatures are a form of signature; (4) the government cannot compel or coerce you to sign a statement that you don’t believe, a statement that is inconsistent with your values.  Each of these four statements has ample precedent in Federal law.  Combined together, (1) and (2) mean that Apple cannot be compelled to write a specific computer program.  (3) and (4) mean that even if the FBI wrote the program (instead of forcing Apple to write it), Apple could not be compelled to sign it with its secret signing key.  The brief argues,

By compelling Apple to write and then digitally sign new code, the Order forces Apple to first write a message to the government’s specifications, and then adopt, verify and endorse that message as its own, despite its strong disagreement with that message. The Court’s Order is thus akin to the government dictating a letter endorsing its preferred position and forcing Apple to transcribe it and sign its unique and forgery-proof name at the bottom.

There are millions of iPhones that rely on Apple’s considered opinion about whether it’s a good idea to install a software update.  Or, if you like, there are millions of iPhone owners who rely on Apple’s considered opinion about what software updates are safe and advisable to install on their phones, and who have deliberately purchased phones that implement this personal reliance by the mechanism of public-key authentication.  The FBI seeks to force Apple to sign a statement in contradiction with its values.  But “compelled speech doctrine prevents the government from forcing its citizens [and corporations] to be hypocrites.”

Regarding whether (1) computer programs are a form of speech, the EFF’s brief cites three previous Federal cases where appellate courts have upheld this principle:

It is long settled that computer code, including the code that makes up Apple’s iOS operating system and its security features including encryption, is a form of protected speech under the First Amendment. Universal City Studios, Inc. v. Corley (2d Cir. 2001); Junger v. Daley (6th Cir. 2000); Bernstein v. DOJ (9th Cir. 1999).  Code consistently receives First Amendment protection because code, like a written musical score, “is an expressive means for the exchange of information and ideas.” (Junger, 209 F.3d at 484.) In Corley, which similarly considered code that could be used to undermine security, the Second Circuit held that “[c]ommunication does not lose constitutional protection as ‘speech’ simply because it is expressed in the language of computer code. Mathematical formulae and musical scores are written in ‘code,’ i.e., symbolic notations not comprehensible to the uninitiated, and yet both are covered by the First Amendment.” (273 F.3d at 445–46.) [citations abridged.]

I am proud to have participated in each of these three cases.  In Bernstein v. Daley I wrote this declaration in 1996 (a form of written testimony about facts), saying, “yes, we scholars publish computer programs just like we publish natural-language papers; I have been publishing open-source software since 1988.”  In Junger v. Daley I wrote this similar declaration in 1997.  These two cases were the foundation of the 1990s victories in “freedom of cryptography” in the United States.

In Universal City Studios, Inc. v. Corley I not only wrote a declaration, I testified as a witness in Federal Court in New York. The “DMCA police” mostly won that case, unfortunately, but even so, the judges at both levels (district court and appellate court) agreed that source code is speech.

Professor Richards has argued that the “Code=Speech” argument is problematic, that this is not the best argument in favor of Apple’s position.  He says, even if Code is Speech, there are other restrictions on speech that (the courts have held) are consistent with freedom of expression.  But he does agree with the digital-signature argument:

“making Apple write and disseminate this particular code—making it lie to one of its customers—could be seen as a kind of compelled speech, and that could violate the First Amendment. But this wouldn’t be the case merely because (as Apple assumes) Code = Speech and the FBI was compelling the creation of code. Instead, it would be offensive to the First Amendment because the particular act being compelled—authenticating a security update as true when it was false—would be compelled false communication in a relationship of trust. The law on this narrow question is underdeveloped, but it could allow Apple to win on free speech grounds.”

Other amicus briefs in support of Apple focus on other important and excellent arguments.  The brief from Stanford, signed by Dino Dai Zovi, Dan Boneh, Charlie Miller, Hovav Shacham, Bruce Schneier, Dan Wallach and Jonathan Zdziarski, argues that “[f]orcing device manufacturers to create forensic capabilities for U.S. investigators creates security risks” and “security breaches are all but certain when law mandates government access.”  I agree completely with this brief as well (but one can’t sign every brief!).

The ACLU’s brief argues, “The All Writs Act does not authorize the government” to compel Apple to do this, in part because “Congress has deliberately withheld the authority sought here;” and that “the order the government seeks violates the Fifth Amendment.”  I quite agree with the ACLU, of which I have been a member since 1988; but I am a computer scientist, not a lawyer, so on that amicus brief my computer-security and computer-science expertise does not specifically apply.

Earlier this week, I came across a working paper from Professor Peter Swire—a highly respected attorney, professor, and policy expert.  Swire’s paper, entitled “Online Privacy and ISPs“, argues that ISPs have limited capability to monitor users’ online activity. The paper argues that ISPs have limited visibility into users’ online activity for three reasons:  (1) users are increasingly using many devices and connections, so any single ISP is the conduit of only a fraction of a typical user’s activity; (2) end-to-end encryption is becoming more pervasive, which limits ISPs’ ability to glean information about user activity; and (3) users are increasingly shifting to VPNs to send traffic.

An informed reader might surmise that this writeup relates to the reclassification of Internet service providers under Title II of the Telecommunications Act, which gives the FCC a mandate to protect private information that ISPs learn about their customers. This private information includes both personal information, as well as information about a customer’s use of the service that is provided as a result of receiving service—sometimes called Customer Proprietary Network Information, or CPNI. One possible conclusion a reader might draw from this white paper is that ISPs have limited capability to learn information about customers’ use of their service and hence should not be subject to additional privacy regulations.

I am not taking a position in this policy debate, nor do I intend to make any normative statements about whether an ISP’s ability to see this type of user information is inherently “good” or “bad” (in fact, one might even argue that an ISP’s ability to see this information might improve network security, network management, or other services). Nevertheless, these debates should be based on a technical picture that is as accurate as possible.  In this vein, it is worth examining Professor Swire’s “factual description of today’s online ecosystem” that claims to offer the reader an “up-to-date and accurate understanding of the facts”. It is true that the report certainly contains many facts, but it also omits important details about the “online ecosystem”. Below, I fill in what I see as some important missing pieces. Much of what I discuss below I have also sent verbatim in a letter to the FCC Chairman. I hope that the original report will ultimately incorporate some of these points.

Claim 1: User Mobility Prevents a Single ISP from Observing a Significant Fraction of User Traffic

The report’s claim: Due to increased mobility, users are increasingly using many devices and connections, so any single ISP is the conduit of only a fraction of a typical user’s activity.

A missing piece: A single ISP can still track significant user activities from home network traffic and (as the user moves) through WiFi sharing services.

The report cites statistics from Cisco on the increase in mobile devices; these statistics do not offer precise information about how user traffic distributes across ISPs, but it’s reasonable to assume that users who are more mobile are not sending all of their traffic over a single access ISP.

Yet, a user’s increased mobility by no means implies that a single ISP cannot track users’ activities in their homes. Our previous research has shown that the traffic that users send in their home networks—typically through a single ISP—reveals significant information about user activity and behavior. The median home had about five connected devices at any give time. Simply by observing traffic patterns (i.e., without looking at any packet contents), we could determine the types of devices that users had in their homes, as well as how often (and how heavily) they used each device. In some cases, we could even determine when the user was likely to be home, based on diurnal traffic usage patterns. We could determine the most popular domains that each home visited.  The figure below shows examples of such popular domains.

Lots to learn from home network traffic. This example from our previous work shows an example of what an ISP can learn from network traffic popular domains from 25 home networks. The number of homes for which each domain appeared in the top 5 or top 10 most popular domains for that home.

Based on what we can observe from this traffic, it should come as no surprise that the data that we gathered—which is the same data an ISP can see—warrants special handling, due to its private nature. University Institutional Review Boards (IRBs) consider this type of work human subjects research because it “obtains (1) data through intervention or interaction with the individual; or (2) private, identifiable information”; indeed, we had to get special approval to even perform this study in the first place.

The report claims that user mobility may make it more difficult for a single ISP to track a user’s activity because a mobile user is more likely to connect through different ISPs.  But, another twist in this story makes me think that this deserves more careful examination: the rise of shared WiFi hotspots—such as Xfinity WiFi, which had deployed 10 million WiFi hotspots as of mid-2015, and which users had accessed 3.6 billion times—in some cases allow a single ISP to track mobile users more than they otherwise would be able to without such a service.

Incidentally, the report also says that “limited processing power and storage placed technical and cost limits [deep-packet inspection] capability”, but in the last mile, data-rates are substantially lower and can thus permit DPI.  For example, we had no trouble gathering all of the traffic data for our research on a simple, low-cost Netgear router running OpenWrt. : Most home networks we have studied are sending traffic at only tens of megabits per second, even at peak rate. We have been able to perform packet capture on very resource-limited devices at these rates.

Claim 2: End-to-End Encryption Limits ISP Visibility into User Behavior

The report’s claim: End-to-end encryption on websites is increasingly pervasive; thus, ISPs have limited visibility into user behavior .

A missing piece: ISPs can observe user activity based on general traffic patterns (e.g., volumes), unencrypted portions of communication, and the large number of in-home devices that do not encrypt traffic.

Nearly all Internet-connected devices use the Domain Name System (DNS) to look up domain names for specific Internet destinations. These DNS lookups are generally “in the clear” (i.e., unencrypted) and can be particularly revealing. For example, we conducted a recent study of traffic patterns from a collection of IoT devices; in that study, we observed, for example, that a Nest thermostat routinely performs a DNS lookup to frontdoor.nest.com, a popular digital photo frame routinely issued DNS queries to api.pix-star.com, and a popular IP camera routinely issued DNS queries to (somewhat ironically!) sharxsecurity.com. No sophisticated traffic analysis was required to identify the usage of these devices from plaintext DNS query traffic.

Even when a site uses HTTPS to communicate with an Internet destination, the initial TLS handshake typically indicates the hostname that it is communicating with using the Server Name Indication (SNI), which allows the server to present the client with the appropriate certificate for the corresponding domain that the client is attempting to communicate with. The SNI is transmitted in cleartext and naturally reveals information about the domains that a user’s devices are communicating with.

The report cites the deployment of HTTPS on many major websites as evidence that traffic from consumers is increasingly encrypted end-to-end. Yet, consumer networks are increasingly being equipped with Internet of Things (IoT) devices, many of which we have observed send traffic entirely in cleartext. In fact, of the devices we have studied, cleartext communication was the norm, not the exception. While of course, we all hope that many of these devices ultimately shift to using encrypted communications in the future, the current state of affairs is much different. Even in the longer term, it is possible that certain IoT devices may be so resource-limited as to make cryptography impractical, particularly in the case of low-cost IoT devices. The deployment of HTTPS on major websites is certainly encouraging for the state of privacy on the Internet in general, but it is a poor indicator for how much traffic from a home network is encrypted.

Claim 3: Users are Increasingly Using VPNs, Which Conceal User Activity from ISPs

The report’s claim: Users’ increasing use of VPNs encrypt all traffic, including DNS, as traffic traverses the ISP; therefore, ISPs cannot see any user traffic.

A missing piece: DNS traffic sometimes goes to the ISP’s DNS server after it exits the VPN tunnel. Configuring certain devices to use VPNs may not be straightforward for many users.

Apple just posted a remarkable “customer letter” on its web site. To understand it, let’s take a few steps back.

In a nutshell, one of the San Bernadino shooters had an iPhone. The FBI wants to root through it as part of their investigation, but they can’t do this effectively because of Apple’s security features. How, exactly, does this work?

• Modern iPhones (and also modern Android devices) encrypt their internal storage. If you were to just cut the Flash chips out of the phone and read them directly, you’d learn nothing.
• But iPhones need to decrypt that internal storage in order to actually run software. The necessary cryptographic key material is protected by the user’s password or PIN.
• The FBI wants to be able to exhaustively try all the possible PINs (a “brute force search”), but the iPhone was deliberately engineered with a “rate limit” to make this sort of attack difficult.
• The only other option, the FBI claims, is to replace the standard copy of iOS with something custom-engineered to defeat these rate limits, but an iPhone will only accept an update to iOS if it’s digitally signed by Apple. Consequently, the FBI convinced a judge to compel Apple to create a custom version of iOS, just for them, solely for this investigation.
• I’m going to ignore the legal arguments on both sides, and focus on the technical and policy aspects. It’s certainly technically possible for Apple to do this. They could even engineer their customized iOS build to measure the serial number of the iPhone on which it’s installed, such that the backdoor would only work on the San Bernadino suspect’s phone, without being a general-purpose skeleton key for all iPhones.

With all that as background, it’s worth considering a variety of questions.

Does the FBI’s investigation actually need access to the internals of the iPhone in question?

Apple’s letter states:

When the FBI has requested data that’s in our possession, we have provided it. Apple complies with valid subpoenas and search warrants, as we have in the San Bernardino case. We have also made Apple engineers available to advise the FBI, and we’ve offered our best ideas on a number of investigative options at their disposal.

In Apple’s FAQ on iCloud encryption, they describe how most iCloud features are encrypted both in transit and at rest, with the notable exception of email. So, if the San Bernadino suspect’s phone used Apple’s mail services, then the FBI can read that email. It’s possible that Apple genuinely cannot provide unencrypted access to other data in iCloud without the user’s passwords, but it’s also possible that the FBI could extract the necessary passwords (or related authentication tokens) from other places, like the suspect’s laptop computer.

Let’s assume, for the sake of discussion, that the FBI has not been able to get access to anything else on the suspect’s iPhone or its corresponding iCloud account, and they’ve exhausted all of their technical avenues of investigation. If the suspect used Gmail or some other service, let’s assume the FBI was able to get access to that as well. So what might they be missing? SMS / iMessage. Notes. Photos. Even knowing what other apps the user has installed could be valuable, since many of them have corresponding back-end cloud services, chock full of tasty evidence. Of course, the suspects emails and other collected data might already make for a compelling case against them. We don’t know.

Could the FBI still find a way into their suspect’s iPhone?

Almost certainly yes. Just yesterday, the big news was a security critical bug in glibc that’s been around since 2008. And for every bug like this that the public knows about, our friends in the government have many more that they keep to themselves. If the San Bernadino suspect’s phone is sufficiently valuable, then it’s time to reach into the treasure chest (both figuratively and literally) and engineer a custom exploit. There’s plenty of attack surface available to them. That attack surface stretches to the suspect’s personal computers and other devices.

The problem with this sort of attack plan is that it’s expensive, it’s tricky, and it’s not guaranteed to work. Since long before the San Bernadino incident, the FBI has wanted a simpler solution. Get a legal order. Get access. Get evidence. The San Bernadino case clearly spells this out.

What’s so bad about Apple doing what the FBI wants?

Apple’s concern is the precedent set by the FBI’s demand and the judge’s order. If the FBI can compel Apple to create a backdoor like this, then so can anybody else. You’ve now opened the floodgates to every small-town police chief, never mind discovery orders in civil lawsuits. How is Apple supposed to validate and prioritize these requests? What happens when they come from foreign governments? If China demands a custom software build to attack a U.S. resident, how is Apple supposed to judge whether that user and their phone happen to be under the jurisdiction of Chinese law? What if the U.S. then passes a law prohibiting Apple from honoring Chinese requests like this? That way lies madness, and that’s where we’re going.

Even if we could somehow make this work, purely as an engineering matter, it’s not feasible to imagine a backdoor mechanism that will support the full gamut of seemingly legal requests to exercise it.

Is backdoor engineering really feasible? What are the tradeoffs?

If there’s anything that the computer security community has learned over the years, it’s that complexity is the enemy of security. One highly relevant example is SSL/TLS support for “export-grade cryptography” — a bad design left over from the 1990’s when the U.S. government tried to regulate the strength of cryptographic products. Last year’s FREAK attack boils down to an exploit that forces SSL/TLS connections to operate with degraded key quality. The solution? Remove all export-grade cipher suites from SSL/TLS implementations, since they’re not used and not needed any more.

The only way that we know how to build secure software is to make it simple, to use state of the art techniques, and to get rid of older feature that we know are weak. Backdoor engineering is the antithesis of this process.

What are appropriate behaviors for an engineering organization like Apple? I’ll quote Google’s Eric Grosse:

Eric Grosse, Google’s security chief, suggested in an interview that the N.S.A.’s own behavior invited the new arms race.

“I am willing to help on the purely defensive side of things,” he said, referring to Washington’s efforts to enlist Silicon Valley in cybersecurity efforts. “But signals intercept is totally off the table,” he said, referring to national intelligence gathering.

“No hard feelings, but my job is to make their job hard,” he added.

As a national policy matter, we need to decide what’s more important: backdoor access to user data, or robustness against nation-state adversaries. If you want backdoor access, then the cascade of engineering decisions that will be necessary to support those backdoors will fundamentally weaken our national security posture. On the flip side, strong defenses are strong against all adversaries, including the domestic legal system.

Indeed, the FBI and other law enforcement agencies will need to come to terms with the limits of their cyber-investigatory powers. Yes the data you want is out there. No, you can’t get what you want, because cyber-defense must be a higher priority.

What are the alternatives? Can the FBI make do without what it’s asking?

How might the FBI cope in a world where Apple, Google, and other engineering organizations build walls that law enforcement cannot breach? I suspect they’ll do just fine. We know the FBI has remarkably good cyber-investigators. For example, the FBI hacked “approximately 1300” computers as part of a child pornography investigation. Likewise, even if phone data is encrypted, the metadata generated just walking around with a phone is amazing. For example, researchers discovered that

data from just four, randomly chosen “spatio-temporal points” (for example, mobile device pings to carrier antennas) was enough to uniquely identify 95% of the individuals, based on their pattern of movement.

In other words, even if you use “burner” phones, investigators can connect them together based on your patterns of movement. With techniques like this, the FBI has access to a mountain of data on their San Bernadino suspects, far more than they ever might have collected in the era before smartphones.

In short, the FBI’s worries that targets of its investigations are “going dark” are simply not credible, and their attempts to coopt technology companies into give them back doors are working against our national interests.

On Monday, the Telecom Regulatory Authority of India (TRAI) released a decision that effectively bans “zero-rated” Internet services in the country. While the notion of zero-rating might be somewhat new to many readers in the United States, the practice is common in many developing economies. Essentially, it is the practice by which a carrier creates an arrangement whereby its customers are not charged normal data rates for accessing certain content.

High-profile instances of zero-rating include Facebook’s “Free Basics” (formerly “Internet.org“) and Wikipedia Zero. But, many readers might be surprised to learn that the practice is impressively widespread. Although comprehensive documentation is hard to come by, experience and conventional wisdom affirm that mobile data carriers in regions across the world regularly partner with mobile data providers to provide services that are effectively free to the consumer, and these offerings tend to change frequently.

I experienced zero-rating first-hand on a trip to South Africa last summer. While on a research trip there, I learned that Cell C, a mobile telecom provider, had partnered with Internet.org to offer its subscribers free access to a limited set of sites through the Internet.org mobile application. I immediately wondered whether a citizen’s socioeconomic class could affect Internet usage—and, as a consequence, their access to information.

Zero-rating evokes a wide range of (strong) opinions (emphasis on “opinion”). Mark Zuckerberg would have us believe that Free Basics is a way to bring the Internet to the next billion people, where the alternative might be that this demographic might not have access to the Internet at all. This, of course, presumes that we equate “access to Facebook” with “access to the Internet”—something which at least one study has shown can occur (and is perhaps even more cause for concern). Others have argued that zero-rated services violate network neutrality principles and could also result in the creation of walled gardens where citizens’ Internet access might be brokered by a few large and powerful organizations.

And yet, while the arguments on zero-rating are loud, emotional, and increasingly higher-stakes, these opinions on either side have yet to be supported by any actual data.

We Must Bring Data to this Debate

Unfortunately, there is essentially  no data concerning the central question of how users adjust their behavior in response to mobile data pricing practices. Erik Stallman’s eloquent post today on the TRAI ruling and the Center for Democracy and Technology‘s recent white paper on zero-rating both lament the lack of data on either side of the debate.

I want to change that. To this end, as Internet measurement researchers and policy-interested computer scientists, we are starting to bring some data to this debate—although we still have a long way to go.

As luck would have it, we had already been gathering some data that shed some light on this question. In 2013, we developed a mobile performance measurement application, My Speed Test, which performs speed test measurements of a user’s mobile network, but also gathers information about a user’s application usage, and whether that usage occurs on the cellular data network or on a Wi-Fi network. My Speed Test has been installed on thousands of phones in several hundred countries around the world over this three-year period. In addition to a significant based of installations in the United States, we had several hundred users running the application in South Africa, due to a study of mobile network performance that we performed in the country a couple of years ago.

This deployment gave us a unique opportunity to study the application usage patterns of a group of users, across a wide range of carriers, across countries, over three years. It allowed us to look at usage patterns in the United States (where many users are on pre-paid plans) to South Africa (where most users are on pre-paid, pay-as-you-go plans).  It also allowed us to look at how users responded to zero-rated services in South Africa. A superstar undergraduate student, Ava Chen, led this research in collaboration with Enrico Calandro at Research ICT Africa and Sarthak Grover, a Ph.D. student here at Princeton. I briefly summarize some of Ava’s results below.

The results of this study are preliminary. More widespread deployment of My Speed Test would ultimately allow us to gather more data and draw more conclusive results. We can use your help by spreading the word about our work, and My Speed Test.

Effects of Zero Rating on Usage

We explored the extent to which the zero-rating offerings of various South African carriers affected usage patterns for different applications. During our data-collection period, mobile data provider Cell C offered its customers several zero-rating packages:

• From November 19, 2014 to August 31, 2015, Cell C zero-rated WhatsApp. From September 1, 2015 until now, Cell C adopted a bundle offer where, for a fee of ZAR 5 (about $0.30), users could use up to 1 GB on WhatsApp for 30 days, including voice calls.
• On July 1, 2015, Cell C began zero-rating Facebook’s Free Basics service.
• On two separate occasions—May 1–July 31, 2014 and August 1, 2014–February 13, 2015—MTN zero-rated Twitter.

We aimed to determine whether users adjusted their mobile behavior in response to these various pricing promotions. We found the following trends:

Cell C users increased WhatsApp usage by more than a factor of three on both cellular and Wi-Fi. The average monthly user for Cell C increased WhatsApp usage on the cellular network by a factor of three, from about 7 MB per month to about 22 MB per month on average. Interestingly, not only did the usage of WhatsApp on the cellular network increased, usage also increased on Wi-Fi networks, by more than a factor of seven—to about 17 MB per month. Interestingly, users still used WhatsApp more on the cellular data network than on Wi-Fi.

Cell C usage on WhatsApp increased on both WiFi and cellular in response to zero-rating a zero-rating offering from the carrier.

Twitter usage on MTN increased in response to zero-rating.  We limited our analysis of MTN’s zero-rating practices to 2014, because we did not have enough data to draw conclusive results from the second period. Our analysis of the 2014 period, however, found that  aside from the holiday season (when Twitter traffic is known to spike due to shopping promotions), the second most significant spike in usage on MTN occurred during the period from May through July 2014 when the zero-rating promotion was in effect. During this period the average Twitter user on MTN exchanged as much as 40 MB per day on Twitter, whereas usage outside of the promotional period was typically closer to about 10 MB per day.

Other Responses to Mobile Data Pricing

Mobile users in the United States use more mobile data, on both cellular and Wi-Fi. Mobile users in both the United States and South Africa used YouTube and Facebook extensively; other applications were more specific to country. We noticed some interesting trends. First, when looking at the total data usage for these applications in each country, the median user in the United States tended to use more data per month, not only on the cellular data network but also on Wi-Fi networks. It is understandable that South African users would be far more conservative with their use of cellular data; previous studies have noted this effect. It is remarkable, however, that these users also were more conservative with their data usage on Wi-Fi networks; this effect could also be explained that even Wi-Fi and wired Internet connections are still considerably more expensive (and more of a luxury good) than they seem to be in the United States. In contrast, users in the United States not only used more data in general, but they often used more data on average on cellular data networks than on Wi-Fi—perhaps as a result of the fact that users in the US were much less sensitive to the cost of mobile data than those in South Africa.

Mobile users in South Africa exchanged significantly more Facebook traffic than streaming video traffic—even when on cellular data plans. Given the high cost of cellular data in South Africa, we expected that users would be conservative with mobile data usage in general. Although our findings mostly confirmed this, Facebook was a notable exception: Not only did the typical user consume significantly more traffic using Facebook than with streaming video, users also exchanged more Facebook traffic over the cellular network than they did on Wi-Fi networks. This behavior suggests that Facebook usage is dominant to the extent that users appear to be more willing to pay for relatively expensive mobile data to use it than they are for other applications.

Summary and Request for Help

Our preliminary evidence suggests that zero-rated pricing structures may have an effect on usage of an application—not only on the cellular network where pricing instruments are implemented, but also in general. However, we need more data to draw stronger conclusions. We are actively seeking collaborations to help us deploy My Speed Test on a larger scale, to facilitate a larger-scale analysis.

To this end, we are excited to announce a collaboration with the Alliance for an Affordable Internet (A4AI) to use My Speed Test to study these effects in other countries on a larger scale. We are interested in gathering more widespread longitudinal data on this topic, through both organic installations of the application or studies with targeted recruitment.

Please let me know if you would like to help us in this important effort!

Despite statements to the contrary by sponsors and supporters in April 2014, August 2015, and October 2015, backers of the Defend Trade Secrets Act (DTSA) now aver that “cyber espionage is not the primary focus” of the legislation. At last month’s Senate Judiciary Committee hearing, the DTSA was instead supported by two different primary reasons: the rise of trade secret theft by rogue employees and the need for uniformity in trade secret law.

While a change in a policy argument is not inherently bad, the alteration of the core justification for a bill should be considered when assessing it. Perhaps the new position of DTSA proponents acknowledges the arguments by over 40 academics, including me, that the DTSA will not reduce cyberespionage. However, we also disputed these new rationales in that letter: the rogue employee is more than adequately addressed by existing trade secret law, and there will be less uniformity in trade secrecy under the DTSA because of the lack of federal jurisprudence.

The downsides — including weakened industry cybersecurity, abusive litigation against small entities, and resurrection of the anti-employee inevitable disclosure doctrine — remain. As such, I continue to oppose the DTSA as a giant trade secrecy policy experiment with little data to back up its benefits and much evidence of its costs.