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.
>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.
I want to say "and especially prevent them from touching my private data (i.e. the whole point of Obsidian plugins being to read/write the documents)".
But if it can't talk to the internet, I kind of don't see the issue.
EDIT: Apparently due to how JS and Electron works, Obsidian plugins are just JS blobs that run in the global scope, and can read/write the whole filesystem (limited by user permissions) and make HTTP requests? Can someone confirm/deny this pls?
That's why I wrote cyberwriter, my company needs sandboxed apps because we work on sensitive data. Community plugins are too risky running with full system access
For those not aware, it has basically been impossible to submit new plugins due to the manual review (and how easy/fun it is to write a plugin with AI). The developer community was becoming increasingly frustrated, and the team was burning out under the load.
So congrats to the team! This relieves a huge scaling bottleneck. It has been really cool to see how y'all build and scale.
(slightly OT): Has anyone been able to replace Notion with Obsidian in a work/team context?
I find there's just enough missing things around collaboration/permissions/sharing that makes Obsidian a non-starter for work, even for the small team I have. Also seems it just feels a bit more "scary" for non-technical users to onboard onto on than Notion.
And if I can't use it for work, I'm not going to use it personally because I don't want to juggle multiple notetakers.
I imagine Obsidian is way more efficient for sharing context between you and agents and wish I could take advantage of that, but I also need to be sharing that context with my team
What I would like is that they made it easier to install plugins locally. Should really just be copy pasting into a folder. I would change it myself, were it not for the fact that Obsidian is proprietary software.
Obsidian CEO here. We've been working for nearly a year to launch this new Community site and review system. I'm very excited about this first version but there are many more improvements to come.
I've tried to be exhaustive with the blog post, FAQs, and next steps on our roadmap, but I am sure I forgot some things, so feel free to ask!
This has been an incredibly challenging project for a number of reasons. We're only seven people but we have thousands of plugin developers and millions of users. There are many competing priorities to balance.
We wanted to make sure the new system would be easy to adopt, backwards compatible, and not completely break people's workflows, while still being a major improvement over the old approach, and allow us to gradually continue enhancing security and discoverability of plugins.
Consider it a work in progress. We're listening to everyone's ideas and gripes, and will keep iterating :)
Obsidian is great- it motivated me to make cyberwriter, where the app is sandboxed and the top community plugins are baked in. I work in healthcare and we can't have unvetted community plugin updates running in our network with full system access and with sensitive data.
I want to use Obsidian... but I won't as long as it's not open source. I know I can keep all my files as plain text, but that's not enough for me. Using a KB on a daily basis shapes my workflows and having to change that from one day to another (e.g., because maybe Obsidian changes in a way I don't like) is too much for me. I could already handle all my plain txt files using simply the file system, but of course I would prefer a KB program. It's a shame because Obsidian looks great.
Very interesting. This is real-world proof that automated plugin reviews is doable for a small team. Sooner or later I'll have to learn how to implement a similar system for my own projects.
I think that plugins are an inherent risk, there is a pop up in obsidian warning the user before enabling them, and it's up to the user to agree or not.
In my opinion, what could have been done is kind of like what mozilla does where it will vet some of the most popular extensions, so that you know there is at least some kind of verification on these extension, and let everything else be wild.
I'm not sure that you can use a.i. to defeat a.i., if an ai is able to spot malware in a code, it can just as well hide it (from itself).
Why the iOS app so terrible? Is it a web app? I have couple plugins on desktop and it makes iOS app load something then I must press reload and again. It’s a terrible experience, how could this been released like that?
The thing I always wondered regarding obsidian plugins is how they are able to offer them on iOS, given that iOS has rules against downloading code that alters functionality of the software.
No permissions system, nothing resolved. Plugins still have access to everything - full disk, network, etc. How does one even speak of security vulnerabilities when the security model of Obsidian plugins is just straight up "click here for RCE".
All I see is a spanking new interface that will accelerate the pace of plugin turnover, bringing forward the next inevitable security incident.
I want an Obsidian where I can:
- Specify network requests on/off from plugins
- Don't allow file access outside the vault
- Don't allow external binary execution.
Most of the reviews are not required if this is enforced.
34 comments
[ 807 ms ] story [ 1191 ms ] threadI think the best (only?) way to solve the plugin security problem would be to properly sandbox them with an explicit API and permission system.
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.
The checks are a filter so they can apply manual review only to those plugins which pass the baseline (and automatable) requirements.
I want to say "and especially prevent them from touching my private data (i.e. the whole point of Obsidian plugins being to read/write the documents)".
But if it can't talk to the internet, I kind of don't see the issue.
EDIT: Apparently due to how JS and Electron works, Obsidian plugins are just JS blobs that run in the global scope, and can read/write the whole filesystem (limited by user permissions) and make HTTP requests? Can someone confirm/deny this pls?
So congrats to the team! This relieves a huge scaling bottleneck. It has been really cool to see how y'all build and scale.
I find there's just enough missing things around collaboration/permissions/sharing that makes Obsidian a non-starter for work, even for the small team I have. Also seems it just feels a bit more "scary" for non-technical users to onboard onto on than Notion.
And if I can't use it for work, I'm not going to use it personally because I don't want to juggle multiple notetakers.
I imagine Obsidian is way more efficient for sharing context between you and agents and wish I could take advantage of that, but I also need to be sharing that context with my team
Time someone builds a compatible clone.
Managing this sort of community contributions is a challenge. Looks like great progress
I've tried to be exhaustive with the blog post, FAQs, and next steps on our roadmap, but I am sure I forgot some things, so feel free to ask!
This has been an incredibly challenging project for a number of reasons. We're only seven people but we have thousands of plugin developers and millions of users. There are many competing priorities to balance.
We wanted to make sure the new system would be easy to adopt, backwards compatible, and not completely break people's workflows, while still being a major improvement over the old approach, and allow us to gradually continue enhancing security and discoverability of plugins.
Consider it a work in progress. We're listening to everyone's ideas and gripes, and will keep iterating :)
User clicks on a project, views the details and returns to the same position in the list (including all the expansions via “Show more”)
I wonder if there would be a role for AI for these automated reviews. Seems like a promising usecase for it.
What's the ideal flow on the user-end? Scorecard seems great on the developer side.
I've come to expect that "The Future Of XYZ" titles from software companies means severely limiting XYZ or preparing XYZ for a shut down!
In my opinion, what could have been done is kind of like what mozilla does where it will vet some of the most popular extensions, so that you know there is at least some kind of verification on these extension, and let everything else be wild.
I'm not sure that you can use a.i. to defeat a.i., if an ai is able to spot malware in a code, it can just as well hide it (from itself).
All I see is a spanking new interface that will accelerate the pace of plugin turnover, bringing forward the next inevitable security incident.
That's heavy handed. Why not allow the previous vetted version to be considered the plugin's latest version?
Most of the reviews are not required if this is enforced.