One of the worst security bugs of browsers is the combined url/search bar. But Google loves it! What about .corp subdomains?
We had them separated once upon a time. UX was arguably worse.
I have them separated in firefox because i find it superior.
Chromium uses web search for .internal TLD instead of opening URL
21–30 of 96 posts
Re: Chromium uses web search for .internal TLD instead of opening URL
#22Having 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
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.
There’s mDNS, zeroconf, and Bonjour.
Re: Chromium uses web search for .internal TLD instead of opening URL
#23Having 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
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.
Rendezvous = Bonjour = Multicast DNS Service Discovery
Re: Chromium uses web search for .internal TLD instead of opening URL
#24One of the worst security bugs of browsers is the combined url/search bar. But Google loves it! What about .corp subdomains?
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.
Re: Chromium uses web search for .internal TLD instead of opening URL
#25Having 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
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."
Re: Chromium uses web search for .internal TLD instead of opening URL
#26One of the worst security bugs of browsers is the combined url/search bar. But Google loves it! What about .corp subdomains?
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?
Re: Chromium uses web search for .internal TLD instead of opening URL
#27Earlier quoted context omitted.
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)
Re: Chromium uses web search for .internal TLD instead of opening URL
#28Earlier quoted context omitted.
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?
The one that says "Search" in it?
Re: Chromium uses web search for .internal TLD instead of opening URL
#29What 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?
Re: Chromium uses web search for .internal TLD instead of opening URL
#30What 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 co…
probably just an ai or unskilled triage tech responding?