Downfall Attacks

HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line.

It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform.

I'd rather we go the other way, and build the browser into the OS, so that desktop apps just serve a perfectly standard web server, with an API to launch a special OS client with slightly more native integration(Toolbar icons, closing the process when the browser closes, etc), to make native app dev easier and hopefully more popular.

Security sandboxes mostly work. People aren't constantly getting viruses from clicking the wrong link, at least not quite as much. They're not perfect, but they're better than having to completely trust 100 different sites unsandboxed, and they can be improved. I'd rather have crappy security than no security at all.

That sounds awful. People would be jamming entire 10MB toolkits into WASM to do things that HTML could do, and performance would probably suffer.

HTML is declarative. The machine understands it. I like things machines can understand and optimize. Things that you can write automated tools to work with because it's not a full turing machine. If you want to make a screen reader, you can. If you want to reflow for mobile in a better way, you can, because you know what's text and what's an image.

Just giving people a programming environment and the ability to draw some pixels, the browser has no idea what the intent is. There's nothing to optimize unless the individual sites do, and I doubt they have Google and Mozilla's budget.

We already have too many unnecessary powerful imperative systems out there.

> Aren't system designers at fault for coming up with the idea of a context switch

Context switching was in the Apollo 11 guidance computer https://www.youtube.com/watch?v=xx7Lfh5SKUQ

The problem is that cycle-speed boosts left the industry cic. 2012-or-so. All the perf boost we get these days is by optimizing the instruction sequencing and multiprocessing. This is why languages like Go popped up (making the advanced programming topic of multiprogramming an entry-level accomplishment) and you now see the 'async' decorator plastered everywhere in C#, and so-on.

Keeping the security context intact and separated is a gargantuan task.

To me it makes more sense to add "lousy cores" to the die and force the operator to declare the launching threads are safe for SMT, else the job gets scheduled to the less-performing core where the pipelining is safer. It delegates responsibility to the chip-gobbler, forces them to understand the tradeoff for performance, until some elegant solution is found for side channel attacks like this.

This. Downfall affects CPUs released almost a decade ago. The argument of 'Intel caught a ton of these and downfall is the one that got away' doesn't add up. Surely Intel would find at least one issue during development of a new chip that has the property that it _also_ affects older chips. They can hardware-fix it before ever releasing their new chip, but unless they just decided to ignore the vulnerability in their older chips, they'd have starte work on a patch or at least on contacting OS vendors.

None of which is easy to do without the public at large figuring out what happend.

Conclusion: That is highly unlikely to have ever happened. Therefore, this isn't survivor bias and it really is bizarre that chip vendors (or, at least, Intel) doesn't look for this stuff or at least didn't find this.

Possibly. When I worked at a place that designed a "simple" chip that was just a more energy efficient and very parallel version of its FPGA, the fab that was contracted to make it insisted on validating it themselves. It consisted primarily of a lot of copy-paste of the primary logic to build as many paths as would fit on the die. They described it as "unusually dense" and, I heard they later said that they'd never seen a design that dense. The validation process was partly described as people manually driving a car through a 3D model, making sure there were no unexpected junctions or other divergences. This process took months longer than their initial estimate, allegedly due to the density.

I guess you could say this was "under the umbrella of the chip-maker", though we had little say in it aside from pressing them for progress as our final product's shipdates came and left. When we finally got the first samples, power consumption was, I think, an order of magnitude higher than expected. Our lead engineer struggled to get it down without going to a smaller process that we could barely afford (and given the delays already, could probably not have afforded to wait for). We thus thought we had working logic, but our case designs were scuttled. After enlarging the cases to accommodate extra cooling, our base unit was more than ten times taller, and our next size up, while the same height, was three times longer. Highest units had a water cooling system[1].

Our QA was able to find other sorts of flaws, like misprinted unpopulated circuit boards, software faults on the host, or when we received shoddy interlink cables that either melted under test[2] or other cables that scrambled communications[3].

All of which is to say, that many other pressing issues can interfere with doing what you feel you ought to be doing. At least at our scale. I can't speak for the likes of big guys like Intel or AMD, but it's possible that unfound faults or known unpatched flaws can ship because resources were committed elsewhere or fabrication leadtimes preclude waiting. This is not to say that shipping a security flaw is okay, but rather that sometimes you think you've done you're due diligence, or sometimes your choices seem to be "Ship, ship late, or never ship.". The answer you pick can be existential, so you hope you've picked the least bad option.

[1] Misbegotten, because "beauty of the promo images".

[2] Conductors much thinner than spec, not initially observed because both ends were fitted with moulded plugs.

[3] Longer than spec, initially recieved with enthusiasm by assembly staff, before an engineer investigating a difficulty saw them and exclaimed, "No-no-no! That's longer than I am tall! Stray capacitance alone will kill the communication.". (He uncharacteristic'ly exagerated here. While they were three times longer than expected, this was at most .40 times his height.)