I'm somewhat fond of including a UUID for that reason. As long as they can copy-paste it into Google, they can get results that are precisely the errors from your application, unlike "error 55324". The same works internally: zero ambiguity which system it came from, and it's trivial to find the full history of the error (message). It's not great for verbally communicating tho.
But yes, I can get behind making things nicer to read and less technically scary, but include enough detail so that people can solve their own problems if needed. There's a decent chance that the software will outlive your desire to support it.
IBM have been doing this for centuries, each error comes with a code you can look up for more information. Although this is probably way too late, all nix/nux utilities should come with either a magic ID string you can copy into Google to find all the other people baffled by the same error message ("Quadrant change in relocatable expression", that's an actual error message), or just an option to launch a browser with said info, because the message itself ain't giving you anything to go on.
Installing a plug-in and reviewing its code at that point is one thing. But if the plug-in can be updated withut you knowing, then there’s little guarantee of security.
You can automatically check for updates but it's off by default, and still requires a manual click. Also the new plugin review system automatically scans every release.
To try to add some explanation here: the server doesn't send the fingerprint. The server sends the public key, your computer just shows a fingerprint because it's more human-friendly and sufficiently secure.
If they forward the real key, so it matches the fingerprint, and you use it, they can't MITM the request because they can't read the contents.
Perhaps something where you can build a graph of who invited whom so you could prune entire sections that act maliciously. One might even consider it a to be a web of connections which are built on (or torn down by the loss of) trust.
Sounds futuristic. Maybe it's an NFT on an agentic blockchain for deep-sea solar farm mining?
Because it's by far the dominant strategy for distributed trust-ranking systems out there, with decades of research around it. Might as well look at the forest when realizing that it'd be nice if trees existed.
And I don't think anyone actually trusts any major actor to verify anything, so a fully centralized system is likely out. Otherwise people would be hype about WorldCoin, instead of recognizing it for the stupendously malicious grift that it is.
>Due to technical limitations, Obsidian cannot reliably restrict plugins to specific permissions or access levels. This means that plugins will inherit Obsidian's access levels. As a result, consider the following examples of what community plugins can do:
Community plugins can access files on your computer.
Community plugins can connect to internet.
Community plugins can install additional programs.
Obsidian has no protection at all. Installing a plugin gives it full access to your computer.
This was only a matter of time, and honestly I think it's inexcusably negligent that they shipped a plugin system like this at all since about 2010 (or arguably much earlier).
It does give full access but Obsidian does tell you that. Community plugins are not enabled by default, you have to enable them manually. Same happens with a shared vault: once you get it you still have to manually enable plugins. So far no one managed to sneak in a plugin completely unnoticed.
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)
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.
fwiw blocking access to anything except my notes folder (and denying internet, among other things) is my very first step when installing Obsidian. Flatseal makes that quite simple.
Flatpak could of course be significantly better... but it's still a massive step in a better direction.
> 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 was pointing out that the claim that "literally a majority of all software on your computer" runs sandboxed is also trivially false, to a significant degree
A majority have more access controls than obsidian plugins, yes. I think that's fairly safe to say, given that new system installs often have hundreds of processes already running.
Sandboxing, at least in the sense of easily configurable access with default deny on most even somewhat sensitive things: agreed, sandboxing is fairly uncommon in general, definitely not a majority on most systems. When ignoring the elephant in the room: mobile OSes.
> A majority have more access controls than obsidian plugins, yes
A majority run as me, a minority run with root privileges.
> I think that's fairly safe to say, given that new system installs often have hundreds of processes already running.
Precisely! Those hundreds of pre installed processes are running without sandboxing, or any access control beyond what Obsidian has.
For example, did you know you can just `ls` a directory, or `cat` a file, and both of those applications will run with full, unsandboxed, unrestricted access as you? And there are countless preinstalled applications just like those.
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.
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.
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.
For me these are the self hosted livesync, copilot and readitlater for better web clippings.
I really don't want my notes on other people's servers so the official sync will never be an option unless they enable that to be self hosted as an option.
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.
I think if the wording had been something like "I, one person out of billions, personally find Obsidian to be unusable without plugins", there probably would have been no disagreement and this discussion would be moot.
The disagreement was because the actual claim made was far broader, and in that far broader context, opposite to reality. We can assume good faith and an honest mistake in wording, but we can also forgive respondents for reasonably taking the words at face value.
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.
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.
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).
I'm not sure I agree or understand where you're coming from.
Side-loaded Android apps are still bound by all the same permission restrictions as any app installed by the Play Store. The only difference is Google didn't review it (for what little good that does) and that I didn't get the app from Google.
If I side-load a camera app, it still has to ask for camera privileges the same way any Play store app does.
Is there something in your message I missed about how it relates to this article or is this just being uninformed about side-loading?
A program one runs on one's computer can and should be able to do computer things. The alternative road you're advocating for ends in hardware attestation https://news.ycombinator.com/item?id=48086190
* Android's permissions model where the user must approve specific potentially undesirable classes of actions (separate from the 24H delay, etc controversy)
I remember reading that page sometime pre-COVID, and being surprised at just how ridiculous it was. It started strong with “The Obsidian team takes security seriously”, but then almost everything else on the page led me to believe they didn’t actually take security very seriously.
I agree with the claim of negligence. I think they were more than happy to reap the benefits of a thriving community plugin ecosystem, and were hoping this page would provide enough CYA when security breaches inevitably occurred.
> TIP: If you're working with sensitive data and wish to install a community plugin, we recommend that you perform an independent security audit on the plugin before using it.
I wonder just how many plugins received a security audit.
I use only one plugin because I am aware of the security model (or lack thereof). I only use one because I read the source and am convinced it’s safe. It would be foolish to blindly install many plugins.
Agreed, but also they prominently feature that they support plugins. Currently it's the second paragraph on the home page: https://obsidian.md/
They're trying to get all the benefits while pushing the extremely-obvious-to-them downsides into subpages. Not hidden, but not shown along-side the feature. It's intentionally misleading for non-technical users.
For at least the vast majority, yes definitely. I'm fine with full bypasses existing (say a webgl thing, or web previews, custom VCS integration, there are tons of legitimate reasons to escape a sandbox), but they should be an abnormality with heavy warnings and proportionate community attention to watch for issues, not the only option.
I don't think they meant it this way, but I honestly consider unsafe official plugin systems to be negligent to the point of being actively malicious. By releasing one, if you ever become successful you have explicitly chosen to screw over an unknown number of your users to save yourself a relatively small amount of work in the short term. It might be single digit users, or it might be septuple digit users - is it really worth it?
(Unsafe unofficial plugins, like most games? Mildly unfortunate but I think that's fine. Though a healthy modding community around your stuff should be a VERY STRONG sign that you should introduce a safe version to protect your users, if it won't cause you to implode (it definitely can)).
Has WASM/WASI DOM-access? When I last read about the architecture, there was a strict separation between WASM, Javascript and the app, but also a movement to allow UI-customization from WASM-space. Many Obsidian-plugins are adding heavy UI-changes, so without that, it would be kinda pointless.
Not generally / as many would hope, but that's partly because both WASM and WASI are not targeting being a full javascript-in-browser replacement - they're lower level, larger APIs are built on top, not defined by them. It's fairly easy to build an unsafe and unstable DOM access layer (a little bit of eval or string key accessers), but the web changes rapidly and isn't a stable target - exposing that in a stricter environment is tricky, and no one approach is likely to solve all needs.
Yeah, I can walk at a moderate pace literally all day with no problems and be fine the next. Plodding for a couple hours brings pain and a lot of general discomfort, and I'm very patient in general - I would love to take my time with such things, but I can't. Gotta take breaks to walk faster or jog or something to recover.
My wife knows me well enough to know that sometimes I'll walk fast to the next exhibit and wait for her; I'm not trying to rush ahead, it is just easier for me to do that than the slow plodding you usually do at museums.
You're asking questions that broadly summarize as: "what if we had an idempotency key [which must work concurrently to be useful], but it didn't work concurrently?"
Idempotency keys are themselves the solution you're looking for. If they don't work concurrently, they aren't idempotency keys. Your response in races or duplicates doesn't inherently matter in that sense, pick whatever semantics make sense for your system.
> You're asking questions that broadly summarize as
No, I'm asking one question, which doesn't seem to be summarized by your summary.
The situation is that your server has received two requests with the same idempotency key. For the first request, one of three things could be true: it could have succeeded, it could have failed, or it could still be in process.
The original post I responded to said what response the second request gets if the first request succeeded and if it failed. But it didn't say what response the second request gets if the first request is still in process on the server--so it hasn't succeeded and it hasn't failed. I do not see an answer to that anywhere in this thread.
If the first is still in progress and a second arrives, you can wait for it to finish (and then return whatever would be useful, e.g. you could replay the first request's response), or fail the second (409, 423, 429, there are a number of codes that could apply) to tell the caller to retry later.
So yeah, you can do basically anything that isn't inconsistent. Success, fail, delay, don't respond until timeout, all are valid as long as you don't double-apply. Most concurrent systems are like this in some way, because all successes can become errors, and all responses might never arrive. It has nothing really to do with idempotency.
tbh I've considered simply banning math-operator-precedence in projects I work on, and requiring all mixed-operator code to use parenthesis or split to multiple statements. I do that myself, at least.
I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it really doesn't seem worth it (in most code) for the extremely minor character savings.
I think I’d generalize that rule to require parentheses in any situation where adding parentheses could change the interpretation. I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.
a - b - c
is order dependent, even if its deterministic and knowable. When I’m scanning the code to look for a pesky bug, I don’t wanna have to take extra seconds to convince myself that it’s doing what I expect. It steals time and my limited attention from more interesting sections of code.
> I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.
At this point you just require every compound infix expression to be parenthesised, the terseness isn't worth the inconsistency. Especially as, as others have noted, these operations are only associative when working in some classes (notably not necessarily when dealing with floats).
And then you do automatic parens insertion in the LSP, so you write
If both `args->begin_argv + consume` are supposed to be the same concept and thus the same value, I'd have a variable for it by now. Some people hate it with a passion, but something like this removes the precendence thinking, prevents modification of one and not the other and makes it easier to follow, for me at least:
Yeah - sharing a variable there is a pretty strong signal that they are the same concept and can't be allowed to be different, not just "maybe the same value". That's useful to know.
If there's a ton of it in a dense bit of code, 1) it might be too complex, try making it clearer, and 2) it unfortunately makes for a lot of indirection and that can make it harder to follow, which is generally why I see people dislike it. In non-critical code I can kinda agree with inlining it. Pointer arithmetic is imo never non-trivial tho, paranoia is warranted. Especially in a kernel.
- and + operators have the same precedence. And a similar bug is possible if the operators were the same (both -). So I’m not sure it’s right to blame this on operator precedence or mixed operators. It’s just that, ultimately, the “consume” needs to be subtracted, not added.
Non-mixed always goes strictly left to right, regardless of the operator, which I haven't seen anywhere near as much struggling with.
But yes, I personally parenthesize `a-b-c` explicitly, because it's not worth it for me to read and wonder if parenthesizing order matters later. Costs less than a second to write, saves a second or ten each time I read it - that's an excellent tradeoff imo, and is a trivial pattern to follow.
I agree with explicit parentheses but please be careful about assuming associativity! The risk when handling floating-point arithmetic in particular is that associativity breaks, and suddenly a + (b + c) does NOT equal (a + b) + c. Not only can these lead to unexpected and hard-to-trace failure patterns, but depending on the details, they also can introduce memory overflow/underflow vulnerabilities.
If you're going for bit-for-bit equivalence of float values, then even with a single operation you're relying on compiler flags, architecture, the phase of the moon... I'm hard-pressed to think of any memory safety issues though.
Yea, you're in a fairly special niche of programming if you're somewhere that truly matters, and you can't accept any valid order's output. In most general code, if that kind of precision matters, float is the wrong choice: use a bignum object and be exactly correct regardless of how you organized your code.
Which is a niche that exists, obviously. So it is absolutely true for some cases. But I would hope that any code that requires this is extremely clear about requiring it.
I once had a job interview where they wanted to evaluate my C knowledge. They showed me a printout of some pointer arithmetic and said spot the bug. (It may actually have been the old puzzle where it turns out that /* is always a comment opener and never a division by the referent of a pointer).
I said "well first, this is a mess, I'm putting parentheses here, here, here and here". They said "well you've fixed the bug but can you tell us where it was?"
I gave them a hypothesis but I said my "real answer" was that it's not worth our brain cycles to figure it out, you just shouldn't write code that requires knowing operator precedence. It's just such desperately boring information that I can't hold it in my head.
Interviewing such an insufferable smartarse was probably quite annoying but they did give me the job and I do stand by the underlying principle!
> I gave them a hypothesis but I said my "real answer" was that it's not worth our brain cycles to figure it out, you just shouldn't write code that requires knowing operator precedence. It's just such desperately boring information that I can't hold it in my head.
this is exactly how I think. and it goes for a lot of stuff in general, we have limited bandwidth and wasting it on useless stuff like this has no real purpose.
yet sometimes I see people show off about how they know how to deal with it but I just don't see the point.
Your response was more correct in a professional sense than producing the piece of knowledge you've been asked for. I'd prefer to work with people who value everyone's time and write programs accordingly. If the interviewer was looking for a valuable expert, they were lucky to get you on board.
It's very common, I believe all the Big Tech firms have you write code.
I think the example from my story was the only one I've had where I had to _read_ code. (I have heard of people doing "code review interviews" though).
I've also had a job interviews with no code though. For startups or non-FAANG type companies.
Literally all of them, for at least the past decade, afaik. Obviously it'll vary a lot outside those though, the field employs all kinds in all kinds of ways.
A much older language that does not have operator precedence is APL.
This is the right choice for a language with a great number of operators.
In C they have tried to minimize the number of parentheses in expressions, but for this they have created far too many levels of precedence between operators, which had the opposite effect to that intended, since people now prefer to insert superfluous parentheses, to avoid having to remember all those levels of precedence.
IIRC several industry and government coding standards don't permit evaluations in arguments to functions, as the compiler can end up doing wonky things, to say nothing of the likely human error. These are the kind of standards we should be adapting into a software building code to avoid security holes like this one.
These standards are that way because older languages (specifically C and C++) have unspecified evaluation orders for arguments, so multiple argument expressions with conflicting side-effects are non-portable.
Here the expressions are pure, OooE has nothing whatsoever to do with the issue.
reply