#70

Thanks for your reply, Klaas. I understand your points. But how to find out, wich developer to trust or not. Of course, the number of downloads may be a hint.

#71

@PietArt It’s okay, I appreciate the perspective. I just don’t want more people to chime in saying the same thing. :wink: (As an aside, Discourse—the forum software we’re using—provides a really neat “summarize thread” feature at the top of long threads like this one.)

It’s a really tough challenge! The power of Obsidian’s API architecture is what makes plugins so useful, but also potentially dangerous. A classic double-edged sword. (I have always hated that saying, though, because… aren’t all swords dangerous to the wielder…? just because it only has one sharp side doesn’t mean you can’t cut yourself on it!)

I did just think of another angle on the element of trust in this conversation.

The role of GitHub and GitHub Profiles

To be published, plugins need to be submitted via GitHub. That means that GitHub itself may play a small role in the detection of malicious code (e.g., How GitHub secures open source software | GitHub Resources).

Moreover, developers submitting plugins need to have a GitHub account. These are tied to a verified email address. So, there’s another layer: anyone who wants to submit malicious code within a plugin needs to have an email address and a GitHub account.

Arguably, then, anyone who intends on malice will not be tying these identities (a GitHub account and an email address) to their own actual identity, because it would personally link them to the malicious code they’ve tried to get published. So, users can increase the amount of trust they put into a plugin by looking at several values:

  • The plugin itself. What does it do? Is it obviously malicious? Is it very complicated (and therefore has more places to hide bad intentions)? Etc.
  • The community. Is the plugin widely used?
  • The developer. Is the developer’s GitHub account well-developed? Do they provide personal information on their profile? Have they been active in other projects over time?

There may be other dimensions of trust on plugins. Can anyone think of them? It may be useful to put this together in a framework in the docs so that users have an easy tool to use to assess risk.

#72

Nice find and post! Thanks. It’s just a little above my pay grade, but it does seem to imply that GitHub may have the tools to provide some layer(s) of protection/security for Obsidian (or substitute me) in regards to Plugins.

One last question?!?

Do you have any knowledge that the Devs are or were aware of the GitHub Security features listed in the article when they chose it for the repository of the Community Plugins?

#73

Thanks for answering, Ryan, and your thoughts about how to check the background of plugin developers.

#74

No, I think it is just a bonus.

To be clear, this GitHub feature still does not guarantee security. It just offers a few features to help. E.g., a plugin developer may be alerted if they include a known vulnerability in their plugin code.

1 Like
#75

Yup, got it. (Something is better than Nothing….I hope). Thanks again for your responses. Maybe others will get some benefit too.

1 Like
#76

I understand that guaranteeing the security of any plugin is not feasible, but I think useful progress can still be made to protect users against the inevitable nasty plugin.

Let’s say that yesterday, someone looked through the source for plugin-x and found it was sending sensitive files to a remote server. Now today, I’m looking at the Obsidian plugins page, considering downloading plugin-x. The fact that it sends sensitive files to a remote server is rather useful information to me! (Or at least the fact that this has been alleged that it is up to no good).

So perhaps a mechanism to ‘report’ a plugin is in order? The reporting form could even ask the reporting user to link to the offending line of code in the GitHub repo and explain what it’s doing, and why that’s bad.

It would take up a bit of the Obsidian devs’ time, but seems like a low-cost option to me.

And even just the existence of this mechanism would act as a deterrent to plugin developers, knowing they’ll get a ban from Obsidian, and maybe even kicked off of GitHub too (hosting malicious service is against the terms of service).

Apologies if the suggestion has already been made above, I’ve only read the summary of the thread.

1 Like
#77

email and responsible disclosure exist.
That and the devs can remotely disable plugins

#78

Excuse my ramble and possible rehashing of ideas, but this more recent discussion gave me a few new thoughts that I wanted to share. I wonder whether once a plugin is installed is it just as capable of causing harm in a vault that is regularly used vs. one that you created for a specific purpose then forgot about. If the plugins can continue to do things that could perhaps be hampered if that plugin was uninstalled, maybe it might be useful for there to be a feature, perhaps a plugin (ha), that keeps track of and reports all vaults and their installed and enabled and even uninstalled plugins and their versions. This way, when and if something ever arises and is recognized by a particular user, they could pass this report along, and maybe a pattern, or lack there of, can be discovered. It also may give users a reality check of how many risks they have taken and whether a system reset and security practice overhaul may be in order.

There are certain things that come with the accumulated risk that are obvious to most but very unclear to beginners that could be spelled out. Even just a summary of some of the greatest hits from this thread that could be linked to from the Safe Mode dialog might give future new users a moment of pause before it is too late. And by too late, I don’t necessarily mean that harm is done to them but rather the perception of harm possibly having been done and no way to know after the fact, which may be bad for Obsidian’s growth within a certain subset of users. This fear could make some people want to do a reset, and if they had the information of how to do it in the first place they might be more likely to proceed with realistic caution and also be less likely to develop some sort of resentment at the app and themselves.

