Wouldn't this be a good case for a Safari content blocker / javascript blocker that's selective?
Ghostery might be a good place to start on the Mac to see if you can use pre-built rules to quash cross-site scripting / ad injection of code into web pages. Of course, if the page is serving up that content directly you'll need to disable javascript on that page entirely or take note and just block those sites that crap up your experience intentionally or due to selling off ad injection to anyone with the means to afford this scare ware and scam ware.
If you wanted to be more precise - GreaseMonkey type user scrips could combat this with enough JS knowledge on your part (or finding someone that wrote the script to block today's iteration of this malware).
Edited By @JBis
The following userscript was successfully in blocking the page.
// ==UserScript==
// @name The Bomb Squad
// @version 0.1
// @description Blocks the pages containing any function with the bomb_ch function detailed in https://apple.stackexchange.com/questions/329594/prevent-spam-downloads-on-safari and https://blog.malwarebytes.com/malwarebytes-news/2018/02/tech-support-scammers-find-new-way-jam-google-chrome/
// @author Josh Brown (@JBis https://apple.stackexchange.com/users/263848/jbis)
// @match *
// @grant none
// ==/UserScript==
if (typeof bomb_ch === "function") {
document.getElementsByTagName("body")[0].innerHTML="<h1>Page Defused by The Bomb Squad</h1><p>Because it contatained the following
function(s): <pre>bomb_ch()</pre> <br>";
}
Note: Sp(c)ammers can easily bypass this by randomizing the bomb_ch() function.
Newer OS versions of Safari might help cut this down a bit, but there's money to be made by people that deliver this load of crap to your Mac so they'll likely adapt to any technologies that try to make it easy to block. Unless you're willing to spend more money supporting a business that maintains a library of settings that can "whack-a-mole" and adapt faster than the charlatans can cook up new code in their boiler room.
You'll also have to decide if the web sites that do this are also charlatans that are part of the con since they should know this is happening to you, one of the visitors they host.
Found both old Coriolis iDefrag and Little Snitch 3 kexts present in the system. Uninstalled LS3 and deleted the iDefrag stuff which I had deleted the app for ages ago.
MBA now boots.
In more detail.
Checked the system reports in Console.app and found kernel panics by time. I'm no expert in reading trace files, but that this showed up caused some concern.
0xffffff80b4c1bfa0 : 0xffffff80213590ce
Kernel Extensions in backtrace:
com.coriolis-systems.driver.Snapshot(113.0)[B6C0FE6D-76C9-3C71-A43A-2D67ED604116]@0xffffff7fa1ffe000->0xffffff7fa2075fff
dependency: com.apple.iokit.IOStorageFamily(2.1)[499E27C9-AC4D-3239-9FC4-754C7699FA76]@0xffffff7fa1fce000
After doing a check to remind me what this was from I found it was an old installation of iDefrag from the pre-SSD days. Although I had removed iDefrag a long time ago when moving to SSD it seems the kexts did not cause an issue up to Mojave.
I checked to see what other items had been quarantined by the Mojave install process, going by what had been reported in the syslog I searched for The Coriolis kexts and found them in the following folder (the migration folder name has been anonymised here...)
$ cd /Library/SystemMigration/History/Migration-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/QuarantineRoot/Library/StagedExtensions/Library/Extensions
$ ls -l
total 0
drwxr-xr-x 3 root wheel 96 12 Jun 2014 ACS6x.kext
drwxr-xr-x 3 root wheel 96 27 Jun 2016 ATTOCelerityFC8.kext
drwxr-xr-x 3 root wheel 96 27 Jun 2016 ATTOExpressSASHBA2.kext
drwxr-xr-x 3 root wheel 96 27 Jun 2016 ATTOExpressSASRAID2.kext
drwxr-xr-x 3 root wheel 96 20 Aug 2013 ArcMSR.kext
drwxr-xr-x 3 root wheel 96 1 Sep 2013 CalDigitHDProDrv.kext
drwxr-xr-x 3 root wheel 96 11 Apr 2017 CoriolisOnlineHelper.kext
drwxr-xr-x 3 root wheel 96 11 Apr 2017 CoriolisSnapshot.kext
drwxr-xr-x 3 root wheel 96 15 Aug 2014 HighPointIOP.kext
drwxr-xr-x 3 root wheel 96 15 Aug 2014 HighPointRR.kext
drwxr-xr-x 3 root wheel 96 5 Dec 2017 LittleSnitch.kext
drwxr-xr-x 3 root wheel 96 31 Mar 2017 PromiseSTEX.kext
drwxr-xr-x 3 root wheel 96 22 Aug 2017 SoftRAID.kext
That the LittleSnitch.kext was also present here gave me the clue that Little Snitch 3 was possibly incompatible. After verifying this on the OBDev website I removed LS3 using the uninstaller https://www.obdev.at/support/index.html?product=LS&topic=faq&entry=245442241039726
Although kexts get quarantined it appears they are still present in the system somewhere, so the uninstall seemed the best approach. Indeed the LS3 uninstaller rebuilt boot caches.
The normal boot now succeeds.
Best Answer
The update process on macOS and iOS is very different.
Apple does not sign macOS installers/updates individually for each device. This means that there is no requirement that Apple "still signs" these updates for them to work and be installable.
This means that as long as you have an valid upgrade that at some point worked, it will always work in the future (you might have to set your computers clock back if the upgrade file is several years old though).
In general you should be very careful when downloading upgrades from a different source than Apple itself. Never install the upgrade without confirming that the file is identical to the original Apple file. This is commonly done by taking an MD5 checksum of the file, and comparing it to the known good checksum.
You can find the MD5 checksum of a file by running the following command in the Terminal:
where you replace "filename" with the actual name of the file, you want to checksum.
The md5 checksum looks something like this: ecfcaab9ad3d019ee982abdc84eff102 (just an example)