6 ms·

Google Chrome Now Blocks Insecure Scripts on HTTPS

58 points by riledhel 15y ago

Groxx 15y ago
Harsh, when this hits the stable build, but a good thing overall. Web security really is a frightening place, this will help encourage at least a chunk of it to improve.
- roam 15y ago
  IE has been doing the same thing for years.
  - skimbrel 15y ago
    It has, but I bet this has trained a lot of Windows users to just click OK because it's another thing that gets in the way of loading a page… At least Chrome's interface for this makes it less obtrusive than a pop-up dialog.
    - Encosia 15y ago
      In IE9, the mixed content warning is not modal. It blocks insecure content by default, with a notification bar that allows the user to allow mixed content.
      - pyre 15y ago
        IE9 hasn't been out for 'years' though.
    - yuhong 15y ago
      Yea, the mixed content warning in IE has been there since at least IE6 (likely earlier), but for IE8 they flipped the Yes and No choices probably because of exactly this, and as mentioned in another comment, in IE9 it is no longer a modal dialog at all.
igorgue 15y ago
This has been annoying to me, since Google Reader doesn't have a valid cert (sometimes) so I always get that message.
- pilif 15y ago
  Nope. Google Reader is fine. But the RSS entries that it's displaying sometimes other resources from the original blogs. For videos or click tracking, this sometimes is JS. Before the change, it just put the browser into mixed-content-mode, but now it does that and in addition it disables loaded JS. I think it should block it without the error message though.
  - abraham 15y ago
    The problem with not having an error message is then content disappears and users will have no idea. Not a good experience.
- Lexarius 15y ago
  Their cert is fine, it's just that the page generally has to load content from external, untrusted sources to do what it does.
dmaz 15y ago
http://news.ycombinator.com/item?id=2662694 http://news.ycombinator.com/item?id=2662694
buro9 15y ago
One of the side effects of this that I've seen is on sites that are on https:// https:// but offer embedded YouTube and other such scripts that are coming from http:// http:// Basically... I'm seeing this message crop up wherever I see embedded media. Message is: Even if your site doesn't need https:// https:// , if you're going to offer widgets and embedding you better offer a https:// https:// option for those.
- abraham 15y ago
  YouTube does provide SSL for embeds. Many sites just don't use it.
iam 15y ago
I would go one step further and block form input when you are on an HTTP site, to forms that go to HTTPS. This would end the charade of "secure" log-ins on an HTTP page by forcing the login page to be an HTTPS page.
- etherealG 15y ago
  can you explain how this is a charade? I would think that posting my username & password from a http site to a https site still does ssl negotiation before sending that username and password along a network pipe. Doesn't sound like a charade to me.
  - mnutt 15y ago
    The only problem is that someone can MITM your connection to the http page and send you back javascript that steals your password.
    - capnrefsmmat 15y ago
      Or just change the form so it POSTs to their secret evil server, rather than to the secure site.
  - burgerbrain 15y ago
    It eliminates the positive feedback browsers normally present. No positive feedback is bad news (see sslstrip).
stellar678 15y ago
I like Chrome's ongoing attempt to push forward security where it's obviously deficient, but I'm worried that that we'll start getting warning-weary with all these drop-down bars telling us that something might be awry. Any site that has Java already gets one of these on Chrome, now this will pop up, seems like it will just train users that the only way to get their web content to display properly will be to click "yes! run it! dammit, just let me see my stuff because i couldn't care less what you're telling me!" I'm not quite sure what a better UI solution would be however...
- mtogo 15y ago
  It's not a UI problem, it's a user problem. Users will always click "Yes, allow" to everything without even reading it, be the message in dialog box or notification bar or a demon holding a flashing neon sign. It's a big problem, but it's more about users compulsively clicking Yes and not so much about Chrome's UI.
  - mquander 15y ago
    Wait a minute, what the hell do you think got them in the habit of compulsively clicking "yes"? It's interfaces like this, which offer a question for which the correct answer 95% of the time is to click "yes". I'm not saying that I have a better idea about how to do it, but this is UI designers reaping what they have sown.
    - thwarted 15y ago
      The correct answer isn't to click "yes", the correct answer is to click "no". The problem is that the correct answer doesn't give someone access to the content, and many, many sites are not in a position to do things correctly or don't understand what the correct thing to do is (I don't know why this is the case), so if the user wants to make any progress at all, even if they end up doing so insecurely, they have to answer in whatever way allows them to make progress.
      - mquander 15y ago
