14 ms·

in the address bar again

257 points by heyyyouu 7y ago

redder2 7y ago
I use Firefox anyway and I would be fine with hiding the https:// https:// and the green lock shows its https anyway but I do not get the subdomain hiding, not on desktops, tablets, phones with enough screen space anyway. If its really limited then maybe with some symbol that indicates that there is something missing there.
kenforthewin 7y ago
This is extremely annoying for a project I'm working on that involves subdomains. If I set nginx to redirect `example.com` to `www.example.com` I want to verify it in the browser.
- notatoad 7y ago
  my chrome hasn't updated yet, but my understanding of this change was that you could display the full unmolested URL by simply clicking in the address bar. is that not the case?
  - blahyawnblah 7y ago
    double clicking. but still.
    - quink 7y ago
      Wow, that is mad. So glad I switched to Firefox.
- _-david-_ 7y ago
  You probably should be checking in the console network tab to make sure you are getting the correct HTTP status code (301 vs 302).
zzo38computer 7y ago
I absolutely do not want it to hide any URI schemes or subdomains at all. (I am able to change these settings in Firefox, at least. I could also disable Unicode rendering for the domain name, but to disable Unicode rendering for the filename I had to write an extension.)
- cpeterso 7y ago
  By default, Firefox's address bar hides the http:// http:// scheme but shows the https:// https:// scheme (to emphasize that the connection is secure). Firefox users that want to see the http:// http:// scheme can set the "browser.urlbar.trimURLs" about:config pref to false.
- wildrhythms 7y ago
  FYI you can revert this behavior in chrome://flags chrome://flags/#omnibox-ui-hide-steady-state-url-scheme chrome://flags/#omnibox-ui-hide-steady-state-url-trivial-subdomains chrome://flags/#omnibox-ui-hide-steady-state-url-path-query-and-ref I just disable all of these.
Rebelgecko 7y ago
Google must really hate URLs. My search results recently stopped showing the full path of the URL, just the domain name. It was a huge pain because I was looking for an item at Ikea and couldn't tell if a result went to their American site or to their UK, Saudi Arabian, Qatari, etc. site (apparently the same item can have small differences in different countries— I almost bought the wrong lightbulbs because the UK version of my lamp uses a different size bulb).
- privateSFacct 7y ago
  Google sees folks falling for google-secure-payments.google.via.net type URLS. They see all the gaming people do with URLs in search results (including abusing the names of other brands like Amazon). There are lots of developers who like distinguishing these subtle topics. I can tell you in a larger enterprise deployment most of these changes will be welcomed (yes, people do still click on bogus URLs believe it or not - FAR more often than I would expect). Or think that the url amazon.lowprice.com is an amazon website in a search result. Folks claiming google is hiding the owner of the website forget that the actual owner of the website is reflected by the END of the domain name, not the earlier parts. In some shared hosting situations this is confusing, but in the end whoever controls the end actually is in control.
  - ljoshua 7y ago
    I'm wondering how the particular address bar change helps alleviate this though. As I've seen it implemented, the only subdomain they'll "elide" is www, so if it is google-secure-payments.google.via.net it will still show as such in the address bar, not as via.net. So I don't understand their reasoning in how this will help from a security standpoint.
  - danShumway 7y ago
    > google-secure-payments.google.via.net How does hiding www help with that? It seems to me that a decent scheme to make the domain-owner more visible would be to separate out the domain and display it separately from the entire URL, the way that Safari does. I'm not a fan of Safari's changes, but at least its easy for me to see how they could improve security -- it's a decision with real benefits, and the only question is whether they outweigh the downsides. But it's difficult for me to imagine a phishing scenario where hiding `www` will make things better. The only scenario I can think of (where `www` redirects to a different site) is made worse by hiding it from the URL.
badrabbit 7y ago
URLs represent and identify content,controling them means you control content. In the short term these changes mean little but in the long term this will benefit google immensely. Google just loves slippery slopes. Identity and payment are extremely important to any ordered system of social interaction. More than content itself,controlling them helps one control everything else. I am trying hard to avoid believing conspiracy theoris about Google. Maybe a legal requirement for intetnet standards compliance makes sense?
- privateSFacct 7y ago
  The focus of this change is to improve the identification of content. This coupled with payment has been subject lots of fraud where users misled about the owner of a website. google-payments-secure.via.net is not a google payment website despite the google in the domain name. The key part that signifies the ownership / identify of the person hosting the site is the END of the domain, the google.com part. That is the owner of the web property, not whatever appears before that.
  - reaperducer 7y ago
    Or Google can stop cramming things in the top of the window and let us see the entire URL.
  - hermanradtke 7y ago
    There are other ways to do this that do not hide parts of the URL. Educating people should not hide information, but instead present information in a way that is more understandable. I think the Chrone team is making URLs harder to understand.
  - badrabbit 7y ago
    That's what google uses as an argument too and I am too familiar with the problem. The problem here is that Google is in control of the solution and the solution is designed by them without consulting everyone else and in a way that would be advantageous to their long term dominance and prosperity. I don't trust google and they certainly don't have my consent to shape the way I and the society I live in interact with each other. I will say it a million times if needed. I do not trust google. Period. They ask forgiveness instead of permission and they love slipperly slops and bait-and-switch psychology tricks to get their way.
mr_puzzled 7y ago
Off topic : there seems to be a disconnect between the chrome devs and users. Another instance was the automatic signing in to chrome incident. I've lost trust in the chrome team and have switched to Firefox full time and honestly there's nothing that I miss. The firefox devs seem to better understand their users, frequently blog about changes that positively impact users. I have a lot more faith in firefox even though it's not perfect (mr. robot incident and others).
- tedivm 7y ago
  I think the chrome team just considers its users to be your average corporate america employee, and no longer considers developers or tech literate people to be their main market.
  - xemdetia 7y ago
    I doubt that, because the number of times they completely ruin chrome as an intranet browser in the last few years with TLS handling, self signed cert handling, and general settings window changing malarkey shows that they are not even catering to that market very well, especially when they add a workaround and take it away in a very short window which for better or worse is often much shorter than most large organization's change control windows. Firefox generally keeps most workarounds working for as long as I've needed to worry about it, but Chrome's timelines seem arbitrary and the UI changes make keeping Chrome configuration guides a constant churn.
    - magicalist 7y ago
      > ruin chrome as an intranet browser in the last few years with TLS handling, self signed cert handling, and general settings window changing malarkey Just put it in the OS certificate store? It's worked like that since Chrome was released.
      - hannob 7y ago
        I think the issue the upper poster is referring to are things like when chrome deprecated ancient certificate features, which enterprise-solutions still happen to use by default 15 years after they were deprecated. (One such issue were certificates with a common name and no subject alt name.)
