We introduced Android’s Private Compute Core in Android 12 Beta. Today, we're excited to announce a new suite of services that provide a privacy-preserving bridge between Private Compute Core and the cloud.
Recap: What is Private Compute Core?
Android’s Private Compute Core is an open source, secure environment that is isolated from the rest of the operating system and apps. With each new Android release we’ll add more privacy-preserving features to the Private Compute Core. Today, these include:
For these features to be private, they must:
Introducing Android’s Private Compute Services
Machine learning features often improve by updating models, and Private Compute Services helps features get these updates over a private path. Android prevents any feature inside the Private Compute Core from having direct access to the network. Instead, features communicate over a small set of purposeful open-source APIs to Private Compute Services, which strips out identifying information and uses a set of privacy technologies, including Federated Learning, Federated Analytics, and Private information retrieval.
We will publicly publish the source code for Private Compute Services, so it can be audited by security researchers and other teams outside of Google. This means it can go through the same rigorous security programs that ensure the safety of the Android platform.
We’re enthusiastic about the potential for machine learning to power more helpful features inside Android, and Android’s Private Compute Core will help users benefit from these features while strengthening privacy protections via the new Private Compute Services. Android is the first open source mobile OS to include this kind of externally verifiable privacy; Private Compute Services helps the Android OS continue to innovate in machine learning, while also maintaining the highest standards of privacy and security.
As an active member of the open source software (OSS) community, Google recognizes the growing threat of software supply chain attacks against OSS we use and develop. Building on our efforts to improve OSS security with an end-to-end framework (SLSA), metrics (Scorecards), and coordinated vulnerability disclosure (guide), we are excited to announce Allstar.
Allstar is a GitHub app that continuously enforces security policy settings through selectable automated enforcement actions. Allstar is already filing and closing security issues for Envoy and GoogleContainerTools, with more organizations and repositories lined up.
See the OpenSSF announcement for more information on Allstar.
Today we are excited to announce some changes to our lineup of Titan Security Keys on the Google Store which provide a simpler experience and make choosing the right security key for you even easier. We will now offer only two types of Titan Security Keys: a USB-A and a USB-C version. Both of these keys have Near Field Communication (NFC) functionality, which allows you to use it with most mobile devices by simply tapping it on the back of your mobile device in order to sign in securely. These keys will be available for all users starting tomorrow, August 10. In 2018, Google introduced the Titan Security Key as a direct defense against credential phishing. Phishing occurs when an attacker tries to trick you into giving them your username and password, and it remains one of the easiest and most successful ways of breaching accounts online. Paired with our Advanced Protection Program and its industry-leading automatic protections, the Titan Security Key remains one of the best ways to keep your Google Account safe.
Chrome's Site Isolation is an essential security defense that makes it harder for malicious web sites to steal data from other web sites. On Windows, Mac, Linux, and Chrome OS, Site Isolation protects all web sites from each other, and also ensures they do not share processes with extensions, which are more highly privileged than web sites. As of Chrome 92, we will start extending this capability so that extensions can no longer share processes with each other. This provides an extra line of defense against malicious extensions, without removing any existing extension capabilities.
Meanwhile, Site Isolation on Android currently focuses on protecting only high-value sites, to keep performance overheads low. Today, we are announcing two Site Isolation improvements that will protect more sites for our Android users. Starting in Chrome 92, Site Isolation will apply to sites where users log in via third-party providers, as well as sites that carry Cross-Origin-Opener-Policy headers.
Our ongoing goal with Site Isolation for Android is to offer additional layers of security without adversely affecting the user experience for resource-constrained devices. Site Isolation for all sites continues to be too costly for most Android devices, so our strategy is to improve heuristics for prioritizing sites that benefit most from added protection. So far, Chrome has been isolating sites where users log in by entering a password. However, many sites allow users to authenticate on a third-party site (for example, sites that offer "Sign in with Google"), possibly without the user ever typing in a password. This is most commonly accomplished with the industry-standard OAuth protocol. Starting in Chrome 92, Site Isolation will recognize common OAuth interactions and protect sites relying on OAuth-based login, so that user data is safe however a user chooses to authenticate.
Additionally, Chrome will now trigger Site Isolation based on the new Cross-Origin-Opener-Policy (COOP) response header. Supported since Chrome 83, this header allows operators of security-conscious websites to request a new browsing context group for certain HTML documents. This allows the document to better isolate itself from untrustworthy origins, by preventing attackers from referencing or manipulating the site's top-level window. It’s also one of the headers required to use powerful APIs such as SharedArrayBuffers. Starting in Chrome 92, Site Isolation will treat non-default values of the COOP header on any document as a signal that the document's underlying site may have sensitive data and will start isolating such sites. Thus, site operators who wish to ensure their sites are protected by Site Isolation on Android can do so by serving COOP headers on their sites.
As before, Chrome stores newly isolated sites locally on the device and clears the list whenever users clear their browsing history or other site data. Additionally, Chrome places certain restrictions on sites isolated by COOP to keep the list focused on recently-used sites, prevent it from growing overly large, and protect it from misuse (e.g., by requiring user interaction on COOP sites before adding them to the list). We continue to require a minimum RAM threshold (currently 2GB) for these new Site Isolation modes. With these considerations in place, our data suggests that the new Site Isolation improvements do not noticeably impact Chrome's overall memory usage or performance, while protecting many additional sites with sensitive user data.
Given these improvements in Site Isolation on Android, we have also decided to disable V8 runtime mitigations for Spectre on Android. These mitigations are less effective than Site Isolation and impose a performance cost. Disabling them brings Android on par with desktop platforms, where they have been turned off since Chrome 70. We advise that sites wanting to protect data from Spectre should consider serving COOP headers, which will in turn trigger Site Isolation.
Users who desire the most complete protection for their Android devices may manually opt in to full Site Isolation via chrome://flags/#enable-site-per-process, which will isolate all websites but carry higher memory cost.
Follow