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

901–910 of 919 posts

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

#901

Post by wwweston »

abalone wrote: post #890
wwweston wrote: post #880

Earlier quoted context omitted.

> the claim that this UI change "breaks DNS", which is trivially false. No real world examples are cited unfortunately. As mentioned in the comment you're replying to here, at least half a dozen such claims with examples are in the comments on the issue/ticket that started this thread, the same one that you even pulled a quote from. They've also been invoked throughout the entire HN discussion. I'm not sure if you mi…

That a misconfigured Singaporian banking site is the worst example in the world anyone can come up with is perfect evidence that the apoplectic reactions are unwarranted, like so many over the history of changes like this in our industry. And my comments are restricted to the "www" prefix. > How will they know the floor wasn't accidentally omitted instead? This is nonsensical. This www change does not hide subdomains…

> That a misconfigured Singaporian banking site is the worst example in the world anyone can come up with is perfect evidence that the apoplectic reactions are unwarranted

The "worst" example? I don't think I turned in a ranking. You asked for concrete examples of a problem. It is one. It's part of an unknown but decidedly non-zero number of examples where the www subdomain meaningfully differentiates hosts in the real world, where we live.

If there's a specific reason this example or others aren't worth considering, that's a bit of goalpost motion, but a more clearly articulated case can be worth it.

> my comments are restricted to the "www" prefix.

I'm glad your comments are. The change under discussion does not appear to be. Per comment #16 under the ticket:

"the domain m.tumblr.com is shown as tumblr.com."

Apparently the policy of identifying some subdomains as "trivial" is not limited to www.

Sortof raises the question -- once a player like Google decides it can designate a subdomain as trivial over its common (but not universal!) redunancy, what keeps them from stopping with www?

> It only concerns the entirely redundant "www"

Commonly redundant is critically distinct from universally redundant.

And allowing domain holders the possibility of treating them as redundant is a distinct situation from unilaterally imposing it.

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

#902

Post by Donzo »

magicalist wrote: post #581
Donzo wrote: post #574

Earlier quoted context omitted.

Did you read the whole article? "The focus right now, they say, is on identifying all the ways people use URLs to try to find an alternative that will enhance security and identity integrity on the web while also adding convenience for everyday tasks like sharing links on mobile devices." My statement is clearly supported by the article. They paint a rosy picture of it, because this is a submarine piece, but they are…

> My statement is clearly supported by the article. You're ignoring a direct quote in favor of a Wired reporter paraphrase (one which mentions sharing links, no less). They cite an earlier effort, which was a display change. This issue is for a display change. None of this points to "trying to do away with URLs".

>"None of this points to 'trying to do away with URLs'"

Except for that "trying to identify an alternative" part. But let's ignore that, because doing so makes you comfortable.

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

#903

Post by royce »

vidarh wrote: post #899
jrnichols wrote: post #870

Earlier quoted context omitted.

yep. or ftp (or mail/smtp/whatever) was a single host separate from the web servers, and www was a CNAME to a virtual ip/load balancer. Still separated physically. That time wasn't even that long ago.

The point was that this was always a choice - there has never been a point where it was required. My first ISP back in '93 ran mail, web, ftp and shell accounts on a single pc. So did the ISP I cofounded in 95. It isn't and never has been a technical limitation, but a choice down to what worked for you. Especially as address rewriting firewalls also existed back then, so multiple services pointing to the same externa…

For us (early regional ISP, mid-'90s), a lack of separate per-service hostnames caused significant scaling fragility.

In the initial rollout, all services were served from a single physical host with just one listening IP, which the bare 'example.net' resolved to. (Was this naive of us? You bet.) Other service hostnames (www., smtp., etc) were all just either CNAMEs to that hostname, or A records to that IP.

When our SMTP usage started to exceed the capacity of that single host, we tried to move 'smtp.example.net' to a different host. This is when we we discovered that many users were configured to use 'example.net' for SMTP instead. We had to update all of those users' configs before we could turn down SMTP on the original host. (We couldn't afford big-iron load balancers, and they were less common then - we just used DNS round-robin for load distribution).

