Het is een gevolg van het verkeerde gebruik van domeinnamen. In DNS was oorspronkelijk het idee dat een bedrijf een domein zou aanvragen bijvoorbeeld bedrijfsnaam.com en dat dan de diverse diensten die dat bedrijf aanbiedt met sub domeinnamen zouden worden onderscheiden, dus bijvoorbeeld www.bedrijfsnaam.com voor de website.
DNS bood zelf namelijk geen ondersteuning voor aparte informatie per service, bijvoorbeeld "WWW" records naast "A"
records die dan het adres van de webserver zouden retourneren en die door browsers worden opgevraagd.
Er is later nog wel een poging gedaan met de SRV records, maar toen was het al te laat en niemand gebruikt dat voor
webservers. En omdat niemand dat gebruikt supporten browsers het ook niet (zou weer extra tijd kosten om eerst een
SRV record te proberen op te vragen en als dat er niet is dan toch maar een A record).

Wat er echter in plaats hiervan veranderd is: bedrijven vragen niet zoals bedoeld 1 domein aan, nee voor ieder project
en voor ieder speciaal doel vragen ze gewoon een nieuw domein aan. Vaak hebben die projecten helemaal niets anders
dan een webserver en misschien mail. Voor mail is er WEL een speciaal record (MX) dus die twee kunnen naast elkaar
bestaan op hetzelfde domein. Daarmee wordt www dan min of meer overbodig. Je ziet dus ook wel dat er juist een
redirect is van www.bedrijfsnaam.com naar bedrijfsnaam.com.

Het is wel jammer dat het zo gegaan is want het heeft de herkenbaarheid van bedrijven op internet aangetast, en heeft
daarmee gevolgen voor de veiligheid. Als je nu een domein "uw-nieuwe-pas-bij-ing.nl" tegenkomt gaan niet meteen
de wenkbrauwen omhoog en ga je niet denken "is die site wel van ING?? is geen ing.nl of sub.ing.nl naam!!" want
iedereen gebruikt die domme namen. En er is nergens een registry (automatisch en in bulk opvraagbaar) waarmee
je zelf of je browser even kan checken of dat wel goed zit. Dat behoeft zeker verbetering want dit dwaalspoor gaan we
niet meer verlaten.

Het is nooit meer dan een conventie geweest om "www." voor het domein te zetten voor websites. Het sloot aan bij een patroon dat al voor andere services werd gebruikt, zoals "smtp." en "pop." of "mail." voor mailservers, "ftp." voor ftp-servers etc.

Het idee is dat je mogelijk verschillende computers op verschillende IP-adressen inzet voor die verschillende services, en dan is het beheersmatig wel zo makkelijk om die ook allemaal een eigen subdomein te geven (die naar hetzelfde IP-adres mogen verwijzen)- want dan kan je services samenvoegen op een machine of juist uitsplitsen naar verschillende machines zonder dat gebruikers hun instellingen moeten veranderen.

Toen "www." voor websites de conventie werd was nog niet evident hoe dominant het web zou worden in vergelijking met andere services. Tegenwoordig gebruiken de meeste mensen webmail in plaats van zelf met de achterliggende mailservers te praten, stel jij je vraag op een website in plaats van op usenet, ga zo maar door. Door die dominantie van het web is het veel vanzelfsprekender geworden om http[s] zonder subdomein op het domein van een organisatie te zetten dan het dertig jaar geleden was. Dat lijkt mij de reden dat je steeds meer websites zonder "www." ervoor ziet. En het zijn er niet een paar. Als ik in mijn browsegeschiedenis kijk is daar ruwweg de helft van de websites met en de helft zonder "www.".

Ik zie dus wel degelijk een ontwikkeling om "www." te laten vallen. Maar het is geen verplichting, het is niet meer dan een conventie, als jij een website opzet staat het je vrij om daar je eigen keuzes in te maken.

Mijn persoonlijke voorkeur is om "www." te laten vallen. Niet omdat het een trend is maar omdat je website sowieso je visitekaartje zal zijn, en omdat "www." extra typewerk oplevert en visuele ruis in je adresbalk en in je browse-historie. Doe wel een redirect van "www." naar het domein zonder voor mensen die het uit gewoonte altijd intypen.

