Hi, I was very enthusiastic about Silverbullet many month ago (still am), experimented a lot and really liked it, but haven’t followed the development due to some real life time restrains unfortunately. There were many awesome improvements since then. (big thanks to Zef and all developers)
Could someone bring me up to speed how plugs work nowadays? I’m kinda security concious when it comes to plugins for all sorts of apps. Is there some kind of permission model? For example I really like the implementation of the “TreeView plug”. Is it possible to restrict outgoing connections initiated by this plug? It needs access to all the knowledgebase data to work, but does not need to connect outside (compared to an AI plug which needs to connect to 3rd party APIs)
Does something like this exist or is it planned maybe?
The idea behind this is I want to very selective where my data can go when adding plugs without having to read / understand all the plug source code.
As @Maarrk is pointing out, in principle there is support for fairly fine-grained permissions for plugs. Certain APIs like performing fetch requests, or running shell commands require explicit permissions.
That said, enforcement of those permissions is not where it potentially could be. I have honestly not spent time on trying to address this. I’ve deprioritized working on this, but I know at the foundational level this can be done, when prioritized.
Currently plug code that runs on the server (in the Deno environment) runs in an isolated web worker that has relatively few permissions: silverbullet/lib/plugos/sandboxes/deno_worker_sandbox.ts at main · silverbulletmd/silverbullet · GitHub however it does, these days, have network access, which means that it could make arbitrary network connections. Previously I had this disabled, but due to some issues of implementing a full sandboxed and some plugs requiring things like streaming support, I re-enabled network access.
Plug code that runs in the browsers has relatively few restrictions (other than the default browser ones, such as CORS). It may be possible to lock this down further by hosting it inside of a sandboxed iframe. I think at some point I had an implementation of it, but I think it broke in certain Safari setups so I dropped it. This may be worth looking at though.
Your best options if you’re concerned right now:
Inspect the plug code yourself, either the original source (all plugs tend to be open source), or the built version. You can scan it for fetch calls, for instance.
Inspect the network traffic as you use these plugs, to see what they actually do. For client-side code this is fairly straight forward, on the server this will likely be harder to do.