Once upon a time, typing “www” at the start of a URL was as automatic as breathing. And yet, these days, most of us go straight to “hackaday.com” without bothering with thos…
Originally the idea was that you would have a domain and then have a host under that domain for each service (e.g. mail.example.net, ftp.example.net, www.example.net,…). Of course eventually the web was used by a lot more people this directly than any other service so the main domain was also configured to point at the web server and then people added a redirect either in one direction (add www.) or the other (remove www.) on the first request.
The final piece is that often each of those services would be on a different computer entirely, each with a different public IP address. Otherwise the port is sufficient to sperate most services on a common domain.
There was a good long while where IP addresses were still unutilized enough that there was no reason to even try being conservative.
Originally there also wasn’t any name-based virtual hosting, especially in SSL/TLS-based services like HTTPS so you needed one IP per name if you wanted to host multiple websites.
And part of the disappearance of www. now is probably that strange decision by Chrome to hide it.
Chromes decision actually makes a lot of sense, from a security perspective. When we model how people read URLs, they tend to be “lazy” and accept two URLs as equal if they’re similar enough. Removing or taking focus away from less critical parts makes users focus more on the part that matters and helps reduce phishing. It’s easier to miss problems with https://www.bankotamerica.com/login_new/existing/login_portal.asp?etc=etc&etc=etc than it is with bankotamerica, with the com in a subdued grey and the path and subdomain hidden until you click in the address bar.
It’s the same reason why they ended up moving away from the lock icon. Certs are easy to get now, and every piece that matches makes it more likely for a user to skip a warning sign.
Originally the idea was that you would have a domain and then have a host under that domain for each service (e.g. mail.example.net, ftp.example.net, www.example.net,…). Of course eventually the web was used by a lot more people this directly than any other service so the main domain was also configured to point at the web server and then people added a redirect either in one direction (add www.) or the other (remove www.) on the first request.
The final piece is that often each of those services would be on a different computer entirely, each with a different public IP address. Otherwise the port is sufficient to sperate most services on a common domain.
There was a good long while where IP addresses were still unutilized enough that there was no reason to even try being conservative.
Originally there also wasn’t any name-based virtual hosting, especially in SSL/TLS-based services like HTTPS so you needed one IP per name if you wanted to host multiple websites.
And part of the disappearance of www. now is probably that strange decision by Chrome to hide it.
Chromes decision actually makes a lot of sense, from a security perspective. When we model how people read URLs, they tend to be “lazy” and accept two URLs as equal if they’re similar enough. Removing or taking focus away from less critical parts makes users focus more on the part that matters and helps reduce phishing. It’s easier to miss problems with https://www.bankotamerica.com/login_new/existing/login_portal.asp?etc=etc&etc=etc than it is with bankotamerica, with the com in a subdued grey and the path and subdomain hidden until you click in the address bar.
It’s the same reason why they ended up moving away from the lock icon. Certs are easy to get now, and every piece that matches makes it more likely for a user to skip a warning sign.
Well also at one point www.domain.com may have actually been a single physical server. That hasn’t been true for sites of any size in a long time.
Yes that’s what the article said.
Yeah, but in many, many more words than necessary to be honest.