Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday December 15 2019, @03:53PM   Printer-friendly
from the making-it-easy-for-fake-sites dept.

Google Achieves Its Goal of Erasing the WWW Subdomain From Chrome

With the release of Chrome 79, Google completes its goal of erasing www from the browser by no longer allowing Chrome users to automatically show the www trivial subdomain in the address bar.

When Chrome 76 was released, Google decided to no longer show the www "trivial subdomain" in the address bar when visiting a web site. This means, that if you are visiting www.bleepingcomputer.com, Chrome would only show bleepingcomputer.com in the address bar...

[...] According to a Google engineer, www is considered a trivial subdomain because "this isn't information that most users need to concern themselves with in most cases".

Many users, though, felt that this was a security issue, could be confusing for users, and is technically incorrect because www.domain.com is not always the same host as domain.com.

So is this a distinction without a difference or a real issue?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Tuesday December 17 2019, @06:10AM (1 child)

    by Anonymous Coward on Tuesday December 17 2019, @06:10AM (#933182)

    What difference? Sometimes, a lot.

    I work in an environment that is locked down. For a long time it was IE11 only. Recently they installed Chrome because some internal web sites don't work in IE11. Usually vendor software. So forced to support another browser they chose Chrome.

    I was installing, configuring and testing new web based software. Chrome was an absolute pain in the ass. The default install is http, so it hid the fucking protocol. Several times I had trouble determining if it was the software or the browser. So bloody annoying. Edge case, I know, but still aggravating.

    Our users get confused by URLs not working. Missing the S in https. Yes, I know, again an edge case, and the product of configuration and control. Still annoying. Having to teach people how to unwank a browser because it hides the uri. Having to add extra lines to documentation to counter it.

    Chrome devs keep claiming they won't add switches to unfuck issues they cause like this, yet add all sorts of crap they want.Fricking hypocritical bastards.

    No, compiling your own version or hacking theirs to fux it really is not a solution.

    Microsoft's new browser may be an alternative if this keep up.

  • (Score: 2) by NotSanguine on Tuesday December 17 2019, @05:09PM

    by NotSanguine (285) <{NotSanguine} {at} {SoylentNews.Org}> on Tuesday December 17 2019, @05:09PM (#933332) Homepage Journal

    Absolutely. That was actually my point. Thanks for providing a different example.

    When I said:

    What difference does the URL make anyway? Whether the url is 'www' or 'cockblock' or 'benihana' .site.tld, who cares?

    I was directing that at Chrome, as *they* shouldn't be screwing with the parsing/display of URLs, which should be displayed exactly as they are parsed/sent.

    I thought I made that clear with my example:

    If www.site.tld redirects to site.tld, all is good. if www.site.tld and site.tld are *not* the same thing (e.g., on intranets which use Active Directory, site.tld resolves to the Domain Controllers by default and are not redirected to www.site.tld), confusion will ensue.

    But I guess not. As such, perhaps folks will get a clearer idea from yours.

    --
    No, no, you're not thinking; you're just being logical. --Niels Bohr