Web Platform Security
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:
[Deprecating modification/creation of "Secure" cookies on non-secure origins](https://tools.ietf.org/html/draft-west-leave-secure-cookies-along) strengthen the security properties of cookies with the Secure attribute. [SameSite](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00) cookies provide a defense against various forms of CSRF [Cookie Prefixes](https://tools.ietf.org/html/draft-west-cookie-prefixes) might provide a mitigation for the integrity and confidentiality limitations of cookies' delivery model. [Origin cookies](https://tools.ietf.org/html/draft-west-origin-cookies) are a slightly more robust model than the prefix proposal, but also seem less likely to be adopted, so. Belts and suspenders.
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
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).
Secure Contexts underlies
our commitment to prefer secure origins for powerful new
We've shipped the concept of a "secure context" in Chrome, and are working over
time to deprecate a set of APIs in insecure
getUserMedia() is unavailable over HTTP as of Chrome 47, and we've got our eye
on geolocation next.
We've specified and implemented 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/.
We've specified EPR as a defense against CSRF, and hope to get to a prototype implementation soonish.(this hasn't made progress in a few years)
If any of the above work resonates with you, come help us! We're hiring in Munich, Germany, which is a wonderful place to work indeed. There's a generic software engineering job description, but the best way to get noticed is probably to ping @mikewest on Twitter, or drop him an email at email@example.com.