Hacker News Reader

I agree that this experiment isn't demonstrating a perfect mitigation, but it's important to appreciate that it's currently vastly easier for a phisher to permute paths and subdomain components than it is to create a convincing ETLD+1. There are various reasons for this, including less text for a phisher to work with and registration requirements for ETLD+1 domains (which means they can't be iterated and dumped as quickly, and domain owners may have a more immediate legal recourse against phishers). That's the point of experimenting on features like this, to get an idea of whether or not the they would be beneficial.

What about doing something more like this: https://twitter.com/aripalo/status/462942544007929857

The issue isn't users recognizing path, it's the domain. It's also that they aren't taking special care while logging in.

Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on a login page.

On the whole, supporting secure logins would be better for the internet.

The problem with that is you can't detect all login forms. If you cannot detect all of them, there's a way to hide them from the browser.

> What about doing something more like this: https://twitter.com/aripalo/status/462942544007929857

The team may choose to do something like that in the end. That's really the point of experimenting with different approaches; they use them to get feedback, run user studies, and get a sense of what works best.

> Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on a login page.

That's actually very, very hard (as in np-hard). Chrome has heuristics for detecting login pages, but it doesn't even detect all legitimate login pages. And it's trivial for a phisher to intentionally make a page that appears exactly like a login page to the user, but will not be detected by Chrome's heuristics.

> That's actually very, very hard (as in np-hard). Chrome has heuristics for detecting login pages, but it doesn't even detect all legitimate login pages. And it's trivial for a phisher to intentionally make a page that appears exactly like a login page to the user, but will not be detected by Chrome's heuristics.

Well, it wouldn't have to detect all login pages, it could just detect most of them. That would add soft pressure to encourage regular websites to use HTTPS in the vein of

https://www.eff.org/https-everywhere

Hopefully we can push the web towards https everywhere, and users begin to ask the question -- "Why is this page not secure" when performing a login.

This soft pressure worked wonders in a number of places: When Google started doing sitelinks, many websites became much more concerned about making those available on their website. In a similar way, hopefully they would be concerned with getting out of the red for their login pages.

It's not even NP-hard, because it's not well-defined and thus isn't even a decision problem.

You could detect forms that have more than one user provided input field as they are submitted. This wouldn't detect most search boxes or forms that use hidden inputs to transmit values to the backend.

But `input[type="password"]` would cover the majority of login forms. At the least, it would force the con-artist have to mimic a native password box, which is more likely to get caught by the end-user.

Yes. Anything that doesn't use a password field is normally a giant hack anyway.

So facebook's mobile login page wouldn't trigger, for example.

It's not as simple as peolpe think of it. It never is.

> Additionally, what about addressing insecure forms that fail to utilize https.

FWIW, Firefox detects insecure login forms and emits a security warning to the web console. This is aimed at developers, however, not users (because the developers are the only ones who can improve the situation).

Our heuristic is imperfect as well. We simply detect <input type="password"> fields on http pages. This works well enough. Trying to detect when developers are abusing <input type="text"> for a password field is non-trivial.

How long has Firefox been logging security warnings (in the web console) for insecure login forms? Do you know of telemetry about how prevalent the problem is or whether the security warnings have helped? I assume, for compatibility, Firefox will never be able to simply reject insecure login forms.

It looks like it's been around half a years¹. There's also a reference to the Chromium bug² for implementing the same there.

There's also mixed content blocking³ which is a similar but user facing feature.

1: https://bugzilla.mozilla.org/show_bug.cgi?id=762593

2: https://code.google.com/p/chromium/issues/detail?id=327032

3: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-bloc...

I'd say that is the best solution, possibly with more work done on the certificate button left of the url. The button currently highlights “good“ sites: https with an Extended Validation certificate. It should be the other way around. Highlight as warning when the site falls short: no SSL or SSL without EV.

I really like that. Preserves all the benefits of hiding the path entirely without... hiding the path entirely. However, how would the browser tell the difference between editing the path and entering an entirely new url or search? It wouldn't be intuitive if you have to click the domain chip to go to a different site. Most of the time a user is going to click the path area in that screenshot, since that's what we're used to. But then, how do you edit just the path?

One solution would be that if you click any part of the url and you get fully editable text so you can change the domain or any part of the path.

