While the web is a virtual treasure trove of great content, it’s also used by bad guys to steal personal information. One of Chrome’s most advanced security features, Safe Browsing, helps protect against the three most common threats on the web: phishing, drive-by malware, and harmful downloads. We recently announced some new enhancements to Safe Browsing, so we thought we’d offer an inside look into how it works.

Safe Browsing downloads a continuously-updated list of known phishing and malware websites, generated by an automated analysis of our entire web index. Each page you visit, and each resource (such as pictures and scripts) on the page, are checked against these lists. This is done in a way that does not reveal the websites you visit, and is described in more detail in our video on Safe Browsing. If Chrome detects that you’ve visited a page on the list, it warns you with a large red page that helps you get back to safety.


Of course, this only helps for dangerous content that Google already knows about. To provide better protection, Safe Browsing has two additional mechanisms that can detect phishing attacks and harmful downloads the system has never encountered before.

Phishing attacks are often only active for a few short hours, so it’s especially important to detect new attacks as they happen. Chrome now analyzes properties of each page you visit to determine the likelihood of it being a phishing page. This is done locally on your computer, and doesn’t share the websites you visit with Google. Only if the page looks sufficiently suspicious will Chrome send the URL of that page back to Google for further analysis, and show a warning as appropriate.

Malicious downloads are especially tricky to detect since they’re often posted on rapidly changing URLs and are even “re-packed” to fool anti-virus programs. Chrome helps counter this behavior by checking executable downloads against a list of known good files and publishers. If a file isn’t from a known source, Chrome sends the URL and IP of the host and other meta data, such as the file’s hash and binary size, to Google. The file is automatically classified using machine learning analysis and the reputation and trustworthiness of files previously seen from the same publisher and website. Google then sends the results back to Chrome, which warns you if you’re at risk.


It’s important to note that any time Safe Browsing sends data back to Google, such as information about a suspected phishing page or malicious file, the information is only used to flag malicious activity and is never used anywhere else at Google. After two weeks, any associated information, such as your IP address, is stripped, and only the URL itself is retained. If you’d rather not send any information to Safe Browsing, you can also turn these features off.

This multi-pronged protection combines to make you much safer against the most prevalent attacks on the web while carefully guarding your privacy. We’ve always believed in making the web a safer place for everyone, so we also make the Safe Browsing API available for free to other browsers and websites.

Safe surfing!

Posted by Niels Provos, Software Engineer, and Ian Fette, Product Manager

Cross posted to: dartlang.org and the Google Code Blog

It took approximately 2000 years for the original Rosetta Stone to be discovered, which helped translate the Egyptian Hieroglyphs. We couldn’t wait that long to bridge the Dart and JavaScript worlds, so today we are releasing the JavaScript to Dart Synonym app.

Like most web developers, we are familiar, comfortable, and productive with JavaScript. We were curious about Dart, and thanks to a recent Dart hackathon, we had the chance to play with the language and libraries. The problem was, as JavaScript developers, we didn’t know how to map common JavaScript idioms to Dart. Hence the idea for this synonym app was born.

We started with the basics that every JavaScript and jQuery developer knows: variables, arrays, functions, classes, DOM manipulation, and many more. Then, with the help of the Dart team, we recorded the corresponding Dart versions of each idiom. To practice what we learned, we wrote this app with Dart.



We hope our app that maps between JavaScript and Dart eases your introduction to Dart and gives you a sense of where the project is going. We know the team is eager to hear your feedback. Don’t hesitate to join the conversation or file a new issue for either Dart or the Synonym app. And remember, Dart isn’t set in stone, so your feedback counts.

Posted by Aaron Wheeler and Marcin Wichary

In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web.

Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search. Given that Google search results are some of the most highly optimized pages on the internet, this was a surprising and welcome result.

We’ve also seen widespread community uptake and participation. Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we're actively working on a full featured mod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.

Given SPDY's rapid adoption rate, we’re working hard on acceptance tests to help validate new implementations. Our best practices document can also help website operators make their sites as speedy as possible.

With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF.

We look forward to working even closer with the community to improve SPDY and make the Web faster!

To learn more about SPDY, see the link to a Tech Talk here, with slides here.

Posted by Roberto Peon and Will Chan, Software Engineers

One of my favorite features of Chrome got a boost earlier today, as we announced support for an experimental new “autocomplete type” attribute for form fields. The new attribute will allow web developers to unambiguously label text and select fields with common data types such as ‘full-name’ or ‘street-address’ and guarantee that their site’s forms work correctly with Chrome Autofill and other form-filling providers.

We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.

For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!


Posted by Ilya Sherman, Software Engineer

Since we open sourced WebRTC this past summer, we’ve been working hard with browser vendors to integrate WebRTC technology in their products. Today, we reached an important milestone: WebRTC is now integrated in the Chrome browser available on the dev channel.

Building industry-leading voice and video capabilities into the browser makes it easier for web developers to incorporate real time communications in their apps. Instead of relying on custom, OS specific, proprietary plug-ins, they can now easily build and maintain their apps using a few simple JavaScript APIs and have the browser do the heavy lifting.

Even though WebRTC is still evolving, we are receiving feedback from the standards process in W3C and IETF and there are already plenty of apps in development. For example, companies like Polycom, Vonage, Vehix.com, Firespotter, Siemens, Nimbuzz and PCCW are currently actively developing browser based solutions using WebRTC. If you are interested to learn more on how you can use WebRTC in your app, review our documentation, join our developer discussion group and go to the WebRTC blog for more details. We are looking forward to seeing what you come up with!


Posted by Niklas Enbom, Software Engineer

When we first set out to design Chrome, we knew we had a unique opportunity to improve the security of the web. In addition to speed and simplicity, we’ve been adamant that security be a central tenet of everything we build. Chrome and the web have since come a long way, and we’ve been challenged to protect a complex and rapidly changing browser against the many threats that emerge on the web.

After spending tens-of-thousands of hours working on ways to make users safer on the web, we thought it might be worth sharing the Chrome security principles that guide the work that we do.

There are lots of technical details, but the fundamentals have always been simple. Security should compliment your browsing experience, not detract from it, and your browser should be secure by default -- no configuration required. No defense is ever perfect, so we rely on multiple layers of protection to help guard against single points of weakness. We support and fund the security research community in their work to identify weaknesses, and when vulnerabilities are found, we pride ourselves on patching them faster than any other browser.

These principles have served us well in protecting users while keeping Chrome super fast and easy to use. If you develop software, we hope you find them helpful in securing your own product, and if you’re a Chrome user, that they give some insight into the many ways we work to help you surf with confidence.

Posted by Justin Schuh and Travis McCoy, Chrome Security Team