Obsidian has a truly terrible security model for plugins. As I realized while building my own, Obsidian plugins have full, unrestricted access to all files in the vault.
Obsidian could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.
Or it could have a browser extension like manifest that declares all permissions used by the plugin, where attempting to access a permission that's not granted gets blocked.
Both of these approaches would've led to more real security to end users than "we have few third party dependencies".
If engineers can't even manage their own security, why are we expecting users to do so?
IMO they should do something like aur on Arch Linux and have a community managed plugin repo and then a smaller, more vetted one. That would help with the plugin review time too.
If they wanted to, one would guess that browser-ish local apps based on stuff like Electron/node-webkit could probably figure out some way to limit extension permissions more granularly.
Sneak in a malicious browser extension that breaks the permissions sandbox, and you have hundreds of thousands to millions of users as an attack surface.
Make a malicious VSCode/IDE extension and maybe you hit some hundreds or thousands of devs, a couple of smaller companies, and probably can get on some infosec blogs...
I would say VSCode has no excuse. It's based on a browser which does have capabilities to limit extensions. Huge miss on their part, and one that I wish drew more ire.
Do you mean mods on Steam? If you do, then that's down to the individual game. Sandboxing mods isn't universal.
And how exactly you can solve that?
I don't want to press 'allow access' on the every file some plugin is accessing.
There is no reason for pdf.js to ever access anything other than the files you wish to export. The Export to PDF process could spawn a containerized subprocess with 0 filesystem or network access and constrained cpu and memory limits. Files could sent to the Export process over stdin, and the resulting PDF could be streamed back over stdout with stderr used for logging.
There are lots of plugin systems that work this way. I wish it were commodofied and universally available. AFAIK there's very little cross-platform tooling to help you solve this problem easily, and that's a pity.
FWIW, MacOS isn't any better or worse for security than any other desktop OS tbh....
I mean, MacOS just had it's "UAC" rollout not that long ago... and not sure about you, but I've encountered many times where someone had to hang up a Zoom or browser call because they updated the app or OS, and had to re-grant screenshare permissions or something. So, not that different. (Pre-"UAC" versions of MacOS didn't do any sandboxing when it came to user files / device access)
Code with publicly-known weaknesses poses exponentially more danger than code with unknown weaknesses.
It's like telling sysadmins to not waste time installing security patches because there are likely still vulnerabilities in the application. Great way to get n-day'd into a ransomware payment.
I mean, jeeze, how much code comes along for the ride with Electron...
It's a great way to keep lifecycle costs down and devops QoL up, especially for smaller shops.
*Insert favorite distro here that backports security fixes to stable package versions for a long period of time.
The problem with supply chain attacks is specifically related to npm, and not related to JS. npm as an organization needs to be taking more responsibility for the recent attacks and essentially forcing everyone to use more strict security controls when publishing their dependencies.
It’s maybe a nit-pick, since most JS is run sandboxed, so it’s sort of equivalent. But it was explicitly what GP asked for. Would it be more accurate to say Electron is secure, not JS?
Any two Turing-complete programming languages are equally secure, no?
Surely the security can only ever come from whatever compiles/interprets it? You can run JavaScript on a piece of paper.
Conversely, barring a bug in the runtime or compiler, higher level languages don't enable those kinds of shenanigans.
See for example the heart bleed bug, where openssl would read memory it didn't own when given a properly malformed request.
I'd also be forced to ask... what exactly are you doing with a markdown note-taking application such that performance is a legitimate concern?
But, I mean, maybe you're reading this in a Lynx session on your ThinkPad 701C.
It runs on a majority of computers and basically all phones. There will be many security issues that get discovered b y virtue of these facts.
What makes you think that "native" apps are any more secure?
It's not a problem on pc, but an obsidian vault with thousands of notes can have a laggy startup on mobile, even if you disable plugins.
Users sidestep this issue with quick capture plugins and apps, but I wish there was a native stripped-down version of obsidian.
I’d love to try it, but speaking of security, this was the first thing I saw:
sh <(curl https://create.tauri.app/sh)
If you use Wayland and it works for you, that's great, but it's not my experience.
While we're on the topic: what's your default markdown handler on Windows?
But as a developer this post is nonsense and extremely predictable [1]. We can expect countless others like it that explains how their use of these broken tools is different and just don't worry about it!
By their own linked Credits page there are 20 dependencies. Let's take one of those, electron, which itself has 3 dependencies according to npm. Picking one of those electron/get has 7 dependencies. One of those dependencies got, has 11 dependencies, one of those cacheable-request has 7 dependencies etc etc.
Now go back and pick another direct dependency of Obsidian and work your way down the dependency tree again. Does the Obsidian team review all these and who owns them? Do they trust each layer of the chain to pick up issues before it gets to them? Any one of these dependencies can be compromised. This is what it means to be. supply chain attack, you only have to quietly slip something into any one of these dependencies to have access to countless critical user data.
[1] https://drewdevault.com/2025/09/17/2025-09-17-An-impossible-...
Maybe, just maybe, don't give fullmouthed advice on reducing risk in the supply chain.
What a horribly disingenuous statement, for a product that isn't remotely usable without 3rd-party plugins. The "Obsidian" product would be more aptly named "Mass Data Exfiltration Facilitator Pro".
It is possible to make your same point without histrionic excess.