#8

I’m not sure what’s unclear from my response - I would love to address this concern but there isn’t much we can do. Fundamentally, we’re a small team with limited resources - if Obsidian was a billion dollar company, then sure I’d love to throw a couple millions to hire security experts to come up with processes and manually review plugins. If you can provide that kind of funding then I’m sure we can find a way to make things work.

We don’t have as much control over the execution engine as browsers do. We also don’t have a team dedicated to writing an execution engine, and making it secure.

I think everyone will agree that we aren’t ignoring this. It’s a serious issue but it’s so far beyond our capabilities that I wouldn’t dare trying to create an illusion of security, which would be terribly irresponsible.

I think what we’re discussing here is akin to asking your local family doctor to cure cancer. Yes it’s a serious issue, and yes the doctor would love to help, but he does not have the necessary equipment, funding, or personnel to do such a thing even if it was possible.

20 Likes
#9

Nice, constructive idea. Thank you.

8 Likes
#10

A different angle: like literally everything else involving people, the plugin “market” will be a social system. Plugins that look or act fishy will be investigated, debated, discussed, and folks will have agency about whether or not they want to use them. Plugin developers will build reputations and we will trust in them.

I fully support anything that allows more powerful plugins to be built. It’s better to have more feature-rich plugins and give users the tools to understand what those plugins do, as a security-conscious user can always choose not to use something.

Naturally, I’d love more granular controls over what plugins can access what data, but I understand the balance that must be struck here. I think the best compromise is including as much information as possible on the plugin’s listing so that users can decide for themselves. Perhaps plugins can be tagged automatically if certain API features are used, or similar, to make this process a little independent of potentially-malicious developers.

(Aside: I am editing the title of this thread to remove the [⚠️ big user's concern]. I don’t think you can insist that this issue is more or less important than any other users’ issues, and theatrics like this make the forum messy. Should other users put multiple alarm/warning emojis in their thread titles to compete with this one? (Answer: no, please, gods, no.))

18 Likes
#11

There will always be that version, which is the one you download and install in the first place. For the core plugins (not third-party), we not only check each line of code – we write them ourselves.

10 Likes
#12

Thanks for the constructive ideas guys! As a few people noted, it’s a good discussion topic, and it’s definitely good to start thinking about and do something about it before 1.0.

We’ll provide easy ways to disable all third-party/community plugins for sure. We’ll also think about adding links to a plugin’s GitHub repo, so that you can inspect the code yourself. Developers and users are also welcome to report any potential security risks they find in third party plugins.

9 Likes
#13

Trivial “social” security task:

  • provide official chanel (like for themes) where plugin can by uploaded / linked
  • provide rating system with user comments
  • also add there Obsidian devs (distinguished from normal user) - they are users too, but let say more advances, so people may trust the plugin more if they are rate it hight or comment on it positively)
  • provide tab where it will be stated the plugin works offline / online
  • mandatory photo, and description for plugin
  • mandatory link to author and contact

This is just over reaction and not focusing on possible solutions… anyway the API should have security in mind…for example read only access…or also checking if Obsidian is communicating with other then (servers for themes, updates, etc…). Don’t tell me for these you need milion dollars and hundreds of DEV :smiley:

2 Likes
#14

As a suggestion, permissions may be a good way to handle this (akin to how gsuite extensions work). A plugin can request read/write access and the user has to accept the permissions model. Also internet access is probably something to request permissions from the user.

On the other hand, pretty much every open source tool with considerably more danger (bash shells, python, etc.) have this problem and no one cares. The user is responsible for what they feel is a trustworthy program/plugin. The simple answer is probably just to require that plugins are open sourced.

#15

Users should be able to choose closed source plugins if they want. It’s their data, their files, their computers, they should be able to make their own choices about acceptable risks.

8 Likes
#16

The problem is really this.
Within Electron, implementing (and enforcing) a permission model is either flat out impossible (no matter the resources you have) or, if possible, extremely challenging (more than building obsidian itself).

There is no way in electron to “containerize” the plugin code execution and allow communication only through some specific APIs. Once a code runs, it runs with access to everything like the main obsidian code.

This issue should be managed at the electron level. However, I would not be surprised to hear the answer from the electron devs: “We never intend to have segregated code execution in electron.”

2 Likes
#17

Please refer to my technical analysis from earlier on why this is impossible and only provides an illusion of security: Security of the plugins

2 Likes
#18

This is not possible?!

Please focus on suggestion of Trivial “social” security more.

1 Like
#19

It is not possible because there are many many many ways a plugin could connect to the internet:

  • By using the NodeJS http/https module
  • By using XMLHttpRequest browser API
  • By using the browser’s “fetch” API
  • By inserting an <image>, <audio>, <video>, and many other HTML elements containing a src property which will make the engine fetch a URL as if it’s some kind of resource
  • By inserting an <iframe>, opening a new BrowserWindow, etc, which can open any page on the internet
  • By adding a CSS property for background-image, font-family, etc which will fetch those resources at any URL.
  • By executing another executable on your computer using the child_process NodeJS module, such as wget.
  • By storing a script in an auto-run location such as .bash_rc, using the fs NodeJS module.
  • And many many more. Possibly hundreds of other methods that we are not even aware of.

This is a huge attack surface, while we can plug those holes one-by-one and cripple the ability of plugins to do useful work, you can’t take into account the unknown ways a malicious player will be able to exploit.

8 Likes
#20

For sure, a great list. I think you’ll see most of these in due time!

5 Likes
#21

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)

Screenshot 2020-10-26 at 08.25.46
Screenshot 2020-10-26 at 08.25.46400×544 23.8 KB

  • 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

3 Likes
#22

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

8 Likes
Is Obsidian connecting to Facebook?
#23

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!

43 Likes
#24

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

#25

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).

6 Likes
#26

@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

3 Likes
#27

Curious, has the community come to a consensus on 3rd-party plugins concerning security?

1 Like