5 ms·

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

by kepano 5mo ago

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

jjice 5mo ago
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.
btown 5mo ago
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?
- kepano 5mo ago
  Every update is scanned, and we will be regularly re-scanning all the latest versions of every plugin as we improve the system. The review system is based on our eslint plugin which itself open source and reproducible, so anyone can contribute to improving it: https://github.com/obsidianmd/eslint-plugin https://github.com/obsidianmd/eslint-plugin And since plugins are open source, users can also audit the code and flag issues via the Community site.
  - chrisweekly 5mo ago
    Longtime (early adopter) Obsidian user here. Thank you for such an amazing tool. And congrats on the launch! Curious if you considered oxlint^1? (It's a a faster, simpler, near drop-in replacement for eslint.) 1. https://oxc.rs/docs/guide/usage/linter.html https://oxc.rs/docs/guide/usage/linter.html
    - kepano 5mo ago
      It's the first I am hearing about it, but I'll take a look!
  - btown 5mo ago
    That's very cool - using a linter as a standardization system removes a lot of the guesswork out of submitting! But it's an unenviable challenge to guard against bad actors here - there's now an open-source oracle that an attacker could use to see if their technique would sneak by the review process, and they can have a coding agent iterate until successful. I might encourage adding things like https://ofriperetz.dev/articles/eslint-plugin-security-is-unmaintained-heres-what-nobody-tells-you-96h https://ofriperetz.dev/articles/eslint-plugin-security-is-un... or https://github.com/mozilla/eslint-plugin-no-unsanitized https://github.com/mozilla/eslint-plugin-no-unsanitized as things that flag for further review - and likely adding even more that you might not publicize as part of the eslint-plugin repository, so there's a more obscure level of protection that might catch a would-be attacker!
    - joethei 5mo ago
      The system consists of a few different parts, the linter is only one part and is responsible for surfacing issues to the dev during development. We have additional checks that also check the release assets to catch issues in dependencies etc, that part is not public.
simonw 5mo ago
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.
- kepano 5mo ago
  I can't speak for other platforms but neither option you propose seems right for Obsidian. I think the right approach for us is somewhere in between. If we were too controlling there wouldn't be the freedom of exploration that we see in the Obsidian community. There are so many niche use cases. Plugins can target a minuscule number of users, and that's a great thing. That's why malleability is one of our core principles: https://obsidian.md/about https://obsidian.md/about I also believe in treating users with intelligence. Obsidian has always skewed towards giving you the maximum freedom at the cost of letting you shoot yourself in the foot. It's impossible to guarantee that software has no bugs and no vulnerabilities, especially not third-party plugins. However that doesn't mean that we shouldn't try to detect dangerous or malicious behaviors. Any transparency we can provide in this regard seems helpful if it can be presented in a way that helps users make their own informed decisions.
  - simonw 5mo ago
    Thanks. I think it's likely I'm seeing this as a binary situation when actually it doesn't need to be that way.
  - deleted 5mo ago
    [deleted]
  - subscribed 5mo ago
    Why not both? Have the reviewed / approved plug-ins in the directory, whatever that's not a wild west free-for-all-malware, then have two other levels, alpha channel (submitted) and beta channel (machine-reviewed only, not yet approved). Display only the main channel by default, but make it easy for the user to click through the earning(s) and indemnity message, and enable either of these two. So I could have stable, slow moving, sanitised plug-ins, but someone else could instantaneously get access to the most recent ones.
sneilan1 5mo ago
Awesome!! Super excited to try this out. Amazing work.
AntiUSAbah 5mo ago
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
- obsidianbases1 5mo ago
  Obsidian Bases are built-in data tables.
  - AntiUSAbah 5mo ago
    Wow true since last year of may.
zie 5mo ago
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 https://community.obsidian.md/plugins/zotlit
- trvz 5mo ago
  I'd say that may be as harmful as it is helpful. Amateur users may have heard of Github and would therefore trust that domain, but you can upload malware to Github just as easily as anything else.
  - zie 5mo ago
    Yes, a bonus would be more context, but already this can show stuff you know you don't want. If you see doubleclick.net for instance you know it will be ad-ridden disasters, or whatever. With just the domain, you can search the code repo and see exactly where it's calling github.com to see what exactly it's trying to reach on github. So it gives you an easy place to track down what's going on. An extra bonus would be clicking on github.com and it would link to the line in the file that makes the github.com call. Clearly they aren't done covering all the bases, but I think this is a great start! Way more than I expected to be honest.
    - joethei 5mo ago
      Ads / telemetry are disallowed completely, as per our developer policies. So plugins that have those domains in the code will not be available from the site / app.
      - zie 5mo ago
        <3
- subscribed 5mo ago
  Which is brilliant...... Especially if we remember how easy is to host a (malicious) script on github :) But yes, great work indeed. It finally makes me want to move over to Obsidian.
