Okay, I was entertaining the author's position to a point, but I have to get off the train where they sing the praises of NPAPI.

Hey fam. I remember NPAPI. I wrote a very large NPAPI plugin.

The problem with NPAPI is that it lets people run arbitrary code as your browser. it was barely sandboxed. At best, it let any plugin do its level best to crash your browser session. At worst, it's a third-party binary blob you can't inspect running in the same thing you use to control your bank account.

NPAPI died for a good reason, and it has little to do with someone wanting to control your experience and everything to do with protecting you, the user, from bad actors. I think the author tips their hand a little too far here; the world they're envisioning is one where the elite hackers among us get to keep using the web and everyone else just gets owned by mechanisms they can't understand, and that's fine because it lets us be "wild" and "free" like we were in the nineties and early aughts again. Coupled with the author's downplaying of the security concerns in the XSLT lib, the author seems comfortable with the notion that security is less important than features, and I think there's a good reason that the major browser creators and maintainers disagree.

The author's dream, at the bottom, "a mesh of building blocks," is asking dozens upon dozens upon dozens of independent operators to put binary blobs in your browser outside the security sandbox. We stopped doing that for very, very good reasons.

▲

zzo38computer 3 hours ago | parent [-]

> put binary blobs in your browser outside the security sandbox

There are reasons to do this sometimes, but usually it would be better to put them inside of the security sandbox (if the security sandbox can be designed in a good way).

The user (or system administrator) could manually install and configure any native code extensions (without needing to recompile the entire browser), but sandboxed VM codes would also be available and would be used for most stuff, rather than the native code.

▲

shadowgovt 3 hours ago | parent [-]

We already have two infrastructures to do that: the JavaScript engine and wasm.

And, indeed, part of the deprecation of XSLT proposal involves, in essence, moving XSLT processing from the browser-native layer to wasm as a polyfill that a site author can opt into.

	▲	zzo38computer 2 hours ago \| parent [-]
		Yes, what I meant (one way to handle what the author proposed; possibly not exactly what they meant) is that many of these "building blocks" can be made from wasm (although I have some criticism of that too, nevertheless, it will do), and many will be included by default, and others would be set up by the user if desired. Native code extensions (e.g. .so files) would also be possible but is not needed for most things, and if you set up from the app store or from stuff specified by the document or server then only sandboxed VM codes would be possible and native codes would not be allowed in those circumstances.