6 ms·

lol we told you plugins were insecure years ago. I distinctly remember getting flamed in your discord because I said that they had full disk access. Too little

by ibash 5mo ago

lol we told you plugins were insecure years ago. I distinctly remember getting flamed in your discord because I said that they had full disk access. Too little too late.

stingraycharles 5mo ago
These types of problems usually only get fixed when it’s too late.
- cromka 5mo ago
  "Sorry we got caught" reactiveness.
  - redsocksfan45 5mo ago
    [dead]
yard2010 5mo ago
Lol it's a social engineering attack. What are you talking about. Don't run programs you don't trust, especially when being asked to do so by strangers on the line.
enoch2090 5mo ago
You better delete all third-party applications for they are having full disk access.
- coldtea 5mo ago
  Hello, 2010s called. In 2026, applications, third or even first party, don't need to have full-disk access, and are not given either. They see a jailroot environment. I give full disk access to the terminal app, and a handful of others. 90% of them, nope. At least that's the case in macOS, I'm pretty sure Windows can do that too. Linux of course has had such capability since forever, but I guess most distros you need to manually take care of it.
  - finghin 5mo ago
    I've never tried to do this or similar in Windows (obviously easy in unix-like environments) but I'm going to bet it's far more trouble than it's worth for 99% of users
    - jon-wood 5mo ago
      On macOS at least those 99% of users are probably installing from the App Store, where apps are sandboxed by default and need to explicitly ask for access to paths outside that sandbox. Even when not installed from the App Store a permission dialogue is popped if an application tries to read from sensitive paths like your photo library.
      - silon42 5mo ago
        For real security, operation should only be allowed after 24h of cooldown.
        SamBam 5mo ago
        User should be required to explain the situation to an older and a younger family member, and get permission from both of them.
      - embedding-shape 5mo ago
        Does that help in this case though? I think the worry is that a rogue Obsidian plugin does bad stuff with your Obsidian vault, not just do stuff to the rest of the computer. But that vault/those notes live in the same sandbox as the (rogue) 3rd party plugin, which doesn't help with that, they really need to be isolated away from the notes themselves.
        zerkten 5mo ago
        Anything that reduces the blast radius helps. There should still be a focus on further hardening. Most value comes from exploits that enable pivots. Attackers will focus on other vectors that enable broader pivots because immediate high value notes only exist for a limited set of users.
redsocksfan45 5mo ago
[dead]
PurpleRamen 5mo ago
The insecurity is part of the benefit. Obsidian being so open, allowing easy customizing is what makes it great. They should add some more bells, whistles and guards to prevent sneaky social attacks, but they can't close Obsidian all together, or it would kill the app.
- fooqux 5mo ago
  There's open, and then there's "full disk access, even outside the vault" open.
  - tredre3 5mo ago
    What do you propose? Even if they configure node's lowest level file APIs to block any access to paths outside the vault, plugins can still execute arbitrary shell commands who will have access to the entire OS. And before you say it's useless and should be stopped too, well, that's a fine opinion! But then you lose plugins providing git integration, automated backups, document conversion using pandoc, etc. Many users might value that greatly. A permission system for their plugins might be the only solution, annoying permission request popups and all.
    - fooqux 5mo ago
      That's a good point. I think I'd solve this in two steps. 0) scripts and plugins should only be able to operate on the text in the vault. Just like how I expect a snippet of JavaScript running in my browser to only have access to the website and not to my entire disk. 1) Any commands that run outside of this sandbox need to be approved first. Obviously this could get annoying, but there's tricks you could use here to help. Obviously this is a high level approach and I'm not on their team, so this is basically armchair programming. But since you asked, it's okay. ;)

by ibash 5mo ago

lol we told you plugins were insecure years ago. I distinctly remember getting flamed in your discord because I said that they had full disk access. Too little too late.

stingraycharles 5mo ago

These types of problems usually only get fixed when it’s too late.

cromka 5mo ago
"Sorry we got caught" reactiveness.
- redsocksfan45 5mo ago
  [dead]

yard2010 5mo ago

Lol it's a social engineering attack. What are you talking about. Don't run programs you don't trust, especially when being asked to do so by strangers on the line.

enoch2090 5mo ago

You better delete all third-party applications for they are having full disk access.

coldtea 5mo ago
Hello, 2010s called. In 2026, applications, third or even first party, don't need to have full-disk access, and are not given either. They see a jailroot environment. I give full disk access to the terminal app, and a handful of others. 90% of them, nope. At least that's the case in macOS, I'm pretty sure Windows can do that too. Linux of course has had such capability since forever, but I guess most distros you need to manually take care of it.
- finghin 5mo ago
  I've never tried to do this or similar in Windows (obviously easy in unix-like environments) but I'm going to bet it's far more trouble than it's worth for 99% of users
  - jon-wood 5mo ago
    On macOS at least those 99% of users are probably installing from the App Store, where apps are sandboxed by default and need to explicitly ask for access to paths outside that sandbox. Even when not installed from the App Store a permission dialogue is popped if an application tries to read from sensitive paths like your photo library.
    - silon42 5mo ago
      For real security, operation should only be allowed after 24h of cooldown.
      - SamBam 5mo ago
        User should be required to explain the situation to an older and a younger family member, and get permission from both of them.
    - embedding-shape 5mo ago
      Does that help in this case though? I think the worry is that a rogue Obsidian plugin does bad stuff with your Obsidian vault, not just do stuff to the rest of the computer. But that vault/those notes live in the same sandbox as the (rogue) 3rd party plugin, which doesn't help with that, they really need to be isolated away from the notes themselves.
      - zerkten 5mo ago
        Anything that reduces the blast radius helps. There should still be a focus on further hardening. Most value comes from exploits that enable pivots. Attackers will focus on other vectors that enable broader pivots because immediate high value notes only exist for a limited set of users.

redsocksfan45 5mo ago

[dead]

PurpleRamen 5mo ago

The insecurity is part of the benefit. Obsidian being so open, allowing easy customizing is what makes it great. They should add some more bells, whistles and guards to prevent sneaky social attacks, but they can't close Obsidian all together, or it would kill the app.

fooqux 5mo ago
There's open, and then there's "full disk access, even outside the vault" open.
- tredre3 5mo ago
  What do you propose? Even if they configure node's lowest level file APIs to block any access to paths outside the vault, plugins can still execute arbitrary shell commands who will have access to the entire OS. And before you say it's useless and should be stopped too, well, that's a fine opinion! But then you lose plugins providing git integration, automated backups, document conversion using pandoc, etc. Many users might value that greatly. A permission system for their plugins might be the only solution, annoying permission request popups and all.
  - fooqux 5mo ago
    That's a good point. I think I'd solve this in two steps. 0) scripts and plugins should only be able to operate on the text in the vault. Just like how I expect a snippet of JavaScript running in my browser to only have access to the website and not to my entire disk. 1) Any commands that run outside of this sandbox need to be approved first. Obviously this could get annoying, but there's tricks you could use here to help. Obviously this is a high level approach and I'm not on their team, so this is basically armchair programming. But since you asked, it's okay. ;)