This is just the first detected and reported instance, in all likelyhood such attacks have been happening for some time. When will the fanatic userbsse finally admit that using Obsidian in any enterprise setting is just plain malpractice?
It takes 5 minutes in their Discord channel to see the founders are D&D nerds, not competent engineers. It was never meant for serious work.
> the founders are D&D nerds, not competent engineers
The two are not mutually exclusive. What would you trust more than a nerd? A jock? A spod? An MBA?
Any evidence of other examples if bad engineering you can point to, or are your thoughts on the pluggin system and throwing shade at random groups of people all you've got?
[FYI: I know little of obsidian other than planning to look into it at some point as people I know use and like it. I stepped into this set of comments in case there was something useful I should be passing on to those people]
The attack relies on social engineering to get the victim to disable protections and could just as easily have happened with a plugin for any code editor.
Anyway,
What I like about obsidian is that it can handle a truly huge amount of notes without slowing down, and the notes are just markdown files on disk, so there's no lock in.
I have used evernote, ms one note and zoho notebook before, and had issues with all of them.
That isn't a response to my post, it is a bit of information already present in the thread that isn't relevant to my question followed by a positive review. This suggests that a shill brigade has been attracted to these comments. I suggest you don't do that, it isn't a good look.
well there was this previous issue in the crypto community where it turned out someone was not a competent engineer and should have stuck to their online exchange for magic: the gathering
To make an actual counter, you need numbers. If only a tiny niche of users use it without community plugins, then yes, it's unusable (in a practical definition of the term)
Yeah, I don't use any community plugins. I take notes in obsidian. And it turns out, having multiple years worth of notes and todos in a tree of crosslinked markdown files is pretty handy in this AI era. I take notes in obsidian and run the Gemini cli from my vault. Works a treat.
An ADD/SUM feature on tables was the first plugin I installed. It could be argued this should be part of the TABLE but I guess the dev team has a lot on their plate not to mention I'm not even sure if there's a feature request for this ability.
I rely on Advanced URI, which opens certain functionality up to external apps. I use Raycast and with Cmd+Space, it lets me open vaults or daily notes.
And Obsidian_to_Anki, but that's probably just me because I have no clue how to use Anki otherwise.
All I want is a top-notch Markdown editor with a mobile app and trustworthy sync, and that's what Obsidian gives me. And if ever Obsidian goes away or is enshittified, I'll still have a perfectly good folder of Markdown documents that I can take elsewhere.
Seriously though, I agree with your sentiment that community plugin security can and needs to be improved, but how does someone saying they use it every day "disregard software usability as a formal discipline, along with decades of UX research and standards"
They are irrelevant for this dispute, because these problems do not concern them. And the amount of people using plugins because of some real demand is not low.
The parent comment says that Obsidian is not usable without plugins and it's simply nonsense. It would be very charitable to call this a "dispute."
Could Obsidian handle plugin permission better? I guess so. But that doesn't mean the users have to use plugins. It's ultimately the user's choice. Blender has zero security guards over the addons besides the OS's and the ecosystem thrives. So does Minecraft. These communities are essentially "arbitrary Python/Java code goes brrrr."
The discussion about the plugin-system, and the people who need it to which degree.
> The parent comment says that Obsidian is not usable without plugins and it's simply nonsense.
Sure, fair. But the comment happened in the context of talking about the plugin-system, and parent comment seems on the side that for them obsidian is worthless without plugins. Saying that other people have no need for them is pointless, because they are not in the picture. Phrasing could indeed be better, but talking about people who are not concerned by the problem is not really adding anything to the discussion.
The attack here requires not just enabling community plugins, but also syncing the attacker's vault to your computer, and also separately enabling the synchronization of the attacker's plugins with yours.
Obsidian Plugins are still incredibly vulnerable. A compromised plugin will essentially take over your machine. There's no sandboxing of any kind. It's even more insecure than browser extensions (that could steal your auth tokens, but at least don't have unfettered access to your filesystem).
This is really unfortunate. I love Obsidian and am a paid subscriber for many years, but the community plugins needs a security overhaul asap, before someone gets hurt.
Not even slightly. Browser extensions are a trivial counter-example, as are all flatpacks, and anything restricted by user/group. That covers probably literally a majority of all software on your computer, because people have been voluntarily restricting their software to protect you from their potential accidents for decades.
In practise, Flatpak packages have many more permissions than you might expect, and the sandbox feature gives a false sense of security. For example, the Obsidian Flatpak package [0] is given all of the following abilities without explicit permission from the user (the user has to know where to look to find out about them):
- Home folder read/write access
- System folder media
- System folder mnt
- Microphone access and audio playback
- And more...
The Obsidian snap [1] is installed with the --classic flag, which also grants access to the whole home directory, but at least you have to consciously specify the --classic flag to grant this permission.
> That covers probably literally a majority of all software on your computer
If you're running GNU/Linux, chances are you'll have hundreds, if not thousands, of pieces of software that run totally unsandboxed.
Yes, a very small minority of applications are unfortunately primarily distributed via flatpak or snap, and the distributors don't care about the user experience, so it's error-ridden and problem-ridden, but chances are you can get a "normal computer program" version of it unencumbered by such grossness.
And tons won't be part of e.g. root, or dialout (to pick one I've had to deal with a lot lately), or many other more-privileged-than-default groups, yes. That's a permissions system working as intended.
Besides. They said "all software on your machine". That is trivially false, to a significant degree.
I think that's especially important to point out because it reminded me of a blog post by Obsidian that also was discussed here[1], where they talked about reducing supply chain risk by not relying on dependencies, but people quickly pointed out that this is only possible because users depend so heavily on extensions. Just look at that top comment and here we are now.
This combination of software relying on third parties without security seems to be untenable. Personally I've gotten rid of just about as many extensions as I can anywhere and switched to batteries included software.
Krita: that is a decision by Krita(/GIMP) and not anything inherent in "plugins" or "python" - it could be a bubblewrap/firejail contained process, for example (other OSes have similar-ish options but there's always something, e.g. don't use cpython). They have chosen to continue to put their users at risk by not doing anything at all like that.
There are of course complications, costs, and downsides associated with doing that. It might not be worth it currently, or performance costs might be too high, or the community might be overwhelmingly using abandoned plugins that won't be updated, etc. It's still a decision to remain complacent until forced by attacks though, it's well beyond common knowledge that these things happen so you can't really call it ignorance.
Software engineers at large would benefit from playing World of Warcraft, and seeing the ongoing fight between Blizzard and add-on authors.
WoW's whole UI is built in the same Lua environment as add-ons, and Blizzard has implemented some interesting restrictions (like the taint system[0]) to prevent add-ons from completely automating gameplay.
If you happen to use the WoW example in the future, the wiki efforts moved from the fandom one to wiki.gg[0], as voted by maintainers and contributors in late 2023[1].
Thanks! I've been meaning to read up on taint systems, looks interesting :)
I'm somewhat convinced that taint-influenced capabilities is a good future model to pursue. Computers are fast, I'm fairly confident that it chould be done at whole-computer scale and still be reasonable... though probably not with a million electron apps. Which is likely a good thing in aggregate (I say as a fan of web tech and the very compelling features such things offer. Great for minor or PoC, not for major pieces of software).
World of Warcraft is one of the most popular MMO's ever made.
You simply can't expect every software that wants a plugin system to have the same security practices as the most used software in the world.
In fact, there are many reasons why you might want a plugin to have full filesystem and internet access, such as batch processing or simply adding things directly from webpages. Sandboxing this will just make plugins less useful.
In the end it's a problem of trust. You're installing software from untrustworthy developers because you trust the name of the application those plugins are associated with.
You could fix the problem in Obsidian, but the same problem will happen in other software. Some of which simply can't justify bothering with sandboxing plugins. This is just the way plugins are.
> You simply can't expect every software that wants a plugin system to have the same security practices as the most used software in the world.
I'm not saying that I think they should, or that I expect them to. I'm saying that it's one particular implementation of sandboxing that has a bunch of interesting properties, and that makes it worth studying.
It shouldn't. It's been extensively documented among modern human groups.
The major question is how much our understanding from recent forager groups applies to pleistocene foragers ("ethnographic analogy"). I'm in the generally skeptical camp. Many other anthropologists aren't, particularly those in older generations.
The Pleistocene lasts from 2.58 million years ago, maybe the first time our ancestors figured out tools, to 11,000 years ago, when we Homo sapiens had been around for ~200,000 years. Isn't that too wide a range of humans and ancestors to characterize in one group?
Are you skeptical about 11 kya ancestors doing similar things? Why?
Isn't that too wide a range of humans and ancestors to characterize in one group?
Yes, that's one reason why I have high standards for arguments from ethnographic analogy.
Are you skeptical about 11 kya ancestors doing similar things? Why?
Because modern forager groups have survived for centuries on the margins of colonial states. The environment they inhabit is very different from late pleistocene humans and we should default to skepticism in the absence of other evidence.
>It's been extensively documented among modern human groups.
Do you have some sources? A quick search doesn't pull up much evidence for current hunter-gatherer dependence on natural fire regime. Or you mean anatomically modern humans?
Yes, Tasmanians are the best example that comes to mind. They had a mythology developed around lightning and subsequent fires and would then try to keep a fire going as long as possible.
from the paper: "The consideration of fire ecology data and various factors involved in the complex process of fire ignition, combustion, and behavior, in relation to the GBY paleoenvironment and archaeology, enabled the rejection of recurrent natural fires as the responsible agent for burning (Alperson-Afil, 2012)."
I've been long fascinated by the rolling release model. But aren't you guys worried about supply chain attacks? Seems those on the bleeding edge serve as canaries in the coalmine for the rest of us.
That's the purpose of reproducible build initiatives like TFA. The idea is to ensure that identical source produces bit-for-bit identical builds on multiple machines when the packages are built.
Sure, if the source itself gets got, then it does nothing. But it at least puts up one more barrier against tampering with the artifacts.
It takes 5 minutes in their Discord channel to see the founders are D&D nerds, not competent engineers. It was never meant for serious work.
reply