Greetings,

Amongst everything the first quarter of 2020 has thrown at the world, it has underlined the crucial role the web plays in our lives. As always, the Chrome Security teams have been focusing on the safety of our users, and on keeping Chrome secure and stable for all those who depend on it.

The Chrome Safe Browsing team, with the support of many teams, introduced a new Safe Browsing mode that users can opt-in to get “faster, proactive protection against dangerous websites, downloads, and extensions.”

We launched previously announced faster phishing protection to Chrome users on high-memory Android devices. This led to a 116% increase in the number of phishing warnings shown to users for main frame URLs.

We also launched predictive phishing protections to all users of Chrome Password Manager on Android, which warns users when they type their saved password on an unsafe website. The initial estimate from the launch on Beta population suggests an 11% increase in the number of warnings shown compared to that on Windows.

Chrome's Enamel team finalized plans to bring users a more secure HTTPS ecosystem by blocking mixed content, mixed downloads, and legacy TLS versions. These changes have now been delayed due to changing global circumstances, but are still planned for release at the appropriate time.

To improve how users understand website identity, we experimented with a new security indicator icon for insecure pages. We also experimentally launched a new warning for sites with spoofy-looking domain names. We’re now analyzing experiment results and planning next steps for these changes.

The Platform Security team made significant forward progress on enabling the network service to be sandboxed on all platforms (it already is on macOS). This required getting significant changes into Android R, migrating to a new way of using the Data Protection API on Windows (which had the side-effect of breaking some crime rings’ operations, albeit temporarily), and more. When complete, this will reduce the severity of bugs in that service from Critical to High.

We also made progress on Windows sandboxing, working towards adopting AppContainer, and are refactoring our Linux/Chrome OS sandbox to handle disruptive upstream changes in glibc and the kernel.

Discussions about the various ways we can improve memory safety continue, and we laid plans to migrate PDFium’s XFA support to Oilpan garbage collection, with the help of Oilpan and V8 teams. This will enable us to safely ship XFA in production, hopefully in 2020.

The bugs-- team launched FuzzBench, a fuzzer benchmarking platform to bridge the gap between academic fuzzing research and industry fuzzing engines (e.g libFuzzer, AFL, Honggfuzz). We have integrated new techniques in ClusterFuzz to improve fuzzing efficiency and break coverage walls - dataflow trace based fuzzing, in-process grammar mutators (radamsa, peach). Also, launched CIFuzz for OSS-Fuzz projects to catch obvious security regressions in a project’s continuous integration before they are checked in.

The Chrome Security Architecture (née Site Isolation) team has been strengthening Site Isolation this quarter. We're securing extension content script requests to unify CORS and CORB behavior, and we're progressing with a prototype to let websites opt in to origin-level isolation. To improve Chrome's security architecture, the team is working on a proposal for a new SecurityPrincipal abstraction. We have also cleaned up RenderWidget/RenderView lifetimes. Finally, we are starting to formalize our thinking about privilege levels and their interactions in Chrome. We are enumerating problem spots in IPC and other areas as we plan the next large projects for the team.

For the past five years, Chrome, along with counterparts at browser vendors such as Mozilla, Microsoft, Apple, Opera, and Vivaldi, have been discussing technical challenges involved in the eIDAS Regulation with members of the European Commission, ETSI, and European Union Agency for Cybersecurity (ENISA). These discussions saw more activity this past quarter, with browsers publicly sharing an alternative technical proposal to the current ETSI-defined approach, in order to help the Commission make the technology easier to use and interoperate with the web and browsers.

We announced Chrome’s 2020 Certificate Transparency plans with a focus on removing “One Google Log” policy dependency.  Pending updates to travel policy, we have tentatively planned CT Days 2020 and sent out an interest survey for participants.

Until next time, on behalf of Chrome Security I wish you all the very best.

Andrew

As we start 2020 and look forward to a new year and a new decade, the Chrome Security Team took a moment to look back at the final quarter of 2019. 

The Safe Browsing team launched two features that significantly improve phishing protections available to Chrome users:

We reduced the false negative rate for Safe Browsing lookups in Chrome by launching real-time Safe Browsing lookups for users who have opted in to “Make Searches and Browsing better.” Early results are promising, with up to 55% more warnings shown to users who had this protection turned on, compared to those who did not.

