`Case 2:17-cv-00514—JRG Document 221-7 Filed 02/21/19 Page 1 of 17 PageID #: 19232
`
`
`
`EXHIBIT F
`EXHIBIT F
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 2 of 17 PageID #: 19233
`
`EXHIBIT 5
`Andrew Wolfe, Ph.D.
`
`2/1/19
`
`Reported by'. Holly Th uman
`CSR 6834, RMR, CRR
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 3 of 17 PageID #: 19234
`
`Contents
`
`3
`
`Overview
`
`7
`
`Google Security
`Services for Android
`
`23
`
`Android Platform
`Security
`
`36
`
`Ecosystem Data
`
`68
`
`Noteworthy
`Vulnerabilities
`
`70
`
`Acknowledgements
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 4 of 17 PageID #: 19235
`
`Overview
`
`Google is committed to protecting the security and privacy of all Android
`users. Keeping more than 1.4 billion devices safe starts with a strong
`foundation-the core Android platform-which is strengthened by regular
`security updates for the platform, applications, and devices and constantly
`evolving security services that monitor and protect the ecosystem.
`
`In 2016, Google worked closely with device manufacturers, system on a chip
`(SoC) providers, and telecom carriers to release security patches to more
`devices than ever before. We made key security features like data encryption
`and verified boot the standard for over one hundred million users. In addition
`to making devices more secure, we actively protected users from application
`threats by reducing the impact of Potentially Harmful Applications (PHAs)
`inside and outside of Google Play and improving the quality of security in
`hundreds of thousands of applications. Overall, devices, apps, and users are
`safer than ever.
`
`Looking forward to 2017, we're working to increase the number of patched
`Android devices and accelerate adoption of key platform security features.
`We believe that advances in machine learning and automation can help
`reduce PHA rates significantly 111 2017, both inside and outside of Google Play.
`
`This is Google's third annual report on Android's security protections.
`The report covers new and updated features, provides metrics that informed
`our view of Android security, and discusses trends around security for Android
`devices in 201 6.
`
`Google security services for Android
`
`Devices with Google Mobile Services (GMS) are protected straight out of
`the box by a complete set of endpoint security and antivirus services. This set
`includes both cloud-based and pre-installed on-device services that use
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 5 of 17 PageID #: 19236
`
`real-time data from the Android ecosystem to understand the security
`environment. Because Google's security services generally don't require
`firmware or platform-level patches to update, they provide a first line of
`defense against evolving security threats.
`
`By 04 2016, fewer than 0.71 % of devices
`had Potentially Harmful Applications (PHAs)
`installed and for devices that exclusively
`download apps from Google Play, that number
`was even smaller at 0.05%.
`
`These small numbers are thanks in part to Google's responsive
`security services.
`
`Google regularly enhances its security services for Android. In 2016, we used
`machine learning and statistical analysis to further automate and speed
`up detection of PHAs and other threats. Enhancements to the Safe Browsing
`service, which protects users from phishing sites and websites hosting
`malware, improved PHA device-scanning capabilities and enabled third-party
`developers to leverage the power of Safe Browsing in their own applications .
`Third-party developers took advantage of the security services offered through
`SafetyNet APls, such as SafetyNet Attest, which serves nearly 200 million
`requests per day.
`
`Android platform security
`
`All Android devices share a common, platform-level security model. This model
`has been enhanced over multiple years with SELinux protections, application
`1solat1on using sandboxing, exploit mitigations, and cryptographic features,
`like file-based encryption and Verified Boot.
`
`In 2016, Android expanded platform-level security with the launch of Android
`7.0 . We streamlined our boot-up process to make it easier to install over-the(cid:173)
`air (OTA) security updates. To support this faster boot up, we implemented
`file-based encryption, which also better isolates and protects individual users
`and profiles on a device. We re-architected the mediaserver stack to address
`Stagefrlght-type vulnerabilities by adding integer overflow protections and
`compartmentalizing mediaserver's components into individual sandboxes with
`minimal privileges. We also increased the degree of randomness in address
`space layout randomization (ASLR), making some attacks more difficult.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 6 of 17 PageID #: 19237
`
`Ecosystem security programs
`Android promotes security best practices in a variety of ways. The Android
`Compatibility Definition Document (COD) and Compatibility Test Suite (CTS)
`provide a detailed series of security requirements and a testing framework
`to verify compatibility. Google works with device manufacturers to keep
`devices secure and quickly adopt security updates and features on all
`supported devices.
`
`Google Play encourages application developers to adopt security best
`practices. We launched 18 campaigns to notify application developers about
`vulnerabilities or recommended security improvements in their apps in Play,
`resulting in security upgrades to over 275,000 apps.
`
`As promised in 2015, we released monthly security bulletins and patches
`to the Android Open Source Project (AOSP). We worked closely with device
`manufacturers, SoC providers, and carriers to ship security updates, and
`introduced a freshness test for security patch levels in CTS. By 04 2016,
`over half of the top 50 devices worldwide had a recent security patch.
`
`Several manufacturers, including Samsung,
`LG, BlackBerry, and OnePlus, regularly deliver
`security updates to flagship devices on the
`same day as Google's updates to Nexus and
`Pixel devices, thereby providing their customers
`with the most up-to-date security available.
`
`Openness strengthens security
`
`Android has been open source since its launch. Because all Android source
`code is publicly available, individuals and companies can create their own
`versions of Android and even add security features.
`
`Open source code means that Android is subject to more scrutiny and creates
`more opportunities for research. We consider this a strength of the platform
`as it allows security researchers to directly examine the code for weaknesses.
`To encourage this, Google offers a security bug bounty program for researchers
`who find and report vulnerabilities to Google. This allows us to fix the reported
`vulnerabilities and improve the overall health of Android devices. In this
`way, Android lever ages the expertise of the security community as a whole.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 7 of 17 PageID #: 19238
`
`Over 100 security researchers made public
`contributions to Android in 2016, for a total
`of nearly 1 million dollars in security rewards .
`
`We continue to iterate and innovate upon Android's security features. In 2016,
`we protected Android users-both on and off their devices-by improving
`our cloud security services, updating the Android platform, and investing in
`our ongoing ecosystem security programs.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 8 of 17 PageID #: 19239
`
`Google Security
`Services for Android
`
`Google protects the Android ecosystem with pre-installed cloud-based and
`on-device services, providing multiple layers of security protections to devices.
`All devices with GMS have a complete set of endpoint and antivirus services that
`protect against common threats including network attacks, application exploits,
`Potentially Harmful Applications, and physical attacks, such as device theft.
`
`Google's security services for Android can be updated independently of device
`or carrier implementations. This autonomy facilitates quick responses to
`emerging security threats, allowing us to block or minimize their impact of
`newly discovered vulnerabilities.
`
`This diagram shows the range of different security services and technologies
`provided by Google for Android.
`
`0
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 9 of 17 PageID #: 19240
`
`In 2016, Google's security services conducted over 790 million device security
`scans daily, protecting Android phones, tablets, smartwatches, and TVs. The
`goal is to provide the right protection at the moment it is needed by the user.
`
`On-device services
`
`This table lists the on-device protections offered in 2016, along with a brief
`description of their roles in device and/or data protection.
`
`Service
`
`Protection
`
`Verify Apps
`
`Antivirus protection and removal options for
`downloaded PHAS
`
`SafetyNet
`
`Protection from network and application-based threats
`
`Safe Browsing
`
`Protection from deceptive websites
`
`Developer APls
`
`Allows third-party applications to use Google's security
`services
`
`Android Device Manager
`
`Protection for lost or stolen devices
`
`Smart Lock
`
`Encourage lock screen adoption by reducing friction
`around device unlock
`
`All of these services integrate with a cloud-based component that allows
`Google to push updates to the device.
`
`In the following section, we provide a description of these services, along with
`new features and improvements made to these on-device protections in 2016.
`
`Verify Apps
`Verify Apps uses a cloud-based service to determine if applications are
`potentially harmful. It scans applications before installation and blocks
`installs of PHAs. It also runs regular scans on all installed apps. If a PHA
`is found, Verify Apps prompts the user to remove it. In cases where the
`PHA has no possible benefit to users, Verify Apps can remove the PHA from
`affected devices with a notification to the user. Future installs of the PHA
`will be blocked.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 10 of 17 PageID #: 19241
`
`In 2016, we made Autoscan faster and more robust. While all devices are
`scanned at least once every 6 days, devices with indicators of installed PHAs
`or other risk factors are scanned more frequently. This feature leverages the
`new Safe Browsing API on Android that pushes information to devices when
`new risk indicators are found. If the device matches a risk indicator, then
`Verify Apps starts a full scan to check that all installed apps are behaving
`in a safe manner.
`
`Rare app collection
`Verify Apps protects users against applications that are installed from any
`source-whether they come from Google Play or not-so it is important that
`our systems understand as many applications as possible. All applications
`that are submitted to Google Play undergo a review prior to publication.
`Similarly, Google's cloud-based systems review all applications they can find
`on public websites.
`
`Users can send applications directly from their device to Google for review
`by enabling the "Improve harmful app detection" feature in Settings. The more
`applications that Verify Apps analyzes, the more accurate it is at identifying
`PHAs. In 2016, approximately 1.8 million rare applications were uploaded by
`Verify Apps, up 87% from 2015.
`
`Harmful secondary installations
`Some harmful apps attempt to install other applications without user
`knowledge or consent. These applications can be benign, but 37% of the time
`they are a PHA. To address this, we updated Verify Apps to automatically
`block install attempts initiated by an installed PHA in September 2016.
`
`Verify Apps blocks between 0.4% and 1.2%
`of all secondary install attempts each day and
`prevents PHAs from benefltting from these
`potential secondary app installs.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 11 of 17 PageID #: 19242
`
`This chart shows the trend of blocked installation attempts made by PHAs
`as a portion of all app installs.
`
`Blocked harmful secondary install attempts
`
`Nove nbtr
`
`1
`
`Safety Net
`In 2013, we introduced SafetyNet, which allows devices to contribute
`security-related information to Google's cloud-based services. This can
`include information about security events, logs, configurations, and other
`security-relevant information. Before 2016, only users that installed apps
`from unknown sources were prompted to enable SafetyNet's protection.
`In 2016, SafetyNet is enabled by default on all Android devices with Google
`Play; users can still opt out of SafetyNet's extended protection in Settings.
`
`SafetyNet integrations
`In addition to the changes to SafetyNet's default settings for consumer pro(cid:173)
`tection, we also updated its APls and documentation to encourage developer
`and enterprise adoption. The SafetyNet Attestation API, launched in 2015,
`helps developers assess the security and compatibility of the Android environ(cid:173)
`ments in which their apps run . It determines the integrity of the device and
`the application, and is commonly used as a signal in anti-abuse systems.
`
`In 2016, we added the basiclntegrity field to the API response to help developers
`assess a broader spectrum of devices than the existing ctsProflleMatch .
`If SafetyNet Attestation returns true for basiclntegrity, then the device exhibits
`the properties of a functional Android device with a working security model,
`though it might not pass Android compatibility testing. If ctsProfileMatch is also
`true, then the profile of the device running the developer's app matches the
`profile of a device that has passed Android compatibility testing (CTS). Device
`manufacturers submit their CTS test results to Google as part of the certification
`process for Google's applications; Google believes that devices that return
`ctsProfileMatch fulflll Android's security and compatibility requirements.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 12 of 17 PageID #: 19243
`
`The SafetyNet Attestation API gathers information about the state of devices
`globally. This table shows the percentage of devices that match an unaltered
`CTS profile certified by Google (ctsProfileMatch) and devices that report
`passing the basic integrity checks (basic Integrity) for the 20 countries
`with the largest number of active users of Google Play.
`
`Country
`
`Argentina
`
`Brazil
`
`Canada
`
`France
`
`Germany
`
`Great Britain
`
`India
`
`Indonesia
`
`Italy
`
`Japan
`
`Korea
`
`Mexico
`
`Russia
`
`Saudi Arabia
`
`Spain
`
`Taiwan
`
`CTS profile match
`
`Basic integrity
`
`85%
`
`93%
`
`92%
`
`92%
`
`93%
`
`94%
`
`86%
`
`79%
`
`90%
`
`97%
`
`97%
`
`82%
`
`80%
`
`90%
`
`83%
`
`94%
`
`91%
`
`96%
`
`94%
`
`96%
`
`95%
`
`97%
`
`96%
`
`89%
`
`95%
`
`97%
`
`97%
`
`91%
`
`93%
`
`94%
`
`90%
`
`95%
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 13 of 17 PageID #: 19244
`
`Country
`
`Thailand
`
`Turkey
`
`United States
`
`Vietnam
`
`CTS profile match
`
`Basic integrity
`
`65%
`
`79%
`
`94%
`
`79%
`
`95%
`
`87%
`
`96%
`
`89%
`
`To make integration easier for developers, we published updated
`documentation and released sample code for Android and server-side
`verification on GitHub. This continued effort in developer advocacy resulted
`in SafetyNet attestation adoption by major entertainment, enterprise,
`and financial applications. SafetyNet attest served nearly 200 million
`requests per day in 2016, an increase of about 25% over 2015.
`
`Checking device certification with Google Play
`In late 2016, we updated the Google Play Store app to show whether a device
`is certified by Google when the device preloads Google applications. Users,
`retailers, carriers, and device manufacturers can see a device's certification
`status in Play Settings
`
`Safe Browsing
`Google introduced Safe Browsing in 2005. Safe Browsing protects users
`against threats by allowing client applications to check UR Ls against lists
`of unsafe web resources, such as social engineering sites (phishing and
`deceptive sites) and sites that host malware or unwanted software. When
`a user attempts to visit an unsafe web resource, their Safe Browsing-supported
`browser displays a warning.
`
`Approximately a billion users take advantage of Safe Browsing every day.
`For every million page views across all platforms, Safe Browsing shows
`around 125 warnings: 80% of which are phishing or social engineering and
`20% are malware.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 14 of 17 PageID #: 19245
`
`Safe Browsing warning
`
`w J3 I ID lei'
`
`Safe Browsing protects Chrome desktop users, as well as other popular
`desktop web browsers. In December 2015, Google Play Services incorporated
`an API that extended Safe Browsing's protections to the Chrome browser on
`Android devices.
`
`In mid-2016, we released the Safe Browsing
`API to third-party developers, which allows their
`apps to use Safe Browsing's database of known
`harmful UR Ls with little additional work on
`their part.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 15 of 17 PageID #: 19246
`
`This allows all apps to use the same protections as the Chrome Browser while
`being considerate of the user's data plan, network bandwidth, and privacy.
`
`Safe Browsing sometimes flags legitimate websites that have been taken over
`by a hostile attacker. Once these legitimate websites remove the harmful code
`and are restored to a safe state, Safe Browsing removes the warning. Some
`harmful websites take advantage of this by temporarily removing the harmful
`behavior to get the warning lifted. Once the warning is removed the website
`reinstates the harmful behavior.
`
`To mitigate these tactics and better protect our users, we adjusted our
`policies to classify these sites as Repeat Offenders, in 2016. Repeat Offenders
`are websites that switch between compliant and policy-violating behavior
`to obtain a successful review and have warnings removed. Repeat Offender
`websites receive a Safe Browsing warning for at least 30 days and the site's
`webmaster cannot request a review to remove the warning until the 30 days
`has passed.
`
`Android Device Manager
`User data is more often at risk from lost or stolen devices than from PHAs.
`To help solve this, Google introduced the Android Device Manager (ADM)
`service in 2013. Users can find their lost device by using the ADM website
`or downloading the ADM app to a different Android device. With either
`approach, users can see their device's location, make it ring, set up a lock
`screen, or wipe all their personal data and accounts from their device.
`
`ADM is available to all Android users who sign into their Google accounts
`on their devices. Users who also enable location services can find their devices
`with ADM ADM is enabled by default on devices running Android 4.4 and
`above. In 2016, we improved ADM by:
`
`- Translating the ADM website into 31 additional languages, for a total of 79.
`- Releasing the ADM app to Android Wear devices, so users can use their
`watch to find their phone.
`
`Most users access ADM by going to the website or searching for the phrase
`"find my phone."
`
`In 2016, approximately 380,000 people used
`ADM to find their phones each day.
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 16 of 17 PageID #: 19247
`
`We started saving ADM usage data in September 2016. This graph shows ADM
`trends since then .
`
`Android Device Manager-Daily users
`
`I
`
`II
`
`......... ----
`
`_,...._ _......,,,, __.,,..,.,....__...... ______ ---......... _____ ._.,,,.... ------ ---..---......
`
`SE ptnrbE 2'll
`
`I t
`
`01
`
`n
`
`Locate and Ring are the most commonly used ADM features. Far fewer users
`take protective measures to lock or wipe their devices, suggesting that most
`users are able to recover their lost devices.
`
`Android Device Manager-Actions
`
`•
`
`•
`
`•
`
`t D Iv
`
`T
`
`er
`
`WEt di'/ J
`
`r
`
`App la f I 'f'
`
`• Lid
`
`-
`
`I
`
`H
`
`01' )UI f
`
`( 6
`
`'<, r lcrJC16
`
`Cc cern tr r r
`
`
`
`Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 17 of 17 PageID #: 19248
`
`To perform any of these actions, the device must be on and have network
`access. ADM contacts the phone in real time to determine its location.
`If the device is off, location services are off, or it can't connect to the network,
`ADM won't be able to find it. Improving protections for lost or stolen devices
`that are not able to connect to the network, such as by strengthening device
`encryption, is an active area of research and development.
`
`Smart Lock
`Lock screens greatly increase user privacy and security. Many users choose
`not to use a lock screen because manually unlocking their device dozens
`or even hundreds of times a day is frustrating. In 2014, Android 5.0 introduced
`Smart Lock, which allows a user's device to remain unlocked as long as it is in
`their possession. This is determined by certain security signals, such as facial
`recognition; trusted places, like a user's home or office; and paired Bluetooth
`devices, such as a smartwatch or car. Enterprises can manage these security
`signals via API to suit their IT policy.
`
`Smart Lock added other security signals including voice recognition and
`on-body detection, which keep the phone unlocked while it's on the user's body.
`Devices running Android 7.0 and above prompt users to set a lock screen and
`enable Smart Lock's on-body detection to remove the friction of entering a PIN
`or password. This reduces the number of times that a user needs to manually
`unlock their device and encourages adoption of a more secure lock screen.
`
`Smart Lock users manually unlock their device about half as often as before
`they enabled the feature. And users who configure Smart Lock with multiple
`unlock mechanisms experience even better results-the combined use of
`trusted Bluetooth devices, trusted places, and on-body detection reduces the
`number of manual unlocks by about 90%. In 2016, Smart Lock's daily active
`users increased nearly 175% over 2015.
`
`Smart Lock-Manual unlock reduction, by type
`
`-
`
`