jeggers5 15y ago
This can only be considered as a good thing. Chrome is innovating, and pushing all the other main browsers to do the same and become more secure. If anything I think that Chrome is helping Google's Apps (Gmail, Calendar etc) to run smoother across the board on all browsers.
jackolas 15y ago
We just need to start doing //:domain.foo/script.js (protocol relative URL)
jasonkester 15y ago
The important thing with features like this is that you can't allow the user a way to disable it. If it can be disabled, the first people who disable it will be developers, who will proceed to continue building websites that pop this up for everybody else, oblivious that it's pissing off every one of their users. We already went through this cycle once with javascript error popups. Developers turned them off, then pasted in crappy 3rd party dhtml menu code, which in turn threw up warnings for every regular user to come down the pike. These warnings need to be prominent and painful. And they need to stay that way for everybody, otherwise they'll just be an annoyance for non-savvy users, rather than an incentive to fix the 400 million sites that are currently getting this wrong.
zmmmmm 15y ago
I've been puzzled for years about why Chrome ever allowed this. IE always blocked such scripts. It makes no sense to block a whole page that has an invalid cert with a warning but display no warning at all to a user (other than losing the green on the URL) when a valid HTTPS site loads an insecure script in the background.
eneveu 15y ago
That's were relative URLs without a scheme come in handy, e.g. "//www.example.com/example_file.js" If the current page is served over https, it will load scripts using https. If it's served over http, it will use http. http://stackoverflow.com/questions/550038/is-it-valid-to-replace-http-with-in-a-script-src-http http://stackoverflow.com/questions/550038/is-it-valid-to-rep...
digamber_kamat 15y ago
this is truly nonsensical. How am I supposed to server my YUI files ?

58 points by riledhel 15y ago

Groxx 15y ago

Harsh, when this hits the stable build, but a good thing overall. Web security really is a frightening place, this will help encourage at least a chunk of it to improve.

roam 15y ago
IE has been doing the same thing for years.
- skimbrel 15y ago
  It has, but I bet this has trained a lot of Windows users to just click OK because it's another thing that gets in the way of loading a page… At least Chrome's interface for this makes it less obtrusive than a pop-up dialog.
  - Encosia 15y ago
    In IE9, the mixed content warning is not modal. It blocks insecure content by default, with a notification bar that allows the user to allow mixed content.
    - pyre 15y ago
      IE9 hasn't been out for 'years' though.
  - yuhong 15y ago
    Yea, the mixed content warning in IE has been there since at least IE6 (likely earlier), but for IE8 they flipped the Yes and No choices probably because of exactly this, and as mentioned in another comment, in IE9 it is no longer a modal dialog at all.

igorgue 15y ago

This has been annoying to me, since Google Reader doesn't have a valid cert (sometimes) so I always get that message.

pilif 15y ago
Nope. Google Reader is fine. But the RSS entries that it's displaying sometimes other resources from the original blogs. For videos or click tracking, this sometimes is JS. Before the change, it just put the browser into mixed-content-mode, but now it does that and in addition it disables loaded JS. I think it should block it without the error message though.
- abraham 15y ago
  The problem with not having an error message is then content disappears and users will have no idea. Not a good experience.
Lexarius 15y ago
Their cert is fine, it's just that the page generally has to load content from external, untrusted sources to do what it does.

dmaz 15y ago

http://news.ycombinator.com/item?id=2662694 http://news.ycombinator.com/item?id=2662694

buro9 15y ago

One of the side effects of this that I've seen is on sites that are on https:// https:// but offer embedded YouTube and other such scripts that are coming from http:// http:// Basically... I'm seeing this message crop up wherever I see embedded media. Message is: Even if your site doesn't need https:// https:// , if you're going to offer widgets and embedding you better offer a https:// https:// option for those.

