The whole issue of trusting other peoples code does have a solution besides just not running it: capability based code execution ("Capability-based security" if you want to look it up)
Processes can forfeit the permission to do certain things. similarily you could allow functions to forfeit the permission to call certain functions down the callstack (transitively, even) or only allow a function to be called from certain contexts/functions.
While certainly a (minor) performance hit when done dynamically, it should be possible,
especially when using an interpreted language. I have not yet seen this done in the context of programming languages, which is probably due to how difficult it would be to set a proper scope and get it right. If A is forbidden from deleting files, for example, but the program allows it to send messages to B (perhaps even by user choice), which is allowed to do so, then that is a natural escape hatch unless B is specifically designed to take this into account. Nonetheless, a hybrid system should be possible to achive, which would at least improve the situation by a non-negligible margin.
In the spirit of the original article: Most editor plugins don't need to interact with other processes or the file system directly, and instead could only affect an associated buffer. In this scenario, I believe that it is actually possible to solve this issue. For other applications, such as git integration, the mass of code that would have to be inspected can at least be reduced.
MacOS has lots of "capabilities" stuff now. It's constantly giving me anonymous prompts asking for some such privilege or not, without any explanation as to why it's necessary, what will or will not happen if I do/don't do it.
I just had the joy of kicking off a large crawl across my file system(s), expecting it to take some time, so I kicked it off just before I went to bed. This morning I arrived to a dialog "Terminal would like to access...", which naturally stalled my 3 command pipeline in its tracks, thus eliminating the primary benefit of doing the job overnight in the first place.
The other day, I guess I installed Discord, or updated it, or something. Anyway, Discord was asking for keystrokes from other apps. "Why!?"
Why does my IDE need root access to install?
What happens if I don't let random program crawl my network?
As a carbon based user, "capabilities" are a pain in the neck.
Windows lost this battle decades ago, when every. single. new program required "admin" privs to be installed. Every single one. Heck, I bet Calculator asked for it. To wit we numb users, wanting to just "use the software" said, "yes. Yes. YES! PLEASE MAKE IT STOP!" to the point where you just gave it no second glance at all.
Capabilities look great on paper. They're fine for things like systemd and daemons and "stuff administrator folks" install.
Wouldn't it be sufficient to "just" write a kind of context manager that watches the macro expansion and then looks at each step what's being done and divvies that up into safe and unsafe execution, so that at least the example of the article
doesn't just automatically run? Obviously it's a lot of work depending on how sophisticated you want that to be but you probably don't need to rearchitect much.
For folks that have never poked around in emacs, the specific difficulty will be that the odds are very high that if you are in an emacs lisp file, you are almost certainly going to want to edit what emacs itself is doing.
I'm specifically talking about scenarios such as "you set debug-on-error."
To that end, the proposal would probably be something like "flymake/flycheck" use a child emacs process to query the code, but the user evaluating the code would still be done in the main emacs?
I feel like capability systems are... the right solution to the right problem at the wrong time.
By that I mean, in an ideal world, nefarious code should never end up on my system in the first place. Regardless of whether it gets ran, regardless if whether it is properly sandboxed to avoid damage. At the end of the day, I don't want bad code in my system at all.
"Easier said than done" is why I said "right solution, right problem, wrong time." But it comes at a cost. A rather extreme cost, in some cases. Walled garden app stores. Runtime overhead.
Development overhead. I'm not just a user, I'm also a developer, so these things end up being roadblocks I have to navigate. And I have to navigate them for no reason of my own. I am not trying to steal my users' data. But in a way, I am getting punished for the actions of others.
It's an editor issue then. "Back in the old days", people used to understand how to input ^A and ^B. Showing these characters is also only a mere addition in the character set.
Sure, there is inertia to change, but even rich text format is/was supported by windows.
Being unable to deal with this is a lazyness of the developer that spilled into the user being unable to deal with it.
This is nothing a user can't be trained on, and I'd argue it makes more sense than weird escaping sequences in the event you actually do want a ",".
P.S.: But then again, with proper editors the escaping issue vanishes - and no, I do not mean IDE's. Lots of people decided it was worth it to support rtf, I figure the decision to support 2 additional characters is way easier in a user friendly way.
If entries can be relations themselves it is not possible afaik. For example
User | Telephone Numbers
-----+------------------
A | 123, 456 <- not atomic; more than 1 number (i.e. a set)
B | 789
Now there are academic operators to convert to and from a purely relational system, but I don't think they are implemented/in the standard. I forgot what they are called, however.
In general you don't want a universal query language. Depending on the shape of the data you want different things to be easily expressible. You can, for example express queries on tree-shaped data with SQL (see xPath-Accelerator), but it is quite cumbersome and its meaning is lost to the reader. I.e.: It's fine when computer-generated, but there is too much noise for a human to read/write themselves.
I'd be glad to be proven wrong here, but as time has shown, there is no one size fits all for programming languages. The requirements for different applications just vary too much.
Any push-based service would be vulnerable to this, wouldn't it? The medium doesn't matter if somewhere in the chain someone stores the message (in public).
I want to take this opportunity to recommend the talk "NTFS isn't that bad"
(https://www.youtube.com/watch?v=qbKGw8MQ0i8).
NTFS prefers a different access pattern than most usual file systems.
I remember that a part of the talk was about speed-ups on Linux as well. So even if it doesn't sway your opinion it should enhance your perspective on how file systems work.
There exist algorithms that deal with state blow-up. In fact, these algorithms project any given DFA into an equivalent DFA of minimal size - guaranteeing a minimal automaton for the language that is accepted by it. In essence, you build equivalence classes between states with respect to possible paths they can take into other equivalence classes for further input.
State machines for LR-Grammars are vastly more complex in comparison to NFA automata, so for most (if not all) applications, a computer that can deal with LR-Grammars will be able to handle a NFA conversion with a subsequent minimization.
reply