The microcode is what implements the fix and each OS pushes out the latest microcode via online updates. So, even if you don't update the motherboard's BIOS, you'll still end up with the latest microcode after the OS boots, assuming the OS you're running is still receiving updates.
That was true during Spectre updates, but seems to no longer be the case. The mcupdate_GenuineIntel application extension is still there in Windows>system32 to update the running microcode, but HWinfo shows whatever pre stability microcode you have in the bios is still active. I'm guessing that a small portion of users have updated their bios to one of these newer microcodes. If anyone out there is curious as to what microcode they are running in Windows HWinfo shows it on the main screen.
Not having automatically updated microcodes changes the degradation narrative. In theory it should still be ongoing for un updated systems and have progressed at least twice as far by now. But that doesn't seem to be the case.
I have one of the voltage addressing microcodes (12b) in the motherboard I picked up for my daughters 4770k upgrade because the ebay refurb seller put it in there, and in my living room itx because APO wanted it, but it is easier to lower your voltage in BIOS than to redo settings if you tune ram like me. And that bios still was awful with voltage by default - I saw a 1.5v spike on a 13600k at stock which I lowered to less than 1.2v with a small OC - by fixing the broken LLC settings and applying an undervolt. My gaming pc is still on microcode 123.
Edit: Here's a screenshot as evidence: Although if one wanted to they could fake this. All they would have to do is have the mcu_gintel extension out of this folder, restart then put it back because it only works during startup, but anybody can verify they have the motherboard bios microcode and not the latest with a RPL they have access to. They just have to open HWinfo and look at their loaded microcode.
Have you ever visited an ad-heavy site without any form of ad blocking or elevated privacy protection enabled? It's not far-fetched. However, Firefox doesn't include the CPU temperature in its crash reports and I don't see any quote of anyone claiming a specific temperature being hit by the CPU.
Also, we have some Dell compact desktops at work, where the CPU fan is controlled by a temperature sensor that's external to the CPU, and the fan doesn't really start waking up until that sensor sees a fairly elevated temperature. I've observed that a heavy workload can easily cause the CPU to hit 100 C, before the Tau limit expires and the CPU drops down to its PL1 of 65W.
So, you should consider that a lot of these CPUs might be in systems that aren't built or configured as you would do.
I do normally have adblocking enabled, but I turned it off to check and opened up MSI AB to check because its detached monitoring stays on top and on my 13900kf I was getting 68w spikes opening Firefox and 32w spikes refreshing various Youtube/YT music pages and supposedly the crashes were happening on these which run at half of the power as the stable Firefox browser starts. With power consumption quickly returning to idle levels. So on any config other than bare socket, 100c seems highly unlikely and even with the same cooler as AMD, AMD is more likely to hit its thermal limit because 1 second spikes of 100w or less can't soak a normal cooler. In addition the problematic CPU mentioned, 14700k is very likely to have at least a midrange cooler.
Unless you are living in some Intel power consumption fantasyland, or unless your AMD CPU is running at thermal throttling temps all of the time, I don't see how one can think that 14700k chips normally hit 100c opening up a Youtube page in Firefox. Especially when one of the 2 he was talking to reported his 14700k was seeing max 50c in Firefox and he just let his likely 100c comment sit:
https://mas.to/@gabrielesvelto/114814117276254003 But I can see an anti Intel troll spreading this nonsense to get a rise out of Intel users which seems like a plausible case here. Either way, not a rational source on this matter.
An area more susceptible to heat issues imo is ram. With DDR5, on 4 DIMM slot motherboards, XMP is commonly not stable for anything higher than average speeds. Ram is also finicky about temperatures even in the range of 50c and that can be easily reached on uncooled ram running at typical XMP voltages. This problem is exacerbated by case temp. Uncooled ram sitting in a glass panel case with interior temps 10c higher than ambient temps can more easily hit higher temps when the ambient temps go up. How many 14700k owners will buy faster XMP ram and only enable XMP and not tune it for stability?
But as for some ignored details about this new report of widespread crashes in unlikely scenarios:
It is one guy Gabriele leading allegations/speculations.
Apparently these crashes are almost entirely on Firefox Nightly, an alpha/beta version of Firefox.
4 months ago the bug was removed from topcrash status.
2 months ago "Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical."
2 months ago it was noted: " There have been only two crashes with microcode 0x12c in the past two months" on a beta program version, so a lot just means more than 1 per month.
From:
https://bugzilla.mozilla.org/show_bug.cgi?id=1950764
S3 stands for :
https://firefox-source-docs.mozilla.org/bug-mgmt/guides/severity.html
The available numbers indicate reported crashes likely number in the tens per week, maybe if it has exploded then hundreds. And it isn't stated that it is one crash report per user so it could just be a few noobs with terrible running 14700k systems.
Where "Mozilla staff's tracking overwhelmed by Intel crash reports, team disables the function" comes from IDK, I have been looking. You are good at finding things, maybe it is somewhere obvious, but it looks like it the bot may have been disabled due to the S3 status being so low.
This might just be a baseless clickbait story.