
Chrome to block insecure resources by default - abraham
http://googleonlinesecurity.blogspot.com/2011/06/trying-to-end-mixed-scripting.html
======
callahad
This would be fine, if only more third party resources were available over
HTTPS at a reasonable cost.

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?

~~~
nl
Why is this getting downvoted?

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/...](https://yui.yahooapis.com/combo?2.9.0/build/yahoo-dom-event/yahoo-
dom-event.js&2.9.0/build/animation/animation-min.js)

~~~
xorglorb
Google's CDN has YUI over SSL:

<http://code.google.com/apis/libraries/devguide.html#yui>

~~~
nl
This is true, but doesn't invalidate my point

------
dexen
That will break the free Google Maps v2 embedded in HTTPS websites (as per
<http://code.google.com/apis/maps/faq.html#ssl>)

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 :-)

~~~
abraham
Google Maps v2 has been deprecated so sites should update to v3 anyways.

~~~
kgrin
You know, I'm sympathetic to this point and yet... I can't help feeling like
this sort of thing really screws people who put up perfectly serviceable
websites just 3 short years ago, who now need to go back and spend effort just
to keep things working.

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!"

------
JoshTriplett
This seems like a great step.

In the future, I hope to see browsers starting to help sites eliminate third-
party scripts entirely. <script src="[http://elsewhere/>](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.

~~~
kijinbear
There's no way Chrome will do this until Google can find a different way to
insert AdSense ads on third-party sites. Currently, third-party scripts are
the best way to achieve this. iframes are inelegant, and telling webmasters to
update the script every once in a while just isn't going to work.

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...

~~~
JoshTriplett
What makes an iframe inelegant? It seems like the correct way to handle
advertisements or other third-party content.

------
runningdogx
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.

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.

~~~
gst
Yes there is a compelling reason: It's not the task of the browser to do this.
With such an ugly hack you gain some short term benefits at large long term
costs.

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.

~~~
runningdogx
Is it more of an ugly hack than forcing arbitrary sites to https based on a
list that's partially hard-coded, partially user-specified, and partially
added through an HSTS header in which case the entry also has a limited
lifespan?

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.

~~~
gst
HSTS (even with the embedded list) only works if the website operator opts-in.

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.

------
ChuckMcM
I see mixed http/https in gmail a lot. I wonder if that will break it.

~~~
abraham
That should be from loading images over http which will not trigger the
warning.

------
nl
Am I alone in questioning this?

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?

~~~
lamby
> 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.

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.)

~~~
nl
_SSL resources are still cached, not sure what you're getting at._

Not unless they have the cache-control:public header.

------
ojilles
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.

------
bazookaBen
how will this affect facebook iframe apps? They load from a different origin,
and the user is bound to receive a cross-domain error.

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...](http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1&installed=1&\[MORE)
INFO HERE CUT OUT]. Domains, protocols and ports must match.

~~~
andrewf
_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.

------
nkassis
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.

But this could break a lot of sites.

------
bane
I'm still miffed at the chrome team for killing the rendering of local XML
files.

~~~
abraham
What are you talking about? Chrome renders XML just fine.

------
puls
Yes please.

