Online security is more than just eliminating buffer overflows from software. One of our biggest security challenges is helping users make safe decisions while they surf the web. Here are some of the things we're doing to make security on the web easier for developers and end users. Some of these are discussed in more detail in this slide deck.
Malicious or compromised websites try to attack visitors. To protect people from these threats, Chrome uses Safe Browsing to identify attack websites. If Safe Browsing tells Chrome that a website is malicious, Chrome shows a full-screen warning. Despite the fact that our warnings are rarely wrong, users ignore the warnings nearly a fifth of the time. We are actively running experiments with the goal of decreasing how many people ignore the warnings.
Shady websites also try to trick people into installing malicious programs on their computers. By default, Chrome blocks known malware downloads. Chrome also warns people about potentially dangerous files that have not been scanned; we are trying to improve this generic warning with new security measures. For example, we want to make it easier for people to view PDFs more safely without needing to show warnings about PDFs.
Safe Browsing to help warn people about phishing pages, but we're also working on other ways to make authentication on the web easier and safer.
The browser’s lack of confidence about the authenticity of a given TLS connection forces it to offer people a choice that they are not likely to understand, so we're working on ways to improve website authentication and protect users from inadvertently visiting or interacting with sites they don't intend to. Here are some of the things we're currently working on:
Presenting Origins To Users
The fundamental security boundary on the web is the origin, defined as the tuple (scheme, hostname, port). For example, (https, www.example.com, 443). We must surface this boundary to users during browsing, in permissions/capabilities dialogs, and so on, so that they can know whom they are talking to. In particular, it is important to note that unauthenticated origins (e.g. (http, www.example.com, 80)) are entirely observable and malleable by attackers who can control the network (often, even just a little bit of control is enough).
Because users tend not to understand the concept of the origin, but do tend to understand the concept of the hostname, we'd like to simplify origin names when we can. Ideally we could reduce the origin name to just the much more understandable hostname. For example, we could elide the scheme or replace it with a meaningful icon, if doing so did not stop users from understanding whether or not an origin is authenticated. And if the port is the default port for the given scheme, we can elide it, too.
If the feature or behavior we are trying to protect (e.g. getUserMedia) is available only on authenticated origins — which we strongly suggest — you could leave off the scheme or the icon. Otherwise, it might be better to highlight the non-authenticated nature of the origin when surfacing it to users.
In addition, we strongly recommend that UIs clearly mark unauthenticated origins as such.
Usability Measurement Tools
Calculate the effective contrast ratio of text on its background: http://webaim.org/resources/contrastchecker/
Flesch-Kincaid (and other) readability calculator: http://www.readability-score.com/