Thanks for analysis!
- The biggest and most easy to close security holes should be closed
- “Less critical” ways should be monitored by Obsidian (here I think is easy to monitor what potentially dangerous classes the plugin is executing)
- It will be nice to find some smart way (fully automated) to utilize this output of this “classes / function monitoring”) and present this simple 1,2,3 text showing what the plugin can potentially do (based on classes / functions used)
- When Plugin is using “potenionally” insecure classes / functions (you list them above) the plugin can be installed only when user will explicitly grant the access and he is aware of the risks (this should be managed by “plugin market” installation process of plugin
- By restricting some ways you have mentioned above you will have more “control” as side effect. Since the way how plugins will be written, the classes they will use will be more uniformed, as there will be not many ways to archive what the developer of the plugin want.
- The list of good practices when writing of plugin should be created by devs
Believe me the plugin market will be huge - in future with paid plugins. The plugins will be one of the main strength of the Obsidian, as it can enhance the functionality of Obsidian exponentially…
- without hight quality plugins
- ensuring best practices when writing them
- and some restrictions and in-build security aspects in API some plugin
Can really shade bad image of Obsidian…you know the internet and average user…
Don’t neglect the Plugins it can turn to one of your sources of funding…
Just look at Apple store, Google play store… this is gold mine for Apple and Google now