Chrome 69: “www.” subdomain missing from URL • Hacker News Board

Re: Chrome 69: “www.” subdomain missing from URL

#841

Post by webXL » Fri, Sep 07, 2018, 4:42 PM UTC

This should have been an opt-in feature. And if enough people opted in, only then do you make it the default, and when you do that, alert all users to that change.

Hiding the protocol was understandable. For web pages it was 99% http or https, and they could convey which with an icon. (iOS Chrome still shows it for some strange reason). Then mobile Safari dropped everything but the domain name and everyone freaked out. But you can get everything back in Safari by clicking on it, but not on Chrome. Such a simple thing to implement.

If anything they could have just hid the query string, unless it's fairly simple like HN comments pages (item?id=17927972). But with pushstate, you could just hide the ugly bits (tracking, language, etc.) from the user. Take this Chrome promo URL:

  https://www.google.com/chrome/whatsnew/?hl=en&brand=CHZQ&utm_source=google.com&utm_medium=homepagepromo&utm_campaign=m69-whatsnew

Using JavaScript, before anything is displayed, simplify it to:

  www.google.com/chrome/whatsnew

And if you don't like www., don't host at or link to that subdomain!

Re: Chrome 69: “www.” subdomain missing from URL

#842

Post by jwr » Fri, Sep 07, 2018, 5:00 PM UTC

soared wrote: post #60

jwr wrote: post #30

This is idiotic and harmful. We already lost information about the protocol, because somebody believed it is "too complex" for users. Now we're losing other parts of the URL. It's making a joke of the SSL/TLS padlock, too — what exactly is the padlock supposed to tell me? It used to signify that a "known authority" certified that I'm connected to whatever I see in the URL bar. But now that browsers take liberties wit…

99.9% of users have no idea what any of the words you just said mean. The change was made for them, not for you (the .1%)

Anytime the "average user" or numbers like "99.9% of users" are mentioned, red lights should go off. These kinds of claims are condescending, often untrue, and rarely based on facts.

Re: Chrome 69: “www.” subdomain missing from URL

#843

Post by ourcat » Fri, Sep 07, 2018, 5:01 PM UTC

Crikey. Looking at the various tests done by people on that thread highlights some pretty amateur string logic by whoever implemented it.

Re: Chrome 69: “www.” subdomain missing from URL

#844

Post by baby » Fri, Sep 07, 2018, 5:01 PM UTC

martimarkov wrote: post #763

baby wrote: post #746

Earlier quoted context omitted.

This is what Chrome's update is trying to fix. Developers are confuser when setting up dns if they should have www or not have www or only have www...

Not really fixing it thou because they just strip the www part from the name. If the developer does not setup www.domain.com and the user goes there chrome will not “fix” anything. I haven’t tested it but it will most likely show up as domain.com in the address bar and will result in an error show to the customer. If chrome wants to strip www as it’s essentially the same domain.com they can submit an RFC and not just…

> If the developer does not setup www.domain.com and the user goes there chrome will not “fix” anything

Yup, that's on the developers. Hopefully this fix will make it so that it will be easier to setup DNS with just one domain instead of 2. Props to Chrome.

Re: Chrome 69: “www.” subdomain missing from URL

#845

Post by ergothus » Fri, Sep 07, 2018, 5:01 PM UTC

sofaofthedamned wrote: post #537

ergothus wrote: post #527

Earlier quoted context omitted.

"www" was not a marketing trick, it was legitimately a different domain, by convention. General users never understood it, so companies started to have to add it to match their weird expectations. To associate a base domain with a company identity happens to be true MOST of the time, but isnt actually true. Plus, foo.example.com follows different security rules than bar.example.com (CORS, certs, etc) The problem here…

There was never a requirement for www. to be anything other than the bare domain for most people. It became useful because it was synonymous with being a web thing right back when people hardly knew what the web was. This was serendipity, which turned out not to be serendipitous when people had to write it on signs / read it out on an advert etc. I see no reason now to associate www. with the web version of your serv…

> It became useful because it was synonymous with being a web thing right back when people hardly knew what the web was

You're missing some history here (or we're talking past one another) Back then ( source: lived through it) subdomains for particular protocols were pretty common (www.example.com, ftp.example.com, gopher.example.com, mail.example.com) were pretty common, though not a requirement at all. Almost all the users were technical, so this helped users AND admins. Plus, machines were FAR less powerful back then, so anything exposed to the "public" probably didn't want to handle multiple purposes anyway.

Then non-technical users came in, saw "www.example.com" being used many places, and assumed it was part of the system. New domains either created a "www" subdomain or lost traffic (until browsers started trying to compensate). Note that what we're discussing is a switch in behavior. Prior to what the article is discussing, a browser would try the domain as typed, and if it failed would try prepending "www" AND ADD IT.

> I see no reason now to associate www. with the web version of your service

First, you still have people that type the "www" automatically because they never learned that was technically incorrect.

Second, what if you're reselling subdomains? The concept of "base domain == identity" is relatively recent and possibly temporary.

Third, what if you don't HAVE a single "web version of your service"?

The internet (and the web) has succeeded (granted, half by accident) by providing loose rules so practices can evolve inside those rules. If we start encoding the current practices in the rules, the rules no longer handle evolution well (or possibly at all).

I'm splitting hairs because hairs sometimes matter.

Re: Chrome 69: “www.” subdomain missing from URL

#846

