Chrome abandons 'simplified domain experiment' in omnibar
bugs.chromium.org
bugs.chromium.org
e.g. "https://www.ghacks.net/2020/06/15/google-to-test-simplified-..." -> "ghacks.net"
> The reason for running the experiment, according to a developer, is that the display of the full URL makes it difficult for the average user to distinguish between legitimate and malicious sites.
From https://www.ghacks.net/2020/06/15/google-to-test-simplified-...
Maybe the next iteration of it will use SSL certificate hijacking, who knows?
I mean, this feature can be argued with from both sides: protection against scam and "UX MITM".
What I don't understand is why a web browser doesn't already include scam websites into their malware/badware reporting feature. It could have been so much easier.
In Germany we have a very restrictive law when it comes to imprints on websites, which makes it easy to spot scamming websites if you care to look for the legibility of the imprint (and required tax law identification numbers). Of course that doesn't apply for international law, but initially I didn't understand the importance of it...meanwhile I do.
The only parallel that comes to mind are all the "helpful" clickjacking toolbars in Internet Explorer that tried to push every search and every link to their own results page.
If someone is scamming people, it wouldn't be too surprising if they do include the imprint or include incorrect data there, wouldn't it?
In imprints there's an address that you can lookup on the Handelsregister. If the HRB matches, and the Handelsregister's Domain for the company matches, too... it's usually an indicator that the website is trustworthy (at least from a legal sue-able-in-case-of-fraud standpoint).
Example (never used the website before):
- https://www.deerberg.de/service/impressum
- Northdata.de entry checks out (public webservice of Handelsregister entries), with same domain(s)
- unternehmen24.info checks out (another public webservice of Handelsregister entries), with same domain(s)
- HRB checks out, it's in Lueneburg
- DNS records and whois point out it's locally hosted in Lueneburg, too.
- Googled Umsatzsteuer-ID, no other (unrelated, scammy looking domain) results
- Googled HRB, checks out as well
- Google Business Page on Google Maps checks out as well (which might be hijacked, so not trustworthy as indicator alone)
- Geschaeftsfuehrer check out as well
So yeah, I guess this page/company is legit. You could do this further with LinkedIn and other things like looking up phone numbers in Breaches/Leaks and match the records with the Handelsregister.
From an automation perspective this is still a lot of manual research that's necessary; and I guess that this is kind of the real issue at hand - that most people are too lazy to do this sort of background check before they buy something online.
But I guess depending on the financial value you're willing to spend some background check beforehand makes more sense if a fraud would financially burden your means of survival afterwards.
To be honest that does seem like an awful lot of detective work especially if this would be for a simple online purchase, particularly if the transaction value isn't that high.
In many countries you would typically pay online using a credit card or Paypal in which case the card issuer/bank/Paypal provides you with a degree of protection if a product doesn't turn up or isn't what you ordered.
In Germany I believe people still are used to there being the option to pay using "Vorkasse" (paying in advance, by bank transfer).
I've simply never understood why any buyer would want to assume all the risk by doing that.
As for the question why people would choose to pay in advance? From my experience it was because they didn't have a credit card and didn't trust/didn't want to have a business relationship with PayPal, leaving Vorkasse as the only available payment option.
Another point that has been brought up was the perception that the bank transfer would be more secure, as in "if they have my credit card info/PayPal account, they can just charge me at any time". The fact that bank account information also enables you to debit the account is curiously often forgotten.
Is this a particular sensible position to take? Maybe not, but not everyone acts sensibly all the time.
Paying by bank account doesn't mean handing over bank account info. But the merchant just redirects to your bank as part of the payment flow. The bank knows how much money the merchant wants and you authorize it for that one transaction. Bank redirects back to the merchant who confirms the payment was successful.
They can't make any further charges at a later date.
Tell that to the people behind the "Sofortüberweisung" [ roughly: "Immediate bank transfer"] scheme - run by Sofort GmbH, now part of Klarna.
I've seen this offered several times but never (dared to) try it personally, but by all accounts* it works something like this:
At the merchant's checkout page you are offered choice of payment methods, Sofortüberweisung is on the list, you select it, then you end up on a third-party site(!) where you provide the login details to your bank account(!!) including PIN and/or one-time TAN(!!!). The third party site checks your balance, then executes a transfer to the merchant for the total of your cart, then confirms the transaction to the merchant.
When I first read about how this works, I assumed I'd understood it wrong. From a security PoV, doesn't this make one's skin crawl?
* sorry, pun intended ;)
With bank payments I just have to be careful to check I am actually at the bank website when entering the login info. Makes me feel more in control.
I guess people in the west were already used to giving out their card info over the phone to make purchases so wasn't a big deal when online sites started doing it. In India credit cards were still not wide spread (still aren't) in the early 2000s.
Even if you know that your card provider will refund you if the card leaks?
In the last decade I've twice had a credit card cloned, and twice I've been pleasantly surprised how quickly the card provider a) detected the issue, b) blocked the old card and re-issued a new card, and c) refunded the fraudent transactions.
Based on that, I'd trust my credit card provider far more than my bank(s).
Don't chargebanks typically involve a dispute between buyer and merchant? In neither of the instances where I personally experienced card fraud was the typical chargeback process involked, both times I had to confirm which recent transasctions were and weren't "mine", and after that the card provider did all the running. The second time I had many thousands of euros of fraudulent transactions refunded onto my account within 48h of the fraud being detected by the card issuer.
> your card issuer which almost always is your bank
Sorry, I wasn't very clear. I trust how credit-card-issuing-banks (in my case it was Barclaycard ie Barclays PLC) treat their card customers more than I trust current/checking/giro account banks treat _their_ customers.
It makes a lot of sense when you think about the underlying incentives to treat customers well.
Changing your current/checking/giro account can take quite a lot of work and has the potential to cause problems for a long time.
Applying for a new credit card takes a few minutes and the entire process is complete in a few days.
But this is also the case when you allow your bank to aggregate info from other banks. At least you can hope that they protect it somehow (because of bank regulations, but this is a very thin hope)
It's nice that it works that way for you, but it does in Germany. You don't need to hand over your login information or anything, but wiring money in any form means that they have your account number. The account number is sufficient to debit the account at a later point. Obviously they're not allowed to do that without your explicit consent, but a malicious actor could.
If you do not, you reject the payment and it is now the bank problem.
An IBAN is never a secret.
The authorization from the person being debited is required but in practical terms it does not always happen. People request DD and then forget to make the paperwork (today this is better because more and more DD agreements is arranged electronically). The bank will the allow the DD without the paperwork to make it easier for everyone (and ask the case to be fixed). In any case this i stheir risk but in the vast majority of cases it works.
Absolutely, but the same is true for credit card charges as well. Your acquirer will terminate your contract if you make fraudulent charges against credit/debit cards.
I am not arguing that you shouldn't wire money or use direct debit. I am just pointing out that it carries much of the same risks to the consumer as using a credit or debit card. (Which is virtually none since you can have charges revoked.) This observation is, in my opinion, relevant since many people in Germany seem to think that one is much safer than the other.
So if I find your IBAN, the work I would need to put in place to get money from your bank would be enormous (= securing the DD arrangement with the bank).
If I know your CC number, I can easily cash it out (by making a payment out of it, or to register a PCI account (eg. with stripe).
I fail to see the difference here. If I have your IBAN and you haven't universally disabled direct debit on your account I can also use it to pay for something, for example by ordering anything I want from Amazon.
> eg. with stripe
Funny that you should mention Stripe specifically. You can accept SEPA direct debit payments with Stripe: https://stripe.com/docs/sources/sepa-debit
It is possible that the compliance requirements around this are slightly higher than for accepting only Credit Cards, but looking at the documentation I don't see any indication of this. Further, credit/debit card payments are subject to SCA whereas direct debit is exempt from SCA if the mandate is given directly to the payee without involvement of their PSP.
Bank account details aren't typically regarded as (worth keeping) secret, to the extent that many businesses are happy to stick their IBAN on their website.
Credit card details, on the other hand, aren't ever published in this way.
This is precisely my point. People are not terribly worried about others (including merchants) knowing their IBAN. They are worried about their credit card.
However, a malicious actor can cause you much of the same trouble with your IBAN as they can with your credit card number. It is therefore illogical, in my opinion, to be worried about one much more than the other.
> to the extent that many businesses are happy to stick their IBAN on their website.
These accounts almost always block direct debit, therefore they don't run these risks.
I disagree with this.
A malicious actor may be able to cause some trouble if they have your IBAN, but it would appear to be significantly harder to steal money _and get away with the crime_ using an IBAN compared with someone's credit card details.
In the Jeremy Clarkson story from 2008, someone set up a direct debit to a charity using bank account details.
Given the hoops you have to jump through to be able to be able to set up a direct debit - and knowing that KYC would apply to the receiving bank account - it would appear to be significantly harder to profit from money withdrawn in this way.
With a stolen credit card you can purchase something online from a merchant that isn't obliged to do any KYC checks and the fraudster is gone long before the crime is detected.
[It's a while since I lived and worked in Germany] are there many people who have a current/checking/Giro account but where this isn't a standard payment card linked to their account which is also a Visa or Mastercard compatible card?
I'm sure you understand this better than I do (and I don't just mean because the language!) but aren't banks like Sparkasse offering any online payment functionality with Girocard ?
eg:
https://www.sparkasse.de/unsere-loesungen/privatkunden/bezah...
"Mit giropay können Sie sicher online bezahlen" (freely translated): "you can pay safely online with giropay"
I would venture that the intersection between people who prefer to wire the money in advance and people who do not use online banking is quite big.
EDIT: The old iteration of giropay (I'm not yet familiar with the new one) was quite similar to Sofort (previously Sofortüberweisung) except not run by a third party, but by your bank. It executed a normal wire transfer and confirmed to the merchant that the transfer had been ordered. In that sense it has the exact same risks as normal "Vorkasse", but did not incur the day of delay for the transfer to go through.
Look... I try not to be too judgemental and keep these types of comments to myself, because generally speaking, breaking new ground is hard.
But that statement right there is one of the worst solutions looking for a problem I've ever seen, and even a moment spent actually thinking about the URL, what it was originally for, how one explains it to someone not indoctrinated into tech or the Net, and how the URL has been repurposed and overloaded to be a drop in replacement for implementing Remote Method Invocation through SOA should reveal what the real problem is.
Example:
Me: Okay, Unusually Observant Gram. This is a URL. A Uniform Resource Locator. Think of it as an address to a webpage. It specifies a mechanism for retrieving something in a computer network. If you put in the same address, you'll come to the same place.
UOG: I've heard of the www.com thing before, but what's the http:// and the bunch of slashes afterward? And what's with the question mark I sometimes see after the slashes?
Me: The http is the part that specifies the protocol, or how you tell your computer how to get what's at the address. The slashes are the path under the domain, which is the www.com part you're familiar with.
UOG: How, pray tell, am I supposed to know what the right way to tell the computer to get what is at that address is if I haven't even been there to see what is there? And you didn't explain the question mark.
Me: Well... Good question. Good question. You see, it's fairly rare that you just go visiting one of these places without hearing about it first. So the person giving you the URL just tells you that to save you the trouble. The question mark starts what is called a query, which is a list of named data values you're bringing with you for when you arrive to hand to what's there. If the domain is the building, the path is directions through the building, and the query is extra stuff you give to the person serving the page to do something with.
UOG: Wait, I have to give them something? How do I know what I need to give them so I make sure I have it before going through all the work to visit them at their address?
Me: <Awkward pause> Well, normally you don't, actually. You either figure it out by trial and error, you read about it somewhere, or they design their webpage in such a way that it knows all that and does it for you.
UOG: I thought you said it was an address? Like a place? That I visit? Then follow a series of directions within, and sometimes have to bring something with me, that I don't have any way of knowing about until I visit, and end up embarrassed because I have to turn around and go get what I didn't know I had to pack. Now you're telling me not only is it a place, but somehow that place can itself move, to visit another place?
This does not sound like an address to me. This sounds like there is way more to it than that.
Me: You're enjoying this way too much.
UOG: Immensely. Please continue explaining. I still have a ball of yarn that needs to be turned into a sweater.
Me: Okay. So... Yes. All of what you said is correct, but you seem to be conflating the place led to by the address with the thing actually at that place.
UOG: Oh, that makes sense. Alright. Where is www.example.com? What's around it? Who are it's neighbors? How is the neighborhood?
Me: Okay, the address analogy is getting a little thin. It's not like you can see nearby things from any of these, except through links embedded in the thing-that-is-at-the-address. In fact, if you change even one letter of the address, you'll either not get anything, or you'll get something completely different than what you were looking for. Like you could end up on the other side of town, or in a completely different city.
UOG: Oh my! Surely there is a way to tell when this has happened? Like, I should be able to see exactly where one of these lynxes you're talking drags me off to?
Me: I see what you did there, and no, there is no guarantee. In fact, some people intentionally set up malicious things at addresses that are easy or frequent typos of another address, and make the page you see as similar as possible to the untypo'd address in the hopes you might disclose valuable information without noticing the mistake you made in the address.
UOG: Wait... People trade in these addresses? I thought you said if I went to the same address I'd get to the same thing! What if the owner changes of an address I rely on? This seems really confusing, and like even less of an address that can be relied upon for producing consistent results. This seems like it's only a bare thread away from unravelling into a big mess.
Me: Like your sweater?
UOG: Shush.
...I mean, I could go on writing, but I'm willing to bet anyone should be able to recognize the problem was never the protocol, or path, or query part of a URL that caused confusion, it was the domain name itself. It completely clashes with most humans innate understandings and heuristics involved with navigating in the Real World.
So ironically, they took information that could be usefully applied to giving away a fraudulent address...to only display the most readily misread bit of information with the fewest guarantees that where you're visiting is actually the same place you want to be.
It only gets more confusing once you start trying to explain DNS and how they that control the DNS servers determine where requests by everyone else land, because there's actually this other address underneath it called an IP address...
Honestly, I should just write a book at this point.
So it's less a street address and more of a mobile phone number.
Your grand should probably understand that metaphor better since I'm sure she's had multiple experiences with phone numbers changing hands over the years. And called people on their cell phones while that person is in different places. Or had different people answer the same number if the owner of the phone has entrusted the phone to another person or maybe even forwarded their number temporarily.
For me, I see the domain name as the sign above the shop front.
Example: https://i.imgur.com/KludkrC.png
Like the % of users who will opt IN to cookies or tracking or similar.
to erode away at the name of things is to erode away the bedrock that holds this all up. it is to make the clear and the district muddled. there's no proposed new abstraction here, no new alternative: to hide the url would be to cloak the truth that makes the web so much better than all other computing: that this is an online space, where things have universal names[1], & that by using the name we can get to that thing.
I love your passion here, but I think this is pretty subjective. Like that model is mostly only useful for the document model of the web. So many things are apps now, where "URLs" only make nominal sense. Even in Electron apps where you can share URLs, it's basically just a bit of serialized state--you could use any format you wanted for this, but it's not at all universal: it's not like I could ever open a shared Spotify URL in VS Code.
But more broadly, I think we should maybe start giving up on the web (and by web, I mean what most people mean which is HTTP/HTML/JS). It is waaaaay too corporatized and saddled with legacy and politics. Let the ad people and the man get http(s).
if you want to do other things, don't see value in the expedition, so be it go else where, do other things. I continue to see this as a shared, mutual platform, one accessible to all, embued with ever more power, but yes, sometimes the entities not so far orable to us also make use of that power. this is not a defect to me.
>showing full URLs makes it harder for non-technical users to distinguish between legitimate and malicious (phishing) sites, many of which use complicated and long URLs in attempts to confuse users
Why not simply make the domain name visually stand out from the rest of the url?
how would it look for this
I think that feature got lost again in the recent rewrite, though...
(Adds the idea to the list of things he wants in his 'Ultimate Browser' that one day he'll write.)
Putting some ugly characters in it isn't really any different to just hiding them
Mind blown! Never noticed that there.
Amazing! Thanks for the tip.
I would have guessed the situation would be the opposite, easy to set in FireFox, obscured/hidden in Chrome. But apparently not! :)
I'm quite sure this option wasn't there when this "experiment" was added.
Every single goddamn time Firefox tries to bring themselves to being the bottom of the barrel, where "naive users need apply", they alienate their user base and all the other people associated to those users. I know that trying to grab market share seems like an "appease more people in the population", but Mozilla repeatedly seems to forget how much we are evangelical for those who don't even know that Firefox exists. The more they try to dumb down their browser, the more market share they lose. They still haven't learned this, and it completely boggles the mind.
Over and over and over and over and over and over and over and over and over and over again… Mozilla makes the wrong choice in trying to dumb down their browser. I could repeat "over and over" another few dozen times. They need a change in management at some level, because we're back to this dumb crap… again, "over and over again".
EDIT: anyone care to explain the downvotes?
On secure sites, the full URL is displayed (including "https://").
I don't have an iPhone anymore but used to, and it was no problem that I only saw the domain, because on my phone I rarely cared about the specific address. When I'm working it's a bitch because quickly knowing the full address is useful all the time, and even at home much the same because I'm used to interacting heavily with my address bar.
I'd imagine that most people, even on their laptops, are closer to the former situation, so it's not hard for it to have relatively widespread support.
That the comments about it mostly come from developers or similarly tech-literate people is neither here nor there, comments are inherently personal. When I post on a forum about a feature, I'm generally presenting only my own opinion. When I'm implementing a feature, I'm generally basing it on the opinions of users, as best I can gather them.
I am also very much against hiding "www.", but that's mostly from a developer/devops perspective. https/http can be hidden behind an icon, that's fine since it's a binary option, but that's as far as I'd go in accepting stripping information from URL's.
I don't know how those two stances, or the positions between them, break down across the population, but at minimum it wouldn't surprise me to learn that it leans towards not understanding or caring.
URLs are mostly not fit for human consumption and don't even reliably show you what page you're on. They're a stinky skidmark on the otherwise human-accessible web.
I hope we can eventually have two clearly distinct parts to URLS - a simple domain name without www. or https:// and clearly separate, a human-readable name for the page without internal implementation details like filename extensions and symbols. Some sites are pretty close to this, New York Times is easily understandable but still filled with slashes and a redundant extension. Eg: "nytimes.com/2021/06/10/us/politics/justice-department-leaks-trump-administration.html". Hacker News is too but has a human-unfriendly "item?id=" before the (good, imo) incrementing decimal integer, not hex, not random, not padded ID number.
https://google.com/amp/something.com/directory/article
something.com
I might have set that as a preference, I can't remember.
edit - btw I don't mean to infer parent poster argues this point, however it is often the reason 'designers' argue for these kinds of regressions.
Doing the right thing even when it's not what you were hoping for deserves to be applauded.
The experiment didn't fail, it concluded.
Interesting, I wonder what exact 'security metric' they were measuring this against to determine if this feature would make the cut.
> we'll have study participants exploring the prototype in lab/survey studies, and we will also roll it out to a small % of real Chrome users to understand if it helps protect them from phishing. If the results show that this simplified domain display does help protect users from attacks, then we'll make a decision about whether to ship it to all users, balancing user feedback with the security considerations.
One of them has learned and is still getting better, but the other has been trying for 20 years and computers are turning into a phobia for her. As everything moves online there is a non-trivial portion of the population getting shut out. Government services are moving online for the most part.
Imagine not being able to help your grandkids with homework, or even do video calls during the pandemic, without a fear of losing your life savings.
I don't like the dumbing down of browsers and the web, but I do believe we (computer professionals, etc...) have to find a way to solve this problem for everyone.
Pretending extensions aren't a thing hasn't been successful in terms of security (see ATTACHMENT.doc.exe for details) and I question whether it's at the end of the day provided any benefits from reduced complexity.
I'm not sure they do to remotely the extent that they would need to, for file extensions to make sense. I expect that, to the average (say) grandma, there are 3 or 4 kinds of files:
Video, Image, Audio, Other
The first three match human senses. The ear (audio), the eye (images), the combination with motion (video). People have understood those are inherently different things since their childhoods. If your grandam is more advanced, maybe she also understands documents (like PDF), that represent physical papers she has in her hand. In any case, those are all reflections of physical things she already understands, but that's about it. She probably doesn't even understand .exe given that every app she sees would have a shortcut icon.
Now you're proposing that jumping from that to .jpg/.png/.bmp/.tif/.jpeg/.tiff/.webp/.gif/.jp2/.mp3/.aac/.wav/.wma/.mp4/.mpg/.mov/etc. is a huge step? Given how confused I know even I have been about file types in the past and what they mean, I... don't agree.
And sorry, but security is secondary here. Usability comes first.
How would showing or not an extension change that? Nobody would expect grandma to make any decisions on the extension.
I’ve been a position where I had to help advertisers with images for their web shops. Many of the advertiser to that understand aspect ratio, a pixel size, compression or image format at a basic level. I do not think that the concept of a landscape versus portrait image is difficult, nor is the idea that one image is made out of 100,000 squares and another one’s made out of 1 million, or that some have 12 colors like crayons and others have millions like a photo. But many people don’t try to advance their knowledge at all, depending on others to do their computer work for them. This wastes a huge amount of everyone’s time. I don’t really think it’s a good system to teach people that they can operate with the absolute minimum knowledge needed to operate a computer. At times it reminds me of children who haven’t taken the steps to do something like learn to take the lid off a jar and so coming to get you to do it every time even a year after they could’ve been doing it themselves.
I do understand that some people just don’t seem to get this stuff. My parents both have advanced degrees and were using computers when I was born, but they seem to have been struggling with the basics of emails and logins for 20 years now.
The problem here is that we we are discussing systems within windows and windows has a poor system for all of this. I’m not sure what Microsoft can do to improve it since I can’t really think of many positive changes they’ve made in this regard in the past 20 years, other than confirming execution with admin rights.
The main problem that comes up here is security. I agree that file formats don’t particularly matter to the average user, it only matters if a legitimate file opens in the right application when they click on it, and clicking on what appears to be a safe file doesn’t actually trigger an executable. Perhaps windows could prevent files from having a double extension. Perhaps MS could not allow executable files to be changed to different extensions. I don’t know. What I do know is that there’s many instances where hiding the extension has been a security problem, and I don’t know what evidence there is that it helps anyone use the system besides speculation. You can only dumb down a system so much before it loses necessary functionality.
E.g. URL length over 80 chars (https included) should be a penalty to search rank. So should parameters. Also everything impacting read- and spellability. URLs have to be designed on their own right. Remember Aaron Swartz's 'Programmable Web' opening chapter 'Building for Users: Designing URLs'.
Design had just no stake here while advertising had. Then happened what happens when candy champions bread.
The technicalities have to be commonplace and must not be hidden – like the wheels of a vehicle. You may not directly interact with them but you must be aware they're what it's all about.
The only thing that matters is the origin. Sad their data didn’t confirm the obvious.
Firefox emphasizes the main part of the domain name in darker text, so "ycombinator.com" is black while the rest of the URL is grey.
Chrome uses slightly darker text for the whole domain name, so "news.ycombinator.com" is black while the rest of the URL is grey — but the difference is so slight that it's nearly impossible to see. I don't know why they would bother to make the distinction and then make it visually indistinguishable.
Safari shows just the domain name, "news.ycombinator.com".
I tried to explain it here https://youtu.be/0-wB1VY3Nrc
The web is made of URLs and hiding them would be like taking the express train back to the AOL days. This "feature" would have brought negligible (if any) security, but would have made the web many times more difficult to use for both inexperienced and power users alike.
It's super easy to turn off in Safari Preferences though. Certainly easier than installing another browser.
This is the main problem with options over good defaults. An option requires enough understanding of the domain to realise that there might be other choices. It also requires enough knowledge to make that choice, especially for something that affects security (knowing if you're on a malicious website) but looks like a simple visual change (simplified URLs).
Usually it'll follow a pattern like:
"Hey friend, my browser is a bit rubbish, I can't see the page I'm on."
Friend uses Chrome and demonstrates how it doesn't do that.
"My friend's browser is better because the URL is clearer. I'll swap to that one."
Non-technical users will usually follow recommendations like that before they considering looking for an option to make the browser work the way they want it to. Configuration isn't something most users do unless it's either suggested by the application or there's a button literally in front of them.
https://news.ycombinator.com/reply?id=27470241&goto=item%3Fi...
and
then why would you actually need to see the full URL? Come to that, why would _anyone_ who isn't debugging a REST API need to see the full URL?
The address, however, still feels like it's behind a piece of glass--it animates to the left when I click it and highlights the whole address, not letting me find a spot to highlight until after this animation is done.
The behavior to center the URL in the location field when not in focus, but to reformat to the left when focused, is somewhat silly, though. (In someone's eyes, it's apparently a form sufficiently importantly impressive to go over function.)
Edit: That you can't grab and drag the icon associated to the URL (but rather the URL itself) is also inconsistent with the general UI. (In other words, Safari's location field is not a Mac UI element.)
It was only showing the domain.
// Called by omnibox code (when enabled) to check whether |url| should be elided
// to show just the eTLD+1 due to failing any number of heuristics.
I wish developers just stop experimenting on URL bars and leave them simple and consistent...
Lots of negatives and not really any positives I can think of.
// Hostnames using sensitive keywords (typically, brandnames) are often social
// engineering, and thus should only show the registrable domain.microsoft.scamsite.com amazon.scamsite.com
would turn into scamsite.com
that said users click on stuff pretty easily so not surprised it didn't move metrics that much.
Google's primary business is advertising. Regardless of what propaganda it spreads, the ultimate motivation of making a browser is to make more money for itself. Almost all the changes that it has done make perfect sense in that context.
But removing the path would be a burden to those discovering how the web really works.
Google really wants to kill the URL. If you have to navigate through Chrome and their search engine to get to things, they'll have sunk their claws deep enough that the web doesn't even matter anymore.
They want to serve and proxy all the content so they can inject more ads and tracking.
The EU and US DOJ should really be asking themselves whether or not the world's biggest search engine and advertising company should be allowed to develop the world's most popular browser. Maybe Google should be told to stop development of Chrome.
This reeks of mobile browser features creeping into desktop software. The use cases are entirely different. And the form informs the function -- you can't usually display a full URL on a mobile browser -- that is why you don't see it on mobile browsers.