[TeMPOraL]

> Requiring a few hoops - and it sounds like e.g. requiring a developer edition sounds like such a hoop - to ensure a likely misconfiguration was actually intentional and the user is capable of dealing with the consequences is not a bad idea.

Except when such hoops then start being used as evidence the user is an undesirable and should be kept away from various services. See e.g. many Android apps refusing to work on rooted phones.

I specifically don't like bucketing things like these under "development" label - "dev mode", "dev build", "dev edition", etc. - because it creates the idea that those "dev capabilities" are there to help developers with development, and should very much not be used for non-development things.

[emn13]

I share your concern here, but I can't see a resolution to that being allowing every bit of software to alter any and all user data and alter the execution of any other software a user is running. That's where we came from, and the number of untrustworthy dependencies is so large nowadays that this kind of approach is both unsafe, but even without malware it's also unreliable and unpredictable.

There _will_ be constraints on running programs altering other stuff. Sandboxes _will_ get even stricter. The benefits are so large that this trend will inevitably continue, and rightly so.

To protect the ability to tinker we'll need to instead talk about who gets to control those sandboxes, ultimately. How can we poke holes without allowing abuse by malware or creative (ab)use rendering the system pointless? How can we ensure the poked-holes exist by user choice, not at the behest of a tiny handful of software behemoths?

On a technical level, I don't think that arbitrary and surreptitious dll injection is a line in the sand worth defending. It's not a great abstraction; it's tech debt.

[TeMPOraL]

> On a technical level, I don't think that arbitrary and surreptitious dll injection is a line in the sand worth defending. It's not a great abstraction; it's tech debt.

I think giving DLL injections up isn't really solving anything. DLL injection isn't an accident of history - it's a solution to a specific problem. The problem won't disappear if you remove the solution.

The issue in question is that it's also broadly useful to allow software to be modified by third parties in arbitrary ways, without the involvement or cooperation of the software vendor. In fact, the security folks are a major users of this capability - that's how malware scanners work, that's how emergency hot-fixing is done, that's how compliance systems work - and moving towards more evil/dystopian use cases, this capability is needed by anti-cheat systems, DRM, and the modern digital surveillance economy.

All this means that, if you eliminate the current way to let third parties inject code into programs, you'll soon be forced to create the equivalent mechanism yourself. The sandboxes will get stricter to protect users from criminals, and then they'll have holes poked in them to accommodate legitimate actors, both good and bad. Problem is, going through the whole dance of making a sandbox and then making it leaky, is that it generates bloat. You end up roughly in the same place you started, just with an extra layer of abstraction on top.

(And, of course, all those abstraction layers have bugs in them, so the attack surface for criminals is getting larger in the process.)