File-Based Encryption Direct Boot experience
One of the security features introduced in Android Nougat was file-based encryption. File-based encryption (FBE) means different files are encrypted with different keys that can be unlocked independently. FBE also separates data into device encrypted (DE) data and credential encrypted (CE) data.

Direct boot uses file-based encryption to allow a seamless user experience when a device reboots by combining the unlock and decrypt screen. For users, this means that applications like alarm clocks, accessibility settings, and phone calls are available immediately after boot.

 Enhanced with TrustZone® security

 Modern processors provide a means to execute code in a mode that remains secure even if the kernel is compromised. On ARM®-based processors this mode is known as TrustZone. Starting in Android Nougat, all disk encryption keys are stored encrypted with keys held by TrustZone software.

This secures encrypted data in two ways:

  • TrustZone enforces the Verified Boot process. If TrustZone detects that the operating system has been modified, it won't decrypt disk encryption keys; this helps to secure device encrypted (DE) data.
  • TrustZone enforces a waiting period between guesses at the user credential, which gets longer after a sequence of wrong guesses. With 1624 valid four-point patterns and TrustZone's ever-growing waiting period, trying all patterns would take more than four years. This improves security for all users, especially those who have a shorter and more easily guessed pattern, PIN, or password.

Encryption on Pixel phones

Protecting different folders with different keys required a distinct approach from full-disk encryption (FDE). The natural choice for Linux-based systems is the industry-standard eCryptFS. However, eCryptFS didn't meet our performance requirements. Fortunately one of the eCryptFS creators, Michael Halcrow, worked with the ext4 maintainer, Ted Ts'o, to add encryption natively to ext4, and Android became the first consumer of this technology. ext4 encryption performance is similar to full-disk encryption, which is as performant as a software-only solution can be.


Additionally, Pixel phones have an inline hardware encryption engine, which gives them the ability to write encrypted data at line speed to the flash memory. To take advantage of this, we modified ext4 encryption to use this hardware by adding a key reference to the bio structure, within the ext4 driver before passing it to the block layer. (The bio structure is the basic container for block I/O in the Linux kernel.) We then modified the inline encryption block driver to pass this to the hardware. As with ext4 encryption, keys are managed by the Linux keyring. To see our implementation, take a look at the source code for the Pixel kernel.


While this specific implementation of file-based encryption using ext4 with inline encryption benefits Pixel users, FBE is available in AOSP and ready to use, along with the other features mentioned in this post.

Percentage of pages loaded over HTTPS in Chrome



As the remainder of the web transitions to HTTPS, we’ll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications, and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP. As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we’ve posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance.


We’ve seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented: “We were able to migrate Wayfair.com to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS.” CNET, a large tech news site, had a similar experience: “We successfully completed our move of CNET.com to HTTPS last month,” said John Sherwood, Vice President of Engineering & Technology at CNET. “Since then, there has been no change in our Google rankings or Google organic search traffic.”


Webmasters that include ads on their sites also should carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense, or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post, “saw no material impact to AdX revenue with the transition to SSL.”


As migrating to HTTPS becomes even easier, we’ll continue working towards a web that’s secure by default. Don’t hesitate to start planning your HTTPS migration today!

OnHub’s security features go beyond those of the typical router: OnHub is hardened against a variety of attacks, protecting your home network from many online threats. Three features in particular help ensure OnHub protects your data and devices from a variety of threats.

Three Security features that set OnHub apart

 1. Defense in Depth
There are many elements that go into creating a robust defense in depth.

Auto updates: OnHub regularly downloads automatic updates without you having to do anything--a long-established practice on mobile devices and software like Chrome, but one that appliances haven’t caught up with yet. These updates provide regular maintenance fixes and address critical vulnerabilities. They’re like the seatbelts of online security— internet security experts recommend that users always accept updates.

However, when updates don’t happen automatically, many people don’t bother. OnHub communicates directly with Google, and makes sure all software is signed and verified. For instance, when a vulnerability was found in a software library (glibc) earlier this year, we were able to update OnHub’s entire fleet of devices within just a few days. In comparison, the vast majority of other routers require active user intervention to protect against such threats.

Verified Boot: Verified Boot protects you by preventing compromised OnHubs from booting. We use this technology in Chromebooks, strictly enforce it in Android Nougat, and we implemented it in OnHub from the very beginning. This makes OnHub extremely difficult to attack or compromise. For instance, the device runs software that has been cryptographically signed by Google.

Cloud administration: A traditional router is commonly attacked through its local administration web interface, where attackers have taken advantage of exploits like CSRF to remotely take control and change critical settings like DNS, so we eliminated that from the beginning. Instead OnHub is managed through the cloud, with strong authentication and authorization, using a simple phone app. A read-only API is available only on the internal network, to provide important data to the OnHub app during setup and when troubleshooting.

