Posted by Sai Teja Peddinti, Nina Taft and Igor Bilogrevic from PDPO Applied Privacy Research, and Pauline Anthonysamy from Android Security and Privacy.
User trust is critical to the success of developers of every size. On the Google Play Store, we aim to help developers boost the trust of their users, by surfacing signals in the Developer Console about how to improve their privacy posture. Towards this aim, we surface a message to developers when we think their app is asking for permission that is likely unnecessary.
This is important because numerous studies have shown that user trust can be affected when the purpose of a permission is not clear.¹ In addition, research has shown that when users are given a choice between similar apps, and one of them requests fewer permissions than the other, they choose the app with fewer permissions.²
Determining whether or not a permission request is necessary can be challenging. Android developers request permissions in their apps for many reasons - some related to core functionality, and others related to personalization, testing, advertising, and other factors. To do this, we identify a peer set of apps with similar functionality and compare a developer’s permission requests to that of their peers. If a very large percentage of these similar apps are not asking for a permission, and the developer is, we then let the developer know that their permission request is unusual compared to their peers. Our determination of the peer set is more involved than simply using Play Store categories. Our algorithm combines multiple signals that feed Natural Language Processing (NLP) and deep learning technology to determine this set. A full explanation of our method is outlined in our recent publication, entitled “Reducing Permissions Requests in Mobile Apps” that appeared in the Internet Measurement Conference (IMC) in October 2019.³ (Note that the threshold for surfacing the warning signal, as stated in this paper, is subject to change.)
We surface this information to developers in the Play Console and we let the developer make the final call as to whether or not the permission is truly necessary. It is possible that the developer has a feature unlike all of its peers. Once a developer removes a permission, they won’t see the warning any longer. Note that the warning is based on our computation of the set of peer apps similar to the developers. This is an evolving set, frequently recomputed, so the message may go away if there is an underlying change to the set of peers apps and their behavior. Similarly, even if a developer is not currently seeing a warning about a permission, they might in the future if the underlying peer set and its behavior changes. An example warning is depicted below.

This warning also helps to remind developers that they are not obligated to include all of the permission requests occurring within the libraries they include inside their apps. We are pleased to say that in the first year after deployment of this advice signal nearly 60% of warned apps removed permissions. Moreover, this occurred across all Play Store categories and all app popularity levels. The breadth of this developer response impacted over 55 billion app installs.³ This warning is one component of Google’s larger strategy to help protect users and help developers achieve good security and privacy practices, such as Project Strobe, our guidelines on permissions best practices, and our requirements around safe traffic handling.
Acknowledgements
Giles Hogben, Android Play Dashboard and Pre-Launch Report teams

References

[1] Modeling Users’ Mobile App Privacy Preferences: Restoring Usability in a Sea of Permission Settings, by J. Lin B. Liu, N. Sadeh and J. Hong. In Proceedings of Usenix Symposium on Privacy & Security (SOUPS) 2014.
[2] Using Personal Examples to Improve Risk Communication for Security & Privacy Decisions, by M. Harbach, M. Hettig, S. Weber, and M. Smith. In Proceedings of the SIGCHI Conference on Human Computing Factors in Computing Systems, 2014.
[3] Reducing Permission Requests in Mobile Apps, by S. T. Peddinti, I. Bilogrevic, N. Taft, M Pelikan, U. Erlingsson, P. Anthonysamy and G. Hogben. In Proceedings of ACM Internet Measurement Conference (IMC) 2019.

Posted by Jon Markoff, Staff Developer Advocate, Android Security

Have you ever tried to encrypt data in your app? As a developer, you want to keep data safe, and in the hands of the party intended to use. But if you’re like most Android developers, you don’t have a dedicated security team to help encrypt your app’s data properly. By searching the web to learn how to encrypt data, you might get answers that are several years out of date and provide incorrect examples.

The Jetpack Security (JetSec) crypto library provides abstractions for encrypting Files and SharedPreferences objects. The library promotes the use of the AndroidKeyStore while using safe and well-known cryptographic primitives. Using EncryptedFile and EncryptedSharedPreferences allows you to locally protect files that may contain sensitive data, API keys, OAuth tokens, and other types of secrets.

Why would you want to encrypt data in your app? Doesn’t Android, since 5.0, encrypt the contents of the user's data partition by default? It certainly does, but there are some use cases where you may want an extra level of protection. If your app uses shared storage, you should encrypt the data. In the app home directory, your app should encrypt data if your app handles sensitive information including but not limited to personally identifiable information (PII), health records, financial details, or enterprise data. When possible, we recommend that you tie this information to biometrics for an extra level of protection.

Jetpack Security is based on Tink, an open-source, cross-platform security project from Google. Tink might be appropriate if you need general encryption, hybrid encryption, or something similar. Jetpack Security data structures are fully compatible with Tink.

