This page aims to answer frequently-asked questions about Chrome/Chromium security. Why can’t I select Proceed Anyway on some HTTPS error screens? A key of guarantee of HTTPS is that Chrome can be relatively certain that it is connecting to the true web server (and not an impostor). Some sites request an even higher degree of protection for their users (you): they assert to Chrome (via Strict Transport Security — HSTS — or by other means) that any server authentication error should be fatal, and that Chrome must close the connection. If you encounter such a fatal error, it is likely that your network is under attack, or that there is a network misconfiguration that is indistinguishable from an attack. The best thing you can do in this situation is to raise the issue to your network provider (or corporate IT department). Chrome only shows non-recoverable HTTPS errors in cases where it can be certain that the server is a false server, and when the true server has previously asked for this treatment. Can you please un-hide old security bugs? Generally we open security bugs to the public once the bug is fixed and the fix has been shipped to a majority of users. However, many vulnerabilities affect products besides Chrome, and we don’t want to put users of those products at risk unnecessarily by opening the bug before fixes for the other affected products have shipped. We must balance a commitment to openness with a commitment to avoiding unnecessary risk for users of widely-used open source libraries. Therefore, we intend to disclose, each quarter, all security bugs that have been closed for more than nine months. We believe that nine months is a more-than-reasonable interval for vendors of affected products to apply and ship bug fixes. Vendors of products based on Chromium can request to be added to a list for earlier access. Email us at security@chromium.org. I need to see these security bugs so that I can back-port the fixes to my downstream project. Many developers of other projects use V8, Chromium, and sub-components of Chromium in their own projects. This is great! We are glad that Chromium and V8 suit your needs. We want to open up fixed security bugs (as described in the previous answer), and will generally give downstream developers access sooner. However, please be aware that backporting security patches from recent versions to old versions cannot always work. (There are several reasons for this: The patch won't apply to old versions; the solution was to add or remove a feature or change an API; the issue may seem minor until it's too late; and so on.) We believe the latest stable versions of Chromium and V8 are the most stable and secure. We also believe that tracking the latest stable upstream is usually less work for greater benefit in the long run than backporting. We strongly recommend that you track the latest stable branches, and we support only the latest stable branch. What are the security and privacy guarantees of Incognito mode? The canonical answer to this question is here: https://support.google.com/chrome/bin/answer.py?hl=en&answer=95464&p=cpn_incognito. In particular, please note that Incognito is not a “do not track” mode, and it does not hide aspects of your identity from web sites. Chrome does offer a Do Not Track option, distinct from Incognito mode: chrome://settings/search#privacy. When in Incognito mode, Chrome on desktop platforms (Windows, Linux, and Mac OS X), Chrome on Android, and Chrome OS do not store any new history, cookies, or other state in non-volatile storage. However, Incognito windows will be able to access some previously-stored state, such as browsing history. It is not possible for Chrome to offer the full Incognito guarantee for iOS. Some data is sometimes stored on non-volatile storage, and while Chrome for iOS makes a best-effort attempt to delete as much history as it can when in Incognito mode, the guarantee is not as strong as it is on other platforms. On Chrome for iOS, we therefore call it “Incognito*” mode. Why aren't physically-local attacks in Chrome's threat model? People sometimes report that they can compromise Chrome by installing a malicious DLL on a computer in a place where Chrome will find it and load it. (See https://code.google.com/p/chromium/issues/detail?id=130284 for one example.) People also sometimes report password disclosure using the Inspect Element feature (see e.g. https://code.google.com/p/chromium/issues/detail?id=126398). We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your computer as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your computer, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome — all applications must trust the physically-local user. There are a few things you can do to mitigate risks from people who have physical control over your computer, in certain circumstances.
|
|
Chromium > Chromium Security >
Security FAQ |