COMMISSION REPORT FEBRUARY 2018

Agency decision

Ask Donna

What actually matters in this document.

Text

1100000110010001100001011101000110010101110011010101010110111001100100011001010111001001110011011101000110000101101110011001000110100101101110011001110111010001101000011001010100100101110

10101011100000110010001100001011101000110010101110011010101010110111001100100011001010111001001110011011101000110000101101110011001000110100101101110011001110111010001101000011001010100100

COMMISSION REPORT FEBRUARY 2018

10100110110010101100011011101010111001001101001011101000111100101010101011100000110010001100001011101000110010101110011010101010110111001100100011001010111001001110011011101000110000101101110011

Federal Trade Commission

10010110110001100101010100110110010101100011011101010111001001101001011101000111100101010101011100000110010001100001011101000110010101110011010101010110111001100100011001010111001001110011011101

10110001001101001011011000110010101010011011001010110001101110101011100100110100101110100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100011000010110111001100100011010010110111001100111011101000110100001100

00100110100101110100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001

0110100101110100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100011000010110111001100100011010010110111001100111011

0100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100011000010110111001100100011010010110111001100111011101000110100

01011000110111010101110010011010010111010001111001010101010111000001100100011000010111010001100101011100110101010101101110011001000

10010011010010111010001111001010101010111000001100100011000010111010001100101011100110101010101101110011001000110010101110010011100

10100101110100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110

1100101010101011100000110010001100001011101000110010101110011010101010110111001100100011001010111001001110011011101000110000101101

00011011101010111001001101001011101000111100101010101011100000110010001100001011101000110010101110011010101010110111001100100011001010111001001110011011101000110000101101110011001000110100

0000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100011000010110111001100100011010010110111001100111011101000110100001100101010010010111001

10110110001100101010100110110010101100011011101010111001001101001011101000111100101010101011100000110010001100001011101000110010101110011010101010110111001100100011001010111001001110011011101000

11110110001001101001011011000110010101010011011001010110001101110101011100100110100101110100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100011000010110111001100100011010010110111001100111011101000110100001

11011110110001001101001011011000110010101010011011001010110001101110101011100100110100101110100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011

01011011000110010101010011011001010110001101110101011100100110100101110100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100

01110100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100011

1110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100011000010110111001100100011010010110111001100111011101000110100001100

10100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100011000010110111001100100011010010110111001100111011101000110100

1010101110010011010010111010001111001010101010111000001100100011000010111010001100101011100110101010101101110011001000110010101110

0111010001111001010101010111000001100100011000010111010001100101011100110101010101101110011001000110010101110010011100110111010001

10111000001100100011000010111010001100101011100110101010101101110011001000110010101110010011100110111010001100001011011100110010001

01001101001011101000111100101010101011100000110010001100001011101000110010101110011010101010110111001100100011001010111001001110011011101000110000101101110011001000110100101101110011001110

01011101000110010101110011010101010110111001100100011001010111001001110011011101000110000101101110011001000110100101101110011001110111010001101000011001010100100101110011011100110111010101

0100110110010101100011011101010111001001101001011101000111100101010101011100000110010001100001011101000110010101110011010101010110111001100100011001010111001001110011011101000110000101101110011

00110010101010011011001010110001101110101011100100110100101110100011110010101010101110000011001000110000101110100011001010111001101010101011011100110010001100101011100100111001101110100011000010110111001100100011010010110111001100111011101000110100001100101010010010111001101110

1101100011001010101001101100101011000110111010101110010011010010111010001111001010101010111000001100100011000010111010001100101011100110101010101101110011001000110010101110010011100110111010001100001011011100110010001101001011011100110011101110100011010000110010101001001011100

Mobile Security Updates:

Understanding the Issues

Mobile Security Updates:

Understanding the Issues

A Commission Report

February 2018

FEDERAL TRADE COMMISSION

Maureen K. Ohlhausen, Acting Chairman

Terrell McSweeny, Commissioner

Mobile Security Updates: Understanding the Issues

Contents

Executive Summary ........................................................................................................... 1

II.

Preliminary Findings ................................................................................................. 3

Characteristics of Some Industry Participants .......................................................................... 3

Benefits and Risks .................................................................................................................... 4

Recommendations .................................................................................................................... 5

Introduction ................................................................................................................ 7

The Commission’s Past Efforts to Improve Mobile Device Security and Security Update

Practices ................................................................................................................................. 11

Mobile Security Study ............................................................................................................ 14

Securing Mobile Devices .........................................................................................17

Mobile Malware: Risk and Harm ........................................................................................... 18

Mitigating the Threat: Patching in a Complex Ecosystem ..................................................... 20

III. The Security Update Process .................................................................................. 24

Identifying Vulnerabilities and Affected Devices .................................................................. 24

Deciding Whether to Update Specific Devices ...................................................................... 25

Deciding When to Update Specific Devices .......................................................................... 26

Security Update Testing ......................................................................................................... 27

Installing the Security Update ................................................................................................ 31

IV. Security Support Practices ......................................................................................33

Duration of Security Update Support ..................................................................................... 33

Mobile Security Updates: Understanding the Issues

Public Statements about Update Support .............................................................................. 33

Device Manufacturer Update Support Data .......................................................................... 36

Security Update Frequency .................................................................................................... 42

Public Statements about Update Frequency .......................................................................... 43

Security Update Frequency Data ........................................................................................... 45

Patch Development and Testing ............................................................................................. 50

Uptake Rates ........................................................................................................................... 58

Security Update Information For Consumers ...................................................... 61

VI. Findings and Recommendations............................................................................. 65

Preliminary Findings .............................................................................................................. 65

Characteristics of Some Industry Participants ....................................................................... 65

Benefits and Risks ................................................................................................................. 67

Recommendations .................................................................................................................. 68

Recommendations for Consumer Education ......................................................................... 68

Recommendations for Industry Best Practices ...................................................................... 69

VII. Conclusion ................................................................................................................74

Appendix A .....................................................................................................................A-1

Order to File a Special Report ..................................................................................................I

Attachment A ......................................................................................................................... .II

Appendix B.......................................................................................................................B-I

Letter from Federal Communications Commission to [Carrier] ............................................. I

Questions to [Carrier] on Mobile Device Security ..................................................................II

Appendix C ......................................................................................................................C-I

Manufacturer Update Support Period .................................................................... 2

Mobile Security Updates: Understanding the Issues

II.

Data and Variables Considered ............................................................................................... 2

Univariate Analysis ................................................................................................................. 3

Multivariate Analysis............................................................................................................... 5

Manufacturer Update Frequency............................................................................. 7

Data and Variables Considered ............................................................................................... 7

Univariate Analysis ................................................................................................................. 7

Multivariate Analysis............................................................................................................... 9

Device Release Date and Update Frequency ......................................................................... 11

a. Univariate Analysis .............................................................................................................. 11

b. Multivariate Analysis ........................................................................................................... 13

III. Patch Development and Testing ............................................................................. 14

Device Manufacturers............................................................................................................. 14

Data and Variables Considered ............................................................................................. 14

Univariate Analysis ............................................................................................................... 16

Multivariate Analysis............................................................................................................. 23

OS Developers ........................................................................................................................ 26

Data and Variables Considered ............................................................................................. 26

Univariate Analysis ............................................................................................................... 27

Multivariate Analysis............................................................................................................. 29

IV. Uptake Rate of Security Updates ........................................................................... 30

Data and Variables Considered ............................................................................................. 31

Univariate Analysis ............................................................................................................... 32

Multivariate Analysis............................................................................................................. 35

Mobile Security Updates: Understanding the Issues

Executive Summary

Thanks to our smartphones and tablets, we shop, bank, play, read, post, watch, date, record, and

search on the go. Three-quarters of Americans own smartphones 1 and most check their devices four

times or more every hour. 2 Many consumers access the Internet primarily, or exclusively, through their

phones. 3 Adults are not alone in their devotion to mobile devices; over the last few years, children under

eight have tripled their daily mobile device screen time 4 and more than 90% of teenagers go online by

mobile device. 5

As these astounding use statistics suggest, consumers can derive enormous benefits from mobile

technology. But reaping those benefits is contingent, in part, on consumers’ willingness to trust the

technology. A basic component of that trust is fulfilling consumers’ expectation of reasonable security

to protect the sensitive data about lifestyle, health, location, finances, and identity that mobile devices

collect, store, and transmit. 6

Security researchers and government agencies have consistently maintained that the best way to

secure consumer information is to take reasonable steps to design secure products and maintain their

security with updates that patch vulnerabilities in device software. 7 Despite this consensus, security

researchers and industry observers have reported that many mobile devices’ operating systems (the

PEW RESEARCH CENTER, MOBILE FACT SHEET (Feb. 5, 2018), http://www.pewinternet.org/fact-sheet/mobile/ [hereinafter

PEW MOBILE FACT SHEET].

Jane E. Brody, Hooked on Our Smartphones, N.Y. TIMES, Jan. 9, 2017,

https://www.nytimes.com/2017/01/09/well/live/hooked-on-our-smartphones.html (reviewing book that notes that most

people check their smartphones every six minutes); SWNS, Americans Check Their Phones 80 Times a Day: Study, N.Y.

POST, Nov. 8, 2017, https://nypost.com/2017/11/08/americans-check-their-phones-80-times-a-day-study/ (reporting on study

claiming that Americans check their phone on average once every 12 minutes).

PEW MOBILE FACT SHEET, supra note 1 (describing “just over one-in-ten American adults” as “‘smartphone-only’ internet

users”).

COMMON SENSE MEDIA, THE COMMON SENSE CONSENSUS: MEDIA USE BY KIDS AGE ZERO TO EIGHT, 3 (2017),

https://www.commonsensemedia.org/research/the-common-sense-census-media-use-by-kids-age-zero-to-eight-2017 (follow

“Read Full Report” link).

PEW RESEARCH CENTER, TEENS, SOCIAL MEDIA & TECHNOLOGY OVERVIEW 2015, 14-15 (Apr. 2015),

http://assets.pewresearch.org/wp-content/uploads/sites/14/2015/04/PI_TeensandTech_Update2015_0409151.pdf.

PEW RESEARCH CENTER, AMERICANS & CYBERSECURITY, 3 (Jan. 26, 2017), http://assets.pewresearch.org/wpcontent/uploads/sites/14/2017/01/26102016/Americans-and-Cyber-Security-final.pdf (reporting that 70% of Americans are at

least “somewhat confident” in the ability of their device manufacturer to protect their data) [hereinafter AMERICANS &

CYBERSECURITY].

See infra Parts I.A, II.B.

Mobile Security Updates: Understanding the Issues

software that powers the devices’ basic functions) are not receiving the security patches they need to

protect them from critical vulnerabilities. 8 As a result, many mobile devices are vulnerable to a wide

range of malware (malicious software) attacks, including spyware, phishing, and ransomware. 9 Each of

these malware variants can put consumers at risk of identity theft scams, fraudulent charges, or device

compromise, which can cost consumers hundreds or thousands of dollars. 10

In May 2016, the Federal Trade Commission (“FTC” or “Commission”) issued identical Orders

to File Special Reports (“Orders”) under section 6(b) of the Federal Trade Commission Act to eight

device manufacturers to gather information about their security update procedures and practices. 11 The

respondents—Apple, Blackberry, Google, HTC, LG, Microsoft, Motorola, and Samsung—comprise

most of the U.S. mobile device market 12 and represent some of the variety of the mobile ecosystem.

Collectively, they use, or have used, four different operating systems, including the two dominant

operating systems in the U.S. (Android and iOS). 13 A few, such as Apple and Microsoft, sell relatively

few models powered by their own operating system. By contrast, several, including HTC, LG, Motorola,

and Samsung, have large device portfolios whose phones and tablets run device-specific customizations

of the Android operating system.

This Report summarizes the information provided in response to the Commission’s Orders, as

well as responses to a parallel inquiry initiated by the Federal Communications Commission (“FCC”)

into mobile carriers’ security updates practices. 14 The data provided in response to these inquiries is not

sufficiently representative to permit definitive conclusions about industry practices as a whole.

Nevertheless, the companies’ narrative responses and several detailed data sets provide remarkable

insight into the security update practices that affect a large proportion of the devices on the U.S. market.

See infra Part I.

See infra Part II.A.

See id.

Press Release, Fed. Trade Comm’n, FTC To Study Mobile Device Industry’s Security Update Practices (May 9, 2016),

https://www.ftc.gov/news-events/press-releases/2016/05/ftc-study-mobile-device-industrys-security-update-practices

[hereinafter, FTC Press Release].

Press Release, comScore, ComScore Reports June 2017 U.S. Smartphone Subscriber Market Share (Aug. 3, 2017),

https://www.prnewswire.com/news-releases/comscore-reports-june-2017-us-smartphone-subscriber-market-share300498296.html.

Id.

See Press Release, Fed. Comm. Comm’n, FCC Wireless Telecommunications Bureau Launches Inquiry into Mobile

Device Security Updates (May 9, 2016), https://apps.fcc.gov/edocs_public/attachmatch/DOC-339256A1.pdf [hereinafter,

FCC Press Release].

Mobile Security Updates: Understanding the Issues

Based on this data, publicly available materials, and the Commission’s long experience with mobile

security and disclosure issues, this report highlights practices that may be conducive to assuring that

consumers shop, bank, play, read, post, date, record, and search with reasonably secure devices.

I. Preliminary Findings

Characteristics of Some Industry Participants

•

Because of the complexity of the mobile ecosystem, the security update process can be

complex and time-consuming. Many device manufacturers customize third-party operating

system software at the device level, either to introduce new features or at the request of a carrier

partner. As a result, a single operating system update may require dozens or hundreds of

different device-level modifications, all of which may be tested by carrier partners (and,

sometimes, additional third parties). Carrier testing labs with finite resources must accommodate

hundreds of updates from multiple device manufacturers. As a result, there are many reasons

why a security update may take weeks, months, or even years to be completed.

•

Industry participants have taken steps to streamline the security update process but

bottlenecks remain. Over the past two years, operating system developers, device

manufacturers and carriers have implemented new policies and practices to improve the security

update process, such as security-only updates and regular security update schedules. To some

extent, these efforts are working, but adoption of these changes is uneven and significant time

gaps between discovery of vulnerabilities and patching likely still exist.

•

Support periods and update schedules are highly variable. Formal support policies are rare.

Many manufacturers prefer just-in-time support decisions, based on an informal assessment of

factors such as the device’s age and popularity, the cost of support, partner input, the severity of

the vulnerability, and regularly scheduled releases. As a result, update support periods and

update schedules are highly variable.

•

Device manufacturers that develop and control their own operating systems tend to commit

in advance to longer support periods (usually for several years) for devices. Because they

tend not to customize their operating system for particular devices, certain support costs (e.g., for

patch implementation and carrier testing) are likely lower.

•

Some device manufacturers state that they do not commit to firm update support periods

or schedules because they cannot anticipate market conditions. Several manufacturers

reported that it is difficult to predict (and share with consumers) update support periods and

update schedules, because update support decisions turn on unpredictable variables like

popularity. Some data, however, suggests that support period length (for at least some

manufacturers) is slightly more closely correlated with device price and age than popularity.

Mobile Security Updates: Understanding the Issues

Manufacturers interested in publicizing update support period may be able to learn from past

update support practices related to device price and age to inform update support estimates.

•

Many device manufacturers do not maintain regular records about update support. A

number of manufacturers reported that they could not provide data in response to the

Commission’s Order because they do not record information about update support decisions,

customized patch development time, carrier testing time, deployment time, or uptake rate. At the

same time, manufacturer-carrier communications revealed that when companies do record,

study, and share their data, they have gleaned important insights that lead to practice

improvements.

•

Manufacturers provide little express information about support period, update frequency,

and end of update support. Some manufacturers make information about security update

support (e.g., minimum support period, support end date, update frequency) available to

consumers before purchase. Many, however, do not, or do not make this information available

for all of their devices. And few, if any, manufacturers or carriers explain that apparently

identical devices may receive different security update support based on the type of service the

consumer selects (e.g., unlocked, WiFi-only, major or budget carrier). Although most device

