Comment by boomlinde | Hacker News Reader

Comment by boomlinde | Hacker News Reader

Parent Full thread

> Hardhats aren't just for clumsy people, seatbelts aren't just for bad drivers, and memory protection isn't just for careless programmers. There's no shame in engineering a situation to maximize safety for the people who will use it.

There's an inherent bias in the choice of analogy. There are many potential metaphors that aren't as favorable as hardhats or seat belts. How about a leash or blinders?

> There's a whole lot of smart people who like static typing for the safety benefits it brings to their programming. Web browsers are the front lines: where one click on a stringly-typed reference can cause unknown third-party code to run on your computer.

URIs have a rather well defined type and you can easily detect a malformed URI. The problem Google seems to intend to address, and the way they intend to address it, has nothing to do with the type of the URI but ultimately how its value should be conveyed and heuristic restrictions on what forms the values may take. This leads to situations where valid URIs are treated as invalid, based on arbitrary heuristics, not a tightening of the type of value a URI encodes.

The more apparent problem, from your description, seems to be that websites can at all use your computer to execute arbitrary third-party code. Addressing this by vaguely limiting what URIs you may access is a weird way not to take the bull by the horns. To somehow hide information that is part of the URI to make it more clear what resource the URI represent is just ass-backwards.

> URIs have a rather well defined type and you can easily detect a malformed URI.

The average internet user is unlikely to be able to detect a malicious URL. Do you think the average person can tell which of these URLs is legitimate, and owned by Example inc.?

- example.com/profiles/al

- example.com.profiles.al

- examp1e.com/profiles/al

- example.co/profiles/al

etc etc.

Safari already only shows the hostname to help with visual identification - this doesn't help with different-but-similar hosts, but it does help regular users to see what website they're on, if they are unfamiliar with the protocol/host/path structure of URLs. Which they shouldn't have to be.

I'm not trying to be BOFH here... but it's not unreasonable to expect web users to have the same basic knowledge of a URL that they have for a telephone number. Most(perhaps nearly all?) of telephone users in the US know that in 123-456-7890, the "123" is an area code, "456" is an exchange, and "7890" is the line number. URLs are not that different. A similar knowledge of URLs would serve users well.

It would, but the web is a mass-market project - while it would be nice if everyone understood how to read a URL, we should cater to the lowest (within reason) common denominator - especially when it comes to security.

