Security of the plugins

Developers & API
#1

Security
Security1000×600 206 KB

I don’t know if Obsidan dev have think about that, but when the Obsidian plugins will open to public there will be:

  • many noble developers
  • as well as many who want to take advantage of the user data.

As the core philosophy of Obsidian hovering around:

  • The user is in charge of his data
  • Data that are locally stored
  • User data are not stored on server or cloud
  • User data are processed locally
  • Obsidian works offline and locally

I can guarantee that there will be a huge amount of plugins & many that plugins will use advantage of non existing security check by Obsidian devs.

The Obsidian devs should ensure that privacy and security of the data will be not compromised by installing users plugins.

This cannot be outsource to the normal user…or simply just give warning: "this plugin may be security…bla bla… If the Obsidian should be secure database after releasing the plugins support, it is the Obsidan devs jobs to protect the users data. This can be archive in various way. Bear in mind that normal user have no option to check what the plugin is really doing! thus installing it is just matter of trust… this should be huge security concern for Obsidan devs. As I believe the Obsidian want to be around long time.

For this I’m writing some proposals:

  1. Official channel should be created with fixed template where developers can upload the plugins
  2. All other ways to install plugins should be closed (for now)
  3. Strict & mandatory information must be filled by developer (like image, compactibility, atd)
  4. Security checklist (made by obsidian devs) that developer must check what kind of access the plugin have
  5. Obsidian devs should have fully automated routine that will install the plugin when neew update to the app is made, and check if app can access: camera, read / write outside of vault, microphone access, atc…) - the devs should not really on information provided by developer regarding the security
  6. If the checklist made by developer and the information form security check by Obsidian script differ a lot, maybe even ban of the developer may be consider, as the developer concisely lie the user

Appsecurity
Appsecurity1300×1032 417 KB

  1. From “automated security audit” the PRIVACY SCORE should be generated
  2. Each update of the plugin the “automated security audit” should be executed and if something has change the PRIVACY SCORE should change accordingly.
  3. User can add comments to plugin

1. I would like to openly ask the devs what is your thoughts on this? and what is your 1,2,3 plan to ensure that Obsidian will be secure after the plugins support.

2. I would like to invite other users to discuss and add your other proposals regarding the security and plugins, we should find solution for this before the plugin support is released

11 Likes
Andy Matuschak mode - V2.7 (updated for 0.7+ new panes)
#2

I’d just like to make a note here that there is ABSOLUTELY NO SECURE WAY to run plugins without severely crippling the plugin API.

Electron by nature is insecure when 3rd party code is involved, and that we won’t even attempt to wrestle that beast. The only advice we can give is “only run code you absolutely trust and have self-audited to be secure for your use case”.

I’d like to add that even VSCode, a hugely popular IDE made by Microsoft, doesn’t have what you’re requesting.

5 Likes
#3

Here’s a technical analysis on why that’s not feasible:

  • Plugins should be able to execute Javascript code in the main execution context. While it is possible to attempt to sandbox the plugin script, it’s mostly pointless because there are probably a thousand Javascript context escape possibilities, and we can’t plug them one by one.
  • Because plugins must be able to execute code, there will be APIs available that we will be unable to restrict access to specific functionality like networking. An example would be the child_process NodeJS library, without which plugins won’t be able to run scripts, use git, etc. If that’s exposed then plugins could in theory do anything they want by executing the right programs.
  • There’s no way to “automatically” detect such things because the Javascript API is huge. There are many ways to “hide” code execution like eval, new Function(), etc. There’s a lot of potential places to exfil your data, for example, sneak the data into a URL for a font inside the CSS.
  • Manual reviews are impossible - not only because we don’t have enough time to review everyone’s plugin, but also because humans are fallible. A clever plugin maker can easily hide more code on a remote server that is inserted using some sneaky code we don’t understand well.
5 Likes
#4

Advice to users who may share the same concern:

We totally understand the concern, and trust me we totally want to address this too.

As with computer security, it’s all about managing your threat model. If you’re someone like Edward Snowden, then there’s no way you can even trust Obsidian the app itself. Top secret government agencies probably shouldn’t run arbitrary executables they download from the internet, or for that matter, even computer hardware they didn’t build themselves!

As a regular user though, it’s probably ok to buy hardware from Amazon, and download apps from the internet. You should treat downloading and running plugins from Obsidian the same as if you’re downloading it from the internet. Check if it’s from a reputable developer, see what other users has to say about it, and audit the source code yourself if you must.

If security is a top concern for you, then you should probably consider writing plugins yourself. We’ll make sure that it’s real easy to do so once the API is out.

9 Likes
#5

How are you addressing this consern? If you re-read your reply you are just writing what is not possible…

It is Obsidian job to check the permissions and capabilities of the plugin do this, not even more advanced user can check the plugin! not saying about the basic user…

You need to plan this when building the API. If Opera, Firefox, Chrome can show you what kind of permission the extension need and what can potentially access. I see no problem do it in Obsidian.

If you ignore this you are really throwing the trust of Obsidian.

This is not any argument to not do in Obsidian.

  • Argument that if user don’t trust the plugin he should not install it is silly
  • As well argument that to have trust user should write his own plugin…

This is begining of Obsidian, and you are responsible not just for the core app, but also for healthy and safe ecosystem, that will be created inside… plugins, paid plugins, etc…

#6

I really, really don’t want the time of the devs sidetracked into a wild goose chase after a level of security that will never be possible.

Undoubtedly there will be plugins that use a database, and maybe cloud storage. Users will have to decide whether they are happy to do this or not. Judging from requests and the popularity of Roam many will be.

Think of Apple’s approach. Total control of all hardware. High prices. Downloads through Apple Store with 30% to Apple. All largely underwritten by the insanely profitable iPhone. And still security holes emerge.

Obsidian will never be able to approach this level of security and it’s much more honest to say that Obsidian itself keeps data locally itself, that users have to be responsible for the security of their local files. And that they will have to make their own judgements about plugins.

And for the devs to spend their time developing mobile apps, wysiwyg and other core features.

11 Likes
#7

I guess the discussion is mainly on the 3rd-party plug-ins. And I think for the core plug-ins, there is no reason to put more attentions to the security aspect. Because, to be honest, even using Obsidian is at your own risk.

I think @den provides a good direction which needs to be discussed and addressed. But currently, there is no need to provide a quick conclusion with so little information available.

I think Obsidian may provide a clean version, which is decoupled with all 3rd-party plug-ins. Obsidian developers may need to do what ever they need to keep their reputation and make sure the plug-ins released with Obsidian are safe, may be by checking each line of the code.

And for the 3rd party plugins, I think requiring that all the 3rd party plugin to be open source software may be a possible way. The peer-review may be the only thing that every people can satisfy about. And as the last resort, if the plug-in is a open-source, you can always read the code by your own to make sure it is secure FOR YOU. Perhaps, a switch that can stop all the 3rd-party plugins it is the only thing that the Obsidian can provided to the end user.

And I think the paid service or solution mentioned by @Dor is another possible way. For people who has a strong concern about the security but unable to fulfill his requirement by himself, he has to pay something: his own efforts or something else, such as trust or money.

And for @Licat, I think what we want to do here is to making the discussion constructive. And for a valid concern or proposal, if it is not the proper time to address it, we can probably recorded it first and postpone the proposal until a specific time. The time may be after a release of a major function.

2 Likes
#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.

11 Likes
#9

Nice, constructive idea. Thank you.

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

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

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

4 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:

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

4 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.”

#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

#18

This is not possible?!

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

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

4 Likes
#20

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

1 Like