manufacturers do notify consumers when a security update is available, most do not inform users

when a phone is about to stop receiving support or when it has in fact stopped receiving security

updates.

Benefits and Risks

•

The mobile ecosystem’s diversity provides extensive consumer choice, but also contributes

to security update complexity and inconsistency. Thanks to the diverse and competitive

mobile ecosystem and to the device-level customizations made possible by free and customizable

operating systems, consumers can choose from thousands of different device-service

combinations at a wide variety of price points. Variety, however, does have costs: Operating

system customization at the device level can prevent uniform security patch application, increase

the time and cost to develop, test, and deploy security updates, and may lead to shorter update

support periods and less frequent updates. Indeed, device manufacturers that customize

operating systems across a wide range of devices tend to support phones for shorter periods—

most often less than a year or two from device release.

•

Device manufacturers’ security support decisions enable flexible responses to market

conditions, but make security support periods and schedules more uncertain. Device

manufacturers’ case-by-case decision-making process can help to control update support costs

that might otherwise be passed onto consumers through higher prices. A byproduct of just-intime decision-making, however, is that it impedes advanced commitments about update support

that might benefit security-conscious consumers.

Mobile Security Updates: Understanding the Issues

•

Each respondent focuses support on newer products and several focus update support on

costlier, more popular devices. Each respondent reported prioritizing new products (whether

measured by device or operating system age) for update support. Data we received suggests a

tendency in practice to allocate update support towards more expensive and more popular

models. Consumers benefit from the availability of older phones at lower prices whose discount

reflects, in part, the reduced update support they receive. But failing to patch critical

vulnerabilities on older, cheaper, or less popular devices creates risks for some device owners.

•

Carrier involvement in the security update process contributes to stability but can lead to

delays. Carrier involvement can benefit consumers: Carriers sometimes use their influence with

manufacturers to encourage good patching practices, carrier testing helps to ensure continued

device and network performance, and carriers bring considerable experience to update

deployments. Carrier involvement comes at a cost, as well: Carriers with overcrowded testing

labs sometimes resist security updates or delay testing for updates that include security patches.

Recommendations

The Commission commends industry for its efforts to expedite the security update process. We

now call on advocacy groups and industry to continue these efforts by considering the recommendations

below, each of which is explained in greater detail in Part VI of the Report.

First, there is a significant opportunity for government, industry, and advocacy groups to work

together to educate consumers about their role in the operating system update process and the

significance of security update support. The more consumers understand the importance of updates, the

more likely they are to install available updates and to consider security update support when making

purchasing, use, and upgrade decisions.

Second, there is an opportunity for industry—device manufacturers, operating system

developers, and wireless carriers—to continue their efforts to “start with security” 15 by embedding

security further into design and support culture and decisions. To that end, industry should ensure that

all mobile devices receive operating system security updates for a period of time that is consistent with

consumers’ reasonable expectations. Support for particular devices will, of course, vary depending on

the circumstances. Reasonable security support should be a shared priority, reflected in policies,

practices, and contracts throughout the mobile ecosystem. When making decisions about operating

system design or about whether to launch a customized device, developers and manufacturers should

consider how their decisions will affect their commitment to reasonable security update support.

FED. TRADE COMM’N, START WITH SECURITY: A GUIDE FOR BUSINESS (June 2015),

https://www.bulkorder.ftc.gov/system/files/publications/pdf0205-startwithsecurity.pdf [hereinafter START WITH SECURITY].

Mobile Security Updates: Understanding the Issues

Third, we recommend that industry prepare for the future by learning from the past. Companies

involved in the security update process should consider keeping and consulting records about support

length, update frequency, customized patch development time, testing time, and uptake rate. Companies

should then consider sharing such information with partners so that industry can fashion policies and

practices based on what they learn.

Fourth, industry should continue to streamline the security update process. In particular,

companies should patch vulnerabilities in security-only updates when the benefits of more immediate

action outweigh the convenience of a bundled security-functionality update. Companies that test updates

(or impose testing requirements) should make sure that their processes and requirements are compatible

with industry’s commitment to timely security updates. And companies that deploy updates should

continue to explore ways to improve the rate at which consumers install updates.

Finally, we recommend that device manufacturers consider giving consumers more and better

information about security update support. Specifically, manufacturers interested in providing security

update information should consider adopting and disclosing minimum guaranteed security support

periods (and update frequency) for their devices. They should also consider giving device owners

prompt notice when security support is about to end (and when it has ended), so that consumers can

make informed decisions about device replacement or post-support use.

Mobile Security Updates: Understanding the Issues

Introduction

Mobile phone use is ubiquitous in America: 95% of Americans own a cell phone and more than

three-quarters own a smartphone. 16 Smartphones are as important to consumers as they are ubiquitous:

Consumers use their smartphones to research health conditions, do their banking, look for information

about jobs and government services, take classes, submit applications, and buy a host of products. 17

Many consumers now rely primarily on their smartphones for Internet access. 18 Adults younger than 30,

those with lower incomes and educational attainment, and non-whites are particularly likely to go online

primarily by phone. 19

As consumers’ tool of choice to store and transmit sensitive information, mobile devices are

obvious targets for attack. With a compromised smartphone, an attacker could steal sensitive user data, 20

freeze the device until a ransom is paid, 21 or be part of a denial-of-service attack on another target. 22

Threats are escalating: A March 2017 security report describes an “all-time high in mobile device

infections,” 23 and several other recent studies have similarly found a significant increase in attacks on

mobile devices. 24

Survey research data shows that Americans trust their mobile device manufacturer to protect

their data more than they trust their credit card companies, email providers, retailers, the government, or

PEW MOBILE FACT SHEET, supra note 1.

See, e.g., PEW RESEARCH CENTER, U.S. SMARTPHONE USE IN 2015, 5 (Apr. 1, 2015),

http://www.pewinternet.org/files/2015/03/PI_Smartphones_0401151.pdf [hereinafter PEW SMARTPHONE USE].

PEW MOBILE FACT SHEET, supra note 1.

Id.; PEW SMARTPHONE USE, supra note 17 at 17.

Robin Sidel, Mobile Bank Heist: Hackers Target Your Phone, WALL ST. J., Aug. 26, 2016,

https://www.wsj.com/articles/mobile-bank-heist-hackers-target-your-phone-1472119200.

Allen St. John, Smartphone Ransomware Is a Looming Threat, CONSUMER REPORTS, Jan. 24, 2017,

http://www.consumerreports.org/digital-security/smartphone-ransomware-a-looming-threat/.

Ryan Knutson, The Night Zombie Smartphones Took Down 911, WALL ST. J., Mar. 3, 2017,

https://www.wsj.com/articles/how-a-cyberattack-overwhelmed-the-911-system-1488554972.

Press Release, Nokia, Nokia Malware Report Reveals New All-Time High in Mobile Device Infections and Major IoT

Device Security Vulnerabilities (Mar. 27, 2017), https://www.nokia.com/en_int/news/releases/2017/03/27/nokia-malwarereport-reveals-new-all-time-high-in-mobile-device-infections-and-major-iot-device-security-vulnerabilities [hereinafter

Nokia Report Press Release].

See, e.g., MCAFEE, TROJANS, GHOSTS, AND MORE MEAN BUMPS AHEAD FOR MOBILE AND CONNECTED THINGS: WHAT

LIES AHEAD FOR 2017, 2 (Feb. 2017), https://www.mcafee.com/us/resources/reports/rp-mobile-threat-report-2017.pdf.

Mobile Security Updates: Understanding the Issues

social media sites. 25 Security researchers, however, have raised questions about whether this high level

of trust is consistent with the security support manufacturers actually provide. Specifically, researchers

have reported in recent years that many mobile devices have not received operating system software

updates to patch known vulnerabilities. For example, in a 2015 study, researchers at the University of

Cambridge found that nearly 88% of Android devices had at least one of 11 known critical

vulnerabilities. 26

One event, in July 2015, focused attention on the harm that could result from slow security

patching. At the Black Hat security conference in Las Vegas, security researcher Joshua Drake

announced the discovery of a number of “Stagefright” vulnerabilities—critical vulnerabilities that put

950 million Android devices at risk of infection by text message-transmitted malware. Following the

event, many observers expressed concern that industry patching practices impeded adequate responses

to serious threats. 27

Stagefright became a seminal moment for the industry. In response, Android operating system

developer Google, Inc. and a number of Android device manufacturers made highly publicized changes

to their security practices to improve patching speed and regularity. 28 Despite improvements, security

researchers and industry observers have continued to report security update gaps. For example, in mid2016, a security research firm published data analysis indicating that only 17% of Android phones were

operating with the latest security patch, and about a third had 24 critical vulnerabilities. 29 In mid-2017,

AMERICANS & CYBERSECURITY, supra note 6 at 3. This survey also reports that more Americans trust their carriers than

their email providers, retailers, government, or social media. See id.

Thomas et al., Security Metrics for the Android Ecosystem, 2015 PROCS. OF THE 5TH ANN. ACM CCS WORKSHOP ON

SECURITY & PRIVACY IN SMARTPHONES & MOBILE DEVICES 87, https://www.cl.cam.ac.uk/~drt24/papers/spsm-scoring.pdf.

See, e.g., Thomas Fox-Brewster, Stagefright: It Only Takes One Text To Hack 950 Million Android Phones, FORBES, July

27, 2015, http://www.forbes.com/sites/thomasbrewster/2015/07/27/android-text-attacks/#39649574715c.

See, e.g., Russell Brandom, How the Stagefright Bug Changed Android Security, THE VERGE, Aug. 5, 2015,

http://www.theverge.com/2015/8/5/9099627/google-stagefright-android-vulnerability-protect-patch. Some of these initiatives

are described in Part III of this Report.

Olabode Anise, Thirty Percent of Android Devices Susceptible to 24 Critical Vulnerabilities, DUO LABS SECURITY BLOG

(June 28, 2016), https://duo.com/blog/thirty-percent-of-android-devices-susceptible-to-24-critical-vulnerabilities. In its

Android Security 2016 Year in Review report, Google reported that by the end of 2016, “over half” of the top 50 Android

devices worldwide had a recent security patch. See ANDROID SECURITY 2016 YEAR IN REVIEW, GOOGLE, 5 (Mar. 2017),

https://source.android.com/security/reports/Google_Android_Security_2016_Report_Final.pdf [hereinafter “2016 ANDROID

SECURITY REPORT”]. The 2017 Android report is not yet available.

Mobile Security Updates: Understanding the Issues

technology press reported that only 7% of devices with Google Play installed were running the latest

version of Android, which has the most up-to-date security protections. 30

In May 2016, the Commission issued identical Orders to eight device manufacturers to gather

information about their security update processes and practices since August 1, 2013. 31 This report

makes findings and recommendations about mobile operating systems patching based on the narrative

responses, data, and communications that the manufacturers submitted. The report also reflects

information gathered through follow-up communications, from publicly available sources, and from

responses to a parallel inquiry by the FCC into mobile carriers’ security update practices. 32

Importantly, device manufacturers do not find security flaws and issue security updates in

isolation. Rather, a host of players—system-on-a-chip manufacturers, operating system developers,

application (“app”) developers, other third-party software developers, carriers, and security

researchers—may be involved in pinpointing security vulnerabilities, developing patches, customizing

those patches for particular devices and carriers, testing the patches, deploying the updates, and

notifying consumers.

Depending on the severity of the vulnerability, the number of parties involved, and their

contractual relationships and norms, patching a device may take a few weeks or many months or years.

A device may receive security updates every month, a few times a year, once a year, or not at all. Some

devices receive regular updates for three years or longer while other devices do not receive any updates

after a few months. 33

Paul Wagenseil, Here’s Which Android Phones Get Regular Security Updates, TOM’S GUIDE, June 2, 2017,

https://www.tomsguide.com/us/android-security-update-list,news-25221.html (“Phones that install the latest security updates

are a small but growing minority in the Android world.”)

FTC Press Release, supra note 11.

See FCC Press Release, supra note 14.

See infra Part IV.A.2 (describing respondents’ update practices).

Mobile Security Updates: Understanding the Issues

Key Players

Who?

Short Term

Original Equipment

Manufacturer

OEM

Operating System

Developer

OS Developer

What?

Examples

Manufacturer of

mobile devices.

Referred to in this

Report as device

manufacturer or

manufacturer.

The Order respondents:

Apple, Blackberry, Google,

HTC, LG, Microsoft,

Motorola Samsung.

Company that creates

the operating system

software for mobile

devices.

Google as Android

operating system developer,

Apple as iOS developer

Microsoft as Windows OS

developer.

System-on-a-chip

Manufacturer

System-on-a-chip

or SoC

Manufacturer of

computer components

that power mobile

devices.

Broadcomm, Nvidia,

Qualcomm.

Wireless carrier

Carrier

Provider of wireless

telecommunication

services. Referred to

in this Report as

carriers.

AT&T, Verizon, Sprint, TMobile.

Mobile Virtual

Network Operator

MVNO

A wireless carrier that

does not own any

network facilities, but

instead purchases

mobile wireless

services wholesale

from facilities-based

service providers and

resells these services

to consumers.

Tracfone, Boost, Virgin

Mobile.

FED. COMM. COMM’N, FCC 17-126, ANNUAL REPORT AND ANALYSIS OF COMPETITIVE MARKET CONDITIONS WITH

RESPECT TO MOBILE WIRELESS INCLUDING COMMERCIAL MOBILE SERVICE (2017),

https://apps.fcc.gov/edocs_public/attachmatch/FCC-17-126A1.pdf.

Mobile Security Updates: Understanding the Issues

The Commission’s Past Efforts to Improve Mobile

Device Security and Security Update Practices

The FTC is an independent agency charged with protecting consumers and promoting

competition. As part of its consumer protection mandate, the FTC enforces a wide range of laws to

protect the privacy and security of consumer data, including the FTC Act, which prohibits “unfair” and

“deceptive” acts or practices in or affecting commerce. 35 Using its enforcement tools, the FTC has

brought over 500 privacy and security-related cases. 36

Through enforcement, policy, and education initiatives, the Commission has addressed an array

of privacy and security issues presented by the explosive growth of mobile technology. For example, the

Commission brought enforcement actions against a mobile device manufacturer, 37 mobile app

developers, 38 and mobile advertising networks. 39 The Commission hosted a public forum on mobile

security issues, in which security researchers, academics and industry representatives discussed threats

to mobile devices, mobile security challenges, and consumer behaviors regarding mobile security. 40 The

15 U.S.C. § 45(a). The FTC also enforces statutes that protect certain health, credit, financial, and children’s information,

and has issued regulations implementing each of these statutes. See, e.g., Health Breach Notification Rule, 16 C.F.R. Part 318

(health information breach notification); Fair Credit Reporting Act, 15 U.S.C. § 1681 et seq. and 16 C.F.R. Part 600

(consumer reporting information security and privacy); Gramm-Leach-Bliley Act Safeguards Rule, 16 C.F.R. Part 314

(financial information security); Children’s Online Privacy Protection Act of 1998, 15 U.S.C. § 6501 et seq. and 16 C.F.R.

Part 412 (children’s online information security and privacy).

Thomas B. Pahl, BCP Acting Dir., Fed. Trade Comm’n, Remarks at ABA/FCBA Privacy and Data Security Symposium

(Mar. 21, 2017), https://www.ftc.gov/system/files/documents/public_statements/1225563/pahl_-_aba_fcba_speech_3-2117.pdf.

HTC America, Inc., No. C-4406 (F.T.C. June 25, 2013),

https://www.ftc.gov/sites/default/files/documents/cases/2013/07/130702htcdo.pdf (Decision and Order).

Fed. Trade Comm’n v. Equiliv Investments, No. 2:2015 cv 04379 (D.N.J. June 24, 2015),

https://www.ftc.gov/system/files/documents/cases/150625equilivstip.pdf (Stipulated Order); General Workings Inc., No. C4573 (F.T.C. Apr. 18, 2016), https://www.ftc.gov/system/files/documents/cases/1604vulcundo.pdf (Decision and Order).

Turn, Inc., No. C-4612 (F.T.C. Apr. 6, 2017),