Process isolation: We also layer multiple techniques such as process isolation (uid/gid separation, namespaces, capability whitelists) and seccomp filtering to isolate network-facing services, which helps reduce potential attack scenarios in a given application by preventing an attacker from making lateral movements in the system.

2. Hardware Provenance
Modern hardware devices include many types of chips, drivers, and firmware. It’s important to know what each part is doing and where it came from. Our security team works to track the origins of all hardware, software, and firmware that goes into OnHub, including those from third-party sources. If a vulnerability is ever found, OnHub security works to fix the problem immediately.

The same goes for the open source components of OnHub. Before shipping, we do comprehensive code reviews of critical attack surfaces (i.e. network facing daemons), looking for security vulnerabilities. For example, we reviewed miniupnpd, hostapd, and dnsmasq. As a result of those reviews, Google reported security bugs to the open source project maintainers and offered patches. Here are three that we fixed: bugs in hosted.

3. Cloud Intelligence
We use anonymized metrics from our fleet of OnHubs to quickly detect and counter potential threats. For example, since we know that DNS is often a target of attacks, we monitor DNS settings on all OnHub routers for activity that could indicate a security compromise. This is “cloud intelligence” – a benefit that Google is uniquely able to deliver. By connecting OnHub to the Google cloud, we provide the same level of protection you expect across all your Google apps and devices. Because you manage your router through the cloud using your secure Google identity, you don’t have to remember yet another password for managing your OnHub, and you don’t have to be at home to control it.

Security Improvements, Automatically
OnHub also participates in Google’s Vulnerability Reward Program, which started in 2010 to honor all of the cutting-edge external contributions that help us keep our users safe. Through this program, if you can find a qualifying bug in OnHub’s security, rewards range from $100 to $20,000. Click here for an outline of the rewards for the most common classes of bugs.

When it comes to security, not all routers are created equal. OnHub protects you and your network with security that continues to adapt to threats. We’re always improving OnHub security, and automatically update without users having to take any actions. As cybersecurity evolves and new threats emerge, OnHub will be ready to meet the latest challenges for years to come.

Even with such a helpful tool, building a safe script whitelist for a complex application is often all but impossible due to the number of popular domains with resources that allow CSP to be bypassed. Here’s where the idea of a nonce-based CSP policy comes in. Instead of whitelisting all allowed script locations, it’s often simpler to modify the application to prove that a script is trusted by the developer by giving it a nonce -- an unpredictable, single-use token which has to match a value set in the policy:

Content-Security-Policy: script-src 'nonce-random123'

 <script nonce='random123'>alert('This script will run')</script>
<script>alert('Will not run: missing nonce')</script>
<script nonce='bad123'>alert("Won't run: invalid nonce")</script>

 With 'strict-dynamic', a part of the upcoming CSP3 specification already supported by Chrome and Opera (and coming soon to Firefox), adopting such policies in complex, modern applications becomes much easier. Developers can now set a single, short policy such as:

script-src 'nonce-random123' 'strict-dynamic'; object-src 'none'

 and make sure that all static <script> elements contain a matching nonce attribute — in many cases this is all that’s needed to enjoy added protection against XSS since ‘strict-dynamic’ will take care of loading any trusted scripts added at runtime. This approach allows setting policies which are backwards-compatible with all CSP-aware browsers, and plays well with applications which already use a traditional CSP policy; it also simplifies the process of adopting CSP and doesn’t require changing the policy as the application evolves.

Adopting strict CSP
In the past months we’ve deployed this approach in several large Google applications, including Cloud Console, Photos, History, Careers Search, Maps Timeline, Cultural Institute and are working on many more. We believe this approach can also help other developers so today we’re publishing documentation discussing the best strategies for implementing CSP, including an overview of the benefits of CSP, sample policies, and examples of common code changes.

Further, today we’re releasing CSP Mitigator, a Chrome extension that helps developers review an application for compatibility with nonce-based CSP. The extension can be enabled for any URL prefix and will collect data about any programming patterns that need to be refactored to support CSP. This includes identifying scripts which do not have the correct nonce attribute, detecting inline event handlers, javascript: URIs, and several other more subtle patterns which might need attention.
As with the CSP Evaluator, we use the extension with our applications to help speed up the process of adopting nonce-based CSP policies nonce-based policies across Google.

Encouraging broader use of strict CSP
Finally, today we’re including CSP adoption efforts in the scope of the Patch Reward Program; proactive work to help make popular open-source web frameworks compatible with nonce-based CSP can qualify for rewards (but please read the program rules and CSP refactoring tips first). We hope that increased attention to this area will also encourage researchers to find new, creative ways to circumvent CSP restrictions, and help us further improve the mechanism so that we can better protect Internet users from web threats.