A while ago we launched predictive phishing protections to warn users who are syncing history in Chrome when they enter their Google Account password into suspected phishing sites that try to steal their credentials. With the Chrome 79, we expanded this protection to everyone signed in to Chrome, even if you have not enabled Sync. In addition, this feature will now work for all the passwords that the user has stored in Chrome’s password manager; this will show an estimated 10 times more warnings daily. 

We also had two telemetry based launches for sending pings to Safe Browsing when users who have opted into Safe Browsing Extended Reporting focus on password fields and reuse their passwords on Android.

HTTPS adoption has risen dramatically, but many https:// pages still include http:// subresources — known as mixed content. In October, the Usable Security team  published a plan to eradicate mixed content from the web. The first phases of this plan started shipping in Chrome 79. In Chrome 79, we relocated the setting that allows users to load mixed content when it’s blocked by default. This setting used to be a shield icon in the Omnibox, and is now available in Site Settings instead. In Chrome 80, mixed audio and video will be automatically upgraded to https://, and they will be blocked if they fail to load. We started work on a web standard to codify these changes. See this article for how to fix mixed content if you run an affected website.

Website owners should keep their HTTPS configurations up-to-date with the latest security settings. Back in 2018, we (alongside other browsers) announced plans to remove support for legacy TLS versions 1.0 and 1.1. In October, we updated these plans to announce the specific UI treatments that we’ll use for this deprecation. Starting in January 2020, Chrome 79 will label affected websites with a “Not Secure” chip in the omnibox. Chrome 81 will show a full-page error. Make sure your server supports TLS >=1.2 to avoid this warning treatment.

To continue to polish our security UI, we iterated on our warning for lookalike domains to make the warning more understandable. We introduced a new gray triangle icon for http:// sites to make a clearer distinction between http:// and https://. This icon will appear for some users as part of a small-scale experiment in Chrome 80. Finally, we cleaned up a large backlog of low severity security UI vulnerabilities. We fixed, closed, or removed visibility restrictions on 33 out of 42 bugs.

The Platform Security Team sandboxed the network service on macOS in Chrome 79, and continued the work on sandboxing it on other Desktop platforms. There is also some forward momentum for reducing its privilege in version R of Android.

You can now check the sandboxing state of processes on Windows by navigating to chrome://sandbox. Also on Windows, we experimented with enabling the renderer App Container but ran into crashes likely related to third party software, and are now working to improve error reporting to support future experimentation. Chrome 79 also saw Code Integrity Guard enabled on supported Windows versions, blocking unsigned code injection into the renderer process.

We have also begun investigating new systemic approaches to memory unsafety. Look for news in 2020, as well as continual improvements to the core libraries in Chromium and PDFium.

