Learning Statistics with Privacy, aided by the Flip of a Coin

Thursday, October 30, 2014

[Cross-posted on the Google Research Blog and the Google Online Security Blog]

At Google, we are constantly trying to improve the techniques we use to protect our users' security and privacy. One such project, RAPPOR (Randomized Aggregatable Privacy-Preserving Ordinal Response), provides a new state-of-the-art, privacy-preserving way to learn software statistics that we can use to better safeguard our users’ security, find bugs, and improve the overall user experience.

Building on the concept of randomized response, RAPPOR enables learning statistics about the behavior of users’ software while guaranteeing client privacy. The guarantees of differential privacy, which are widely accepted as being the strongest form of privacy, have almost never been used in practice despite intense research in academia.  RAPPOR introduces a practical method to achieve those guarantees.

To understand RAPPOR, consider the following example. Let’s say you wanted to count how many of your online friends were dogs, while respecting the maxim that, on the Internet, nobody should know you’re a dog. To do this, you could ask each friend to answer the question “Are you a dog?” in the following way. Each friend should flip a coin in secret, and answer the question truthfully if the coin came up heads; but, if the coin came up tails, that friend should always say “Yes” regardless. Then you could get a good estimate of the true count from the greater-than-half fraction of your friends that answered “Yes”. However, you still wouldn’t know which of your friends was a dog: each answer “Yes” would most likely be due to that friend’s coin flip coming up tails.

RAPPOR builds on the above concept, allowing software to send reports that are effectively indistinguishable from the results of random coin flips and are free of any unique identifiers. However, by aggregating the reports we can learn the common statistics that are shared by many users. We’re currently testing the use of RAPPOR in Chrome, to learn statistics about how unwanted software is hijacking users’ settings.

We believe that RAPPOR has the potential to be applied for a number of different purposes, so we're making it freely available for all to use. We'll continue development of RAPPOR as a standalone open-source project so that anybody can inspect and test its reporting and analysis mechanisms, and help develop the technology. We’ve written up the technical details of RAPPOR in a report that will be published next week at the ACM Conference on Computer and Communications Security.

We’re encouraged by the feedback we’ve received so far from academics and other stakeholders, and we’re looking forward to additional comments from the community. We hope that everybody interested in preserving user privacy will review the technology and share their feedback at rappor-discuss@googlegroups.com.

Posted by Ăšlfar Erlingsson, Tech Lead Manager, Security Research

Noto on ChromeOS: No More “Tofu”

Tuesday, October 14, 2014

Every so often when reading a page written in a different language—especially Chinese, Korean, or Japanese (CJK) pages—you might see little boxes where letters should be, something that we call “tofu”. What's happened is that some of the characters are not supported by your computer. In July Google released Noto Sans CJK, the newest font in a family designed to cover 200+ languages in a harmonious way. As of Chrome OS 38, Noto is now the default sans serif and UI font for CJK languages.

Noto supports major living languages such as English, Russian, Greek, Arabic, and Hebrew, as well as widely supported languages such as Cherokee and Sinhala, and even ancient languages like Egyptian hieroglyphics and Imperial Aramaic. The ultimate goal is for Noto to support every character for every language in the world—which will make tofu a thing of the past.

Noto has many advanced features:
  • Pan-CJK: Simplified and Traditional Chinese, Japanese, and Korean, all in a single font.
  • Seven weights: Thin, Light, DemiLight, Regular, Medium, Bold, Black. ChromeOS has default support for Regular and Bold, with more coming soon.
  • Free and open source: Freely available for everyone under the Apache License, v2.0.
  • Comprehensive character coverage: Covers all the CJK Ideographs in the Unicode Basic Multilingual Plane and a few hundred Ideographs in Unicode Plane 2. Also covered are over twelve thousand Korean Hangul characters with full support for Old Hangul. The total number of glyphs in each font instance is exactly 65,536, the maximum number of glyphs allowed by the OpenType font specification. 
  • Region-appropriate glyph forms: CJK-shared ideographic characters follow region writing conventions to look appropriate to Chinese, Japanese, and Korean users. 
  • Harmony: Noto Sans CJK and all other members of the Noto family are visually compatible with Noto Sans for English, so that text mixing English with another language looks harmonious.

