User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 If an HTTPS page embeds a SWF movie over HTTP, the browser fails to detect mixed content. SWF movies can script the embedding page. Insecure Java applets go similarly undetected. This bug is particularly insidious because site developers often rely on the browser to detect mixed content in their site. For example, at least one major bank includes an insecure SWF on their login page, allowing an active network attacker to steal their customer's passwords and second factors of authentication. Reproducible: Always Steps to Reproduce: Steps to reproduce: 1) Navigate to <https://www.stanford.edu/~collinj/research/flashjs.html>. 2) Notice the insecure applet can script the page. 3) Notice the lack of a slash over the lock icon. Actual Results: Browser treats page as secure (does not degrade to mixed content). Expected Results: Browser should degrade page to mixed content.

This is related to bug 369503, although that one complains about security UI not being updated to reflect insecure connections made by the plugin itself, rather than not updating because of insecure loading of the plugin file. I think we probably load plugins in the background, as we do for XMLHTTPRequest loads and some image loads, so this might depend on bug 305284/bug 135007.

We don't do plugin loads in the background, no. That said, there are at least three different plugin loading codepaths. :( Can someone trace through the code here to see exactly where we do the AsyncOpen on the nsHttpChannel? I'd do it if gdb would let me breakpoint there.... I suspect this may be a PSM bug, not a plug-in bug.

Boris, what do you think the priority should be on this? Note: We're up to about 175 P3 bugs here. Need to be super rational about how we prioritize things from this point on. I don't see this making beta 2. So, we need to decide Beta 3 or final. Thoughts?

ccing Daniel and Kai for their thoughts. The answer sort of depends on how reliable the security UI is now and how seriously we take issues with it... I suspect any change here would be somewhat risky, but can't really justify rating this above P3, I don't think.

+'ing and making P3.

Jonas assigned this to me, but I agree with boris in comment 2 that this is probably an NSS/PSM bug with the kinds of updates we get in chrome through our WebProgressListener. We've seen mixed content breaking in other bugs too, as gavin mentions. I think Kai is looking at this brokenness as a result of bug 402574, which also deals with broken signalling between crypto and chrome. Re-directing to sec:ui anyhow, since it seems likely that it has more to do with how we're handling the security of the channel than with the plugin in particular. Judging from the symptoms alone, and without knowing the code involved, it feels like we have one or two bugs here that are responsible for a dozen different chrome-misidentifying-security-level reports.

This has been fixed, though I don't know when.