Google Chrome Now Blocks Insecure Scripts on HTTPS | Hacker News Reader

Google Chrome Now Blocks Insecure Scripts on HTTPS

google-chrome-browser.com

58 pointsriledhel47 comments

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

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.

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.

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.

Well, I'm not sure I agree. The correct answer is determined by how much they care about the risk that someone might be feeding them a malicious script. I think most users care more about the convenience of accessing their favorite site with full functionality than this security problem, as demonstrated by most people's totally lax regard for security in other ways.

(Of course, I'm sure that most users have no idea what clicking 'yes' entails -- I'm just proposing that if they did, they would probably click 'yes' anyway.)

No, you're wrong. If a site has users that don't care about security at all and are happy to have their accounts compromised, the site shouldn't even be using SSL in the first place.

Isn't it perfectly plausible that 80% of a site's users don't give a hoot about security, but 20% do? I don't see any reason not to give the minority SSL (hopefully compromised minimally by non-SSL resources) regardless of whether the majority cares.

| SSL (hopefully compromised minimally by non-SSL resources)

There's a reason browsers don't display a secure logo on HTTPS connections with non-HTTPS resources: it's not secure. It's not "minimally compromised", it's compromised. If my server has one service with one vulnerability, it's not "minimally vulnerable", it's vulnerable.

| I don't see any reason not to give the minority SSL

I was being sarcastic.

| Isn't it perfectly plausible that 80% of a site's users don't give a hoot about security, but 20% do?

It's not even about the users. The site should not ever be mixing HTTP with HTTPS on the same page.

Yeah, I agree with that. It's a stupid problem, but the problem exists, and until we are allowed to forcefully seize the servers of people who implement shitty software and fix the problems, it won't go away, so it's worth trying to do the best thing possible for users.

| Wait a minute, what the hell do you think got them in the habit of compulsively clicking "yes"?

The user is trying to do something (check email, save a note, play angry birds). Something is in their way, and there is an obvious way to get it out of their way. It has nothing to do with UI design or habits.

If you're using a computer, something usually "gets in your way" every ten minutes. If that wasn't the case, users might be less keen to get it out of their way, and try to figure it out or ask for help instead.

Take the Xbox then. It only interrupts starting a game once in a while, when there's a game update. Yet, every one of my friends start mashing the A button as soon as the update window pops up. They just want to play black ops, not read some dialog.

Good point.

Interfaces should cater to users. It's not the users' fault your interface isn't intuitive—it's yours.

In this case, "Load anyway" is a poor label. "Load potentially insecure script anyway" is better (if a bit long-winded).

| Interfaces should cater to users. It's not the users' fault your interface isn't intuitive—it's yours.

I did not design this interface.

Just word the question to "do you want to be sure you have a secure web experience" so the default yes is secure...

then the bug reports of stuff not working come flooding in

Those bug reports should go to the site, not the browser. That's part of the problem.

I think the expectation is that any halfway decent web site will make whatever changes are necessary to avoid the warning.

Sure, but halfway decent web sites aren't the ones hosting malware.

The problem is not sites hosting malware. The problem is man-in-the-middle attacks on javascript loaded in the clear on sites otherwise using HTTPS. If an attacker can replace a bit of JavaScript that gets loaded into the page, that somewhat defeats the purpose of using SSL.

That is already the case on Android, where 99% of the times, even a "techie" would click yes, considering the permissions are so general.

To be fair to Android, I haven't personally found that to be the case. I went to connect to my workplace's Exchange server and got hit with a host of overkill permissions that I need to give to the Exchange admin. As a result, I went and read about what control Exchange administrators have over connected devices, and decided that getting my work email wasn't worth the risk. So the Android permissions system worked for me.

One of the side effects of this that I've seen is on sites that are on https:// but offer embedded YouTube and other such scripts that are coming from http://

Basically... I'm seeing this message crop up wherever I see embedded media.

Message is: Even if your site doesn't need https:// , if you're going to offer widgets and embedding you better offer a https:// option for those.

YouTube does provide SSL for embeds. Many sites just don't use it.

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.

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.

The only problem is that someone can MITM your connection to the http page and send you back javascript that steals your password.

Or just change the form so it POSTs to their secret evil server, rather than to the secure site.

It eliminates the positive feedback browsers normally present. No positive feedback is bad news (see sslstrip).

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.

IE has been doing the same thing for years.

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.

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.

IE9 hasn't been out for 'years' though.

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.

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

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.

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.

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

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

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.

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

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.

The problem with not having an error message is then content disappears and users will have no idea. Not a good experience.

Their cert is fine, it's just that the page generally has to load content from external, untrusted sources to do what it does.

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

Reply on news.ycombinator.com