I think everyone is down playing the severity of this issue. The T2 exploit, if proven, is persistent until a full reboot of the system occurs, not until the external hardware is removed.
Imagine the situation where you're sitting in a coffee shop using your computer, you get up to get something from the café. An attacker only needs 5 to 10 seconds with your machine to exploit it whilst you're not there looking at it, once they've done that, the entire machine has been compromised. When you return, entering your password for your account, a keylogger in the T2 can capture your password, and then later use it for FileVault and Keychain decryption, and because the network connection is also accessible to the T2 chip, they can then use this to exfiltrate any file, login credential, fingerprint data, or anything they're interested in off of your computer, via the internet, without a single sign that your machine has been tampered with. All this from 5-10 seconds of unmonitored access with your machine.
Sure, the machine can be uncompromised with a reboot, but how often do we actually shutdown or reboot our macOS-based machines, rather than just shutting the lid? Further, the T2 chip can continue to operate even whilst the lid is closed, potentially waking up the machine via ACPI commands, connecting to a WiFi network, and downloading further malware onto the machine, whilst you think it's asleep in your backpack.
What's worse is that this exploit, as alluded to in the article, is likely present in the boot ROM, an area that is burnt into the chip at the factory and cannot be modified. Think of it like the exploit of the NVIDIA Tegra X1 that caused the first batch of Nintendo Switch units to have a permanent "jailbreak" that couldn't be patched.
That just means the code in the chip can’t be changed. The original Mac had code in ROM and errors in that code were patched at runtime. We don’t know if this is patchable or not until Apple speaks.
The issue here, is that the T2 is the first thing to run in the entire system. It is literally the root of trust in any T2-based Mac devices. Once macOS has booted, it's too late. There is nothing they can do to mitigate the exploit in the operating system.
A fix was produced for those, but in reality the vast majority of affected computers are not fixed. Those exploits required a firmware update, which means every single PC vendor had to create an update to their custom firmware.
This is not true, at least for Windows and (most) Linux based operating systems. Both Spectre and Meltdown were patched via microcode updates, these are delivered directly from Intel themselves via Windows Update or packages from distribution repositories, and are applied directly to the CPU from there. They do not need vendor intervention to deploy these patches.
What vendors can do, however, is ship a patched version of microcode with their BIOS/firmware, so that even before Windows or Linux is installed and updated, the microcode in the CPU is patched. Like you said, this is up to each vendor to deploy, however the vast majority of users will have received the patched microcode via Windows update or other OS update methods.
So the bottom line is that those Intel exploits can still attack most computers with the vulnerability, and remotely, and simply by visiting a compromised website.
This is also only partially accurate these days. The original exploit relied on extremely precise timestamp resolution available via specific APIs in browsers, to do cache timing analysis. When the exploit was originally revealed, these APIs were patched by browser vendors to intentionally "knee cap" the available resolution of these timestamps to prevent their use for timing analysis, but still providing more than enough resolution for web developers needs.
For Meltdown and Spectre to be effective from "simply visiting a compromised website", you'd need to be running a browser version from before the era of these exploits
as well as running an unpatched CPU, Kernel and Operating System. Internet Explorer and Microsoft Edge do/did not expose an API for these high resolution timers, so are not affected, Chrome and Firefox both have aggressive update mechanisms, so most users will be on "patched" versions. I'm not aware if Safari exposed these high resolution timer APIs, but I suspect it has been patched also if it did.