Key Generation

Before we jump into encrypting your data, it’s important to understand how your encryption keys will be kept safe. Jetpack Security uses a master key, which encrypts all subkeys that are used for each cryptographic operation. JetSec provides a recommended default master key in the MasterKeys class. This class uses a basic AES256-GCM key which is generated and stored in the AndroidKeyStore. The AndroidKeyStore is a container which stores cryptographic keys in the TEE or StrongBox, making them hard to extract. Subkeys are stored in a configurable SharedPreferences object.

Primarily, we use the AES256_GCM_SPEC specification in Jetpack Security, which is recommended for general use cases. AES256-GCM is symmetric and generally fast on modern devices.

val keyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)

For apps that require more configuration, or handle very sensitive data, it’s recommended to build your KeyGenParameterSpec, choosing options that make sense for your use. Time-bound keys with BiometricPrompt can provide an extra level of protection against rooted or compromised devices.

Important options:

• userAuthenticationRequired() and userAuthenticationValiditySeconds() can be used to create a time-bound key. Time-bound keys require authorization using BiometricPrompt for both encryption and decryption of symmetric keys.
• unlockedDeviceRequired() sets a flag that helps ensure key access cannot happen if the device is not unlocked. This flag is available on Android Pie and higher.
• Use setIsStrongBoxBacked(), to run crypto operations on a stronger separate chip. This has a slight performance impact, but is more secure. It’s available on some devices that run Android Pie or higher.

Note: If your app needs to encrypt data in the background, you should not use time-bound keys or require that the device is unlocked, as you will not be able to accomplish this without a user present.

// Custom Advanced Master Key
val advancedSpec = KeyGenParameterSpec.Builder(
    "master_key",
    KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
).apply {
    setBlockModes(KeyProperties.BLOCK_MODE_GCM)
    setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    setKeySize(256)
    setUserAuthenticationRequired(true)
    setUserAuthenticationValidityDurationSeconds(15) // must be larger than 0
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
        setUnlockedDeviceRequired(true)
        setIsStrongBoxBacked(true)
    }
}.build()

val advancedKeyAlias = MasterKeys.getOrCreate(advancedSpec)

Unlocking time-bound keys

You must use BiometricPrompt to authorize the device if your key was created with the following options:

• userAuthenticationRequired is true
• userAuthenticationValiditySeconds > 0

After the user authenticates, the keys are unlocked for the amount of time set in the validity seconds field. The AndroidKeystore does not have an API to query key settings, so your app must keep track of these settings. You should build your BiometricPrompt instance in the onCreate() method of the activity where you present the dialog to the user.

BiometricPrompt code to unlock time-bound keys

// Activity.onCreate

val promptInfo = PromptInfo.Builder()
    .setTitle("Unlock?")
    .setDescription("Would you like to unlock this key?")
    .setDeviceCredentialAllowed(true)
    .build()

val biometricPrompt = BiometricPrompt(
    this, // Activity
    ContextCompat.getMainExecutor(this),
    authenticationCallback
)

private val authenticationCallback = object : AuthenticationCallback() {
        override fun onAuthenticationSucceeded(
            result: AuthenticationResult
        ) {
            super.onAuthenticationSucceeded(result)
            // Unlocked -- do work here.
        }
        override fun onAuthenticationError(
            errorCode: Int, errString: CharSequence
        ) {
            super.onAuthenticationError(errorCode, errString)
            // Handle error.
        }
    }

To use:
biometricPrompt.authenticate(promptInfo)

Encrypt Files

Jetpack Security includes an EncryptedFile class, which removes the challenges of encrypting file data. Similar to File, EncryptedFile provides a FileInputStream object for reading and a FileOutputStream object for writing. Files are encrypted using Streaming AEAD, which follows the OAE2 definition. The data is divided into chunks and encrypted using AES256-GCM in such a way that it's not possible to reorder.

val secretFile = File(filesDir, "super_secret")
val encryptedFile = EncryptedFile.Builder(
    secretFile,
    applicationContext,
    advancedKeyAlias,
    FileEncryptionScheme.AES256_GCM_HKDF_4KB)
    .setKeysetAlias("file_key") // optional
    .setKeysetPrefName("secret_shared_prefs") // optional
    .build()

encryptedFile.openFileOutput().use { outputStream ->
    // Write data to your encrypted file
}

encryptedFile.openFileInput().use { inputStream ->
    // Read data from your encrypted file
}

Encrypt SharedPreferences

If your application needs to save Key-value pairs - such as API keys - JetSec provides the EncryptedSharedPreferences class, which uses the same SharedPreferences interface that you’re used to.

