throbber
Case 2:17-cv-00514-JRG Document 221-7 Filed 02/21/19 Page 1 of 17 PageID #: 19232
`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
`
`-
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket