Q2 Summary from Chrome Security

[Andrew R. Whalley]

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. Here’s a recap from last quarter:

The Bugs-- team have released a new tool to make ClusterFuzz testcase reproduction easy for developers. Our open source fuzzing efforts (aka OSS-Fuzz) continue to improve the security of the overall web (86 projects, 1859 bugs, see recent blog post here). We have written a new Javascript fuzzer that has filed 102 bugs to date, many with security implications. We also found some interesting vulnerabilities (1, 2, 3) through our code auditing efforts.

We integrated the Safe Browsing API with WebView starting in Android O, allowing custom interstitial blocking pages. WebView developers will be able to opt-in to check URLs against Google Safe Browsing’s list of unsafe websites.

We understand that sites which repeatedly prompt for powerful permissions often annoy users and generate warning fatigue. Starting in Chrome 59, we’ve started temporarily blocking permission requests if users have dismissed a permission prompt from a site multiple times. We’re also moving forward with plans to deprecate permissions in cross-origin iframes by default. Permission requests from iframes have the potential to mislead users into granting access to content they didn’t intend.

The Platform Security team has concluded several years of A/B experimentation on Android, and with Chrome 58 we have turned on the Seccomp-BPF sandbox for all compatible devices. This sandbox filters system calls to reduce the attack surface of the Linux kernel in renderer processes. Currently about 50% of Android devices support Seccomp, and this number is rising at a steady rate. In Chrome 59, you can navigate to about:sandbox to see whether your Android device supports Seccomp.

We have migrated PDFium to use PartitionAlloc for most allocations, with distinct partitions for strings, array buffers, and general allocations. In Chrome 61, all three partitions will be active.

We continue to work on MOAR+BETTER TLS and announced the next phase of our plan to help people understand the security limitations of non-secure HTTP. Starting in Chrome 62 (October), we’ll mark HTTP pages as “Not secure” when users enter data in forms, and on all HTTP pages in Incognito mode. We presented new HTTPS migration case studies at Google I/O, focusing on real-world site metrics like SEO, ad revenue, and site performance.

We experimented with improvements to Chrome’s captive portal detection on Canary and launched them to stable in Chrome 59, to avoid a predicted 1% of all certificate errors that users see.

Also, users may restore the Certificate information to the Page Information bubble!

Those working on the Open Web Platform have implemented three new Referrer Policies, giving developers more control over their HTTP Referer headers and bringing our implementation in line with the spec. We also fixed a longstanding bug so that site owners can now use upgrade-insecure-requests in conjunction with CSP reporting, allowing site owners to both upgrade and remediate HTTP references on their HTTPS sites.

After our launch of --isolate-extensions in Chrome 56, the Site Isolation team has been preparing for additional uses of out-of-process iframes (OOPIFs). We implemented a new --isolate-origins=https://example.com command line flag that can give dedicated processes to a subset of origins, which is an important step towards general Site Isolation. We also prepared the OOPIF-based <webview> field trial for Beta and Stable channels, and we ran a Canary field trial of Top Document Isolation to learn about the performance impact of putting all cross-site iframes into one subframe process. We've been improving general support for OOPIFs as well, including spellcheck, screen orientation, touch selection, and printing. The DevTools team has also helped out: OOPIFs can now be shown in the main frame's inspector window, and DevTools extensions are now more fully isolated from DevTools processes.

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

For more thrilling security updates and feisty rants, subscribe to securi...@chromium.org. You can find older updates at https://dev.chromium.org/Home/chromium-security/quarterly-updates.

[obr...@gmail.com]

About marking HTTP pages as “Not secure” when users enter data in forms, I would like to comment as I've been informed by Google Search Console of this new feature.

My web page ( http://hpwizard.com/car-performance.html ) is actually a stand-alone application. There are no forms and the input fields are only for the javascript app that runs only on the client side.

The «Not secure» gives a false information to the user as there are not even exchanges between the server and client. Even the fact that the connection is not secure is irrelevant on this point of view, since the information never leaves the client's computer.

So, either identify all HTTP pages as not secure (I liked the little red lock and the like), such that the user link the message to the HTTP protocol, or reconsider how you pick & choose the ones with input fields. I don't appreciate a «Not secure» that appears out of nowhere, that an unaware user could link to a more serious issue with the website instead of a trivial feature of the web page.

I don't know if this is the right place to comment, if not I hope the message will find its way to whom it concerns.

[Chris Palmer]

[other lists to BCC — in general it's not helpful to cross-post so widely]

On Thu, Aug 17, 2017 at 5:08 PM, <obr...@gmail.com> wrote:

My web page ( http://hpwizard.com/car-performance.html ) is actually a stand-alone application. There are no forms and the input fields are only for the javascript app that runs only on the client side.

As you have written it, sure. But, without HTTPS, there is no guarantee that the page you wrote is really the page people get. And indeed, it is common for pages delivered by non-secure protocols to be tampered with in transit. (It's some people's business model: https://www.google.com/search?q=injecting+advertising+http&rlz=1CAZZAD_enUS732US732&oq=injecting+advertising+http&aqs=chrome..69i57.3357j0j7&sourceid=chrome&ie=UTF-8)

More generally, there is no programmatic way for the browser to determine, before POSTing the form, that the form will never POST (or otherwise contact a server). The browser doesn't have strong AI or a solution to the halting problem; it has only heuristics ("is there an <input> element? is the URL HTTPS?"). So, yes, there will be what look like false positives. But since there is no security guarantee of any kind for HTTP, even what seem like false positives are not really.

I suggest setting your site up with HTTPS, with a free and automatically-issued certificate from Let's Encrypt. They have a handy online configuration guide: https://certbot.eff.org/

So, either identify all HTTP pages as not secure (I liked the little red lock and the like), such that the user link the message to the HTTP protocol, or reconsider how you pick & choose the ones with input fields.  I don't appreciate a «Not secure» that appears out of nowhere, that an unaware user could link to a more serious issue with the website instead of a trivial feature of the web page.

Identifying all non-secure pages as such is indeed on our roadmap. This behavior with <input> elements and forms is just 1 gradual step toward that future.

See https://blog.chromium.org/2017/04/next-steps-toward-more-connection.html for more information.