No. There are two categories of developers: one understands why this is a warning-worthy situation and would never do it, and the other, that shouldn't be trust

No. There are two categories of developers: one understands why this is a warning-worthy situation and would never do it, and the other, that shouldn't be trusted to do the right thing and this message is for. It saddens me that a site as reputable as 37signals would come down on this side of the issue. When people see the padlock icon they expect uncompromised security. (that's not something we can provide, strictly speaking, but that's the expectation, just the same) There are innumerable attack vectors that letting part of the traffic avoid SSL and cache controls would enable. Here's what I can think off right off of the top of my head: 1) Unencrypted HTTP snooping Referral header info: base.css being requested by https://secure.lousy.gov/cgi-bin/home.pl?ssn=123-45-6789 https://secure.lousy.gov/cgi-bin/home.pl?ssn=123-45-6789 2) simple http/https confusion or misconfiguration: http(no-s)://secure.lousy.gov/tempdir/nonce123456/taxes.pdf -- generated by a backend process on the server -- this could be an over-the-wire or cache issue 3) Assorted javascript injections. This would be a sweet malware attack vector, actually. Once you got people to download your .exe you could tend browser caches and update bank javascripts to download 1x1px images with encoded bank information from hostilesite.com Long story short, just like with certificate warning issues, when the argument comes down to "this security error is too confusing for $target_audience, can't we just turn it off?" the answer is always no.