amarant 5mo ago
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.
- kepano 5mo ago
  Yes they are mentioned in the blog post in the bullet point about disclosures. You can think of disclosures as the first step towards permissions. See my previous answer here: https://news.ycombinator.com/item?id=48110592 https://news.ycombinator.com/item?id=48110592
- cma 5mo ago
  Google has been very careful not to add an internet permission on Android, even though things like flashlight apps shouldn't have needed internet. Google is an internet ad company.
  - SchemaLoad 5mo ago
    I'm fairly sure Android used to have an internet permission back in the early days. But then basically every single app requested it so the utility was diluted. Then they switched away from a static list of permissions and more to a ask for permission at the time of use model. The old permissions model was always a bit of an illusion of choice. The app presented a massive list of permissions and you could take it or leave it. But when every app asks for every permission you don't really get a choice and just had to accept it. The new model where you can install an app and then reject it's permissions is much better.
ninjamar 5mo ago
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!
guiambros 5mo ago
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 https://news.ycombinator.com/item?id=48089793 [2] https://community.obsidian.md/plugins/templater-obsidian https://community.obsidian.md/plugins/templater-obsidian
- kepano 5mo ago
  1) Yes. Working on it. (You can already partially do this e.g. ?score=90) 2) Yes. You will see these radically improve over the next few weeks. As stated on the scorecard itself they are a work in progress. You have to consider that overnight we intentionally exposed tens of thousands of warning messages across thousands of plugins, so there will be false positive, false negatives, and severity tweaks as we gather feedback from the community. But I expect these to get sorted out fairly quickly!
  - guiambros 5mo ago
    This is awesome news. Thank you for the great work, and being so open to suggestions from the community. That's what makes Obsidian a world apart from all its competitors and predecessors.
joeriddles 5mo ago
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. [1] https://github.com/joeriddles/extended-task-lists https://github.com/joeriddles/extended-task-lists
- dSebastien 5mo ago
  Same, very cool DX. A Markdown report of issues would be nice to have though to save a few tokens ^^
uncSoft 5mo ago
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.
adityamwagh 5mo ago
Hey man! Would it be possible for you to release a webapp version of Obsidian?
joshspankit 5mo ago
A bit of UI/UX sand: Store the scroll position when navigating the list. User clicks on a project, views the details and returns to the same position in the list (including all the expansions via “Show more”)

by kepano 5mo ago

jjice 5mo ago

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.

btown 5mo ago

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?

