[GedByrne]

I’d like to defend this guy. What he is doing is testing the trust mechanism.

If he went to Google and said ‘I think the trust mechanism is broken’ Google would say: ‘We know, that’s why we are pushing to move everyone to https.’

‘That isn’t enough. The padlock on the https page gives users a false sense of security.’

‘We don’t agree with that. Where’s your data?’

Google wouldn’t have accepted this. They have pushed full HTTPS hard, and suggesting that it has a negative consequence is unacceptable to them.

His experiment has proven the problem. How else could it have been demonstrated?

Ideally this would have been a large scale study done by academics. But this guy doesn’t have those resources. Nobody is going to fund this research.

The depressing thing here is that everybody is more interested in calling this guy a jerk than dealing with the issues he has raised.

Trust on the internet is broken. This guy did it with ease. Imagine what is being done by those who want to scam millions?

But yeh, call him a jerk and then you can bury your unease beneath a big pile of outrage. It’s fine. Fine. He’s a jerk.

[dejanseo]

Thank you. I'm not having a good time at the moment. Anyway, the basis of my test hypothesis is that people are easily fooled by URL both by HTTPS and brand recognition (e.g. subdomain) so I conducted a survey which revealed the very real problem: https://dejanseo.com.au/trust/

Raw data: https://dejanseo.com.au/wp-content/uploads/2017/04/survey-te...

[3pt14159]

Hey man, I know how hard the hate hits when you explain something like this to a community. It happened to me here too when I talked about the mass weaponization of autonomous systems via cyber attack. One guy said I was somehow right and a crank at the same time and dismissed one of my conclusions out of hand without addressing any of the reasoning behind it. I hurt at the time, but I came to understand it wasn't really directed at me.

The thing you got to realize is that many here make their livings trying to secure systems and we're finding it hopeless. The way you did what you did was fine. In terms of proving the hack you needed to violate Google's trademarks. It's in the very nature of the hack, and as far as I'm concerned, warranted given that they have a bug bounty. Now, I probably would have disclosed it to Google, Bing, etc. ahead of time, but it's your bug. You could have sold it to blackhat scammers and you didn't. For all we know this hack could have been going on for years.

I think most people are confusing their anger at the situation with anger towards you. You're cool.

[specialist]

This was my experience working on election integrity issues.

No good deed goes unpunished.

[dejanseo]

Thank you! :)

[moolcool]

Don't listen to the haters here. The same people upvoted this article 3 days ago, and then promptly forgot about it https://news.ycombinator.com/item?id=17799083

[geofft]

I think you'll find that a lot of people on this site—from lots of political leanings—believe there's a wide gulf between "This behavior is a bad idea and we should use social mechanisms like debate to discourage it" and "This behavior should be illegal and we should point the government's monopoly on violence in your face to make you stop."

The flip side of the defend-to-the-death quote is that caring about someone's right to speak, even caring about that position being well-represented, doesn't mean you have to agree with what they say.

[dejanseo]

The irony...

[winkeltripel]

I believe that you acted ethically, unlike Google. The history API should be locked behind one of those: "RandomSite.com wants to use the History API: Allow / Deny" dialogs, and the TLD and second-level-domain should be clearly marked in browsers, to prevent this sort of https://google.com.search.mydomain.cz schenanigans

[S-E-P]

For what it's worth, I love reading about this stuff, though I specialize in InfoSec so this sort of thing is actually pretty common in our communities.

You would have definitely had a much easier time with them than you are right now.

But for what it's worth, this will blow over soon enough, the internet does not have the greatest memory (unless you actually did something horrendous, which you didn't)

[dejanseo]

I hope so, and I also hope Chrome gets a fix for this.

[brlewis]

I read the article, but still don't get what's Chrome-specific about this vulnerability, or what a good fix would look like.

My reply to someone who proposed making the back button always go to the previous URL: https://news.ycombinator.com/item?id=17826406

[scratchnsniff]

The issue is that some web applications don't load what traditionally were discrete pages (e.g. PAJAX) with their own URLs. It's a trend you'll find in sites built to feel more like applications. Scroll the the bottom of an onion.com article and watch your URL update to the next page without a page refresh. This was done so modern sites built like this could still allow the user to navigate back and forward. It let's the site update the browsers location history and effectively what URL that back button will point to. I could imagine blocking this behavior if it points to a site off the TLD and it's sub domains. Hard pressed to figure out how they could prevent this, definitely a flaw in the trust model but probably worth the trade off.

[brlewis]

I could imagine blocking this behavior if it points to a site off the TLD and it's sub domains

This would not address the vulnerability in the article.

[S-E-P]

Hopefully, but even then, it's good that you are making people more aware of just how sketchy it can get.

Chrome will always have nasty exploits, because it's dealing with the flexibility of the world wide web. It's more important that we the users are aware of the tricks that attackers employ, rather than having clean solutions.

I don't trust that any software is secure, and to date that mindset hasn't burned me yet!

[marichards]

We need experiments like this.

Clinical studies, try to address various factors beyond does the drug technically work, but does it work in practice (coping with people doing everyday things like having dementia, drinking or babies).

