Hacker News new | past | comments | ask | show | jobs | submit login
Chrome abandons 'simplified domain experiment' in omnibar (chromium.org)
263 points by uncertainrhymes 2 days ago | hide | past | favorite | 192 comments

Kudos to Emily Stark for letting the real data guide her decision. It's hard to let go of something you've invested a lot of effort in, and it seems like this was something she had strong feelings about. Doing the right thing even when it's not what you were hoping for deserves to be applauded.

Treating users like idiots who must be veiled from reality is, I hope, something we can continue to find good data against.

The maddening thing is that there is data that will always be ignored.

Like the % of users who will opt IN to cookies or tracking or similar.

And how many opt in just because the choices are "Manage site permissions... / Allow all"

IDK if "veiled from reality" is helpful here. Our job as software engineers is to build abstractions so like, glass houses and all that.

engineers & companies break the compact, but the truest, most compelling heart of the web is about viewing named things, and those names are urls.

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.

[1] https://www.w3.org/DesignIssues/Axioms.html

+1 to this.

Irrespective of what data says its a very bad idea. Data says lots of users visit porn sites. Now what?

Let them enjoy it?

"simplified domain" = address bar only shows domain name.

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-...

Not only that. On mobile, it meant that AMP delivered pages by google's domain were stripped out in a way that the publisher's domain was displayed, effectively MITMing the website from a user's point of view.

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.

I don't understand how the imprints on websites help with scams. Could you elaborate?

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?

> I don't understand how the imprints on websites help with scams. Could you elaborate?

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.

> that most people are too lazy to do this sort of background check before they buy something online

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.

Another popular payment option is to pay by invoice. Obviously this means the merchant assumes (almost) all the risk. Hence this option is not available most of the time.

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.

Lots of websites in India also offer payment via bank account, including amazon.in. The benefit from my POV was the same as you describe. I don't want random websites to have my credit card info and I don't want to deal with paypal.

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.

> Paying by bank account doesn't mean handing over bank account info.

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.

In India having somebody's bank details is not enough to debit it. Many business post their full account numbers and IFSC codes (sort of like a sort code) but with that info people can only send money into their account.

If you mean that some organization (not an individual) could Direct Debit you, then you have to hive your bank an explicit agreement for that.

If you do not, you reject the payment and it is now the bank problem.

An IBAN is never a secret.

Yes, you can have the charge reversed, but they can still make the charge initially. In that sense it is no different from a credit card: if they have your info, they can charge you again and you can have the charge reversed.

Direct Debit requires a special license - this is not something any company can dio. Making a fraudulent charge will have this license revoked.

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.

> Making a fraudulent charge will have this license revoked.

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.

The main difference is that in order to have Direct Debit capacities you must have a special, tight arrangement with the banking system. A generic company does not have this possibility.

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).

> by making a payment out of it

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.

> Paying by bank account doesn't mean handing over bank account info

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 ;)

Well, to be frank when you provide someone your credentials you oprn yourself to a new world of pain.

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)

Yep this flow is ripe for phishing. But I prefer it over just giving a card number that a merchant has the ability to store and eventually leak.

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.

> I prefer it over just giving a card number that a merchant has the ability to store and eventually leak

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).

Which cards are you using? AMEX? For the most commonly accepted schemes in Europe, i.e., Visa and MasterCard, requesting a chargeback typically goes through your card issuer which almost always is your bank.

> From my experience it was because they didn't have a credit card [..]

