Chrome 69: “www.” subdomain missing from URL
bugs.chromium.org
bugs.chromium.org
It seems that "m." is also considered a trivial subdomain. So when a user clicks a link to a "m.facebook.com" uri, they'll be confused why FB looks different when the browser reports it's on "facebook.com".
I sincerely hope Firefox doesn't follow suit.
(If you want to put focus on the domain, then display the host-part with less contrast, i.e. grey, but don't hide any potentially vital information. Otherwise, put out a RFC, defining "www" as a substitute for "*", or a zero-value atom, in order to guarantee consistent behavior.)
Edit: There are also legal concerns with catch-all domains in some countries. Blending the lines certainly doesn't help.
"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 type it in the browser. Most decent websites revert "www." or without to whichever is the canonical version; the one without should be that tbf.
The 'm.' is ridiculous too and ruins shareability. If the link was the bare domain, and the frontend does any switch that's needed, we'd all be better off.
I want to know that I'm receiving a degraded version of a website and that maybe dropping the m. will restore it.
Everytime they want to use Facebook, they type 'facebook' or maybe 'facebook login' in the location/search bar.
And to get to their gmail account they might type their own email address in the location bar.
Can you link to a site where these two are different?
Will they? I find it very unlikely that many users would even check the URL in the first place, let alone understand that m.foo and foo route to different places.
For me, this is a minor inconvenience, precisely because I'm technically capable/interested enough to handle the inconsistency.
But this kind of stuff (and I am speaking somewhat generally here) tends to frustrate me, precisely when I'm trying to educate or deal with a non-technical user in some capacity where it happens to matter. I can't just tell them, "that is the address of the page, and that will always lead to the exact same place if you type it fully and correctly, and that's that". Instead I have to get my head around what if they're using browser X or operating system Y, I have to ask on the phone first, "hang on, tell me what you see on your screen", I have to say to the lady who's eagerly sat in front of me with pen hovered above paper waiting for me to dictate how to do a thing in straightforward steps, "well it depends, first you have to check this thing, and if it's like this then you can do this but it might also be like that in which case it's a bit different, let me explain" - and this is usually the point at which the non-technical user gets tired and throws the book at me.
In short, I think consistency of information and process is usually much more understandable and useful to users of any level, than the dumb 'simplification' of this half-baked information-hiding.
Grandma has no problem with technical details being shown, she just ignores them, she just knows that clicking on the button on the top left will go the the webmail and that she needs to click the big red button in order to write a new email. Change anything and she will get lost, click everywhere, and usually find the solution, but sometimes make a mess.
There are also security implications. I told her to be aware of any change, because it may imply a phishing attempt, or some malware. But how is it going to work if legitimate software always change. You are basically training them to stop thinking about what happens, which is terrible since thinking is the only thing that can protect them since they don't have the technical intuition most of us have.
Browser start screens with a large search box in the center haven't helped either. Some users do see no difference between the location-field and this search box. Some have even unlearned this. Arguably, it facilitates ignorance of the location, the significance of URLs and how they work. Reading a URL isn't witchcraft, it's just about three simple things. But dumbing things down towards convenience at the expense of consistency will not empower users.
(Surprisingly, ordinary people have been able to manually dial a phone or to parse a street address without the help of a map service in the past. It can't be that bad.)
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 trying to do.
They _are_ indeed planning to get rid of AMP cache URLs, but they'll be doing it through open W3C standards anyone can use, not through special-casing their own domains: https://amphtml.wordpress.com/2018/05/08/a-first-look-at-usi...
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.
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.
For power users, they never look at the url unless they want information from it, in which case the `www` is valuable.
For low tech users, it can lead to straight up incomprehensible issues, like sites not rendering properly (think of a `m.*`).
The UI gains are so small, that part of the screen is never really looked at, but needs to be there, and typically has tons of horizontal room... I don't get it
Preferences > Advanced > Show full website address
EDIT: Formatting. Add missing article. Change linked image.
It is still confusing for tech people, because we often need awareness where we are.
Lots of google's UI is getting (or has) things shifting instantly under the pointer it's quite annoying. The new gmail design quick-tools are often in the way, unknown until you actually click. Hell calling on my phone shifts the speaker and keypad buttons over instantly when someone picks up. Often placing the person I just called on hold if they answer too fast.
Wasn't this a pretty well covered UX rule to not move shit around on users. Up there with don't use modes and the like.
Could you expand on this? What are you referring to?
No doubt all of us have at some point been forced to learn things that we did not find particularly useful or pleasant to learn at the time, but then later experienced a great "satisfaction of knowledge" when faced with a situation in which that knowledge became advantageous or even essential, and then proceeded to use it to better ourselves.
Imagine a world in which none of that learning took place; one in which you never have to think, everything you see and do automatically satisifies you and keeps you in a blissful state of ignorance. Who makes the decisions in that world; or rather, who can make those decisions? Who is in charge of your life? Not you.
Gradually reducing the motivation to learn, by making things "easy" and hiding/obfuscating anything that could be used as a starting point for more learning, makes for a population that won't think, won't learn, won't question or rebel. It makes them docile and easy to control.
Making statements like "ordinary users will never learn" is one thing, but explicitly making decisions to ensure that status quo is a horrible trend. It's quite a genius plan, and certainly used by organisations other than Google, but thoroughly disturbing.
I've said a few times before in the past: "knowledge is power --- they don't want you to have too much."
/s
> How will you distinguish http://www.pool.ntp.org vs http://pool.ntp.org ?
In the above case pool.ntp.org is a decades old time service, while www.pool.ntp.org is a website describing the service.
Clearly, in those cases, people aren't "confused" by the fact that they are seeing a mobile version on www., so other than the fact that you're used to Facebook specifically working this way, wouldn't you just send the Desktop header whenever you get mobile and want desktop?
Back when they removed the "http:" off of URLs, I used to use a hex editor to turn the kFormatUrlOmitHTTP bit flag off every time I got a new build, so I'd get the URL formatting I wanted, but eventually lost the mental wherewithal to continue the hack every week.
[1] https://github.com/chromium/chromium/blob/3d41e77125f3de8d72...
[2] https://github.com/chromium/chromium/blob/78aae16be65e409075...
Mozilla needs to put more resources on Android.
https://www.wired.com/story/google-wants-to-kill-the-url/
WTF? People get angry when you just move their cheese without notice.
Sorry, unrelated, but ahah, what is this saying? I love it and have never heard it before. I guess it's from some sort of book? https://hbswk.hbs.edu/item/cheese-moving-effecting-change-ra...
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.
> Another case I ran into:
> "subdomain.www.domain.com" displays as "subdomain.domain.com".
The other two: Google may/may not be pushing the open web standard towards their own AMP pages, instead:
https://news.ycombinator.com/item?id=17920720
Google wants to get rid of URLs but doesn't know what to replace it with:
For a couple of hours, I thought Citibank Singapore's website was down.
If one tries accessing citibank.com.sg, there's no redirect to the www. subdomain. (That's still the case, if anyone wants to try.)
If Chrome didn't hide the www., I would have been able to tell from Chrome's search/address bar that the various banking services that I've been accessing were all on the www. subdomain.
While that is shoddy implementation on Citibank's part, hiding the www. most definitely didn't help with the troubleshooting process.
This is standard incumbent behaviour, they are drawing up the moat bridge, inch by inch.
It's not like they're just changing stuff randomly. The TLS padlock change has been going on for a while now, and not without reason. As we get to a point where almost everything is served over TLS it doesn't make sense to tell the user every time. It makes more sense to only notify them of the exceptional situation where we're on an insecure connection.
The certificate authority system is terrible, but it's what we have for now. There's been some advances to help make it better though. CT for example, ensures that if anyone starts making fake certs we can all see it at least.
I suspect (and hope) that browsers will slowly transition to using trusted spotters to verify certificates in addition to (and eventually instead of) authorities. If you remember a few years back when moxie marlinspike made that promising, but underspecified cert verification system that relied on the user supplying a list of trusted verifiers and the browser basically goes to each of them asking "I see cert 88:A4:etc" for domain "google.com", do you see the same thing? The idea was to make it really hard to MITM someone since you'd also have to MITM every verifier the browser asked. Not impossible, but probably harder than getting a fake cert under our current system.
That's why they're getting rid of it.
https://blog.chromium.org/2018/05/evolving-chromes-security-...
While sure, www seems odd now, it's still a subdomain and we're inching into territory of obscuring things that matter for small gains in end-user perception that aren't _that_ impactful.
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.
Say, for example, if the canonical URL doesn't have a "www" in it?
* login.<target_site>.www.com -> login.<target_site>.com
* members.<target_site>.www.com -> members.<target_site>.com
Even some carefully chosen <target_site>.www.com's will now be valuable:
* login.www.<target_site>.www.com -> login.<target_site>.com
What a stupid idea...
For this to actually help scammers (after the bug is fixed) they'd need to own www.example.com but not example.com, which is unlikely to say the least.
This is just removing data that is useless and confusing to 99.9% of users - whats the problem?
What happens when you copy and paste that URL?
Now every single website that wants to support Chrome needs to ensure that https://foo.com is always redirected to https://www.foo.com, or at least works as if it's www. It doesn't matter that most websites already do this, it's not standard, and represents Google breaking standards because they are big enough to do their own thing.
It's just one of the 1000s of papercuts that google is inflicting to keep users from switching web browser.
What ISPs teach their users anymore these days? Why the heck do we want to go back to that?
Time for a modicum of historical perspective.
If you care about usability this is clearly an improvement. This is part of a long-running industry trend -- Safari does this too -- to improve the usability of the Internet and technology in general.
At EVERY STEP in that journey there has whining and griping from the more technically advanced folks (like all of us on this forum). They zero in on the negatives, the tradeoffs that come with simplification. They don't see the positives because they're technically advanced enough and don't benefit from simplification (or so they think).
Then after the griping whines (sic) down and they realize the world didn't end and the downsides really weren't that bad and we move forward towards a better, simpler, more usable web.
Like, who actually runs separate HTTP servers on example.com and www.example.com anyway? Everyone is hyperventilating over contrived "the principle of it all" examples. Bottom line, Apple & Google are putting usability above technical pedantry. That's the right priority for mass market technology products.
Like, big companies run separate servers on the two domains.
That's besides the fact where if you have www.example.www.example.com, it rewrites to example.example.com.
1. "m.tumblr.com " and "tumblr.com " are BOTH displayed as "tumblr.com" even though they're literally different sites.
2. "www.example.www.example.com" displays as "example.example.com" which means all "www" subdomains, whether leading or not are being stripped out.
3. In the extreme case, "www.m.www.m.example.com" shows up as "example.com" which is pretty misleading.
Usually, the Chrome team is very thoughtful about decisions that impact security. I'm surprised this was released in such a half-baked state. I hope this is not an indication of how Google's plan to "kill the URL" will work out.
This isn't the first time it's happened.
Take the https-everywhere changes. If you explicitly type something like "http://example.com.:80/" but the browser knows about an SSL cert for the domain, it will attempt to shuttle you off to https, failing to do the SSL handshake because of course it's port 80. Adding the protocol and the port isn't enough of a hint that I know what I'm trying to do.
What's worse, this is a domain-wide setting. If you have say, local.example.com, the browser will try to protect you again.
You have to go to an obscure preference and make the browser forget about this on a domain-by-domain basis, which will reset the next time it gets a wildcard SSL cert for the domain.
This thing is of the same vain, it's the new Ctrl-Q of the browser world; a feature that, due to some dogmatic ideology, doesn't have a "knock off the bullshit" setting.
Somehow irreversibly child-proofing software by making it not do what you tell it and hide important details has become fashionable, it's nonsense and needs to stop.
I'm noticing despite the invocation of vague concepts of progress and usability... you haven't articulated any particular case for how this represents either. No model for why it's simpler or more usable.
"Safari does this too" or imprecise aspersions about the supposed "whining and griping from the more technically advanced folks" doesn't really cut it.
I could guess that what you mean is "oh, if you can omit something and yet it's implicitly understood, obviously that's a simplification," though that's obviously a guess. If I've misunderstood, well, there's counterexample #1, to get a little meta. If I've managed to guess correctly, the broad topic of language and notation is a fairly rich well as to the potential for ambiguity or outright miscommunicated meaning when things are moved from consistent and explicitly denoted syntax to implicit syntax. Or examples for when the implicitly understood isn't particularly burdensome to use or even require in some cases.
"the world didn't end" .... lots of bad ideas that make things marginally worse don't end the world.
"the principle of it all" Again, this is a pretty vague and imprecise charge. Do you understand what the particular principles people are registering their objection on? If so, why not name them and respond?
I am genuinely interested in knowing if this is a usability improvement. Citing "Apple does it too" is not convincing to me.
It seems to me if URLs are meaningless to you, hiding part of them is meaningless to you so why do it? It seems just as plausible that it's only unusual subdomains that confuse users ("Is foobaz.example.com the same entity as example.com?!"), so hiding common ones might only make uncommon ones more confusing.
This is a false dichotomy. There are tons of ways to improve the implementation without just hacking parts of the URL out of the "omnibar."
You could split the omnibar and/or allow it to be resized so both pieces of information can be shown. You can use differential color highlighting and/or text formatting to convey which parts google considers "trusted." You could implement an "expert mode" button somewhere that turns all of these "improvements" off. You could add an extra field that shows security-critical information not just about the URL but about the resulting connection(s) to the host.
This is hardly exhaustive, which is also a good description for Google's effort on this one.
The cost/benefit doesn't work out. It's a usability improvement, but it comes with a huge cost, where many, many sites have the fundamental function of a URL -- that of an address/specifier across the internet -- basically broken. The person who implemented this change either didn't work out the cost, or decided they didn't care.
Everyone is hyperventilating over contrived "the principle of it all" examples.
How would you feel if primary keys in your database started to change their semantics? How would you feel if your phone started to change the telephone number it dialed? I guess we're kind of alright with the message app editing our messages as we type them. Now we're supposed to adapt to our tools, not the other way around, and insisting on tools doing what we say is "pedantry."
>Like, who actually runs separate HTTP servers on example.com and www.example.com anyway?
My university doesn't work with example.com but does work with www.example.com. I see how someone could waste a lot of time trying to solve a nonexistent network issue because typing example.com doesn't work, but he had seen it working before.
I personally feel like any negative user experience should be addressed by the developers of the website, not the browser.
Meanwhile I'm sure there are people out there who want to maintain a distinction between www.x.y and just x.y.
I do. Over and over again. Having been doing that for 2 decades, and with a limited budget, I require things like SNI[1] to work. But of course, I could just triple the tech budget...
EDIT: And wrt "Time for a modicum of historical perspective." - please give it to me. I am keen to learn what I did wrong all the time.
However, Chrome should handle this intelligently like it does with localhosts vs. internet hosts. If you manually type in "http://" into the address bar (e.g "http://my-local-domain"), it will not search the usual DNS and will honor any locally configured domains you may have on your network.
This doesn't seem to be the case now with this 'www' concern, though. With slenk's example of http://www.pool.ntp.org and http://pool.ntp.org - the only way to access the second link properly is to click the link. Typing it in the address bar loads the same website as first link - so it appears Chrome is automatically adding 'www' or somehow making the request differently making the second link's page inaccessible via the address bar.
Browsers are supposed to be as unopinionated as possible since they are browsers, not mediators, and their job is to implement the standards of the web.
https://www.aishitei.ru vs https://aishitei.ru vs https://kimiwo.aishitei.ru
I never set up a www cname, but now unless you're paying attention (or actually reading error messages) you might not notice that the reason it failed is because you're not at the domain but on the `www` subdomain. The URL bar doesn't convey this information until you click it and then it shows the full URL.
It's really minor but I also don't see a good reason to do this. All the sites hosted by the company I work for are hosted on `www.` with the intention that it "looks more professional".
Is it really a big deal if you serve the wrong content 1% of the time?
When a website requires "www" to resolve and respond, who in their right mind would want it hidden in the displayed URL?
So fine, don't display the URL. Define a full-on standard that lets a user agent show a "friendly but not unwieldy" name to the user. You have that funky Graph API or whatever Facebook started to allow URL posts in Facebook to expand to include site info. Why not just use that at the top of browse? Then design the browser to allow access and editing of the URL somehow if desired (an old browser called 'OB1' didn't display the URL unless you pressed Ctrl-W, for example), but don't display it by default.
The truth is probably not many technical people directly enter URLs in browsers any more.
Honestly maybe it wasn't a good idea to allow query strings in URLs. Perhaps deprecate them and keep URLs looking like hierarchical filenames. Which honestly, is still something difficult to understand for non-technical people.
But this crap of hiding parts of it is dumb.
The "trivial subdomain" will show when you click the url bar, however.
This is Google making subdomain usage decisions for other entities outside of Google. My domains and how subdomains are assigned and delegated are not Google's business to decide.
But I'd prefer they did it in another way which doesn't involve hiding anything. For example, render the most important parts of the URL in bold type, a color that contrasts more, or a slightly larger point size.
That way, you still make it easier for the eye to pick up the parts that the browser believes probably matter most, but you don't make it impossible to see the parts that might also matter.
It must be this. They haven't given a single positive reason, except "users need not concern them with this information", which is so vague it's not even a reason.
Google is still (partly) a search engine, and people interacting with the address bar is pretty much the opposite of using a search engine. So Google wants to discourage that. They will never teach users how URLs work, how to read them and definitely not how to construct them, because it makes people less dependent on their search engine.
Think about it. Even the security part. Google wants to be the arbiter of what is secure and what is trustworthy. Anything that lets users figure this out for themselves, or that can be mediated without Google coming in between, takes away from this power.
They don't show http/https any more, just a coloured lock icon. The meaning of that lock icon is for Google to decide, unlike the meaning of http/https.
Now they take away information from the address bar, claiming it is irrelevant and none of our concern. They just want you to click on the links in their search engine, or some app or assistant thing.
One thing it is NOT about though, is distraction. If anyone knows that users can tune out irrelevant information perfectly fine, it's Google. They are an advertising network, after all.
plus
>"subdomain.www.domain.com" displays as "subdomain.domain.com".
and
>http://m.tumblr.com/ [1]
Hoo boy. Can we officially call this a "shit-storm"? It seems extremely poorly thought through.[2]
[1] seriously, visit that right now. utterly brilliant username, I wish them all the best.
[2] unless you want to sell invisible AMP URLs. but then I want you to lose your job.
BTW, it sucks that existing comments cannot be voted or reacted with emojis, they should know this: https://bugs.chromium.org/p/monorail/issues/detail?id=4248
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
www.google.com/chrome/whatsnew
"www." is useless. Eliminating it wouldn't be a bad thing.
"m." for mobile sites is extremely archaic. Sites should work on mobile without special subdomains.
If you issue subdomains to strangers on your root domain, the URL bar showing the subdomain shouldn't be your "security model."
The root domain is the root authority behind the site in question. Chrome showing users that information in a clear and concise way isn't "subverting the domain name system".
Safari has been doing this for a long time, and Chrome/Chromium have settings/flags that allow you to turn this behavior off. The amount of crying over this change is ridiculous in my opinion. As long as they keep this configurable (in fact, they should add a UI config for it) I see no problem here.
> If you issue subdomains to strangers on your root domain, the URL bar showing the subdomain shouldn't be your "security model."
What do you propose instead? Azure gives me custom subdomains for my servers that are immensely useful, being much more regular and memorable than IP addresses. I only see two solutions here: stop doing that or let anybody with access to subdomain creation pretend to be "azure.com". One of them is comically dangerous and the other is throwing out a perfectly good feature to save a handful of characters in the URL bar.
No other reason given besides that very vague assumption about .. I'm not even sure, say if most users need not concern themselves with information that isn't there, does that mean they would otherwise be concerned about it? And what does that mean? And how is it bad? And why don't you just say so?
I'm calling bullshit. If there is a reason why they decided this, it is not that. My bet it's something political.
While I'd personally disagree with these kind of changes, and I would always prefer it to show the http/https and the www dot, it doesn't actually break things like copy and pasting the URL from the address bar. You still go to www.google.com when you type in www.google.com, it's just trimming away the www dot displayed in the address bar.
I think for the vast majority of non-technical people it's not really going to make even a little bit of difference. If anything it'll make it easier to spot what domain they're on, assuming they're even checking to begin with.
https://bugs.chromium.org/p/chromium/issues/detail?id=872665
So are https://example.com and http://example.com.
If you serve materially different content based on small differences, that's user-hostile, and common tools have no obligation to support you. Chrome shouldn't cater to sites that change behavior based on a www prefix, because the vast majority of users expect those sites to be the same. Hiding the prefix won't change their mind.
news.ycombinator.www.com would get normalized to news.ycombinator.com (not sure what would happen when using the www tld)
That's an extreme example, but there's an obvious security risk. This is a half assed change with buggy behaviour, regardless of whether you think www.domain.tld is materially different from domain.tld or not.
So basically a dumb design-by-committee change that just wasted effort for negative progress.
I would wager the twelve character prefix "https://www."would make no sense to 99.9% of the users and should be the default for over 99.9% of requests they would be making any given day.
I am guessing Google has evidence that this is the case.
We were able to somewhat break up microsoft's attempt at something similar in the 90s through anti-trust legislation, perhaps it's time to look at google?
On a side note, it seems like the openness of the internet has come under attack more and more often in the past few years, from a combination of corporate and government entities. It's absolutely essential that we keep the internet open, transparent, and free.
So, not similar at all?
URLs may be weird but they are not so complex that we need these games.
This is why the History channel shows reality TV instead of programs about, you know, history. It was decided that "history" that doesn't involve celebrities, aliens or Nazis is just too boring for normal people.
Google has decided that the 50% of population who are confused about the basics of URLs are more important than the rest of us who have been using them for over 25 years without problems. This will in theory allow Google to target a larger swath of the population. In practice, it simply takes something useful away from the rest of us.
It's "digital ochlocracy": The targeting of the least common denominator to the detriment of those with greater knowledge or expertise.
I suspect that Google wants to gradually get rid of URLs, because if users can't identify websites by their addresses, they will be more dependent on Google Search. Landing on search pages means that users will click on more of their well-concealed ads.
I think it's also the reason why Google Chrome's URL bar has such terrible auto-completion functionality. It appears designed to send users to Google Search to click on ads instead of taking them directly to their destinations. Firefox's old address bar didn't do that. (The newer address bar in Firefox appears to be following Chrome's time-wasting functionality, and its auto-completion no longer works well.)
Without URLs, users won't know whether they are really on your site, viewing your content on google.com (via AMP), or in some kind of app or PWA. To get to an item of content, most people will end up clicking on an ad in Google Search or land on an AMP page that eliminates most monetization options that don't involve passing the money through Google's systems.
URLs shouldn't be trimmed at all. When you're on the URL, http://example.com/, (note the trailing slash), Chrome will only display "http://example.com", even if you copy it onto the clipboard. (It's still possible to fix it in Firefox with about:config.)
Technology shouldn't be made more restrictive and stupid -- users should be taught how to use technology correctly, and they will adjust. I've even met professional programmers who don't really understand URLs because their browsers mask the real URLs. The WWW isn't only about consumption -- it's about creating as well. People need to know how it works in order to create things.
No more red purses? Give me a break.
If technical users want their own browser mode, where all these things are readily available, then I'd be all for that.
Clicking on the browser location bar should reveal the full URL. But the noise of the protocol, the www. prefix, and the param string is all irrelevant to the experience of the casual user of web browsers and should indeed be hidden. We're already hiding a ton of stuff from them already, if you want to go see it, you can always "view source".
One argument in the thread was that 'www.pool.ntp.org' and 'pool.ntp.org' go to a website and a nameserver respectively. Nontechnical users will never want to use a web browser to access a nameserver, so there's no UX benefit to distinguishing them. From a URL entry standpoint, it should go to the URL that was typed into the location bar. There isn't a conflict.
Edit: well I was right, this breaks in the new Chrome, http://m.tumblr.com/ , tumblr usernames on the 'trivial' list are broken.
> "subdomain.www.domain.com" displays as "subdomain.domain.com".
This is very deceiving. This change gives phishers a huge opportunity.
[1] chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains
Now I know Chromium is developed by bunch of idiots who don't understand the practical consequence of omitting the part of domain name.
Maybe instead of masking users from the "complexity" we should be teaching them instead.
On a completely unrelated topic, there is a bug I'm noticing: ICANN doesn't allow emojis in TLDs.
What? That's ridiculous-- I can put them in the main part of the domain name along with an enormous number of cute homoglyphs. So why not smileys and homoglyphs in TLDs? If users can deal with smileys in the main domain that tells where the site is, surely they can deal with them in the little extra part that comes at the end. Everything's just .com underneath anyway so what would problem be?
Google has done the work to remove the unsafe part of domains. Now our domains can really shine. So give us more bling to put in there, ICANN! C'mon.
Also-- why not www as tld? I love "biz" and "pizza" as much as anyone, but excuse me they got nuthin on the world wide web. C'mon ICANN give us "www" in the Trailing Little Domain! We're ready for it now! :)
Best, Your Userbase
I'm sure it never used to do this. Did it?
Please, predictability and consistency is what helps newcomers, not pandering to prejudiced intuitions.
Still..with Google's horrible AMP efforts this seems nice :)
And what if I setup a domain with a subdomain of the www? I'm sure also someone clever could find a way of using this for phishing.
1. www.* doesn't end up as a 404 or DNS resolution error
2. www.example.com matches the content from example.com
3. www.example.com -> example.com is a valid permanent redirect
and then finally
4. Publicly shame them. Don't hide it from people because you run into all sorts of UX issues.
I really hate www. for a multitude of reasons, but the biggest one is just thinking about the amount of time spent saying it out loud. Nothing aggrivates me more than turning on the radio and hearing "go to our website DOUBLE YEW DOUBLE YEW DOUBLE YEW DOT <some long name like nelsonfurnishingandrepair dot com>". That's like two seconds of air time they could recover.
> "People have a really hard time understanding URLs" - Adrienne Porter Felt, Chrome's engineering manager.
> "But I do know that whatever we propose is going to be controversial." - Parisa Tabriz, director of engineering at Chrome.
URL's is already dead.
Visit "www.apple.com" in Safari and you will get "Apple, Inc" in the URL bar after a moment.
This seems like a potentially reasonable choice until you realize that someone could register, say "Apple, Inc" in another state and get a HTTPS cert to match it. One phishing email later and the Safari user is convinced they are logging in to the correct domain.
I can see lots of new phishing attacks made possible because of this. :(
I dumped Microsoft when they tried to shove Windows 10 down my throat. I use them only when I have to now.
It's now Firefox for me.
Chrome on my work laptop doesn't even bother resolving a name that certainly does not look like an url but exists in the network.
Instead it will look it up on (guess what?) Google.
Most. Not all.
The browser is doing something out-of-spec for really no reason at all and it has the chance to break some sites.
www.domain.com and domain.com are never guaranteed to go to the same page. Yes, out of modern convention, they do now, but it's only a convention. Sites are free to break it, and some do, so to make this change is a bad idea.
I'm assuming you can always click to expand and show the full URL.
For a lot of people (devs especially) it would be nice to be able to change an option to see the whole URL at a glance, but for most people it's just a confusing mess they have to look through for the domain name.
disables this new "feature"
Spearphishing is still one of the most common ways of breaching a corporate network. If I target you, you will likely fall for one of my attempts. If you are a company rather than a person, my odds go way up, because I have N chances to trick someone rather than 1 (where N is roughly the number of people at the company with email access).
This is one of those things that everyone says "Ha, I'm smart. I'd notice. You can't trick me."
And maybe you are. But you're also distracted. And that's my greatest advantage against you. All I need is to sneak in an unexpected Github prompt that looks completely authentic, and now I have your Github password. Wanna bet you don't have 2FA turned on, even though you know you really ought to? And even if you do, it's getting easier to social engineer your way past AT&T's lovely customer support: https://www.youtube.com/watch?v=caVEiitI2vg
Ok, what's the point?
This: Every character in the URL bar unrelated to the apex name is a deadly distraction.
Right now, how do you know you're actually on HN instead of some knockoff? "ycombinator.com".
How many characters do you have to read unrelated to that? "https://news. /item?id=17927972"
The most vital part of a URL for vetting identity is also, usually, the hardest to see.
Now, I don't know whether google made this change in order to assist with this. But it's one possible justification, and a step in a good direction.
We may not like it, just like we didn't like when Google removed the clickable "cached" links from search results, but in this case consumer protection outweighs our urges as a power user.
Instead, make the key part stand out, so even a cursory glance catches it instantly. It still allows more careful examination without clicking anywhere, or second-guessing.
Also, detect anomalies like www.google.com.hacked.domain.wtf, and show them in a really contrast way. Both Chrome and FF do this already.
I think Firefox shows normal URLs about right; they could add even more contrast.
I'm not convinced. When your tools lie you (as this does), you are LESS likely to notice a problem when you're busy. Another way to view this approach is:
> Every character in the URL bar different from the actual URL is a deadly lie.
Distraction is a problem, I totally agree, but other methods like Firefox's color-shading seem to work just fine.
and then
https://fake-original.blogger.com
if I make them look the same, and the address will hide the subdomain, it looks like a step backwards in securing the web
now, imagine the actual platform has a payment section, and I create a fake subdomain that looks pretty similar, email you, boom, I get your cc info because I tricked you into entering new cc info (assuming your scenario of someone being distracted)
For starters, it doesn't work for non "www." subdomains, for example... news.ycombinator.com isn't protected by this solution.
A better solution IMHO, would be to do it like firefox, grey it out.
Flag websites that look like phishing URLs - websites that contain domain names of popular websites in their subdomains or other parts of the URI. But initially, don't do anything. it could be harmless. AMP has domain names in the URI, right?
But, as soon as the user starts typing into a text-entry field (especially a password one), you bring a pop-up warning them that this might be a phishing site.
>http://www.example.www.example.com -> example.example.com
What the fuck. I don't even.
At least they haven't been as idiotic as Apple and didn't remove everything but the domain name like Apple did, and they did it incrementally.
Please submit any complaints you have as a video on YouTube.
So they're doing it again, just slower: https://www.extremetech.com/computing/276454-google-wants-to...
I'm pretty sure the eventual plan is to force everyone to browse the web using a version of the App Store, which we all know is incredibly secure, and never difficult to use.