
“We plan to hide ‘https’ scheme and subdomain ‘www’ in Chrome omnibox in M76” - PieUser
https://bugs.chromium.org/p/chromium/issues/detail?id=883038#c114
======
masswerk
Hm, hiding the protocol and the host part in the address – what next, hiding
the domain? However, the path is hidden already, what's left then?

Seriously speaking: If browsers are simplifying the URI scheme for the alleged
benefit of users, how do we expect these users to know anything about
addresses? Isn't this rather undermining security than enhancing it?
Highlighting significant parts may be preferable to hiding those deemed
insignificant. Moreover, regarding https, I personally prefer positive
affirmation over lack of warning.

For me, this worked best for desktop browsers with the padlock icon (and,
before this, the key icon) shown together with a display of link targets in a
status bar as a separate, reserved area. (While allowing pages to overwrite
`window.status` was certainly not a good idea.) A consistent display of the
authority issuing the certificate of the current page in a status bar like
this may be also nice. I'm not convinced that less but more opaque information
is the way to go.

Dedicating 20 vertical pixels of virtual real estate to security relevant
information may be worth it. It may be also easier to parse than an overloaded
omnnibox/location/search/navigation/security/menu bar. Cutting down any
information which is displayed too densely right from the beginning won't help
the issue. How many bits of information are there in this "everything bar"?
Yes, there's still a bit of grouping left, mainly by spacing, but color is
mostly gone as a signal in order to make the information density bearable. So
users will be applying quite an amount of selectivity when parsing this
display, by this inevitably missing relevant information. (That this densely
combined display is rather homogenous both for esthetics and acceptance just
aggravates the need for selective parsing, which is likely to become a habit.)
"We'll pre-filter this for you" isn't addressing the problem, it's rather
"living with the outcome".

Edit: A legitimate reason for redacting the host name are extensive names,
crafted to exceed the space available in the location display in order to
deceive users regarding the identity of the host. Here, abbreviating by an
ellipsis (compare text-overflow: ellipsis) in order to fully display the
domain may be a way to go.

\--

P.S.: What's the general lesson taught by such redactions by the browser
vendor? That it is OK to ignore these things, as they are truly irrelevant?
(Must be without significance, since Google told me so?)

~~~
skocznymroczny
I guess the direction is appification of the Internet. On your phone, you
launch "Facebook" and "Instagram", not /mnt/apps/facebook.apk and
/mnt/apps/instagram.apk. Likewise, on the internet, they want you to visit
"Facebook.com", not
"[https://facebook.com/index.html"](https://facebook.com/index.html").

~~~
masswerk
Yeah, it's about products for the most. (Also, what happened with human
readable URLs? Even, if you'r driving your single page app on fragment
identifiers, you could route them internally based on the path info.)

On a more generally level, I think, it's probably more about amplification vs
augmentation, the kind of human-computer symbiosis, what this dialog really
is. (Actually, I do prefer Licklider over Engelbart.) Take for example a
middle-aged worker in India, who has now one of those new, cheap, not-that-
smart phones on a $2/month mobile plan. S/he connects to streaming services
via voice search and communicates by the press of a single button. For the
first time in her/his life, s/he's able to reach out on her/his own. This is
certainly empowering. There's much to be said in favor of such interfaces on
devices like this.

However, Licklider's vision of a human-computer symbiosis was of a completely
different nature, of partners in cooperation on equal levels. This was not
about amplification in this sense, it was about mutual comprehension and
directing work flows, with the later heavily depending on the former. This is
the desktop environment. Here, simple amplification models are ultimately
doing more harm as they may be convenient.

Now, where are the growing markets, what should a company care about? However,
this may be a question and an answer too simple. When will our Indian worker
gain access to a laptop? The answer may be quite well, "never". Is this still
the same market, the same product, the same network?

------
sam_goody
And this way you won't know if your page is AMP, or just a webpage (since amp
follows www in things they are hiding).

I strongly suspect that this (and the eventual goal of making the whole web
hosted by Google) is actually the rationale behind the decision.