https://www.ftc.gov/system/files/documents/cases/152_3099_c4612_turn_decision_and_order.pdf (Decision and Order);

United States. v. InMobi Pte Ltd., No. 3:16-cv-3474 (N.D. Cal. June 22, 2016),

https://www.ftc.gov/system/files/documents/cases/160622inmobistip.pdf (Stipulated Order).

Press Release, Fed. Trade Comm’n, FTC Announces Mobile Security Forum: Potential Threats & Solutions (May 24,

2013), https://www.ftc.gov/news-events/press-releases/2013/05/ftc-announces-agenda-panelists-upcoming-mobile-securityforum [hereinafter Forum Press Release]. The forum convened four panels that included security researchers, academics and

industry representatives who discussed threats to mobile devices, mobile-specific security challenges, efforts to secure

devices, the role of each player in the complex mobile ecosystem with respect to security, and consumer behaviors regarding

mobile security. Several participants described formidable obstacles to patching mobile devices: the complexity of the mobile

ecosystem and diffuseness of responsibility for patching. After the forum, the Commission sought further comment on a

number of topics discussed in the forum, including security updates. Press Release, Fed. Trade Comm’n, FTC Invites Further

Mobile Security Updates: Understanding the Issues

FTC has testified before Congress about consumer privacy in the mobile marketplace 41 and on mobile

devices. 42 Building on lessons from enforcement actions and workshops, the Commission has issued

guidance and tools for mobile app developers. 43

The Commission has consistently emphasized that reasonable security requires secure product

design and maintenance of security through timely and effective software patching. For example, in

2013, the Commission entered into a consent order with mobile device manufacturer HTC America that

settled allegations that HTC had put the sensitive information of millions of consumers at risk by

introducing security vulnerabilities in the design of its phones. 44 As part of the settlement, HTC agreed

to implement and maintain a comprehensive security program; to undergo independent security audits;

and to develop, release, and notify consumers about software patches to fix the specific vulnerabilities

identified during the investigation. 45

Similarly, in 2016, the Commission settled two complaints alleging that a router manufacturer

(ASUS) and software manufacturer (Oracle) had engaged in unfair and/or deceptive practices related to

their security update programs. 46 The Commission’s complaint against ASUS alleged that the company

Public Comment on Mobile Security (Apr. 17, 2014), https://www.ftc.gov/news-events/press-releases/2014/04/ftc-invitesfurther-public-comment-mobile-security.

Consumer Privacy and Protection in the Mobile Marketplace: Hearing Before the S. Comm. on Commerce, Sci. & Transp.,

112th Cong. 10-19 (2011) (prepared statement of the FTC),

https://www.ftc.gov/sites/default/files/documents/public_statements/prepared-statement-federal-trade-commission-consumerprivacy-and-protection-mobile-marketplace/110519mobilemarketplace.pdf.

Protecting Mobile Privacy: Your Smartphones, Tablets & Your Privacy: Hearing Before the S. Comm. on the Judiciary,

Subcomm. for Privacy, Tech. & the Law, 112th Cong. 53-65 (2011) (prepared statement of the FTC),

https://www.ftc.gov/sites/default/files/documents/public_statements/prepared-statement-federal-trade-commissionprotecting-mobile-privacy-your-smartphones-tablets-cell/110510mobileprivacysenate.pdf.

FED. TRADE COMM’N, APP DEVELOPERS: START WITH SECURITY (May 2017), https://www.ftc.gov/tips-advice/businesscenter/guidance/app-developers-start-security; FED. TRADE COMM’N, MOBILE HEALTH APPS INTERACTIVE TOOL (Apr. 2016),

https://www.ftc.gov/tips-advice/business-center/guidance/mobile-health-apps-interactive-tool.

HTC America, Inc. (Decision and Order), supra note 37; Complaint at 2-8, HTC America, Inc., FTC File No. 1223049

(F.T.C. filed June 25, 2013), https://www.ftc.gov/sites/default/files/documents/cases/2013/07/130702htccmpt.pdf.

HTC America, Inc. (Decision and Order), supra note 37 at 3-5.

Press Release, Fed. Trade Comm’n, ASUS Settles FTC Charges That Insecure Home Routers and “Cloud” Services Put

Consumers’ Privacy At Risk (Feb. 23, 2016), https://www.ftc.gov/news-events/press-releases/2016/02/asus-settles-ftccharges-insecure-home-routers-cloud-services-put; Lesley Fair, ASUS Case Suggests 6 Things to Watch For in the Internet of

Things, FTC BUSINESS BLOG (Feb. 23, 2016, 12:15 PM), https://www.ftc.gov/news-events/blogs/businessblog/2016/02/asus-case-suggests-6-things-watch-internet-things; Press Release, Fed. Trade Comm’n, Oracle Agrees to Settle

FTC Charges It Deceived Consumers About Java Software Updates (Dec. 21, 2015), https://www.ftc.gov/news-events/pressreleases/2015/12/oracle-agrees-settle-ftc-charges-it-deceived-consumers-about-java; Lesley Fair, Oracle Java SE Case

Mobile Security Updates: Understanding the Issues

unfairly failed to give consumers adequate notice of security vulnerabilities and related updates, 47 and

the complaint against Oracle alleged that the company unfairly failed to disclose material information

about the effect of its security updates. 48 The Commission’s consent order with ASUS required the

company to notify consumers, clearly and conspicuously, when a software update is available and to

explain to them how to install the update and the risks associated with declining it. 49 The consent order

with Oracle similarly required the company to make clear and conspicuous disclosures of certain

security update-related information. 50

Emphasizing the importance of patching has also been central to the Commission’s recent policy

work on security. For example, in 2015, FTC staff issued a report on the Internet of Things (“IoT”) that,

among other things, detailed challenges to updating devices, such as hardware limitations, lack of

consumer awareness, and potential economic incentives to focus on manufacture rather than support. 51

In 2016, Commission staff filed a comment with the National Telecommunications and Information

Administration (“NTIA”) that recommended best practices for IoT manufacturers, such as informing

consumers, when feasible, of the security support period. 52 In 2017, the Commission submitted another

comment to NTIA that recommended, among other things, that IoT device manufacturers tell consumers

before purchase what security support they can expect. 53 Most recently, the Commission announced an

Serves Up a Cuppa Caution, FTC BUSINESS BLOG (Dec. 21, 2015, 11:37 AM), https://www.ftc.gov/newsevents/blogs/business-blog/2015/12/oracle-java-se-case-serves-cuppa-caution.

Complaint at 3-7, ASUSTeK Computer, Inc., F.T.C. File No. 1423156 (F.T.C. filed July 18, 2016),

https://www.ftc.gov/system/files/documents/cases/1607asustekcmpt.pdf.

Complaint at 2-4, Oracle Corp., F.T.C. File No. 1323115 (F.T.C. filed Mar. 28, 2016),

https://www.ftc.gov/system/files/documents/cases/160329oraclecmpt.pdf.

The order further provided that notice must be provided through at least several means, including by website posting and

user interface (if feasible); by direct notice to registered consumers by email, text message, push notification or similar

method; and by informing any consumer who contacted the company. ASUSTeK Computer, Inc., No. C-4587, 6-7 (F.T.C.

July 18, 2016), https://www.ftc.gov/system/files/documents/cases/1607asustekdo.pdf (Decision and Order).

Oracle Corp., No. C-4571 (F.T.C. Mar. 28, 2016), https://www.ftc.gov/system/files/documents/cases/160329oracledo.pdf

(Decision and Order).

See FTC STAFF REPORT, INTERNET OF THINGS: PRIVACY & SECURITY IN A CONNECTED WORLD, FED. TRADE COMM’N (Jan.

2015), https://www.ftc.gov/system/files/documents/reports/federal-trade-commission-staff-report-november-2013-workshopentitled-internet-things-privacy/150127iotrpt.pdf.

See Comments from the Staff of the Fed. Trade Comm’n to Dep’t of Commerce, Nat’l Telecomm. & Info. Admin. on The

Benefits, Challenges, and Potential Roles for the Government in Fostering the Advancement of the Internet of Things, No.

160331306-6306-01 (June 2, 2016), https://www.ftc.gov/system/files/documents/advocacy_documents/comment-staffbureau-consumer-protection-office-policy-planning-national-telecommunications/160603ntiacomment.pdf.

Comment from Fed. Trade Comm’n to Dep’t of Commerce, Nat’l Telecomm. & Info. Admin. on Communicating IoT

Device Security Update Capability to Improve Transparency for Consumers, No. P175410 (June 19, 2017),

Mobile Security Updates: Understanding the Issues

“IoT Home Inspector Challenge,” a public competition aimed at creating security update-related IoT

tools. 54 In July 2017, the Commission announced a winner of the competition, whose “IoT Watchdog”

app would flag devices with out-of-date software and provide update instructions. 55

Finally, the Commission’s education efforts have highlighted the role of security updates in a

reasonable security program. For example, the Commission’s business education guide, “Start with

Security,” advises companies to implement a process for regularly updating software. 56 Similarly, the

Commission’s “Careful Connections” guidance, geared towards IoT device manufacturers, advises

companies to consider in advance how they will update devices and notify customers of available

updates. 57

Mobile Security Study

In May 2016, the FTC and the FCC, which have related responsibilities in protecting the online

privacy of American consumers, 58 initiated separate studies of mobile security practices. 59 The FTC

issued identical Orders to eight mobile device manufacturers who use (or have used) four different

operating systems, requiring them to provide information related to their processes and practices for

https://www.ftc.gov/system/files/documents/advocacy_documents/ftc-comment-national-telecommunications-informationadministration-communicating-iot-device-security/170619ntiaiotcomment.pdf [NTIA Comment on IoT Device Security

Update Capability].

See FTC Notice of IoT Home Inspector Challenge, 82 Fed. Reg. 840-2, 840-41 (Jan. 4, 2017),

https://www.ftc.gov/system/files/documents/federal_register_notices/2017/01/iot_frn_pub_010417_-_2016-31731.pdf.

Press Release, Fed. Trade Comm’n, FTC Announces Winner of its Internet of Things Home Device Security Contest (July

26, 2017), https://www.ftc.gov/news-events/press-releases/2017/07/ftc-announces-winner-its-internet-things-home-devicesecurity.

See START WITH SECURITY, supra note 15 at 12 (“Outdated software undermines security. The solution is to update it

regularly . . . . [H]aving a reasonable process in place to update and patch third party software is an important step to reducing

the risk of a compromise.”); see also Thomas B. Pahl, Stick With Security, FTC BUSINESS BLOG (Sept. 22, 2017, 11:32 AM),

https://www.ftc.gov/news-events/blogs/business-blog/2017/09/stick-security-put-procedures-place-keep-your-security.

FED. TRADE COMM’N, CAREFUL CONNECTIONS: BUILDING SECURITY IN THE INTERNET OF THINGS, 6 (Jan. 2015),

https://www.ftc.gov/system/files/documents/plain-language/pdf0199-carefulconnections-buildingsecurityinternetofthings.pdf

(advising IoT manufacturers to consider the following questions: “How will you provide updates for products that are already

out there? Will you offer them for free? Will updates happen automatically?”).

Press Release, Fed. Trade Comm’n, Joint Statement of Acting FTC Chairman Maureen K. Ohlhausen and FCC Chairman

Ajit Pai on Protecting Americans’ Online Privacy (Mar. 1, 2017), https://www.ftc.gov/news-events/pressreleases/2017/03/joint-statement-acting-ftc-chairman-maureen-k-ohlhausen-fcc.

FTC Press Release, supra note 11; FCC Press Release, supra note 14.

Mobile Security Updates: Understanding the Issues

issuing security updates to address vulnerabilities in smartphones, tablets, and other mobile devices. 60

The FCC issued letters to mobile carriers asking questions about their processes for reviewing and

releasing security updates for mobile devices. 61 The FCC subsequently decided not to issue its own

report, instead deferring to the FTC’s expertise in protecting consumer privacy. The FCC shared with

the FTC all material obtained from the carriers in response to its inquiries. 62 Appendix A is a copy of the

text of the Orders that the Commission issued to the companies. Appendix B is a copy of the text of the

letters that the FCC issued to wireless carriers.

The eight companies to whom the FTC sent its Orders are as follows:

1. Apple, Inc.: Apple offers smartphones and tablets running its iOS operating system and provides

software updates directly to Apple devices, regardless of carrier. Although Apple is also an

operating system developer, the Order focused on Apple’s role as a device manufacturer.

2. Google, Inc.: Google offers “Nexus”- and “Pixel”-branded smartphones and tablets that use

Google’s Android operating system. Google collaborates with other manufacturers to produce

these devices, but it controls the software and updates for them. After discovery of the

Stagefright vulnerabilities in mid-2015, Google, as developer of the Android operating system,

announced that it would provide monthly Android security bulletins. Although several other

respondents use versions of Google’s Android operating system in their devices, the Order issued

to Google was identical to that issued to other respondents: It focused on Google as the

manufacturer for Nexus and Pixel devices rather than on Google as Android operating system

developer.

3. Motorola Mobility, LLC: Motorola offers smartphones and tablets running the Android

operating system. Motorola now offers many of its devices directly to consumers rather than

through carriers (i.e., the devices are “unlocked” from any specific carrier network so that

consumers can select any carrier’s service or use WiFi only).

In addition, the Orders requested that respondents identify the factors each company considers in deciding whether to patch

a vulnerability on a particular mobile device; provide detailed data on the specific mobile devices they have offered for sale

to consumers since August 2013; name the vulnerabilities that have affected those devices; and state whether and when the

company patched such vulnerabilities. See Appendix A, Model Order to File Special Report, FTC No. P165402, FED. TRADE

COMM’N (May 6, 2016), https://www.ftc.gov/system/files/attachments/press-releases/ftc-study-mobile-device-industryssecurity-update-practices/160509mobilesecuritymodelorder.pdf.

Appendix B, Model Letter to Common Carriers, FED. COMM. COMM’N (May 9, 2016),

https://apps.fcc.gov/edocs_public/attachmatch/DOC-339256A2.pdf.

See 47 CFR § 0.442. The carriers confirmed in their submissions to the FCC that they did not oppose such disclosures.

Mobile Security Updates: Understanding the Issues

4. Samsung Electronics America, Inc.: Samsung is the largest Android device manufacturer. 63

The company also offers devices running Microsoft’s Windows operating system. Samsung

devices are available through a number of carrier partnerships.

5. Microsoft Corporation: Microsoft offers smartphones and tablets running its Windows

operating system. Several Order respondents (Samsung, LG, HTC) use the Windows operating

system, but, as with Google, the Order issued to Microsoft focuses on its role as a device

manufacturer.

6. LG Electronics USA, Inc.: The second largest Android device manufacturer, LG offers

smartphones and tablets running the Android operating system and smartphones running

Microsoft’s Windows operating system.

7. HTC America, Inc.: HTC offers smartphones and tablets running the Android operating system

and smartphones running Microsoft’s Windows operating system.

8. Blackberry Corporation: Blackberry has offered smartphones and tablets running its

Blackberry 10 operating system. Currently, it offers smartphones using the Android operating

system. As with Apple, Google, and Microsoft, the Order focused on Blackberry’s role as device

manufacturer rather than as operating system developer.

The Commission selected these device manufacturers for several reasons. First, their offerings

represent a significant percentage of the devices in the U.S. market. Second, they use or have used the

most common operating systems: Google’s Android, Apple’s iOS, Microsoft’s Windows, and

Blackberry OS. 64 Third, these device manufacturers are known to have differing update practices;

deploying updates, for example, in different ways (e.g., directly versus through carriers) and at different

speeds.

Sections 6(f) and 21(d) of the FTC Act authorize the publication of reports derived from

information obtained pursuant to that authority in anonymized or aggregated form as long as no such

information discloses any trade secret or any commercial or financial information which is obtained

from any person and which is privileged or confidential. 65 Reports issued pursuant to Section 6(b) of the

Press Release, Gartner, Inc., Gartner Says Worldwide Sales of Smartphones Grew 9 Percent in First Quarter of 2017 (May

23, 2017), http://www.gartner.com/newsroom/id/3725117.

