[HN Gopher] New TLDs: Not Bad
       ___________________________________________________________________
        
       New TLDs: Not Bad
        
       Author : NavinF
       Score  : 88 points
       Date   : 2023-05-13 16:50 UTC (6 hours ago)
        
 (HTM) web link (textslashplain.com)
 (TXT) w3m dump (textslashplain.com)
        
       | weinzierl wrote:
       | _" but it is fair to say that .com files are rarely seen by users
       | any more; on Windows, .com has mostly been supplanted by .exe
       | except in some exotic situations."_
       | 
       | Now _" rarely"_, _" mostly"_ and _exotic situations "_ made me
       | curious. Is there any chance at all to get a *.com file running
       | on a any windows not older than two decades?
        
         | ericlaw wrote:
         | .com files still work fine on Windows; Visual Studio installs
         | devenv.com, for example (IIRC, it's there for a somewhat wacky
         | reason. See %PATHEXT%)
        
         | disconcision wrote:
         | out of curiosity i checked my relatively recent windows 10
         | installation. i see 102 files ending in .com; 13 if filtered to
         | unique files names. 12 in the windows folder, and 1 in a game
         | folder. most of the windows folder ones are in System32m
         | WinSXS, and SysWow64 subdirs, as well as some windows update
         | subfolders. so it looks like mostly for win32 compatibility. i
         | tried running system32/tree.com in powershell and it works fine
        
       | sam_goody wrote:
       | Apple finder mixes web results with local results.
       | 
       | Search for file.zip and if it doesn't find a local copy, it will
       | look for a similar result on the web.
       | 
       | If you clicked enter before looking (say, you had a typo but
       | meant another file), Safari happily opens the page. I believe
       | that if the page serves a zip, it downloads and unzips it in the
       | background.
       | 
       | This TLD sounds like a terrible idea for Mac security, at the
       | least.
       | 
       | mov and app is similar, but requires more configuration - and
       | .app by default will not run when downloaded, and .mov is harder
       | to exploit.
        
       | charcircuit wrote:
       | >However, what if I sent an email to my family saying, "hey,
       | check out VacationPhotos.zip" with a ZIP file of that name
       | attached to my email
       | 
       | Nothing was stopping people from doing that before.
       | hey, check out <a
       | href="https://example.com">VacationPhotos.zip</a>
        
         | Volundr wrote:
         | The concern here is that someone could say write something like
         | "look in assets.zip for our marketing assets." in an email,
         | repository, etc and a parser automatically turns that into a
         | link. The reader, trusting the source and seeing the link
         | reasonably assumes it's a link to said assets, and clicks it.
         | All a malicious actor needs to do is register assets.zip and
         | wait for people to make this (I'd argue soon to be common)
         | mistake.
         | 
         | The malicious actor doesn't need to be in the loop at all.
         | Similar to typosquatting.
        
         | sebzim4500 wrote:
         | Ok, now do that in a tweet.
        
           | zamadatix wrote:
           | Doesn't Twitter still have automatic forced link shortening
           | via their t.co service?
        
             | charcircuit wrote:
             | But it does show you the url in the tweet. But if you use
             | opengraph the image for your link is more prominent so I
             | bet not as many people look at the domain for it.
        
               | zamadatix wrote:
               | Ah that's right, up to some length for the display.
        
         | smileybarry wrote:
         | But that's _intentional_ malicious linking. Auto-hyperlinking
         | "VacationPhotos.zip" or even just "photos.zip" can mean
         | clicking into a malvertising page, or in some worse-designed
         | cases, your email program prefetching a malvertising page.
        
       | echelon wrote:
       | .horse is still the best TLD.
        
         | BeFlatXIII wrote:
         | Charlie.horse
        
         | pavlov wrote:
         | I have my (sadly inactive) blog on app.rodeo only because I
         | bought this domain a decade ago, and sunk cost fallacy dictates
         | I have to use it for something after so many years of paying
         | fees.
         | 
         | If a rich Texan rodeo entrepreneur showed up in my email inbox
         | wanting to buy this unique domain, I wouldn't say no. But I'd
         | ask for a pony.
        
           | CrampusDestrus wrote:
           | notmyfirst.rodeo
        
           | MrGilbert wrote:
           | app.rodeo sounds like the perfect name for a app review
           | site...
        
       | datavirtue wrote:
       | Parking needs nerfed.
        
         | chungy wrote:
         | While maintaining a free market, the course of action is to not
         | reward people that park domains. Don't pay the asking price,
         | just let them expire.
        
       | throwaway22032 wrote:
       | I don't understand the kerfuffle here at all.
       | 
       | If you have a file it's after a /. Usually it's after multiple
       | /'s.
        
       | flatline wrote:
       | "Normal humans" may not type these for personal use, but I do for
       | work all the time and it is a frequent source of confusion, even
       | if not an attack. It's not just .zip and .mov, but .txt, .js,
       | more.
        
       | chunk_waffle wrote:
       | I shipped an international package with USPS today and there was
       | an option to add an email. I used my email address with a .family
       | TLD.
       | 
       | They couldn't add the email, they said the system was telling
       | them it was an invalid email. Inaccurate email validation in the
       | wild... I suspect the system has a list of known TLDs and that
       | didn't exist when their system was created. Or even worse, they
       | have some hardcoded list of known email providers...
        
         | MrGilbert wrote:
         | When I was in charge to implement the email validation at my
         | previous employer, the only thing I did was checking for "."
         | and "@" in the correct order.
         | 
         | The sales-focused part of the company complained that they
         | would still receive invalid email-addresses for their
         | newsletter.
         | 
         | Turns out what they really wanted was an email address where
         | they could send stuff to. So we implemented a MX-check for the
         | host part of the email address. However, that check was mostly
         | a warning, in the sense of "Hey, are you sure the email you
         | entered is correct?".
        
         | rattlesnakedave wrote:
         | Judging by the amount of infosec dorks I've seen kvetching on
         | twitter over .zip, it's probably blocking less popular TLDs.
        
         | splix wrote:
         | Also, if some system accepts such a domain it sill likely it
         | gives it a red flag.
         | 
         | I'm using .email domain for a long time, in many cases it's not
         | accepted on registration. When it's accepted and it's an
         | e-commerce website then half the time I get an automated email
         | that the sale was either declined, or they require additional
         | proofs. Or, in some cases, the order just gets ignored, and
         | when you physically call them they can't even find the email in
         | their system, so my guess some anti-spam system just blocks it.
        
         | dehrmann wrote:
         | Emails can theoretically be sent to TLDs, right?
        
           | rattlesnakedave wrote:
           | Yes
        
         | shortcake27 wrote:
         | I own a .co domain. Frequently when entering my email address
         | the validator tries to correct me - "Did you mean .com?". No, I
         | meant the thing I entered.
         | 
         | The real problem is when I give my email address to someone
         | else and then they get corrected by their email client. For
         | some reason, people place implicit trust in these validators.
         | This results in emails getting sent to the wrong TLD.
         | 
         | .co was released in 1991, and it's easier than ever to launch a
         | TLD. Email validators need to stop validating TLDs. It doesn't
         | help anyone.
        
         | sixstringtheory wrote:
         | Or a regex with a \\.[a-z]{2,3} suffix. I've had similar
         | problems with my email at a newer TLD.
        
           | jasomill wrote:
           | Newer? My .at (est. 1988) email address is still occasionally
           | rejected for its "invalid" TLD.
        
             | jjeaff wrote:
             | Kind of surprising that a country (Austria) tld would not
             | be accepted.
        
           | pwdisswordfishc wrote:
           | This wouldn't even let in .info...
        
             | chrismorgan wrote:
             | I've been exclusively using email address(es) at my .info
             | domain for over twelve years now. To my recollection, I've
             | had issues due to the domain name exactly once, about two
             | years ago; in that case it was a website with a bad email
             | validation regex, and, being a web developer, I was able to
             | bypass it, and the backend accepted it.
             | 
             | Now I do recall noticing things that would baulk at _five_
             | -character TLDs once or twice more. (Actually-deployed
             | stuff, this is--if I counted example email address
             | validation regular expressions I've seen from Stack
             | Overflow and similar and "see how good/bad/otherwise this
             | LLM is", it'd be quite a few more.)
        
             | marcosdumay wrote:
             | Yes... You didn't make a point, so I'm guessing it's just
             | an observation.
             | 
             | Or, seriously, not supporting .info won't stop a lot of
             | people from adopting and keeping a system, not a lot of
             | developers from doing things this way.
        
               | jjeaff wrote:
               | You'd be surprised. Especially if you are building B2B
               | and users want to use their company emails. Blocking any
               | non-standard TLDs will create a customer service pain for
               | any reasonably large business.
        
           | wongarsu wrote:
           | Judging by the amount of problems I had with an email address
           | on a subdomain (@students.univerity.tld), it seem about 5% of
           | all registration forms use a regex similar to
           | .*@[a-z0-9]\\.[a-z]{2,4}
           | 
           | I wonder what the success-rate with unicode domains looks
           | like
        
             | paulryanrogers wrote:
             | This would lock out countries that use .co.uk and similar
        
         | alpaca128 wrote:
         | > Or even worse, they have some hardcoded list of known email
         | providers...
         | 
         | I still remember humblebundle rejecting my mailbox.org email as
         | invalid, I'm guessing because of that. They fixed it at some
         | point, fortunately.
        
         | davchana wrote:
         | The discover bank doesn't even accept an email at indian tld
         | like hello@example.in The reason given by support was that .in
         | email will work only in India & discover operates only in USA.
         | I tried to reason that people move from India to USA all the
         | time & keep the same email accounts.
        
       | OrvalWintermute wrote:
       | I don't know that the diagram is correct.
       | 
       | Where it indicates "scheme" - that is actually protocol to be
       | used.
        
         | omoikane wrote:
         | According to RFC 1738, that part is called "scheme".
         | 
         | https://www.rfc-editor.org/rfc/rfc1738
        
       | dehrmann wrote:
       | I can't tell if TLDs or emojois are trying harder to stay
       | relevant.
        
       | gkoberger wrote:
       | If "not bad, actually" is the best praise we can give these new
       | TLDs, then it still feels like the downsides far outweigh the
       | potential issues.
       | 
       | Google bought these TLDs. Google also owns Chrome. When you type
       | "something.zip" into the Chrome toolbar, it used to search for
       | it. Now it takes you to a URL. Is that the most widespread vector
       | for attack? Probably not. But at the very least, it's super
       | annoying for people searching for a certain file.
       | 
       | I'm yet to see a single compelling reason why they should exist;
       | the best defense has been "well yeah there's a ton of issues but
       | _maybe_ it's not as bad as we think".
        
         | classified wrote:
         | Google needs to enshitten their search so people spend more
         | time looking at ads.
        
         | waboremo wrote:
         | You never should have been able to type "something.zip" and go
         | to a zip. That was chrome being unnecessarily "ambitious" in
         | creating a shortcut when you should have always had to specify
         | "file:///" like every other browser.
        
         | Volundr wrote:
         | > Is that the most widespread vector for attack? Probably not.
         | 
         | Yeah one big issue I had with the article was the assertion
         | that telling people to open a file like VacationPhotos.zip
         | isn't something humans do. Is it common? Probably not, but
         | there are a LOT of humans. Even 1% of them doing something
         | makes for a huge attack surface. The vacation photos example is
         | also probably not a very good one. How many README.md files are
         | there out there telling someone to look in assets.zip for the
         | webserver assets, or docs.zip for documentation? Someone seeing
         | this is a link would likely reasonably assume it's a link to
         | the file in the repository, and I'm sure someone more creative
         | than me could get up to all sorts of interesting shenanigans
         | with that (incorrect) assumption.
        
           | hfkwer wrote:
           | [dead]
        
         | smoldesu wrote:
         | You just can't trust '.' separators to always mean something is
         | a file. I think most people have known that since the dotcom
         | era. It's annoying that Google owns them, but there's no
         | shortage of power inequalities in the domain registrar field.
         | It sounds to me like a minor roadbump that is exacerbated by
         | common misconceptions around FQDNs and MIME types.
        
       | motohagiography wrote:
       | The internet was designed around a very specific human readable
       | taxonomy of distinct objects, namely hosts, files, and users. We
       | technically could cause the host and file namespaces to collide
       | on purpose, but other than creating a market for products and
       | services that unknot the mess this makes, what makes it a good
       | idea? I think it's probably time to abandon the platform
       | dominated internet for new cryptographic protocols, as the
       | beneficiaries of this inconsistency are the intermediaries who
       | will charge you to manage the chaos and inconsistency they have
       | themselves created.
       | 
       | If you have to do file scanning in email or do any
       | security/governance work at all, TLDs that collide with filenames
       | look like a disaster. An example would be, given a string in a
       | file draft.temp.zip, does it refer to a local filename or a
       | domain? I'd even suggest muddying the namespace like this is a
       | kind of subversion of the internet, which was effectively a
       | social contract about consistency and end to end connectivity.
       | Breaking internet namespaces like this separates the user and
       | person from the network and makes them completely dependent on
       | mediation in the OS for reasoning about basic endpoints. If there
       | is no distinction between files on your machine and on platform
       | company machines, you are in a walled garden.
       | 
       | Adding well known file extensions as TLDs will add a fundamental
       | inconsistency that is just injecting chaos as a means to manage
       | it. Yes, MSFT always had .com files and the internet survived,
       | but that's an exception from a company that has never solved a
       | problem they hadn't first caused.
        
       | d--b wrote:
       | It may not be that terrible security-wise, but it's just plain
       | stupid to add .zip and .mov as tlds.
       | 
       | I mean WHY?! Why the fuck do we need more tlds? And even if we
       | needed new tlds, in the billions of possible choices, why would
       | you choose something that confusing?!
        
         | toast0 wrote:
         | where else was I supposed to put this? https://badday.mov/
        
         | sillysaurusx wrote:
         | Money, honey. https://youtu.be/7HxXFi2IGoc
        
           | em-bee wrote:
           | reading your comment i first thought of a different song:
           | https://www.youtube.com/watch?v=ETxmCCsMoD0
        
           | Animats wrote:
           | Right. Network Solutions keeps gifting me with unwanted
           | domains in strange TLDs. Then they add "privacy protection"
           | and other unwanted services for which they try to bill. I
           | have to transfer those domains to another registrar to stop
           | that.
        
         | rattlesnakedave wrote:
         | .zip is not an inherent security risk.
        
       | teddyh wrote:
       | This only strengthens the argument _against_ overmatching
       | autolinkers. The URL RFCs recommend using less-than and greater-
       | than characters to denote URLs in text, like so:
       | <https://www.example.com/>. I welcome a return to this practice.
        
       | mike503 wrote:
       | I'm just waiting for clownpenis.fart or horsedick.mpeg, anything
       | else is irrelevant.
        
       | crazygringo wrote:
       | I just think it's annoying that if I see a reference to "foo.zip"
       | or "foo.mov" it's not immediately clear anymore whether it's a
       | file or a domain.
       | 
       | The fact that file extensions and TLD's were roughly the same
       | length in the same format wasn't a big issue, when it's generally
       | understood that ".com" and ".edu" are domains, while ".jpg" and
       | ".mp4" are files. (And as the author states ".com" files are
       | rarely seen by users anymore.)
       | 
       | But if the .zip TLD takes off, it's just adding a little bit more
       | cognitive load. Sure, hopefully it's usually clear whether
       | somebody's discussing a filename or a domain name from context.
       | But not always, and that's annoying and anti-user. Conventions
       | have value, and this decreases that value.
       | 
       | So really, it's just like... of all the possible TLD's, is there
       | really any benefit to picking ones that are also common filename
       | extensions? Is our economy really going to suffer if we say, hey
       | let's _not_ make things like .txt and .doc into domains as well?
       | There are _tons_ of other TLD 's we can create instead.
        
         | ithkuil wrote:
         | Fwiw once upon a time .com was the file extension that predates
         | .exe
        
         | mc32 wrote:
         | Yeah I think there is potential for confusion given users have
         | been warned for years not to download zipped files as they
         | could harbor malicious payloads, now they have to think is it a
         | link to a file or a tld?
        
         | schwartzworld wrote:
         | > when it's generally understood that ".com" and ".edu" are
         | domains
         | 
         | .com is also a file extension. It describes an executable
         | format that predates the web.
        
         | yakubin wrote:
         | It's not a new problem. The Polish TLD is ".pl", which is also
         | the file extension of Perl scripts. We get by just fine with
         | that.
        
           | comex wrote:
           | And .sh (shell script or Saint Helena), and .rs (Rust source
           | file or Republic of Serbia). The latter in particular is
           | quite popular for Rust-related websites.
        
             | hfkwer wrote:
             | Or Moldova's .md, Anguila's .ai, Cocos Islands' .cc,
             | Palestine's .ps, Paraguay's .py, Somalia's .so... The list
             | goes on. Filename extensions have always been confusable
             | with TLDs. And yet we've somehow coped for decades.
        
               | paulddraper wrote:
               | Ah yes the infamous Cocos Islands TLD/file extension
               | conflict.
        
             | franga2000 wrote:
             | These, as well as the ones cited in the next comment down,
             | are all file extensions only developers or perhaps power
             | users would know. But .zip is a very mainstream file
             | extension, perhaps one of the most mainstream ones besides
             | the media ones (mp3, mp4, jpg, png, gif) and .exe.
        
         | mcv wrote:
         | Completely agreed. It might not be an immediate disaster, but
         | it adds cognitive load. And for what benefit exactly? What's
         | the use in having these TLDs?
        
         | toomim wrote:
         | So if it's a domain, you should fully qualify it:
         | https://foo.zip.
         | 
         | Over time, this can become a convention. Part of the price you
         | pay in using a .zip domain will be that software doesn't auto-
         | linkify it unless you prefix it with http(s)://.
        
           | None4U wrote:
           | But domains and protocols are orthogonal?
        
           | simlevesque wrote:
           | The domain has no relation to the protocol. I can own domains
           | and never use http or https on them.
        
             | CydeWeys wrote:
             | Right but if you're not hosting Web content then you
             | wouldn't _want_ it linkified in a Web context. If you 're
             | using it for something else, e.g. SMTP, then you'd
             | represent the domain name differently as
             | username@your.domain
        
           | mike503 wrote:
           | And with chrome leading it (IIRC) and other browsers
           | following, end users don't even see http or https:// prefixes
           | in their browser bar anymore. Further adding to confusion.
           | 
           | I don't see a reason for adding these new TLDs other than a
           | cash grab.
        
             | em-bee wrote:
             | hiding the protocol prefixes was always a bad idea. the
             | .zip domain would be an argument to revert that. but i
             | don't have high hopes.
        
           | dubcee349 wrote:
           | W W W PERIOD FOO PERIOD ZIP
        
         | awesome_dude wrote:
         | I'm sure that bagder (https://twitter.com/bagder) tweeted about
         | this, but I cannot find the tweet (either I'm losing it, bagder
         | deleted it, or twitter's search is broken)
         | 
         | At any rate, `.com` is a (windows) file extension and we've not
         | been too fussed about that as a TLD for the last 40 years.
        
         | waboremo wrote:
         | This solution only works if you believe no filename extensions
         | will ever be created (or popularized) from here on out.
         | 
         | So, instead of hoping for that, why not search for solutions
         | that actually will stand the test of time and aren't as fragile
         | as "freeze the filename extensions!"
         | 
         | Also one of the really funny parts of this entire debate is the
         | focus on filenames when most average people aren't even aware
         | of their existence. Windows and Mac have hidden them _by
         | default_ for years now. It 's only an image if it shows the
         | image thumbnail, it's only a folder if it shows the folder
         | icon, and so on. I bring this up because it shows how fragile
         | this solution is. You can't get people to adhere to the rule of
         | looking out for ".zip" if they don't even know it exists!
        
           | thomasahle wrote:
           | > This solution only works if you believe no filename
           | extensions will ever be created (or popularized) from here on
           | out.
           | 
           | It works if you just don't believe a filename extension like
           | .com or .net will be popular in the future. Personally I
           | don't think they will, as people rightly find it annoying if
           | the clash with TLDs.
        
             | schwartzworld wrote:
             | Would you settle for it being popular in the past?
             | https://en.m.wikipedia.org/wiki/COM_file
        
             | hfkwer wrote:
             | [dead]
        
             | waboremo wrote:
             | Not much of a solution if it requires hoping something
             | doesn't become popular in the future. That's more like a
             | hot potato you've just passed on.
        
         | noizejoy wrote:
         | In response to the new TLDs I've made www. the official primary
         | part of most of my websites.
         | 
         | www.example.com would be the primary, and example.com redirects
         | to www.example.com
         | 
         | It's my simple approach to overcome the cognitive overload
         | issue.
        
           | dingusdew wrote:
           | We've done a full reversal and instead of dropping the www
           | because its a given, now we're having to bring it back
           | because it's not a given.
        
             | IceWreck wrote:
             | Even if its not a given just set it www.yourdomain.tld to
             | redirect to yourdomain.tld
        
       | burglins wrote:
       | > There are now 40 such TLDs: android, app, bank, chrome, dev,
       | foo, gle, gmail, google, hangout, insurance, meet, page, play,
       | search, youtube, esq, fly, eat, nexus, ing, meme, phd, prof, boo,
       | dad, day, channel, hotmail, mov, zip, windows, skype, azure,
       | office, bing, xbox, microsoft
       | 
       | Interesting how Google and M$ added their own TLDs (and a fairly
       | large amount of them).
       | 
       | (Edit: .meme and .dad are also google, so it's all forgiven)
        
         | CydeWeys wrote:
         | We announced we were doing this way back in 2017 and have stuck
         | to it. It's just surprising that so few others have joined us.
         | 
         | https://security.googleblog.com/2017/09/broadening-hsts-to-s...
        
           | bullen wrote:
           | Can you stop redirecting http to https if there is nothing on
           | port 443 please.
           | 
           | Also zip does not execute.
        
             | CydeWeys wrote:
             | http is insecure and should not be used. Not always using
             | https would defeat the entire purpose of the added
             | security, not least because a MitM attacker could block
             | only the https packets and then force a silent downgrade to
             | insecure http. It needs to always be https, never anything
             | else.
        
               | jackweirdy wrote:
               | I know this is good for the internet, but not all HTTP is
               | the internet.
               | 
               | I have to upload TLS certificates to a printer. A
               | printer!
               | 
               | The printer doesn't even have a sensible tls algorithms,
               | because its firmware was written at least a decade ago.
               | And the likelihood of someone, anyone, MITMing my printer
               | is 0
        
       | russellbeattie wrote:
       | The horse is already out of the barn on this one, but .zip really
       | is a moronic TLD and I'm surprised it was inflicted on us.
       | 
       | Pedantically it shouldn't matter, but in practice it seems like a
       | real headache. We can all think of common usage and edge cases
       | where it could lead to real issues, from automatic link detection
       | to malware spread.
       | 
       | At this point all we can do is shake our heads at the stupidity
       | and prepare ourselves for the worst.
        
       | xg15 wrote:
       | The arguments in that blog feel very much like a Google press
       | release.
       | 
       | The main argument against domain confusion is basically that the
       | author doesn't personally see it as an issue, underlined with a
       | bunch of strawman arguments of things that could theoretically
       | appear in urls but never do in practice.
       | 
       | But none of that matters, because thanks to forced HSTS, there
       | will surely never ever be a malicious domain on those new TLDs.
       | This is because, though the new domains may make security harder
       | for users, forced HSTS makes security easier for certain other
       | parties which are not users. So users just have to rely on the
       | smooth operation of those theoretical other parties and
       | everything will work out.
        
         | tptacek wrote:
         | This is not a Google press release.
        
           | xg15 wrote:
           | Which is why I wrote "feels very much like" one.
           | 
           | But sorry, I did think the author was a Googler, but
           | apparently he works at Microsoft instead.
        
             | tptacek wrote:
             | The guidelines ask us not to write things like that,
             | because they lead to really bad threads.
        
               | xg15 wrote:
               | On second read, that was a bit much sarcasm. Apologies.
        
       | silisili wrote:
       | I wish more TLDs did what travel, tel, and US did(or tried to do,
       | in the latter's case).
       | 
       | Travel vetted each applicant, so you'd know that you were
       | probably not visiting a scam site.
       | 
       | Tel was a little different, and more of a registry, but
       | again...not malicious.
       | 
       | Us was more standard, only requiring that you be a US resident to
       | register. But because it was a govt contract, any whisper of a
       | domain being used maliciously was met with an audit that would
       | shut it down if you couldn't provide a passport. It wasn't
       | perfect, but better than nothing.
       | 
       | It would be nice if more TLDs audited registrants or restricted
       | registrations in some way. A TLD that gains trust is more likely
       | to gain adoption, IMO, even if it is a gTLD.
       | 
       | Instead, it seems to be a giant money grab from all parties
       | involved, which has greatly hurt both trust and adoption.
        
         | thomc wrote:
         | This was attempted with the .trust TLD but did not catch on.
        
       ___________________________________________________________________
       (page generated 2023-05-13 23:01 UTC)