At that point, we realized that customers were using bare "example.net" for everything - homepage, SMTP, POP3, IMAP, FTP, DNS, shell access - you name it. It was easy to remember - and it worked. So it was hard-coded everywhere - FTP scripts, non-dynamic DNS settings, etc. And this was looong before email clients had automatic configuration detection, so that was all hard-coded, too.

So we had to painfully track down all the users who were still hitting 'example.net' for SMTP, and help them update their configs before we could turn down SMTP on the original ancient host. The other services had to go through a similar painful transition.

We concluded that the only way to prevent this from happening again was to make sure that the bare hostname never offered any services at all - except for a single HTTP service whose sole purpose was to redirect 'example.net' to 'www.example.net'.

From then on, each new vISP domain had the same non-overlapping service namespace ... so that the otherwise inevitable configuration drift would be impossible.

Later, with the rise of things like email autoconfiguration, load balancers, and POP/IMAP multiplexors (like 'smunge'), we had more options. But at the time, avoiding services on 'example.net' was the only way to go (for us). Having a bare 'example.com' as the sole hostname in the browser bar was a sign of brokenness. :)

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

#904

Post by pvorb »

pvorb wrote: post #555
masswerk wrote: post #294

Earlier quoted context omitted.

A proposal for better security with domain names: The domain name system has been around for decades and it's a clever and proven system. It can – and should be – taught in school and, arguably, knowledge of it is, while not difficult to obtain, essential in our times. Additional ambiguity in this is probably not what we want. Arguably, the most sincere problems arise from mixed alphabets with Unicode domains and loo…

How about displaying an identicon, that is rendered from the domain, in the address bar? People might soon learn what the icons of their important sites look like and will easily detect if somebody is trying to phish their bank account.

I dedicated a blog post to this idea: https://vorba.ch/2018/url-security-identicons.html

Here is the discussion on HN: https://news.ycombinator.com/item?id=17947467

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

#905

Post by floatingatoll »

shaan7 wrote: post #881
floatingatoll wrote: post #867

Earlier quoted context omitted.

What difference is indicated by "news." rather than "www."?

Um, that they can be different websites?

The general public does not perceive that difference, likely as a direct result of dot-com inventiveness with respect to domain names. Thanks to the stupidity of “m.” (WAP is dead) and “amp.” (WAP lives!) and the cuteness of “baredoma.in” (Silicon Valley represent) and the insanity of “www1034.www” (here’s looking at you, HP), we have spent the last decade on the web directly teaching non-tech users that what used to matter (“www”) no longer means anything at all, and they’ve listened.

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

#906

Post by sofaofthedamned »

vidarh wrote: post #754
Matheus28 wrote: post #534

Earlier quoted context omitted.

There is an actual (small) reason for the existence of "www" nowadays. You cannot have a CNAME record for the domain apex (example.com). Many dns providers implement a workaround by resolving the CNAME record into A/AAAA records when queried. https://serverfault.com/questions/613829/why-cant-a-cname-re...

You can but it prevents you from having other records there, which includes things like an MX record. Just a nitpick, as in practice that prevents most people from being able to use a CNAME on the apex.

I upvoted you because you're correct - it's a failing of the system.

My original point still stands though - we used to use 'http://' and 'http://www.' as a signal that this was a web address. I cannot believe this will still stand in 5 years time. The default is now the domain name, not the phone number.

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

#907

Post by igornadj »

berti wrote: post #589
sofaofthedamned wrote: post #497

Earlier quoted context omitted.

Oh come on. "www." was used as a way of delineating what was a web address. Hence the fashion of putting that there so people knew you had to do it in the browser. Before then people used to also put the " http://" on there, and the combination of the two on vehicles/signs was ridiculous. We're now in a web world. People know what a URL is. "domain.com" isn't ambiguous, it's obvious to man, beast or child that you ty…

