Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of Obsidian Plugins

obsidian.md

Post reply on HN
Print view View original

101–110 of 186 posts

Re: The Future of Obsidian Plugins

#101

Post by nickjj »

andai wrote: post #26
varun_ch wrote: post #2

I’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.

>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, Obs…

> But if it can't talk to the internet, I kind of don't see the issue.

No internet access doesn't save you.

With file system access it can delete a file.

Without sudo access it can silently add something to your user's crontab so a few days from now it runs a custom shell script that does anything with internet access. If you're not checking into this sort of thing regularly, you wouldn't know.

It can add something to your user's shell's rc so when you open a new terminal session, a bad side effect happens.

Malware scanning won't protect from these sort of things and every time a new version is available, it's another opportunity for something bad to happen.

To be fair this isn't a problem unique to Obsidian. Code editor plugins and most programming language package managers have the same problem.

Re: The Future of Obsidian Plugins

#102

Post by subscribed »

zie wrote: post #92
kepano wrote: post #30

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 on…

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

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.

Re: The Future of Obsidian Plugins

#103

Post by tyler-dot-earth »

soupfordummies wrote: post #36
dtkav wrote: post #13

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.

Got any cool plugins you recommend? I'm finally getting comfortable after switching from OneNote and getting sync set up.

i made an Obsidian plugin to search and embed blocks with ^block-references (aka ^block-ids) if that sounds handy for you:

https://github.com/tyler-dot-earth/obsidian-blockreffer

Re: The Future of Obsidian Plugins

#104

Post by kid64 »

kepano wrote: post #98
kid64 wrote: post #89

Earlier quoted context omitted.

In what universe is it trusted? This blog post is an admission that they've been lying to their userbase about their review process for years, with updates receiving no review whatsoever. Enjoy your mass exfiltration.

Huh? The old review process has always been well-documented and occurred via PRs on GitHub completely in the open. It was a known limitation and something that we set out to revamp with the new system. From the docs: > The Obsidian team is small and unable to manually review every new release of community plugins. Instead, we rely on the help of the community to identify and report issues with plugins. https://github…

I realize you're just doing your job as CEO to shape perceptions here, but this is your best effort? The docs should have correctly stated "we don't review ANY new community plugin release". Hint: This is where you would admit the review process itself was meaningless theater intended to provide a false sense of security to users that trusted you.

Re: The Future of Obsidian Plugins

#105

Post by zie »

subscribed wrote: post #102
zie wrote: post #92

Earlier quoted context omitted.

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

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.

Yes, for sure. More context is a bonus. like clicking a link takes you to the code that calls out to github.com. Or for some sites like github, instead of just showing the domain, it shows the repo in question or it's a gist or something it says whoa nelly! and marks it questionable, etc.

But already they have a great start here.

Re: The Future of Obsidian Plugins

#106

Post by kepano »

subscribed wrote: post #100
kepano wrote: post #69

Earlier quoted context omitted.

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 princip…

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,…

That's effectively how the new system works. We just need to add filters so users can choose their preferred level of strictness.

Re: The Future of Obsidian Plugins

#107

Post by zie »

trvz wrote: post #96
zie wrote: post #92

Earlier quoted context omitted.

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

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.

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.

Re: The Future of Obsidian Plugins

#108

Post by kepano »

kid64 wrote: post #104
kepano wrote: post #98

Earlier quoted context omitted.

Huh? The old review process has always been well-documented and occurred via PRs on GitHub completely in the open. It was a known limitation and something that we set out to revamp with the new system. From the docs: > The Obsidian team is small and unable to manually review every new release of community plugins. Instead, we rely on the help of the community to identify and report issues with plugins. https://github…

I realize you're just doing your job as CEO to shape perceptions here, but this is your best effort? The docs should have correctly stated "we don't review ANY new community plugin release". Hint: This is where you would admit the review process itself was meaningless theater intended to provide a false sense of security to users that trusted you.

That would not have been accurate though.

Re: The Future of Obsidian Plugins

#109

Post by aucisson_masque »

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

Post reply on HN