Both keys and values are encrypted. Keys are encrypted using AES256-SIV-CMAC, which provides a deterministic cipher text; values are encrypted with AES256-GCM and are bound to the encrypted key. This scheme allows the key data to be encrypted safely, while still allowing lookups.

EncryptedSharedPreferences.create(
    "my_secret_prefs",
    advancedKeyAlias,
    applicationContext,
    PrefKeyEncryptionScheme.AES256_SIV,
    PrefValueEncryptionScheme.AES256_GCM
).edit {
    // Update secret values
}

More Resources

FileLocker is a sample app on the Android Security GitHub samples page. It’s a great example of how to use File encryption using Jetpack Security.

Happy Encrypting!

Posted by Elie Bursztein, Security & Anti-Abuse Research Lead; David Tao, Software Engineer; Neil Kumaran, Product Manager, Gmail Security 


Gmail protects your incoming mail against spam, phishing attempts, and malware. Our existing machine learning models are highly effective at doing this, and in conjunction with our other protections, they help block more than 99.9% of threats from reaching Gmail inboxes.

Posted by Per Bjorke, Senior Product Manager, Ad Traffic Quality
As part of our ongoing efforts — along with help from newly developed technologies — today we’re announcing nearly 600 apps have been removed from the Google Play Store and banned from our ad monetization platforms, Google AdMob and Google Ad Manager, for violating our disruptive ads policy and disallowed interstitial policy.
Mobile ad fraud is an industry-wide challenge that can appear in many different forms with a variety of methods, and it has the potential to harm users, advertisers and publishers. At Google, we have dedicated teams focused on detecting and stopping malicious developers that attempt to defraud the mobile ecosystem. As part of these efforts we take action against those who create seemingly innocuous apps, but which actually violate our ads policies.
We define disruptive ads as ads that are displayed to users in unexpected ways, including impairing or interfering with the usability of device functions. While they can occur in-app, one form of disruptive ads we’ve seen on the rise is something we call out-of-context ads, which is when malicious developers serve ads on a mobile device when the user is not actually active in their app.
This is an invasive maneuver that results in poor user experiences that often disrupt key device functions and this approach can lead to unintentional ad clicks that waste advertiser spend. For example, imagine being unexpectedly served a full-screen ad when you attempt to make a phone call, unlock your phone, or while using your favorite map app’s turn-by-turn navigation.
Malicious developers continue to become more savvy in deploying and masking disruptive ads, but we’ve developed new technologies of our own to protect against this behavior. We recently developed an innovative machine-learning based approach to detect when apps show out-of-context ads, which led to the enforcement we’re announcing today.
As we move forward, we will continue to invest in new technologies to detect and prevent emerging threats that can generate invalid traffic, including disruptive ads, and to find more ways to adapt and evolve our platform and ecosystem policies to ensure that users and advertisers are protected from bad behavior.

Posted by Christiaan Brand, Product Manager, Google Cloud 

Security keys provide the strongest protection against phishing attacks. That’s why they are an important feature of the Advanced Protection Program that provides Google’s strongest account protections for users that consider themselves at a higher risk of targeted, sophisticated attacks on their personal or work Google Accounts.

Last year, we made the Titan Security Key bundle with USB-A/NFC and Bluetooth/USB/NFC keys available in Canada, France, Japan, the UK, and the US. Starting today, USB-C Titan Security Keys are available in those countries, and the bundle and USB-C Titan Security Keys are now available on the Google Store in Austria, Germany, Italy, Spain, and Switzerland.

Security keys use public-key cryptography to verify your identity and URL of the login page so that an attacker can’t access your account even if they have your username or password. Unlike other two-factor authentication (2FA) methods that try to verify your sign-in, security keys support FIDO standards that provide the strongest protection against automated bots, bulk phishing attacks, and targeted phishing attacks.

We highly recommend users at a higher risk of targeted attacks (e.g., political campaign teams, activists, journalists, IT administrators, executives) to get Titan Security Keys and enroll into the Advanced Protection Program (APP). If you’re working in a federal political campaigns team in the US, you can now request free Titan Security Keys via Defending Digital Campaigns and get help enrolling into the APP. Bulk orders are also available for enterprise organizations in select countries.

You can also use Titan Security Keys for any site where FIDO security keys are supported for 2FA, including your personal or work Google Account, 1Password, Bitbucket, Bitfinex, Coinbase, Dropbox, Facebook, GitHub, Salesforce, Stripe, Twitter, and more.

Posted by Andrew Ahn, Product Manager, Google Play + Android App Safety
[Cross-posted from the Android Developers Blog]

