The problem is that you asserted it is "just as easy".

It certainly might be possible for the attacker to compromise a specific server that you have chosen to trust - but that's a much higher barrier to an attacker than performing MITM on an open Wifi connection which doesn't require them to compromise any server.

Okay, here's another "just as easy" scenario:

1. You include http://google.com/trusted.js on a https page

2. Someone goes to a cafe, opens up your website with Safari while someone is performing a MiTM attack on that file.

3. No warnings, your user is compromised.

Yeah, then don't do that, that's the point. Whether you include mixed content in your site is up to you, the developer.

The entire concept of the SSL icon is so that a user can trust a third party (web developer) that they don't know. If it's up to you (the web developer) — it's all up in the air again. And the icon/warnings are pointless. Which is where I've been trying to go with this…

Eh? SSL provides security against eavesdroppers, network manipulation, etc. - it doesn't help against a malicious site that you actually intended to communicate with.

Any browser which doesn't warn about that in some way is essentially broken. (Yes, I see you cited Safari as one, but it must the the only one as far as I know - it does remove the padlock, but that seems pretty inadequate ...)

EDIT: I do take your point in that I think IE is the only browser that actually blocks the content. The others warn about it but still load it, by which time, of course, the damage is done.

Our theory is that an SSL site including non-SSL content is no better or worse, in terms of security, than a completely non-SSL site.

What is the purpose of warning more prominently in the scenario described, than in the scenario where the user goes to a non-SSL site in the first page, or is redirected from an SSL login form to a non-SSL page?

Saying you can hack an analytics company's servers is cheating. I can just say I can hack GitHub's servers. Or obtain a root SSL cert. Or crack SSL.

If you don't trust a company and their competency at security you probably shouldn't be using their service for anything sensitive. You can't assume that your users aren't on hostile networks vulnerable to MITM attacks, etc.

Absolutely, but the protection SSL helps with is it actually forces the attacker to compromise hot-new-metrics whereas without SSL you can just skip the first part of step 2 and just do "send malicious js" through a MITM without ever having to go compromise any of the services involved.

Unless they're using Safari which doesn't have a mixed content idea. My point is that it doesn't fix anything at all. Like filling 8/10 holes in a bucket of water. It's still going to leak out.

It is the webapp developer who ultimately decides whether or not there is mixed content, not the browser. If you don't mix content in your webapp, an attacker who controls the network shouldn't be able to change your content (not even to inject references to new untrusted HTTPS or plain HTTP servers), or that of trusted service providers. The browser needs to implement SSL securely, but even users with a browser with no mixed-content warning benefit from there being no mixed-content.

The mixed content warning helps to warn the developer of the site of the problem, and let users of browsers that support it know that they are not fully protected.