[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?

Your standard checking account will (almost) always come with a girocard, which is a national debit card scheme. It can be used to pay in stores, but not online. These cards are typically co-branded with either Maestro or V-Pay, so they can be used on the MC/Visa networks if you're outside of Germany. However, the latter functionality is also restricted to card present transactions. You just cannot use these cards to pay online.

> girocard [..]

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 ?



"Mit giropay können Sie sicher online bezahlen" (freely translated): "you can pay safely online with giropay"

Banks are offering online payment functionality with giropay and other solutions. This is, however, a fully separate product with a similar name. It was quite late to the market and isn't universally supported by online shops. It doesn't come with your girocard, is also not supported by all banks, and requires that the customer use online banking.

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.

“UX MITM” is the funniest thing I’ve heard all week

I don't even know how to call this to be honest. I mean, it's not scam, it's not MITM, it's not fraud but it's still trying to deceive users...so what is it?

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.

"Dark pattern" fits, but is not very specific.

Hmm, doesn't the latest version of Firefox show the domain in a slightly highlighted way? Wouldn't that be a good middle ground, if we wanted to make URLs easier to distinguish for the average user, without explicitly hiding that information?

Example: https://i.imgur.com/KludkrC.png

Chrome has done something similar for a long time, but keeps subdomains the same colour as the main domain (and deemphasises the path part).

>We think this is an important problem area to explore because phishing and other forms of social engineering are still rampant on the web, and much research shows that browsers' current URL display patterns aren't effective defenses.

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.


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.

But there's one fundamental truth about URLs: there is a single owner of a URL that decides what content appears at any particular address.

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.

> So it's less a street address and more of a mobile phone number.

For me, I see the domain name as the sign above the shop front.

Multiple shops can have the exact same sign. Domains and phone numbers are controlled by a single entity at a time, and that is an important attribute.

>Showing only the domain name was considered a good way to remove the extra chaff from a complex URL and only leave the core domain visible in the URL bar.

>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?

Yes! Bold out the domain and leave the rest of the URL in a slightly lower contrast color.

That's what Firefox is doing

Wow I legitimately never noticed before.

Chrome has already done that for a long time.

It already does, but I guess they didn't think that was enough.

browsers have tried that, and it doesn't do any good because the phishers just make a long enough domain that the bolded part gets pushed off the screen.

? just have the bolded part fixed and the long part off screen ?


how would it look for this

Expand the url bar to show the full domain like wrap text in cell works in excel. That would be pretty effective in showing scam urls

+1 to this. We're now in a world where long urls are the norm. The ominbox or urlbox should be [optonally] multi lined with word-wrap.

(Adds the idea to the list of things he wants in his 'Ultimate Browser' that one day he'll write.)

For a while, Firefox on Android used to right-align the TLD with the edge of the URL bar (plus a little bit of space, so you could tell whether the URL contained a path segment or not), so even excessively long subdomains couldn't push the main domain off-screen.

I think that feature got lost again in the recent rewrite, though...


Isn't this basically the same solution as the one chrome was experimenting with - selectively hiding portions of the URL that they seemed irrelevant?

Putting some ugly characters in it isn't really any different to just hiding them

At least Chrome let you right click the URL field and choose to view full URLs. Firefox has also started messing with the way URLs are displayed and you have to trawl through the about:config settings to stop the insanity.

I don't understand what this is referring to WRT Firefox. In Firefox I'm seeing the full URL right now, and have never not seen a full URL, and have never needed to configure anything. By "insanity" is this just referring to the way that Firefox renders the TLD and 2LD in black and the rest in gray? What about:config setting is this obliquely referencing?

EDIT: anyone care to explain the downvotes?

Firefox hides the "http://" and only shows a crossed out padlock icon.

On secure sites, the full URL is displayed (including "https://").

I haven't noticed (I guess I don't visit http sites?), but that's quite different from the behavior the article is describing, where every component except the TLD and 2LD are completely absent.

Just right clicked a URL in chrome and saw the "Always show full URLs" option.

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! :)

This is fantastic, how did I not know about this before!

Just learned this too! I never use the mouse to type in the URL bar. Ctrl+L :)

> Never noticed that there

I'm quite sure this option wasn't there when this "experiment" was added.

It was, they added the right click option shortly before starting the experiment.

The worst is when you copy an fqdn from the address bar to use somewhere else, and it copies the https, even though it didn't show it to you

I remember finding this setting before, for myself and at least half a dozen other people in my life. Not seeing the full URL is something that Mozilla should have fucking understood was something their users want. Firefox is supposed to be the "Good Browser™", which includes technical users configuring the browser for other people in their lives.

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".

I find it weird how Chrome threads turn into an attack on Mozilla or rant about Firefox. Firefox does not hide the full URL. Never has done in my experience.

Maybe take a deep breath and relax a bit before posting next time.

Why did everybody lose their minds over this? It seems Safari does this without much drama.