Google Play connects users with great digital experiences to help them be more productive and entertained, as well as providing app developers with tools to reach billions of users around the globe. Such a thriving ecosystem can only be achieved and sustained when trust and safety is one of its key foundations. Over the last few years we’ve made the trust and safety of Google Play a top priority, and have continued our investments and improvements in our abuse detection systems, policies, and teams to fight against bad apps and malicious actors.
In 2019, we continued to strengthen our policies (especially to better protect kids and families), continued to improve our developer approval process, initiated a deeper collaboration with security industry partners through the App Defense Alliance, enhanced our machine learning detection systems analyzing an app’s code, metadata, and user engagement signals for any suspicious content or behaviors, as well as scaling the number and the depth of manual reviews. The combination of these efforts have resulted in a much cleaner Play Store:

• Google Play released a new policy in 2018 to stop apps from unnecessarily accessing privacy-sensitive SMS and Call Log data. We saw a significant, 98% decrease in apps accessing SMS and Call Log data as developers partnered with us to update their apps and protect users. The remaining 2% are comprised of apps that require SMS and Call Log data to perform their core function.
• One of the best ways to protect users from bad apps is to keep those apps out of the Play Store in the first place. Our improved vetting mechanisms stopped over 790,000 policy-violating app submissions before they were ever published to the Play Store.
• Similarly to our SMS and Call Log policy, we also enacted a policy to better protect families in May 2019. After putting this in place, we worked with developers to update or remove tens of thousands of apps, making the Play Store a safer place for everyone.

In addition we’ve launched a refreshed Google Play Protect experience, our built-in malware protection for Android devices. Google Play Protect scans over 100B apps everyday, providing users with information about potential security issues and actions they can take to keep their devices safe and secure. Last year, Google Play Protect also prevented more than 1.9B malware installs from non-Google Play sources.
While we are proud of what we were able to achieve in partnership with our developer community, we know there is more work to be done. Adversarial bad actors will continue to devise new ways to evade our detection systems and put users in harm's way for their own gains. Our commitment in building the world's safest and most helpful app platform will continue in 2020, and we will continue to invest in the key app safety areas mentioned in last year’s blog post:

• Strengthening app safety policies to protect user privacy
• Faster detection of bad actors and blocking repeat offenders
• Detecting and removing apps with harmful content and behaviors

Our teams of passionate product managers, engineers, policy experts, and operations leaders will continue to work with the developer community to accelerate the pace of innovation, and deliver a safer app store to billions of Android users worldwide.

Posted by Joe DeBlasio, Chrome security team
Update (April 6, 2020): Chrome was originally scheduled to start user-visible warnings on mixed downloads in Chrome 82. These warnings, as well as subsequent blocking, will be delayed by two releases. Console warnings on mixed downloads will begin as scheduled in Chrome 81.

User-visible warnings will start in Chrome 84. The text below has been updated to reflect this change. Developers who are otherwise able to do so are encouraged to transition to secure downloads as soon as possible to avoid future disruption.

Today we’re announcing that Chrome will gradually ensure that secure (HTTPS) pages only download secure files. In a series of steps outlined below, we’ll start blocking "mixed content downloads" (non-HTTPS downloads started on secure pages). This move follows a plan we announced last year to start blocking all insecure subresources on secure pages.

Insecurely-downloaded files are a risk to users' security and privacy. For instance, insecurely-downloaded programs can be swapped out for malware by attackers, and eavesdroppers can read users' insecurely-downloaded bank statements. To address these risks, we plan to eventually remove support for insecure downloads in Chrome.

As a first step, we are focusing on insecure downloads started on secure pages. These cases are especially concerning because Chrome currently gives no indication to the user that their privacy and security are at risk.

Starting in Chrome 84 (to be released July 2020), Chrome will gradually start warning on, and later blocking, these mixed content downloads. File types that pose the most risk to users (e.g., executables) will be impacted first, with subsequent releases covering more file types. This gradual rollout is designed to mitigate the worst risks quickly, provide developers an opportunity to update sites, and minimize how many warnings Chrome users have to see.

We plan to roll out restrictions on mixed content downloads on desktop platforms (Windows, macOS, Chrome OS and Linux) first. Our plan for desktop platforms is as follows:

• In Chrome 81 (released March 2020) and later:
• Chrome will print a console message warning about all mixed content downloads.

• In Chrome 84 (released July 2020):
• Chrome will warn on mixed content downloads of executables (e.g. .exe).

• In Chrome 85 (released August 2020):
• Chrome will block mixed content executables.
• Chrome will warn on mixed content archives (.zip) and disk images (.iso).

• In Chrome 86 (released October 2020):
• Chrome will block mixed content executables, archives and disk images.
• Chrome will warn on all other mixed content downloads except image, audio, video and text formats.

• In Chrome 87 (released November 2020):
• Chrome will warn on mixed content downloads of images, audio, video, and text.
• Chrome will block all other mixed content downloads.

• In Chrome 88 (released January 2021) and beyond, Chrome will block all mixed content downloads.