To reach out to us, email [email protected].


Chrome currently indicates HTTP connections with a neutral indicator. This doesn’t reflect the true lack of security for HTTP connections. When you load a website over HTTP, someone else on the network can look at or modify the site before it gets to you.


A substantial portion of web traffic has transitioned to HTTPS so far, and HTTPS usage is consistently increasing. We recently hit a milestone with more than half of Chrome desktop page loads now served over HTTPS. In addition, since the time we released our HTTPS report in February, 12 more of the top 100 websites have changed their serving default from HTTP to HTTPS.


Studies show that users do not perceive the lack of a “secure” icon as a warning, but also that users become blind to warnings that occur too frequently. Our plan to label HTTP sites more clearly and accurately as non-secure will take place in gradual steps, based on increasingly stringent criteria. Starting January 2017, Chrome 56 will label HTTP pages with password or credit card form fields as "not secure," given their particularly sensitive nature.


In following releases, we will continue to extend HTTP warnings, for example, by labelling HTTP pages as “not secure” in Incognito mode, where users may have higher expectations of privacy. Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.

We will publish updates to this plan as we approach future releases, but don’t wait to get started moving to HTTPS. HTTPS is easier and cheaper than ever before, and enables both the best performance the web offers and powerful new features that are too sensitive for HTTP. Check out our set-up guides to get started.

Encryption support is getting stronger across the Android ecosystem as well. Starting with Marshmallow, all capable devices were required to support encryption. Many devices, like Nexus 5X and 6P also use unique keys that are accessible only with trusted hardware, such as the ARM TrustZone. Now with 7.0 Nougat, all new capable Android devices must also have this kind of hardware support for key storage and provide brute force protection while verifying your lock screen credential before these keys can be used. This way, all of your data can only be decrypted on that exact device and only by you.


The media stack and platform hardening

In Android Nougat, we’ve both hardened and re-architected mediaserver, one of the main system services that processes untrusted input. First, by incorporating integer overflow sanitization, part of Clang’s UndefinedBehaviorSanitizer, we prevent an entire class of vulnerabilities, which comprise the majority of reported libstagefright bugs. As soon as an integer overflow is detected, we shut down the process so an attack is stopped. Second, we’ve modularized the media stack to put different components into individual sandboxes and tightened the privileges of each sandbox to have the minimum privileges required to perform its job. With this containment technique, a compromise in many parts of the stack grants the attacker access to significantly fewer permissions and significantly reduced exposed kernel attack surface.

In addition to hardening the mediaserver, we’ve added a large list of protections for the platform, including:
App security improvements

Android Nougat is the safest and easiest version of Android for application developers to use.
  • Apps that want to share data with other apps now must explicitly opt-in by offering their files through a Content Provider, like FileProvider. The application private directory (usually /data/data/) is now set to Linux permission 0700 for apps targeting API Level 24+.
  • To make it easier for apps to control access to their secure network traffic, user-installed certificate authorities and those installed through Device Admin APIs are no longer trusted by default for apps targeting API Level 24+. Additionally, all new Android devices must ship with the same trusted CA store.
  • With Network Security Config, developers can more easily configure network security policy through a declarative configuration file. This includes blocking cleartext traffic, configuring the set of trusted CAs and certificates, and setting up a separate debug configuration.
We’ve also continued to refine app permissions and capabilities to protect you from potentially harmful apps.
  • To improve device privacy, we have further restricted and removed access to persistent device identifiers such as MAC addresses.
  • User interface overlays can no longer be displayed on top of permissions dialogs. This “clickjacking” technique was used by some apps to attempt to gain permissions improperly.
  • We’ve reduced the power of device admin applications so they can no longer change your lockscreen if you have a lockscreen set, and device admin will no longer be notified of impending disable via onDisableRequested(). These were tactics used by some ransomware to gain control of a device.
System Updates

Lastly, we've made significant enhancements to the OTA update system to keep your device up-to-date much more easily with the latest system software and security patches. We've made the install time for OTAs faster, and the OTA size smaller for security updates. You no longer have to wait for the optimizing apps step, which was one of the slowest parts of the update process, because the new JIT compiler has been optimized to make installs and updates lightning fast.

The update experience is even faster for new Android devices running Nougat with updated firmware. Like they do with Chromebooks, updates are applied in the background while the device continues to run normally. These updates are applied to a different system partition, and when you reboot, it will seamlessly switch to that new partition running the new system software version.

We’re constantly working to improve Android security and Android Nougat brings significant security improvements across all fronts. As always, we appreciate feedback on our work and welcome suggestions for how we can improve Android. Contact us at [email protected].


Share on Twitter Share on Facebook


