The Future of Obsidian Plugins
151–160 of 186 posts
Re: The Future of Obsidian Plugins
#152Earlier quoted context omitted.
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…
Re: The Future of Obsidian Plugins
#153Earlier quoted context omitted.
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 And since plugins are open source, users can also audit the code and flag issues via the Community site.
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…
We have additional checks that also check the release assets to catch issues in dependencies etc, that part is not public.
Re: The Future of Obsidian Plugins
#154What 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. Time someone builds a compatible clone.
Re: The Future of Obsidian Plugins
#155Earlier quoted context omitted.
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…
Stock Android has always classified internet as a "normal" permission that can't be toggled by the user. I think it still might have to be requested by the app, and you could see it in the app details, but it has always been auto-granted with no way to turn off.
Re: The Future of Obsidian Plugins
#156Earlier quoted context omitted.
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.
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…
Re: The Future of Obsidian Plugins
#157Most of the reviews are not required if this is enforced.
Re: The Future of Obsidian Plugins
#158Earlier quoted context omitted.
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…
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.
Re: The Future of Obsidian Plugins
#159Earlier 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.
No individual WiFi toggle!
Re: The Future of Obsidian Plugins
#160Obsidian 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…