[gejose]

This is one way to look at it, but ignores the fact that most users use third party community plugins.

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".

[hinkley]

When I was young there were a few luminaries in the software world who talked about how there is a steady if small flow of ideas from video game design into conventional software.

But I haven't heard anyone talk like that in quite sometime (unless it's me parroting them). Which is quite unfortunate.

I think for example if someone from the old guard of Blizzard were to write a book or at least a novella that described how the plugin system for World of Warcraft functioned, particularly during the first ten years, where it broke, how they hardened it over time, and how the process worked of backporting features from plugins into the core library...

I think that would be a substantial net benefit to the greater software community.

Far too many ecosystems make ham-fisted, half-assed, hair-brained plugin systems. And the vast majority can be consistently described by at least two of the three.

[setr]

I’ve been of the opinion that every hard problem in CS shows up somewhere in gamedev. It’s a great space for inspo.

[pjmlp]

I came to learn that even though in process plugins are easier to implement, and less resource demanding, anyone serious about host stability and security can only allow for plugins based on OS IPC.

And in general, it will take less hardware resources that the usual Electron stuff.

[awesome_dude]

Kernel design is (to me) another one where ideas have flowed into other software fields - there were monolithic kernels, micro kernels, and hybrid kernels, and they all need to work with third party modules (drivers)

The lessons from all fields seem to be relearnt again and again in new fields :-)

[ibash]

> Obsidian plugins have full, unrestricted access to all files in the vault.

Unless something has changed, it's worse than that. Plugins have unrestricted access to any file on your machine.

When I brought this up in discord a while back they brushed it aside.

[Tallain]

Having recently read through a handful of issues on their forums, they seems to brush aside a lot of things. It's a useful tool but the mod / dev team they have working with the community could use some training.

[esseph]

If you're using a flatpak, that's not actually the case. It would have very restricted access to the point where you even would have to explicitly give it access to user /home.

[HSO]

What if you run little snitch and block any communications from obsidian to anything?

[qbit42]

Is this true on Mac? Usually I am notified when programs request access outside the normal sandboxed or temp folders. Not sure how that works in any detail though.

[raybb]

Ah I guess that's one reason some folks started running it in a docker container. I think Linux server recently released a container for it.

[eli]

To be fair it also ships with the ability to install community plugins disabled.

[hsbauauvhabzb]

To be fair, it’s no worse of a dumpsterfire than any other plug-in ecosystem.

[eek2121]

Funny enough, I thought this earlier about Arch Linux and it's deritives. It was mentioned on reddit that they operate on a small budget. A maintainer replied that they have very low overhead, and the first thought that popped into my mind was that most of the software I use and rely on comes from the AUR, which relies on the user to manage their own security.

If engineers can't even manage their own security, why are we expecting users to do so?

[mcgrath_sh]

I'm shocked it is most of your software. I think I have under a dozen AUR packages. It has been that way for about a decade. I added a couple for gaming recently (mostly because Lutris just crashes for me), but nearly all of my software comes from the official repos.

[fa3556]

I think this criticism is unfair because most common packages are covered by the core and extra repos which are maintained by Arch Linux. AUR is a collection of user build scripts and using it has a certain skill cliff such that I expect most users to have explicit knowledge of the security dangers. I understand your concern but it would be weird and out of scope for Arch to maintain or moderate AUR when what Arch is providing here amounts to little more than hosting. Instead Arch rightly gives the users tools to moderate it themselves through the votes and comments features. Also the most popular AUR packages are maintained by well known maintainers.

The derivatives are obviously completely separate from Arch and thus are not the responsibility of Arch maintainers.

[zer00eyz]

> If engineers can't even manage their own security, why are we expecting users to do so?

This latest attack hit Crowdstrike as well. Imagine they had gotten inside Huntress, who opened up about how much they can abuse the access given: https://news.ycombinator.com/item?id=45183589

Security folks and companies think they are important. The C suite sees them as a scape goat WHEN the shit hits the fan and most end users feel the same about security as they do about taking off their shoes at the airport (what is this nonsense for) and they mostly arent wrong.