Message 3[1] in the linked discussion has a great counter-example: "How will you distinguish http://www.pool.ntp.org vs http://pool.ntp.org ? One takes you to the website about the project, the other goes to a random ntp server." I do totally agree about m., but it's not Google's place to dictate that, rather it's a decision for each entity to make for themselves. [1] https://bugs.chromium.org/p/chromium/issues/detai…

Easy answer. If you end up where you wanted to go, you are in the right place. If not, google it. This is how the vast vast majority of users behave.

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

#908

Post by mcjiggerlog »

foozed wrote: post #796
PostOnce wrote: post #779

Earlier quoted context omitted.

firefox has both profiles (for actual different users) and containers for isolating stuff (i.e. a sub-profile) for a single user. The containers have a great UI/UX. I'm looking at the profile stuff now (after having not in years) and it seems counterintuitive and clunky https://support.mozilla.org/en-US/kb/profile-manager-create-... https://support.mozilla.org/en-US/kb/containers Anyway, "forced" is a strong word whe…

the containers are great thanks for sharing, will definitely use those at home! You're right I should have emphasized the feel part of my comment since the dev tools especially are just a matter of preference. However I stand by my point that the profiles are definitely not on par with chrome, since there doesn't seem to be a way to have multiple profiles open at once.

If you just need a "personal" profile and a "work" profile, what I do as a workaround is to use normal firefox for personal and firefox developer edition for work. They are completely sandboxed from each other.

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

#909

Post by basch »

daveFNbuck wrote: post #823
basch wrote: post #809

Earlier quoted context omitted.

really we are talking about rendering, right? not actually changing the protocol itself? (:lock: = lock unicode/emoji = secure http) :lock:/com/GOOGLE/www/maps/hawaii I am a strong proponent of the URL being part of the user interface. I should be able to manipulate what i request of a service by modifying the url. The text in the url should mean something.

Making the rendering that different from the actual URL would be very confusing, especially if it varied from program to program or within programs. Links would look one way on websites and then have a completely different form in the url bar after clicking them. That particular rendering choice would also have the downside of being the same for both https://www.google.com/maps/hawaii and https://google.com/www/maps/…

Yeah you might have to double punctuate after the subdomain, BUT it still makes it clear what domain you are on.

https://com/google/www//maps/hawaii

And its not like the browser couldnt render it both ways, either on click or hover.

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

#910

Post by nathan_long »

travem wrote: post #603
lalaithion wrote: post #585

Earlier quoted context omitted.

The best security change we could make, imo, is rewriting domains so that they look like com.evil.bank.www/now/urls/go/from/most/specific/to/least

You're in good company. Tim Berners-Less said something similar when reflecting on what he would do differently if given the chance: > Looking back on 15 years or so of development of the Web is there anything you would do differently given the chance? > "I would have skipped on the double slash - there’s no need for it. Also I would have put the domain name in the reverse order - in order of size so, for example, th…

Yes. Think how you have to read "mobile.tasty.noodles.com/italian/fettuccine" to determine where it goes.

First start at the slash and work your way left: "com -> noodles -> tasty -> mobile" - then jump back to the slash and work your way right: "italian -> fettuccine".

This is counterintuitive and I doubt most users understand it. "com.noodles.tasty.mobile/italian/fettuccine" makes more sense to me.

Also, I think TLDs like "com" and "edu" and now "io" and "cool", etc, are misguided. I wish we had "country.language" as the only TLDs. For instance, "us.en.apple.www/mac". I see several advantages.

One, if "us.en.apple" and "uk.en.apple" were different entities, it would make legal sense, whereas "apple.com" and "apple.cool" being different entities makes no sense. Two, a use would likely notice if they ventured outside their usual TLD(s), and be less surprised by the different entity. Three, these TLDs could have rules about allowed characters; eg, only ASCII in "us.en". This would make homoglpyh attacks much more difficult.

Post reply on HN