Press Release, IDC Research, Inc., Smartphone OS Market Share, 2017 Q1, http://www.idc.com/prodserv/smartphone-osmarket-share.jsp (last visited Feb. 22, 2018).

15 U.S.C. §§ 46(f), 57b-2.

Mobile Security Updates: Understanding the Issues

FTC Act are intended to describe general trends and issues affecting an industry. 66 This report does not

identify the practices of individual device manufacturers or carriers unless such information is publicly

available.

This report focuses on operating system vulnerability patching, because, as described above,

security researchers have raised concerns that mobile devices are not receiving operating system patches

needed to defend against attack. Despite this report’s singular focus, it is important to recognize that

operating system patching is only one element of reasonable device security. Other layers of the

smartphone stack (comprised of the device, the operating system, apps, and the network) are also

vulnerable to attack and require periodic security patches. 67 Similarly, patching is only one aspect of

security; as the FTC’s “Start with Security” guidance explains, secure product design is another

indispensable element of a reasonable security program. 68

Part II of this report explains what threatens the security of mobile devices, how security updates

mitigate those threats, and how the complexities of the mobile ecosystem impact that process. Part III

describes the often-complex process for patching vulnerabilities. Part IV addresses security update

practices, making observations about support length, update frequency, patch rate, and uptake based

primarily on the data provided by the device manufacturers. Part V describes the types of information

about security updates that are available to consumers. Finally, Part VI summarizes our findings and

makes recommendations for industry best practices and consumer education.

II. Securing Mobile Devices

This Part relies primarily on publicly available information to describe the threats to the security

of consumers’ mobile devices and the often-sensitive information they contain and transmit. It then

The FTC has issued Section 6(b) reports on a wide variety of other consumer protection topics, such as data brokers and

patent assertion entities. See, e.g., Press Release, Fed. Trade Comm’n, FTC Recommends Congress Require the Data Broker

Industry to be More Transparent and Give Consumers Greater Control Over Their Personal Information (May 27, 2014),

https://www.ftc.gov/news-events/press-releases/2014/05/ftc-recommends-congress-require-data-broker-industry-be-more;

Press Release, Fed. Trade Comm’n, FTC Report Sheds New Light on How Patent Assertion Entities Operate; Recommends

Patent Litigation Reforms (Oct. 6, 2016), https://www.ftc.gov/system/files/documents/reports/patent-assertion-entity-activityftc-study/p131203_patent_assertion_entity_activity_an_ftc_study_0.pdf.

For example, in January 2018, security researchers announced the discovery of two vulnerabilities, Spectre and Meltdown,

that affect the microprocessors of nearly all computers, including those in mobile devices. See Sam Schechner & Stu Woo,

Tech Giants Race to Address Chip Flaws With a Potentially Vast Impact, WALL ST. J., Jan. 4, 2018,

https://www.wsj.com/articles/tech-giants-race-to-address-widespread-chip-flaws-1515070427 (describing scope of the

problem and enormous challenges to remediation).

As the FTC advised in START WITH SECURITY, companies should “[a]pply sound security practices when developing new

products.” Supra note 15 at 9.

Mobile Security Updates: Understanding the Issues

describes how security updates mitigate these threats and how certain aspects of the mobile ecosystem

complicate the patching process.

Mobile Malware: Risk and Harm

Among internet-connected devices, mobile devices have unique security challenges because

consumers use them to access diverse content, services, and networks, and because mobile apps, in turn,

often access a broad range of device data and functionality. 69 Anyone can create a website for a

consumer to visit, and app stores exercise varying levels of control 70 over the millions of developers that

publish apps. 71 Moreover, websites and apps increasingly embed code from third-party providers to

provide services (like advertising) and those third parties may then connect to dozens of other

companies to solicit bids for an ad impression. 72 Each point of connection creates another opportunity

for a bad actor to exploit operating system vulnerabilities to execute malicious code, sometimes without

any user interaction at all. 73

As more consumers use mobile devices as their primary mode of computing, 74 bad actors are

increasingly targeting mobile devices. Specifically, although the likelihood of attack remains relatively

low (about 1.35% 75), the risk is increasing dramatically—rising 400%, for example, in 2016. 76 One

See, e.g., Paul Ruggiero & Jon Foote, CYBER THREATS TO MOBILE PHONES, US-CERT, 2011, https://www.uscert.gov/sites/default/files/publications/cyber_threats-to_mobile_phones.pdf (comparing risk profile of mobile devices to

PCs). Cf. Goldenshores Tech., No. C-4446 (F.T.C. Mar. 31, 2014),

https://www.ftc.gov/system/files/documents/cases/140409goldenshoresdo.pdf (Decision and Order) (settling allegations that

Android app developer deceived consumers about the extent to which its flashlight app accessed sensitive device data).

Compare Google Play Developer Distribution Agreement, GOOGLE (May 17, 2017),

https://play.google.com/about/developer-distribution-agreement.html with Apple App Store Guidelines, APPLE,

https://developer.apple.com/app-store/guidelines/ (last visited Feb. 12, 2018) and App Distribution Agreement, AMAZON

(Jan. 1, 2018), https://developer.amazon.com/public/support/legal/da.

Artyom Dogtiev, Mobile App Developer Statistics Roundup, BUSINESS OF APPS, Jan. 20, 2016,

http://www.businessofapps.com/mobile-app-developer-statistics-roundup/.

Everything You Need To Know About Real Time Bidding For Display Ads, MARKETING LAND, May 8, 2014,

http://marketingland.com/infographic-real-time-bidding-83186.

See generally Blue Coat Systems 2014 Mobile Malware Report: A New Look at Old Threats, BLUE COATS SYSTEMS, INC.

(2014), https://media.scmagazine.com/documents/64/report-mobilemalware-fn_15880.pdf (summarizing threats); see also

Chris Mills, How To Patch Your Devices Against the KRACK Wi-Fi Vulnerability Right Now, BGR, Oct. 16, 2017,

http://bgr.com/2017/10/16/krack-wi-fi-wpa2-patches-available-android-ios-windows/ (internal citation omitted) (noting that

“41% of Android devices are vulnerable to an ‘exceptionally devastating’ version of the attack, which allows [attackers] to

insert fake websites into a network and collect sensitive information”).

PEW MOBILE FACT SHEET, supra note 1.

Nokia Report Press Release, supra note 23 (reporting infection rate as of October 2016).

Mobile Security Updates: Understanding the Issues

security report notes that while mobile malware used to be an afterthought for cyber criminals,

researchers have seen a “dramatic” rise in both the number of mobile malware variants as well as the

sophistication of the attacks. 77 U.S. consumers are particularly attractive targets for mobile malware,

because of worldwide familiarity with the English language and Americans’ relatively high wealth

levels. 78

Importantly, malware is not just an irritant; it can harm consumers in significant ways. For

example, recent mobile ransomware attacks have extorted money—ranging from about $100-$300—

from victims by holding photos, music, and other files hostage or by preventing users from accessing

their devices or apps at all. 79 Spyware and phishing applications have harvested financial information

and passwords that enabled unauthorized access to consumers’ bank and credit card accounts, costing

consumers thousands of dollars. 80 Malware hidden in 200 recreational apps like style guides and

children’s books (each of which had been downloaded between 500,000 and 1 million times) turned

mobile devices into “backdoors” that allowed attackers to infiltrate any network connected to the

device. 81 Other malicious apps enrolled unwitting device owners in paid SMS subscription services that

surreptitiously stole consumers’ money. 82

Id.

See Bruce Snell, Mobile Threat Report: What’s on the Horizon for 2016, INTEL SECURITY, Mar. 1, 2016,

https://securingtomorrow.mcafee.com/consumer/mobile-security/mobile-threats-report-whats-on-the-horizon-for-2016/

(follow “click here” link to access full report); see also Nokia Report Press Release, supra note 23; Michael Kan, Mobile

Ransomware Use Jumps, Blocking Access to Phones, PC WORLD (June 30, 2016),

http://www.pcworld.com/article/3090049/security/mobile-ransomware-use-jumps-blocking-access-to-phones.html.

John Snow, Ransomware on Mobile Devices: Knock-Knock-Block, KASPERSKY LAB DAILY BLOG (June 29, 2016),

https://blog.kaspersky.com/mobile-ransomware-2016/12491/.

St. John, supra note 21 (reporting that ransomware transmitted through an app in the Google Play Store demanded the

Bitcoin equivalent of about $180 in ransom); Doug Olenick, New Ransomware Demands Payments in iTunes, Targets Older

Android Software, SC MAGAZINE, Apr. 26, 2016, https://www.scmagazine.com/new-ransomware-demands-payment-initunes-targets-older-android-software/article/528546/ (describing ransomware that demands $200 in iTunes gift cards).

Beware Downloading Some Apps or Risk ‘Being Spied On,’ CBS NEWS, Feb. 24, 2016,

http://www.cbsnews.com/news/mobile-phone-apps-malware-risks-how-to-prevent-hacking-breach/ (reporting that hackers

used malware in a slot machine game app to spend $5000 of victim’s money); Sidel, supra note 20 (describing malware used

to steal banking credentials); Carlos Castillo, Android Banking Trojan Asks for Selfie With Your ID, MCAFEE, Oct. 13, 2016,

https://securingtomorrow.mcafee.com/mcafee-labs/android-banking-trojan-asks-for-selfie-with-your-id/ (describing Android

banking Trojan malware).

Bradley Barth, Got MilkyDoor? Android Malware Lets Attackers Infiltrate Your Phone's Connected Network, SC MEDIA,

Apr. 21, 2017, https://www.scmagazine.com/got-milkydoor-android-malware-lets-attackers-infiltrate-your-phonesconnected-network/article/652045/.

Swati Khandelwal, 300,000 Android Devices Infected by Premium SMS-Sending Malware, HACKER NEWS, Feb. 15, 2014,

http://thehackernews.com/2014/02/android-Malware-subscription-premium-SMS-Services.html.

Mobile Security Updates: Understanding the Issues

Malware not only victimizes smartphone owners; it also turns mobile devices into weapons that

target third parties, causing serious economic—and sometimes physical—harm. For example, a botnet

of infected smartphones attacked 13 internet root name servers (servers that perform an authentication

function necessary for websites to function), threatening the millions of businesses and critical

infrastructure that rely on a stable internet. 83 Another mobile botnet took down a website by issuing 4.5

billion page requests—showcasing the vulnerability of all websites to such attacks. 84 In a different kind

of attack, a flood of calls from compromised smartphones incapacitated 911 emergency call centers in

twelve states, which may have prevented injured or endangered individuals from timely reaching

emergency responder services. 85

Mitigating the Threat: Patching in a Complex Ecosystem

When designing mobile operating systems, developers attempt to anticipate vulnerabilities that

attackers could exploit, but, in many cases, vulnerabilities are only discovered after the device’s public

release. 86 Developers mitigate discovered vulnerabilities by creating patches, software that overwrites

the vulnerable code. 87 Once the patch is incorporated into a software update, the new version of the

device’s operating system includes the patched code.

Patching is essential to maintaining the security of software-based products, 88 and security

support can be a salient product attribute for security-conscious consumers. Successful and timely

patching can also confer reputational benefits by providing evidence to consumers of a manufacturer’s

Anthony Cuthbertson, Massive DDoS Attack on Core Internet Servers Was ‘Zombie Army’ Botnet from Popular

Smartphone App, INT’L BUSINESS TIMES, Dec. 11, 2015, http://www.ibtimes.co.uk/john-mcafee-massive-ddos-attackinternet-was-smartphone-botnet-popular-app-1532993.

Robert Abel, DDoS Attack Sent 4.5 Billion Requests Using Mobile Browsers, SC MEDIA, Sept. 29, 2015,

https://www.scmagazine.com/ddos-attack-used-mobile-devices-to-deliver-45-billion-requests/article/533674/.

Knutson, supra note 22.

Developers and security researchers constantly search for vulnerabilities, and identify dozens of new vulnerabilities on a

monthly, if not weekly, basis. For example, Google reported that the company addressed 655 vulnerabilities in 2016, of

which 133 were rated critical and 365 were rated high. See 2016 ANDROID SECURITY REPORT, supra note 29 at 31.

Software patching is a long-standing practice in computing: in its original form, the term “patching” was quite literal, as

software patches for systems processing punch cards consisted of replacement paper segments to be taped into an older deck.

See, e.g., Kami Vaniea & Yasmeen Rashidi, Tales of Software Updates: The Process of Updating Software, 2016 PROCS.

OF THE 34TH ANN. ACM CONFERENCE ON HUMAN FACTORS IN COMPUTING SYSTEMS, 1 (May 2016),

https://vaniea.com/papers/chi2016.pdf (“As soon as a vulnerability becomes public knowledge, exploit rates jump by as

much as 5 orders of magnitude . . . . Systems that are regularly updated have both smaller attack surfaces and less

compromise attempts.”).

Mobile Security Updates: Understanding the Issues

ongoing investment in its product. 89 But support comes with costs that will be passed onto the consumer,

perhaps through higher device prices. 90 Patching can also impose direct time and inconvenience costs on

consumers, and some patches may change device functionality. Moreover, maintaining existing software

may divert resources from development of valuable new products and may prolong consumer reliance

on outmoded software. 91 When considering a purchase, security-conscious consumers may compare the

level of support for their current devices with the likelihood of better security for new devices. Device

manufacturers are, therefore, constantly balancing the need to meet consumers’ expectations that

existing products will remain useful and reasonably secure with the desire to devote resources to new

product innovation and sales.

There are unique challenges to issuing timely operating system patches for mobile devices. First,

whereas operating system developers usually have a direct line to consumers in the PC market, updating

a mobile device may involve cooperation among a diverse set of participants, including the operating

system developer, the system-on-a-chip manufacturer, the device manufacturer, the carrier, carrier

partners, and third-party testing labs.

Second, one of the greatest strengths of the mobile ecosystem—the ability to customize the

operating system for each device—further complicates the patching process, because each device-level

customization requires a somewhat different patch. A manufacturer that licenses the customizable

Android operating system may sell dozens of models running dozens of slightly different customizations

of the operating system—all of which require slightly different applications of a single security patch. 92

Third, the involvement of wireless carriers can contribute to the complexity of the patching

process. Carriers often impose software update testing requirements and may ask manufacturers to

modify the devices’ operating systems further to differentiate that model from other carriers’ versions.

While carrier testing and carrier-specific devices can benefit consumers, they have the ancillary effect of

further complicating the patching process.

Cf. Nick Wingfield, In Ransomware Attack, Where Does Microsoft’s Responsibility Lie?, N.Y. TIMES, May 15, 2017,

https://www.nytimes.com/2017/05/15/technology/cyberattack-microsoft-software-responsibility.html (describing reputational

incentives for software vendors like Microsoft to patch their operating systems).

Cf. Robert L. Scheier, Foiled! How to Beat Software Vendors’ Sneaky Price Increases, INFOWORLD, Jan. 13, 2014,

http://www.infoworld.com/article/2609217/software-licensing/software-licensing-foiled-how-to-beat-software-vendorssneaky-price-increases.html (describing how software support costs are passed onto businesses through licensing models).

Cf. Wingfield, note 89 (“Providing updates to older systems could make computers more insecure by removing an

incentive for users to modernize . . . .”).

For example, LG’s website offers 136 smartphones. Smartphones, LG, http://www.lg.com/us/smartphones (last visited

Feb. 12, 2018). Samsung offers 265 devices. All Phones, SAMSUNG, http://www.samsung.com/us/mobile/phones/allphones/s/all_other_phones-galaxy_note-galaxy_s/_/n-10+11+hv1rp+zq1xc+zq1xb+zq1xa/ (last visited Feb. 12, 2018).

Mobile Security Updates: Understanding the Issues

All of this variation means that consumers can choose from a wide array of products, with more

variation in price and features than non-customizable operating systems permit. This diversity, however,

imposes certain support costs: Because the operating systems may vary at the device and carrier level,

security updates too must be customized on a model-by-model and carrier-by-carrier basis. Indeed, at

any given time, a manufacturer may be supporting dozens, or even hundreds, of models with slightly

different operating systems and testing regimes. While some consumers may understand and value the

tradeoffs between variety and support, others may not perceive the cost to security that this variety may