Ik geloof niet dat je gelijk hebt dat HSTS bepaalt hoe die redirects werken. Het is prima mogelijk om in een keer een redirect naar de eindbestemming te geven. Een HSTS-header wordt door de browser genegeerd als die in een http-response staat. Als een browser eenmaal via https een geldige HSTS-header heeft ontvangen zal die voortaan voor dat domein http zelf naar https omzetten nog voordat er een request wordt gedaan. Dat is geen redirect, je browser handelt het intern af; het levert dus geen extra netwerkverkeer op.

Voor zover ik weet, de www. subdomein werd vroeger gebruikt om je website te kunnen scheiden van andere diensten.
Tegenwoordig is dat niet meer nodig, of word dat op een andere manier opgelost.

Als je een nieuwe website maakt, kan je de www. gewoon weglaten zonder gevolgen.
Sterker nog, er zijn al websites die de www. automatisch eraf halen. ( https://www.nos.nl/ )
Maar als je een bestaande website hebt, vergeet dan niet de een naar de ander door te verwijzen.

Volgens mij kan je trouwens gewoon van http://www.example.com direct naar https://example.com verwijzen.

Voor alle duidelijkheid: dat laatste is wel mogelijk, maar onverstandig (omdat dit de voordelen van HSTS voor bezoekers teniet doet). Ik heb het e.e.a. geprobeerd uit te leggen in o.a. https://www.security.nl/posting/802243/Steekproef%3A+overheid+%2B+HSTS.

Er zijn een stel niet altijd duidelijke afwegingen die je moet maken, vooral bij grotere organisaties. Denk maar aan google.com, met subdomein sites.google.com waar user-content op staat. Als er de een of andere "policy" bestaat die wordt ingesteld voor google.com, die automatisch geldt voor subdomeinen, kan dat ongewenste gevolgen hebben.

Eén voorbeeld is "includeSubdomains" bij HSTS. Indien je jouw website op example.nl wilt zetten, en je daar HSTS met "includeSubdomains" voor configureert, kun je geen "legacy" toepassingen (zoals http://intranet.example.nl) meer gebruiken. Maar ook bij andere headers en content kan "naar beneden" (van een domeinnaam naar een subdomeinnaam) anders werken dan "omhoog".

Onthoud dat een publieke domeinnaam (in het publieke DNS geregistreerd) een krachtig iets is omdat deze -noodzakelijkerwijs- wereldwijd uniek is. Precies daarom kun je er bijvoorbeeld publiek erkende https (en andere TLS-) servercertificaten voor kopen.

M.b.t. jouw website: als je bijvoorbeeld internen iets anders (dan externen) wilt laten zien als zij "naar example.nl gaan" (in de adresbalk van hun browser example.nl invoeren en op Enter drukken), kan het verstandig zijn om van example.nl een jumpsite te maken: internen stuur je door naar bijvoorbeeld https://intranet.example.nl en externen naar https://www.example.nl. Desgewenst kunnen internen dan ook https://www.example.nl openen.

Nb. Iedereen kan een interne server SRV01 of srv01.local noemen (waar je geen publiekelijk erkend certificaat voor kunt krijgen). Eveneens kan iedereen een eigen CA (Certificate Authority) en DNS server realiseren en een server intranet.example.nl met intern erkend certificaat optuigen - maar die zou, buiten hun netwerk, niet bereikbaar moeten zijn (zelfs een interne website met de letterlijke naam https://example.nl of https://security.nl is mogelijk, maar ook die hoort extern niet vanaf internet bereikbaar te zijn, en mocht dat toch zo zijn, krijgt een bezoeker een foutmelding - indien voor zijn/haar browser niet het rootcertificaat van de interne CA is geïnstalleerd).

Omdat het aanvallers van Windows-omgevingen vaak lukt om beheertoegang tot (AD) domain controllers te verkrijgen en vervolgens certificaten uit te geven, zou je zelfs kunnen overwegen om geen eigen CA in te richten en alle interne servers (waar nodig) van publieke certificaten te voorzien (en de gangbare AD-beheertoegang op die servers te blokkeren - meer werk, minder risico's).

Kortom, je haalt je potentieel vanalles op de hals door de website van een Nederlandse organisatie genaamd "Example" te bouwen direct op example.nl in plaats van op www.example.nl; die laatste is meestal de veiligste keuze als je niet alles overziet en de toekomst niet kunt voorspellen.

En als je HSTS goed configureert (check je domein op https://internet.nl, zeer leerzaam!) krijgen bezoekers twee in plaats van één records in de HSTS database van hun browser, maar verder zie ik geen nadelen voor hen.

P.S. let er wel op dat alle klikbare links (vooral naar externe sites), in elk geval "onder water", met https:// beginnen (dit zou m.i. op z'n minst een PTOLU moeten zijn). Bijv. op https://inspiratie.uwv.nl kon ik met een paar klikken al 2 pagina's vinden met achter "Deel dit artikel" een "(in)" icoontje met daaronder een link die begint met http://www.linkedin.com/shareArticle?. Nergens voor nodig!

Tijdens testwerkzaamheden kan het vervelend zijn als je geen www. gebruikt.
Want example.nl kan anders reageren dan www.example.nl als je testserver op www-testserver.example.nl staat.
Immers: www. en www-testserver. zijn subdomeinen, example.nl niet.

Heel benieuwd of X (oude twitter) binnenkort nog problemen gaat ondervinden als ze geen www. gaan gebruiken, want browsers konden in ieder geval in het verleden slecht omgaan met domeinen die minder dan 3 tekens hadden (even uit het hoofd om te voorkomen dat iemand cookies kon zetten op landdomeinen zoals .co.uk)

Dat kan, maar als https://example.com geen HSTS header met includeSubdomains meestuurt, en de user de volgende keer weer http://www.example.com, opent, zal de browser opnieuw via http verbinden [*] (en is die verbinding dus kwetsbaar voor een MitM/AitM).

[*] Alternatief: https://example.com kan de browser vragen iets op te halen van https://www.example.com, bijv. een 1x1 pixel plaatje, mits https://www.example.com daarbij zelf ook een geldige HSTS header verstuurt. Daarna heeft de browser zowel van www.example.com als van example.com een HSTS record (want dat is het doel).

Er is een example.com en zelfs een .example TLD welke je kan gebruiken voor snel even lokaal testen van dingen.
Of je nu www. gebruikt of niet maakt daarbij niet zo veel uit volgens mij.

En wat Xwitter betreft, moderne browsers kunnen gewoon met korte domeinnamen omgaan.

Volgens mij moet je het niet groter maken dan dat het is, als je in DNS op een domein een ip adres op hety domein zelf zet (vb security.nl) dan gaat de webbrower naar dat adres, als je dus geen www ervoor intypt in de URL balk. Dit werkt volgens mij al >30 jaar zo en is geen ontwikkeling maar gewoon een technische mogelijkheid en zeker handig voor de luieriken die geen www in willen typen. Domeinen die dit niet hebben zijn dan alleen te bereiken als je www. intypt voor de domeinnaam, zodat het ip adres van dat A record "www" wordt opgevraagd.

De reden voor een www hostname binnen de W3 adressen is waarschijnlijk gewoon dat het altijd zo geweest is.

Zelfs voor HTTP had je Gopher adressen zoals: gopher://gopher.mijndomein.nl:70

Om onderscheid te maken tussen welke dienst je gebruikte (gopher is een alternatief voor http) stond dit nadrukkelijk in de hostname.

Maar het is niet verplicht. Het is alleen technisch memetisch wat netter.

Hetgeen dat dit niet mogelijk maakt, is dat de initiële http request bij het gebruik van HSTS (na een eerste bezoek) uberhaupt niet mogelijk is, die wordt door de browser al omgeleid naar https. "omdat van http naar https://www niet mogelijk is" klopt dus niet helemaal. De http request is door HSTS helemaal niet mogelijk. Als die wel mogelijk was, zou die ook naar https://www kunnen redirecten.