Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.localhost Domains

inclouds.space

Post reply on HN
Print view View original

181–190 of 212 posts

Re: .localhost Domains

#181

Post by morjom »

onre wrote: post #169
morjom wrote: post #165

Earlier quoted context omitted.

It would be more like .mold.ticket

Thanks, I always mix up mold and mildew. However, "arpa" is specifically a lottery ticket, whereas there are tickets for concerts, tickets to ride, tickets in Jira etc...

Arpa is used for all kinds of random chance things, not specifically for lottery. I feel like ticket would still be the equivalent but I guess that would be more transliteration and opinion than direct translation? Also my view for lottery may be skewed due to the Finnish lottery culture, and how lottery has more meanings in English. Sorry turned ranty.

Re: .localhost Domains

#182

Post by mbreese »

watusername wrote: post #151
isleyaardvark wrote: post #136

Earlier quoted context omitted.

For anyone unaware, the domain 'example.com' is specifically reserved for the purpose of testing, so you don't have to worry about some rando reading emails sent to "test@gmail.com"

I don't get it. What does gmail.com have to do with example.com?

Is a public service announcement. If you’re using test@gmail.com to actually test something, you should probably be using test@example.com. Not everyone knows that example.com exists for these purposes.

That is of course unless you really intend to send an email to someone at test@gmail.com.

Re: .localhost Domains

#183

Post by DrBazza »

onre wrote: post #169
morjom wrote: post #165

Earlier quoted context omitted.

It would be more like .mold.ticket

Thanks, I always mix up mold and mildew. However, "arpa" is specifically a lottery ticket, whereas there are tickets for concerts, tickets to ride, tickets in Jira etc...

Arguably, Jira ‘has issues’.

Re: .localhost Domains

#184

Post by wutwutwat »

jrvieira wrote: post #179
bolognafairy wrote: post #163

Earlier quoted context omitted.

Well shit. TIL. Time to go reduce the complexity of our dev environment.

you should never trust browsers default behavior 1. not all browsers are the same 2. there is no official standard 3. even if there was, standards are often ignored 4. what is true today can be false tomorrow 5. this is mitigation, not security

1. not all browsers are the same

they are all aiming to implement the same html spec

2. there is no official standard

there literally is

> A context is considered secure when it meets certain minimum standards of authentication and confidentiality defined in the Secure Contexts specification

https://w3c.github.io/webappsec-secure-contexts/

3. even if there was, standards are often ignored

major browsers wouldn't be major browsers if this was the case

4. what is true today can be false tomorrow

standards take a long time to become standard and an even longer time to be phased out. this wouldn't sneak up on anyone

5. this is mitigation, not security

this is a spec that provides a feature called "secure context". this is a security feature. it's in the name. it's in the spec.

Re: .localhost Domains

#185

Post by thaumasiotes »

alexvitkov wrote: post #89
hardaker wrote: post #20

You might check out .internal instead which was recently approved [1] for local use. [1]: https://en.wikipedia.org/wiki/.internal

Too much typing, and Chromium-based browsers don't understand it yet and try to search for mything.internal instead, which is annoying - you have to type out the whole http://mything.internal . This can be addressed by hijacking an existing TLD for private use, e.g. mything.bb :^)

> Chromium-based browsers don't understand it yet and try to search for mything.internal instead, which is annoying

That's hardly the only example of annoying MONOBAR behavior.

This problem could have been avoided if we had different widgets for doing different things. Someone should have thought of that.

Re: .localhost Domains

#186

Post by jbverschoor »

jeroenhd wrote: post #178
jbverschoor wrote: post #138

Earlier quoted context omitted.

Docs at https://docs.orbstack.dev/docker/domains Forgot to add .local I see

I hope Orbstack is also advertising those hostnames on mDNS, because using .local (or, seemingly worse, _relying_ on .local) will conflict with resolver logic on all kinds of devices.

I'm not seeing any broadcasts.

What it does is it has a private network for the containers and itself (all containers get their own unique IP, so there's no port mapping needed).

http://orb.local simply lists all running containers.

The host-names are automatically derived from the containername / directoryname / compose project, but you can add other hostnames as well by adding docker labels.

It works really well.

Re: .localhost Domains

#187

Post by globular-toast »

jFriedensreich wrote: post #25

Chrome and i think Firefox resolve all .localhost domains to localhost per default, so you don't have to add them to the hosts file. I setup a docker proxy on port 80 that resolves all requests from .localhost to the first exposed port of that container (in order of appearing in the docker compose file) automatically which makes everything smooth without manual steps for docker compose based setups.

Source for this? Are you sure it's not your system resolver doing it?

Re: .localhost Domains

#188

Post by kbolino »

wutwutwat wrote: post #184
jrvieira wrote: post #179

Earlier quoted context omitted.

you should never trust browsers default behavior 1. not all browsers are the same 2. there is no official standard 3. even if there was, standards are often ignored 4. what is true today can be false tomorrow 5. this is mitigation, not security

1. not all browsers are the same they are all aiming to implement the same html spec 2. there is no official standard there literally is > A context is considered secure when it meets certain minimum standards of authentication and confidentiality defined in the Secure Contexts specification https://w3c.github.io/webappsec-secure-contexts/ 3. even if there was, standards are often ignored major browsers wouldn't be m…

Notably, assuming conformance to this standard, a browser might still not treat localhost domains as trustworthy if it has reason to believe they can be resolved remotely. However, I'm not sure in what environments this is likely to be the case, especially with browsers implementing their own DNS over HTTPS.

Re: .localhost Domains

#189

Post by kbolino »

globular-toast wrote: post #187
jFriedensreich wrote: post #25

Chrome and i think Firefox resolve all .localhost domains to localhost per default, so you don't have to add them to the hosts file. I setup a docker proxy on port 80 that resolves all requests from .localhost to the first exposed port of that container (in order of appearing in the docker compose file) automatically which makes everything smooth without manual steps for docker compose based setups.

Source for this? Are you sure it's not your system resolver doing it?

It's probably both. Browsers now have built-in DoH so they usually do their own resolving. Only if you disable "secure DNS" (or you use group policies) will you fall back to the system resolver anymore.

Re: .localhost Domains

#190

Post by Pxtl »

jeroenhd wrote: post #176
Pxtl wrote: post #131

Earlier quoted context omitted.

> HTTPS on LAN is essentially useless Public wifi isn't a thing? Nobody wants to admin the router on a wifi network where there might be untrusted machines running around?

Sure, but you can connect those devices to a real domain and use Let's Encrypt on them, or you can TOFU and add the self-signed cert to your browser; after you've verified that you're not being MitM'd by one of those untrusted devices, of course (I dunno, by printing the public key on the side of the device or something?). In practice, you probably want an authorized network for management, and an open network with t…

The former just aren't practical for small business and home consumers, though. Browsers just don't have good workflow for TOFU.

I agree on the latter, but that means your IoT devices being accessible through both networks and being able to discriminate which requests are coming from the insecure interface and which are coming from secure admin, which isn't practical for lay users to configure as well. I mean, a router admin screen can handle that but what about other devices?

I know it seems pedantic, but this UI problem is one of many reasons why everything goes through the Cloud instead of our own devices living on our own networks, and I don't like that controlling most IoT devices (except router admin screens) involves going out to the Internet and then back to my own network. It's insecure and stupid and violates basic privacy sensibilities.

Ideally I want end users to be able to buy a consumer device, plug it into their router, assign it a name and admin-user credentials (or notify it about their credential server if they've got one), and it's ready and secure without having to do elaborate network topology stuff or having to install a cert onto literally every LAN client who wants to access its public interface.

Post reply on HN