pmccarren 7y ago
I'm certainly not a fan of the new URI scheme, but it is worth pointing out that Safari has already made the same change. Furthermore I'm not convinced said change is a net-negative for the average consumer. Safari added the setting "Show full website address", which does just that. I wouldn't have a problem if Chrome followed suit and defaulted to the new scheme, but gave us the option to show the full URI.
- pwinnski 7y ago
  I was reading your comment thinking, "What? No!" and then kept reading. I apparently checked "Show full website address" when the change was first made.
- cpeterso 7y ago
  Safari only shows the domain name. Chrome still shows both the domain name (minus "www.") and URL path.
  - type0 7y ago
    Allright, now we know what's coming...
  - pmccarren 7y ago
    Check your Safari setting "Show full website address". Checking it will show the full URI.
- AnIdiotOnTheNet 7y ago
  > I'm not convinced said change is a net-negative for the average consumer. And this is why modern technology sucks.
josteink 7y ago
Google wants nobody to know URLs exist, and that everyone is forced to search Google for everything, even sites they know, and there visit fake AMP-sites portraying to be from a server they are not, all while Google tracks every single keystroke you make. This is just another tiny step in that overall plan, and it is 100% evil. Don’t waste your time trying to talk the Chrome-team into reason. You are not their customer, nor their employer. They will not listen. If you don’t like what Google is doing, use other products. Firefox, DDG, iPhones etc.
- type0 7y ago
  General population already thinks that the Web has been taken over by Google and that "social media" is Facebook and Twitter.
