PSA: Tightening Blink's mixed content behavior.

[Mike West]

+security-dev, BCCing blink-dev, FYI.

A few CLs have landed in the recent past that are meant to tighten up Blink's mixed content handling. These behavioral changes will be noticeable to developers, so a here's a quick overview of what's changed so far:

1. XMLHttpRequest, WebSockets, and EventSource are now blocked by default in a mixed context, just like scripts. WebSocket's behavior changed in time for Chrome 37, XMLHttpRequest and EventSource are currently targeting Chrome 38.
   
   Each of these APIs exposes users to the risk that data could be intercepted and modified in transit, and this change brings Blink's behavior into line with Firefox and Internet Explorer, which were already protecting users from these threats.
   
   
2. TextTrack, Web Fonts, Beacon, CSP violation reports, and <a ping> requests are now also blocked by default in a mixed context. These are all passive content, but their usage is such that blocking mixed requests is low risk.
   
   
3. In an ideal world, we wouldn't allow any mixed content: to that end, I've added UseCounters to the remaining types of passive content (images, audio, video, PPAPI requests); if we're successful in driving down usage of those types of mixed content as well, we'll change their default behavior as well.
   
   
4. Forms with mixed action attributes are now treated as passive mixed content, and break the SSL indicator in the omnibox. Ideally, we'd never submit forms to insecure origins, but that's not a change we can make without actually breaking today's web.
   
   
5. We now consistently check both the current context and the top-level context when determine whether we need to worry about mixed content. It was possible to bypass mixed content checking in a few edge cases; now it shouldn't be.

I also intend to clean up the console messages that the mixed content checker to improve clarity, but that's going to take a bit of refactoring work in order to teach the checker what it's looking at.

http://crbug.com/388650 is the bug to follow to keep up with these changes, and you're also cordially invited to participate in the dicsussion around a proposed mixed content spec[1] on the WebAppSec WG's mailing list[2].

[1]: https://w3c.github.io/webappsec/specs/mixedcontent/

[2]: http://lists.w3.org/Archives/Public/public-webappsec/

Thanks!

-mike