It's really disturbing how many would be indistinguishable (to almost everyone) from malware servers. Lots of .net domains and entities I've never heard of.
A non-technical person's computer is often a source of agitation for a wide variety of reasons. Sometimes those reasons are reasonable. Sometimes they are not.
I don't think we're doing ourselves any favors by speculating what Aunt Tilly might think of a long list of human-unfriendly domain names.
> It's pretty common practice for a .com to run its backend stuff on the .net version of their .com domain.
Meaning the .com is basically just the UI that sends all its information to the .net to be processed, then back to the .com to be rendered? What's the benefit of that to the company, instead of having it all on the .com site?
I can't tell you why you'd want to have a front office/back office split like that, but I could speculate: Domains are cheap, and it might reduce cognitive overhead to have a .com/.net operational split.
Part of it is removing extra data when requesting style sheets and such - there's no need for a browser to send all of the set cookies it has for your web application when it's fetching styles, so people buy separate domains for them.
The problem is you can't explicitly tell a browser to fetch a cookie from cookie.example.com - and when you have multiple subdomains which rely on the cookie, plus analytics software which sets it for the whole domain, you can't do that.
Sort of: If you only ever need a cookie set on app.example.com, you can do that and use assets.example.com. It'll work for simple applications and not much else.
Things like Google Analytics also set cookies by default on *.example.com so you'll have to figure out a way around that.