kepano 5mo ago
Every update is scanned, and we will be regularly re-scanning all the latest versions of every plugin as we improve the system. The review system is based on our eslint plugin which itself open source and reproducible, so anyone can contribute to improving it: https://github.com/obsidianmd/eslint-plugin https://github.com/obsidianmd/eslint-plugin And since plugins are open source, users can also audit the code and flag issues via the Community site.
- chrisweekly 5mo ago
  Longtime (early adopter) Obsidian user here. Thank you for such an amazing tool. And congrats on the launch! Curious if you considered oxlint^1? (It's a a faster, simpler, near drop-in replacement for eslint.) 1. https://oxc.rs/docs/guide/usage/linter.html https://oxc.rs/docs/guide/usage/linter.html
  - kepano 5mo ago
    It's the first I am hearing about it, but I'll take a look!
- btown 5mo ago
  That's very cool - using a linter as a standardization system removes a lot of the guesswork out of submitting! But it's an unenviable challenge to guard against bad actors here - there's now an open-source oracle that an attacker could use to see if their technique would sneak by the review process, and they can have a coding agent iterate until successful. I might encourage adding things like https://ofriperetz.dev/articles/eslint-plugin-security-is-unmaintained-heres-what-nobody-tells-you-96h https://ofriperetz.dev/articles/eslint-plugin-security-is-un... or https://github.com/mozilla/eslint-plugin-no-unsanitized https://github.com/mozilla/eslint-plugin-no-unsanitized as things that flag for further review - and likely adding even more that you might not publicize as part of the eslint-plugin repository, so there's a more obscure level of protection that might catch a would-be attacker!
  - joethei 5mo ago
    The system consists of a few different parts, the linter is only one part and is responsible for surfacing issues to the dev during development. We have additional checks that also check the release assets to catch issues in dependencies etc, that part is not public.

simonw 5mo ago

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.

kepano 5mo ago
I can't speak for other platforms but neither option you propose seems right for Obsidian. I think the right approach for us is somewhere in between. If we were too controlling there wouldn't be the freedom of exploration that we see in the Obsidian community. There are so many niche use cases. Plugins can target a minuscule number of users, and that's a great thing. That's why malleability is one of our core principles: https://obsidian.md/about https://obsidian.md/about I also believe in treating users with intelligence. Obsidian has always skewed towards giving you the maximum freedom at the cost of letting you shoot yourself in the foot. It's impossible to guarantee that software has no bugs and no vulnerabilities, especially not third-party plugins. However that doesn't mean that we shouldn't try to detect dangerous or malicious behaviors. Any transparency we can provide in this regard seems helpful if it can be presented in a way that helps users make their own informed decisions.
- simonw 5mo ago
  Thanks. I think it's likely I'm seeing this as a binary situation when actually it doesn't need to be that way.
- deleted 5mo ago
  [deleted]
- subscribed 5mo ago
  Why not both? Have the reviewed / approved plug-ins in the directory, whatever that's not a wild west free-for-all-malware, then have two other levels, alpha channel (submitted) and beta channel (machine-reviewed only, not yet approved). Display only the main channel by default, but make it easy for the user to click through the earning(s) and indemnity message, and enable either of these two. So I could have stable, slow moving, sanitised plug-ins, but someone else could instantaneously get access to the most recent ones.

sneilan1 5mo ago

Awesome!! Super excited to try this out. Amazing work.

AntiUSAbah 5mo ago

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

obsidianbases1 5mo ago
Obsidian Bases are built-in data tables.
- AntiUSAbah 5mo ago
  Wow true since last year of may.

zie 5mo ago

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 https://community.obsidian.md/plugins/zotlit

trvz 5mo ago
I'd say that may be as harmful as it is helpful. Amateur users may have heard of Github and would therefore trust that domain, but you can upload malware to Github just as easily as anything else.
- zie 5mo ago
  Yes, a bonus would be more context, but already this can show stuff you know you don't want. If you see doubleclick.net for instance you know it will be ad-ridden disasters, or whatever. With just the domain, you can search the code repo and see exactly where it's calling github.com to see what exactly it's trying to reach on github. So it gives you an easy place to track down what's going on. An extra bonus would be clicking on github.com and it would link to the line in the file that makes the github.com call. Clearly they aren't done covering all the bases, but I think this is a great start! Way more than I expected to be honest.
  - joethei 5mo ago
    Ads / telemetry are disallowed completely, as per our developer policies. So plugins that have those domains in the code will not be available from the site / app.
    - zie 5mo ago
      <3
subscribed 5mo ago
Which is brilliant...... Especially if we remember how easy is to host a (malicious) script on github :) But yes, great work indeed. It finally makes me want to move over to Obsidian.

amarant 5mo ago

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.

kepano 5mo ago
Yes they are mentioned in the blog post in the bullet point about disclosures. You can think of disclosures as the first step towards permissions. See my previous answer here: https://news.ycombinator.com/item?id=48110592 https://news.ycombinator.com/item?id=48110592
cma 5mo ago
Google has been very careful not to add an internet permission on Android, even though things like flashlight apps shouldn't have needed internet. Google is an internet ad company.
- SchemaLoad 5mo ago
  I'm fairly sure Android used to have an internet permission back in the early days. But then basically every single app requested it so the utility was diluted. Then they switched away from a static list of permissions and more to a ask for permission at the time of use model. The old permissions model was always a bit of an illusion of choice. The app presented a massive list of permissions and you could take it or leave it. But when every app asks for every permission you don't really get a choice and just had to accept it. The new model where you can install an app and then reject it's permissions is much better.

ninjamar 5mo ago

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!

guiambros 5mo ago

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 https://news.ycombinator.com/item?id=48089793 [2] https://community.obsidian.md/plugins/templater-obsidian https://community.obsidian.md/plugins/templater-obsidian

kepano 5mo ago
1) Yes. Working on it. (You can already partially do this e.g. ?score=90) 2) Yes. You will see these radically improve over the next few weeks. As stated on the scorecard itself they are a work in progress. You have to consider that overnight we intentionally exposed tens of thousands of warning messages across thousands of plugins, so there will be false positive, false negatives, and severity tweaks as we gather feedback from the community. But I expect these to get sorted out fairly quickly!
- guiambros 5mo ago
  This is awesome news. Thank you for the great work, and being so open to suggestions from the community. That's what makes Obsidian a world apart from all its competitors and predecessors.

joeriddles 5mo ago

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. [1] https://github.com/joeriddles/extended-task-lists https://github.com/joeriddles/extended-task-lists

dSebastien 5mo ago
Same, very cool DX. A Markdown report of issues would be nice to have though to save a few tokens ^^

uncSoft 5mo ago

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.

adityamwagh 5mo ago

Hey man! Would it be possible for you to release a webapp version of Obsidian?

joshspankit 5mo ago

A bit of UI/UX sand: Store the scroll position when navigating the list. User clicks on a project, views the details and returns to the same position in the list (including all the expansions via “Show more”)