Google shares Chrome browser security principles

Google provides a useful document that helps users understand what's under the Chrome browser's hood, especially as it relates to keeping hackers at bay.

Earlier this week, I declared Google Chrome the most secure browser available today based on its sandbox, auto-update mechanism and the speed with which the Google Security Team patches vulnerabilities.

I received a lot of e-mail feedback questioning that claim so today I'm happy to see Google sharing its Chrome security principles, a very useful document that helps users understand what's under the browser's hood, especially as it relates to keeping hackers at bay.

[ SEE: 10 things to secure your online presence ]

Some key highlights:
  • follow Ryan Naraine on twitter
    Defense in depth:
    Our goal in designing Chrome’s security architecture was to layer defenses, and avoid single points of failure. Chrome’s sandbox architecture represents one of the most effective parts of this strategy, but it’s far from the only piece. We also employ the best available anti-exploit technologies—including ASLR, DEP, JIT hardening, and SafeSEH—along with custom technologies like Safe Browsing, out-of-date plugin blocking, silent auto-update, and verified boot on Chrome OS. And we continue to work towards advancing the state of the art with research into areas like per-origin sandboxing and control flow integrity.
  • Transparency: We do not downplay security impact or bury vulnerabilities with silent fixes, because doing so serves users poorly. Instead, we provide users and administrators with the information they need to accurately assess risk. We publicly document our security handling process, and we disclose all vulnerabilities fixed in Chrome and its dependencies—whether discovered internally or externally. Whenever possible, we list all fixed security issues in our release notes, and make the underlying details public as soon as other affected projects have an adequate amount of time to respond. When we do not control the disclosure timeline for a security issue and cannot list it at the time of release, we make the details of the issue public as soon as disclosure occurs.
  • Community engagement: No software is perfect, and security bugs slip through even the best development and review processes. That’s why we’re grateful for the work of the independent security research community in helping us find and fix vulnerabilities. In response, we do our best to acknowledge and reward their contributions by ensuring proper attribution, paying out bounties, and sponsoring security conferences. We leverage the community to even greater extent where we can, by hiring members directly onto our team and contracting with industry leading, independent security consultancies.

Computer users should always seek to reduce attack surface for attackers and indepth knowledge of under-the-hood security features can help with these decisions.