This would be fine, if only more third party resources were available over HTTPS at a reasonable cost.<p>For instance, I'd love to use Olark for occasional customer support queries, and the free plan would work great for now. Unfortunately, Olark doesn't offer SSL until their $49/month plan.<p>Similarly, Cloudmade's fantastic OpenStreetMap tileserver is only available over plain HTTP, period.<p>With this change, I would have to choose between great services like Olark or CloudMade and offering SSL everywhere on the site. I understand that select pages with mixed content could be subject to man-in-the-middle attacks, but surely that's a better risk profile than forcing me to run everything over HTTP, right?
That will break the free Google Maps v2 embedded in HTTPS websites (as per <a href="http://code.google.com/apis/maps/faq.html#ssl" rel="nofollow">http://code.google.com/apis/maps/faq.html#ssl</a>)<p>That aside, a good move. Seems Chrome team is the first browser team not affraid of stating openly, ``stick to standards and best practices, because we won't be piling hacks upon hacks for compatibility''. Yay :-)
This seems like a great step.<p>In the future, I hope to see browsers starting to help sites eliminate third-party scripts entirely. <script src="<a href="http://elsewhere/>" rel="nofollow">http://elsewhere/></a>; makes your site's security depend on that of "elsewhere", and allows "elsewhere" to do anything the logged-in user can do; changing the URL to <a href="https://elsewhere/" rel="nofollow">https://elsewhere/</a> doesn't change that.
In an https page, why not rewrite http resources to https by default? Then it could omit the content if there is a cert error or if there is no ssl server there at all.<p>I'm thinking of a use case of a typical not-ssl-mandatory online forum/wiki/whatever. There are going to be tons of historical img and script tags, either to local content or to other sites, that do not use https even when they could; when those links were set up years ago very few sites (other than ecommerce) took ssl seriously. The solutions are going through and changing links in the database, rewriting links in the app, or rewriting links in the web browser. Is there a compelling reason why rewriting links in the web browser is bad? There are five web browsers that people care about: Chrome, FF, IE, Safari, Opera (mostly mobile). There are thousands of webapps and at least tens of thousands of moderately popular sites that would have to rewrite content in the database or webapp in order to go ssl-only.
Am I alone in questioning this?<p>I'm all for serving anything requiring logins over HTTPS, and can accept the argument for anything requiring cookies.<p>But what about the performance improvements available by using shared, cached CDN resources? That doesn't really work over HTTPS, and the performance impact of missing out on that is substantial.<p>There are other cases too: I think it often makes sense to serve static content (eg images) via HTTP while having the HTML on HTTPS. Why should the browser block (or even alert) about this?
Awesome, looks like a good idea to me! It should also not be very destructive as most legitimate websites already try to eradicate mixed (secure|insecure) content.
how will this affect facebook iframe apps? They load from a different origin, and the user is bound to receive a cross-domain error.<p>normally, the following would pass:<p>Unsafe JavaScript attempt to access frame with URL <a href="http://apps.facebook.com/my_app" rel="nofollow">http://apps.facebook.com/my_app</a> from frame with URL <a href="http://server-hosting-my-app.com" rel="nofollow">http://server-hosting-my-app.com</a>. Domains, protocols and ports must match.<p>will this blocked by Chrome in the future? if so, everyone running Chrome 14 onwards won't be able to play Farmville.<p>more info: if you load Farmville on Chrome, this comes up in the debug console (which still passes)<p>Unsafe JavaScript attempt to access frame with URL <a href="http://apps.facebook.com/cityville/?installed=1" rel="nofollow">http://apps.facebook.com/cityville/?installed=1</a> from frame with URL <a href="http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1&installed=1&[MORE" rel="nofollow">http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1...</a> INFO HERE CUT OUT]. Domains, protocols and ports must match.
Well they already managed to get me to fixed one of those issues with their announcement ;p I had an embedded youtube video using http on an encrypted site. Just fixed it.<p>But this could break a lot of sites.