All of these things seem like possible positives for Obsidian, which hopefully is what we all want. As Obsidian succeeds, so do the top plugins and the number of eyes checking them out, which is good for us all. Again sorry for any repeats. Over time, I have read this and other similar threads in their entirety, but it has been over a long period of time, bit by bit. Anyways, thanks to everyone for sharing such valuable information and concerns. It really is helpful.

1 Like
#79

As a brand new user of Obsidian, I just want to add my 2 cents.

With so many people concerned about data privacy and the over-reach of the big tech platforms, one of the strongest benefits of Obsidian is that you own your data… so if it’s not secure that seems to undermine your community plugin approach for the vast majority of users that just want plug-and-play solutions.

At the least, a user guide (in plain and simple, non-technical English) to ‘staying safe’ on Obsidian (and the risks/mitigation options) for non-tech-savvy Obsidian users like me would be a fall-back for now. This should be incorporated as a topic in Obsidian Help. For example, could you rate the security risks of community plugins? Or make transparent somehow what data a plugin is using, and why (eg via an Obsidian-verified statement).

Speaking personally, until I understand the risks it pains me to say that I will not be using any community plugins. Which is a real pain.

2 Likes
#80

This is quite a long thread but if you spend time reading the initial posts it is explained that in the current framework it is not possible to provide the assessment or guarantees that you are asking (not for a lack of will).

2 Likes
#81

Thanks for the response. Yes I had seen some prior similar responses, but I still think some help for users to understand the risks could usefully be included in the Help - rather than leaving the information buried in a long thread like this.

Have any of the YouTube channels covering Obsidian made any videos related to security that might help me investigate further?

I do understand there are technical limitations, and that Obsidian has chosen a certain development path, but as you know online fraud, malware and data theft is a very real issue of concern to many people.

2 Likes
#82

There is a pretty clear statement about risks when you disable safe mode.

#83

Which is why I didn’t. My points still stand.

1 Like
#84

Which points?

What more information is needed to understand the risks of the message when you disable safe mode and what is continued here https://help.obsidian.md/Advanced+topics/Community+plugins#Plugin+security?

you can contribute to the docs here: https://github.com/obsidianmd/obsidian-docs

2 Likes
#85

Okay, thanks. I imagine you’re referring to this from your link (which I’ve seen already, along with the ‘safety’ tab):

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.

The good news is that Obsidian has an amazing and passionate community, so we rely on community trust to ensure security of community plugins.

I came to Obsidian, and this forum, for that amazing community. But I respectfully, and politely, disagree that trust is the solution to security.

Please understand, that I get that the app is free. I hope you also understand that not everyone who is using Obsidian is here just because it’s free. Personally I came because I’d heard about that amazing community, from SweetSetup and others, and thought it was a neat solution. My disappointment in the security gaps is therefore coming from a place of loving the Obsidian concept, not a place of trying to be difficult.

1 Like
#86

That is completely valid position to hold.

Since you were claiming that there is a lack of transparency about plugin risks in the app/docs, I was just trying to what exactly are you referring to and what more should we add. What is buried in this thread that is not covered at high level in the app/docs?

2 Likes
#87

Could I ask if I’m understanding this correctly, specifically how turning off Safe Mode works? I searched but didn’t find the answer.

Turning off Safe Mode, I presume, doesn’t automatically turn on all community plugins? Is the process similar to Core Plugins, where one can turn on/off plugins? So, if I turn off Safe Mode, I now get access to (a list of) community plugins. I can then choose to turn on a specific plugin? So I’m accepting the risk of that one plugin, not all plugins?

Thanks for your clarification. :slight_smile:

#88

Yes. Mostly.
Turning off safe mode gives you access, and you can download the individual plugins you choose.
There’s a further switch where you can turn individual plugins on or off.

3 Likes
#89

Thanks, Dor, that’s very helpful to know.

FWIW, since the warning about plugins is general, I understood this as signaling that just turning off Safe Mode would open a kind of Pandora’s box. Would it be useful to rephrase, or add a phrase like (additions in italics):

Turning off Safe Mode allows you to download and turn on/off plugins created by community members.

Community plugins can access files on your computer, connect the internet, and even install additional programs. They can also be faulty and cause data corruption or data loss. [? Possibly add: See [link] for guides on how to evaluate the safety of third-party plugins.]

Would you like to disable Safe Mode to allow access to these third-party plugs? Before downloading and activating any third-party plugin, make sure you have set up backups of your vault in case plugs malfunction and wipe your notes.

(My ex-technical writer hat is rusty…still thinking (if it’s helpful).)

Mozilla has a nice article (on evaluating the safety of Firefox extensions) that could be a useful model for addressing this question of Obsidian plugins safety. The link could be offered as a general of guide for how to think about evaluating third-party plugins or extensions. (Obviously, Mozilla has a lot more resources for vetting extension safety.)

Thanks again.

2 Likes