Hacker News Reader

Comment by stellar678 | Hacker News Reader

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

View on HN

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.

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.

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.

Reply on news.ycombinator.com