| I'm a programmer, I have zero fear of programmable tools, and it's a clumsy attempt to divert from my point to suggest I do. You're creating a false dichotomy. A well designed sandbox with accurate permissions is HOW a person "understands and accepts risks". A system whereby a plugin pinky-promises one thing, and then does another, precludes informed consent. Obsidian tacitly endorses this ecosystem because it is profitable for Obsidian to point to plugins for missing base functionality, and then throw up its hands and pretend like it's not their problem when something inevitably goes pear-shaped. That's how we end up with "warning screens" that in fact encourage the user to press "Yes". (And, as in the recent security incident, Obsidian then disclaims any responsibility when the user does click Yes, despite the heavy encouragement by Obsidian.) Not hard to see why a business would act this way - all profits are ours and all risks are someone else's - but spare me the faux moralising about software freedom. It is surreal to claim that a well defined sandbox with accurately described permissions is somehow against freedom. It would be a far more robust, trustworthy and empowering plugin ecosystem than the one Obsidian has now. > Obsidian is not for you Ooft. And a lot of other HN commenters and other tech-savvy users with my exact concerns, apparently. Somehow, most other software doesn't have this recurrent problem of mainlining third party malware to their users. See you at the next Obsidian "security incident", I guess? |
I don't think these two points should be particularly controversial:
1. Permissions are planned but they're not a panacea. Apps are sandboxed on iOS/Android, browser extensions have permissions, yet both can easily do dangerous things. Permissions suffer the same issue you described: all a user needs to do is press "Yes" to allow danger. If you care about making powerful software you inevitably must have some way for a user to say they "understand and accept the risks". The other option is to simply not let your software be powerful, which is not what I am interested in working on.
2. Analyzing plugin source code must be part of the overall solution not only for security, but also performance, reliability, ease-of-use, etc. How can you be against that? It makes absolutely no sense to me.
48 hours in, the new review system is already working. Hundreds of updates have been published by developers cleaning up their code and making their plugins safer in ways that a permission system would not catch. You can see that for yourself by looking at recent updates from the community: https://community.obsidian.md/search?type=plugin&sort=update...
As I have stated elsewhere many times, I'd be working on Obsidian even if I were the only user. That's why the app is free, we don't have investors, and we're okay staying small. The way plugins work is not motivated by money, it's a reflection of the kind of software we want to use.
It is fulfilling to see many people find value out of the app. People are creating many useful and interesting plugins I would have never imagined. Selfishly, I want to be able to use and trust those plugins just like anyone else. And that's the only motivation I need to work on the problem of plugin safety.
I understand you wish we had sandboxed plugins first, and built on top of it that way. But we didn't. Now we have been cursed with success and a large ecosystem that needs to be managed and transitioned. We will continue to chip away at the problem bit by bit. I don't think there's any other way to do it.