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 haven't seen any reports of users being affected by this attack.
In 2026, applications, third or even first party, don't need to have full-disk access, and are not given either. They see a jailroot environment. I give full disk access to the terminal app, and a handful of others. 90% of them, nope.
At least that's the case in macOS, I'm pretty sure Windows can do that too. Linux of course has had such capability since forever, but I guess most distros you need to manually take care of it.
Would love to enable this for all apps, and add exceptions for the ones that need more access.
I installed Lulu and BlockBlock recently, and want to do more to harden my Mac.
When an app tries to access something outside of its sandbox, you get a notification asking to approve or deny. Full Disk Access I think needs to be explicitly given on System Settings (Privacy & Security -> Full Disk Access).
I have no idea how to do that in Windows though.
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 users might value that greatly.
A permission system for their plugins might be the only solution, annoying permission request popups and all.
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. ;)
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.
-
I've read the article describing the attack, and my very first thought was utter surprise that the entire attack chain started with someone accepting a shared vault from a stranger via social media (linked in and similar). That seems really, really strange to me.
I've never shared a vault - but if I did, I'd probably do so as a git repo of markdown files.
It would be interesting to see a blog post from Obsidian about "good hygiene for sharing vaults".
Is this like a popup? which most people actively accept without blinking
I think plugin/extensions should be a bit harder to run by default. I get the user friction from extra hurdles before using their plugins etc., but I don't think there is an actually safe way to execute arbitrary code, unaudited, without sandboxing, or other restrictions.
There's no protections beyond that, community plugins can do whatever they want. Thankfully, the vast majority of them are open-source.
IMO that's an issue in and of itself, but it doesn't read that way in the (very unclear) original article.
I know many people swore / swear by the datatables plugin, but now that Bases in core, you can get pretty far without it, no?
There's countless articles and videos about various community plugins and even curated selections of them depending on your use case for Obsidian.
1. exit restricted mode to allow third-party plugins
2. trust the author of the vault that's being shared with you
3. trust the plugins being shared with you via sync
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 mean for the security of the app without plugins you can currently inspect the app's code in app.js and review third-party audits:
I O S. APPLE ECOSYSTEM. MOBILE STUFF.
Idk, I've always thought it was odd that the "community plugins" settings pane seemed more concerned with assuring the user that community plugins were fine than actually explaining the risk.
There is literally a single sentence about the fact that plugins "may cause data integrity and security issues", and it is hedged with the mealy-mouthed modifier "like any other software you install". The absolute majority of it - maybe 80% of the text by window height - is about the measures Obsidian does to vet and secure plugins. All of it appears to be written with the intent to placate any concerns.
Is this the safety warning? The screen that says that community plugins could cause issues "like any other software", but they're actually super safe and vetted and totally fine? Is it surprising that a person, faced with a screen like this, would be susceptible to a social engineering attack?
Given that vaults are just Markdown documents, and plugins are so safe (or so Obsidian seems to claim), why should a person feel at all concerned clicking yes to these prompts? Is it still a social engineering attack when the app appears to encourage you along the way? Are these even safety warnings, or just (vaguely encouraging) confirmation dialogs?
I don't see how Obsidian should come off as completely blameless here. They've always tacitly encouraged this wild west plugin ecosystem, because it's an obvious generator of value. They don't get to absolve themselves of any responsibility by pointing at safety warnings, when those "safety warnings" spend (far!) more time explaining why the user might want to click "yes" than "no".
To be clear, I like and use (and pay for!) Obsidian. But the design of Obsidian plugins was clearly broken from the beginning, and the official messaging around them has always been more encouraging than wary. This sort of event is an absolutely inevitable consequence of those decisions.
Yes it would be good to make it less easy to shoot yourself in the foot. However, I believe users should be in control. People should be able to do powerful things if they choose to. But that will always come with the risk of misuse or social engineering.
I use Obsidian because it does not treat me like a child. They can add more nags and banners for normies, but the capabilities should remain.
This can't be dismissed as "slippery slope" logic either. Should elderly people with a bank account be allowed to use a computer? They might read something online and give their savings to a scammer. Frankly, that's a far more convincing argument than the one given here. There's only one solution if your objective function is exclusively to minimize the possibility of a security incident.
Plugins like Tasks do offer a Query functionality that allows me to list e.g. weekly tasks on my daily template, replicating most of Noteplan's workflow, except Noteplan relies on being able to easily link those tasks into daily template by drag and dropping them, which internally assigns a unique but hidden by default ID in ^129abz notation (https://help.noteplan.co/article/138-synced-blocks). The latter is already supported by Obsidian, it's just not as "clean" and, AFAIK, impossible to get done when drag and dropping.