What a bizarre response from Google, a couple hours after this was posted:
> @Reporter: As we are not very clear about the issue being faced by you, could you please elaborate on the same by providing detailed manual repro steps to reproduce the issue from our end.
> Also requesting you to share the expected, actual behaviours along with screen-cast for better understanding of the issue.
> *Note: Requesting you to copy-paste the entire content of "chrome://version/?show-variations-cmd" details to a .txt file format and attach it.
> Thanks..!
What could possibly be unclear about this bug report?
I'd tend towards the latter, AI would have been more wordy and polite (it would have written "Also, please share" instead of " Also requesting you to share").
Sounds like someone just had a desire to make this pesky bug report go away, requesting detailed version information, detailed steps to reproduce, expected behaviour and a screencast (!), hoping the reporter wouldn't provide them so they have an excuse to close the ticket?
Personally I like them separate. But I’ve been working with folks who are not very computer literate at all and I think I agree with you. If one doesn’t know what a URL is in the first place, how would one distinguish which box to type in?
Having them be the same can make tech support a nightmare trying to figure out whether someone actually successfully entered a URL or if they just googled it :(
(I personally love the URL bar & search bar being the same bar)
I get the luxury of working with folks in person. In 99% of cases the search produces the right website as the first result. But yeah idk maybe AOL had something going with keywords in some sense in terms of accessibility ¯\_(ツ)_/¯
I think that’s part of it. I love URLs (and URIs). Another big part is the predominance of closed social media platforms where the concept of a URL is mostly irrelevant
You have it backwards: The omnibox (or whatever you want to call it) came about because people don't know what the hell a Universal Resource Locator is.
Most people don't know how to navigate their local file system, let alone the internet.
I had managed to make a old version of Firefox to treat URLs entered in the location bar as relative. In my opinion, this is the reasonable way to work. The computer doesn't have to guess what you mean, and does not have to guess if the TLD is valid. It will do what you typed into the computer; and if it is an error, will display the error message.
For searching, I had done that if you put a colon at first and then the name of the search engine, then it will search.
No, everyone loves it. By everyone I mean the vast majority of the world.
The fact of the matter is most people do not grok addresses, so a dedicated address bar is useless to them. It's bad user interface design that defies what most people can do.
Here's how most people actually use a web browser if they want to go somewhere, say Amazon:
1. Type "amazon".
2. Enter.
3. First result is (probably) amazon.com.
4. Click.
5. ????
6. PROFIT!
In the dark ages this was facilitated by setting the home page to a search engine like Google, changing the address bar to a search bar removes that additional step making it that much easier for the common man.
Is it horrible for security and privacy? Yeah. But you write a web browser for users, not security and privacy nazis.
Could we please not use such a term for privacy/security conscious people?
Maybe it’s because I am German but I feel very uncomfortable being called such.
Resolved (2024.07.29.06), the Board [ICANN] reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications. The Board recommends that efforts be undertaken to raise awareness of its reservation for this purpose through the organization's technical outreach
Can’t you usually force it to skip the search by prefixing with the schema? Certainly if I type in http://example.internal and press enter, I would be very displeased to have that turn into a Google search regardless of whether the part after the // fits some regex or whatever else internal to the browser.
Right, considering that single-label names (indistinguishable from search queries) have been a thing since WINS/NetBIOS, DHCP suffixing, etc. -- expecting a dot (let alone a dot followed by a public suffix) is bogus.
Actually, entering _anything_ that looks like a FQDN should automatically bypass search in any browser. It’s been a long-standing pain of mine that when browsers merged the URL and search fields it became impossible to type “home.lan” (or .local, or .internal) and have it just work without stomping out http:// in front.
Also one of the reasons I seriously appreciate Firefox, because you can still have a dedicated search box to the right side of the URL entry field/address bar, and easily reach it by hotkey by command-K on MacOS or other similar shortcuts on Linux, Windows.
The number of times I've typed some internal-only thing or raw IP address into a browser and had it go to a search page instead of the thing I want to talk to, I've lost track of in the past 15 years, and it's too damn high.
Also a good argument for, if you run internal-network only resources, to purchase and use an actual domain for it (such as companyname.us or whatever).
Publish a zone file for the domain as authoritative master and secondary on an internet facing DNS server, but have basically no records in the zone (no useful A or CNAME or anything else).
Host the actual DNS for your internal services on your internally-accessible-only DNS server.
Hanlon's razor is malicious. Assuming malice is the trivial right choice. Assuming stupidity just bc it rhymes, or bc you can feel smart about yourself is stupid.
Isn't .local specific to 'rendezvous' tech anyway? I forget the generic name but it was Apple that put it on the map under this name. But I mean that serverless broadcast protocol.
What I do is I just bought a domain and use that together with DNS-based SSL. It's a bit hard to set up with every different SSL server but it's doable.
The non Apple name is multicast DNS or mDNS. mDNS is exclusive to .local, but not necessarily the other way around. From its Wikipedia entry:
"By default, mDNS exclusively resolves hostnames ending with the .local top-level domain. This can cause problems if .local includes hosts that do not implement mDNS but that can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that mDNS was designed to avoid."
What a bizarre response from Google, a couple hours after this was posted:
> @Reporter: As we are not very clear about the issue being faced by you, could you please elaborate on the same by providing detailed manual repro steps to reproduce the issue from our end.
> Also requesting you to share the expected, actual behaviours along with screen-cast for better understanding of the issue.
> *Note: Requesting you to copy-paste the entire content of "chrome://version/?show-variations-cmd" details to a .txt file format and attach it.
> Thanks..!
What could possibly be unclear about this bug report?
probably just an ai or unskilled triage tech responding?
I'd tend towards the latter, AI would have been more wordy and polite (it would have written "Also, please share" instead of " Also requesting you to share").
Sounds like someone just had a desire to make this pesky bug report go away, requesting detailed version information, detailed steps to reproduce, expected behaviour and a screencast (!), hoping the reporter wouldn't provide them so they have an excuse to close the ticket?
Maybe outsourced?
Nah, it’s “AI”.
One of the worst security bugs of browsers is the combined url/search bar. But Google loves it!
What about .corp subdomains?
I think it's the autocomplete in particular that leaks a lot of private data. I've rarely had the combined bar do a search when I didn't want it to.
But I use firefox and I turned off autocomplete. And I use my own search instance (SearXNG)
> I think it's the autocomplete in particular that leaks a lot of private data.
That’s the beauty. The whole unified input can be presented as a UX simplicity gain, while this quote points at the actual business value. ;)
IIRC there is no setting in Firefox to keep the content of the URL bar local.
How could searchengines provide suggestions without your browser sending the url-bar content?
If you want the content of your URL bar to stay local you should disable suggestions
We had them separated once upon a time. UX was arguably worse.
Personally I like them separate. But I’ve been working with folks who are not very computer literate at all and I think I agree with you. If one doesn’t know what a URL is in the first place, how would one distinguish which box to type in?
Having them be the same can make tech support a nightmare trying to figure out whether someone actually successfully entered a URL or if they just googled it :(
(I personally love the URL bar & search bar being the same bar)
I get the luxury of working with folks in person. In 99% of cases the search produces the right website as the first result. But yeah idk maybe AOL had something going with keywords in some sense in terms of accessibility ¯\_(ツ)_/¯
It's because of the omnibox that people no longer know what an URL is.
I think that’s part of it. I love URLs (and URIs). Another big part is the predominance of closed social media platforms where the concept of a URL is mostly irrelevant
You have it backwards: The omnibox (or whatever you want to call it) came about because people don't know what the hell a Universal Resource Locator is.
Most people don't know how to navigate their local file system, let alone the internet.
The one that says "Search" in it?
You’d be surprised how many folks don’t turn up their font size when they have bad vision
I have them separated in firefox because i find it superior.
Me too. I search through both URL bar and search bar, and sometimes I use the search bar as a scratchpad of sorts – very convenient IMO.
I had managed to make a old version of Firefox to treat URLs entered in the location bar as relative. In my opinion, this is the reasonable way to work. The computer doesn't have to guess what you mean, and does not have to guess if the TLD is valid. It will do what you typed into the computer; and if it is an error, will display the error message.
For searching, I had done that if you put a colon at first and then the name of the search engine, then it will search.
No, everyone loves it. By everyone I mean the vast majority of the world.
The fact of the matter is most people do not grok addresses, so a dedicated address bar is useless to them. It's bad user interface design that defies what most people can do.
Here's how most people actually use a web browser if they want to go somewhere, say Amazon:
1. Type "amazon".
2. Enter.
3. First result is (probably) amazon.com.
4. Click.
5. ????
6. PROFIT!
In the dark ages this was facilitated by setting the home page to a search engine like Google, changing the address bar to a search bar removes that additional step making it that much easier for the common man.
Is it horrible for security and privacy? Yeah. But you write a web browser for users, not security and privacy nazis.
> nazis
Could we please not use such a term for privacy/security conscious people? Maybe it’s because I am German but I feel very uncomfortable being called such.
From TFA:
Can’t you usually force it to skip the search by prefixing with the schema? Certainly if I type in http://example.internal and press enter, I would be very displeased to have that turn into a Google search regardless of whether the part after the // fits some regex or whatever else internal to the browser.
Right, considering that single-label names (indistinguishable from search queries) have been a thing since WINS/NetBIOS, DHCP suffixing, etc. -- expecting a dot (let alone a dot followed by a public suffix) is bogus.
Adding a trailing / does it as well.
As a workaround you can type a trailing slash: example.internal/
I find auto-complete adding to this annoying behavior. It's (nearly) broken the 'view-source:' functionality in Chrome on Android
it's the deliberate dumbing down of the computer to the ordinary user, in the name of ease of use.
Whether intentional malice, or unintentional incompetence is moot by now. The effect has already been done.
Actually, entering _anything_ that looks like a FQDN should automatically bypass search in any browser. It’s been a long-standing pain of mine that when browsers merged the URL and search fields it became impossible to type “home.lan” (or .local, or .internal) and have it just work without stomping out http:// in front.
Also one of the reasons I seriously appreciate Firefox, because you can still have a dedicated search box to the right side of the URL entry field/address bar, and easily reach it by hotkey by command-K on MacOS or other similar shortcuts on Linux, Windows.
The number of times I've typed some internal-only thing or raw IP address into a browser and had it go to a search page instead of the thing I want to talk to, I've lost track of in the past 15 years, and it's too damn high.
The first thing I do after installing a web browser is disable search for the URL bar.
Is that even possible? I agree that it should be the default behavior.
..maybe I can set up an own mock search service on localhost. Hmph, I will think about it
In the comments.
>Firefox does this correctly
Perfect.
I gotta say, I didn't like when Google grabbed .dev, but now I like having a .dev domain =)
Is the motivation known for this change? Any clue from commit history?
There has not been a change, it's always worked like this. ICANN only reserved *.internal for use in internal networks a few months ago.
This. I suppose they use a list of TLDs to check if something looks like a domain, and .internal is not on the list and needs to be hardcoded.
safari also does the same thing
Also a good argument for, if you run internal-network only resources, to purchase and use an actual domain for it (such as companyname.us or whatever).
Publish a zone file for the domain as authoritative master and secondary on an internet facing DNS server, but have basically no records in the zone (no useful A or CNAME or anything else).
Host the actual DNS for your internal services on your internally-accessible-only DNS server.
Also can use DNS validation with Let’s Encrypt this way!
Having trouble not attributing to malice that which is adequately explained by stupidity here...
For Home Assistant for instance, the only reasonable option is .internal - its default .local is not the right TLD to use. [1]
[1]: https://serverfault.com/a/937808
Hanlon's razor is malicious. Assuming malice is the trivial right choice. Assuming stupidity just bc it rhymes, or bc you can feel smart about yourself is stupid.
Isn't .local specific to 'rendezvous' tech anyway? I forget the generic name but it was Apple that put it on the map under this name. But I mean that serverless broadcast protocol.
What I do is I just bought a domain and use that together with DNS-based SSL. It's a bit hard to set up with every different SSL server but it's doable.
The non Apple name is multicast DNS or mDNS. mDNS is exclusive to .local, but not necessarily the other way around. From its Wikipedia entry:
"By default, mDNS exclusively resolves hostnames ending with the .local top-level domain. This can cause problems if .local includes hosts that do not implement mDNS but that can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that mDNS was designed to avoid."
Per https://www.iana.org/assignments/special-use-domain-names/sp... and https://www.rfc-editor.org/rfc/rfc6761.html .local. is only for mDNS, but as with any other name you can always misuse it (see .corp. .dev. etc.).
I notice .alt. now exists.
There’s mDNS, zeroconf, and Bonjour.
https://en.wikipedia.org/wiki/.local
Rendezvous = Bonjour = Multicast DNS Service Discovery
> its default .local is not the right TLD to use
What if you advertise it on mDNS?