[matthewaveryusa]

It’s solving a very real problem for enterprises. They want to run local agents that serve up content with a cert chained to an installed trusted corp ca. In general localhost is a pain to reason about security-wise —- the best approach is to simply kill it (despite my personal nostalgic love for it.) Use a proxy instead and forget it exists — enterprise is now the owner of that domain.

[oefrha]

Local agents can serve up content with proper domain names, which can resolve to anything, including 127.0.0.1. There’s exactly zero reason to use the insane setup of HTTPS + HSTS with localhost.

Plus, what’s the benefit of encrypting on a loopback connection? Who’s intercepting?

[jeroenhd]

I'd be very annoyed if I were troubleshooting HTTPS/HSTS bugs and found out that certain headers were ignored because the target IP is localhost. It makes my life harder for no good reason other than to protect those who misconfigure their webserver from their own mistakes.

[Already__Taken]

You have that backwards. Parent was stating internal domain names can resolve to 127 to enable HSTS. Specifically using "localhost" should be the exception, not the resolution of 127. you could shove securehost in /etc/hosts as 127.0.0.1 to turn on HSTS for example.

[zarzavat]

How about no? Enterprise can use Chrome for Enterprise. Why are they using a consumer browser?

[ocdtrekkie]

Let me tell you a secret: They're all just the same browser. Every enterprise policy applies to consumer Chrome installs. The only real difference is that consumers often get a user-folder-installed version which annoyingly doesn't require admin rights to install, and businesses generally properly deploy an MSI file that installs to Program Files.

[marcosdumay]

So, now there's a good reason for them not to be the same browser, but rather be the same executable, but with different default settings.