The Future of Obsidian Plugins
obsidian.md
The Future of Obsidian Plugins
1–10 of 186 posts
Re: The Future of Obsidian Plugins
#2I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious.
I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
Re: The Future of Obsidian Plugins
#3I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious. I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
Obviously this wouldn’t be compatible with existing plugins, so I’d separate legacy plugins and new plugins, and add a lot of friction to install the legacy plugins, which will be deprecated at some point.
Re: The Future of Obsidian Plugins
#4I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious. I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
Read through the blog post. A permissions system is planned in addition to the automated scans and more controls for teams.
All are necessary because permissions alone can't solve certain malicious behaviors. Look at some scorecards on the Community site you'll quickly see why some of the warnings are not things a permissions system or sandboxing could catch.
The blog post contains details about the rollout, but it will be a phased approach because it requires changes to the plugin API.
Re: The Future of Obsidian Plugins
#5I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious. I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
Podman/Linux has an API with a permission system and we still god Copy Fail: https://garrido.io/notes/podman-rootless-containers-copy-fai...
Security and authorization is just hard and at one point if you are designing a platform you have to ask yourself if it's worth the risk for the sake of flexibility. To plan for a perfectly safe system is a hopeless proposition.
Re: The Future of Obsidian Plugins
#6I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious. I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
Read through the blog post. A permissions system is planned in addition to the automated scans and more controls for teams. All are necessary because permissions alone can't solve certain malicious behaviors. Look at some scorecards on the Community site you'll quickly see why some of the warnings are not things a permissions system or sandboxing could catch. The blog post contains details about the rollout, but it w…
> A permissions system is planned
I'm not sure that "Plugins will declare what they access" should be interpreted as a planned sandbox system. My (cynic) interpretation that it's an opt-in honor system, that would give a good overview about well-maintained plugins, but doesn't do anything to restrict undesired API access by malware.
Re: The Future of Obsidian Plugins
#7I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious. I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
IMO this is an outdated view. Existing developer platforms have had to rely on static heuristics and capability-based permission systems, but now AI can run at scale and surface a lot of user-unfriendly intent that wasn't possible before.
The permission system are definitely useful for hard limits - but AI review can surface way more detail (what kinds of things are actually sent over the network, etc).
Re: The Future of Obsidian Plugins
#8I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious. I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
It doesn't do anything about first-party malware, but it can help a lot in gauging how dependencies are kept up-to-date and whether they contain any known CVEs, e.g. the same way that e.g. Trivy does and Artifacthub highlights.
I am curious how well this works out in practice for the ecosystem, though. In my experience blanket scans have a good chance to produce false-positives (= CVE exists but doesn't apply to the context it's used in), so the scans need some know-how to interpret correctly, which can lead to a lot of maintainer churn.
Re: The Future of Obsidian Plugins
#9I’m not convinced that automated checks will be able to reliably assess whether a plugin is malicious. I think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
Read through the blog post. A permissions system is planned in addition to the automated scans and more controls for teams. All are necessary because permissions alone can't solve certain malicious behaviors. Look at some scorecards on the Community site you'll quickly see why some of the warnings are not things a permissions system or sandboxing could catch. The blog post contains details about the rollout, but it w…
Hey kepano - can you please grandfather in existing plugin IDs?
Forcing a migration seems really user-unfriendly unless there's a symlink or something.
We have a "caution" score because our plugin (system3-relay) has a 3 in it (part of our business name), and we have thousands of daily active users that would need to essentially download a new plugin if we change it.
Re: The Future of Obsidian Plugins
#10Earlier quoted context omitted.
Read through the blog post. A permissions system is planned in addition to the automated scans and more controls for teams. All are necessary because permissions alone can't solve certain malicious behaviors. Look at some scorecards on the Community site you'll quickly see why some of the warnings are not things a permissions system or sandboxing could catch. The blog post contains details about the rollout, but it w…
> A permissions system is planned I'm not sure that "Plugins will declare what they access" should be interpreted as a planned sandbox system. My (cynic) interpretation that it's an opt-in honor system, that would give a good overview about well-maintained plugins, but doesn't do anything to restrict undesired API access by malware.
We haven't shared anything about sandboxing yet. Yes, to start disclosures will be opt-in because we have to help thousands of developers with existing plugins migrate.
However, a permissions system alone is not enough. For example if a user allows a plugin with network connections, it would be easy for a plugin to abuse that permission. That's why scanning the code is still necessary to give users trust in the plugin.
Take a look at scorecards on the Community site, you'll see why some issues are not something a permissions system or sandboxing could catch.