#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
#28

Question of trust, I guess.

1 Like
#29

How do you mean? Many plugins have been developed and can be inspected on the community plugin gallery in-app or on Github. Some have 20k+ installs.

#30

Was just curious, as all the above discussions kinda just ended. So I just presumed it was “self code audit”. I personally don’t know any of the programming langs used with obsidian, therefor inspecting the plug-in code doesn’t work for me. :expressionless:

Just my two-cents on what might be the best balance:

Something simple as using gpg pki might be the “best bang for the buck” concerning the security and effort. Granted I wouldn’t really start this journey until a 1.0 release is closer to being scheduled. Maybe something like the following could work if the devs choose to go down that path.

  • Devs create a gpg key pair.
  • Plugin authors request a code audit of their plugin “Devs may require a fee for this.” There could be a path for providing a binary plugin, but that would require more effort and more money.
  • Once the plugin is vetted, a digest and gpg signature is created. The plugin is packaged “just an example” in that “asar” format and hosted on the devs plugin delivery system." Therefor we have a cryptographically authenticated “trust” plugin.
  • The Obsidian comes with the public key that can check signature of the digest to ensure that the plugin has not been modified. Possibly doing random checks through out.
  • Provide an option in the community plugins section to allow “vetted” 3rd-party plugins. (Maybe the mobile version of obsidian can provide an option for using the vetted plugins.)

(Honestly, the best option is to keep safe mode on, and have the devs cook in the features natively. Just keep with current “turn off safe-mode” option of prompting the user with a legal narrative about not holding the devs liable for any mishaps unintended or not)

1 Like
#31

I understand what you are proposing but I think you are missing the point here.

Here are the major points:

  1. The plugins can execute any code and are not just limited to Obsidian’s API. Plugins are more side-loaded applications. This is an electron limitation where there is no mechanism to contenarize some part of the code. (VScode has the same issue)
  2. We do not have time to look at the source code of every plugin
  3. Even if we looked at the code, there are a million+1 ways to obfuscate and sneek-in maliciuous code.
  4. Even if we looked at the code once, the plugin author can insert malicious code in a following update.

This is not a techical problem on how to sign plugins. And we don’t want to certify anything because this will give some users a sense of security that we know is not warranted.

We currently have in place one simple safeguard mechanism: if a plugin is known to cause problems, we can remotely disable it.

9 Likes
#32

I do not disagree at all and understand that it all boils down to “effort and time.” I believe the (clickwrap agreement) is the best “at the moment” option.

#33

I also think that while the number of installs and developer’s reputation and involvement in the community are important to gauge things, it should be understood that many people who are doing these installs have their computers locked down pretty well.

So for an average user who does not consider the implications of what could potentially happen, some of this sense of trust and consistency could be misleading.

I think it is cool that the developers and moderators are so upfront about this. It has really made me question my computer security practices, and that is always a good thing.

3 Likes
#34

Can remotely disable it? Wait… what? Can you elaborate on this a bit?

1 Like
#35

We maintain a plugin blacklist/deprecation list. Obsidian (tries to) download an updated version of this list every 12 hours.

8 Likes
#36

This seems like a good place to ask my question! And perhaps my participation will be a helpful contribution to this discussion just to give devs a better picture of the population of their user base, as well as their market potential from where their app currently stands in terms of security.

I’m a healthcare professional learning to use Obsidian on macOS to take notes for my newly formed private practice. I use mac’s native FileVault to encrypt my hard drive. I’m very new to Obsidian (and note-taking apps in general), and in addition to the obvious perks of the app, I really appreciate the local data storage, as macOS FileVault is actually HIPAA-compliant.

I’ve learned that plugins like macOS-keyboard-nav-obsidian are going to be important for my workflow as a Mac user, and so this is a plugin that I’d ideally like to use in all of my vaults, especially my vault chock-full of PHI.

So…

  1. Is safe mode a security vulnerability by itself? Or is it exclusively the plugins themselves which are potentially insecure? Perhaps if there is a way to easily use community plugins with safe mode off, it would feel safer. Earlier in this thread, I noticed that there might be a work-around to this, but perhaps an “offline plugins” option, if you will, within Obsidian itself would be a more user-friendly substitute.

  2. Does anybody know if Mac users who use FileVault to protect their hard drive are essentially “signing a waiver” to allow access to our data when we turn off safe mode or use a third-party plugin? Asking at a mostly layman-level understanding of data encryption.

1 Like
#37

I’m not sure about question number 2 (legal is outside of my arena) but to answer this one, it’s just the plugins you choose to use that could represent a potential threat.

If you really want to use a plugin, there’s ways of reducing the risk. The good thing about plugins is that they’re open source, so anyone can review what they’re doing. If possible, you may want to enlist someone you trust with knowledge of TypeScript (or JavaScript) to check out any you’re interested in. Some plugins are fairly simple, so this shouldn’t be too hard in those cases.

If I were to scrutinize a plugin, I’d be looking for anything on Licat’s list and anything that seems to be unrelated to the direct functions of the plugin.

I’m the dev of the keyboard nav plugin you mention, and it’s a good example. The actual code is only 63 lines. Anyone with knowledge of the aforementioned languages should be able to quickly tell that it isn’t doing anything remotely nefarious.

Still, this isn’t 100%. The only real way to be completely and totally secure with highly sensitive information is to stick to the methods you’re using already: locally encrypt your data and don’t expose it to uncertainties.

But, hey, at least I can vouch for the macOS alt keys plugin!

4 Likes
#38

Thank you! I appreciate your answer and that resource. Very helpful.

And whoops, I didn’t literally mean legal self-incrimination, I was making an analogy that I’m now realizing was misleading. Sorry about that.

I just mean: do locally-encrypted hard drives (like mine which uses the macOS native FileVault) offer meaningful security against third-party plugins and/or safe mode off in Obsidian? Would these elements hypothetically be able to “invade” a system protected by something like FileVault? Or do the plugins and safe mode bypass any hard drive encryption based on our implicit use of them? Maybe this is really a question for Apple? Haha!

Thanks again.

1 Like
#39

I don’t know the specifics of FileVault, but whole disk encryption means that the whole disk is unencrypted when the password is entered and everything is therefore exposed to any malware that is present.

2 Likes
#40

I don’t know for sure, but I think @Dor’s right. If the app is given unencrypted data, so too are the plugins. The vault is locked when it’s locked, but unlocked while the door is open, if that makes sense.

2 Likes