It's not that engineers cant take care of their own security. It's that we have made it a fight with an octopus rather than something that is seamless and second nature. Furthermore security and privacy go hand and hand... Teaching users that is not to the benefit of a large portion of our industry.

[dtkav]

I'm developing an Obsidian plugin commercially. I wish there was a higher tier of vetting available to a certain grade of plugin.

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.

[netghost]

Just out of curiosity, what's the plugin? Are there folks interested in paying for plugins?

[bryanhogan]

This open letter seems relevant here: https://www.emilebangma.com/Writings/Blog/An-open-letter-to-...

[bdzr]

I think it's a matter of time until we see a notable plugin in the obsidian space get caught exfiltrating data. I imagine then, after significant reputational harm, the team will start introducing safe guards. At a minimum, create some sort of verified publisher system.

[0cf8612b2e1e]

Don’t most plugin models work this way? Does VSCode, Vim, Emacs, and friends do anything to segregate content? Gaming is the only area where I expect plugins have limited permissions.

[jabbany]

Browser extensions also have a relatively robust permissions-based system.

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.

[schmichael]

vim and emacs are over 30 years old and therefore living with an architecture created when most code was trusted. Encrypting network protocols was extremely rare, much less disks or secrets. I don't think anything about the security posture of vim and emacs should be emulated by modern software.

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.

[raincole]

> Gaming is the only area where I expect plugins have limited permissions.

It's pretty much the opposite. A lot of modding communities' security model is literally just to "trust the community."

Example: https://skylines.paradoxwikis.com/Modding_API

> The code in Mods for Cities: Skylines is not executed in a sandbox.

> While we trust the gaming community to know how to behave and not upload malicious mods that will intentionally cause damage to users, what is uploaded on the Workshop cannot be controlled.

> Like with any files acquired from the internet, caution is recommended when something looks very suspicious.

[erik]

> Gaming is the only area where I expect plugins have limited permissions.

Do you mean mods on Steam? If you do, then that's down to the individual game. Sandboxing mods isn't universal.

[gejose]

Perhaps, but I think what you might put onto Obsidian (personal thoughts, journal entries etc) can be more sensitive than code.

[justsomehnguy]

> Obsidian plugins have full, unrestricted access to all files in the vault.

And how exactly you can solve that?

I don't want to press 'allow access' on the every file some plugin is accessing.

[schmichael]

One of the large dependencies they call out is an excellent example: pdf.js.

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.

[gejose]

Specific permissions declared in a manifest much like browser extensions could be a good first step.

[varenc]

Another thought: what about severely sandboxing plugins so they while they have access to your notes, they have no network or disk access and in general lack anyway for them to exfiltrate your sensitive info? Might not be practical but approaches like this appeal to me.

[antoniojtorres]

Deno would be a good candidate for this.

[zargon]

That's ok. I haven't come across an Obsidian plug-in that's worth introducing a dependency for.

[myvoiceismypass]

I use “Templater” and “Dataview” but now I am rethinking my usage; they were required for the daily template I use (found here on HN) but this is probably overkill.

[rajatkulk]

As someone who specifically started building Octarine, just for this reason, I understand.

Having to rely on random devs for the most basic functionality and passing it off as `community does what it wants` is weird. Either add it in yourselves, or accept the fact that given your app requires external contributors to work at a little above the basic level, there are going to be security issues.

Writing a whole blog post, and throwing shade on "other apps" that have far more dependencies than Obsidian is weird to me.

Anyway, it seems like you can't really talk bad about them, since there's a huge following that just comes at you, and that feels weird, cause they apparently can throw shade, others can't just talk back.

[Pikamander2]

> 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.

Ah, the WordPress model.

[shelled]

This app deals with very critical, personal, and intimate data – personal notes and professional/work-related notes, but proudly has an Electron app. This alone has seemed like a massive red flag to me.

[aucisson_masque]

Until there is a better alternative you’re left with electron. Nothing come close to obsidian.

[hahn-kev]

It's no worse than vscode. Sure there's permissions, but it's super common for an extension to start a process and that process can do anything it wants.

