131–140 of 186 posts
Earlier quoted context omitted.
It seems like you have not read the blog post.
Just wanted to say a huge thankyou for being so patient in the forum; it's quite annoying that the comment section is a more a function of the title + personal opinions than a function of the blog content. I love using obsidian, and thanks so much for all the work that you and the team have put in :)
Earlier quoted context omitted.
We've been working on the project for nearly a year, so no. https://github.com/obsidianmd/eslint-plugin/commits/
Just say "I think my users are stupid" and be done with it. The timing of your announcement is obviously not a coincidence. You are genuinely terrible at this.
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.
It seems like you have not read the blog post.
Surely you're not about to claim that asking plugins to "disclose" what resources they use is in any way comparable to sandboxing and permissions.
Earlier quoted context omitted.
Just wanted to say a huge thankyou for being so patient in the forum; it's quite annoying that the comment section is a more a function of the title + personal opinions than a function of the blog content. I love using obsidian, and thanks so much for all the work that you and the team have put in :)
Thank you! It means a lot <3
Part of my frustration with this is that I've seen hobbyist video games with a more robust plugin security model than Obsidian's plugins. It's possible to do better than just "yolo, eval(github)", and I feel like it would thoroughly improve Obsidian for me, and apparently many others (judging by all these comments), if Obsidian invested in creating a secure plugin ecosystem rather than putting lipstick on the existing yolo plugin vortex.
Just because Obsidian is in JS, and JS has a terrible culture around package security, doesn't mean Obsidian needs to inherit and propagate that culture.
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…
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 permiss…
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…
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
Earlier quoted context omitted.
It seems like you have not read the blog post.
I have indeed read the blog post. Can you point out which part of my post is inaccurate? It is certainly possible I misunderstood something. Surely you're not about to claim that asking plugins to "disclose" what resources they use is in any way comparable to sandboxing and permissions.
Millions of people depend on thousands of Obsidian plugins. We cannot just flip a switch and break everyone's workflows overnight. It will be a gradual process. We're working on it, and I hope you'll at least concede that this is better than nothing.
Earlier quoted context omitted.
>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…
Theoretically in an Electron app, you could run plugins in a separate v8 context without the node native FS libraries available. Short of OS-level sandboxing that's probably the best they could do.
But almost all plugins would need to be rewritten?
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…
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…
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!
Earlier quoted context omitted.
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 permiss…
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.
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.