Developers should have the tools necessary to defend their creations against the wide spectrum of maliciousness thrown at them on a daily basis. We design and implement platform-level features that enable a robust defense, and work in standards bodies to get them in front of as many developers as possible.
We've shipped Content Security Policy Level 2 as of Chrome 42, and we're starting to put together the vision for the next iteration of the standard. You can follow along at https://github.com/w3c/webappsec-csp. Firefox has support for most of CSP2 as well.
We've shipped Subresource Integrity as of Chrome 46. This feature should also be shipping in Firefox ~43, which is exciting to see.
We've shipped Upgrade Insecure Requests as of Chrome 44. This feature should also be shipping in Firefox 42, which will give us a fairly broad base of support.
We've been steadily tightening our Mixed Content blocking over the last ~18 months. The specification has broad approval from other vendors, who are generally aligning with Chrome's behavior over time.
We have a number of cookie-related proposals floating around that we're building support for in the IETF's HTTPbis group:
We're working with Chrome's password manager team to define an imperative
API for interaction with the browser's stored credentials. The spec is
progressing nicely at https://w3c.github.io/webappsec-cred»
and the feature is mostly implemented behind
Referrer Policy shipped in Chrome a long time ago, and the new bits we've added to the spec are trickling out over time.
We need to do some refactoring in order to consistently apply referrer policy for redirects (basically hoisting the parsing and processing up out of Blink and into the network stack). Hopefully we'll get that done in Q4 (2015).
underlies our commitment to
prefer secure origins for powerful new features. We've shipped the concept of a "secure context" in Chrome, and are working over
time to deprecate a set of APIs in insecure contexts.
We've specified a feature to allow developers to clear out the data a browser has stored for their origin at https://w3c.github.io/webappsec-clear-site-data/, and hope to start on implementation in Q4.
We've specified EPR as a defense against CSRF, and hope to get to a prototype implementation soonish.