In Q4, the Bugs-- team moved closer to our goal of achieving 50% fuzzing coverage in Chrome (it's currently at 48%). We added new features to our ClusterFuzz platform, such as Honggfuzz support, libFuzzer support for Android, improved fuzzer weights and more accurate statistics gathering pipeline. We also enabled several new UBSan features across both Chrome and OSS-Fuzz. As part of OSS-Fuzz, we added Go language support and on-boarded several new Go projects. We also gave a talk about ClusterFuzz platform at Black Hat Europe. 

In conversation with our friends and colleagues at Mozilla over the course of Q4, the Open Web Platform Security team made substantial progress on Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy. These isolation primitives will make it possible for us to ensure that process isolation is robust, even as we ship new and exciting APIs that give developers more capability. Implementations of both are mostly complete behind a flag, and we're looking forward to getting them out the door, and beginning the process of relying upon them to when deciding whether to allow cross-thread access to shared memory.

Similarly, we're polishing our implementation of Trusted Types based on feedback from origin trials and other vendors' review of the spec. We're still excited about its potential for injection mitigation, and we're looking forward to closing out the last few issues we know about in our implementation.

The Site Isolation team posted to the Google Security Blog and the Chromium Blog about our recent milestones for Site Isolation on Android and defending against compromised renderer processes. We also gave a talk at Black Hat Europe about Site Isolation and how to look for new bypasses for the VRP. At the same time, we made progress on additional enforcement, and we ran experiments to expand Android coverage to more devices. Finally, we also used Q4 to clean up a lot of core Site Isolation code, and we started updating Chrome's WebUI framework to better support new types of Chrome features without large risks of privilege escalation.

In the world of Web PKI Security, as part of our ongoing collaboration with Microsoft and Mozilla on the Common CA Database, "Audit Letter Validation" is now enabled for the full set of publicly trusted Certificate Authorities. This tool, developed by Microsoft and Mozilla, automatically validates the contents of audit letters to ensure they include the information required of a publicly trusted CA. Audit letter validation was previously done by hand, which was not scalable to CA's 2,500+ intermediate certificates.

Audit Letter Validation enabled us and other root stores to detect a wide variety of issues in the Web PKI that had previously gone unnoticed. We’ve spent the past quarter leading the incident response effort, working with non-compliant CAs to remediate issues and mitigate future risk. This helps not only Chrome users, but all users who trust these CAs. We can now automatically detect issues as they happen, ensuring prompt remediation.

We also collaborate with Mozilla to provide detailed reviews of organizations applying to be CAs, completing several in Q4. These public reviews take an extremely detailed look at how the CA is operated, looking at both compliance and for risky behaviour not explicitly forbidden, as well as opportunities for improvement based on emerging good practices.

Certificate Transparency (CT) continues to be an integral part of our work. Beyond helping protect users by allowing quick detection of potentially malicious certificates, the large-scale analysis that CT enables has been essential in helping improve the Web PKI. Analysis of CT logs this quarter revealed a number of systemic flaws in how Extended Validation certificates are validated, which has spurred industry-wide effort to address these issues. 

We took steps to protect users from trusting harmful certificates that might be installed by software or which they might be directed to install. Working with the Enamel team, we built on steps we’d previously taken to protect users from certificates used to intercept their communications by adding the ability to rapidly deploy targeted protections via our CRLSet mechanism. CRLSets allow us to quickly respond, using the Component Updater, without requiring a full Chrome release or respin.

More generally, we continue to work on the “patch gap”, where security bug fixes are posted in our open-source code repository but then take some time before they are released as a Chrome stable update. We now make regular refresh releases every two weeks, containing the latest severe security fixes. This has brought down the median “patch gap” from 33 days in Chrome 76 to 15 days in Chrome 78, and we continue to work on improving it.

Finally, you can read what the Chrome (and other Google) Vulnerability Rewards Programs have been up to in 2019 in our recent blog post.

Cheers,

Andrew,  on behalf of the Chrome security team

Greetings,

With 2019 already more than 58% behind us, here's an update on what Chrome Security was up to in the second quarter of this year.

Chrome SafeBrowsing is launching stricter download protections for Advanced Protection users, and a teamfood has begun to test the policy in M75. This will launch broadly with M76. This significantly reduces an Advanced Protection user’s exposure to potentially risky downloads by showing them warnings when they try to download “risky” files (executable files that haven’t been vetted by SafeBrowsing) in Chrome.

Users need to understand site identity to make safe decisions on the web. Chrome Security UX published a USENIX Security paper exploring how users understand modern browser identity indicators. To help users understand site identity from confusing URLs, we launched a new warning detecting domains that look similar to domains you’ve visited in the past. We published a guide to how we triage spoofing bugs involving such domains. We also built a Suspicious Site Reporter extension that power users can use to report deceptive sites to Google’s Safe Browsing service, to help protect non-technical users who might not be able to discern a deceptive site’s identity as well.

Site identity is meaningless without HTTPS, and we continue to promote HTTPS adoption across the web. We implemented an experimental flag to block high-risk nonsecure downloads initiated from secure contexts. And we continued to roll out our experiment that auto-upgrades mixed content to HTTPS, pushing to 10% of beta channel and adding new metrics to quantify breakage.

In addition to helping with the usual unfaltering flow of security launch reviews, Platform Security engineers have been continuing to investigate ways to help Chrome engineers create fewer memory safety bugs for clusterfuzz to find. While performance is a concern when adding checks to libraries, some reports of regressions nicely turned out to be red herrings. On macOS, Chrome executables are now signed with the hardened runtime options enabled. Also on macOS, the change to have Mojo use Mach IPC, rather than POSIX file descriptors/socket pairs, is now fully rolled out. On Windows, we started to enable Arbitrary Code Guard on processes that don't need dynamic code at runtime.

We've done a lot of analysis on the types of security bugs which are still common in Chromium. The conclusion is that memory safety is still our biggest problem, so we've been working to figure out the best next steps to solve that—both in terms of safer C++, and investigating other choices to find if we can parse data in a safe language without disrupting the Chromium development environment too much.

We've also been looking at how security fixes are released, to ensure fixes get to our users in the quickest possible way. We have also improved some of the automatic triage that Clusterfuzz does to make sure that bugs get the right priority.

To augment our fuzzing efforts and find vulnerabilities for known bad patterns, we have decided to invest in static code analysis efforts with Semmle. We have written our custom QL queries and reported 15 bugs so far (some of these were developed in collaboration with Project Zero).

We have made several changes to improve fuzzing efficiency which include - leveraging DFSan for focused mutations, added support for custom mutators, build-type optimizations (sanitizers without instrumentation) and libFuzzer fork mode on Windows. We have upstreamed a helper module in libFuzzer to make it easy to split fuzz input and decrease fuzz target complexity.

The Open Web Platform Security team was mainly focused on Trusted Types, and conducted an Origin Trial for the feature in Q2. The team is presently scrambling to address the issues raised by public feedback, to modify the feature to make it easier to deploy, and to generally make Trusted Types fit for a full launch.

The Site Isolation team published their Usenix Security 2019 paper about the desktop launch (Site Isolation: Process Separation for Web Sites within the Browser), which will be presented in August. We now have a small Stable channel trial of Android Site Isolation, which isolates the sites that users log into rather than all sites. That work included persisting and clearing the sites to isolate, fixing text autosizing, and adding more metrics. Separately, we ran a trial of isolating origins rather than sites to gauge overhead, and we helped ship Sec-Fetch-Site headers. We also started collecting data on how well CORB is protecting sensitive resources in practice, and we've started launch trials of out-of-process iframe based PDFs (which adds CORB protection for PDFs).

The Chrome OS Security team has been working on the technology underlying Chrome OS verified boot. Going forward, dm_verity will use SHA256 as its hashing algorithm, replacing SHA1. So long, weak hashing algorithm!

We also spent some time making life easier for Chrome OS developers. Devs now have access to a time-of-check-time-of-use safe file library, and a simplified mechanism for building system call filtering policies.

Cheers,

Andrew, on behalf of the Chrome security team

Greetings,

Here's an update on what Chrome Security was up to in the first quarter of 2019!

The Site Isolation team finished the groundwork for Android Beta Channel field trials, and the trials are now in progress. This Android mode isolates a subset of sites that users log into, to protect site data with less overhead than isolating all sites. We also started enforcing Cross-Origin Read Blocking for extension content script requests, maintaining a temporary allowlist for affected extensions that need to migrate. We tightened compromised renderer checks for navigations, postMessage, and BroadcastChannel. We also continued cross-browser discussions about Long-Term Web Browser Mitigations for Spectre, as well as headers for isolating pages and enabling precise timers. Finally, we are close to migrating PDFs from BrowserPlugin to out-of-process iframes, allowing BrowserPlugin to be deleted.

In the last several years, the Usable Security team have put a lot of effort into improving HTTPS adoption across the web, focusing on getting top sites to migrate to HTTPS for their top-level resources. We’re now starting to turn our attention to insecure subresources, which can harm user security and privacy even if the top-level page load is secure. We are currently running an experiment on Canary, Dev, and Beta that automatically upgrades insecure subresources on secure pages to HTTPS. We also collected metrics on insecure downloads in Q1 and have started putting together a proposal to block high-risk insecure downloads initiated from secure pages.

People need to understand website identity to make good security and trust decisions, but lots of research suggests that they don’t. We summarized our own research and thinking on this topic in an Enigma 2019 talk. We open-sourced a tool that we use to help browser developers display site identity correctly. We also published a set of URL display guidelines and subsequently incorporated them into the URL standard.

The Safe Browsing team increased the coverage against malware and unwanted software downloads by changing the logic of which file types to check against Safe Browsing. We flipped the heuristic to an allow-list of known-safe file extensions, and made the rest require verification. This adds protection from both the uncommon file extensions (where attackers convince users to rename them to a common executable after scanning), and from Office document types where the incidence of malware has increased significantly.

The Chrome Cleanup Tool is now in the Chromium repository! This lets the public audit the data collected by the tool, which is a win for user privacy, and gives an example of how to sandbox a file scanner. The open source version includes a sample scanner that detects only test files, while the version shipped in Chrome will continue to depend on internal resources for a licensed engine.

The Bugs-- team has open sourced ClusterFuzz, a fuzzing infrastructure that we have been developing over the past 8 years! This army of robots has found 30,000+ bugs in Chrome and 200+ open source projects. To improve the efficiency of our cores, we have developed automated fuzzer weights management based on fuzzer quality/freshness/code changes. Additionally, we have developed several new WebGL fuzzers (some of them leverage GraphicsFuzz) and found 63 bugs. We have significantly scaled up fuzzing Chrome on Android (x86) by using Cuttlefish over GCE. Lastly, we have transitioned Chrome code coverage tools development to Chrome Infra team, see the new dash here.

The Platform Security team added some checks for basic safety to our base and other fundamental libraries, and are investigating how to do more while maintaining efficiency (run-time, run space, and object code size). We hope to continue to do more, as well as investigate how to use absl without forgoing the safety checks. We’ve been having great success with this kind of thing in PDFium as well, where we’ve found that the compiler can often optimize away these checks, and investigating where it hasn’t been able to has highlighted several pre-existing bugs. On macOS, we have re-implemented the Mojo IPC Channel under the hood to use Mach IPC, which should help reduce system resource shortage crashes. This also led to the development of two libprotobuf-mutator (LPM) fuzzers for Mach IPC servers. We’re working on auto-generating an LPM based fuzzer from Mojo API descriptions to automatically fuzz Mojo endpoints, in-process. We also continue to write LPM fuzzers for tricky-to-reach areas of the code like the disk cache. We are also investigating reducing the privilege of the network process on Windows and macOS.

Our next update will be the first full quarter after joining Chrome Trust and Safety. We're looking forward to collaborating with more teams who are also working to keep our users safe!

Cheers,

Andrew on behalf of Chrome Security

Greetings,

With the new year well underway, here's a look back at what Chrome Security was up to in the last quarter of 2018.

In our quest to make HTTPS the default, we started marking HTTP sites with a red Not Secure icon when users enter data into forms. This change launched to stable in Chrome 70 in October. A new version of the HTTPS error page also launched to the stable channel as an experiment: it looks the same but is much improved under the hood. We built a new version of the HTTPS Transparency Report for top sites; the report now displays aggregate statistics for the top sites instead of individual sites. We also built a new interstitial warning to notify Chrome users of unclear mobile subscription billing pages. The new warning and policy launched in Chrome 71.

The Bugs-- team ported libFuzzer to work on Windows, which was previously lacking coverage guided fuzzing support, and this resulted in 93 new bugs. We hosted a month-long Fuzzathon in November, focused on improving fuzz coverage for Chrome’s browser process and Chrome OS. This effort led to 85 submissions and 157 bugs. We have added more automation towards auto-adjusting cpu cycles allocated to various fuzzers based on code coverage changes and recency of fuzzer submission. Lastly, we added Linux x86 fuzzing configurations (1, 2) for libFuzzer, which resulted in 100 new bugs.

In Platform Security, we started sandboxing the network service on macOS. On Windows, we’re starting to experiment with an improved GPU sandbox. The network service has the beginnings of a sandbox on Windows, and we’ll be working on tightening it in future work. We’re also continuing to gradually harden the implementations of core Chromium libraries in base/ and elsewhere. We had a great adventure finding and fixing bugs in SQLite as well, including an innovative and productive new fuzzer. We’re continuing to hammer away at bugs in PDFium, and refactoring it significantly.

To help sites defend against cross-site scripting (XSS), we are working on Trusted Types. This aims to bring a derivative of Google's "Safe HTML Types" — which relies on external tooling that may be incompatible with existing workflows or code base — directly into the web platform, thus making it available to everyone. Both Google-internal and external teams are presently working on integrating Trusted Types into existing frameworks which, if successful, offers the chance to rapidly bring this technique to large parts of the web. Chrome 73 will see an origin trial.

The work on Site Isolation continues as we focus on enabling it on Android — support for adding isolated origins at runtime, fixing issues with touch events, and balancing process usage for maximizing stability. We added improvements to CORB to prevent bypasses from exploited renderers, we announced extensions changes for content script requests, and we reached out to affected authors with guidance on how to update. Additionally, we continue to add more enforcements to mitigate compromised renderers, which is the ultimate end goal of the project. Last but not least, we have worked to improve code quality and clean up architectural deficiencies which accumulated while developing the project.

Chrome OS 71 saw the initial, limited release of USBGuard, a technology that improves the security of the Chrome OS lock screen by (carefully) blocking USB devices on the lock screen.

As ever, many thanks to all those in the Chromium community, and our VRP reporters, who help make the Web more secure!

Cheers,

Andrew, on behalf of the Chrome security team

Greetings and salutations,

It's time for another (rather belated!) update from your friends in Chrome Security, who are hard at work to keep Chrome the most secure platform to browse the Internet.

We're very excited that Site Isolation is now enabled by default as a Spectre mitigation in M67 for Windows, macOS, Linux, and Chrome OS users! This involved an incredible number of fixes from the team in Q2 to make out-of-process iframes fully functional, especially in areas like painting, input events and performance, and it included standardizing Cross-Origin Read Blocking (CORB). Stay tuned for more updates on Site Isolation coming later this year, including additional protections from compromised renderers. Chris and Emily talked about Spectre response, Site Isolation, and necessary developer steps at I/O. We also announced that security bugs found in Site Isolation could qualify for higher VRP reward payments for a limited time.

In their quest to find security bugs, the Bugs-- team integrated Clang Source-based Code Coverage into Chromium project and launched a dashboard to make it easy for developers to see which parts of the code are not covered by fuzzers and unit tests. We wrote a Mojo service fuzzer that generates fuzzing bindings in JS and found some scary vulnerabilities. We added libFuzzer fuzzing support in Chrome OS and got new fuzz target contributions from Chrome OS developers and found several bugs. We made numerous improvements to our ClusterFuzz fuzzing infrastructure, examples include dynamically adjusting CPU allocation for inefficient fuzz targets until their performance issues are resolved, cross-pollinating corpuses across fuzz targets and projects, and more.

The Platform Security team has been working on adding bounds checks and other sanity checks to base/containers, as part of an overarching effort to harden heavily-used code and catch bugs. We’ve had some good initial success and expect to keep working on this for the rest of the year. This is a good area for open source contributors and VRP hunters to work on, too!

In our quest to move the web to 100% HTTPS, we prepared for showing Not Secure warnings on all http:// pages which started in M68. We sent Search Console messages to affected sites and expanded our enterprise controls for this warning. We announced some further changes to Chrome’s connection security indicators: in M69, we’ll be removing the Secure chip next to https:// sites, and in M70 we’ll be turning the Not Secure warning red to more aggressively warn users when they enter data on a non-secure page.

We also added some features to help users and developers use HTTPS more often. The omnibox now remembers pages that redirect from http:// to https://, so that users don’t get sent to the http:// version in the future. We fixed a longstanding bug with the upgrade-insecure-requests CSP directive that helps developers find and fix mixed content: it now upgrades requests when following redirects. Finally, we added a setting to chrome://flags#unsafely-treat-insecure-origin-as-secure to let developers more easily test HTTPS-only features, especially on Android and ChromeOS.

To better protect users from unwanted extensions, we announced the deprecation of inline installations for extensions. This change will result in Chrome users being directed to the Chrome Web Store when installing extensions, helping to ensure user can make a better informed decision.

Chrome OS spent a big chunk of Q2 updating and documenting our processes to ensure we can better handle future incidents like Spectre and Meltdown. We expanded our security review guidelines so that they can be used both by security engineers while reviewing a feature, as well as by SWE and PM feature owners as they navigate the Chrome OS launch process.

We continued our system hardening efforts by making Shill, the Chrome OS network connection manager, run in a restrictive, non-root environment starting with M69. Shill was exploited as part of a Chrome OS full-chain exploit, so sandboxing it was something that we’ve been wanting to do for a long time. With PIN sign-in launching with M68, the remaining work to make the underlying user credential brute force protection mechanism more robust is underway, and we plan to enable it for password authentication later this year. Hardening work also happened on the Android side, as we made progress on functionality that will allow us to verify generated code on Android using the TPM.

Q2 continued to require incident response work on the Chrome OS front, as the fallout from Spectre and Meltdown included several researchers looking into the consequences of speculative execution. The good news is that we started receiving updated microcode for Intel devices and these updates will start to go out with M69.

As ever, many thanks to all those in the Chromium community, and our VRP reporters, who help make the Web more secure!

Cheers

Andrew

on behalf of the Chrome Security Team

Greetings and salutations,

It's time for another update from your friends in Chrome Security, who are hard at work trying to make Chrome the most secure platform to browse the Internet. As it's the start of 2018, we reflected on a year’s worth of security improvements, and announced new stats around our VRP and Safe Browsing warnings.

Here are some highlights from the last quarter of 2017:

In effort to find and fix bugs, we (Bugs--):

• Wrote a new and easily extensible javascript fuzzer using Babel, which found 100+ bugs in both V8 (list) and other browser javascript engines (list).

• Started integrating Clang Source-based Code Coverage in the Chromium build system and are deprecating Sanitizer Coverage. Clang coverage is very precise, shows hit frequencies and is much easier to visualize. You can follow progress here.

• Hosted a month long fuzzathon in October where Chromium developers participated in writing new fuzz targets and fixing blockers for existing ones. This resulted in 93 bugs, several of which were in new uncovered areas of codebase; results here.

• Fixed several bugs in our automated owner and component assignment pipeline and expanded our buildbot infrastructure to archive builds more frequently, for more accurate blame results. Faster and more accurate bug triaging means faster fixes for users!

Other than fixing bugs, we (MOAR TLS, Enamel, Safe Browsing) also:

• Blogged about the massive uptick in HTTPS we saw in 2017: 71 of the top 100 sites on the Web use HTTPS by default, up from 37 a year ago. We also announced our continuing platinum sponsorship of Let’s Encrypt.

• Delivered a change (in M62, announced in April), extending the “Not Secure” omnibox warning chip to non-secure pages loaded while Incognito and to non-secure pages after the user edits a form field.

• Added an enterprise policy (in M65) for treating insecure origins as secure contexts, to help with development, testing, and intranet sites that are not secured with HTTPS.

• More tightly integrated Chrome’s captive portal detection with operating system APIs. This feature helps users log in to captive portals (like hotel or airport wifi networks) rather than seeing unhelpful TLS certificate errors.

• Launched predictive phishing protection to warn users when they’ve typed their Google password into a never-seen-before phishing site.

As always, we invest a lot in security architecture and exploit mitigations. Last quarter, we (Platform Security / Site Isolation):

• Started rolling out the Mac Sandbox v2, bringing both greater security and cleaner code.

• Refactored sandbox code out of //content to make it easier to use across the system.

• Worked on and helped coordinate Chrome's response to the recently announced Spectre and Meltdown CPU vulnerabilities and worked with the V8 team who spearheaded Chrome's Javascript and WebAssembly mitigations which are rolling out to users now.

• Accelerated the rollout of Site Isolation as a mitigation for Spectre/Meltdown. Enabling Site Isolation reduces the amount of valuable cross-site data that can be stolen by such attacks. We're working to fix the currently known issues so that we can start enabling it by default.

• Implemented cross-site document blocking in (M63) when Site Isolation is enabled.  This ensures that cross-site HTML, XML, JSON, and plain text files are not given to a renderer process on subresource requests unless allowed by CORS. Both --site-per-process and --isolate-origins modes are now available via enterprise policy in Chrome 63.

• Ran field trials of --site-per-process and --isolate-origins on 50% of Chrome Canary instances to measure performance, fix crashes, and spot potential issues. In a separate launch involving out-of-process iframes and Site Isolation logic, https://accounts.google.com now has a dedicated renderer process in Chrome 63 to support upcoming requirements for Chrome Signin.

• We have landed a large number of functional and performance improvements for Site Isolation, including fixes for input events, DevTools, OAuth, hosted apps, crashes, and same-site process consolidation which reduces memory overhead.

To help users that inadvertently installs unwanted software, we (Chrome Protector):

• Launched new Chrome Cleanup Tool UI , which we think is more comprehensible for users.

• Launched a sandboxed ESET-Powered Chrome Cleanup Tool

• Running on 100% of Chrome users by Nov 23

Lastly, we (BoringSSL) deployed TLS 1.3 to Chrome stable for a couple weeks in December and gathered valuable data.

As ever, many thanks to all those in the Chromium community who help make the Web more secure!

Cheers

Andrew

on behalf of the Chrome Security Team