impose. In addition, reduced security from delayed patching for devices in a network can expose other

users of the network to an increased risk of harm. 93

See, e.g., Robert W. Hahn & Anne Layne-Farrar, The Law and Economics of Software Security, 30 Harv. J.L. & Pub. Pol’y

283, 317 (2006) (explaining that “by securing net-works himself, a user closes off one entry route for would-be hackers,

benefiting himself and others on the larger, interconnected network.”). See also Ginger Zhe Jin & Andrew Stivers, Protecting

Consumers in Privacy and Data Security: A Perspective of Information Economics (May 22, 2017),

https://ssrn.com/abstract=3006172 (describing potential market failures, including externalities).

Mobile Security Updates: Understanding the Issues

III. The Security Update Process

This Part of the Report explains the patching process, which can involve several—or many—

steps. For example, for an unlocked device (i.e., a device not linked to a particular carrier) with a noncustomized operating system, the device manufacturer/operating system developer will identify the

vulnerability, develop and test the patch, and deploy an update to consumers. By contrast, for a

customized operating system using a carrier’s service, the process often involves several extra steps:

The relative simplicity of this depiction belies the complexity and variability that often

characterizes the process. In discussing each step of the security update process, this section explores the

factors that can contribute to that complexity and variability.

Identifying Vulnerabilities and Affected Devices

When a code owner (e.g., system-on-a-chip manufacturer, operating system developer, other

software vendor) discovers a vulnerability, 94 it identifies the severity of the vulnerability, 95 develops a

A number of operating system developers and system-on-a-chip manufacturers incentivize vulnerability reporting with

“bug bounty” programs. See, e.g., Google Vulnerability Reward Program (VRP) Rules, GOOGLE,

https://www.google.com/about/appsecurity/reward-program/index.html (last visited Feb. 12, 2018); Nicole Perlroth, Apple

Will Pay a ‘Bug Bounty’ to Hackers Who Report Flaws, N.Y. TIMES, Aug. 4, 2016,

http://www.nytimes.com/2016/08/05/technology/apple-will-pay-a-bug-bounty-to-hackers-who-report-flaws.html?_r=0; Press

Release, Qualcomm, Inc., Qualcomm Announces Launch of Bounty Program, Offering up to $15,000 USD for the Discovery

of Vulnerabilities (Nov. 17, 2016), https://www.qualcomm.com/news/releases/2016/11/17/qualcomm-announces-launchbounty-program-offering-15000-usd-discovery.

Vulnerabilities are frequently assigned a Common Vulnerabilities and Exposures (CVE) list identifier, which is a common

reference for members of the security community. See CVE: The Standard for Information Security Vulnerability Names,

MITRE, http://cve.mitre.org/ (last visited Feb. 12, 2018).

Mobile Security Updates: Understanding the Issues

patch for the primary source code, 96 and conveys the vulnerability and patching information to its

downstream partners, usually via regular security bulletins. 97

Device manufacturers must then determine whether the vulnerability affects any of their devices.

Because of device- and carrier-specific customizations, a vulnerability affecting one device may not

affect a similar device using the same type of operating system, made by the same manufacturer, and

serviced by the same carrier. And a vulnerability that affects one device may not affect exactly the same

device (same operating system, manufacturer, and model) if it is serviced by a different carrier. For

manufacturers with large device portfolios and numerous carrier relationships, this step may involve

examining dozens or even hundreds of instances of code.

Deciding Whether to Update Specific Devices

Device manufacturers then decide whether to issue security updates for affected devices.

Respondents reported that they typically decide to stop issuing regular security updates to a device based

on the characteristics of that device, rather than making support decisions for each device on a

vulnerability-by-vulnerability basis. 98 Only one respondent had a written patch policy that expressly

identifies the device characteristics that inform support decisions. However, in practice, the rest weigh

similar factors:

Device Age: It is not feasible from either a technical or business perspective to support any

device indefinitely. Hardware becomes outdated and consumers upgrade to new phones, so every

manufacturer reported allocating support resources either towards newer devices or devices with newer

operating systems.

Device Popularity: Popular devices are more likely to be updated, because a patch to a popular

phone will benefit more consumers than a patch for a little-used phone and maintaining flagship devices

(i.e., usually the most popular) benefits the brand. Although flagships tend to be more expensive than

Fixing the primary source code may itself be a complex process, because code owners often support multiple versions of

their code. See, e.g., Android – Story, GOOGLE, https://www.android.com/history/ (last visited Feb. 12, 2018) (describing

support for last three versions of the Android operating system).

For example, since Stagefright, Google has issued monthly security bulletins. ANDROID SECURITY 2015 YEAR IN REVIEW,

GOOGLE (Apr. 2016), https://source.android.com/security/reports/Google_Android_Security_2015_Report_Final.pdf

(describing transition from quarterly to monthly security bulletins). Other code owners, like Qualcomm and Microsoft,

similarly issue regular security bulletins. Security Bulletins, QUALCOMM, https://www.qualcomm.com/company/productsecurity/bulletins (last visited Feb. 12, 2018); Security Update Guide, Security TechCenter, MICROSOFT,

https://portal.msrc.microsoft.com/en-us/ (last visited Feb. 12, 2018).

Notwithstanding this preference for global assessment, device manufacturers will occasionally “backport” a patch, i.e.,

develop a patch for particular critical vulnerabilities, like Stagefright, even for devices that do not receive regularly scheduled

support.

Mobile Security Updates: Understanding the Issues

other devices, no company described retail cost of the device (e.g., premium or budget) as relevant to its

update decisions, nor did any manufacturer describe security support as a feature exclusively for highend models.

Cost of Support: Because patching requires development and testing resources, manufacturers

are cognizant of how many devices in their portfolio are receiving support and how much it will cost to

continue supporting a particular device.

Carrier Input: Carrier contracts may require a minimum support period (e.g., 18 or 36 months),

although, based on the contract provisions we received, such requirements are fairly rare. Where the

contract is silent, carriers may function as conduits for any updates device manufacturers independently

choose to provide, or they may be active partners in support decisions. Manufacturer-carrier

communications reveal that, at times, carriers urge manufacturers to support popular devices, patch

critical vulnerabilities, and use a routine update schedule. Other communications, however, show that

carriers sometimes resist updates that require immediate action or consume limited testing resources.

Vulnerability Severity: Even if a device manufacturer is no longer supporting a device

regularly, it may decide to “backport” patches for certain high-risk vulnerabilities to all devices.

Deciding When to Update Specific Devices

Next, the patching manufacturer must decide when to issue the update: in an emergency release

(usually reserved for the most severe vulnerabilities), as part of a regularly-scheduled security-only

update, or with a regularly scheduled general software update that bundles security fixes with

functionality upgrades. Since Stagefright, several Android manufacturers have attempted to develop

formal policies or, at least, relatively consistent practices for security-only updates, especially for

flagship devices. For example, Google, LG, and Samsung have committed to monthly security updates

for certain devices. 99 Respondents reported, however, that many timing decisions remain case by case,

with the manufacturer considering the severity of the vulnerability, the date of the next regular update,

and any carrier input. The latter two factors are described further below.

Next Regular Update: If an update for a particular device is already scheduled within the next

few months, the manufacturer will often slot a security patch for delivery with that update. A number of

respondents reported that they prefer to deliver security patches in updates that bundle functionality

upgrades with security fixes, for several reasons: Bundling reduces the overall number of updates that

require testing and deployment, may reduce disruption to consumer experience (i.e., because there are

fewer updates overall), may speed up functionality upgrades, and may provide an incentive for

consumers interested in new functionality to install the update. Some respondents, however,

See infra Part IV.B.1 (chart summarizing device manufacturers’ public statements about update frequency).

Mobile Security Updates: Understanding the Issues

acknowledged that bundling can significantly delay security fixes. And some commentators have argued

that for consumers who avoid functionality changes, bundling creates an incentive to avoid security

patches. 100

Partner Input: Partners may persuade manufacturers to patch at a certain time or on a certain

schedule. For example, Google has received media attention for pressing manufacturers to issue monthly

security-only updates. 101 Manufacturer-carrier communications reveal a complex interplay: At times,

some carrier personnel have viewed security-only updates as needlessly clogging testing labs, while, at

other times, they have requested security-only releases. Carriers may provide their input by persuasion,

by contract, or with testing fees (or waiver of such fees) pegged to the size of the update, the amount of

advance notice about the update, or the number of updates per device per year. 102

Security Update Testing

The next step is testing. First, for device manufacturers that license the Android operating

system, Google mandates compatibility testing to verify that an update does not compromise the

functionality of Android or Google applications. 103 Second, for devices with carrier service, carriers

conduct network compatibility and device functionality testing. 104

100

See, e.g., Zeynep Tufekci, The World Is Getting Hacked. Why Don’t We Do More to Stop It?, N.Y. TIMES, May 13, 2017,

https://www.nytimes.com/2017/05/13/opinion/the-world-is-getting-hacked-why-dont-we-do-more-to-stop-it.html?_r=0

(“[U]pgrades almost always bring unwanted features . . . . Users hate this, and often are rightfully reluctant to upgrade. ”).

101

See, e.g., Ewan Spence, Google Embraces Security Shaming To Answer Android’s Security Problems, FORBES, Oct. 1,

2015, https://www.forbes.com/sites/ewanspence/2015/10/01/google-android-security-fix-visible-solution/#19a7740946c7;

Catalin Cimpanu, Google Publishes List of 42 Phones Running Latest Android Security Updates, BLEEPING COMPUTER, June

2, 2017, https://www.bleepingcomputer.com/news/security/google-publishes-list-of-42-phones-running-latest-androidsecurity-updates/.

102

How much weight manufacturers give to partner input appears to depend on the bargaining power between the parties.

Based on our review of their communications, it appears that companies that make popular, high-end devices and deploy

their own updates are more likely to make unilateral timing decisions. By contrast, manufacturers competing to make their

less expensive products available in limited carrier storefronts are more likely to acquiesce to carrier requests.

103

2016 ANDROID SECURITY REPORT, supra note 29 at 5. Respondents reported that because this compatibility testing must

be performed for each device-carrier combination, it can consume considerable resources.

104

For example, carrier testing may explore whether a fix inadvertently affects basic device functions (e.g., phone call

connection), core network functions (e.g., voicemail or roaming capabilities), safety features (e.g., 911 calls), data usage, or

memory. If a regional carrier or a mobile virtual network operator (“MVNO,” i.e., a wholesale purchaser and reseller of

wireless services such as TracFone) services the device, then both the regional carrier or MVNO and its carrier partner are

likely to test the update. They often attempt to test simultaneously, but may complete testing at different times. Testing may

be required by contract, or, if not, manufacturers may give the carrier time for a courtesy review.

Mobile Security Updates: Understanding the Issues

Carrier testing can vary significantly in length and substance. Some manufacturers described a

lengthy, complex process. First, account managers for manufacturers and carriers develop test plans and

negotiate a testing timeline (and, sometimes, associated fees). Second, the carrier will review alreadycompleted testing and documentation, such as release notes, certifications, and test reports. Third, the

carrier team will conduct its own testing. At the same time, the carrier may require information for

consumer messaging, such as the proposed text of any device update notification and/or presentations to

aid the carrier’s marketing team in describing functionality updates. Finally, when the carrier deems the

documentation and testing sufficient, the carrier sends the device manufacturer a formal approval letter.

Potential Requirements for Carrier Testing

•

Create formal test plans

•

Negotiate an “entry date” in the carrier’s testing lab

•

Send a letter of intent for carrier approval

•

Obtain and submit additional third party testing

•

Submit required documentation (e.g., proof of

compatibility testing, technical and/or release notes, pretest report)

•

For new devices, ship test versions to carrier

•

Conduct the testing

•

If the device fails any aspect of testing, contact the code

owner (e.g., system-on-a-chip manufacturer, operating

system developer, other software vendor) and discuss a

fix

•

Draft a test report

•

After any failure, repeat each step in the process

•

If the device will be operated by a carrier partner, satisfy

its parallel testing requirements

Since Stagefright, a number of OS developers, manufacturers, and carriers have adopted (or put

renewed emphasis on) three related procedures for expedited security testing: security-only releases,

self-certification, and regular security updates. Respondents reported that these techniques are

Mobile Security Updates: Understanding the Issues

improving responsiveness; testing times for security-only releases are usually less than a week,

compared with six weeks or more for functionality updates.

Security-Only Releases: Security-only releases fast-track security updates by disentangling them

from larger functionality upgrades. The carrier can leverage prior testing to focus exclusively on the

impact of a few security fixes, with the goal of providing approval in one or two days. In some

instances, the procedures for security-only releases are defined by contract or another formal document.

In other instances, the parties simply agree on a security-only testing model or adopt one by practice. 105

Self-Certification: Security-only releases are made possible, in part, by device manufacturer

self-certification. A self-certifier submits documentation to the carrier showing that it has conducted its

own testing (or obtained third party testing) and determined that the update differs from previouslytested code only to the extent necessary to address specified issues. If the carrier determines that the

manufacturer has satisfied its documentation requirements, the carrier will test the few specified

changes. 106

Update Regularity: The third mechanism streamlines the testing process by setting expectations.

Routine vulnerability reporting and patch cadences (e.g., on the same day every month) and set testing

schedules (e.g., monthly security updates for flagships) enable downstream players to anticipate testing

and deployment resources. Of course, there are limits to how much regularity is feasible: Even with

routine patch cadences, manufacturers with large portfolios of customized devices cannot readily

forecast how many update iterations must be tested each month.

105

Communications reveal instances in which manufacturers have pressed carriers to adopt these procedures—and,

conversely, instances in which carriers have driven the process.

106

Manufacturer-carrier communications make clear that, at least in some relationships, self-certification is not a rubber

stamp; carriers press manufacturers for meaningful documentation.

Mobile Security Updates: Understanding the Issues

Different Views of Carrier Testing

Device manufacturers expressed different views about costs and

benefits of carrier testing. One view is that carrier testing imposes greater

costs (i.e., delay) than benefits. Proponents of this view argue that the

mobile ecosystem is at its most efficient when manufacturers focus on

security and functionality and carriers focus on wireless service. 107 Several

manufacturers stated that their carrier partners had found few, if any, errors

during their testing processes over the last several years, and the parties

had developed a high level of trust that the manufacturer would provide

high-quality updates. And some communications revealed instances in

which carrier personnel acknowledged that the carrier’s processes were

unwieldy. If patches were consistently error-free, the level of the parties’

trust consistently high, and the carriers’ processes cumbersome, then the

costs of carrier testing would likely outweigh the benefits.

But there is evidence to support a contrary view: that carrier testing

actively contributes to device security, in several ways. First, carriers

function as a backstop. As one manufacturer described it, there is a

“productive tension” between some partners, with carriers’ focus on quality

and operability acting as a “healthy” check on device manufacturers’ focus

on update speed. Second, carriers can create accountability:

Communications showed numerous instances of carriers’ actively tracking

vulnerability reports and verifying that manufacturers focused on

functionality changes were addressing the vulnerabilities in the next

scheduled update. Third, carriers provide additional expertise and

resources: Communications reveal that, especially for certain

manufacturers with large device portfolios, carriers do identify errors that

might otherwise be passed onto consumers. 108 Finally, carriers who test

devices from numerous manufacturers provide a certain degree of panindustry insight. 109 Because of their global view of manufacturer practices,

they are uniquely positioned to notify a manufacturer when a particular

practice introduces easily avoidable inefficiencies.

107

Participants in the FTC’s Mobile Security Forum discussed this view. See Forum Press Release, supra note 40.

108

For example, several manufacturer-carrier communications showed carriers identifying functionality problems with device

manufacturers’ proposed updates. Another showed the carrier objecting to an update that would have required the consumer

to delete device content to free up storage space, which likely would have depressed uptake.

109

For example, in one manufacturer-carrier communication, a carrier informed a device manufacturer that its updates were

larger than other device manufacturers’, leading to lower-than-average uptake.

Mobile Security Updates: Understanding the Issues

Installing the Security Update

After testing, the security update is ready for consumer installation. There are two aspects to

installation: deployment and device uptake.