[bdzr]

It's *significantly* worse than vscode. vscode is at least attempting to grapple the problem: https://code.visualstudio.com/docs/configure/extensions/exte....

[endorphine]

And why is VSCode our baseline?

[thund]

Plus vscode is maintained by a company with thousands of devs. Obsidian is less than 10 people, which is amazing. About plugins why blame the product, pls check what you install on your machine instead

[TomaszZielinski]

My personal take is that the only way to be reasonably sure you're OK is to install as few apps as possible and then as few plugins as possible (and ideally stick to the bundled ones only). I don’t think it’s controversial, but for some reason this is not how many people think, even if in the real world you don’t give keys to your place to everyone who says they’re cool :)

[Jeff_Brown]

Among others, this is a big reason I want effect systems to gain more attention. After having seen them, the idea that in most languages, the only option is that any function can do anything without keeping track of what it affects in its type signature is bonkers to me.

[NelsonMinar]

I agree Obsidian plugins do nothing about safety. But I'm not sure "most users use plugins", that's not my impression from reading the subreddit. I wonder if there's any data on it?

[freehorse]

> most users use third party community plugins

Is this true? Is there any source about how many obsidian users use third party plugins? For once I don't. Moreover, obsidian by default runs in "restricted mode" which does not allow for community plugins. You have to specifically enable it to be able to install community plugins, hence I assume somebody who does that understands the risks involved. How many people even get into enabling that?

For me it is not even about security firstmost, the whole appeal of markdown is simplicity and interoperability. The more I depend on "plugins" the more I am locked in into this specific platform.

[gjsman-1000]

That just sounds like Linux packages; also not a system known for security of desktop apps and scripts especially compared to MacOS, shoot me.

[jabbany]

Operating systems are different though, since their whole purpose is to host _other_ applications.

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)

[kepano]

(CEO of Obsidian here)

Yes, on desktop, Obsidian plugins can access files on your system, unless you run it in a container. On iOS, iPadOS, and Android the app is sandboxed so plugins are more constrained.

This is not unique to Obsidian. VS Code (and Cursor) work the same way despite Microsoft being a multi-trillion dollar company. This is why Obsidian ships in restricted mode and there's a full-screen warning before you turn on community plugins.

VS Code and Obsidian have similar tradeoffs, both being powerful file-based tools on the Electron stack. This fear about plugins was raised on the Obsidian forums in 2020 when Obsidian was still new, and Licat explained[1] why it’s not possible to effectively sandbox plugins without making them useless.

So... what do you do?

The drastic option is to simply not use community plugins. You don't have to leave restricted mode. For businesses there are several ways to block network access and community plugins[2]. And we're currently planning to add more IT controls via a policy.json file[3].

The option of using Obsidian without plugins is more viable in 2025 than it was in 2020, as the app has become more full-featured. And we're now regularly doing third-party security audits[4].

But realistically, most people want to run community plugins, and don't have the technical skills to run Obsidian in a container, nor the ability and time to review the code for every plugin update.

So the solution that appeals to us most is similar to the "Marketplace protections"[5] that Microsoft gradually implemented for VS Code. For example, implementing a trusted developer program, and automated scanning of each new plugin update. We plan to significantly revamp the community directory over the coming year and this is part of it.

Note that Obsidian is a team of 7 people. We're 100% user-supported[6] and competing with massive companies like Microsoft, Apple, Google, etc. Security audits are not cheap. Building an entire infrastructure like the one I described above is not easy. We're committing to doing it, but it wouldn't be possible without our supporters.

[1] https://forum.obsidian.md/t/security-of-the-plugins/7544/3

[2] https://help.obsidian.md/teams/deploy

[3] https://x.com/kepano/status/1957927003254059290

[4] https://obsidian.md/security

[5] https://code.visualstudio.com/docs/configure/extensions/exte...

[6] https://stephango.com/vcware

[mallowdram]

Is there an alternate to obsidian?

[schmichael]

The Simpsons Springfield Nuclear Plant Security scene in real life.

https://www.youtube.com/watch?v=eU2Or5rCN_Y