Huge reason was that Google also simultaneously pushed AMP while hiding that pages are hosted on Google servers. So if you visited page like:

And in your address bar there will be just:

This is literaly URL hijacking and it's fundamentslly breaks trust in your address bar.

Did google do that as part of this feature?

No, but I sure backlash against feature discussed here wouldn't be as big if Google's other hand wasn't pushing fake URLs for AMP pages.

You may refer SXG, but it seems that anyway SXG overrides URL to origin. So this is irrelevant.

The argument that the address bar is too complex and we need to dumb it down is irritating. If we want to regress to AOL keywords then great. I would prefer we stick with an address bar. Let those who can learn the reason it exists and how to use it, learn.

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.

I was wondering about exactly the same thing, had to use Safari for work recently and not seeing the URL was extremely confusing.

In preferences it’s simply a check box to have it show full URLs in safari all the time.

Yes, as someone who only occasionally uses a Mac, I always think Safari is broken until I remember Apple tries to hide everything from you for your own good.

This might be news to you, but many apps on Mac actually have preferences that allow you to change their behavior. That's one of them.

If you can't do anything, you also can't do anything bad!

I like to know which page I'm on

The current one

The next change Google will try is replacing the URL with just "The current one".

That’s basically what this experiment was. Show the origin only. The current page is obvious from the page itself.

Pure speculation, but maybe because most of the commentary on this was coming from developers.

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.

On a phone there simply isn't space to display much more than the domain name. Picking some subset of the URL to display is unavoidable, and the domain name usually going to be a better subset than the obvious other options of the start or the end of the URL. As such I see nothing wrong with it there. On desktops you do typically have enough space to show the full URL, so I dislike it showing only the domain name.

As a user it's often also helpful to understand the context of what you're reading (as long as the site has a descriptive URL structure) - is this a blog post, featured article, sponsored article, when was it written.... a good URL conveys a lot of useful information and hiding this seems highly counterproductive.

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.

That's the kind of usage that only happens because it's available. No matter what internal information is presented to people, some will find a way of using that. But part of designing software is to curate what information to show the user, not dump an arbitrary pile of cryptic internal details on them.

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.

I'm 100% with you, but I know plenty of fairly computer-literate people who wouldn't know how to interpret a URL, and wouldn't know what to do with that information if they did.

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.

Who is going to advocate for users if not developers? It’s like giving out that civil rights lawyers are lawyers so why is their work relevant to ordinary citizens

How is this not advocating for users? They tested the idea based on a metric they hoped would improve among users, found it didn't work, and so left it as is.

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.

Yeah and they came to the same conclusion as “the cranky developers” had been moaning about all along. Fancy that.

/me looks up, see a full URL in Safari's address bar, looks down, reads comment, looks up...

I might have set that as a preference, I can't remember.

I had to turn it off in Safari, not a good ux.

I imagine most people here used Chrome before people started switching to Firefox once Google's large presence became more of a concern.

Safari doesn't have enough marketshare for people to get very upset about it, and more importantly you can turn it off, which people did not trust Google to do.

Safari is what safari does

Safari was always garbage; Chrome used to fight for the users and now it's fighting for Master Control.

Kudos to Emily Stark for letting the real data guide her decision. It's hard to let go of something you've invested a lot of effort in, and it seems like this was something she had strong feelings about.

Doing the right thing even when it's not what you were hoping for deserves to be applauded.

The verbiage of this article: "Google’s experiment ... has failed" - seems to be written by someone who doesn't know what an experiment is for. It did exactly what it was meant to - provide the data needed to make the right decision. Kudos to those involved for following the data.

The experiment didn't fail, it concluded.

Deja vu. I feel like I have seen this comment before.

> This experiment didn't move relevant security metrics, so we're not going to launch it. :(

Interesting, I wonder what exact 'security metric' they were measuring this against to determine if this feature would make the cut.

From the bug:

> 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.

If I were to guess, conversion rate on phishing sites

Probably financial security of C-suite :)

This is the same bad idea as hiding file extensions.

I'm actually not sure hiding file extensions was a bad idea. As a developer I hate it, but I'm not sure for ordinary users they should be visible or editable as easily as the file name.

Why do we have to design for the lowest capacity users? Are they the largest demographic, or doesn't that matter?