abraham 15y ago
YouTube does provide SSL for embeds. Many sites just don't use it.

iam 15y ago

I would go one step further and block form input when you are on an HTTP site, to forms that go to HTTPS. This would end the charade of "secure" log-ins on an HTTP page by forcing the login page to be an HTTPS page.

etherealG 15y ago
can you explain how this is a charade? I would think that posting my username & password from a http site to a https site still does ssl negotiation before sending that username and password along a network pipe. Doesn't sound like a charade to me.
- mnutt 15y ago
  The only problem is that someone can MITM your connection to the http page and send you back javascript that steals your password.
  - capnrefsmmat 15y ago
    Or just change the form so it POSTs to their secret evil server, rather than to the secure site.
- burgerbrain 15y ago
  It eliminates the positive feedback browsers normally present. No positive feedback is bad news (see sslstrip).

stellar678 15y ago

I like Chrome's ongoing attempt to push forward security where it's obviously deficient, but I'm worried that that we'll start getting warning-weary with all these drop-down bars telling us that something might be awry. Any site that has Java already gets one of these on Chrome, now this will pop up, seems like it will just train users that the only way to get their web content to display properly will be to click "yes! run it! dammit, just let me see my stuff because i couldn't care less what you're telling me!" I'm not quite sure what a better UI solution would be however...

mtogo 15y ago
It's not a UI problem, it's a user problem. Users will always click "Yes, allow" to everything without even reading it, be the message in dialog box or notification bar or a demon holding a flashing neon sign. It's a big problem, but it's more about users compulsively clicking Yes and not so much about Chrome's UI.
- mquander 15y ago
  Wait a minute, what the hell do you think got them in the habit of compulsively clicking "yes"? It's interfaces like this, which offer a question for which the correct answer 95% of the time is to click "yes". I'm not saying that I have a better idea about how to do it, but this is UI designers reaping what they have sown.
  - thwarted 15y ago
    The correct answer isn't to click "yes", the correct answer is to click "no". The problem is that the correct answer doesn't give someone access to the content, and many, many sites are not in a position to do things correctly or don't understand what the correct thing to do is (I don't know why this is the case), so if the user wants to make any progress at all, even if they end up doing so insecurely, they have to answer in whatever way allows them to make progress.
    - mquander 15y ago

jeggers5 15y ago

This can only be considered as a good thing. Chrome is innovating, and pushing all the other main browsers to do the same and become more secure. If anything I think that Chrome is helping Google's Apps (Gmail, Calendar etc) to run smoother across the board on all browsers.

jackolas 15y ago

We just need to start doing //:domain.foo/script.js (protocol relative URL)

jasonkester 15y ago

The important thing with features like this is that you can't allow the user a way to disable it. If it can be disabled, the first people who disable it will be developers, who will proceed to continue building websites that pop this up for everybody else, oblivious that it's pissing off every one of their users. We already went through this cycle once with javascript error popups. Developers turned them off, then pasted in crappy 3rd party dhtml menu code, which in turn threw up warnings for every regular user to come down the pike. These warnings need to be prominent and painful. And they need to stay that way for everybody, otherwise they'll just be an annoyance for non-savvy users, rather than an incentive to fix the 400 million sites that are currently getting this wrong.

zmmmmm 15y ago

I've been puzzled for years about why Chrome ever allowed this. IE always blocked such scripts. It makes no sense to block a whole page that has an invalid cert with a warning but display no warning at all to a user (other than losing the green on the URL) when a valid HTTPS site loads an insecure script in the background.

eneveu 15y ago

That's were relative URLs without a scheme come in handy, e.g. "//www.example.com/example_file.js" If the current page is served over https, it will load scripts using https. If it's served over http, it will use http. http://stackoverflow.com/questions/550038/is-it-valid-to-replace-http-with-in-a-script-src-http http://stackoverflow.com/questions/550038/is-it-valid-to-rep...

digamber_kamat 15y ago

this is truly nonsensical. How am I supposed to server my YUI files ?