[foobarbaz33]

> Sandboxing is used when the host is concerned about running programs that he doesn't trust.

Trust? Trusting criminals doesn't stop them from committing crime.

You may trust your emacs color theme author. Pretty colors from an innocent artist. You run the theme code without any sandboxing. Everything is going well. Then the author adds a keyloger, project code scrapper, and phone-home feature in his theme.

You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party.

Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent?

[dokyun]

Read my other reply in this tree.

> You update all your emacs packages automatically without any code review. Then you start getting emails from your companies security team asking why you uploaded sensitive projects to a 3rd party.

If you do not trust the author or maintainers of a random program and refuse to review any code updates before installing it, then you are a moron.

I think if there is a concern that people would upload malicious packages, then there would be a level of trust put into the repositories that accept and offer them to review submissions before accepting them. This is still imperfect, but it shifts some responsibility off of you.

> Wouldn't it make more sense to restirct color themes to color and font related tasks? Why should a color theme be allowed to scrape sensitive code from your disk and upload it to a 3rd party without your consent?

Why SHOULDN'T a color theme be allowed to scrape code from your disk? Maybe the color theme is sophisticated enough to want to do that, or talk to some network. Something like a seasonal color theme that responds to the local weather might have a lot of hack value; and that is precisely the point you are missing. Emacs is not about restricting what you can and can't do, because the designers of Emacs understand that restricting what the user is allowed to do ultimately hinders freedom and creativity. It is one of the very few platforms left that's still like that, and I believe it should stay that way. If people want to use an editor that's very safe and tells them what to do rather than vice versa, then they should probably consider VS Code, or something like it which DOES upload your data to a third party without your consent, because it is smarter and knows better than you what you should be doing with your computer.

[foobarbaz33]

> If you do not trust...

Trust provides no protection.

> refuse to review any code updates before installing it, then you are a moron.

I personally do review every line of Emacs code I run. But I'd wager only a small handful of Emacs users do that.

> Why SHOULDN'T a color theme be allowed to scrape code from your disk?

Security.

> precisely the point you are missing.

Not missing it. nabla9's suggested security measures for extensions. You then asked why security is a concern. You seemed to imply there wasn't any reason for limiting extensions if you trust the author. That's simply not true, as you can easily be sabotaged by the most trusted color theme author.

[dokyun]

> You seemed to imply there wasn't any reason for limiting extensions if you trust the author.

That may be implied but the precedent is not important. The bigger consequent point I am trying to make is that there is no good reason for limiting extensions at all, and my reasoning for that will follow.

> you can easily be sabotaged by the most trusted color theme author.

Okay. Let's say that we solved the hypothetical issue of colour theme authors sabotaging their themes by requiring color themes to use a format that can't evaluate arbitrary code, only dictate UI options.

Now what about all of the other packages that aren't color themes, that do more useful things and require greater breadth of functionality? I am not trying to separate things into functional and non-functional, as it is futile to do so--there are an infinite number of separations between the degrees of utility packages have, and once you have "solved" the issue of their insecurity by restricting one class of them, there are always more. And every time you do this you only degrade the freedom and extensibility of the entire system; you do not gain anything by it, you only lose.

This phenomena can be explained because it's really an application of Gödel's Incompleteness Theorem. For any program running on any computer, it will always be possible to induce conditions that the program was never designed to handle. Thus it is my belief that the entire field of computer security is really a joke, and anyone who sacrifices freedom for safety ultimately ends up with neither.

In practical terms a bit of security is useful, however Emacs is not the kind of program that benefits from it. It is not useful to waste time reasoning about which methods of security should be applied to a text editor. If you were using Emacs to run an air traffic control system then this type of thinking might make sense, but not as a reasonable or common case.