The updated information provides more specific explanations of six different security issues detected by Safe Browsing, including malware, deceptive pages, harmful downloads, and uncommon downloads. These explanations give webmasters more context and detail about what Safe Browsing found. We also offer tailored recommendations for each type of issue, including sample URLs that webmasters can check to identify the source of the issue, as well as specific remediation actions webmasters can take to resolve the issue.

We on the Safe Browsing team definitely recommend registering your site in Search Console even if it is not currently experiencing a security issue. We send notifications through Search Console so webmasters can address any issues that appear as quickly as possible.

Our goal is to help webmasters provide a safe and secure browsing experience for their users. We welcome any questions or feedback about the new features on the Google Webmaster Help Forum, where Top Contributors and Google employees are available to help.

For more information about Safe Browsing’s ongoing work to shine light on the state of web security and encourage safer web security practices, check out our summary of trends and findings on the Safe Browsing Transparency Report. If you’re interested in the tools Google provides for webmasters and developers dealing with hacked sites, this video provides a great overview.
Share on Twitter Share on Facebook


Our goal is to have fuzz testing for every component of Chrome where fuzzing is applicable, and we hope all Chromium developers and external security researchers will contribute to this effort.

How to write a fuzz target

With libFuzzer, you need to write only one function, which we call a target function or a fuzz target. It accepts a data buffer and length as input and then feeds it into the code we want to test. And... that’s it!

The fuzz targets are not specific to libFuzzer. Currently, we also run them with AFL, and we expect to use other fuzzing engines in the future.
Sample Fuzzer

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
  std::string buf;
  woff2::WOFF2StringOut out(&buf);
  out.SetMaxSize(30 * 1024 * 1024);
  woff2::ConvertWOFF2ToTTF(data, size, &out);
  return 0;
}
See also the build rule.
Sample Bug

==9896==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62e000022836 at pc 0x000000499c51 bp 0x7fffa0dc1450 sp 0x7fffa0dc0c00
WRITE of size 41994 at 0x62e000022836 thread T0
SCARINESS: 45 (multi-byte-write-heap-buffer-overflow)
   #0 0x499c50 in __asan_memcpy
   #1 0x4e6b50 in Read third_party/woff2/src/buffer.h:86:7
   #2 0x4e6b50 in ReconstructGlyf third_party/woff2/src/woff2_dec.cc:500
   #3 0x4e6b50 in ReconstructFont third_party/woff2/src/woff2_dec.cc:917
   #4 0x4e6b50 in woff2::ConvertWOFF2ToTTF(unsigned char const*, unsigned long, woff2::WOFF2Out*) third_party/woff2/src/woff2_dec.cc:1282
   #5 0x4dbfd6 in LLVMFuzzerTestOneInput testing/libfuzzer/fuzzers/convert_woff2ttf_fuzzer.cc:15:3

Check out our documentation for additional information.

Integrating LibFuzzer with ClusterFuzz

ClusterFuzz is Chromium’s infrastructure for large scale fuzzing. It automates crash detection, report deduplication, test minimization, and other tasks. Once you commit a fuzz target into the Chromium codebase (examples), ClusterFuzz will automatically pick it up and fuzz it with libFuzzer and AFL. 

ClusterFuzz supports most of the libFuzzer features like dictionaries, seed corpus and custom options for different fuzzers. Check out our Efficient Fuzzer Guide to learn how to use them.

Besides the initial seed corpus, we store, minimize, and synchronize the corpora for every fuzzer and across all bots. This allows us to continuously increase code coverage over time and find interesting bugs along the way.

ClusterFuzz uses the following memory debugging tools with libFuzzer-based fuzzers:

 Sample Fuzzer Statistics


It’s important to track and analyze performance of fuzzers. So, we have this dashboard to track fuzzer statistics, that is accessible to all chromium developers:


Overall statistics for the last 30 days:
  • 120 fuzzers
  • 112 bugs filed
  • Aaaaaand…. 14,366,371,459,772 unique test inputs!

 Analysis of the bugs found so far

Looking at the 324 bugs found so far, we can say that ASan and MSan have been very effective memory tools for finding security vulnerabilities. They give us comparable numbers of crashes, though ASan crashes usually are more severe than MSan ones. LSan (part of ASan) and UBSan have a great impact for Stability - another one of our 4 core principles.


Extending Chrome’s Vulnerability Reward Program

Under Chrome's Trusted Researcher Program, we invite submission of fuzzers. We run them for you on ClusterFuzz and automatically nominate bugs they find for reward payments.

Today we're pleased to announce that the invite-only Trusted Researcher Program is being replaced with the Chrome Fuzzer Program which encourages fuzzer submissions from all, and also covers libFuzzer-based fuzzers! Full guidelines are listed on Chrome’s Vulnerability Reward Program page.
Share on Twitter Share on Facebook