Previous discussion:
[https://news.ycombinator.com/item?id=17927972](https://news.ycombinator.com/item?id=17927972)

Also, training the user to treat the URL as text, so that you search for
domains (type "amazon" instead of "amazon.com"), is better for them. The "URL"
bar is for Chrome also a search bar (and every domain you enter is sent to
Google "for search suggestions").

~~~
mtgx
Yes, I also believe this is the primary reason Google is doing this. They want
to hide urls with referrer tracking, AMP URLs, and other such things from the
user.

------
madiathomas
For Google, there is no money to be made when people know how to enter URL in
a browser's address bar. Money is on users searching for a company using a
name each time they want to visit a company website. That way Google can
bombard users with adverts. When they click on those adverts, Google get paid.
Now companies will be forced to advertise using Google AdWords. So that they
can appear on top of the search list. Otherwise Google will show ads of their
competitors first.

~~~
move-on-by
Also there is terrible URL usability with google AMP pages. Google has every
reason to do away with URLs as a user tool. I might be going off in the deep-
end now, but if there are no URLs, why ever leave google.com at all? AMP is
basically an early opt-in of rebranding the internet as google.com. Of course
its all being done in the name of security, speed, and data-saving. Truly
altruistic motivations.

------
pyentropy
So apparently Google rolled out an update where they 'm.domain.com' turn into
'domain.com' in the omnibox. In what world is this acceptable? How can they
assume that 'm.' always means mobile and 'www.' is the same as the root domain
for all hosts?

Let's assume that you have a blog platform offering subdomains for each user
and 'm.blogplatform.com' is available. Now, any user can get that subdomain
and impersonate the homepage because Emily from Chromium decided that eliding
parts of the URL without any spec is a reasonable decision.

~~~
saalweachter
I hate to break it to you, but if you allow www.companyname.website,
companyname.website, and m.companyname.website to be owned by different
entities, your users are already being phished.

~~~
rnotaro
Tumblr have a url scheme where subdomains are user-owned.

[https://m.tumblr.com/](https://m.tumblr.com/) !=
[https://tumblr.com](https://tumblr.com)

When they initially decided to hide the "m" subdomain,
[https://m.tumblr.com/](https://m.tumblr.com/) was shwon as tumblr.com.

It's not the only website with that issue.

------
eridius
I'm not sure why everyone is so up in arms here. I don't see how this change
is detrimental to the web or somehow good for Google. Hiding the
"[https://"](https://") seems like a perfectly fine idea as long as there's a
clear way to distinguish between https and http pages. Safari's done this for
a long time; https pages display a tiny padlock icon and http pages display a
much more prominent "Not Secure — " prefix (i.e. the obvious display is when
you're insecure, which is the right way to go about things).

Hiding "www" seems less meaningful. I'm not really sure what the motivation is
there, beyond the fact that the "www" prefix is mostly just aesthetics. My
best guess is they want the url to start with "google.com" instead of
"www.google.com", except that's not helpful from a security standpoint at all
and might be slightly detrimental, if it trains people that the very first
word they encounter is the most important, as paypal.whatever.com is not in
fact paypal. But a lot of domains already elide the "www" anyway.

Of course, in both cases I am assuming that putting focus on the URL bar will
display the full URL.

~~~
dao-
> Of course, in both cases I am assuming that putting focus on the URL bar
> will display the full URL.

It won't. From the issue tracker: "The full URL is also revealed by clicking
twice in the URL bar on desktop," in other words, merely focusing the URL bar
won't be enough.

~~~
eridius
How does that work? If you put focus on the URL bar but it doesn't show the
whole URL, how are you supposed to edit it?

~~~
dao-
On focus you can only copy or replace the URL, not edit it. You need to click
a second time to edit.

------
dazhbog
Its all fine until you have to explain to your loved ones how to read domains
and the difference between an email link with random-server-name.paypal.com
vs. www.paypal.random-name.com

If we remove meta data like this from everyday browsing maybe it will be
harder for people to even grasp the idea of how domain names work?

~~~
onion2k
Telling people to look for [https://](https://) as a way to indicate that
they're secure isn't good enough. There's nothing stopping a malicious party
applying an SSL certificate to www.paypal.random-name.com. Browsers need to
inform users based on actual information that they have (eg the SSL cert,
reports of malicious domains, etc) and display _that_ to the user.

Essentially Google know more about the state of a website than a user can
learn from the domain alone, and they should display that to the user. Once
that's happening the various parts of the domain are less important. The
downside of this is that it increases Chrome users reliance on Google.

~~~
cm2187
So basically a brave new word where google will decide what is a good and a
bad website. Great.

~~~
amfsn
That's what they wanted when they pushed Let's Encrypt. https meant something
before, since a certificate was expensive and required proof of identity. Yes,
those methods weren't infallible, but they were good enough. Now we've lost
that with free https.

~~~
cm2187
EV certs required that. DV certs never provided that sort of security.

~~~
amfsn
Of course they did. When you paid with your card they knew your identity.
Unless you were carding which is a pretty serious crime.

~~~
logifail
> When you paid with your card they knew your identity.

Who's the "they" in that sentence? As it stands, a certificate reseller knows
that the Paypal account "some.name.here@gmail.com" paid for a SSL certificate
for "www.unrelatedcompany.TLD"

The certificate itself tells you nothing about who paid for it - it doesn't
even tell you which email account was used to confirm some level of
association with the unrelatedcompany.TLD domain.

~~~
amfsn
Then PayPal has the data and LE can follow the trail. Because it's about LE
being able to tell who actually bought the certificate, telling me end users
can't do that is kinda moving the goalposts.

~~~
pilsetnieks
There are certificate authorities all over the world, and many of them not in
jurisdictions that would share data with your law enforcement.

~~~
logifail
Q1: What kinds of serious crimes involve law inforcement needing to chase up
who's behind the purchase of a SSL certificate, anyway?

Q2: Can't the bad guys just buy a pre-paid debit card with cash if they're
that desperate to cover their tracks?

------
driverdan
The worst part:

> We've worked with other browser representatives to incorporate URL display
> guidance into the web URL standard ([https://url.spec.whatwg.org/#url-
> rendering-simplification](https://url.spec.whatwg.org/#url-rendering-
> simplification)). The URL spec documents that browsers may simplify the URL
> by omitting irrelevant subdomains and schemes in security-sensitive surfaces
> like the omnibox.

Google is trying to make this obfuscation a standard.

~~~
josteink
> security-sensitive surfaces like the omnibox.

Yes. It’s security sensitive. Any incorrect or misleading information placed
here can trick a user proceeding with actions they otherwise would not.

So we should let the URL-bar present the unmangled URL and nothing else.

~~~
UncleMeat
The "security sensitive" information in the URL bar is horrible.

For TLS you need to look for the presence of a single character. For most
people, "[http://"](http://") and "[https://"](https://") are both gibberish
and remembering which one is good is not obvious. For domain names you now
need to look past all of the subdomains since mybank.evil.com isn't safe. But
don't look all the way to the right since that is usually full of gibberish
and everything after the "/" isn't trustworthy either. Oh and watch out for
homoglyphs too.

URLs suck for security.

Also I bet you are upset that port numbers aren't included in the displayed
URL too.

------
Santosh83
Industry wants you to open apps and click buttons and links, and not worry
about such things as bothering with what the URL may be, or gasp, even typing
in or editing your own URL. That's too complicated and dangerous for 'normal'
users apparently according to them.

~~~
supernes
Wondering how far they can take this. How long before we read that "Google
will replace URLs with the Google search terms you can use to find the page
you're viewing"

~~~
giancarlostoro
Sounds like the I'm feeling lucky button will finally be used and abused by
Google. I already hate that search is merged into the url bar even in Firefox
if I type an internal hostname sometimes instead of trying to resolve it
googles it or duckduckgo's the damn hostname even at times where it ends in
.com from an intranet url I dont understand why its so stupid in those cases
either, Chrome being worse than Firefox in this regard. I dont mind it on
mobile where real estate on my screen is already expensive.

~~~
saghm
From a quick google (ironic, I know), you can disable this by disabling
`keyword.enabled` in the `about:config` menu. If you still want a way to
search without manually navigating to a search engine site, there's also a
setting in `about:preferences` to add a separate search bar to the browser
interface.

------
skybrian
On Chrome for Android, the URL is not editable unless you press an edit
button, which displays a text box. I imagine this is another step in that
direction, and if you click "edit", the text box still shows the whole thing.

Compare with how email headers work in gmail. You don't see email addresses
anymore by default, but there's a dropdown that shows them.

~~~
rudiv
Are you sure this is the case for everyone? On my two android devices, tapping
on the address bar still opens the keyboard for direct editing of the URL.
I've never seen the behavior you're describing on Chrome for Android, although
I concede it may be geofenced or something of the like.

~~~
kuschku
This is what it shows for me on latest Chrome when clicking the address bar
while on Wikipedia: [https://i.k8r.eu/WIPPrQ.png](https://i.k8r.eu/WIPPrQ.png)

You have to press edit for it to put the address back into the input field

------
amanzi
Just use Firefox! And then install Firefox on your friends' and family's
computers too, and set it as the default for them. Spread the word...

~~~
isostatic
Firefox has a nasty history of following chrome's choices

~~~
giancarlostoro
Yeha they merhed the URL and search boxes. I am not a fan. Now and then my
browser thinks a local hostname is actually a search term.

~~~
isostatic
Fortunately you can undo that in firefox (separate boxes -- ctrl-l for
location, ctrl-k for search, and disable the "search if not a url" option),
but it's not the default, and that leads to more and more people using bing to
search for google to then search for facebook, as they have no concept of the
idea of a URL (or indeed a program, a file or a directory) :(

------
duskwuff
Didn't we already go through this last year?

[https://www.zdnet.com/article/chrome-69-kills-off-www-in-
url...](https://www.zdnet.com/article/chrome-69-kills-off-www-in-urls-heres-
why-googles-move-has-made-people-angry/)

~~~
PieUser
They delayed the rollout after people spoke out against it:

"In Chrome M69, we rolled out a change to hide special-case subdomains “www”
and “m” in the Chrome omnibox. After receiving community feedback about these
changes, we have decided to roll back these changes in M69 on Chrome for
Desktop and Android."

I don't think there's any going back this time around...

------
cloud_thrasher
On the chrome://flags page, these prefs are found under

#omnibox-ui-hide-steady-state-url-scheme / #omnibox-ui-hide-steady-state-url-
trivial-subdomains / #omnibox-ui-hide-steady-state-url-path-query-and-ref /
#omnibox-ui-one-click-unelide

~~~
la_barba
That's the nerd pacifier. They will remove those flags eventually as they have
always done.

------
jazzyjackson
The omnibox never seemed like a crowded part of the interface, did they do any
kind of user testing where they found people were confused or annoyed by this
'[https://www'](https://www') prefix? Or is this just one team's sense of
aesthetic ?

~~~
bencollier49
People who don't understand URLs will use search to find sites. Obviously I've
no clue why Google would be motivated to encourage that behaviour. Must be
their sense of aesthetic.

~~~
comex
So your claim is that simplifying URLs, which on its face seems like an
attempt to make them _easier_ to understand, is secretly intended to make them
hard to understand?

Forgive me for being skeptical.

~~~
ezrast
I don't doubt that Googlers believe this is a useful change, but that belief
is borne out of their own vested interest in deprecating traditional web
navigation. That's really the best light you can put it in, considering how
utterly user-hostile this decision is.

~~~
comex
The best light you can put it in is that removing unnecessary parts of the URL
makes it easier for less advanced users to understand what the URL consists
of, _helping_ them use "traditional web navigation".

To be fair, Google _has_ previously experimented with hiding the entire path
part of the URL, which does hinder URL-based navigation by making the
displayed text unusable as a URL. However, that's different from this change,
where typing the displayed text into a browser's URL bar would normally get
you to the same page (unless the site is configured strangely).

~~~
TeMPOraL
> _removing unnecessary parts of the URL makes it easier for less advanced
> users to understand what the URL consists of, helping them use "traditional
> web navigation"._

How? If the users are supposed to learn "what the URL consists of", how
removing and hiding all but one piece of it helps?

It's like saying, "to make postal addresses easier to understand, we'll hide
everything except the recipient's name and surname".

~~~
username90
If I want to go to facebook, all I need to write in the address bar is
"facebook.com", but the displayed address is
"[https://www.facebook.com/"](https://www.facebook.com/"). A naive user would
believe that they need to write the entire
"[https://www.facebook.com/"](https://www.facebook.com/") instead of just the
short version to navigate to facebook, which is too cumbersome for them so
they just use google search to find it instead.

~~~
nybble41
That is site-specific behavior. It depends on a redirect from
[http://facebook.com/](http://facebook.com/) to
[https://www.facebook.com/](https://www.facebook.com/) which may not exist for
all sites. If the user wants to end up at the proper page without risking an
insecure redirect over HTTP then they _do_ need to type the entire URL.

I would support making HTTPS the default when a URL fragment is entered
without an explicit scheme, and site operators should just drop the obsolete
www domain name prefix. However, the _browser_ should not be masking the full
name of the site you're visiting. At the very least it should verify that
www.example.com and example.com resolve to the same IP address(es) and use the
same TLS certificate before presenting them as equivalent, though that still
doesn't guarantee that they have the same content.

------
reilly3000
Safari has been hiding protocol and path for years. I don't care for it, but I
also don't think its a conspiracy to destroy the web as we know it.

~~~
rusk
You can disable this behaviour, and its all right there when you go to click
on it. Presume you mean on mac btw, cos I using safari on ios and I can see
the full address right in front of me. No protocol spec but a lock icon at
least

~~~
comex
The way Safari does it is a lot nicer UX. In Chrome, the URL scheme is always
hidden, but if you press copy it magically copies the full URL to the
clipboard – as opposed to the actual displayed text. In Safari, the URL scheme
becomes visible once you click on the URL bar, so what you see is what you
get.

That said, I dislike the default behavior of hiding the entire path until you
click, as opposed to just the URL scheme.

------
bencollier49
It increasingly grates on me that Google seem to want to ruin the internet
using their browser monopoly in service of their ad revenue.

~~~
clouddrover
Don't let it grate on you, just use Firefox. The only way you're going to
influence their development direction from the outside is to choose a non-
Chrome based alternative.

~~~
asdernr
Please change my mind. Besides the 1% privacy gain and some more free RAM when
using firefox over chrome. Which are the key/killer arguments for firefox,
NOW?

That chrome can become shit in the future is not to be discussed...

~~~
jddj
While it's better now in many ways, some of which you've already dismissed,
the future matters now because our choices now effect our options tomorrow.

In a way, with your browser choice you're effectively voting for the internet
you want in the future.

If that's Chrome and, despite the practical benefits of using Firefox, you
trust Google above Mozilla to work in your best interests, then use Chrome.

------
peterbraden
Chrome is getting more and more user hostile. At the moment you can't inspect
a site's certificate without going into developer tools.

Terrible decisions, the developers should be ashamed.

------
Communitivity
Hiding the scheme is a dangerous path, because users then have to depend on
browser specific indicators of https, or other secure schemes.

I think it's a bad idea for that reason, and for another higher level reason.
As a developer and sys admin before that I've always tried to assume my users
are smart people and try to educate them about what they might not know,
instead of assuming they are dumb and attempting to PICNIC-proof
software/systems. I think hiding the scheme indicates an assumption that users
are dumb and need to be told what to do. I've seen reporting on other
indicators of this from Google over the last decade (e.g., Google Reader's
sunset, Google+, working with China's censors, and others).

FYI, PICNIC = Problem In Chair Not In Computer

~~~
teddyh
> _PICNIC_

I believe the more common term is “PEBKAC”:

[http://www.catb.org/~esr/jargon/html/P/PEBKAC.html](http://www.catb.org/~esr/jargon/html/P/PEBKAC.html)

------
lunias
Why must we continue to insist on dumbing down our presentation of technology.
Instead we must insist that users rise to the occasion.

We are all inextricably linked to technology and yet I wonder if the newest
users even know what a file extension is; because we hide that by default for
some reason now. How many people have been the victims of phishing because an
alias is more prominently displayed than the actual domain which the email
originated from?

I'm ready for a return to function over form. Do not hide information from me.
If I suspect that your product development is driven by the lowest common
denominator then I will look for alternatives.

http and https are distinct and as such cannot be hidden; you could replace
them with icons (barf) or ports (unlikely).

www.site.com is a subdomain and is again distinct from site.com with the
'www.' omitted. Just because they tend to resolve to the same server does not
mean that they must.

Let's just call PI 3 because those decimals are an eyesore.

------
julius
About 15 years ago we, the techies, killed the IE6 super monopoly (they
basically had 100% browser market share). We installed firefox on any device
we could get our hands on.

Guess it is that time again.

------
Zekio
Gotta say I'm not a fan of browser hiding information from the user

~~~
DangitBobby
That was my first instinct as well but, you know, at some point if you don't
know what it means and you aren't going to bother to find out, extra
information is just noise. Green locks and red slashes are probably enough.

~~~
nerdponx
That's bullshit IMO, people learn all sorts of complicated stuff in video
games through embedded tutorials. There's no reason a browser couldn't do the
same thing.

------
duluca
Sigh. Many new comers to web development learn by observing, this will take
that away. Www and https handling requires explicit configuration. Unless the
intent is to not let people type in www or http, but what happens when they do
and it’s not handled correctly?

------
BluSyn
I'll play devils advocate. I'm fine with this being default assuming there's
an option for advanced users to disable it. 95% of Chrome users will not
notice or care about this change, and in fact will make things simpler for
them in the long run.

Also, seriously people, ditch www. subdomains already. It's not 2002 anymore.
I cringe so hard when I see that crap in print ads and billboards.

~~~
robocat
> ditch www. subdomains already

Sweet, unless you use any other subdomains for web pages, or want to in the
future.

Usually you don't want cookies for domain.com to affect api.donain.com,
admin.domain.com, test.domain.com etc.

I actually love www subdomains - the origin tells you it is a website.

~~~
Avamander
> I actually love www subdomains - the origin tells you it is a website.

It lacks that connotation for the regular user.

~~~
mrweasel
I don't think so. Let's say you have one of the new TLDs for your site, say
"new-york.florist", a nice domain. It's my belief that writing "new-
work.florist" on your ads, business cards or merchandise will not let regular
users know that it's a domain name. Writing www.new-york.florist will help
indicate that this is your website.

Adding all the new TLDs have made the www prefix more useful than ever.

~~~
Avamander
Or we could put `[https://`](https://`) in front and the www. is redundant.

~~~
robocat
Let's say you have your business advertised on your vehicle.

Put www.somthing.com on there and it is obvious to most how to find your
business online.

[https://](https://) is ugly and longer IMHO.

~~~
Avamander
Wouldn't you place it next to some other contact details? A regular person can
deduce it's a internet address.

------
Boulth
Hiding "www" subdomain looks like an ugly workaround for missing support for
DNS SRV records in HTTP/browsers.

~~~
tialaramex
Good news on that front.

To do a bunch of new things browser vendors want, they need to put more stuff
into DNS. For example eSNI needs keys in DNS, and HTTP/3 (HTTP over QUIC,
which is the new encrypted transport protocol) wants a way to discover HTTP/3
availability before connecting with TLS.

So at IETF 105 last week there was stuff pinging around about the idea of a
single new record, perhaps just for HTTP or perhaps more, that wraps all this
stuff up, with all the SRV features too.

The DPRIVE work is having the effect of reducing the pressure to not use DNS,
because crappy DNS servers break all the time when you add new things, but
DPRIVE servers are operated by people who actually know what they're doing so
that isn't a risk, and eSNI in particular makes no sense without DPRIVE, so
why not.

------
EamonnMR
URLs are one of the few things the modern web has retained that has allowed it
to be truly interoperable across different devices, platforms, and walled
gardens. If we loose the URL, we loose the web. I don't like this at all.

------
apeace
A lot of the comments here are about Google's motivations for doing this, and
it seems the consensus is they want to hide URLs so that users don't notice as
Google swallows more of the internet.

A couple question for those with this point of view:

1) Do you think users notice when they are using AMP articles today, even
though the URL has not been hidden yet?

2) Do you think it would actually matter if they did notice a Google-hosted
URL? Would they boycott Google or change their behavior somehow?

3) Do you think Apple has the same motivations as Google? Safari has been
hiding www, scheme, and path for a while now. Do you think they have any valid
reason for having done this?

4) What do you say to Google's stated reasons for making this change
(simplicity and security)?

~~~
la_barba
I think the point is that Google wants fuzzy boundaries between things that
were never fuzzy to begin with, until they started confusing people - whether
they intended to or not.

If you asked any person- How do go to your favorite website before the
omnibox, they had a clear set of steps that worked. If you asked them, how do
you search for recipes they had a clear set of steps for that too.

Google's omnibox/(aka keyword logger) made that boundary fuzzy and made it
confusing for people. Earlier, people very quickly learned to recognize what
is and isn't a valid url, because an invalid URL simply didn't work - this was
a very very useful skill/knowledge to have. And every-time you had a typo you
noticed it immediately. But then Google insisted on merging the URL and search
bar and started correcting their typos and mistakes and people started losing
this knowledge/skill. So now.. a lot of non technical folks I know type the
url in google's search box in weird ways .. like "wwwfacebook" or "facebook
.com" or other typos. So now, nobody actually knows what a valid URL is. That
makes them easy targets for phishing and scamming. I'm not blaming this
entirely on Google, but they did play a part. Google doesn't seem to realize
how they're fucking up things even if that is not their intent.

------
PieUser
First HN discussion:
[https://news.ycombinator.com/item?id=17927972](https://news.ycombinator.com/item?id=17927972)

They rolled this out 10 months ago but rolled it back after community
backlash.

------
lucasyvas
This hurts younger generations. They will become more and more oblivious to
how things work. They will be forced to "trust" someone that knows better
instead of having the knowledge to decide themselves.

For those that become engineers, it will take even longer to untrain all the
handholding they've had to endure.

If the web is apparently so damn complicated maybe we should rebuild it to be
"simpler" instead of hiding it how it works. I'd prefer to leave it exactly
how it is until there is a clear reason to revisit the design.

------
bitcurious
Reads like folks at Chrome are just making work to have work because the
senior leadership has no vision. Needs to be addressed before they burn
through the goodwill they’ve built up.

------
ubermonkey
This seems like a bad idea.

------
tempodox
By all means, hide the truth from the users and flat-out lie to them. After
all, what's it of their concern which site they are browsing? The main thing
is they see the ads.

------
Endy
Good reason to de-Google my existence. When an evil thing is actively trying
to destroy the Web in a way even Microsoft didn't, it's time for that evil to
get destroyed.

------
Mindwipe
What a toxic, user-hostile idea.

The Chromium team desperately need new leadership.

------
skybrian
It seems this change hasn't rolled out on Chrome 76 on a Mac. I don't see any
change.

(I don't have it on Android yet.)

------
ep103
Can we all start moving back to firefox yet?

------
fortran77
hiding www. seems like a bad idea.

------
emilfihlman
No. This is really god damn annoying and stupid. The protocol is not
distracting and www is different from non www.

------
gsich
What a stupid idea.

------
dusted
yeah, whatever, it's too late anyway.

------
stojano
again??

------
lousken
So instead of fixing their tab interface which is terrible if you have
hundreds of tabs they rather choose to fix something that wasn't broken in the
first place, gj chrome team

------
alexghooper
This is unbelievably dumb.

~~~
dang
Maybe so, but please don't post unsubstantive comments here.

------
josteink
So google wants to replace the URL in the URL bar with a URL which is
semantically different. What could possibly go wrong?

Seriously. What kind of incompetent, lazy people are working at Google these
days? Because clearly nobody gave this any real thought.

------
cannedslime
Remove protocol? Sure an arguement could be made that showing it is redundant
giving the lock symbol appears when HTTPS is enabled. But removing sub domains
like m. and www. isn't really cool.

I already hate the fact that chrome on mobile totally removes the URL when you
focus the navbar, sucks if you want to go to some other subreddit etc.

------
keymone
both changes are great.

www must go, it's a remnant of the past, the sooner the better.

protocol is not a detail that should be ever exposed to the end user, at least
not in text form. visual cues "you're safe" or "your connection isn't secure"
are much more effective.

~~~
masswerk
Post addresses should go away. "You're at home" or "you are away" displayed on
your smartphone lock screen should do. For the rest, there's Uber. – I'm not
so sure that this is how real life works. Understanding addresses (post or
electronic) is an important part of liability and a sound mind. Also, how do
you identify authority, if you do not know about uniforms or IDs?

~~~
keymone
a) you're confusing addressing something with presenting the address; b)
you're completely (possibly intentionally) ignoring the context, which is all
about specifically "www" part, the trivial non informative part that is just a
historical artifact.

i'll let you sort out the rest.

~~~
masswerk
If in doubt about the historical context of the "www" subdomains: This was,
when dedicated services were run on dedicated machines (or rather, dedicated
network interfaces). "www" was just a default appellation (much like a well
known address on particular services) for a server running W3 services. I
don't see, why there isn't a use case for dedicated service domains anymore.
(Not everything is WWW.) There's no magic to this and has never been. (The
magic is in the port number as encoded in the protocol portion of a URI.)

Regarding the context of the example, all this is about navigating and about
communicating how to navigate. Real live addresses tend to be much more messy,
but they are bearable and users have been able to operate them for what is now
several centuries.

------
logiclogic
Google doing more evil again. Fuck everyone working for this company. The
devils minions is what you are.

~~~
dang
Could you please not break the site guidelines when posting here?

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

