alt Hacker News>I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
I want to say "and especially prevent them from touching my private data (i.e. the whole point of Obsidian plugins being to read/write the documents)".
But if it can't talk to the internet, I kind of don't see the issue.
EDIT: Apparently due to how JS and Electron works, Obsidian plugins are just JS blobs that run in the global scope, and can read/write the whole filesystem (limited by user permissions) and make HTTP requests? Can someone confirm/deny this pls?
Replies
Theoretically in an Electron app, you could run plugins in a separate v8 context without the node native FS libraries available. Short of OS-level sandboxing that's probably the best they could do.
Confirmed: https://news.ycombinator.com/item?id=48088576
There is no sandboxing at all. Every plugin has full access to your computer.
> But if it can't talk to the internet, I kind of don't see the issue.
No internet access doesn't save you.
With file system access it can delete a file.
Without sudo access it can silently add something to your user's crontab so a few days from now it runs a custom shell script that does anything with internet access. If you're not checking into this sort of thing regularly, you wouldn't know.
It can add something to your user's shell's rc so when you open a new terminal session, a bad side effect happens.
Malware scanning won't protect from these sort of things and every time a new version is available, it's another opportunity for something bad to happen.
To be fair this isn't a problem unique to Obsidian. Code editor plugins and most programming language package managers have the same problem.