I don't know if such a thing already exists, but perhaps a way for a user to define 'secure urls' that go to their bank (or other important site) would be useful. Chrome could then warn when a user goes to a site that looks too similar.

There is more that can be productively argued about this topic, at least for parties who decide to not insist otherwise. URLs won't go away as long as people are still sharing websites on social networks or their own websites. I don't see the problem with not displaying the entire URL at the top of the browser window, if no actual functionality it lost. I this case, there's not even any additional clicks required to perform the same operations with URLs.

I agree with the possibility for productive debate, my comment is probably a bit too cynical. I just see a lot of redundant arguments, bad analogies and strawmen coming up soon and jumped the gun.

Came here to say similar. In addition I dont see any problem. The URL bar is a redundant usability smell. Needs to be cleaned up in the fashion they have.

On security, I feel its a problem sure, but teaching users about URLs is a bandaid fix, a hack and completely irrelevant to this change. You can't fix the phishing problem by showing URLs. It needs to be tackled in the proper manner and solved silently from the user.

Google already does the right thing when you use them for DNS (redirects on mispelt). They also implemented blacklists of dodgy content, not ideal and doesn't scale but its a good start. Better than claiming the user is at fault.

Basically if you need to claim the user is at fault your design is wrong whether you like it or not.

Well, if www and .com become meaningless then advertisers will use "type xxx yyy into you bar" instead (which goes to the search engine) or hash tags (already doing this). Then Google could come up with "associate permanent keywords with your URL" (for a small fee of course) to guarantee that those keywords won't shift under you when your Google ranking changes.

I already see this happening in Japan. Rarely do I see ads include URLs, they have a search term.

Which IMO is a smart idea. URLs are too often hard to remember and/or type correctly if not too long anyway.

Until a competitor's SEO outranks your site for those keywords or buys similar Google AdWords.

Those keywords are not supposed to live long: they are used as part of marketing campaigns. But your comment is still valid. Such a strategy would be very risky in the long term.

Agreed. It also solves another problem in Japan, namely that brand names etc are usually written in Japanese letters, but URLs in ASCII (yes, I'm aware of IDN, but haven't ever seen it used). This is obviously not limited to Japan, I wouldn't be surprised if other countries used the same trick.

That's sort of been happening in the UK. Instead of some companies giving out a URL, they'll just say "Search xyz for more information"

Aren't Google AdWords effectively "stable keywords for sale" today?

Good summary, basically the inter web linking will become:

google://keyword

or better

google keyword

or even simply

keyword

Reminds me of AOL

no it wouldn't. You might put that in an ad (and as people above note, this is already happening), but this only changes what's displayed in the location bar. It would be stupid to link to another site through a web search when you can just link to the site.

although, I'll note that once again, the internet is already on the case. The link you were looking for was http://lmgtfy.com/?q=keyword

We've seen this before:

http://www.musicman.com/00pic/credits.jpg

Great link... Seeing people communicate "google yourbank" and address bar becoming a search box, I thought href could be extended as an innovative technology to allow intermediated linking through a search engine.. (or Url shorteners with keywords)... But AOL already had it...

Hah! "Edwaed Burns"

I've already experienced this with a vendor who sends me links to his own site as parameters of a Google search.

e.g. google.com/search?q=http%3A%2F%2Fexample.com%2Fdemo3.html

I don't even know how he generates those URLs and he didn't respond when I asked why he does it.

He probably searches for his website, and then copy the link directly from the google page, rather than jumping into his page and copying the URL.

> but creates an entire class of users that don't understand what a URL is.

Most people have little idea what an URL is, nor how to use an address bar.

Watch a few people navigating to http://www.example.com/example.html to see what they do.

I personally have never understood the huge sums of money paid by some people for some URLs. I can't remember URLs; I can't remember keywords. What I can remember is some fragment of a page title, and I hope that's enough to find it in my bookmarks or in a websearch.

I wish Google would just release some numbers about the numbers of people who get this stuff wrong, because learning how many people use (correctly) the + operator made that change much easier to cope with.

>There is nothing more that can be productively argued about this topic.

Is that ever a good thing to say?

The change is good. I never saw any mention of people disliking this in Mobile Safari, and it's an option power users will turn off. There's plenty of them already.