The threat model for phone numbers is considerably different, not least due to the link-based nature of the web and email. The URL takes on the role of both the number and the caller ID (if caller ID didn't suck) - you should be able to be confident that you're talking to who you think you're talking to.

It's not really about the structure of the URL it's there's not a good way for someone to know what URL goes with an IRL identity.

What's the URL for Valve's Steam?

* steam.com

* valve.com

* steamgames.net

* store.steampowdered.com

* steampowered.com

If you guessed none of them except for steampowered.com, congrats!

What's the URL for Americal Eagle, the clothing store?

* americaneagle.com

* americaneagleoutfitters.com

* aeo.com

* ae.com

* aerie.com

If you guesses all of them except americaneagle.com congrats!

You're right, my phone number comment really didn't add up after I read your response. I can't think of a good solution for your example, even something as well known as Steam or American Eagle falls apart when the average person is presented with multiple choices. Short of spending loads of $$$ buying every domain similar to your company name, I don't see any good solutions. Sad state of affairs :(

This is an abuse issue at the DNS level, not a problem suitable for end user cosmetic witchery in the browser. Fix DNS abuse.

I disagree that what Safari is doing is good for the user. Safari used to show https://stripe.ian.sh/ as "Stripe, Inc". By hiding the URL, it significantly increased the phishing potential of the website. Feel free to visit the above false stripe site, its not malicious and has a great write up in the issue. In this case they are putting a lot of blame on EV Certificates - which I agree causes more harm then good - but Safari's decision to cover up the URL made the issue significantly worse.

that is unrelated to the "hide the path" functionality - as you pointed out, it's because they displayed the EV name instead of the URL. That's a separate, and much more harmful, UI choice - because EV certificates are poor evidence of association.

> The average internet user is unlikely to be able to detect a malicious URL. Do you think the average person can tell which of these URLs is legitimate, and owned by Example inc.?

I think you are missing my point of that statement, which is that this is not a problem with the type of the URI, and that there is no basis for the idea that "If you advocate for type safety within software, you should also advocate for a better system than URIs."

Either way, to answer your question, no one can tell which of those URLs are legitimate without Example Inc. first communicating their official address to them.

> Safari already only shows the hostname to help with visual identification - this doesn't help with different-but-similar hosts, but it does help regular users to see what website they're on, if they are unfamiliar with the protocol/host/path structure of URLs. Which they shouldn't have to be.

I'm against the idea that a user shouldn't need to know what they are doing on such a fundamental level. This is an attitude that people tend to have towards software and computers in general that doesn't really exist for other useful-but-dangerous technology with mass appeal like cars. It promotes magical thinking which I think may leave the users even less aware of the risks than they already are. Risks that don't somehow stop existing because you hide trivial information from the user. If properly educating people in using these systems is not an option, maybe letting them touch the hot stove isn't such a bad thing.

When you try to water some information embedded in an URI down for the dumbest user, you invariably hide or even misrepresent information. Safari only displaying host names is a great example of this, but another favorite of mine is how Chrome displays "Secure" in the address bar to indicate HTTPS with a verified certificate. In reality, it is of course only a very limited sense in which anything I do at that address is secure. A sense which the user that this was watered down for most likely won't recognize, instead being instilled with a false sense of security. By all means, color code the different parts of the URI, add tool tips or whatever, but don't hide what's actually there from someone that has every reason to care.

When some user on example.com starts impersonating Al, how does Safari hiding everything but the domain help the user differentiate "example.com/profiles/al" from "example.com/profiles/fakeal"?

> There's an inherent bias in the choice of analogy. There are many potential metaphors that aren't as favorable as hardhats or seat belts. How about a leash or blinders?

A leash and blinders are put on an animal which is not free, to control it. But nobody is proposing removing your freedom to use any web browser you want. In what way is that metaphor applicable?

> The problem Google seems to intend to address, and the way they intend to address it, has nothing to do with the type of the URI but ultimately how its value should be conveyed and heuristic restrictions on what forms the values may take.

I suppose it depends on how one defines "type". I'm not just thinking of the "java.lang.String" level, but the broader level of anything that can be checked by a compiler, without evaluating it.

Consider the basic problem of navigating a link. We get a big stream of bytes from the network. It's pretty easy for the computer to identify URIs in it, by the syntax of HTML and CSS and URIs themselves. It's not an easy problem for humans -- I wouldn't trust myself to always accurately identify URIs in an arbitrary buffer! It's hard to tell what's a valid URI, or where (say) the URI ends and a color or some raw text begins. That's a type problem, and humans are bad at it.

This project sounds like the next level beyond that. My computer can already parse the stream and analyze it to find the URI, and automatically paste it in my URL bar when I click near it. Nifty. But "URI" is a richly structured type (just look at the URI class in your favorite programming language), and the browser can do far more with it, even just at the UX level, than simply treating it as an opaque string.

> The more apparent problem, from your description, seems to be that websites can at all use your computer to execute arbitrary third-party code.

No, sorry if that was misleading. I was not presenting it as the problem that this team at Google aims to solve, but as an example of the security issues at stake. Just as seatbelts aren't the only safety feature keeping my face intact on the highway, a sandbox shouldn't be the only safety feature keeping my disk intact on the internet.

What's the difference between viewing the source of some malicious code, and running that malicious code? Only the type system: it's in a SCRIPT tag, or a PRE tag. What's the difference between seeing a malicious link, and following that malicious link? Pretty much the same thing.

> A leash and blinders are put on an animal which is not free, to control it. But nobody is proposing removing your freedom to use any web browser you want. In what way is that metaphor applicable?

As I said, there is an inherent bias in the choice of analogy. The ones I present are just as vague and useless as yours and present an opposite bias.

> I suppose it depends on how one defines "type". I'm not just thinking of the "java.lang.String" level, but the broader level of anything that can be checked by a compiler, without evaluating it.

How did I give you the impression that this is the level I was addressing it on? URIs have a much more restrictive type than simply a sequence of characters.

> Consider the basic problem of navigating a link. We get a big stream of bytes from the network. It's pretty easy for the computer to identify URIs in it, by the syntax of HTML and CSS and URIs themselves. It's not an easy problem for humans -- I wouldn't trust myself to always accurately identify URIs in an arbitrary buffer! It's hard to tell what's a valid URI, or where (say) the URI ends and a color or some raw text begins. That's a type problem, and humans are bad at it.

It's an easy job for the browser simply not to accept malformed URIs. Unfortunately, browsers like Chromium deliberately accept entirely malformed URIs and even interpret valid URIs the wrong way. IMO that would be a good place to start looking if you had a genuine interest in improving security.

> This project sounds like the next level beyond that. My computer can already parse the stream and analyze it to find the URI, and automatically paste it in my URL bar when I click near it. Nifty. But "URI" is a richly structured type (just look at the URI class in your favorite programming language), and the browser can do far more with it, even just at the UX level, than simply treating it as an opaque string.

Yes, because it is well defined what a URI consists of this is easy. Chromium already does to color highlight the different parts of the URI.

> What's the difference between viewing the source of some malicious code, and running that malicious code? Only the type system: it's in a SCRIPT tag, or a PRE tag. What's the difference between seeing a malicious link, and following that malicious link? Pretty much the same thing.

So what is Google doing to address this that has anything to do with the type of URIs? Absolutely nothing.

Reply on news.ycombinator.com