There is a dark pattern whereby websites maliciously use a JavaScript confirm() to deceive users into believing a “problem” has been detected by the browser. It’s often triggered using setTimeout(), so it does not appear to be in response to any action that would be attributed to the visited website (background and related).

This site demonstrates the assault if you have a sufficiently defensive browser:

https://www.repairwin.com/

Often I can get around it by doing torsocks lynx "$URL", but not this time. The website is also hostile toward text browsing users. This site is extra obnoxious because if you give no answer to the popup it enters an endless loop of reloading the page -- which likely hammers their server too (the morons).

The fix: I fetched the webpage using HTtrack. Then I was able to view the page in peace. But then I noticed my hard drive working hard non-stop. Ran top, and a “program” called file:// Content (literally) was hogging CPU, memory, and putting the hard drive to work. I killed the process, at which point the browser tab that was showing the webpage as a local file crashed.

So while HTtrack at least got me access to the page, I was forced to hurry up and read the page and close it because of how hard my system had to work just to display some text. Perhaps the local copy needs to be viewed this way: firejail --net=none firefox file://$myindex/. Or maybe I should run wkhtmltopdf on the local copy and then just read the PDF.