There’s something that the earlier discussions were missing, and the devs tried to explain but it didn’t seem to come across very clearly to some folks.
So I’ll try to break it down a bit and hopefully it will help others understand the issues here.
For reference, I work in cybersecurity, and although I don’t know the specifics of the inner workings of Electron and Node I do know enough to understand the nature of how these types of apps work and the ramifications of those architectures.
- Obsidian runs on Electron, which is an implementation of Node.js and Chromium on the desktop
- Normally javascript runs inside a browser which has a strict security model, often called a “sandbox” that prevents the JS from touching anything the browser does not expose
- browser-executing javascript cannot even see the file system so it cannot execute arbitrary commands against your files – this is by design inherent in the browser security model
- this seems to be the viewpoint adopted by some which appears to reflect a misunderstanding of the nature of Electron vs normal browser-based apps
- When “normal” apps run they are run with the security permissions of the user who runs them
- behind the scenes each process must run under a user ID, and for apps you open/execute they automatically run under your user ID – with your security permissions attached
- this is why running an app can mean the app has access to any file/folder that you have access to, because the app is effectively running “as you” while it executes
- mobile apps (in particular iOS) have altered how people understand security at the app & OS level, because iOS is specifically designed to create this “sandbox” effect by restricting what data an app can see centrally
- non-mobile OSes (e.g. Windows, Mac, Linux) are not designed that way and instead run each process in the process space and memory space of the user who runs them with that user’s security permissions
- Node.js is a javascript engine designed for direct execution at the OS level on Windows, Mac, and Linux OSes, and as such it does not run inside a browser or any other app “sandbox”
- it runs in the process space and memory space of the user who runs it and thus has access to everything that user has access to
- this means any Node.js app has full access to all of your files and data, anything you can open in your file browser or editor of choice and read/edit/delete, so can any Node.js app you open, because behind the scenes it is running “as you” with your permissions
- Since Electron runs on Node.js it also runs as that user in the process/memory space of the user who runs it, and thus has full access to everything that user has access to
- “Plugins” in an Electron ecosystem are simply javascript files that are loaded into the running Electron process, which again already has full access to everything the user running it has access to (and again, this was by design when OSes were designed decades ago)
- Since Obsidian runs on Electron then Obsidian plugins are also just javascript loaded into the same process space and memory space as the main Electron components, which again behind the scenes are running on Node.js which is itself running within the process/memory space of the user who runs it
Therefore, it isn’t feasible to restrict the plugins in the manner requested since any arbitrary javascript code by design can be injected into a running Electron process.
This is articulated by the Electron developers themselves. From a link originally posted by @rapatel0:
As web developers, we usually enjoy the strong security net of the browser - the risks associated with the code we write are relatively small. Our websites are granted limited powers in a sandbox, and we trust that our users enjoy a browser built by a large team of engineers that is able to quickly respond to newly discovered security threats.
When working with Electron, it is important to understand that Electron is not a web browser. It allows you to build feature-rich desktop applications with familiar web technologies, but your code wields much greater power. JavaScript can access the filesystem, user shell, and more. This allows you to build high quality native applications, but the inherent security risks scale with the additional powers granted to your code.
With that in mind, be aware that displaying arbitrary content from untrusted sources poses a severe security risk that Electron is not intended to handle. In fact, the most popular Electron apps (Atom, Slack, Visual Studio Code, etc) display primarily local content (or trusted, secure remote content without Node integration) – if your application executes code from an online source, it is your responsibility to ensure that the code is not malicious.
Source: Security | Electron
Additionally, creating a “privacy rating” risks two things:
- security theater, where people trust what they perceive to be a quantified rating that is in fact based on a subjective qualitative analysis (this is a massive problem across all of security, btw)
- legal/financial liability for the devs, where a plugin is proven to not have sufficient protections to warrant the rating it was given
Finally, to one of @den’s points:
anyway the API should have security in mind…for example read only access
As above, since javascript plugins are loaded into the running user context of the underlying Node.js process they can trivially bypass any restrictions the Obsidian devs tried to place into the API.
If the devs add security restrictions to the API the javascript can simply bypass that by executing a shell command to run against the underlying folders and markdown files in the vault. Remember, the plugin runs under the Node.js process which runs “as you” and has all the same permissions you do to read/write all the files in your vault (and anywhere else on your computer that you have access to as well).
There’s nothing Obsidian can do to prevent that, since that capability exists by design as an inherent feature of Node.js itself.
Given all of the above the only immediately feasible mechanism for handling this situation appears to be the social rating trust mechanism already built into the plugin system, where users can easily access the GitHub projects for each plugin and see its source code and can rate the plugin up/down, and if necessary can contact the devs directly here to report an egregious security flaw to have it placed on the central denylist.