Chrome to block insecure resources by default
googleonlinesecurity.blogspot.com
googleonlinesecurity.blogspot.com
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.
Similarly, Cloudmade's fantastic OpenStreetMap tileserver is only available over plain HTTP, period.
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?
It's a huge, common issue. For example, Yahoo's AJAX libraries serve via HTTP, and it doesn't work over HTTPS. See, for example https://yui.yahooapis.com/combo?2.9.0/build/yahoo-dom-event/...
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 :-)
It's hard to say if the benefits in this particular case are worth it, but I'm becoming increasingly wary of "this old hotness is deprecated, everyone should upgrade to the new hotness!"
In the future, I hope to see browsers starting to help sites eliminate third-party scripts entirely. <script src="http://elsewhere/>; 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 https://elsewhere/ doesn't change that.
But I do hope that something like this becomes one of the standard add-ons that we can install. I'll have to go check if NoScript has a similar option...
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.
I guess about 15 years ago someone asked: "Why not let the browser try to interpret broken HTML instead of showing an error page?". The result is today's security nightmare, where it's impossible to reliable prevent script injection into HTML pages, because you can't just block the "official" way to insert a script, but also need to look into each of those ways how an HTML engine might interprete broken HTML.
Ugly hacks to make the web even marginally more safe by encouraging or forcing use of https (in places it isn't explicitly specified) may be worthwhile. The thread's chrome hack alone reduces the usability of https, to the point of (I would guess) encouraging sites to use http and disable https so that visitors can actually see embedded content. Average web users know nothing of https, but if they happen across a site using https and embedded content doesn't show up, they'll blame the site. Certainly _that_ is not good. If this google hack is truly worth the pain, and even a small fraction of embedded content works with the uri changed from http to https, that's a benefit because it makes https more usable.
Would you think the same about simply changing the HSTS header so that sites could tell a browser to force loading all embedded http:// content through https://?
It seems to me like Google's long-term goal is to encourage tls everywhere. If all sites that have user accounts (thus logins) are using https, and all content embedded on those sites has to be referenced over https (or another secure protocol), that's probably the bulk of the web.
So the long term costs (in the far future) are an irrelevant cruft of a hack that ends up doing nothing because there are no http:// resource links anywhere. A hack which could, at that point, be removed with no impact whatsoever.
Just one example where your suggestion might break sites:
Let's assume a site hosts non-SSL content on www.example.com and SSL content on example.com. Now the site want's to default to SSL by changing most of the links and by automatically redirecting every non-SSL www.example.com request to a SSL secure.example.com.
For "traditional" browsers this approach would work fine: Even if non-SSL resources are linked users are redirected to the right place.
With the new Chrome approach chrome might block some of the content, but makes it clear why this was done. Users can also override this block (at least for now).
With your suggestion this page will break as the browser tries to access the SSL version at www.example.com, which might not exist, or which might not have a correct certificate.
Granted, this is just one example, and there are other cases where this approach might work fine. But the Web is just too complex to predict how such hacks will work out. I cannot think of a single such hack that did not create long term problems eventually.
Regardless, embedded content sites that would be swamped if all requests were over https, and sites that map http://foo and https://foo differently, are going to have to figure out solutions, or they'll stop being embedded as more sites enable https. Even under the status quo, mixed content warnings and symbols are a little bit scary and sites wishing to go https-enabled or https-only will encourage members to use embeddable content hosting services that support https.
I'm all for serving anything requiring logins over HTTPS, and can accept the argument for anything requiring cookies.
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.
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?
SSL resources are still cached, not sure what you're getting at.
> 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?
I MITM your users and insert a huge image saying "You need to confirm your bank account details, please call this number now <insert my phone number>" (etc.)
Not unless they have the cache-control:public header.
normally, the following would pass:
Unsafe JavaScript attempt to access frame with URL http://apps.facebook.com/my_app from frame with URL http://server-hosting-my-app.com. Domains, protocols and ports must match.
will this blocked by Chrome in the future? if so, everyone running Chrome 14 onwards won't be able to play Farmville.
more info: if you load Farmville on Chrome, this comes up in the debug console (which still passes)
Unsafe JavaScript attempt to access frame with URL http://apps.facebook.com/cityville/?installed=1 from frame with URL http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1... INFO HERE CUT OUT]. Domains, protocols and ports must match.
That's always popped up in WebKit debuggers. I think everyone that's ever developed a Facebook app wastes 20 minutes learning that they can and should ignore it.
But this could break a lot of sites.