Google Takes Its First Steps Toward Killing the URL

OK, but the only thing I want out of AMP is for it to not exist. Is there any chance that I can get involved in AMP's open governance with a "stop existing" goal?

It is already quite surprising that AMP has gone in the direction of "We'll accept signed webpackages and publish those so we aren't acting as the origin". But my goal is that even this should not need to exist: websites that genuinely load fast on their own, comparable to downloading the webpackage, should be ranked as high as AMP websites. And it's preferable for websites to do that. So there should be no boost for AMP websites, just a boost for fast pages, and if AMP does anything it should just provide guidelines for how to build fast pages. Examples of fast pages include HN and most things published before 1998.

At the end of the day AMP exists because it's privileged by Google Search, and AMP is privileged by Google Search because Malte Ubl has whatever amount of influence he does within Google and has convinced them that AMP is a good idea (or other people have decided it's a good idea and have put Malte Ubl in charge of making sure it happens, or whatever). No matter how many non-Google people you put on the steering committee you won't change that. You don't have the internal access to change Google's mind about it.

This is like saying that it's okay that I should be happy living in a city that always votes $party because I can get involved in the party. If my personal political views are $opposing_party, that statement is technically true but completely useless.

Who are the actual decision makers? What percentage are google employees?

The reality is the "open governance" AMP spec means nothing, because as a monopoly, the only AMP cache which actually matters is Google's. And it's implementation is Google's proprietary business, not part of what they allegedly allow open governance of.

I won't believe this until I see the tech lead and the committee go from being totally opaque to actually answering direct questions.

So far "after months of research" they can't even provide a description of how working groups are selected, which are the criteria, what exactly they govern and many other things described, e.g. here: https://github.com/ampproject/meta/pull/1#pullrequestreview-...

Or, e.g. they are going to have an AMP4Email working group. For a feature that no one asked for, no one wants, no one was discussed with. How did it get there? Oh "Gmail team said they are going to do it". But yeah, the "Approvers" working group will surely have something to say about this. Riiiight.

People get used to anything. Their failure to realize what they are missing is not a good measure how much they are missing. Indeed, the people who are most able to assess the cost of the new compared to the old are exactly the old timers who have experienced both, not the new comers who haven't.

Hiding the URL is like blocking out the windshield and telling the user to trust the GPS.

Seatbelts in Europe are required by law, in Brasil it's possible that there are no seatbelts because it's cheaper.

Seatbelts make it safer unregarding your driving skill. As an experienced développer, I want to see the URL. I want to copy the original one.

URL's are useful outside security. That's why it's one of the SEO variables.

It's a bad analogy

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"?

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.

So I search on Google or eBay, find a product number, run a search in Amazon. Until a few years ago, that resulted in a cheaper price but now more often than not, Amazon is not the cheapest (even accounting for shipping); and increasingly they are no longer the fastest either.

But you're using a knife daily, so I presume you know what is dangerous about a knife, (not how to make one!), or say you use a credit card. Should you not have at least a vague idea of the concept before you use it responsibly? That's all am asking for.

Well... yes? Don't you?

Most of that is taught in schools, and I feel one can reasonably expect an adult to have some cursory knowledge about all of the above - enough to at least reason about the basics and to know when to hand a problem off to a professional.

You don't have a cursory knowledge of everything you use/own and believe it's alright?

Do you know you shouldn't cut your electric wire while having them plugged in?

Do you know you shouldn't put your finger under the knife while you are cutting carrots?

Do you know you shouldn't put metal into your microwave?

You do have cursory knowledge about the tools in your house. You give an absurd list of example in your comment, but theses aren't the tool in your house, they are completely different field that sure are required to give you the tools/food you have, but they aren't part of any of your tool-set required to live. I fully expect someone that use a fountains pens to know how to change its ink cartridge, just like I fully expect a plumber to know how to use a wrench safely and a web user to know how to safely navigate the web.

Sure the tools can be made safer and better, but that doesn't means to remove actual feature from it. You wouldn't make the wrench out of rubber because the metal is too hard and can hurt someone, you expect the wrench user to know it or to teach him if required.

The problem, of course, is that this trains us to be incapable, and leaves us incapacitated if anything goes wrong. If my rental car breaks down I have no idea what to do except ring the rental company and hope they can send someone to fix it. Likewise, if Google's filter makes a mistake (which it will) then the user has no ability to make any kind of decision on their own. They'll click on the fake bank, lose all their money, and whose responsibility will that be? Google won't pay them back - they just provided a free tool. The bank will want to shift responsibility ("you must have done something unsafe, Google stops all phishing attempts, so you must have told them your login details"). The net result is that while most people will be safer, some people will be in a worse position than they are now.

It doesn't solve any problems for anyone, it just makes us helpless if there is a problem.

Among other things, that means posting with respect for fellow users, regardless of how wrong you think they are.

https://news.ycombinator.com/newsguidelines.html