We have a flawed obsession with responsible disclosure (that we should mandate includes public disclosure). What we need is a framework for Software Studies that allows any nature of research including in at risk areas and they should answer to ethics committee and regulators, not a disclosure terms of service from the company likely to be put in a bad light.

We need an equivalent to ICH GxP. Drugs have to deal with all the same craziness as software, they're just centuries ahead at how to do it (although they still fail at public disclosure).

Was this study appropriate? Whilst Google corrupts the security integrity of the internet with its Ad and Analytics system, it shouldn't be complaining. For the rest of us, I think we need to pressure for regulation if you want to draw lines and look to the drug industry for inspiration. At the very least we need InfoSec Trials if not the whole suite of Software.

[cryptonector]

Did we not have enough evidence already that this is true??!

[_bxg1]

I'm willing to give you the benefit of the doubt and assume you were just unaware of how things are supposed to be done (reporting exploits to the vendors privately and waiting for the fix before going public), but man, you did a fantastically dangerous thing even if it was unintentional.

I'd never condone beating up on somebody on the internet, but I dearly hope you've learned a valuable lesson here. You've put lots of people in danger of being exploited. It's not about whether or not you'd do anything malicious with it, it's about all the other people who now can because Google doesn't have a fix out there yet.

[rapind]

This is the misconception I can't stand. Where we hold individuals responsible for a product / companies defect. I thoroughly disagree with the idea that it's his fault people are vulnerable.

So called responsible disclosure is just a marketing spin term. Disclosing bugs privately is a favour not a responsibility. All this does is reduce the risk of bad software decisions. It doesn't solve anything.

How about free market instead? If you run a multi-billion dollar company that can be hurt by issues like this, then it's on you to make it more profitable to disclose issues privately. If you can't or refuse to do that, then you're exposing your company and your customers to risk. Enough with the shunning and the "responsibility" of individuals which expose bugs.

[EGreg]

I sympathize with THIS position. It’s the same blame shifting crap when “identity theft” becomes your fault, even though any cashier or clerk can “steal your identity”.

What this marketing spin does is give cover to those who design badly secured systems.

http://www.youtube.com/watch?v=CS9ptA3Ya9E

Also similar is the “jaywalking” idea, made by car manufacturers to make the default right of way to cars!

http://amp.charlotteobserver.com/opinion/op-ed/article650322...

[winkeltripel]

I mean, Google has been told (over and over) for a long time that HTTPS doesn't fix trust on the web being broken, and that the back button shouldn't have an API. These are both well documented security problems. What has happened now is that Google is under public pressure and scrutiny to actually fix these things. A fire has been lit under their bum, and rightly so.

[_bxg1]

I believe they did remove the green lock from https sites to avoid implying trustworthiness. And removing the back button API is something Google can't decide on their own; it has to go through the standards process.

[hermitdev]

> I believe they did remove the green lock from https sites to avoid implying trustworthiness.

Nope. I'm on build 68.0.3440.106, the latest public stable build and as I'm writing this comment, little green lock and "Secure" right next to https://news.ycombinator.com.

[joshuamorton]

Its a process. The green lock will be eventually removed, and instead of the "LOCK Secure" you see now, you'll see nothing, and http-only sites will be "Unsecure". This you can already see if you go to a non-https site like neverssl.com. There's a "Not Secure" banner in white.

[dejanseo]

Trying to be objective and understand my own motivations here. Obviously I didn't do anything out of malice. But yes, I could have told Google directly about the problem, but then I'd have no cool story to publish on my blog. At the end of the day, that's what it boils down to. Now that I got too much attention from it, I regret all of it.

[_bxg1]

"I could have told Google directly about the problem, but then I'd have no cool story to publish on my blog"

First of all, you definitely would. Standard practice is 1) report the bug privately, 2) wait for a fix, 3) get the go-ahead to publish your report and take credit publicly. That's how it always works; that's how security researchers build their reputations and careers. I guess you just weren't aware of that.

Second of all, even if you wouldn't get to publish it, that is horribly selfish reasoning. Putting millions of people at risk of having their information stolen for the sake of a popular blog post?

[C4stor]

I fail to see how dejanseo put the people at risk. Exposing how a tool is dangerous and poorly conceived isn't the same as conceiving a dangerous tool.

In this case, Google put millions of people at risk, and dejanseo actually contributed saving them.

[bdamm]

Right; but sometimes someone is the first to have an idea or realize a vulnerability, even if it seems trivial to them. Once it's public, novelty is no longer a factor, and it is a good idea to allow the vendor a chance to remove that vulnerability before the novelty is clearly eliminated. Obscurity does actually matter in the real world, even though it is a useless design principle.

[geofft]

FWIW, "the padlock is enough" is quite the opposite of Google's position:

https://blog.chromium.org/2018/05/evolving-chromes-security-...