In ChromeOS, Noto is now the default “sans serif” font. Developers that want to use Noto on platforms other than ChromeOS can load them as web fonts from Google Fonts: Early Access.

Although Noto's Latin, Greek, and Cryllic (LGC) characters are designed to harmonize with the CJK characters, developers might still want to use more familiar fonts for the LGC text. To support that, Noto is available in different subsets including Japanese, Korean, Simplified Chinese, Traditional Chinese, and all of CJK. Developers can then use CSS's font fallback mechanism to specify a LGC font ahead of a Noto Sans subset.

For example, if you're targeting devices that don't have Noto installed, want to use Arial for LGC characters, and want to use Noto for Japanese characters, you can include the following in your stylesheet:
@import url(http://fonts.googleapis.com/earlyaccess/notosansjapanese.css); 
 body {
font-family: Arial, 'Noto Sans Japanese', sans-serif;
Shipping Noto by default on ChromeOS is one step towards making “tofu” a thing of the past. You can learn more at the Noto homepage.

Jungshik Shin, Font Harmony Master

Chrome 39 Beta: JS Generators, Animation Playback Control, and the WebApp Manifest

Thursday, October 09, 2014

Today’s Chrome Beta channel release includes new tools to make web application development simpler and more powerful. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

JavaScript Generators

Writing asynchronous code in JavaScript can be less than straightforward. It often involves several nested functions and non-linear program execution, making it hard to develop, maintain and debug. This is such a common pain point for developers that they've given it a name: callback soup.

Starting today, Chrome Beta supports ES6 Generators. They allow developers to create iterators that pause their execution after yielding a value, and resume again when later invoked. This greatly simplifies the process of developing asynchronous code and reduces dependence on callback functions.

For additional information about Generators, read more about them or see them in action.

Web Animation Playback Control

Web Animations is a powerful new API that unifies all of the animation APIs on the web. We shipped basic support in May with Chrome 36. In this release we've added playback control, with methods such as play(), pause(),  and reverse(), and the ability to jump to a specific point in an animation's timeline. With our initial support, developers could create animations but not precisely control their playback. This next iteration enables animations that can react in real time to user input - as well as a variety of other creative uses.

Web Application Manifest

Previously when developers wanted to allow their web applications to be added to the home screen from Chrome for Android, they had to use a variety of <meta> and <link> tags to trigger this behavior and deliver relevant resources such as icons. Having this embedded in every page was not only repetitive, but was a waste of bandwidth and put extra bits on the critical path.

Starting in Chrome 39, Manifests provide a way to wrap metadata about a web application into a single file, reducing duplication. Developers seeking to enable "add to homescreen" can define a title, landing page, default orientation, and different icons depending on size and screen density. You can see how it works today, but stay tuned for more properties to be added in later releases.

Other updates in this release

  • The Beacon API enables developers to queue asynchronous network requests that will be sent, regardless of whether the user navigates to a new page
  • Scroll offsets (scrollTop, scrollLeft) now return high-precision fractional values in preparation for high-DPI support
  • XMLHttpRequest progress event properties position and totalSize are now deprecated in favor of the loaded and total properties
As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

Posted by Mounir Lamouri, the Manifestation of a Software Engineer

Fewer bugs, mo’ money

Tuesday, September 30, 2014

[Cross-posted on the Google Online Security Blog]

We work hard to keep you safe online. In Chrome, for instance, we warn users against malware and phishing and offer rewards for finding security bugs. Due in part to our collaboration with the research community, we’ve squashed more than 700 Chrome security bugs and have rewarded more than $1.25 million through our bug reward program. But as Chrome has become more secure, it’s gotten even harder to find and exploit security bugs.

This is a good problem to have! In recognition of the extra effort it takes to uncover vulnerabilities in Chrome, we’re increasing our reward levels. We’re also making some changes to be more transparent with researchers reporting a bug.

First, we’re increasing our usual reward pricing range to $500-$15,000 per bug, up from a previous published maximum of $5,000. This is accompanied with a clear breakdown of likely reward amounts by bug type. As always, we reserve the right to reward above these levels for particularly great reports. (For example, last month we awarded $30,000 for a very impressive report.)

Second, we’ll pay at the higher end of the range when researchers can provide an exploit to demonstrate a specific attack path against our users. Researchers now have an option to submit the vulnerability first and follow up with an exploit later. We believe that this a win-win situation for security and researchers: we get to patch bugs earlier and our contributors get to lay claim to the bugs sooner, lowering the chances of submitting a duplicate report.

Third, Chrome reward recipients will be listed in the Google Hall of Fame, so you’ve got something to print out and hang on the fridge.

As a special treat, we’re going to back-pay valid submissions from July 1, 2014 at the increased reward levels we’re announcing today. Good times.

We’ve also answered some new FAQs on our rules page, including questions about our new Trusted Researcher program and a bit about our philosophy and alternative markets for zero-day bugs.

Happy bug hunting!

Posted by Tim Willis, Hacker Philanthropist, Chrome Security Team

Chrome Apps for Mobile: Now with a faster dev workflow and a modern WebView

Monday, September 22, 2014

In January, we told you about Chrome Apps for Mobile, a project based on Apache Cordova to run your Chrome Apps on both Android and iOS. The project provides a native application wrapper around your Chrome App, allowing you to distribute it via the Google Play Store and the Apple App Store. Cordova plugins give your App access to a wide range of APIs, including many of the core Chrome APIs. The newest version of Chrome Apps for Mobile includes Chrome APIs for identity, Google Cloud Messaging (GCM) and rich notifications, as well as an improved developer workflow and modern WebView capabilities extended to older versions of Android.

The developer workflow for Chrome Apps for Mobile is now significantly faster and simpler with the new live deploy feature. With live deploy, you can instantly preview the Chrome App you’re editing, running right on your Android or iOS device. When you make a change to the code, you will be able to see it straight away. Live deploy is available in both Chrome Dev Editor (CDE) and the Chrome Apps for Mobile command line tool.

Chrome Apps are at their best when they leverage the powerful functionality and performance of the latest Chromium WebView. The introduction of an updated WebView into Android KitKat paved the way for advanced features such as WebRTC, WebAudio and Accelerated 2D Canvas, and we will continue to see improvements with each new Android release. However, now you have a way to leverage the latest Chromium WebView on any device running Android versions back to Ice Cream Sandwich by bundling your Chrome App with an embeddable Chromium WebView, provided by the Crosswalk open source project.

To show Crosswalk in action, we have taken the Topeka Polymer Web App released at I/O and packaged it as a Chrome App for Mobile, available for you to try out on Android.

The Topeka Android app uses an embedded Crosswalk WebView to achieve smooth performance even on older versions of Android, enabling a full fidelity material design UI with fluid animations and no polyfills. Crosswalk is now readily available through the Chrome Apps for Mobile tooling and should be used with an understanding of its advantages and tradeoffs.

Using Chrome Apps, you can now build performant and capable applications that target desktop, Android, and iOS devices. To get started, take a look at our documentation. As always, we welcome your feedback on Stack Overflow and our G+ Developers page.

Posted by Michal Mocny, Chrome Apps for Mobile Engineer and Mobile Magic Maker

Responsive Web Design with DevTools' Device Mode

Monday, September 08, 2014

We all develop websites on our desktop and laptop machines, so we tend to initially develop for the desktop experience. But that's increasingly out of sync with our users who, more and more, consume the web on mobile. To deliver a great experience for the web, we need to accurately experience it on mobile. Chrome DevTools has had mobile emulation features for awhile, but it's still too disconnected from real device conditions and requires too much trial and error. Chrome 38 Beta includes a new Device Mode that puts you one click away from emulating mobile devices, inspecting media queries, and emulating flaky network conditions.

Now, you can turn on Device Mode right next to the "inspect element" icon. Once enabled, it automatically emulates a mobile viewport, along with complete emulation of touch events. You can test various viewport sizes easily with the large drag handles instead of resizing the whole browser window. You can select from popular device presets to automatically set viewport, touch, user agent and screen density settings in one fell swoop.

2014-09-06 20_47_44.gif

Every media query gets represented visually, so you can correlate your breakpoints with the viewport. Clicking one resizes the viewport, making it easier to iterate on your associated styles. If you want to edit the media queries themselves, right-click and jump to the line of CSS where it's defined.

Lastly, device emulation needs to accurately represent the connectivity of your mobile users. For example, a 3G connection significantly limits the experience of your website compared to your speedy office WiFi. The DevTools can now help you emulate the network conditions (both throughput and latency) of connectivity like EDGE, 3G, 4G – and even go offline.
Screen Shot 2014-08-22 at 3.44.13 PM.png
While typical system-wide network conditioning throttles everything, DevTools will only throttle the current tab. This enables you to take your app offline and try out AppCache and Service Worker scenarios, and meanwhile browse documentation in another tab.

Please try out Device Mode your development workflow and let us know what you think. And if you're hungry for more DevTools goodness, check out my Google I/O 2014 talk: Developing Across Devices.

Posted by Paul Bakaus, Developer Advocate and Device Diviner

Gradually Sunsetting SHA-1

Friday, September 05, 2014

The SHA-1 cryptographic hash algorithm has been known to be considerably weaker than it was designed to be since at least 2005 — 9 years ago. Collision attacks against SHA-1 are too affordable for us to consider it safe for the public web PKI. We can only expect that attacks will get cheaper.

That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.

SHA-1's use on the Internet has been deprecated since 2011, when the CA/Browser Forum, an industry group of leading web browsers and certificate authorities (CAs) working together to establish basic security requirements for SSL certificates, published their Baseline Requirements for SSL. These Requirements recommended that all CAs transition away from SHA-1 as soon as possible, and followed similar events in other industries and sectors, such as NIST deprecating SHA-1 for government use in 2010.

We have seen this type of weakness turn into a practical attack before, with the MD5 hash algorithm. We need to ensure that by the time an attack against SHA-1 is demonstrated publicly, the web has already moved away from it. Unfortunately, this can be quite challenging. For example, when Chrome disabled MD5, a number of enterprises, schools, and small businesses were affected when their proxy software — from leading vendors — continued to use the insecure algorithms, and were left scrambling for updates. Users who used personal firewall software were also affected.

We plan to surface, in the HTTPS security indicator in Chrome, the fact that SHA-1 does not meet its design guarantee. We are taking a measured approach, gradually ratcheting down the security indicator and gradually moving the timetable up (keep in mind that we release stable versions of Chrome about 6 – 8 weeks after their branch point):

Chrome 39 (Branch point 26 September 2014)

Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

The current visual display for “secure, but with minor errors” is a lock with a yellow triangle, and is used to highlight other deprecated and insecure practices, such as passive mixed content.


Chrome 40 (Branch point 7 November 2014; Stable after holiday season)

Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.

The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.

Screen Shot 2014-09-05 at 12.05.52 PM.png

Chrome 41 (Branch point in Q1 2015)

Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.

The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.

Screen Shot 2014-08-29 at 1.26.59 PM.png

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

Posted by Chris Palmer, Secure Socket Lover and Ryan Sleevi, Transport Layer Securer