I don't want anything about the Internet to be like television, and while I know you're trying to make an analogous statement I think the real threats to freedom on the Internet are coming from entrenched interests who would take what you say literally.

I am being literal. The internet is not about freedom. It's about making money and influencing thought and action.

Realize that the majority (and I'm willing to say probably over 95%) of people today us the internet on their phone. They have a few "apps" which they switch through by swiping left or right (changing channels). The use Facebook, Amazon, their chosen politically aligned news site, Google search, and a few other things. Probably not much more than the 6 channels of TV I had as a kid.

And the Google searches are rarely if ever for anything beyond the first few links or the sponsored content. Really, page 2 and beyond might as well not exist. The users don't go there. Google could just return results from major organizations and users would be fine with it.

I lived through PC era, from start to finish. It took me a long time, but eventually I realized that 99% of the population was never going to understand how computers work. Just the concept of a file and a folder is beyond most people (that's why phones don't have them). Once I gave up on expecting people to learn about computers, computing became much easier. Phones, tablets, and so on, for the masses, the desktop for me. And now I didn't have to go fix peoples screwed up computers - they don't have them anymore.

The importance of a domain name, much less a sub-domain, is now irrelevant. A search result, of of the first few, is what matters. You will never get users to understand a URL.

At one time the internet might have been for us hackers, but that time has passed. It's now the domain of the masses.

How does hiding part of the domain make the web any easier to use?

if anything, it should be time to declare that its a bit insane to expect lay people to be able to read from right to left and left to right concurrently, and understand all the delimiting punctuation correctly, along with unicode. its time to restructure url rendering to be right to left, and combine delimiters. dashes, periods, slashes, and subdomains and hundreds of tlds have made it too confusing.

https://www.google.com./ should become either https/com/google/www/ OR secure/com/google/www/ OR secure.com.google.www. Browsers can then just always bold the third word?

I think re-ordering like that would actually benefit technical users more, but it's probably too late to make such a change. I don't think we'd need that change for browsers to put the parts they consider most relevant in bold. That logic is simple enough right now.

really we are talking about rendering, right? not actually changing the protocol itself? (:lock: = lock unicode/emoji = secure http)

:lock:/com/GOOGLE/www/maps/hawaii

I am a strong proponent of the URL being part of the user interface. I should be able to manipulate what i request of a service by modifying the url. The text in the url should mean something.

Making the rendering that different from the actual URL would be very confusing, especially if it varied from program to program or within programs. Links would look one way on websites and then have a completely different form in the url bar after clicking them.

That particular rendering choice would also have the downside of being the same for both https://www.google.com/maps/hawaii and https://google.com/www/maps/hawaii

Yeah you might have to double punctuate after the subdomain, BUT it still makes it clear what domain you are on.

https://com/google/www//maps/hawaii

And its not like the browser couldnt render it both ways, either on click or hover.

And how would the client distinguish the part that goes to DNS from the HTTP path?

double punctuation?

https://com/google/www//maps/hawaii

Why even bother with URL language? It should just be 'Google Search' in the bar and you can see the URL if you want.

I have many websites which I don't let Google to index, how would my users access them?

If you're not in Google's index, then it's likely you're not in Google's interest to use Google's product to visit your site, since the company prefers if you use their search rather than type links directly or follow links from other links, hence they want to kill the URL — https://www.wired.com/story/google-wants-to-kill-the-url/

What's your rationale for this? The removal of the superfluous www subdomain makes sense. It puts to actual unique site information immediately after the padlock.

Most sites either redirect to it away from www when you visit them anyways.

People have always said to host your site at www and redirect to it, something I have never understood nor heard a convincing argument for.

I have my servers configured to redirect visitors away from www.

I had some years I thought the same way, however:

From a DNS point of view: you can't have CNAME's on your root (can be useful, especially in some DNS load balancing situations, or load balancing on third party providers)

From HTTP point of view: A no-www domain might not be the best solution if you ever want a 'Cookie-free Domain' (static.) for images etc. which speeds up your site. If you start with a no-www domain you have to setup a different domain (no subdomain) for it: like sstatic.net for SO, ytimg.com for YT and yimg.com for Yahoo.

When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.

If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. https://developer.yahoo.com/performance/rules.html#cookie_fr...

in my view having a www record (and no-www redirect) has more benefits that a no-www

> People have always said to host your site at www and redirect to it, something I have never understood nor heard a convincing argument for.

It comes from the long-lost days when people actually ran their own servers, and would have [www,mail,ns1,ns2,intranet,chat].example.com servers. If you already have a lot of special-purpose domains, it seems weird to privilege "www" as the real example.com, so the recommendation was to redirect from it.

So we should have a limited control medium requiring extremely high levels of capital and regulation to provide content in a limited set of locations that can only be consumed by the user?

I suppose this change does get to this exact point since it obfuscates the page location so far as to be totally inaccurate, just as channel numbers obscure the frequencies and data transmission methods do on television.

I really don't know why you consider that a bad thing. It's a little bit silly that users have to know or care about what a domain/url is. Like if a user is just trying to get to, say, CNN, can they not just type in CNN and have the browser do the rest. Why put additional barriers?

Would we really design this system today?

We basically have the system you describe. I type CNN and the browser brings up a page of things that match my query. The first one is CNN. If I visit CNN a lot, my new tab page will have a thumbnail of the CNN website and I end up with an even simpler UI of just clicking a picture.

Because you need sufficient complexity to design a system where users can make things you dont bake into the system.

Would we have the web if we would design it today?