and in fact one of the main reasons is that use of HTTPS is far too little information for the browser to affirmatively indicate "This site is secure and trustworthy." So they are planning to get rid of the padlock. (Use of HTTP is enough for the browser to affirmatively say it's insecure, though.)

So I think Google understands that one of the consequences of pervasive HTTPS is that the padlock is at best meaningless and at worst misleading, as we saw here.

[Ibethewalrus]

I can agree firsthand, people think a site, any site, is safe because of the padlock... :facepalm:

[Klathmon]

So you are implying that HTTPS made this attack easier or more impactful?

I don't buy it. This same attack would work the same with or without HTTPS having existed, and the only reason it wouldn't work as well in practice is because HTTPS is a baseline of security.

It's like saying that airbags cause people to trust unsafe cars. An HTTP only site is a red flag now, but HTTPS just means it won't be instantly considered untrustworthy.

HTTPS has massive benefits, and Google is already starting to "deprecate" the green padlock (IIRCthey have plans for HTTPS to be "normal" with no green padlock and HTTP to be marked as "unsafe").

[palotasb]

There is a similar debate about making wearing bicycle helmets mandatory. [1] One problem is basically that with cyclists wearing helmets, they and drivers around them might think that smaller safety margins are necessary. (Both physically as drivers drive closer to them and e.g., cyclists more likely to drive at unsafe speeds.)

I think the argument here is the same: the green padlock makes people feel too safe. I could easily buy an argument that if HTTPS was not highlighted prominently as a SAFE thing by the browser, people would pay more attention to other indicators such as the domain when browsing the internet.

[1] https://discerningcyclist.com/2018/05/mandatory-bicycle-helm...

[tialaramex]

But as your parent pointed out we _already know_ that padlocks for HTTPS are the wrong UI here. The goal is to get to the right UI, which you can only do after getting to very high HTTPS usage rates, which we've been working on for several years already.

Tim's toy hypertext system from last century doesn't have confidentiality or integrity at all and the authentication mechanisms are garbage (which is why nobody uses them). So adding these necessary features has been a retro-fit for the past 20 years or so, and unfortunately the original attempt at the retro-fit was done by people who knew nothing about security UX. Which is understandable, this was the era when people thought PGP was usable.

So, we have to get from this cul-de-sac we were in 10+ years ago, to the correct approach, which means some U-turns and all the major browser vendors are more or less on board with that. The padlock will go away (at least from the main UI) as part of the journey, but it hasn't gone away yet because we're not finished. Notice that even going as slowly as we have, every time there's an incremental move Hacker News is full of people screaming about how awful this is, they can't be expected to handle this pace of change...

[chmike]

It looks indeed like "The Emperor's New Clothes" story of Anderson [https://en.m.wikipedia.org/wiki/The_Emperor%27s_New_Clothes].

[justaguyhere]

Agreed. Forget a huge, third party like Google, many times (at least in my experience) even our own bosses in small companies wouldn't listen. And even if they did listen, they wouldn't act. Unless of course, it is proven with data and it is big enough to cause them a headache. I'd guess mostly it is due to laziness and not any malicious intent.

[SquareWheel]

>‘That isn’t enough. The padlock on the https page gives users a false sense of security.’

>‘We don’t agree with that. Where’s your data?’

Where is your source that this is Google's position? Considering they have some of the best security employees in the business, I find that hard to believe.

[_gok2]

Allowing sites to intercept browser actions that should make a user leave the site, and inject other operations is obviously and plainly a security issue.

I reported this to google several years ago, and it was never addressed.

[geofft]

Can't you do the same thing without JavaScript, by having the web page go through a brief redirect so the back button takes you to the redirect?

And if so, how do you solve this? Ban server-side redirects? Make the Google SERP iframe all sites it takes you to? I agree this is a problem but I have no idea how to solve it in a way that's not worse.

[SerLava]

Maybe if you visit a page for only two tenths of a second, the back button skips it.

It won't fix the whole problem but it's a start.

[SquareWheel]

>Allowing sites to intercept browser actions that should make a user leave the site, and inject other operations is obviously and plainly a security issue.

Sure, I agree. But what does it have to do with the parent comment's claim?

I've read much of the discussions involving the early push for HTTPS, and the developers involved were very fastidious.

[AndrewKemendo]

The point is that google should be penalizing sites that do that in search results, or at least in chrome with some kind of browser recognition - as the OP states in the article.

[SquareWheel]

They should do more than penalize them in search. They should add them to their malicious site list.

[real-hacker]

Raising awareness is what he want, being called a jerk is the price he has to pay. Defend +1.

[chrisweekly]

FWIW I don't think he acted like a jerk at all. /$.02

[drewmol]

>Google would say: ‘We know, that’s why we are pushing to move everyone to https.’

Am I presuming too much to think Google's primary motivation for pushing HTTPS is to protect their revenue model by preventing their ads from being replaced as opposed to simply being motivated by benevolence?

[_bxg1]

Google has shown time and again that they're open and enthusiastic about receiving properly reported bug reports which give them the chance to fix things before hitting the web. Usually that includes compensation. Why would you think this one would be any different? Maybe this guy just wasn't familiar with proper practice, in which case, well, what can you do. But it's extremely bad to go public with bugs without talking to the vendor first. How many sites might exploit this between the blog post going live and Google rolling out a fix?