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.
2 Likes
Have you changed your mind about using community plug in? I’m also a new user, it seems that plugins have a lot to offer but I cannot risk my sensitive data. What were your solutions?
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”?
1 Like
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.
You could use the “Copy share link” button on the plugin page and paste the link in a list.
2 Likes
This question of disabling vs. removing plugins remains unanswered. Most security experts recommend completely removing unused extensions/apps, but in doing so all the customized settings are lost.
Perhaps the developers could explain exactly what disabling means, and let the users decide the best course of action?
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
1 Like
About security concern, maybe the dev team can add 2 CORE features :
- A “report” section, report to user which plugin are connecting to where
- A “button/switch” next to it, which still allow plugin to work, but when press it, it will make that plugin completely offline.
- A new section in obsidian forum, have a public list to let the community know which plugin officialy connect to where. So it easier to detect anything weird happen.
2 Likes
So sorry for the long silence, to be honest I’ve lapsed in my use of Obsidian… I’m now picking it up again to take another look.
I’m open minded about plugins, but still concerned about security. The issue for me is that you have to trust the developer, there is no quality control. So the onus is on us the users.
I’ll let you know if I change my mind… I’m catching up again after being ‘away’…
Hi,
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.
4 Likes
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.
1 Like
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.
1 Like
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.
2 Likes
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?
If not, clarify what you mean, because I am lost.
Sadly Javascript is an extremely insecure language, just look at this.
I am not sure if it’s possible to have a permission system in obsidian, but that would be really awesome.
Otherwise, maybe a DSL for writing plugins for obsidian with controlled effects (similar to elm) could make it so that auditing the code becomes trivial (just look wherever a side-effect is being used). Because in Javascript it’s neigh impossible for someone to implement a sneaky bitcoin mining process or similar into the plugin without anyone noticing it.
1 Like
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.
Yes, that’s correct.
The general attitude here talking about people needing to make their own decisions and review the code like everybody is a programmer is kind of hilarious.
1 Like
Not everybody needs to check obviously. There’s a sweet spot of enough developers checking—in particular those who want to improve or fix the plugins.
Once the first rogue Obsidian plugin is discovered, it will be a huge story.
But this will take much longer than, say, Chrome extensions because the plugins’ source are on GitHub (with one or more closed-source paid extensions which I understand are under strict review by Obsidian core developers?)