I can tell you it's been a total nightmare when family members have been phished and hacked. It's happened to grandparents on both sides of the family.

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.

Well it depends on what you're designing. For a general-purpose OS used by everyone and their grandmothers, it makes sense to have them in mind and let the more advanced users customize the settings. And I would assume non-computer-savvy folks are indeed the largest demographic too, though I don't have data on it. And also, if you believe it's a good thing for the world to become digital (say, to reduce carbon emissions), you need products and services to be accessible to most kinds of users.

They're the least able and likely to make their way to settings to change it.

I agree about editable, but it's a critical piece of information. Users already deal with the concept that some files are images, some are audio, some are documents and so forth without apparent problems understanding that. The concept that different types of documents have different random letters at the end isn't a huge step.

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.

> Users already deal with the concept that some files are images, some are audio, some are documents and so forth without apparent problems understanding that.

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.

Your example with matching human senses is excellent (I will reuse it) but I do not understand the link with extensions.

How would showing or not an extension change that? Nobody would expect grandma to make any decisions on the extension.

Until yesterday I had a IMO even more annoying problem: Dead keys on a qwertz keyboard and "," as the separator on the numpad. So glad that I finally made a custom layout that fixed those.


There's no perfect tradeoff.

But what's the advantage of hiding file extensions? Windows already asks if you're sure when you try to change a file's extension.

The advantage is you don't show something that laymen probably wouldn't want to change 99% of the time. That way they don't do it by accident and mess up their files. Not every user even knows what a "file extension" is in the first place. Or whether/when it should be changed. See if your grandma can comprehend that error message.

You show extensions to users not so they can change them, but so they can see that a file is actually a .jpg instead of a .exe with the icon of a .jpg.

Your grandma isn't going to look at .exe every single time when she sees a photo icon.

I have taught my mother to do just that.

Windows already asks if you're sure when you try to change a file's extension.

Ever clicked on document.exe?

Ever heard of Windows Defender?

the design issues of URLs are IMO less technical and much more SEO induced. Google has a lot to say here.

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 problem with your stance is that URLs don’t matter.

The only thing that matters is the origin. Sad their data didn’t confirm the obvious.

I'm all for making phishing less effective, but this was just bad UX.

Why not instead apply syntax highlighting to the URL?

That's a good idea.

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".

You can build a very long name yo push the domain outside the visible part of the form. This way all of your text is the same color and you may not realize that what you see does not have the domain part.

it does

Isn't this implemented on Safari for some time now?

Yes, and it is awful. I know no Mac user who isn't using Chrome and the hidden URL is one reason for this.

I use safari exclusively at work and at home. It’s just a better browser; simpler, faster and behaves like a Mac app should. The only things I miss about chrome are the plugin ecosystem and the (better) address bar suggestions.

> the hidden URL is one reason for this

It's super easy to turn off in Safari Preferences though. Certainly easier than installing another browser.

To turn it off you first need to know that Safari is doing something to the domain. That requires some basic understanding of URL structures that non-technical users don't have. They often won't go looking for an option because they don't know there's another way to view addresses.

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).

A user that uses Chrome because Safari simplifies the URL must be aware that Safari simplifies the URL.

They're probably only aware that Safari and Chrome display different things in the address bar. If they don't like Safari they'll switch to something they prefer.

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.

If you're not technical enough to see what the specific difference is between




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?

To create a document with links. Hiding the URL makes that harder for non-technical users IME.

But if you copy-paste it, it will copy the full URL. Even if you copy directly without tapping. I don't think there's a way to get just the domain.

I didn't expect it to be a problem, but empirically it is.

Contra data point here, I don’t use Chrome besides at work, enjoy the simplicity

Anecdote, I am using Safari for speed, except for Google Meet (since Safari seems to have never-ending issues with that, for some reason).

A lot of Mac users are using safari for other reason. If there will be a true exodus, it will be because of the horrendous “tab” redesign in macOS 12

What's horrendous about it? Haven't really tried it much yet, but it seems to acknowledge that most people use tabs as a form of less permanent bookmarks, and for that it seems perfect.

Because control elements that change size and move around are bad. In Safari's case that would be the address bar.

