Earlier quoted context omitted.
You better delete all third-party applications for they are having full disk access.
Hello, 2010s called. 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…
Obsidian plugin was abused to deploy a remote access trojan
121–130 of 241 posts
Re: Obsidian plugin was abused to deploy a remote access trojan
#122Earlier quoted context omitted.
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.
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?
Re: Obsidian plugin was abused to deploy a remote access trojan
#123Earlier quoted context omitted.
Releasing the source code to the clients would also address many of our concerns.
How would that make a difference for plugin security? Almost all plugins are already open source. 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: https://obsidian.md/security
Re: Obsidian plugin was abused to deploy a remote access trojan
#124What are the reasons behind the fact that almost all of these plugin systems are so poorly engineered? Is it too much work (ie, there are no good plugin development frameworks that already enable proper isolation/permission capabilities) or "simply" a widespread lack of knowledge of what is needed, so devs learn only after their own system has been abused? Both? Something else?
Web stack plus lack of resources to architect the proper interfaces is my guess. These are software written in high level js frameworks, thus using poor dataflow patterns by default, mostly just following what is actually possible instead of employing intentional design, which would require going down some levels of abstraction and maintaining a custom fork of said frameworks. So they probably just architect plug-ins…
Re: Obsidian plugin was abused to deploy a remote access trojan
#125Earlier quoted context omitted.
Chrome gutted extension capabilities for safety and now it is so useless, politically unwanted extensions have "lite" versions and every big project and their dog ship their own chromium browser. 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.
[flagged]
I think by that logic dangerously-skip-permissions and openclaw should've never been a thing. I agree that people use them too liberally, but I think at some point you have to find a balance between systemic safety risks and individual freedom.
Re: Obsidian plugin was abused to deploy a remote access trojan
#126Earlier quoted context omitted.
I've never tried to do this or similar in Windows (obviously easy in unix-like environments) but I'm going to bet it's far more trouble than it's worth for 99% of users
On macOS at least those 99% of users are probably installing from the App Store, where apps are sandboxed by default and need to explicitly ask for access to paths outside that sandbox. Even when not installed from the App Store a permission dialogue is popped if an application tries to read from sensitive paths like your photo library.
Re: Obsidian plugin was abused to deploy a remote access trojan
#127Yet another reason to not install anything third-party made. Favor batteries, built-in functionality and reject “Unix philosophy” or whatever bullshit people use to ship incomplete software under guise of.
Re: Obsidian plugin was abused to deploy a remote access trojan
#128Earlier quoted context omitted.
Hello, 2010s called. 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…
Sadly, Windows cannot do that. Every installed program has full disk access by default. It's very, very difficult to make it not so.
Re: Obsidian plugin was abused to deploy a remote access trojan
#129I really do think Obsidian needs 2 things to have any reasonable security:
1. It needs to be a lot more batteries-included. A user shouldn't need a plugin for basic functionality.
2. It needs a granular permission system, where each plugin should have to declare and prompt you to allow or reject specific permissions, just like on iOS and Android. The system should enforce that a plugin cannot bypass this.
Re: Obsidian plugin was abused to deploy a remote access trojan
#130> The victim is prompted to enable the "Installed community plugins" synchronization feature. Obsidian has the proper protections in place to prevent this type of attack, and the victims are being convinced to ignore them. This is just a successful social engineering event. I hate to see Obsidian dragged down by this headline, since this attack is not exploiting a vulnerability in it or its plugin system.
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 intern…
That's what make obsidian plugins useful. It it's just for having themes , there is no need for them