Here’s my suggestion:
We could maybe limit the community plugins to plugins which have had some audit from the devs, and before updates are pushed, they are again audited. These plugins can be installed without turning safe mode off. From a risk perspective, these plugins would sit somewhere between Obsidian’s own plugins and how plugins are done currently.
And then the usuer has the ability to just add plugins outside the community plugins page by disabling safe mode. From a risk perspective, they would be exactly like current plugins.
As some devs in this thread have mentioned, sandboxing the plugins would be infeasable, so we might as well not try for now.
Additionally, I want to say that I dislike OP’s 2nd suggestion. I use obsidian because if there’s a functionality that’s missing in Obsidian and existing plugins, I have the ability to make a plugin that does what I want.
I’ll just quote what WhiteNoise already said well, and has been said in other ways multiple times in this thread:
And from the help files:
Due to technical reasons with our platform, we’re unable to restrict plugins to a specific permission or access level. Since we offer Obsidian for free, currently we’re unable to manually review each plugin.
As far as I can tell, your suggestion is essentially, “yeah but some of them?” And (according to this thread, not according to me) the short answer is: No.
Thanks for the reply.
This is going to sound embarasing, but I kinda only skimmed Licat’s responses to Den (which do adress my suggestion) because I assumed they were all responses on why sandboxing wasn’t feasible.
This discussion thread is quite informative and philosophical at times. I have a purely technical question: if I download a plugin but not enable it, is there any harm if the plugin has a (honest) security hole?
So I have about a dozen plugins that I might potentially use, but would like to enable them only when needed. Would the need-based-enabling minimize any security risk? In other words, is there any difference between “disabled” and “uninstalled”, or between “all plugins disabled” and “safe mode”?
So I have about a dozen plugins that I might potentially use, but would like to enable them only when needed
I’ve downloaded tons of plugins for the same reason. What I really need is a way to “favorite” plugins instead so that I stop downloading plugins that take up space and take time to update even when I’m not yet ready to use them.
I think it’s a pretty safe guess that there are no security risks if the plugin isn’t enabled, just from my own technical experience and what I’ve seen so far about how Obsidian plugins can be manually installed in the .obsidian/plugins by just doing a git clone there. So I wouldn’t worry about it.
If you want to be more safe, then maybe you could go into the .obsidian folder, create a new folder called .obsidian/plugins-disabled and move that particular plugin’s folder into it from the .obsidian/plugins
For Linux user, what about flatpak package ? Every flatpak applications are sandboxing, and with flatseal we can manage permissions for each flatpak. We can authorize only one path acces for obsidian, and we can block internet access.
I think it work also for the plugins, but maybe i’ve wrong ?
What about recommend Flatpak package for linux users who care about security, and what about create an official flatpak, with indications about flatseal ?
(I made a handful of searches before writing this)
There’s been news recently about the Kindle Highlights plugin sending telemetry data to Sentry, and has been removed from the plugins store as a result. I don’t know how or if the Obsidian API handles outgoing data / HTTP requests, but there should be a standardized way in the API. Plugins may send data to 3rd party sites / servers, either way when a user installs a plugin, Obsidian should ask for permission for a plugin to send data. Any sort of data, or which sites it can be sent to, if a plugin sends it to multiple sites.
I know Obsidian’s policy is not to send data anywhere, but what if its for benefit of the user, or the user would want a plugin to do that for the sake of features it may provide? I think it should be the choice of the user.
I quickly threw together this mock up of what it could look like: another button on the plugin list for permissions, showing a notification dot after installing so a user can decide on permission. When they click on it, it looks like a plugin settings page, where they toggle what permissions to give it. Although I imagine it would actually look different.
I added a feature request related to this topic, now knowing this conversation had unfolded. In it, I proposed Obsidian devs to require developers of plugins that send your notes to any external web services (not that interface with 3rd party services, nor that might introduce malicious code, though I acknowledge those are important security concerns too), to include as part of the development of their plugins a consent mechanism explaining to users why, where and how their notes are being sent outside the local first, security-oriented environment of Obsidian. Part of the response was:
Maybe I am not explaining myself correctly when I talk about a consent. A consent is not enforceable, its nature is informative with the goal to allow whoever consents with the appropriate, (hopefully) fair amount of information to make a decision. When we turn off restricted mode in order to install community plugins, we must consent to do this while being provided with useful, transparent information. I am speaking about this type of consent.
As a former Atom user, I know how difficult enforcing security can be technically speaking when dealing with Electron. But I find it disappointing that Obsidian devs cannot enforce a simple UI feature on plugin devs in order to allow all users, especially those without technical knowledge, to make an informed decision. Doing this should not affect any aspect of plugin development and, although it cannot guarantee that notes will be safe under any plugin it does signal Obsidian commitment to do as much as possible to protect user’s privacy. If this is a barrier for submission to a plugin developer, then maybe there is reason to not let said plugin hit the community store.
Yes, a “standardized pledge” would be a good step towards signaling a culture to developers, but my request is focused on providing information to users.
This is your opinion. I instead argue that some users might be under the impression that their consent is enforced by Obsidian (especially since we are used to how mobile OS work). The consent/dissent for restrict mode is enforced. When you consent for an app on your phone to do/not do certain things that is also enforced by iOS/Android. Hence why I stress with the wording “Third-Party Developer Pledge”
If the goal is making an informed decision, having a standardized pledge of what each plugin developer promise to do/not to do is enough. You read the pledge and you decide 1) if you are fine with the terms chosen by the developer and 2) if you trust that they will honor their pledge.
One thing that perhaps wasn’t clear in my first post is that different plugins can pledge different things.
I understand now what you mean by “enforced” and what you interpret as “consent” in this context, thanks for clarifying. Yet, this enforcement you talked about happens on the developers end, not on the users end. I do not see why enforcing developers to add a screen, similar to the one Obsidian uses to activate community plugins to each plugin sending notes to third parties would be a hard buy.
You stress a pledge but that doesn’t give any agency to users who are at mercy of developers’ ethics instead of having the agency to decide what to do based on clear, succinct and transparent information, they way they do when they activate plugins.
This is a very low barrier to allow users to make informed decisions when their private notes might end up feeding proprietary algorithms.
I am confused because I think we are describing the same thing but then you think it’s not informed decision.
If for every plugin in the store, you see on top a table that says
This third party developer promises that the plugin does X, Y, Z, and doesn’t do A, B, C. (in a standardized fashion), can’t you make an informed decision based on that?
I am not sure if it’s possible to have a permission system in obsidian, but that would be really awesome.
I love Obsidian, been obsessed with it and went through the learning curve, there was data on my notes that were not sensitive before but now I just can’t afford for it to be exfiltrated. Without really strict controls on how plugins could manipulate data I will be forced to use some alternative for this vault / content. Question, the core plugins are completely under Obsidian dev control including any libraries these could use?
Edit: Note that I was always aware the plugins could potentially pose a risk, this is not new, just found this post which reflects my similar thoughts.