Which is strange because displaying the full URL is an option in the Safari Preferences (on macOS, not on iOS)...

Just out of curiosity, are all your Mac friends web developers or is there some reason a normal user would want to see the entire URL?

Yes, I don't care for it personally but it is a behavior that can be turned off.

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.

Preferences > Advanced > Check "Smart Search Field: Show full website address"

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.)

Yes. Years. I think a URL bar that sticks to the security relevent parts is a good idea. It's hard for even experienced users to figure that stuff out.

I tried to explain it here https://youtu.be/0-wB1VY3Nrc

Well I mean the whole story is that google's own evidence was that the experiment didn't bear any fruit.

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.

I could also live without hiding the protocol for non-secured websites. I mean leave the label there, I don't care, but whenever I want to copy the domain of a HTTP website, it also automatically prepends it with the protocol, which more often than not is not what I want.

I wish developers just stop experimenting on URL bars and leave them simple and consistent...

What do they mean by "we're not going to launch it"? Doesn't Chrome already hide the URL scheme and www subdomain?

This is the commit: https://chromium.googlesource.com/chromium/src/+/180e57971e7...

  // 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.
The heuristics: https://chromium.googlesource.com/chromium/src/+/322283e5085...

This would have removed the path from the omnibox until the user hovers, much like mobile browsers or Safari.

Simplified domain was supposed to hide the path too. Display only the domain name so that the user can focus there only which really mattered.

It's such a weird thing to change in the first place, who benefits from it??

Lots of negatives and not really any positives I can think of.

If you support a larger / older user base you'd understand immediately what they are trying to deal with.

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.

Or, worse, "amazon.com.contact-support.something-else-to-confuse-the-user.shadytld". Even with the path part of URLs dimmed, users are really bad at identifying the authoritative part of a hostname.

No question - outlook users struggle here particularly especially if bit behind a Google class filter for email etc (legacy email)

Users are bad at it because English is ordered left to right. The path also is. The domain is right to left. It was designed by morons.

Ironically the opposite order predates the current standard: https://en.wikipedia.org/wiki/Reverse_domain_name_notation#H...

It bugs me that the normal notation is called "reverse notation". :D

It seems that they were combating phishing sites. A comment from the field trial's code:

  // Hostnames using sensitive keywords (typically, brandnames) are often social
  // engineering, and thus should only show the registrable domain.

I suppose this implies that the average non-technical user pays no attention to the contents of the address bar? Perhaps for Google to improve security metrics maybe the user needs a new canonical UI element indicating what site they're on, since to most people the address bar is just computer noise.

Sounds to me like they see their users as idiots.

They are sheep to be gently herded and monetised.

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.

Always wondered when this, removing the path after the domain, would be put in. It's visually simpler and would probably improve the metrics recording perceived sleekness of user experience.

But removing the path would be a burden to those discovering how the web really works.

Why not just take out the address bar altogether.

The purpose of removing the path and subdomains is that some people think it will help stop phishing. Does anyone think removing the domain name will help stop phishing?

Removing the URL didn't seem to stop phishing. I was just being obtuse.

Thank God

Just wanted to post the same.

Good, now Safari next, please.

Sweet Jesus thank you. Whomever thought this was a good idea needs to have their hands removed from any production database. There has got to be a better way to help people realize they're on the right domain than removing information for everyone.

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.

I wonder if highlighting the naked domain (example.com) would be useful.

Funnily enough, that's exactly what Firefox is doing.

Good lord this one guys's mess up address bar OKR pursuit finally stops.

Google stops malicious blablabla... due to a public outrage and temporarily, until most will forget about it.

Oh well, was worth a shot.

This felt like phase two of putting everything under the AMP umbrella, and I would not be shocked if Google shut this down out of fear of regulatory scrutiny.

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.

Also a mobile OS don't forget. So in the less monied parts of the world, (the majority), Google supplies the dominant mobile OS, mobile browser and search engine. As well as email, voice and location services.

Ah sense prevails for once

Oh thank God, this was so irritating. At least it didn't last long.

Anyone what the "security metrics" they referenced in the commit message were that they thought would be impacted by making this unrequested change to how the web works?

Probably conversion rate on phishing sites

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact