The Dangers of Microsoft Pluton

Agreed.

However, interesting conversations are missed because of noise (e.g. down-votes) - I'm less likely to interact with a down-voted post, they usually are not as informative or interesting.

Proposed solution - abolish negative points entirely, points should be per-thread, not per user. If a user is causing frequent problems (frequently downvoted), per admin review then issue ban/rate limits, etc.

I view the positive/negative points mostly as a sentiment rating - if I receive downvotes I can tell my point is unpopular/uncontroversial, if not I know someone found it interesting. That does affect how I post in two ways:

I make more effort to expose common context for posts which are down-voted, people who are lazy and don't care won't read the expanded post, people who are more open-minded (the ones I want to attract and start conversations with) are more likely to come around to my viewpoint, or at least offer more interesting conversation (disagreement is necessary to have a discussion).

So I find both positive and negative votes to be useful, even on my own posts. Even the manner in which I've been down-voted recently tells me something, and it tells me valuable data about who has which opinions.

That CPU is set up by the kernel at boot time, given the code to run, then some hardware bits are toggled such that the main CPU can't write later, it can only access the separate CPU via a defined API.

The kernel could do the same with an in-kernel process. It wouldn't have quite the same depth of defense against userspace sandbox escapes, but could be done. That's roughly how /dev/random was implemented for many years.

Look at the APIs provided — it's nothing new. It's nothing OSes haven't provided before, it's just further removed from a Chrome/FF/Safari sandbox escape, because overcoming the write-once hardware toggles is harder than getting kernel read/write primitives for a sandbox privilege escalation.