Deployment: There is no single deploying party or deployment method in the mobile

ecosystem. Sometimes carriers deploy updates over-the-air (“OTA”) using their wireless network;

sometimes operating system developers or device manufacturers deploy the updates themselves

over a WiFi connection. Some operating system developers and device manufacturers reported that

they prefer to deploy their own updates to maximize control over the testing and deployment

schedule. Other manufacturers and carriers reported that consumers can benefit from carriers’

deployment expertise (developed from long experience with updates) and the opportunity to

contact a carrier directly with any concerns about the update.

Deploying parties may use one or more of three methods: pushing, polling, and pulling.

First, the deploying party may push the update to devices for automatic download, with installation

complete upon consumer confirmation. Second, the deploying party may set devices to poll, or

periodically check with the deploying party’s server for updates. Third, the deploying party may

require consumers to affirmatively pull the update from their server by checking their website. No

matter the deployment method(s), deploying parties often prefer a gradual schedule so that any

problems with the update can be identified early before the update is deployed to all devices.

Uptake: Deployment does not guarantee an update; the device must “take” or install the

update. The uptake rate depends on several factors. First, installing an update requires sufficient

Internet access, either by WiFi or carrier service. There are advantages and disadvantages to each

method. WiFi offers greater bandwidth (i.e., faster download times), which is particularly

important for larger updates. It also offers all-inclusive pricing (i.e., “free” downloads unlike

cellular plans with monthly data caps). However, consumers who do not have immediate or

frequent access to WiFi—many of whom may be among the 10% of American consumers who do

not have any home WiFi access110—may not be able to install the update. Installation over carrier

network similarly has benefits and potential drawbacks. Carriers may charge for bandwidth usage

or they may decide not to include update data (especially the minimal data usually required for a

security-only update) against a user’s monthly cap. Network deployments can be slower than WiFi

deployments, because carriers often deploy in waves to avoid network congestion. That gradual

approach, however, can enable carriers to spot update issues and address them before these issues

affect many consumer devices.

110

PEW SMARTPHONE USE, supra note 17; 2016 Broadband Progress Report, FED. COMM. COMM’N, 33-34 (Jan. 28, 2016),

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

Mobile Security Updates: Understanding the Issues

Second, updating requires sufficient device power. Consumers without enough battery or power

outlet access must defer, and may ultimately ignore, an update. Third, updating requires sufficient

device storage. A security-only update is less likely to require significant storage, but a maintenance

release that bundles functionality and security upgrades may require the user to make space available on

the device. Fourth, uptake can depend on user notifications; if a consumer must take affirmative action

to install the update (either pulling the update or accepting installation), prominent notification increases

uptake. Fifth, some devices have configurable update settings and can be set by default to autodownload updates, which increases uptake. 111 Sixth, uptake depends on consumer deferrals and

rejections. Forcing the device to update immediately, or after a certain number of deferrals, improves the

uptake rate but may bother users, 112 particularly those who are actively attempting to avoid functionality

changes. 113

Finally, not every device is able to accept updates: Non-standard devices—e.g., iOS devices that

have been “jailbroken” or Android devices that have been “rooted” to bypass manufacturers’ default

restrictions and expand the phones’ capabilities—may not be compatible with updates. 114 In addition,

some mobile device management software installed by enterprise customers to enhance enterprise

control and security may interfere with a device’s ability to receive over-the-air updates.

111

According to a recent survey, only about 32% of American smartphone owners set their devices to update automatically.

AMERICANS & CYBERSECURITY, supra note 6 at 20.

112

Recent survey research sheds light on the reasons for consumer deferrals and rejections. Specifically, users may reject

updates because they do not want familiar functionality to change, do not think the upgrade sufficiently important to justify

its inconvenience, or do not understand the update notice. See, e.g., Arunesh Mathur & Marshini Chetty, Impact of User

Characteristics on Attitudes Towards Automatic Mobile Application Updates, 13TH SYMPOSIUM ON USABLE PRIVACY AND

SECURITY, 175 (July 12-14, 2017), https://www.usenix.org/conference/soups2017/technical-sessions/presentation/mathur

(describing reasons that user avoid mobile app updates); Vaniea & Rashidi, supra note 88 at 2 (summarizing survey research

on consumers’ confusion about security updates); M. Fagan, et al., A Study of Users’ Experiences and Beliefs About Software

Update Messges, 51 J. OF COMPUTERS IN HUMAN BEHAVIOR 504 (2015) (describing survey research reporting consumers’

annoyance with and confusion about security updates messaging).

A recent Pew Research survey reports that 42% of Americans only update their phones when it is convenient, and 14% say

they never update their phones. AMERICANS & CYBERSECURITY, supra note 6 at 20. Consumers ages 65 and older are

especially likely to ignore an update; nearly a quarter of these consumers report that they never update their phone’s

operating system. Id.

113

Tripp Mickle, Apple Limits Performance in Old iPhones to Prevent Shutdowns, WALL ST. J., Dec. 21, 2017,

https://www.wsj.com/articles/apple-limits-performance-in-old-iphones-to-prevent-shutdowns-1513812316 (describing an

Apple operating system software update that throttled device performance to preserve battery health).

114

By jailbreaking or rooting a device, the owner configures it to run a customized operating system not certified by a carrier,

which may violate some party’s terms of service (i.e., the operating system, manufacturer, and/or carrier), potentially

jeopardizing support, updates, or even connectivity. See Marshall Honorof, Jailbreak, Root or Unlock: What’s the

Difference?, MSN, Mar. 6, 2013, http://www.nbcnews.com/id/51071301/ns/technology_and_sciencetech_and_gadgets/t/jailbreak-root-or-unlock-whats-difference/.

Mobile Security Updates: Understanding the Issues

IV. Security Support Practices

The previous Part provided an overview of the mobile security update process. This Part

provides some insight into device manufacturer’s security support practices: the duration of their

security support, the frequency of their updates, the amount of time it takes to develop and test patches,

and their uptake rates.

No recipient of the Order maintained comprehensive or readily-accessible records of these

practices, and each reported that it would be burdensome to fully reconstruct them. And perhaps because

device manufacturers do not keep such records, they appear to have somewhat limited insight into their

own practices. This section draws on available data to highlight some commonalities and trends in their

practices.

Duration of Security Update Support

The Commission’s Order asked respondents to identify the period of time that individual device

models were supported for security updates. In response, manufacturers generally described

approximate time periods (e.g., “1-2 years,” “about 2 years,” “1-3 years,” etc.). They explained that they

could not provide more definitive responses because support periods vary based on factors (such as

device popularity, support costs, and carrier input) that cannot be easily predicted at the time the device

is released.

We also researched whether any manufacturers made public statements about minimum support

periods or security support periods for their devices. We then compared these public statements to

update support data the manufacturers provided. This section first describes manufacturers’ public

statements on update support and then reports on our data analysis.

1. Public Statements about Update Support

The table below summarizes device manufacturers’ public statements on the length of update

support periods. 115

115

This table (and the companion table, infra Part IV.B.1) does not necessarily identify every statement these device

manufacturers have made; we used Internet search methods that attempt to simulate the types of searches consumers would

conduct when researching smartphone and tablet purchases.

Mobile Security Updates: Understanding the Issues

Manufacturer

Google

116

Operating System Update Period

Pixel and Nexus: at least 2 years from

launch

Pixel 2 (2017): at least 3 years from

launch

Android One: “All [device manufacturers]

have committed to giving software

updates for at least 18 months after the

phone’s launch . . . [with] at least one

major software update.”

Security Update Period

Pixel and Nexus phones: “security

patches for at least 3 years from when

the device first became available, or at

least 18 months from when the Google

Store last sold the device, whichever is

longer.”

Android One phones: for at least 18

months from launch.

Google Play edition devices: no

statement

Google Play edition devices: “usually

around 18 months after a device has been

released.”

Microsoft

Windows 10 Mobile: minimum of 24

117

months from launch.

Same as regular support

Windows 8.1: minimum of 36 months from

118

launch.

Motorola

No statement

116

Nexus Help: Check & Update Your Android Version, GOOGLE, https://support.google.com/nexus/answer/4457705 (last

visited Feb. 12, 2018) [hereinafter Nexus Help].

117

Lifecycle FAQ—Device Operating System Policy, MICROSOFT, https://support.microsoft.com/en-us/help/18403 (last

update Feb. 1, 2018) [hereinafter Microsoft Lifecycle FAQ].

118

Search Product Lifecycle, Windows Phone 8.1, MICROSOFT, https://support.microsoft.com/enus/lifecycle/search?sort=PN&alpha=windows%20phone%208.1&Filter=FilterNO (last visited Feb. 12, 2018).

Mobile Security Updates: Understanding the Issues

Blackberry

No statement

Samsung

No statement

HTC

Previous statements that “most devices

119

have a 2 year update lifecycle,” “all new

North America flagship devices going

forward [will receive] . . . all major Android

updates for 2 years after their release

120

121

date,” or “up to 2 years” for flagships.

No statement

Apple

No minimum period of support but states:

“years of use . . . are conservatively

modeled to be . . . three years for iOS . .

.devices. Most Apple products last

significantly longer [and] are kept current

122

through regular software updates . . .”

Same as regular support

As the table shows, not all manufacturers publicize minimum support periods, and only Google

distinguishes security support from regular operating system updates. Only Google and Microsoft

provide an updated schedule on their websites about when support will end for each device or operating

system. 123

As the table shows, manufacturers that develop their own operating system (i.e., Apple,

Microsoft, Google for Pixel and Nexus phones) tend to state more explicitly the support periods for

119

@HTCUSA, TWITTER, Feb. 11, 2016,

https://twitter.com/search?l=&q=%22%22most%20devices%20have%20a%202%20year%20update%20lifecycle%22%22&s

rc=typd&lang=en.

120

HTC USA Product Team, REDDIT, Feb. 14, 2014,

https://www.reddit.com/r/Android/comments/1xxjfx/hi_were_the_htc_usa_product_team_amaa/.

121

HTC Advantage, HTC, previously available at https://www.htc.com/ca/advantage/ (last visited Mar. 29, 2017).

122

FAQ, More Answers To Your Questions About Apple & the Environment., APPLE,

http://www.apple.com/environment/answers/ (last visited Feb. 12, 2018).

123

Nexus Help, supra note 116; Microsoft Lifecycle FAQ, supra note 117.

Mobile Security Updates: Understanding the Issues

operating system updates and security updates. They may be able to make commitments more easily

because they support fewer devices, do not customize their operating system by device or carrier, and

their support processes may involve fewer entities (e.g., Apple is the operating system developer and

device manufacturer).

2. Device Manufacturer Update Support Data

As part of this study, we requested operating system update support data from each device

manufacturer for the Order response period: roughly mid-2013 through mid-2016. Three of the eight

respondents provided data conducive to comparison. These three manufacturers, which sell devices

using customized versions of the Android operating system, produce well over 50% of the Android

devices sold. As a result, their practices collectively provide important insight into security update

practices for Android devices.

Each manufacturer provided a detailed spreadsheet identifying the dates on which they released,

sold, and/or updated their devices. We compiled these spreadsheets into a single, comprehensive data set

that enabled us to observe certain characteristics about the data as a whole. 124 We then explored

differences in the data based on several attributes: manufacturer, price tier (i.e.¸ budget, mid-tier, or

premium), popularity (i.e., units sold), and service, and used statistical analysis to analyze the

relationship among these variables. 125 Below is a series of observations based on our data analysis.

Observation #1: For Some Manufacturers, Variation in Update Support Periods Is the Norm.

One salient aspect of the data we received is its heterogeneity at the device level. Figure A-1 shows the

distribution of operating system update support periods (in years) for devices released by three

manufacturers in 2013 and 2014. 126

124

A few notes on the data and our calculations: First, the Order response period (mid-2013 to mid-2016) created an artificial

support cut-off that limited our ability to comment on the evolution of practices over time. We focused our analysis on

devices released in 2013 and 2014, where we could more reliably conclude that a device had stopped receiving updates.

Second, respondents generally provided the month and year of the release and update rather than precise dates. In that

instance, we calculated support period from the first day of the month, which slightly extended some support periods and

reduced others. Third, we calculated support period by comparing release date to the date of the last update. The data does

not identify which, if any, updates were backported patches to unsupported devices. As a result, our calculations may have

inflated some regular support periods. Finally, we describe data only for selected devices so that, consistent with the

requirements of the § 6(b) process requirements, no manufacturer can be identified by device count.

125

Appendix C (Part I) contains tables summarizing these regressions and explains the mechanics of our analysis.

126

See supra note 124 (explaining why we confined our analysis to devices released in 2013 and 2014).

Mobile Security Updates: Understanding the Issues

Figure A-1: Distribution of Update Support Periods in Years

Both the spread of the data and the series of distinct peaks illustrate the variability among

devices’ update support periods. The average period was 1.5 years, but update support lengths ranged

from no update support to almost three years. About a quarter of the devices were supported for less

than one year, but about a third were supported for more than two years.

Update support periods varied significantly even for devices made by the same manufacturer or

with other similar attributes, such as price or popularity. Figure A-2 below is a series of graphs showing

update support period distributions for each of the three manufacturers.

Mobile Security Updates: Understanding the Issues

Figure A-2: Distribution of Update Support Periods by Manufacturer

Here, too, the spread of the data is broad. The average update support period for the first

manufacturer’s devices was 1.3 years, but a substantial number of devices received update support for

less than a year, and few devices were supported for over two years. The second manufacturer’s devices

had a somewhat longer average update support period (1.5 years), but, as with manufacturer #1, update

support periods were variable, ranging from a few months to nearly three years. The third manufacturer

offered the most support (as shown by the skew of the data towards the right), providing updates for an

average of 1.9 years. Although most devices were supported for about one and a half to two and a half

years, support for individual devices ranged from about half a year to more than three years.

The data did not provide meaningful insight into whether devices released since 2015 have

received similarly variable support. However, manufacturers’ narrative responses generally did not

reference any efforts to extend the length of update support periods, and, as noted above, manufacturers

still make few public statements about support period length. Update support variability may remain the

norm.

Observation #2: Many Update Support Periods Are Short, but Devices with Longer Update

Support Periods Are Available. As Figures A-1 and A-2 above show, a substantial number of devices

(about 24%) were supported for less than a year from release. Such short update support periods may be

at odds with how some consumers use their devices. According to a 2015 Gallup poll, more than half of

respondents (54%) reported that they planned to use their phones until they “stop[] working” or

Mobile Security Updates: Understanding the Issues

“become[] totally obsolete.” 127 It is possible that some consumers view phones as “totally obsolete”

when they stop receiving security updates, although this seems unlikely, because consumers typically do

not receive a notification when support ends (and, therefore, are unlikely to know when support ends).

And some consumers might prefer to keep using their old device even if they knew security support has

ended.

According to survey data, consumers are using devices for longer periods. Several years ago,

consumers typically kept a phone for 24-26 months. That figure increased to 29 months in 2016. 128 If

some consumers expect to use their phones for several years, this data suggests that many consumers

will continue to use devices that do not receive security updates.

Respondents’ support data shows that devices with longer update support periods are available.

As Figure A-2 shows, each manufacturer supported some devices with updates for more than two years,

and each supported at least one device with updates for close to three years. But it may be challenging

for security-conscious consumers to compare these devices at the time of purchase. Without consistent

update support period disclosures, consumers must rely on information (perhaps imperfect) obtained

from other sources (e.g., news articles about support), infer likely update support periods from device

characteristics or reputation, 129 or purchase devices offered by the relatively few manufacturers that do

promise to provide updates for a specified period. They may also choose to replace devices at greater

frequency to minimize the risk of an unsupported device.

Observation #3: Some Devices Are Sold After Update Support Has Ended. Data containing the

release date, sales end date, and last update for certain device-carrier combinations revealed that devices

were sometimes sold after update support had ended. That is, devices that had been launched months (or

years) earlier and whose update support period has lapsed continued to be sold to consumers. We

identified 16 examples of post-support device sales.

127

Art Swift, Americans Split on How Often They Upgrade Their Smartphones, GALLUP, July 8, 2015,

