←back to thread

478 points saeedesmaili | 1 comments | | HN request time: 0.205s | source
Show context
gejose ◴[] No.45308131[source]
This is one way to look at it, but ignores the fact that most users use third party community plugins.

Obsidian has a truly terrible security model for plugins. As I realized while building my own, Obsidian plugins have full, unrestricted access to all files in the vault.

Obsidian could've instead opted to be more 'batteries-included', at the cost of more development effort, but instead leaves this to the community, which in turn increases the attack surface significantly.

Or it could have a browser extension like manifest that declares all permissions used by the plugin, where attempting to access a permission that's not granted gets blocked.

Both of these approaches would've led to more real security to end users than "we have few third party dependencies".

replies(20): >>45308149 #>>45308208 #>>45308212 #>>45308222 #>>45308224 #>>45308241 #>>45308572 #>>45308600 #>>45308749 #>>45310219 #>>45310642 #>>45310881 #>>45310991 #>>45311185 #>>45311760 #>>45311782 #>>45312975 #>>45313054 #>>45314194 #>>45315453 #
0cf8612b2e1e ◴[] No.45308149[source]
Don’t most plugin models work this way? Does VSCode, Vim, Emacs, and friends do anything to segregate content? Gaming is the only area where I expect plugins have limited permissions.
replies(6): >>45308244 #>>45308310 #>>45308373 #>>45308539 #>>45309613 #>>45310771 #
schmichael ◴[] No.45308310[source]
vim and emacs are over 30 years old and therefore living with an architecture created when most code was trusted. Encrypting network protocols was extremely rare, much less disks or secrets. I don't think anything about the security posture of vim and emacs should be emulated by modern software.

I would say VSCode has no excuse. It's based on a browser which does have capabilities to limit extensions. Huge miss on their part, and one that I wish drew more ire.

replies(3): >>45311209 #>>45312130 #>>45312368 #
tlavoie ◴[] No.45311209[source]
I'd love to see software adopt strong capabilities-based models that enforce boundaries even within parts of a program. That is, with the principle of least authority (POLA), code that you call is passed only the capabilities you wish (e.g. opening a file, or a network socket), and not everything that the current process has access to. Thomas Leonard's post (https://roscidus.com/blog/blog/2023/04/26/lambda-capabilitie...) covers this in great detail, and OCaml's newer Eio effect system will has aspects of this too.

The Emily language (locked-down subset of OCaml) was also interesting for actively removing parts of the standard library to get rid of the escape hatches that would enable bypassing the controls.

replies(1): >>45312303 #
debugnik ◴[] No.45312303[source]
> OCaml's newer Eio effect system

Eio is an IO library out of many competing ones, not OCaml's effect system. The capabilities are an Eio thing, not an effects thing.

replies(1): >>45314907 #
1. tlavoie ◴[] No.45314907[source]
Gotcha, thanks!