alt Hacker NewsObsidian 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 :)
Replies
I have a bunch of projects with plugins and I've sometimes thought about introducing a "reviewed" mechanism where the project marks specific versions as reviewed and trusted.
One of the things that's held me back (aside from the huge time commitment) is my fear that people will come to depend on that review process, such that if the process misses an obfuscated exploit the project itself will be blamed for the subsequent attacks.
How are you thinking about that?
To me it feels like the difference between the Debian/Ubuntu approach - everything in their registry is tightly reviewed - and the PyPI/npm approach where there's no review guarantees at all.
I love that under disclosures "Plugin might make requests to 1 external domain", if you click on it, it shows the domain: "github.com". great work!
Example from https://community.obsidian.md/plugins/zotlit
Congrats on the launch! Curious about whether the automated scanning system flags expansions of scope and network domain access for internal/human review.
For instance, an AI summarization plugin that starts by saying it accesses url="api.openai.com"+path with a user-supplied OpenAI key is going to be incredibly common - and I'm really excited for what the community builds here!
But what if that plugin has an update that allows the "user" to choose an arbitrary endpoint as an OpenAI-compatible API - how do you ensure that's not a malicious update that has coopted that flexibility to create a network egress that will bypass your scans, and might subtly prefill that with a malicious endpoint?
Fantastic work from the Obsidian team! I'll gladly continue to be a Obsidian Sync user and can't wait to feel more comfortable using community plugins. Seriously excellent work from y'all.
This is fantastic news. Just a few days ago I mentioned [1] the Obsidian Community Plugins model was broken and needed an overhaul. This is a step in the right direction.
If I may, two suggestions:
1) Allow the user to filter for plugins based on the desired level of strictness (manually reviewed, safety rating, etc).
2) The Disclosures seems a bit too lenient. For example, the popular Templater plugin [2] gets a 92 rating, with Excellent Health and Satisfactory review. But the disclosures are pretty concerning: dynamic code execution, network calls, wasm blobs, malware scan not available, etc.
I know it's tricky to boil this down to a single numerical score that works for everyone, but I think the bar needs to be higher than this. And Plugin developers should be held to a higher standard (e.g. don't use eval()) or at least thoroughly document why you need it.
[1] https://news.ycombinator.com/item?id=48089793
[2] https://community.obsidian.md/plugins/templater-obsidian
Nice! It was pretty easy to take my extension[1] from a middling Health and Review score to in the green. The obsidian eslint extension is helpful.
Do you plan to integrate the new web interface into the app? I would like to see which plugins I've already installed in the new interface.
Thanks for the greatness!
Finally!
When i tried obsidian and discoverd that the data table thing was not build in but some plugin which has full access, i deleted Obsidian quickly after.
But you are only 7 people? Crazy :D
Awesome!! Super excited to try this out. Amazing work.
One thing that I think would be a huge boon that I didn't see mentioned in the article is permissions.
Basically a plugin would need to request and receive permission to use APIs from the user. Wanna write to disk? Ask the user for disk permissions(preferably limited to certain paths). Wanna phone home? User has to approve that permission upon install(or first usage or whatever)
Kinda like how Android manages permissions (maybe iOS too?I dunno I don't use it)
That's probably a bit of work, but it would make me feel a lot safer about plugins if you could make it happen!
Edit: wait I just realised that the "disclosure" part might actually be this, and I just got confused by the terminology used? I don't think it's entirely clear from the text if a plugin could technically use capabilities without disclosing them? Hopefully they can't, and then that's good enough, I think.