Security of the plugins

Thanks for analysis!

  • The biggest and most easy to close security holes should be closed
  • “Less critical” ways should be monitored by Obsidian (here I think is easy to monitor what potentially dangerous classes the plugin is executing)
  • It will be nice to find some smart way (fully automated) to utilize this output of this “classes / function monitoring”) and present this simple 1,2,3 text showing what the plugin can potentially do (based on classes / functions used)

  • When Plugin is using “potenionally” insecure classes / functions (you list them above) the plugin can be installed only when user will explicitly grant the access and he is aware of the risks (this should be managed by “plugin market” installation process of plugin
  • By restricting some ways you have mentioned above you will have more “control” as side effect. Since the way how plugins will be written, the classes they will use will be more uniformed, as there will be not many ways to archive what the developer of the plugin want.
  • The list of good practices when writing of plugin should be created by devs

Believe me the plugin market will be huge - in future with paid plugins. The plugins will be one of the main strength of the Obsidian, as it can enhance the functionality of Obsidian exponentially…

  • without hight quality plugins
  • ensuring best practices when writing them
  • and some restrictions and in-build security aspects in API some plugin

Can really shade bad image of Obsidian…you know the internet and average user…

Don’t neglect the Plugins it can turn to one of your sources of funding…
Just look at Apple store, Google play store… this is gold mine for Apple and Google now

1 Like

Thanks for the suggestion. We’ll try our best to keep everyone safe!


Here are some important take aways for me:

  1. Using Obsidian is optional
  2. Obsidian is currently free. Rewarding the developers is optional
  3. Installing plugins is optional

I want to say that I’m in awe @Licat and @Silver at the quality of what you are creating and the pace of your development. I get that you are trying to create a safe and awesome project. I’m grateful and I’m using Obsidian all day long, every day!


Totally agree. I was just throwing out a suggestion, but honestly i think it’s not worth the effort at this point. You’ll be pluging a bunch of holes “hoping” to guarentee security, but as any security professional knows, having an informed the user is the best defence.

The more scalable solution is to have a community-inspectable repository for non-official plugins. Open-source will make it easier to inspect for security holes. In the future, maybe a paid model will work but it’s way too much work to do that now.

I took a cursory look at the electron security guidance and it seems like there are basic controls for protecting the main application but nothing about plugins. (Not sure i fully understand it though.) I’m a c++, data, ml, devops person lol

If I understand the issue correctly, it would very misleading to provide such information, because it’s impossible to properly detect all the cases when the plugin has access to something.

And if you try to detect just some cases, this will lure users in the false sense of security: “oh, it says it can access only these, I’m fine”. We can argue about it, but I would prefer the application to honestly say “sorry, we have no idea what that plugin can do”, than try to guess and fail.

On the other hand, pure social features like comments and ratings are good suggestions that would help a lot (though, even they are not without possible hacks).


@ryanjamurphy I think you’re exactly right. The social aspect of it along with the fact that plugin source code (since I believe it is not compiled) to be always “readable” by the community members that do understand the code will probably allow the community to sniff things out.

I think its a good rule of thumb for non-coders like me to not install any plugin unless you see some kind of endorsement (aka a 10+ like count) from forum members amongst whom someone is bound to understand the code