- joshuamorton 7y ago
  Firefox and Safari already made similar changes. Safari made the exact same change, and Firefox hides http:// http:// already, but not https:// https://, chrome is just using a lock icon to represent the https:// https:// instead of the actual string.
  - zzo38computer 7y ago
    As mentioned, at least this setting can be disabled in Firefox. (I don't know if this is possible in Chrome.)
    - wildrhythms 7y ago
      Since nobody replied, I mentioned this in another comment that you can revert this in chrome://flags https://news.ycombinator.com/item?id=20631676 https://news.ycombinator.com/item?id=20631676
  - josteink 7y ago
    Firefox doesn’t hide the WWW subdomain. The domain-name remains unmangled.
- 7y ago
type0 7y ago
If I have one webpage with different languages and want my visitors recognize it from url, what are the options? Previously I could have www.example.com/en/ and www.example.com/fr/ etc If subdomains are not possible there's no hope that visitors using Chrome would see it?
- deleted 7y ago
  [deleted]
- knd775 7y ago
  Subdomains in general still show, just not www. Also, in the case you mentioned, the subdomains are the same. The path still shows.
  - type0 7y ago
    Thanks for correction, I confused that with technically handicapped Safari Browser then.
- deleted 7y ago
  [deleted]
- joshuamorton 7y ago
  Unless I'm grossly misunderstanding, those would still show up as `example.com/fr/` and `example.com/en/`. Heck, if you use `fr.example.com` and `en.example.com`, those would also work.
RandomGuyDTB 7y ago
This is great and all until you (like me) need to be able to differentiate www.example.com from example.com and https:// https:// example.com versus http:// http:// example.com. My website doesn't forward example.com to www.example.com (due to errors on my part that I don't know how to fix, my email is in my profile and if you can help I'd greatly appreciate it). I don't know if there are any scenarios in which a properly-configured website (mine isn't) needs to differentiate example.com from www.example.com. But I liked the ability to do so easily.
- notatoad 7y ago
  >need to be able to differentiate ... https:// https:// example.com versus http:// http:// example.com this requirement is handled by the "not secure" badging, which is much more obvious that requiring users to pick out the "s" in the middle of a string. https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...
- jammygit 7y ago
  Can you just set a CNAME record in your DNS settings for that redirect?
- JorgeGT 7y ago
  Based on your certificate, are you using Cloudflare? If so, this shows how to handle these redirects: https://www.bybe.net/cloudflare-enforce-ssl-redirect-http-https/ https://www.bybe.net/cloudflare-enforce-ssl-redirect-http-ht... I use Github pages+Cloudflare to host my page and that's how I do it, free and quite resilient.
- UncleMeat 7y ago
  HTTP headers are hidden. That's great and all until you need to examine them for some development task. iframe URLs are hidden. That's great and all until you need to verify that your iframe is loading the correct content. Yet people don't complain about these. They are happy using the dev tools to access this information that is sometimes useful for developers and almost entirely useless for ordinary users.
dlandis 7y ago
It's just so bizarre how strongly the Google product people continue to insist that this change is beneficial to users when so many users themselves simultaneously insist that it's not. Combined with the fact that their explanation is dubious at best (i.e. www is not a technically a "special case"), I find it very hard to believe they do not have additional, confidential reasoning for making this change.
- annadane 7y ago
  Yeah forums where the company "interacts" with users is great. "This change is beneficial." "No, it isn't." "Yes, it is." "But it isn't!" "We respect your feedback but we're implementing it anyway."
_o-O-o_ 7y ago
What a slippery slope. I imagine a future when the entire URL itself has disappeared and we live in some sort of Google-controlled walled garden environment, like what they're trying to do with AMP[0]. Some sites only work with WWW prefixed as the APEX DNS record is misconfigured and points to nothing. I've even seen some sites point to `0.0.0.0' but had a CNAME record for WWW and I could then view the site. [0] https://developers.google.com/amp/ https://developers.google.com/amp/
- y_molodtsov 7y ago
  Then these websites are broken and needs to be fixed. In the end, the most of the people would probably search for it in the first place.
  - aaomidi 7y ago
    This is a stupid argument. Subdomains are part of the standard of the web. They shouldn't be hidden.
  - horsawlarway 7y ago
    broken according to who, exactly? It's entirely reasonable to choose to host http/https traffic on a www subdomain and host entirely different services at the non-www domain. The internet is not just http traffic. Full fucking stop. There are plenty of systems and industries where the actual web front-end is an after-thought.
jdashg 7y ago
This reminds me of how Windows frustratingly hides file extensions by default. This sounds low-upside/high-downside to me, but it's the sort of thing with simple arguments-for (easier for clueless users! Cleaner!), and nuanced arguments-against (eliding rarely-useful details in special cases causes ambiguity, and can lead to confusion is some cases, particularly for clueless users).
- zzo38computer 7y ago
  And, there is a setting to tell it to not do that, but even then, for some files it is hidden anyways. But, it is possible to use regedit to change it so that the extensions are not hidden even for those cases.
  - sjs382 7y ago
    Editing Chrome flags is similar to editing the Windows registry. Here are the relevant settings: chrome://flags/#omnibox-ui-hide-steady-state-url-scheme chrome://flags/#omnibox-ui-hide-steady-state-url-trivial-subdomains chrome://flags/#omnibox-ui-hide-steady-state-url-path-query-and-ref
    - Jaruzel 7y ago
      Until they take those away. The Chrome devs have an annoying habit of removing flag options once they consider the 'feature' to be out of beta.
  - zrobotics 7y ago
    On windows? I've never experienced/noticed this, what extensions are still hidden? Hidden files is a separate setting from hiding extensions (which is good), but I've never noticed a file that wouldn't display the extension after changing the setting. I can't remember specifically for any of the earlier versions, but this has been my experience on 7 & 10.
    - berns 7y ago
fadisaleh 7y ago
Can someone help me understand why this is a big deal? Safari has had this change for a while and I haven't felt like I'm missing anything. Where's the slippery slope? Does have to do with AMP?
- heyyyouu 7y ago
  It has nothing to do with AMP. There's a lot of reasons why, but one reason is for example, two different sites can technically be hosted on www. and the non-www version, if the site isn't set up to redirect the www to the non-www, for example. So this could, in certain scenarios, pose a security risk in that if you pretend that www and the non www are the same sites -- when they're not -- it can make it easier for those that hijack one or the other to get away with it. Now, that's fairly extreme and esoteric. But there are actually times in development when you use subdomains, which this makes more difficult, and there's other subdomains they're considering trivial which, in fact, aren't. This is really good discussion on the topic and why this change just simply ignores so many technical issues, best practices and simply realities: https://bugs.chromium.org/p/chromium/issues/detail?id=881410 https://bugs.chromium.org/p/chromium/issues/detail?id=881410
- toast0 7y ago
  Here's a problem: people often share screenshots with the address bar in the screenshot. If they share it from Safari with default options, the address is mostly useless, it's just the domain (and www may elided), but it doesn't even look like a url, so whatever. If they share it from Chrome with these new options, if it's like the last time Chrome released this, it looks like the full url, but it's not: When you go to https://example.org/some/deep/url https://example.org/some/deep/url it may very well not be the same as https://www.example.org/some/deep/url https://www.example.org/some/deep/url and adds an extra layer of confusion to figuring out whatever the issue is.
toast0 7y ago
This behavior will train users to believe that the www in domains isn't important, when it actually serves a very important purpose. You can't cname example.org, which makes it very hard to use a CDN to serve it unless the CDN provides anycast ips or you delegate DNS to the CDN. If they're intent on making the address bar useless, they may as well go full hog, like Apple does in desktop Safari -- the address bar shows the domain only, until you click.
- y_molodtsov 7y ago
  But it’s definitely not important for an average user typing “facebook.com” into the address bar. Safari proved that.
  - toast0 7y ago
    If the url isn't important enough to display, then they shouldn't display it. They can display just the domain. They shouldn't display almost the url, but they removed an important thing. Edit to add: if you type in an almost url from the screen or a screenshot, it's likely to not take you to the same page, and you'll be confused as to why. If you type in the domain only and go to the home page, that's not that confusing.
- UncleMeat 7y ago
  The "www" isn't important for the huge majority of users the huge majority of the time.
mholt 7y ago
Ah yes, this fun bug: https://twitter.com/mholt6/status/1037810122603421696 https://twitter.com/mholt6/status/1037810122603421696
JTbane 7y ago
It's obvious that this is a dark pattern to increase the usage of Google search versus just typing in an address.
gvx 7y ago
I would have no trouble with hiding "https://" https://" in the address bar, as long they show it for other protocols (including http). It might help move us to a world with https everywhere even faster. I still prefer Firefox: protocol, subdomains and path are greyed out but still clearly legible. This way I can eyeball "on which site am I?" quickly (and read google-secure-payments.google.via.net as via.net for example) and still have access to the full URL in 0 clicks.
- acqq 7y ago
  It seems that Firefox stopped copying http:// http:// (when I want to copy URL) which is very annoying to me. I need the whole address when copying.
  - cpeterso 7y ago
    Firefox hides the http:// http:// scheme in the address bar, but will include it if you copy the URL. You can test with http://example.com/ http://example.com/ and https://example.com/ https://example.com/.
    - munk-a 7y ago
      Nice! Though it'd be good if they swapped the scenario where they hide the protocol to be `https` and make `http` the one that sticks out awkwardly.
      - acqq 7y ago
        At least for copying nothing should be hidden.
      - anthony_doan 7y ago
        I mean they have the lock icon for https. If you want it to stick out awkwardly I feel like they just need a opened lock in red icon.
  - csours 7y ago
noncoml 7y ago
Google wants a world where eventually all internet is hosted and controlled by Google. To get there they have to disassociate what’s shown in the URL bar with how and where the content comes from.
AlchemistCamp 7y ago
I'm not a Chrome user, but this seems like a good thing. Address bars have been getting crowded the past few years.
RandomInteger4 7y ago
This is so pointless. Why? To make the URLs prettier for the average user who they assume is too stupid to function or something? Meanwhile most URLs around the web have UUIDs or other garbage appended to the end for the sake of tracking, which I doubt they intend to do anything about any time soon, so what even is the point of hiding the protocol and a single subdomain? Just leave the URL alone.
fkhatri 7y ago
Hiding the subdomains doesnt make any sense!!
chmod775 7y ago
A coworker and me got bit by this just today. I introduced him to a new tool I built for internal development, and wanted him to access the locally running instance of our codebase. Took us some time to figure out that chrome was trying to connect to https:// https:// instead of http:// http://, which wasn't enabled. I think it said something in the error message about that, but who reads these anyways.
TazeTSchnitzel 7y ago
I work for well-known tech company [redacted] and visiting our website with the www omitted does not work from within our network. But if you've just updated Chrome, it would now be unclear whether you typed the site name right. My previous employer [redacted] had its marketing site on www and actual SaaS application product on www-less. Again a case where mis-typing would be made more confusing by Chrome.
- bsmith0 7y ago
  Those both seem like implementation issues.
  - TazeTSchnitzel 7y ago
    They're not good practice on the part of the website operators, for sure, but they are real examples of the root and www domains being different. In my experience there are also lots of old or government sites that just plain don't work without the www. And when the person phones up tech support “ma'am, does it show the www. in front of the website?” “no” “sorry you need to retype” “it still doesn't show www.” is going to happen. Or someone will write down the URL from the screen, and when someone else types it in, it won't work. Oh, right, and there's the same issue with sites where https:// https:// has a different site to http:// http://!
joe_hoyle 7y ago
Only issue I have with this is it removes a bit of useful information when I'm asking users for screenshots when reporting errors on websites!
- Veedrac 7y ago
  http/https is already given by the lock/“Not secure” icon FWIW.
keymone 7y ago
I just opened this page on safari and I see just “bleepingcomputer.com” with a lock icon. Its great chrome will do the same. Every browser should. Low level technical details and historical artifacts should go die in fire.
RobertRoberts 7y ago
This is a giant AMP scam. The next change will be that it will trick users into thinking they are on are on a real site like example.com but will instead be on Google.com/example.com. But chrome will remove google.com just like http/s.
- cpeterso 7y ago
  Chrome on Android already hides the "google.com/amp" URL prefix for AMP URLs: https://blog.amp.dev/2018/01/09/improving-urls-for-amp-pages/ https://blog.amp.dev/2018/01/09/improving-urls-for-amp-pages...
  - RobertRoberts 7y ago
    Thanks for the tip, I haven't used Chrome on my phone enough to notice this. This is really sad and dangerous for the web. I don't know why people aren't up in arms over this kind of devious behavior from Google. If Microsoft had pulled this in the late 90s early 2000s there would have been senate hearing and talks of breaking up their monopoly.
  - floriferous 7y ago
    How scammy is this?!
- v7p1Qbt1im 7y ago
  Signed HTTP exchanges. It was actually the main complaint about AMP because it caused confusion among users. Technically it makes no difference wether the content is hosted by the author or any AMP CDN. The question is more a philosophical one. If it’s wrong that the URL doesn’t point to where files are “actually” stored. Or rather that the package delivery and package creator aren’t the same party. In my mind this hasn’t been the case for a long time now anyway. https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/ https://amp.dev/documentation/guides-and-tutorials/optimize-...
  - RobertRoberts 7y ago
lone_haxx0r 7y ago
"The Chrome team values the simplicity, usability, and security of UI surfaces. This change is the complete opposite of simple. Simple is showing the real URL. Complex is trying to remember in what cases Chrome hides part of the URL and trying to guess what website you're viewing.
- UncleMeat 7y ago
  Simple is showing the full http headers. Simple is showing iframe urls. Of course it isn't. URLs are largely made of useless and incomprehensible information for most users.
  - lone_haxx0r 7y ago
    If the bar was called the "http headers bar" then simple would be showing the full http headers, but it is called address bar, so the simple thing to do is to show the address.
emilfihlman 7y ago
This is absolutely stupid. The www subdomain and the bare domain are not equivalent and should not be treated as such. Hiding the protocol is also stupid if it's still shown for other protocols, like ftp or http.
crazygringo 7y ago
To place this in context -- Safari already does this and even more, hiding the path after the domain as well. Firefox does something in the middle where it makes the "https://www." https://www." and path lighter gray, while the domain name is black. I think this is just about ease of use and displaying the most relevant information. Regular users think of it as "google.com", not as "https://www.google.com" https://www.google.com". And the full URL is still there whenever you click through to select or copy.
bhauer 7y ago
This is "mobile-first" mentality in a malignant retroactive form, where it is taking away functionality and behavior that is already established in the desktop environment to better match user expectations set in the mobile space. Mobile browsers often elide the protocol and trivial hostnames from domains in order to economize on precious screen space of phones. Desktop browsers do not face the same constraints. A desktop browser can play to the strengths of desktop computing—taking a "desktop-first" point of view—and display the full URL with the abundant space available. See Firefox's display of the full URL with a highlighted color for the domain. Alternatively, they can be made subservient to mobile and adopt conventions established from constraints that do not exist in the desktop space. Mobile-first is frequently damaging to new desktop software projects, but in my experience it's atypical for mobile limitations to be back-ported to established desktop software.
toast0 7y ago
I guess the responsible thing to do is to redirect www to vvvvvv
- hedora 7y ago
  https.llwww, you mean?
eridius 7y ago
I don't understand why you have to click twice to show this info. That's just bizarre.
- Veedrac 7y ago
  Simple UX: don't move things around more than necessary. I honestly don't understand why people think this second click is unreasonable; the power-user shortcut (ctrl-l) already expands immediately anyway.
  - eridius 7y ago
    It's unreasonable because it violates user expectations. One click already makes the field editable and selects the text, having a second click change the text has no precedent whatsoever. It's also confusing because this means that clicking to position the insertion point suddenly moves the text out from under where you clicked (thankfully it does still place the insertion point at the right location, but that location is no longer where you're looking and pointing). There's also just no reason for this. It's unnecessary overhead to showing the full URL and there's no benefit.
    - Veedrac 7y ago
      The point is that the most common thing people do when clicking the URL is typing something else in the search bar, and the second most is copying the URL. In both cases, having the URL change is a problem, because this includes people who don't know what the http:// http:// means or what a subdomain is, and don't immediately understand when a URL is the same as another. Your extra click saves my mother, and millions like her, much more confusion than the click costs you. You probably mostly know technically fluent people, and think ‘my mother’ is a euphemism, but it's not. If we can get to a world where she can see an unfakeable padlock and read ‘facebook.com’, rather than remember whether it was ‘https:’ or ‘https.’ in the URL bar, and which parts of the string of letters to skip, we've made her life less hostile. The corresponding problem you're complaining about is incredibly trivial in comparison. If you're actually editing the URL, you see the whole URL. If you need to know these implementation details, they're vastly easier to find than, say, HTTP headers.
jakeogh 7y ago
Google's business model ultimately revoves around deception. They need their assets to not know or care where they really are or who they really are talking to or who is reviewing thier words and movements. I had to laugh when they started parading thier fake-human avatar "to call and lie to people". But really, their big value item is language engineering.
mrtweetyhack 7y ago
That's funny cause I've hidden Chrome from my computer
spondyl 7y ago
I find this really annoying. We have an internal SPA with buggy routing where it'll render for both http and https but the requests made by the client fail because they mirror the protocol when hitting the backend. It's a pretty trivial issue that has sat around for a while. While I run Firefox, I would normally distinguish what version of the site a user is on by the green lock. While http does show a "Not secure" segment next to the URL, everything just shows as black and white in dark mode, making it harder to distinguish at a glance.
thrwwy4357 7y ago
There's a user story that can be filled: "As a ____, I want to get users to our []-controlled version of our site, without alerting the user aware they are on our []-controlled version of our site." So in this sense there are points for filling it. It's still the correct domain, so this is quite a niche user story.
Yizahi 7y ago
We all know why they really did it - to hide AMP page prefix in the future, to silo all internet (=Googlenet) users on their servers and won't raise much suspicions from them.
StefanoC 7y ago
First "bug" raised this morning about naked domain not redirecting to www... SEO departments in my experience still insists that the www subdomain is necessary (e.g. they have no idea so better not touch it), yet Google instead of publicly coming out saying that it's pointless goes as far as hiding it. I don't get the point.
adultSwim 7y ago
Good riddance to www

257 points by heyyyouu 7y ago

I use Firefox anyway and I would be fine with hiding the https:// https:// and the green lock shows its https anyway but I do not get the subdomain hiding, not on desktops, tablets, phones with enough screen space anyway. If its really limited then maybe with some symbol that indicates that there is something missing there.

kenforthewin 7y ago

This is extremely annoying for a project I'm working on that involves subdomains. If I set nginx to redirect `example.com` to `www.example.com` I want to verify it in the browser.

notatoad 7y ago
my chrome hasn't updated yet, but my understanding of this change was that you could display the full unmolested URL by simply clicking in the address bar. is that not the case?
- blahyawnblah 7y ago
  double clicking. but still.
  - quink 7y ago
    Wow, that is mad. So glad I switched to Firefox.
_-david-_ 7y ago
You probably should be checking in the console network tab to make sure you are getting the correct HTTP status code (301 vs 302).

zzo38computer 7y ago

I absolutely do not want it to hide any URI schemes or subdomains at all. (I am able to change these settings in Firefox, at least. I could also disable Unicode rendering for the domain name, but to disable Unicode rendering for the filename I had to write an extension.)

cpeterso 7y ago
By default, Firefox's address bar hides the http:// http:// scheme but shows the https:// https:// scheme (to emphasize that the connection is secure). Firefox users that want to see the http:// http:// scheme can set the "browser.urlbar.trimURLs" about:config pref to false.
wildrhythms 7y ago
FYI you can revert this behavior in chrome://flags chrome://flags/#omnibox-ui-hide-steady-state-url-scheme chrome://flags/#omnibox-ui-hide-steady-state-url-trivial-subdomains chrome://flags/#omnibox-ui-hide-steady-state-url-path-query-and-ref I just disable all of these.

Rebelgecko 7y ago

Google must really hate URLs. My search results recently stopped showing the full path of the URL, just the domain name. It was a huge pain because I was looking for an item at Ikea and couldn't tell if a result went to their American site or to their UK, Saudi Arabian, Qatari, etc. site (apparently the same item can have small differences in different countries— I almost bought the wrong lightbulbs because the UK version of my lamp uses a different size bulb).

privateSFacct 7y ago
Google sees folks falling for google-secure-payments.google.via.net type URLS. They see all the gaming people do with URLs in search results (including abusing the names of other brands like Amazon). There are lots of developers who like distinguishing these subtle topics. I can tell you in a larger enterprise deployment most of these changes will be welcomed (yes, people do still click on bogus URLs believe it or not - FAR more often than I would expect). Or think that the url amazon.lowprice.com is an amazon website in a search result. Folks claiming google is hiding the owner of the website forget that the actual owner of the website is reflected by the END of the domain name, not the earlier parts. In some shared hosting situations this is confusing, but in the end whoever controls the end actually is in control.
- ljoshua 7y ago
  I'm wondering how the particular address bar change helps alleviate this though. As I've seen it implemented, the only subdomain they'll "elide" is www, so if it is google-secure-payments.google.via.net it will still show as such in the address bar, not as via.net. So I don't understand their reasoning in how this will help from a security standpoint.
- danShumway 7y ago
  > google-secure-payments.google.via.net How does hiding www help with that? It seems to me that a decent scheme to make the domain-owner more visible would be to separate out the domain and display it separately from the entire URL, the way that Safari does. I'm not a fan of Safari's changes, but at least its easy for me to see how they could improve security -- it's a decision with real benefits, and the only question is whether they outweigh the downsides. But it's difficult for me to imagine a phishing scenario where hiding `www` will make things better. The only scenario I can think of (where `www` redirects to a different site) is made worse by hiding it from the URL.

badrabbit 7y ago

URLs represent and identify content,controling them means you control content. In the short term these changes mean little but in the long term this will benefit google immensely. Google just loves slippery slopes. Identity and payment are extremely important to any ordered system of social interaction. More than content itself,controlling them helps one control everything else. I am trying hard to avoid believing conspiracy theoris about Google. Maybe a legal requirement for intetnet standards compliance makes sense?

privateSFacct 7y ago
The focus of this change is to improve the identification of content. This coupled with payment has been subject lots of fraud where users misled about the owner of a website. google-payments-secure.via.net is not a google payment website despite the google in the domain name. The key part that signifies the ownership / identify of the person hosting the site is the END of the domain, the google.com part. That is the owner of the web property, not whatever appears before that.
- reaperducer 7y ago
  Or Google can stop cramming things in the top of the window and let us see the entire URL.
- hermanradtke 7y ago
  There are other ways to do this that do not hide parts of the URL. Educating people should not hide information, but instead present information in a way that is more understandable. I think the Chrone team is making URLs harder to understand.
- badrabbit 7y ago
  That's what google uses as an argument too and I am too familiar with the problem. The problem here is that Google is in control of the solution and the solution is designed by them without consulting everyone else and in a way that would be advantageous to their long term dominance and prosperity. I don't trust google and they certainly don't have my consent to shape the way I and the society I live in interact with each other. I will say it a million times if needed. I do not trust google. Period. They ask forgiveness instead of permission and they love slipperly slops and bait-and-switch psychology tricks to get their way.

mr_puzzled 7y ago

Off topic : there seems to be a disconnect between the chrome devs and users. Another instance was the automatic signing in to chrome incident. I've lost trust in the chrome team and have switched to Firefox full time and honestly there's nothing that I miss. The firefox devs seem to better understand their users, frequently blog about changes that positively impact users. I have a lot more faith in firefox even though it's not perfect (mr. robot incident and others).

tedivm 7y ago
I think the chrome team just considers its users to be your average corporate america employee, and no longer considers developers or tech literate people to be their main market.
- xemdetia 7y ago
  I doubt that, because the number of times they completely ruin chrome as an intranet browser in the last few years with TLS handling, self signed cert handling, and general settings window changing malarkey shows that they are not even catering to that market very well, especially when they add a workaround and take it away in a very short window which for better or worse is often much shorter than most large organization's change control windows. Firefox generally keeps most workarounds working for as long as I've needed to worry about it, but Chrome's timelines seem arbitrary and the UI changes make keeping Chrome configuration guides a constant churn.
  - magicalist 7y ago
    > ruin chrome as an intranet browser in the last few years with TLS handling, self signed cert handling, and general settings window changing malarkey Just put it in the OS certificate store? It's worked like that since Chrome was released.
    - hannob 7y ago
      I think the issue the upper poster is referring to are things like when chrome deprecated ancient certificate features, which enterprise-solutions still happen to use by default 15 years after they were deprecated. (One such issue were certificates with a common name and no subject alt name.)

pmccarren 7y ago

I'm certainly not a fan of the new URI scheme, but it is worth pointing out that Safari has already made the same change. Furthermore I'm not convinced said change is a net-negative for the average consumer. Safari added the setting "Show full website address", which does just that. I wouldn't have a problem if Chrome followed suit and defaulted to the new scheme, but gave us the option to show the full URI.

pwinnski 7y ago
I was reading your comment thinking, "What? No!" and then kept reading. I apparently checked "Show full website address" when the change was first made.
cpeterso 7y ago
Safari only shows the domain name. Chrome still shows both the domain name (minus "www.") and URL path.
- type0 7y ago
  Allright, now we know what's coming...
- pmccarren 7y ago
  Check your Safari setting "Show full website address". Checking it will show the full URI.
AnIdiotOnTheNet 7y ago
> I'm not convinced said change is a net-negative for the average consumer. And this is why modern technology sucks.

josteink 7y ago

Google wants nobody to know URLs exist, and that everyone is forced to search Google for everything, even sites they know, and there visit fake AMP-sites portraying to be from a server they are not, all while Google tracks every single keystroke you make. This is just another tiny step in that overall plan, and it is 100% evil. Don’t waste your time trying to talk the Chrome-team into reason. You are not their customer, nor their employer. They will not listen. If you don’t like what Google is doing, use other products. Firefox, DDG, iPhones etc.

type0 7y ago
General population already thinks that the Web has been taken over by Google and that "social media" is Facebook and Twitter.
joshuamorton 7y ago
Firefox and Safari already made similar changes. Safari made the exact same change, and Firefox hides http:// http:// already, but not https:// https://, chrome is just using a lock icon to represent the https:// https:// instead of the actual string.
- zzo38computer 7y ago
  As mentioned, at least this setting can be disabled in Firefox. (I don't know if this is possible in Chrome.)
  - wildrhythms 7y ago
    Since nobody replied, I mentioned this in another comment that you can revert this in chrome://flags https://news.ycombinator.com/item?id=20631676 https://news.ycombinator.com/item?id=20631676
- josteink 7y ago
  Firefox doesn’t hide the WWW subdomain. The domain-name remains unmangled.
7y ago

type0 7y ago

If I have one webpage with different languages and want my visitors recognize it from url, what are the options? Previously I could have www.example.com/en/ and www.example.com/fr/ etc If subdomains are not possible there's no hope that visitors using Chrome would see it?

deleted 7y ago
[deleted]
knd775 7y ago
Subdomains in general still show, just not www. Also, in the case you mentioned, the subdomains are the same. The path still shows.
- type0 7y ago
  Thanks for correction, I confused that with technically handicapped Safari Browser then.
deleted 7y ago
[deleted]
joshuamorton 7y ago
Unless I'm grossly misunderstanding, those would still show up as `example.com/fr/` and `example.com/en/`. Heck, if you use `fr.example.com` and `en.example.com`, those would also work.

RandomGuyDTB 7y ago

This is great and all until you (like me) need to be able to differentiate www.example.com from example.com and https:// https:// example.com versus http:// http:// example.com. My website doesn't forward example.com to www.example.com (due to errors on my part that I don't know how to fix, my email is in my profile and if you can help I'd greatly appreciate it). I don't know if there are any scenarios in which a properly-configured website (mine isn't) needs to differentiate example.com from www.example.com. But I liked the ability to do so easily.

notatoad 7y ago
>need to be able to differentiate ... https:// https:// example.com versus http:// http:// example.com this requirement is handled by the "not secure" badging, which is much more obvious that requiring users to pick out the "s" in the middle of a string. https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...
jammygit 7y ago
Can you just set a CNAME record in your DNS settings for that redirect?
JorgeGT 7y ago
Based on your certificate, are you using Cloudflare? If so, this shows how to handle these redirects: https://www.bybe.net/cloudflare-enforce-ssl-redirect-http-https/ https://www.bybe.net/cloudflare-enforce-ssl-redirect-http-ht... I use Github pages+Cloudflare to host my page and that's how I do it, free and quite resilient.
UncleMeat 7y ago
HTTP headers are hidden. That's great and all until you need to examine them for some development task. iframe URLs are hidden. That's great and all until you need to verify that your iframe is loading the correct content. Yet people don't complain about these. They are happy using the dev tools to access this information that is sometimes useful for developers and almost entirely useless for ordinary users.

dlandis 7y ago

It's just so bizarre how strongly the Google product people continue to insist that this change is beneficial to users when so many users themselves simultaneously insist that it's not. Combined with the fact that their explanation is dubious at best (i.e. www is not a technically a "special case"), I find it very hard to believe they do not have additional, confidential reasoning for making this change.

annadane 7y ago
Yeah forums where the company "interacts" with users is great. "This change is beneficial." "No, it isn't." "Yes, it is." "But it isn't!" "We respect your feedback but we're implementing it anyway."

_o-O-o_ 7y ago

What a slippery slope. I imagine a future when the entire URL itself has disappeared and we live in some sort of Google-controlled walled garden environment, like what they're trying to do with AMP[0]. Some sites only work with WWW prefixed as the APEX DNS record is misconfigured and points to nothing. I've even seen some sites point to `0.0.0.0' but had a CNAME record for WWW and I could then view the site. [0] https://developers.google.com/amp/ https://developers.google.com/amp/

y_molodtsov 7y ago
Then these websites are broken and needs to be fixed. In the end, the most of the people would probably search for it in the first place.
- aaomidi 7y ago
  This is a stupid argument. Subdomains are part of the standard of the web. They shouldn't be hidden.
- horsawlarway 7y ago
  broken according to who, exactly? It's entirely reasonable to choose to host http/https traffic on a www subdomain and host entirely different services at the non-www domain. The internet is not just http traffic. Full fucking stop. There are plenty of systems and industries where the actual web front-end is an after-thought.

jdashg 7y ago

This reminds me of how Windows frustratingly hides file extensions by default. This sounds low-upside/high-downside to me, but it's the sort of thing with simple arguments-for (easier for clueless users! Cleaner!), and nuanced arguments-against (eliding rarely-useful details in special cases causes ambiguity, and can lead to confusion is some cases, particularly for clueless users).

zzo38computer 7y ago
And, there is a setting to tell it to not do that, but even then, for some files it is hidden anyways. But, it is possible to use regedit to change it so that the extensions are not hidden even for those cases.
- sjs382 7y ago
  Editing Chrome flags is similar to editing the Windows registry. Here are the relevant settings: chrome://flags/#omnibox-ui-hide-steady-state-url-scheme chrome://flags/#omnibox-ui-hide-steady-state-url-trivial-subdomains chrome://flags/#omnibox-ui-hide-steady-state-url-path-query-and-ref
  - Jaruzel 7y ago
    Until they take those away. The Chrome devs have an annoying habit of removing flag options once they consider the 'feature' to be out of beta.
- zrobotics 7y ago
  On windows? I've never experienced/noticed this, what extensions are still hidden? Hidden files is a separate setting from hiding extensions (which is good), but I've never noticed a file that wouldn't display the extension after changing the setting. I can't remember specifically for any of the earlier versions, but this has been my experience on 7 & 10.
  - berns 7y ago

fadisaleh 7y ago

Can someone help me understand why this is a big deal? Safari has had this change for a while and I haven't felt like I'm missing anything. Where's the slippery slope? Does have to do with AMP?

heyyyouu 7y ago
It has nothing to do with AMP. There's a lot of reasons why, but one reason is for example, two different sites can technically be hosted on www. and the non-www version, if the site isn't set up to redirect the www to the non-www, for example. So this could, in certain scenarios, pose a security risk in that if you pretend that www and the non www are the same sites -- when they're not -- it can make it easier for those that hijack one or the other to get away with it. Now, that's fairly extreme and esoteric. But there are actually times in development when you use subdomains, which this makes more difficult, and there's other subdomains they're considering trivial which, in fact, aren't. This is really good discussion on the topic and why this change just simply ignores so many technical issues, best practices and simply realities: https://bugs.chromium.org/p/chromium/issues/detail?id=881410 https://bugs.chromium.org/p/chromium/issues/detail?id=881410
toast0 7y ago
Here's a problem: people often share screenshots with the address bar in the screenshot. If they share it from Safari with default options, the address is mostly useless, it's just the domain (and www may elided), but it doesn't even look like a url, so whatever. If they share it from Chrome with these new options, if it's like the last time Chrome released this, it looks like the full url, but it's not: When you go to https://example.org/some/deep/url https://example.org/some/deep/url it may very well not be the same as https://www.example.org/some/deep/url https://www.example.org/some/deep/url and adds an extra layer of confusion to figuring out whatever the issue is.

toast0 7y ago

This behavior will train users to believe that the www in domains isn't important, when it actually serves a very important purpose. You can't cname example.org, which makes it very hard to use a CDN to serve it unless the CDN provides anycast ips or you delegate DNS to the CDN. If they're intent on making the address bar useless, they may as well go full hog, like Apple does in desktop Safari -- the address bar shows the domain only, until you click.

y_molodtsov 7y ago
But it’s definitely not important for an average user typing “facebook.com” into the address bar. Safari proved that.
- toast0 7y ago
  If the url isn't important enough to display, then they shouldn't display it. They can display just the domain. They shouldn't display almost the url, but they removed an important thing. Edit to add: if you type in an almost url from the screen or a screenshot, it's likely to not take you to the same page, and you'll be confused as to why. If you type in the domain only and go to the home page, that's not that confusing.
UncleMeat 7y ago
The "www" isn't important for the huge majority of users the huge majority of the time.

mholt 7y ago

Ah yes, this fun bug: https://twitter.com/mholt6/status/1037810122603421696 https://twitter.com/mholt6/status/1037810122603421696

JTbane 7y ago

It's obvious that this is a dark pattern to increase the usage of Google search versus just typing in an address.

gvx 7y ago

I would have no trouble with hiding "https://" https://" in the address bar, as long they show it for other protocols (including http). It might help move us to a world with https everywhere even faster. I still prefer Firefox: protocol, subdomains and path are greyed out but still clearly legible. This way I can eyeball "on which site am I?" quickly (and read google-secure-payments.google.via.net as via.net for example) and still have access to the full URL in 0 clicks.

acqq 7y ago
It seems that Firefox stopped copying http:// http:// (when I want to copy URL) which is very annoying to me. I need the whole address when copying.
- cpeterso 7y ago
  Firefox hides the http:// http:// scheme in the address bar, but will include it if you copy the URL. You can test with http://example.com/ http://example.com/ and https://example.com/ https://example.com/.
  - munk-a 7y ago
    Nice! Though it'd be good if they swapped the scenario where they hide the protocol to be `https` and make `http` the one that sticks out awkwardly.
    - acqq 7y ago
      At least for copying nothing should be hidden.
    - anthony_doan 7y ago
      I mean they have the lock icon for https. If you want it to stick out awkwardly I feel like they just need a opened lock in red icon.
- csours 7y ago

noncoml 7y ago

Google wants a world where eventually all internet is hosted and controlled by Google. To get there they have to disassociate what’s shown in the URL bar with how and where the content comes from.

AlchemistCamp 7y ago

I'm not a Chrome user, but this seems like a good thing. Address bars have been getting crowded the past few years.

RandomInteger4 7y ago

This is so pointless. Why? To make the URLs prettier for the average user who they assume is too stupid to function or something? Meanwhile most URLs around the web have UUIDs or other garbage appended to the end for the sake of tracking, which I doubt they intend to do anything about any time soon, so what even is the point of hiding the protocol and a single subdomain? Just leave the URL alone.

fkhatri 7y ago

Hiding the subdomains doesnt make any sense!!

chmod775 7y ago

A coworker and me got bit by this just today. I introduced him to a new tool I built for internal development, and wanted him to access the locally running instance of our codebase. Took us some time to figure out that chrome was trying to connect to https:// https:// instead of http:// http://, which wasn't enabled. I think it said something in the error message about that, but who reads these anyways.

TazeTSchnitzel 7y ago

I work for well-known tech company [redacted] and visiting our website with the www omitted does not work from within our network. But if you've just updated Chrome, it would now be unclear whether you typed the site name right. My previous employer [redacted] had its marketing site on www and actual SaaS application product on www-less. Again a case where mis-typing would be made more confusing by Chrome.

bsmith0 7y ago
Those both seem like implementation issues.
- TazeTSchnitzel 7y ago
  They're not good practice on the part of the website operators, for sure, but they are real examples of the root and www domains being different. In my experience there are also lots of old or government sites that just plain don't work without the www. And when the person phones up tech support “ma'am, does it show the www. in front of the website?” “no” “sorry you need to retype” “it still doesn't show www.” is going to happen. Or someone will write down the URL from the screen, and when someone else types it in, it won't work. Oh, right, and there's the same issue with sites where https:// https:// has a different site to http:// http://!

joe_hoyle 7y ago

Only issue I have with this is it removes a bit of useful information when I'm asking users for screenshots when reporting errors on websites!

Veedrac 7y ago
http/https is already given by the lock/“Not secure” icon FWIW.

keymone 7y ago

I just opened this page on safari and I see just “bleepingcomputer.com” with a lock icon. Its great chrome will do the same. Every browser should. Low level technical details and historical artifacts should go die in fire.

RobertRoberts 7y ago

This is a giant AMP scam. The next change will be that it will trick users into thinking they are on are on a real site like example.com but will instead be on Google.com/example.com. But chrome will remove google.com just like http/s.

cpeterso 7y ago
Chrome on Android already hides the "google.com/amp" URL prefix for AMP URLs: https://blog.amp.dev/2018/01/09/improving-urls-for-amp-pages/ https://blog.amp.dev/2018/01/09/improving-urls-for-amp-pages...
- RobertRoberts 7y ago
  Thanks for the tip, I haven't used Chrome on my phone enough to notice this. This is really sad and dangerous for the web. I don't know why people aren't up in arms over this kind of devious behavior from Google. If Microsoft had pulled this in the late 90s early 2000s there would have been senate hearing and talks of breaking up their monopoly.
- floriferous 7y ago
  How scammy is this?!
v7p1Qbt1im 7y ago
Signed HTTP exchanges. It was actually the main complaint about AMP because it caused confusion among users. Technically it makes no difference wether the content is hosted by the author or any AMP CDN. The question is more a philosophical one. If it’s wrong that the URL doesn’t point to where files are “actually” stored. Or rather that the package delivery and package creator aren’t the same party. In my mind this hasn’t been the case for a long time now anyway. https://amp.dev/documentation/guides-and-tutorials/optimize-and-measure/signed-exchange/ https://amp.dev/documentation/guides-and-tutorials/optimize-...
- RobertRoberts 7y ago

lone_haxx0r 7y ago

"The Chrome team values the simplicity, usability, and security of UI surfaces. This change is the complete opposite of simple. Simple is showing the real URL. Complex is trying to remember in what cases Chrome hides part of the URL and trying to guess what website you're viewing.

UncleMeat 7y ago
Simple is showing the full http headers. Simple is showing iframe urls. Of course it isn't. URLs are largely made of useless and incomprehensible information for most users.
- lone_haxx0r 7y ago
  If the bar was called the "http headers bar" then simple would be showing the full http headers, but it is called address bar, so the simple thing to do is to show the address.

emilfihlman 7y ago

This is absolutely stupid. The www subdomain and the bare domain are not equivalent and should not be treated as such. Hiding the protocol is also stupid if it's still shown for other protocols, like ftp or http.

crazygringo 7y ago

To place this in context -- Safari already does this and even more, hiding the path after the domain as well. Firefox does something in the middle where it makes the "https://www." https://www." and path lighter gray, while the domain name is black. I think this is just about ease of use and displaying the most relevant information. Regular users think of it as "google.com", not as "https://www.google.com" https://www.google.com". And the full URL is still there whenever you click through to select or copy.

bhauer 7y ago

This is "mobile-first" mentality in a malignant retroactive form, where it is taking away functionality and behavior that is already established in the desktop environment to better match user expectations set in the mobile space. Mobile browsers often elide the protocol and trivial hostnames from domains in order to economize on precious screen space of phones. Desktop browsers do not face the same constraints. A desktop browser can play to the strengths of desktop computing—taking a "desktop-first" point of view—and display the full URL with the abundant space available. See Firefox's display of the full URL with a highlighted color for the domain. Alternatively, they can be made subservient to mobile and adopt conventions established from constraints that do not exist in the desktop space. Mobile-first is frequently damaging to new desktop software projects, but in my experience it's atypical for mobile limitations to be back-ported to established desktop software.

toast0 7y ago

I guess the responsible thing to do is to redirect www to vvvvvv

hedora 7y ago
https.llwww, you mean?

eridius 7y ago

I don't understand why you have to click twice to show this info. That's just bizarre.

Veedrac 7y ago
Simple UX: don't move things around more than necessary. I honestly don't understand why people think this second click is unreasonable; the power-user shortcut (ctrl-l) already expands immediately anyway.
- eridius 7y ago
  It's unreasonable because it violates user expectations. One click already makes the field editable and selects the text, having a second click change the text has no precedent whatsoever. It's also confusing because this means that clicking to position the insertion point suddenly moves the text out from under where you clicked (thankfully it does still place the insertion point at the right location, but that location is no longer where you're looking and pointing). There's also just no reason for this. It's unnecessary overhead to showing the full URL and there's no benefit.
  - Veedrac 7y ago
    The point is that the most common thing people do when clicking the URL is typing something else in the search bar, and the second most is copying the URL. In both cases, having the URL change is a problem, because this includes people who don't know what the http:// http:// means or what a subdomain is, and don't immediately understand when a URL is the same as another. Your extra click saves my mother, and millions like her, much more confusion than the click costs you. You probably mostly know technically fluent people, and think ‘my mother’ is a euphemism, but it's not. If we can get to a world where she can see an unfakeable padlock and read ‘facebook.com’, rather than remember whether it was ‘https:’ or ‘https.’ in the URL bar, and which parts of the string of letters to skip, we've made her life less hostile. The corresponding problem you're complaining about is incredibly trivial in comparison. If you're actually editing the URL, you see the whole URL. If you need to know these implementation details, they're vastly easier to find than, say, HTTP headers.

jakeogh 7y ago

Google's business model ultimately revoves around deception. They need their assets to not know or care where they really are or who they really are talking to or who is reviewing thier words and movements. I had to laugh when they started parading thier fake-human avatar "to call and lie to people". But really, their big value item is language engineering.

mrtweetyhack 7y ago

That's funny cause I've hidden Chrome from my computer

spondyl 7y ago

I find this really annoying. We have an internal SPA with buggy routing where it'll render for both http and https but the requests made by the client fail because they mirror the protocol when hitting the backend. It's a pretty trivial issue that has sat around for a while. While I run Firefox, I would normally distinguish what version of the site a user is on by the green lock. While http does show a "Not secure" segment next to the URL, everything just shows as black and white in dark mode, making it harder to distinguish at a glance.

thrwwy4357 7y ago

There's a user story that can be filled: "As a ____, I want to get users to our []-controlled version of our site, without alerting the user aware they are on our []-controlled version of our site." So in this sense there are points for filling it. It's still the correct domain, so this is quite a niche user story.

Yizahi 7y ago

We all know why they really did it - to hide AMP page prefix in the future, to silo all internet (=Googlenet) users on their servers and won't raise much suspicions from them.

StefanoC 7y ago

First "bug" raised this morning about naked domain not redirecting to www... SEO departments in my experience still insists that the www subdomain is necessary (e.g. they have no idea so better not touch it), yet Google instead of publicly coming out saying that it's pointless goes as far as hiding it. I don't get the point.

adultSwim 7y ago

Good riddance to www