Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome 69: “www.” subdomain missing from URL

bugs.chromium.org

Post reply on HN
Print view View original

781–790 of 919 posts

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

#781

Post by untog »

sam_goody wrote: post #741

Most comments assume that this is for solving user confusion, or security, or building a better URL scheme, et al. It's not, that is all smokescreen. As ivs wrote[1] They are going to hide amp subdomain, so you don't know if you're looking at AMP or the actual destination. And then suddenly the whole world funnels through AMP. And for that reason, it won't be reversed until people call them for what they are actually…

AMP pages are served through google.com, though? It's one of the big problems with them.

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

#782

Post by EvanAnderson »

hiram112 wrote: post #714
brodo wrote: post #700

Earlier quoted context omitted.

I don’t know anything about AD, so this might be a stupid question: can you not just run a web server on the same host as the AD server or port forward all HTTP traffic to a different server?

From the two comments above, it sounds like yes, some people who named their AD the same as their root DNS zone now have to run Http forwarders. And the other comment mentioned that this was a known issue 20 years ago because the old versions of IIS did not support redirecting.

We beat this to death on Serverfault.com 9 years ago, so I'll spare all the rehashing here: https://serverfault.com/questions/76715/windows-active-direc...

Having a disjoint DNS namespace (and the needless make-work that it creates) is the issue, more than running HTTP servers on all your DCs to do redirects. There is absolutely no practical advantage to running an Active Directory domain with a public DNS name. It's all downside. It has always been all downside, and anybody who had any experience with DNS could see that all the way back in the beta and RC releases of the product in 1999 and 2000.

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

#783

Post by kwk1 »

saintPirelli wrote: post #724
rckclmbr wrote: post #259

Earlier quoted context omitted.

I switched to firefox a year ago. Its a little slower, but im a lot happier. Ive been trying to degoogle as much as reasonable. I moved to fastmail as well. Still using an android, but would switch if a reasonable alternative that wasnt iphone came up. Im not paranoid or a privacy nut, just think google is too involved in my life.

Same here. Have you found any viable alternative to the Google Calendar? I'm at the point where I'm thinking about hosting a calendar project from GitHub myself.

Nextcloud, whether self-hosted or otherwise, works great! It's just WebDAV. You can get calendar, contacts, task, and note syncing, and it can even host your documents for reference management software like Zotero.

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

#784

Post by schiffern »

Yokohiii wrote: post #735
crazygringo wrote: post #356

Safari already hides "www.". In fact it hides everything except the root-level domain, e.g. " https://www.google.com/about/" shows just "[lock] google.com". Firefox and Opera show the full domain but gray out everything in the entire URL except the root-level domain, so "www." is gray. Just saying, de-emphasizing and hiding parts of the URL is clearly a trend. This isn't just a Google thing.

There is quite a bit confusion how it actually works, nobody seems to had a look at it. Chrome simply hides the subdomain if the url bar is not in edit mode, these parts are still accessible/editable and the http host behaves (and is recovered from history) as before. Copying the url works as expected. It is still confusing for tech people, because we often need awareness where we are.

>Chrome simply hides the subdomain if the url bar is not in edit mode

Not so. You have to click the Omnibox twice.[1] Clicking on the Omnibox once puts you in a completely new state, "edit mode [with corrupted URL]," and clicking on the Omnibox again puts you in "edit mode [with correct URL]."

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=881410...

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

#786

Post by pluma »

Tharkun wrote: post #751
ozfive wrote: post #43

This and many other changes over a course of a short period of time have caused me to go to Firefox exclusively now. I heard Firefox is going to stop third party cookie tracking altogether. Why not give Google the big finger and use a different browser? Vote with your cold hard actions if you feel so strongly about something.

Firefox does similar things though. They hide the URL scheme by default. And subdomain are displayed in a more subtle colour than the rest of the domain.

Firefox hides the scheme IFF it is `http://`. It doesn't hide `https://`. Also the subdomain AND the path is slightly toned down. The net effect is precisely what Google tries to do and Apple has been doing (namely, only showing the second level domain) without actually hiding any information.

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

#788

Post by krn »

sam_goody wrote: post #741

Most comments assume that this is for solving user confusion, or security, or building a better URL scheme, et al. It's not, that is all smokescreen. As ivs wrote[1] They are going to hide amp subdomain, so you don't know if you're looking at AMP or the actual destination. And then suddenly the whole world funnels through AMP. And for that reason, it won't be reversed until people call them for what they are actually…

This should be the top comment. After this change, we are just one step away from using the browser's address bar only as a Google search box, and Google as the entire internet's gatekeeper. Google doesn't make money when you type the URL into your browser's address bar – it makes when you don't.

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

#789

Post by lucideer »

Even if you believe this is in theory a good idea, in practice it's clear that Chrome has implemented this extremely badly.

As Comment 5 on that issue points out:

> This does appear to be inconsistent/improperly implemented. Why is www hidden twice if the domain is "www.www.2ld.tld"? [...] If the root zone is a 301 to the "www" version, removing "www" from the omnibox would be acceptable since the server indicated the root zone isn't intended for use. This isn't the behavior, though.

> If example.com returns a 403 status, and www.example.com returns a 404 status, the www version is still hidden from the user. The www and the root are very obviously different pages and serve different purposes, so I believe the should be some logic regarding whether or not www should be hidden.

It's not very difficult to come up with a simple algorithm that checks HTTP standard responses and implements this in a sensible way: it seems Chrome's developers haven't even stopped to think about how this should be done properly though.

This is not so much a new policy issue as a buggy implementation issue.

Post reply on HN