Comment by Groxx
3 days ago
Ehm. No? https://obsidian.md/help/plugin-security#Plugin+capabilities
>Due to technical limitations, Obsidian cannot reliably restrict plugins to specific permissions or access levels. This means that plugins will inherit Obsidian's access levels. As a result, consider the following examples of what community plugins can do:
Community plugins can access files on your computer.
Community plugins can connect to internet.
Community plugins can install additional programs.
Obsidian has no protection at all. Installing a plugin gives it full access to your computer.
This was only a matter of time, and honestly I think it's inexcusably negligent that they shipped a plugin system like this at all since about 2010 (or arguably much earlier).
It does give full access but Obsidian does tell you that. Community plugins are not enabled by default, you have to enable them manually. Same happens with a shared vault: once you get it you still have to manually enable plugins. So far no one managed to sneak in a plugin completely unnoticed.
That's horse hockey. Obsidian is not a usable system without community plugins.
Folks will reply "but I use it every day without plugins".
That position disregards software usability as a formal discipline, along with decades of UX research and standards.
If you want to use a niche, academic definition of "usable", that's fine but you better be ready to explain yourself.
Because in general, "usable" means "people use it". Which they do for Obsidian without community plugins without issues.
3 replies →
The attack here requires not just enabling community plugins, but also syncing the attacker's vault to your computer, and also separately enabling the synchronization of the attacker's plugins with yours.
12 replies →
As one of those people that uses Obsidian without plugins, what plugins do you consider essential?
6 replies →
But I use it every day without plugins.
Seriously though, I agree with your sentiment that community plugin security can and needs to be improved, but how does someone saying they use it every day "disregard software usability as a formal discipline, along with decades of UX research and standards"
> Obsidian is not a usable system without community plugins.
It's horse hockey. Plenty users use the vanilla Obsidian.
> Folks will reply "but I use it every day without plugins".
Because they do. You're saying that they should lie about their usage to fit your narrative?
5 replies →
I think that's especially important to point out because it reminded me of a blog post by Obsidian that also was discussed here[1], where they talked about reducing supply chain risk by not relying on dependencies, but people quickly pointed out that this is only possible because users depend so heavily on extensions. Just look at that top comment and here we are now.
This combination of software relying on third parties without security seems to be untenable. Personally I've gotten rid of just about as many extensions as I can anywhere and switched to batteries included software.
[1]https://news.ycombinator.com/item?id=45307242
Using it daily without plugins is, by definition, a "usable system".
Yeah, but these attacks are possible without any of that complexity.
The real problem is people believing "plugins" are not full software.
If you install a dozen mini-apps from random developers you never heard about, you can't complain if one is malware.
Krita also has a plugin system based on Python. Any "plugin" has the same level of access as running a python script.
Personally I blame operating systems for not providing a way to isolate how programs interact with user files.
6 replies →
"Hey users: don't do insecure things. Here's a button to do cool insecure things!" is not a plugin security model.
Meanwhile that is exactly what a lot of people here want for Android with side loaded apps
2 replies →
A program one runs on one's computer can and should be able to do computer things. The alternative road you're advocating for ends in hardware attestation https://news.ycombinator.com/item?id=48086190
There are in-between models, such as:
* Android's permissions model where the user must approve specific potentially undesirable classes of actions (separate from the 24H delay, etc controversy)
* Optional sandboxing
I remember reading that page sometime pre-COVID, and being surprised at just how ridiculous it was. It started strong with “The Obsidian team takes security seriously”, but then almost everything else on the page led me to believe they didn’t actually take security very seriously.
I agree with the claim of negligence. I think they were more than happy to reap the benefits of a thriving community plugin ecosystem, and were hoping this page would provide enough CYA when security breaches inevitably occurred.
> TIP: If you're working with sensitive data and wish to install a community plugin, we recommend that you perform an independent security audit on the plugin before using it.
I wonder just how many plugins received a security audit.
I use only one plugin because I am aware of the security model (or lack thereof). I only use one because I read the source and am convinced it’s safe. It would be foolish to blindly install many plugins.
Agreed, but also they prominently feature that they support plugins. Currently it's the second paragraph on the home page: https://obsidian.md/
They're trying to get all the benefits while pushing the extremely-obvious-to-them downsides into subpages. Not hidden, but not shown along-side the feature. It's intentionally misleading for non-technical users.
Obsidian seems like a perfect candidate for a WASM/WASI based plugin system that would properly sandbox plugin code.
For at least the vast majority, yes definitely. I'm fine with full bypasses existing (say a webgl thing, or web previews, custom VCS integration, there are tons of legitimate reasons to escape a sandbox), but they should be an abnormality with heavy warnings and proportionate community attention to watch for issues, not the only option.
I don't think they meant it this way, but I honestly consider unsafe official plugin systems to be negligent to the point of being actively malicious. By releasing one, if you ever become successful you have explicitly chosen to screw over an unknown number of your users to save yourself a relatively small amount of work in the short term. It might be single digit users, or it might be septuple digit users - is it really worth it?
(Unsafe unofficial plugins, like most games? Mildly unfortunate but I think that's fine. Though a healthy modding community around your stuff should be a VERY STRONG sign that you should introduce a safe version to protect your users, if it won't cause you to implode (it definitely can)).
Has WASM/WASI DOM-access? When I last read about the architecture, there was a strict separation between WASM, Javascript and the app, but also a movement to allow UI-customization from WASM-space. Many Obsidian-plugins are adding heavy UI-changes, so without that, it would be kinda pointless.
Not generally / as many would hope, but that's partly because both WASM and WASI are not targeting being a full javascript-in-browser replacement - they're lower level, larger APIs are built on top, not defined by them. It's fairly easy to build an unsafe and unstable DOM access layer (a little bit of eval or string key accessers), but the web changes rapidly and isn't a stable target - exposing that in a stricter environment is tricky, and no one approach is likely to solve all needs.
Seems like the same risks of downloading plugins/packages for various text editors.
> Community plugins can access files on your computer. Community plugins can connect to internet. Community plugins can install additional programs.
That's what make obsidian plugins useful. It it's just for having themes , there is no need for them