Post by jwr » Fri, Sep 07, 2018, 5:05 PM UTC

RadioactiveMan wrote: post #45

jwr wrote: post #30

This is idiotic and harmful. We already lost information about the protocol, because somebody believed it is "too complex" for users. Now we're losing other parts of the URL. It's making a joke of the SSL/TLS padlock, too — what exactly is the padlock supposed to tell me? It used to signify that a "known authority" certified that I'm connected to whatever I see in the URL bar. But now that browsers take liberties wit…

The padlock was already meaningless.

No, the padlock means that you are likely connected to the website that the URL bar shows you. This is useful and should not be discarded because of condescending ideas about "average users". It also has the advantage of being easy to explain.

Some people assign additional meaning to the padlock, which should not be done. It doesn't mean you are talking to your bank, it only means that you are talking to the website shown in the URL bar and that reasonable (simple) checks were performed to make sure that is the case.

I'd suggest we invent something better before we start breaking it.

Re: Chrome 69: “www.” subdomain missing from URL

#847

Post by wstuartcl » Fri, Sep 07, 2018, 5:14 PM UTC

mrec wrote: post #582

masswerk wrote: post #575

Earlier quoted context omitted.

We might even call it "favicon", for the fun of it… :-)

Not sure if serious, but no. Anyone can copy a favicon; the point of an identicon is that it's generated from the domain name, so subverting it would require an attacker to find a hash collision with a visually similar domain.

Yeah, cause moving from a text domain with no collision possible to some sort of collision prone visual system to ensure are able to understand the domain they are viewing seems like a great idea.

FFS, if users cant see that somedomainname.com is different than somedomanname.com how does a randomized image of the domain name based on a hash solve this.

Re: Chrome 69: “www.” subdomain missing from URL

#848

Post by krn » Fri, Sep 07, 2018, 5:39 PM UTC

Ajedi32 wrote: post #836

krn wrote: post #821

Earlier quoted context omitted.

No, this Chrome update is about hiding the "amp." subdomain from the original URL. What Google wants to achieve, is to make it impossible for the average user to tell when the entire website is being served from Google Cache.

Google cache links aren't served from `amp.yoursite.com`, they're served from `cdn.ampproject.org`. If you're visiting `amp.yoursite.com`, then the site _isn't_ being served from the Google cache. Also "this Chrome update is about hiding the "amp." subdomain on the original site from the viewer" is patently false since this update _doesn't_ hide `amp.`; only `m.` and `www.`.

> Google cache links aren't served from `amp.yoursite.com`

That's not where things are going, according to your own source from the previous comment:

> Our approach uses one component of the emerging Web Packaging technologies—technologies that also support a range of other use cases. This component allows a publisher to sign an HTTP exchange (a request/response pair), which then allows a caching server to do the work of actually delivering that exchange to a browser. When the browser loads this “Signed Exchange”, it can show the original publisher’s web origin in the browser address bar because it can prove similar integrity and authenticity properties as a regular HTTPS connection.

So, the content will be served from Google Cache with the original publisher's URL in the address bar.

> this update _doesn't_ hide `amp.`; only `m.` and `www.`

It's Google, who decides what and when it wants to add to its browser's list of "trivial subdomains". Especially, when the websites with "amp." subdomains will become common.

Re: Chrome 69: “www.” subdomain missing from URL

#849

Post by Ajedi32 » Fri, Sep 07, 2018, 5:50 PM UTC

krn wrote: post #848

Ajedi32 wrote: post #836

Earlier quoted context omitted.

Google cache links aren't served from `amp.yoursite.com`, they're served from `cdn.ampproject.org`. If you're visiting `amp.yoursite.com`, then the site _isn't_ being served from the Google cache. Also "this Chrome update is about hiding the "amp." subdomain on the original site from the viewer" is patently false since this update _doesn't_ hide `amp.`; only `m.` and `www.`.

> Google cache links aren't served from `amp.yoursite.com` That's not where things are going, according to your own source from the previous comment: > Our approach uses one component of the emerging Web Packaging technologies—technologies that also support a range of other use cases. This component allows a publisher to sign an HTTP exchange (a request/response pair), which then allows a caching server to do the wor…

Yes, once the Web Package Standard is finalized and implemented then AMP pages will indeed use the normal `amp.` URLs.

But at that point, what would be your concern with hiding `amp.`? That's no worse than hiding `m.`; it's just another subdomain which serves a different version of the same content. Heck, sites could serve their amp pages on `m.` domains if they wanted to; the actual subdomain they decide to use is irrelevant.

Re: Chrome 69: “www.” subdomain missing from URL

#850

Post by philwelch » Fri, Sep 07, 2018, 6:04 PM UTC

TheSpiceIsLife wrote: post #728

philwelch wrote: post #634

Earlier quoted context omitted.

It's not about knowing how many spark plugs are in their car. It's more about buying a car that comes with a custom power adapter plugged into the cigarette lighter, never realizing that you can plug your own accessories into the cigarette lighter instead of buying your phone charger or GPS from the car company, and then not caring when they just take away the cigarette lighter and replace it with their own custom po…

Since we know all analogies breakdown under close inspection, I'm pushing the idea that the best analogy is actually a brief description of the event / idea itself. So in this case: Not display www. in the address bar is actually a whole lot like not display www. in the address bar .

And if anyone doesn't understand why that is a bad idea, maybe we should explain it to them, which might require using admittedly imperfect analogies that they can nonetheless understand.