http://www.gallup.com/poll/184043/americans-split-often-upgradesmartphones.aspx?utm_source=Economy&utm_medium=newsfeed&utm_campaign=tiles.

128

Press Release, Phone Arena, Americans Are Keeping Their Phones Longer; New Data Says U.S. Users Wait 29 Months

Between Upgrades (Apr. 18, 2016), http://www.phonearena.com/news/Americans-are-keeping-their-phones-longer-newdata-says-U.S.-users-wait-29-months-between-upgrades_id80327.

129

For example, industry observers have reported that Apple allows multiple generations of devices to run the same version

of its operating system; phones receive updates as long as they are capable of running the most recent OS versions. See Apple

Seemingly Ends Support For 32-bit Devices With iOS 10.3.2, APPLE INSIDER, Mar. 28, 2017,

http://appleinsider.com/articles/17/03/28/apple-seemingly-ends-support-for-32-bit-devices-with-ios-1032.

Mobile Security Updates: Understanding the Issues

We are not aware of survey data that identifies how much mobile security support consumers

expect to receive. It seems likely, however, that, absent effective notification, many consumers expect

that their devices will receive some security updates, even if only for a short period.

It is possible that, based on the circumstances, post-support sales could be consistent with

purchasers’ expectations. Most of these sales were of budget or mid-tier phones whose lower price may

have signaled reduced support—although several devices were priced at more than $500. The

Commission did not request evidence as to whether the device manufacturer informed purchasers of this

cost-for-support bargain or otherwise alerted them to the lack of security support. Examining whether,

and to what extent, consumers viewed security support as a relevant characteristic for mobile phones is

an area for future research.

Observation #4: For Some Manufacturers’ Update Support Periods, Price Matters As Much

As Popularity (Or Perhaps Slightly More). Recall that several device manufacturers explained that

when making update support decisions, they consider device popularity, but do not consider price tier.

These data, however, suggest that price point actually correlates with update support as well as

popularity does—or perhaps slightly better. 130

Figure A-3 below is a series of bar graphs showing update support period distribution for

inexpensive (less than $250), mid-tier ($250-500), and costly (more than $500) devices.

130

We conducted a regression analysis, available in Part I of Appendix C, that suggests that price effects are somewhat

stronger than popularity effects.

Mobile Security Updates: Understanding the Issues

Figure A-3: Distribution of Update Support Periods by Price

As these graphs suggest, more expensive devices were more likely to have longer update support

periods. Specifically, the bottom graph, with the most expensive devices, has a greater concentration of

update support periods around 2-3 years, as shown by the cluster of bars on the right. The cheapest

devices (top graph) received the shortest update support periods (an average of 1.3 years). Mid-tier

devices overall received slightly more update support (an average of 1.4 years of support). The most

expensive devices overall received the most update support (an average of 1.9 years).

Price is not a perfect proxy for update support. Figure A-3 shows a wide spread for each graph,

with some inexpensive devices receiving as much as 2.5 years of updates. And as the graph shows (the

bottom bar on the far left), one expensive device did not receive any updates.

Popularity, like price, also correlates with better support. Specifically, the most popular phones

(i.e., those that sold more than 500,000 units) received an average of 1.9 years of support, compared

with the least popular devices (those that sold fewer than 100,000 units), which received an average of

1.3 years of support.

Manufacturers are well aware of the popularity-support correlation; many reported basing

support decisions, at least in part, on device popularity. They did not report a similar awareness of the

correlation between price and support. As discussed in Part III, manufacturers generally do not have

support policies and do not keep records of their update support decisions or the length of update

support by device. One result may be that manufacturers are simply not aware of this historical

relationship between device price and update support.

Mobile Security Updates: Understanding the Issues

Observation #5: Carrier Identity and Service Type Do Not Predict Update Support Period

Overall, But Can Matter Significantly In Individual Instances. As explained in Part III, carriers

sometimes provide substantial input into manufacturers’ update support decisions. Based on these

reports, we examined the data from three manufacturers for evidence of differences in update support

periods depending on carrier identity and the type of service. To compare service type, we divided

service into three categories: (1) major carriers (the four largest carriers), (2) other carriers (including

budget and regional carriers), and (3) those sold without any carrier service (i.e., WiFi-only devices) or

unlinked to any particular carrier’s service (i.e., unlocked devices). Devices in the third category,

WiFi/unlocked, are not customized by carrier and may not undergo any carrier testing.

We did not find significant differences in length of update support period based on these

categories. Although we did not observe significant differences by category overall, we did identify

numerous instances in which identical devices received substantially different update support when

serviced by different carriers or when sold without carrier service. For example, one inexpensive device,

serviced by eight carriers, received as little as eight months of support or double that, depending on the

carrier. One flagship device with carrier service received only 1.3 years of support, but the identical

device serviced by a different carrier received support for over a year more (2.5 years). A third device

received about 1.4 years of support with carrier service, but the unlocked version received 2.9 years of

support.

This demonstrates that consumers owning apparently identical devices—same manufacturer,

same device model—can in fact experience very different update support.

Security Update Frequency

The Commission’s Orders also elicited data showing how frequently certain device

manufacturers issue updates. Regular security updates are important because they help ensure that

devices receive patches for recently discovered vulnerabilities. For example, an Android phone that

receives and installs monthly updates has the most up-to-date security because, as described in Part III,

vulnerability and patching information is released in monthly security bulletins. 131 This section first

describes public statements about update frequency and then discusses certain manufacturers’ update

frequency data.

131

Update frequency is, therefore, one indicator of the strength of a device’s security. Of course, it is not a perfect proxy. A

device could receive fewer updates and nonetheless have robust security overall because of other security features. Moreover,

for some operating systems, less frequent patching could actually be a marker of good security (e.g., strong operating system

design) or a low risk profile (a less prominent attack surface). Nonetheless, devices using the same operating system are

likely to need approximately the same number of security updates, so update frequency is one way to compare similar

devices.

Mobile Security Updates: Understanding the Issues

1. Public Statements about Update Frequency

After discovery of the Stagefright vulnerabilities in mid-2015, news outlets reported certain

Android device manufacturers’ new commitments to regular security updates. 132 In light of these

reports, we searched for public statements regarding security update frequency.

As the chart below shows, only one manufacturer (Microsoft) states that it will provide monthly

updates. Until recently, Blackberry, like Microsoft, provided monthly updates and used its promise of

monthly updates as a means of differentiating its product from other Android devices (e.g., describing

the PRIV device as the “[m]ost secure Android smartphone” with “[b]est-in-class monthly Android

security updates”). 133 Blackberry, however, announced in December 2017 that it would no longer

provide monthly updates. 134

Three manufacturers (LG, Samsung, and Google) make qualified statements about monthly

updates. LG states that certain devices receive security updates, but “[d]epending on regions and

carriers, updates may be released monthly, quarterly, or irregularly.” Samsung identifies specific devices

that receive monthly and quarterly security updates but notes that this list is “subject to change” and is

reviewed “on a periodic basis.” Google describes a monthly patch cycle for its devices and partners

(“We also have an established monthly update cycle for Nexus and Pixel devices, and partners.”),

without expressly promising to deliver monthly updates.

Finally, three manufacturers (Apple, HTC, and Motorola) do not make statements about update

frequency. Following reports that Samsung, LG, and Google were promising monthly updates for some

devices, HTC’s president posted on Twitter that the company would “push for [monthly security

updates],” but it is “unrealistic for anyone to say guaranteed every month.” 135

132

See, e.g., Emily Dreyfuss, Big Android Makers Will Now Push Monthly Security Updates, WIRED, Aug. 6, 2015,

https://www.wired.com/2015/08/google-samsung-lg-roll-regular-android-security-updates/; Samsung Lists Devices to

Receive Monthly Updates, XDA DEVELOPERS, Oct. 19, 2015, https://www.xda-developers.com/samsung-lists-devices-toreceive-monthly-security-updates/.

133

Blackberry Overview, BLACKBERRY, http://www.blackberrymobile.com/us/ (last visited July 6, 2017).

134

Alex Thurber, Status of PRIV Monthly Updates, INSIDE BLACKBERRY BLOG (Dec. 14, 2017),

http://blogs.blackberry.com/2017/12/status-of-priv-monthly-updates/.

135

President of HTC America, Jason Mackenzie, posted on Twitter that the company “will push for them, but unrealistic for

anyone to say guaranteed every month.” Kevin Tofel, HTC Says Monthly Android Security Updates Are “Unrealistic,” ZD

NET, Oct. 5, 2015, http://www.zdnet.com/article/htc-says-monthly-stagefright-android-security-updates-are-unrealistic/.

Mobile Security Updates: Understanding the Issues

Manufacturer

Public Statements About Frequency of Security Updates

Apple

No statement

Blackberry

No statement

Google

“To make Android even safer, we share source code for security fixes every

month with our partners and users. We also have an established monthly

update cycle for Nexus and Pixel devices, and partners.” 136

Android One: “at least one major software update and several smaller

security updates” 137

Specified models receive “ . . Depending on regions and carriers, updates

may be released monthly, quarterly or irregularly.” 138

HTC

No statement

Microsoft

With Windows 10, there are two release types: feature updates that add

new functionality twice per year, and quality updates that provide security

and reliability fixes at least once a month. 139

Motorola

No statement

Samsung

Monthly and quarterly security updates on selected devices ( “subject to

change and . . . will be reviewed on a periodic basis”) 140

136

Android Security Center, GOOGLE, https://www.android.com/security-center/monthly-security-updates/ (last visited Feb.

12, 2018).

137

Nexus Help, supra note 116 (expand drop-down for “Android One devices).

138

LG Security Bulletins, LG, https://lgsecurity.lge.com/security_updates.html (last visited Feb. 12, 2018).

139

Overview of Windows as a Service, MICROSOFT (Feb. 9, 2018), https://docs.microsoft.com/enus/windows/deployment/update/waas-overview.

140

SAMSUNG MOBILE SECURITY BLOG, https://security.samsungmobile.com/main.smsb (last visited Feb. 12, 2018)

[hereinafter SAMSUNG MOBILE SECURITY BLOG].

Mobile Security Updates: Understanding the Issues

2. Security Update Frequency Data

We then compared these public statements with manufacturers’ update frequency data.

Unfortunately, as with support length, few device manufacturers kept records in a manner that allowed

them to readily provide this information. Two manufacturers, however, both of which customize the

Android operating system for a large number of devices, gave us detailed patch history data.

We analyzed this data in a manner similar to how we analyzed support period. First, we

compiled a single data set that enabled us to observe certain characteristics about the data as a whole. 141

Next, we explored differences based on several attributes: manufacturer, price tier, popularity (i.e., units

sold), release date, and service. 142 Below is a series of observations based on this data analysis, which

includes 84 devices from these two manufacturers.

Observation #1: Variation Is the Norm for Update Frequency for Some Manufacturers. As

with support period, we observed enormous device-level variation. Figure B-1 below shows the number

of devices that received x number of updates per year during their support periods.

Figure B-1: Distribution of Updates per Year Within Support Period

for Manufacturers #1 and #2

This multi-modal graph neatly shows the variability of updates per year within the support

period. Most device-service combinations received between 0.5 and 7 updates per year during their

141

The data explanations in note 124, supra, apply to this section as well.

142

See Appendix C, Part II (providing regressions and explaining statistical significance of our analysis).

Mobile Security Updates: Understanding the Issues

support period—a remarkable spread. As the bars on the far right show, a handful received between

about 8 and 10 updates per year. The average number of updates per year was about one per quarter (3.7

per year), but about a quarter of devices received less than 2.3 updates per year. Around a quarter of the

devices received five or more updates per year.

Variability in update frequency was the norm for both manufacturers, although the range in

variation differed. The two graphs in Figure B-2 show the update frequencies for manufacturers #1 and

#2.

Figure B-2: Distribution of Updates per Year within Support Period

for Manufacturers #1 and #2

As the top graph shows, the first manufacturer had a slightly higher average number of updates

per year (4 compared to 3.5), with update frequency concentrated between about one and seven updates

per year during the support period. The second manufacturer had a broader update distribution, with

several devices receiving less than two updates, and a few devices receiving more than eight updates per

year on average.

Observation #2: For At Least Some Manufacturers, Update Frequency Remains Highly

Variable. We examined the data to determine whether, over time, update frequency has increased,

decreased, or stayed the same. We did not observe a consistent increase or decrease in update frequency

for all devices from these two manufacturers over the 2013-16 time period. To the contrary, update

frequency for all devices from these two manufacturers remained highly variable. 143 Our data sample

143

See Appendix C, Part II.

Mobile Security Updates: Understanding the Issues

mostly predates or is contemporaneous with the Stagefright incident and immediate aftermath. Increases

in update frequency, if any, are more likely to be seen from studying data from 2016-2018.

Observation #3: Some Device Manufacturers Have Not Adopted Security-Only Updates or a

Regular Patch Schedule. Device manufacturers using the Android operating system reported efforts to

implement Google’s post-Stagefright monthly patch release schedule and to develop security-only

updates. Manufacturer-carrier communications revealed challenges to implementing these process

changes. The data also suggests uneven progress.

Monthly updates appear to be uncommon for at least some manufacturers. In this data, only one

device-service combination received monthly updates within a one-year period. 144 No other deviceservice combination approached this frequency of updates. Indeed, the same device that received

monthly updates with one service option only received one update when serviced by a different carrier.

Security-only updates are not the norm. One device manufacturer identified the type of each

update it issued (e.g., functionality, security, or emergency). It reported that 20 out of 154 total updates

were security-only releases. Of those 20 security-only updates, eleven were for the single device

described above that received monthly updates. The rest of its large device portfolio received nine

security-only releases over a several year period. This suggests that at least this manufacturer has

continued to prefer maintenance releases, which bundle security and functionality updates, to securityonly updates.

Observation #4: For At Least Some Manufacturers’ Update Frequency, Price Matters More

Than Popularity. Price was a more significant predictor of update frequency than device popularity, at

least for these two manufacturers. Figure B-3 below shows a series of graphs based on price: the first

shows update frequency for devices costing less than $250; the second for devices priced between $250

and $500; and the third costing more than $500.

144

This device did not receive monthly updates for its entire support period, so these monthly updates are not visible on

Figure B-2, which shows average annual updates within support period.

Mobile Security Updates: Understanding the Issues

Figure B-3: Distribution of Updates per Year within Support Period by Device Price

As these graphs suggest, expensive devices (in the bottom graph) were more likely to receive

frequent updates (as shown by the bars on the far right). The cheapest devices typically received 3.2

updates per year; mid-tier devices received 3.6 updates per year; and the highest priced devices averaged

4.9 updates per year.

Although price, overall, correlates with more frequent updates, price did not correlate with

update frequency for every device-service combination. Indeed, the most expensive devices had the

most significant variation in update frequency. Whereas the top two graphs (of low-cost and mid-tier

devices) show update frequencies somewhat clustered together, the bottom graph spreads out

significantly, with several high-priced devices receiving fewer than four updates per year and others

receiving more than eight.

Whereas price, overall, did predict update frequency, popularity, measured in units sold for each

device-carrier combination, was a less reliable indicator. The most popular devices (those selling more

than 500,000 units) received the same number of updates per year (3.8) as less popular devices (those

selling less than 100,000 units).

Observation #5: Based on Evidence from Two Manufacturers, Devices Serviced by Major

Carriers Have Received Slightly More Frequent Updates. Based on our review of manufacturer and

carrier narratives and communications, it appeared that some carriers emphasize security updates more

than others. To explore whether these apparent differences were reflected in the update frequency data,

we used the data from the two manufacturers described above to compare update frequency for major

carriers (the four largest carriers) and all other carriers (including budget and regional carriers). Figure

B-4 below shows the results.

Mobile Security Updates: Understanding the Issues

Figure B-4: Density of Number of Updates per Year by Carrier Type

As Figure B-4 suggests, devices serviced by major carriers (top graph) were updated more

frequently than devices serviced by other carriers (bottom graph). Specifically, devices serviced by

major carriers received on average 4.1 updates per year, compared with an average of 3.2 updates per

year for other carriers. The spread of the data in both graphs is considerable, and is particularly large for

