#64

First, feature requests are prioritized in a very very fuzzy process. Popularity is important (as shown by demonstrated interest by users here on the forum). So is ease of implementation. So are a dozen or so other factors. The devs look at the forum, and so do us mods, in order to find interesting and valuable FRs. It is not a methodological process. Now, please keep on topic.

In terms of security reviewing: if you handle sensitive data in Obsidian and you do not have the skillset to review what a plugin is doing, consider either hiring someone to audit the code for you or not using the plugin.

As has already been discussed, it is impossible to offer a security guarantee on just one plugin, let alone at scale. More than a plugin a day has been published since Obsidian’s API was launched. Many of those plugins have been updated dozens of times. Reviewing each of those plugins and updates takes hours. The initial review is a quality review. It does not mean the plugin has been guaranteed to be safe and secure. It’s a cursory analysis to check for anything obvious, and to provide feedback to the plugin developers about how they might improve the plugin design/engineering.

Let me restate: it is impossible to offer a security guarantee on plugins. Please please stop beating this poor horse. What we have instead is a social system in which other users and developers are highly likely to notice and report nefarious behavior. But, if you are dealing with sensitive data, it is best to audit the code of plugins you’re using yourself, hire someone to audit for you, or not to use third-party plugins.

I encourage future contributions to this thread to advance the conversation beyond this focus. E.g., by…

  • suggesting ways of checking plugin security on the user side; or
  • suggesting and discussing models of resourcing so that a more robust reviewing mechanism could be offered.
4 Likes
#65

(1) (I added the numeral to the Quote) That gives me comfort.
(2) THAT, brings back to square one. Concern for ‘Security’.

#66

Thank you for your expansive explanation of the plugin ‘review’ process. It is most helpful. On the other hand, your statement……”please stop beating a dead horse”…is troublesome to me. I love the app, I appreciate ALL that the Devs do to provide me with a game changing app/workflow. Likewise, my hats off to the Mods for all they do. I personally don’t know of any other site/forum/app with this kind of participation or value. My purpose in posting is simply to gain whatever insight I can from people who certainly know more than I do. It is not my intention to be negative!

3 Likes
#67

Oh….and one more thing :wink:……is there some way to post your reply in a section of the Help Vault designed to explain Security. Hope this is not another example of me beating a dead horse.

1 Like
#68

I get that. In fact I don’t really take issue with your contributions here… it’s more @PietArt’s commentary that simply restated what we have already discussed at length in this thread.

Nonetheless this is an important conversation. Anyone working with Obsidian’s community plugins should be aware of the possible risks. Moreover, we should be finding ways to mitigate it.

The recent conversations in this thread made me think that there could be some kind of “verified”-type program for highly popular plugins where a group of developers and users vouch for the integrity of plugins in the program. I wonder what that could look like? It would still not provide a guarantee but could increase users’ confidence and trust of a subset of plugins.

I just really wanna get past people saying “this is important!!!” and get to “here are some ideas for how to make this situation better” (where those ideas are anchored in the realities of the situation, e.g., we can’t just review every plugin completely.)

2 Likes
#69

I get that. In fact I don’t really take issue with your contributions here… it’s more @PietArt’s commentary that simply restated what we have already discussed at length in this thread.

I’m sorry. It was not my intention to start the same discussion all over again. This thread is long. I am not a native English speaker, so it is a challenge to understand all the arguments in this discussion.

I posted (between the developers here) because I wanted to make a contribution from a user’s point of view. As a user, I cannot assess the risk of installing plugins. of course I can omit them. But on the other hand I’m glad that they exist. Many external developers (mods?) are doing a great job. But I would also like to find a way to minimize this risk - without having to do without plugins.

By the way, I am a designer and can assist with layouts or usability design. If desired. Not just to demand.

1 Like
#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