A very relevant article:
"On the security of plugins" (in notes app)
Obsidian plugin was abused to deploy a remote access trojan
211–220 of 241 posts
Re: Obsidian plugin was abused to deploy a remote access trojan
#212Obsidian CEO here. There is a major update coming soon for plugin security. I think it will address many of the concerns people have raised in this thread. It's a hard problem but we are working on it. That said, the headline is misleading. This article is about a social engineering attack that requires the user to actively reject multiple safety warnings in Obsidian. As far as I know this is a proof of concept, I ha…
Obsidian is great. And glad to see how you’re looking at plugin security. But one more thing you should consider is: How do you reduce the need for plugins for basic product behavior. E.g., I use a plugin to be able to open a file in new tab instead of replacing current tab. That should be a setting, not a plugin I’m forced to use.
Re: Obsidian plugin was abused to deploy a remote access trojan
#213Earlier quoted context omitted.
I was pointing out that the claim that "literally a majority of all software on your computer" runs sandboxed is also trivially false, to a significant degree
A majority have more access controls than obsidian plugins, yes. I think that's fairly safe to say, given that new system installs often have hundreds of processes already running. Sandboxing, at least in the sense of easily configurable access with default deny on most even somewhat sensitive things: agreed, sandboxing is fairly uncommon in general, definitely not a majority on most systems. When ignoring the elepha…
> A majority have more access controls than obsidian plugins, yes
A majority run as me, a minority run with root privileges.
> I think that's fairly safe to say, given that new system installs often have hundreds of processes already running.
Precisely! Those hundreds of pre installed processes are running without sandboxing, or any access control beyond what Obsidian has.
For example, did you know you can just `ls` a directory, or `cat` a file, and both of those applications will run with full, unsandboxed, unrestricted access as you? And there are countless preinstalled applications just like those.
Re: Obsidian plugin was abused to deploy a remote access trojan
#214Obsidian CEO here. There is a major update coming soon for plugin security. I think it will address many of the concerns people have raised in this thread. It's a hard problem but we are working on it. That said, the headline is misleading. This article is about a social engineering attack that requires the user to actively reject multiple safety warnings in Obsidian. As far as I know this is a proof of concept, I ha…
Obsidian is great. And glad to see how you’re looking at plugin security. But one more thing you should consider is: How do you reduce the need for plugins for basic product behavior. E.g., I use a plugin to be able to open a file in new tab instead of replacing current tab. That should be a setting, not a plugin I’m forced to use.
Re: Obsidian plugin was abused to deploy a remote access trojan
#215Earlier quoted context omitted.
There's open, and then there's "full disk access, even outside the vault" open.
What do you propose? Even if they configure node's lowest level file APIs to block any access to paths outside the vault, plugins can still execute arbitrary shell commands who will have access to the entire OS. And before you say it's useless and should be stopped too, well, that's a fine opinion! But then you lose plugins providing git integration, automated backups, document conversion using pandoc, etc. Many user…
That's a good point. I think I'd solve this in two steps.
0) scripts and plugins should only be able to operate on the text in the vault. Just like how I expect a snippet of JavaScript running in my browser to only have access to the website and not to my entire disk.
1) Any commands that run outside of this sandbox need to be approved first. Obviously this could get annoying, but there's tricks you could use here to help.
Obviously this is a high level approach and I'm not on their team, so this is basically armchair programming. But since you asked, it's okay. ;)
Re: Obsidian plugin was abused to deploy a remote access trojan
#216Obsidian CEO here. There is a major update coming soon for plugin security. I think it will address many of the concerns people have raised in this thread. It's a hard problem but we are working on it. That said, the headline is misleading. This article is about a social engineering attack that requires the user to actively reject multiple safety warnings in Obsidian. As far as I know this is a proof of concept, I ha…
I don't understand the hate here. Obsidian is a well working product that scratches many inches. Plugins allow to scratch some more itches, but are not mandatory.
I am using several plugins and would prefer not to, but they allow me to bring the (mobile) app closer to what I want (notably templater and homepage as I want to get a new daily note sorted in monthly folders, which obsidian doesn't seem to allow natively).
Maybe an alternative would also be to more explicitly allow users to create their own scripts - but maybe that's possible and I just don't know.
Overall I think the key challenge with obsidian use is that it offers too much, and there's a lot to fiddle with. While it will bother the power users probably best would be to just move on many ways to "default" behaviours and e.g. make many of the "core plugins" just settings to make the list lsss overwhelming.
Re: Obsidian plugin was abused to deploy a remote access trojan
#217A very relevant article: "On the security of plugins" (in notes app) https://standardnotes.com/blog/on-the-security-of-plugins
While not wrong I'm not sure the publisher is uninterested as they are a competitor.
E.g. this is how they criticise obsidian - suggesting that a default location backup is somehow worse than default cloud sync is just very strange to me.
Obsidian stores your data as a folder of plaintext files on your local computer. You are thus responsible for securing this folder and making it available on your other devices. This is particularly difficult on mobile platforms that lack access to a robust file system.
Re: Obsidian plugin was abused to deploy a remote access trojan
#218Earlier quoted context omitted.
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.
To make an actual counter, you need numbers. If only a tiny niche of users use it without community plugins, then yes, it's unusable (in a practical definition of the term)
If that's so, then without numbers, it's neither usable nor unusable.
Re: Obsidian plugin was abused to deploy a remote access trojan
#219I hope I'm speaking as a minority but when I first started using Obsidian the Youtube videos I watched encourage the usage of community plugins, even with these warnings I would enable the community plugins. You may very well have good actors that eventually turn bad for these plugins and users won't know. Maybe I just also have a higher personal risk appetite, but even as a dev and knowing these risks I would have e…
One issue seems to be also that there are means dead plugins, not updated for years but still available. Does that mean they are especially stable or just no longer maintained? I don't know but ili applied the same rule I would for FDroid or the play store - not to install anything that isn't actively maintained.
Also I can't tell how to prevent plugin updates. As long as you rely on a known safe version I guess there is never any real risk.
Re: Obsidian plugin was abused to deploy a remote access trojan
#220Earlier quoted context omitted.
I've been using obsidian for years as a paying customer. Will continue to pay as price point is good and it just works. However, unless plugin security massively improves I will never install any plugins.
Obsidian is only seven people but we are working on this from all three angles: 1. Make community plugins less necessary over time as basic features become part of core 2. Improve the security of community plugins 3. Make it easy to create your own plugins that you can fully trust, e.g. with the recent release of Obsidian CLI
If you can build in one thing, I'd pick something equivalent to Omnisearch. That makes it much easier to find things. I always struggle with the default search.