devices serviced by major carriers. Although most devices received three or four updates a year, devices

serviced by major carriers received anywhere from no updates to monthly updates. Devices serviced by

other carriers received anywhere from no updates to bimonthly updates.

Although the differences in the average annual update frequency between major and minor

carriers do not seem large (roughly four versus three), the differences for particular devices could be

dramatic. For example, one device received as few as one and as many as 15 updates over the course of

its support period, depending on the carrier. The single update was issued by a budget carrier, so perhaps

any value consumers may have lost as a result of fewer security updates was offset by the lower price

paid by the device owners. 145

Disparities in update frequency based on carrier, like the disparity in support length, means that

consumers owning apparently identical devices may in fact have had very different protections for their

personal information. For example, in mid-2015, one device manufacturer released security updates to

address Stagefright vulnerabilities on every carrier version of its device—except one. As a result, some

consumers remained vulnerable to text-message transmitted malware; owners of identical devices

serviced by different carriers were not.

145

The Orders did not ask for information about whether consumers were informed about minimal security support.

Mobile Security Updates: Understanding the Issues

Patch Development and Testing

The Order required respondents to identify when they learned of vulnerabilities and patches and

when related updates were ready for testing and deployment. The respondents generally did not maintain

records that would allow them to readily identify these dates. 146 Most, however, provided some data

related to patch development and testing. This section discusses that data and makes some observations

about how quickly respondents patch vulnerabilities. 147

Observation #1: Although Android Device Manufacturers Have Adopted Practices To

Expedite Security Patch Development and Testing, Patch Development Times Vary. As Parts II and III

described, after discovery of the Stagefright vulnerabilities in mid-2015, Android device manufacturers

took steps to expedite security patch development and testing, such as adopting a fast-track for securityonly updates. Only two manufacturers provided data conducive to comparing their patch rates.

Based on this data, it appears that one manufacturer patched vulnerabilities more slowly over

time, although we do not know the reasons for the apparent slowing. A second manufacturer patched

vulnerabilities at about the same rate (or somewhat more slowly) over time. Figure C-1 below, with

these manufacturers’ patching data for years 2014, 2015, and 2016, illustrates these patch rates.

146

Device manufacturers generally maintain records about updates (which may patch multiple vulnerabilities) rather than

individual vulnerabilities (the focus of the Order). As a result, manufacturers provided data with somewhat different dates

(e.g., the date of discovery or notification of the vulnerability; the date on which its patch was ready for testing or was

incorporated into an update ready for testing; the date on which the carrier received or approved the update; the date on which

the update was first deployed or deployment was completed). These inconsistencies prevent precise comparisons of

manufacturers’ practices.

147

We confined our analysis to vulnerabilities patched via updates (rather than those corrected by the time of a device’s

initial release). As with the data on support length and update frequency, we used a regression analysis to examine the

statistical significance of various attributes (e.g., price tier, popularity, carrier service, device release year). See Appendix C,

Part III (containing regressions and statistical analysis).

Mobile Security Updates: Understanding the Issues

Manufacturer 1

Manufacturer 2

Figure C-1: Percentage of Vulnerabilities Fixed as Time (in Days) since Discovery Increases, by Year,

for Manufacturers #1 and #2

As the first graph shows, manufacturer #1 patched vulnerabilities at about the same rate for years

2014-2016. There are modest increases in 2016 (blue line) compared with 2015 (orange line), but this

manufacturer overall patched vulnerabilities more quickly in 2014 (green line). As the second graph

shows, manufacturer #2 appears to have patched vulnerabilities at a noticeably slower rate over time.

We have far more data for years 2014 and 2015 than for year 2016; a more complete data set might,

perhaps, show a different trajectory for other vulnerabilities patched in 2016.

The apparent slowing in patch rate could be the result of a number of factors attributable to the

manufacturers and/or one or more of their partners (e.g., delays in the operating system developer’s

provision of patches, delays in customizing patches for individual devices, delays in partner testing,

discovery of vulnerabilities that are more challenging to patch). Unfortunately, the data is insufficiently

detailed to tease out these (or other) potential factors influencing patch rate. Ultimately, it is important to

note that much of this data predates Stagefright, so it reflects little of the post-Stagefright measures to

increase patch rate.

Observation #2: Some Device Manufacturers Patch Expensive, Popular Devices Somewhat

Faster. Four manufacturers reported that device popularity influences their support decisions. As

discussed in Part IV.A-B above, however, support data from three manufacturers suggests that device

price is as good—or even better—a predictor of both support length and update frequency as popularity.

To explore further the relationship among price, popularity, and support, we first analyzed how

quickly inexpensive devices (less than $250), mid-tier devices ($251-$500) and expensive devices (more

than $500) were patched. We then analyzed how quickly unpopular devices (less than 100,000 units

sold), mid-tier devices (between 100,000 and 500,000 units sold) and popular devices (more than

500,000 units sold) were patched. Although no manufacturer identified price as relevant to its support

Mobile Security Updates: Understanding the Issues

decisions, we found that, for the two manufacturers from whom we received data, both higher prices and

greater popularity were associated with faster patching.

The pair of graphs in Figure C-2 below illustrates how price matters. The graphs show the rate at

which vulnerabilities for inexpensive, mid-tier, and expensive devices were fixed over time (i.e., the

percentage of vulnerabilities that were patched over the number of days since the vulnerability was

discovered) for two manufacturers with large Android device portfolios.

Manufacturer 1

Manufacturer 2

Figure C-2: Percentage of Vulnerabilities Fixed as Time (in Days) since Discovery Increases, by Price

Band, for Manufacturers #1 and #2

As the graphs show, for both manufacturers, vulnerabilities on the most expensive devices

(shown with the steeply sloped blue lines) were fixed faster than other devices.

Figure C-3 below illustrates the varying significance of popularity. For Manufacturer #1,

popularity did predict faster patching; as the blue line shows, the most popular devices were patched

faster than less popular ones. Popularity was not as consistent a predictor of support for Manufacturer

#2; as the orange line shows, devices of medium popularity were patched faster than both more and less

popular devices.

Mobile Security Updates: Understanding the Issues

Manufacturer 1

Manufacturer 2

Figure C-3: Percentage of Vulnerabilities Fixed as Time (in Days) since Discovery Increases, by

Popularity Band, for Manufacturers #1 and #2

Observation #3: Unlocked Devices Tend To Be Patched More Quickly Than Devices Sold

With a Particular Carrier’s Service. To explore further the relationship between carrier service and

update support, we compared the patch rates for: (1) WiFi-only and unlocked devices (i.e., devices sold

without a particular carrier’s service), (2) devices sold with major carrier service, and (3) devices sold

with other carrier service. Figure C-4 below illustrates the results of our analysis. The pair of graphs

show the rate at which two Android device manufacturers patched vulnerabilities (i.e., the percentage of

vulnerabilities that were patched over the number of days since vulnerability discovery), based on

service type: major carrier, other carrier, and WiFi-only/unlocked.

Manufacturer 1

Manufacturer 2

Figure C-4: Percentage of Vulnerabilities Fixed as Time (in Days) since Discovery Increases, by

Carrier Type, for Manufacturers #1 and #2

Mobile Security Updates: Understanding the Issues

As the figures show, unlocked phones or WiFi-only tablets (represented by the blue lines) were

patched much more quickly (for manufacturer #2) or somewhat more quickly (for manufacturer #1) than

devices with carrier service (orange and green lines). Devices serviced by major carriers (represented by

the green lines) were patched slightly more quickly than devices serviced by other carriers (represented

by the orange lines). Note, however, that variation remains. While unlocked/WiFi-only devices may be

patched somewhat faster overall, particular devices may receive faster updates with carrier services. 148

The relative rapidity of patching for WiFi-only and unlocked devices is consistent with

manufacturers’ reports that carrier customization and testing take time.

Observation #4: Newer Devices Are Patched More Quickly Than Older Devices. Manufacturers

reported that they allocate support towards newer devices. To understand the effect of device age on

patching speed, we analyzed how quickly devices were patched depending on their release date (in

2013, 2014, or 2015). Figure C-5 below illustrates our analysis. It presents a pair of line graphs showing

the rate at which two Android device manufacturers patched vulnerabilities, based on the year the device

was released (a green line for 2013; an orange line for 2014; and a blue line for 2015).

Manufacturer 1

Manufacturer 2

Figure C-5: Percentage of Vulnerabilities Fixed as Time (in Days) since Discovery Increases, by Device

Release Year, for Manufacturers #1 and #2

148

See, e.g., Aamir Siddiqui, Unlocked Samsung Galaxy S7 and S7 Edge Get Slower Updates than Carrier Variants, XDA

DEVELOPERS, Feb. 17, 2017, https://www.xda-developers.com/security-update-discrimination-unlocked-samsung-galaxy-s7and-s7-edge-get-slower-updates-than-carrier-variants/ (describing how “users who purchased the phone [Samsung Galaxy S7

and S7 Edge] at full retail [unlocked] are at a disadvantage against users who opted for a carrier-based contract”).

Mobile Security Updates: Understanding the Issues

As the manufacturers reported, device age is indeed predictive of support. Although the

differences in patch speed for 2014 and 2015 devices (blue and orange lines) are not great, the difference

between 2013 devices (represented in green) and more recently released devices is larger. 149 We did not

receive sufficient data to analyze patch rates for devices released in 2016 or 2017, but manufacturers

reported that their attention to device age has remained constant.

Observation #5: Vulnerabilities Fixed in Large Bundled Updates May Be Patched More

Slowly Than Those Patched in Smaller Updates. As discussed in Part III, device manufacturers may

deliver security patches through security-only updates or through maintenance releases that bundle both

functionality and security updates. Manufacturers reported that maintenance releases take much longer

to develop and test than stand-alone security updates because they involve many more working parts.

To explore the relationship between bundling and patching speed, we compared the patching

times for vulnerabilities fixed in new operating system releases (i.e., large bundled updates) with those

for vulnerabilities patched in post-release updates (some of which are security-only updates). This

attempt to compare bundles with security-only updates is imperfect. Not all post-release updates are

security-only updates; many are bundled updates (although the bundles are smaller than new operating

system releases). Nevertheless, these groupings permit a rough comparison of the time to patch

vulnerabilities in large or small bundles.

Figure C-6 illustrates the results. It presents a pair of bar graphs showing the time from discovery

of a vulnerability to release of the update for one manufacturer’s devices. The graph on the left shows

the patching rate for new operating system versions; the graph on the right shows the patching rate for

post-release updates.

149

Using a statistical analysis, we determined that these differences were statistically significant. See Appendix C, Part III.

Mobile Security Updates: Understanding the Issues

Figure C-6: Patching Time (in Days) for New Operating System Releases (Left) versus Post-Operating

System Releases (Right)

Two key points are evident from these graphs. First, more vulnerabilities are patched in postoperating system releases than in new operating system releases. This makes sense; the focus of a new

release is new functionality rather than patching. Second, post-operating system releases patch

vulnerabilities in less time. Specifically, the first graph, with patching times for vulnerabilities fixed in

new operating system releases, shows that although many vulnerabilities were patched within 250 days,

it took much longer to patch many vulnerabilities (shown in the concentration of bars between

approximately 250 and 600 days). By contrast, the second graph, with patching times for vulnerabilities

fixed in post-release updates, shows a higher concentration of vulnerabilities patched in about six

months or less; very few vulnerabilities were patched after the 200-day mark. 150

These differences, of course, do not necessarily mean that all patching delay is attributable to

bundling. There are a number of factors that may have contributed to slower patching in new operating

system releases. For example, the manufacturer may have made a reasonable decision to bundle patches

for low-risk vulnerabilities (for which there was little time pressure) in an operating system release in

order to prioritize critical, time-sensitive patches in interim updates. But this data is consistent with

reports from both industry observers and manufacturers themselves that bundling security and

functionality changes can contribute to slower patching. 151

150

Using a regression analysis, we determined that these differences were statistically significant. See Appendix C, Part III.

151

See supra Part III.C.

Mobile Security Updates: Understanding the Issues

Observation #6: Some Operating Systems Are Patched More Quickly Than Others. Finally,

because four of the device manufacturers from whom we received data are (or have been) operating

system developers, we used the data to compare how quickly vulnerabilities affecting different operating

systems were patched. Figure C-7, which presents a pair of graphs for two operating systems with the

distribution of updates over time (days from discovery of the vulnerability to release of an update with a

patch), illustrates the results. 152

Figure C-7: Testing Time (in Days) for Operating System Developers #1 and #2 during the Order

Response Period 153

As the graphs show, many vulnerabilities discovered in each operating system were patched

within several months. The average patching time for Operating System #1 was 119 days, or less than

four months. The average testing time for Operating System #2 was 189 days, or less than six months.

As the bars towards the right show, it took much longer (several years) to patch a number of

vulnerabilities in both operating systems.

152

As explained supra note 145, the Order respondents kept records in different ways, which prevents ready comparison of

their data. This illustration compares the patching times for two operating systems whose developers maintained records in a

similar fashion.

153

The graphs display the distribution of vulnerabilities patched during the Order response period in less than 1000 days.

Operating System Developer #1 patched two vulnerabilities after 1,000 days (1,318 days and 2,061 days). We excluded these

outliers to permit better visual comparison of how quickly most vulnerabilities were patched.

Mobile Security Updates: Understanding the Issues

But the graphs contrast on the right. Whereas there are only a few short bars in the right portion

of the graph for Operating System #1, the second graph is bimodal, showing that it took more than two

years to patch many vulnerabilities in Operating System #2. Specifically, 10% exceeded 640 days, and

5% exceeded 824 days. By contrast, such long patching times were rare for Operating System #1; less

than 5% exceeded 356 days.

The Order, which focused on manufacturers’ practices, did not request information to explain

differences in operating system developers’ practices or the risk profiles of their systems. We cannot,

therefore, account for the variability we observed. Operating system developers may gain additional

insight by continuing to analyze these issues.

Uptake Rates

The final type of data we studied is uptake, the rate at which updates are installed on devices. In

response to the Order’s request for uptake data, most device manufacturers provided average uptake

rates and ranges, accompanied only by sporadic uptake data about certain individual updates. Several

explained that gaps existed because another party (e.g., a carrier partner) deployed most updates and did

not provide back reports on uptake. One Android device manufacturer, however, provided detailed

uptake data for devices serviced by at least some carriers. This section discusses the data and reports we

received to make some observations about uptake. 154

Observation #1: Uptake Rates Vary Widely by Update. Uptake rates often vary significantly

among updates. For example, depending on the update, device manufacturers reported uptake rates

ranging from less than 1 to 100%, less than 1 to 93%, 1 to 77%, and 13 to 100%. Manufacturers that

excluded inactive devices (i.e., devices that have not been used in the past month or longer) reported

narrower ranges (e.g., 53-89% uptake for security updates, and 67-100% uptake for all releases). 155

Carriers, some of which have greater visibility into uptake rates because they primarily deploy

the updates, reported somewhat higher numbers. One carrier stated that operating system updates for

expensive smartphones were installed over 90% of the time, but the acceptance rate for other devices

was around 80%. Another stated that “the vast majority of . . . customers (typically over 90 percent)

install Android security updates within two to four weeks of release.” But carriers, like manufacturers,

also noted that uptake varies considerably by update. For example, one carrier stated that, depending on

the update, uptake varies between 60 and 98%.

154

As with the data on support length and update frequency, we used a regression analysis to examine the statistical

significance of certain attributes (e.g., type of carrier service). See Appendix C, Part IV.

155

Another manufacturer provided an average uptake rate (70% for active devices) rather than providing a range. One

manufacturer stated that it did not have and, therefore, could not provide any uptake data.

Mobile Security Updates: Understanding the Issues

Figure D-1 below depicts the distribution of uptake for the one manufacturer that provided the

most granular data. This graph neatly illustrates the variability in uptake that manufacturers and carriers

reported.

Figure D-1: Distribution of Percent Uptake for One Manufacturer’s Updates

The figure shows the wide range of update success. A majority of updates had high take rates:

about half above 80%. Nearly half, however, fell below 80%, about a quarter of updates fell below 50%,

and one fell below 10%.

Observ

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

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.