10 ms·

Less is safer: Reducing the risk of supply chain attacks

522 points by saeedesmaili 1y ago

amai 1y ago
Is that the reason why Obsidian does not support the https://textbundle.org/ https://textbundle.org/ format for import/export like any other markdown editor?
- kepano 1y ago
  for import it does: https://help.obsidian.md/import/textbundle https://help.obsidian.md/import/textbundle for export it's the same reason many features don't exist yet — the team only has 3 full time developers
apitman 1y ago
Love it. Jonathan Blow had a nice thread about dependencies a while back: https://x.com/Jonathan_Blow/status/1924509394416632250 https://x.com/Jonathan_Blow/status/1924509394416632250
brandonspark 1y ago
missed opportunity for "less is secure"
- mpalmer 1y ago
  "Secure" is a different, harder promise than safeR.
  - brandonspark 1y ago
    but still along the same lines as "safer". the stresses are different, "safer" has the stress as "SAY-fer" and "secure" has the stress as "sih-KYOOR". the latter sounds more similar (and rhymes better) with "more", the originator of the phrase "less is more"
    - mpalmer 1y ago
      Well uh sure if meter's all you're going for here
system7rocks 1y ago
I’ve been using other apps than Obsidian for notes and sharing, so this is nice to read and consider. But isn’t Obsidian an electron app or whatever? Electron has always seemed resource intensive and not native. JavaScript has never struck me as “secure”. Am I just out of touch?
- GabeIsko 1y ago
  If you have to render html, which is what markdown ultimately becomes, you might as well use a web broswer.
- anon7000 1y ago
  JavaScript is a very secure language. The browser is a massive success at running secure JavaScript on a global scale. Every website you use is running JavaScript and not able to read other site data. Electron is the same, running v8 to sandbox JavaScript. Assuming you aren't executing user input inside that sandbox (something many programming languages allow, including JS), it's very secure. The problem with supply chain attacks is specifically related to npm, and not related to JS. npm as an organization needs to be taking more responsibility for the recent attacks and essentially forcing everyone to use more strict security controls when publishing their dependencies.
  - asgraham 1y ago
    Doesn’t this mean browser sandboxing is secure, not JS? Or are you referring to some specific aspect of JS I’m not aware of? (I’m not aware of a lot of JS) It’s maybe a nit-pick, since most JS is run sandboxed, so it’s sort of equivalent. But it was explicitly what GP asked for. Would it be more accurate to say Electron is secure, not JS?
    - dalmo3 1y ago
      I'm really curious about this comment. What would it mean for a programming language to be secure? Any two Turing-complete programming languages are equally secure, no? Surely the security can only ever come from whatever compiles/interprets it? You can run JavaScript on a piece of paper.
montroser 1y ago
Yes, you are responsible for all the code you ship to your users. Not pinning dependencies is asking for trouble. It is literally, "download random code from the Internet and hope for the best."
- lelandfe 1y ago
  Pinned dependencies usually have their own dependencies so you are generally always downloading random code and hoping. I mean, jeeze, how much code comes along for the ride with Electron...
  - cosmic_cheese 1y ago
    The real answer is to minimize dependencies (and subdependencies) to the greatest extent practical. In some cases you can get by with surprisingly few without too much pain (and in the long run, maybe less pain than if you'd pulled in more).
    - Scramblejams 1y ago
      Yep, and for the rest I've gotten a lot of mileage, when shipping server apps, by deploying on Debian or Ubuntu* and trying to limit my dependencies to those shipped by the distro (not snap). The distro security team worries about keeping my dependencies patched and I'm not forced to take new versions until I have to upgrade to the next OS version, which could be quite a long time. It's a great way to keep lifecycle costs down and devops QoL up, especially for smaller shops. *Insert favorite distro here that backports security fixes to stable package versions for a long period of time.
  - chrisweekly 1y ago
    No. "Always downloading random code and hoping" is not the only option. Even w/ the supply-chain shitshow that the public npmjs registry has become, using pnpm and a private registry makes it possible to leverage a frozen lockfile that represents the entire dependency graph and supports vulnerability-free reproducible builds. EDIT to add: Of course, reaching a state where the whole graph is free of CVEs is a fleeting state of affairs. Staying reasonably up-to-date and using only scanned dependencies is an ongoing process that takes more effort and attention to detail than many projects are willing or able to apply; but it is possible.
platers 1y ago
What about the third party extensions?
montroser 1y ago
This is obviously the way to do it, assuming you have the skills and resources to operate in this manner. If you don't, then godspeed, but you have to know going in that you are trading expediency now for risk later. Risk of performance issues, security vulnerabilities, changes in behavior, etc. And when the mess inevitably comes, at whatever inopportune time, you don't really get to blame other people...
doesnt_know 1y ago
Going to preface this post by saying I use and love Obsidian, my entire life is effectively in an Obsidian vault, I pay for sync and as a user I'm extremely happy with it. But as a developer this post is nonsense and extremely predictable [1]. We can expect countless others like it that explains how their use of these broken tools is different and just don't worry about it! By their own linked Credits page there are 20 dependencies. Let's take one of those, electron, which itself has 3 dependencies according to npm. Picking one of those electron/get has 7 dependencies. One of those dependencies got, has 11 dependencies, one of those cacheable-request has 7 dependencies etc etc. Now go back and pick another direct dependency of Obsidian and work your way down the dependency tree again. Does the Obsidian team review all these and who owns them? Do they trust each layer of the chain to pick up issues before it gets to them? Any one of these dependencies can be compromised. This is what it means to be. supply chain attack, you only have to quietly slip something into any one of these dependencies to have access to countless critical user data. [1] https://drewdevault.com/2025/09/17/2025-09-17-An-impossible-future-for-JS.html https://drewdevault.com/2025/09/17/2025-09-17-An-impossible-...
- dsissitka 1y ago
  Coincidentally I did that yesterday. Mermaid pulls in 137 dependencies. I love Obsidian and the Obsidian folks seem like good people but I did end up sandboxing it.
- PhilipRoman 1y ago
  To be fair, the electron project likely invests some resources in reviewing it's own dependencies, because of its scale. But yeah this is a good exercise, I think we need more systems like Yocto which prioritize complete understanding of the entire product from source.
deleted 1y ago
[deleted]
gejose 1y ago
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".
- justsomehnguy 1y ago
  > Obsidian plugins have full, unrestricted access to all files in the vault. And how exactly you can solve that? I don't want to press 'allow access' on the every file some plugin is accessing.
  - schmichael 1y ago
    One of the large dependencies they call out is an excellent example: pdf.js. There is no reason for pdf.js to ever access anything other than the files you wish to export. The Export to PDF process could spawn a containerized subprocess with 0 filesystem or network access and constrained cpu and memory limits. Files could sent to the Export process over stdin, and the resulting PDF could be streamed back over stdout with stderr used for logging. There are lots of plugin systems that work this way. I wish it were commodofied and universally available. AFAIK there's very little cross-platform tooling to help you solve this problem easily, and that's a pity.
  - gejose 1y ago
    Specific permissions declared in a manifest much like browser extensions could be a good first step.
- gjsman-1000 1y ago
  That just sounds like Linux packages; also not a system known for security of desktop apps and scripts especially compared to MacOS, shoot me.
scuff3d 1y ago
This doesn't make any sense to me. I've always been told you don't write anything yourself unless you absolutely have to and having a million micro-dependencies is a good thing. JavaScript and now Rust devs have been saying this for years. Surely they know what they're doing...
- elric 1y ago
  There is a balance to be struck. NPM in particular has been a veritable dependency hell for a long time. I don't know if it just attracts inexperienced developers, or if its security model is fundamentally flawed, but there have been soooo many supply chain attacks using NPM that being extra careful is very much warranted.
  - scuff3d 1y ago
    Right, I get that. I was just making a joke because I really dislike the micro-dependency approach. Honestly bothers me more in Rust then JavaScript, but that's probably just because I'm not a web dev. From my buddies who have worked in JS my understanding is that a lot of it is rooted in JavaScript having a really shitty standard library for a long time. So that lead to a culture of code sharing early on since everyone was rewriting the same utilities and what not. Which evolved into the package management ecosystem over time. Why that came about in something like JavaScript but not C, which also obviously has a really small std is super interesting. My only guess is that JavaScript came up in the internet when package managers started to take on a new meaning, and web dev is more relavent to a broader range of (nontech) companies and they're more likely to put a huge focus on quality over quantity.
profsummergig 1y ago
I love Obsidian and wish I could make it my default markdown handler on Windows. While we're on the topic: what's your default markdown handler on Windows?
- password4321 1y ago
  Not my favorite but I was surprised recently when Windows 11 Notepad popped up something mentioning markdown support.
system2 1y ago
I wish they could add Google Drive support to their mobile app. I'd be happy to pay $100+ for one-time-only Google Drive support.
qntmfred 1y ago
If the obsidian team did a 2 hour q&a livestream every week, I'd watch every one (or at least get the AI summary). One of my favorite pieces of software ever.
- callc 1y ago
  I recently had a similar experience using Libby for the first time. An absolutely incredible piece of software. If anyone here on HN works on it, you deserve to be proud of your work.
  - 2dvisio 1y ago
    Fully agree. Libby is awesome!
groby_b 1y ago
I love Obsidian dearly, but if you build an app that's only really useful with plugins, and that has a horrifyingly bad security model for plugins and little to no assurance of integrity of the plugins... Maybe, just maybe, don't give fullmouthed advice on reducing risk in the supply chain.
- MonaroVXR 1y ago
  But what about VScode?
  - groby_b 1y ago
    Do you hear the VSCode team talk about supply chain security?
kid64 1y ago
'It may sound obvious but the primary way we reduce the risk of supply chain attacks is to avoid depending on third-party code." What a horribly disingenuous statement, for a product that isn't remotely usable without 3rd-party plugins. The "Obsidian" product would be more aptly named "Mass Data Exfiltration Facilitator Pro".
- freddie_mercury 1y ago
  I've used Obsidian for years without a single 3rd party plugin. It is possible to make your same point without histrionic excess.
  - kid64 1y ago
    Yeah, this is always the response. Usability can be assessed objectively, so you just have low standards.
    - Capricorn2481 1y ago
      I have to agree that I don't find plugins necessary, and I'm not sure why you're so down on people using a solid backlinking note taker. I don't think I have low standards, I think Roam and Logseq aren't that great and Obsidian is all I need.
    - maxbond 1y ago
      A more charitable interpretation would be that that have different needs. My keyboard costs more than my computer, but most people probably spend $15-$50 on a keyboard. Even my mouse is well outside that range. Do I have high standards or do I have tendonitis?
      - kid64 1y ago
        Software usability, in this context, is measured objectively, there is no interpretation. This is separate from a specific user's preferences, the ergonomics of their hardware, etc.. As for your high standards vs tendonitis distinction, I'd say these things are not mutually exclusive, and the comparison is not related to what we're talking about.
deleted 1y ago
[deleted]
Mountain_Skies 1y ago
Absolutely love Obsidian but had to stop using it because Electron apps don't play well with Wayland. After lots of tinkering around with flags and settings for compatibility layers, it became obvious that it would never work seamlessly like it did on Windows (and probably does on x11). So it was either give up Wayland compositors or give up Obsidian. Luckily I don't use any plugins, so moving to other software was easy, but I still would prefer Obsidian. Electron's "works everywhere" works about as good as Java's "works everywhere", which is to say it works great, until it doesn't, at which point it's a mess of tinkering. If you use Wayland and it works for you, that's great, but it's not my experience.
- lyu07282 1y ago
  In my experience electron + Wayland was absolutely god awful for a long time, but it got dramatically better in the last 4-5ish months. So depending on when you last tried it, might be worth a revisit. Heavily depends on which GPU+DE though, Nvidia+Plasma here.
- yoavm 1y ago
  What issues are you seeing? Haven't noticed the slightest glitch here, using Sway.
pier25 1y ago
I also recommend using this site to evaluate the dependencies of your dependencies: https://npmgraph.js.org/?q=express https://npmgraph.js.org/?q=express
lyu07282 1y ago
> The other packages help us build the app and never ship to users, e.g. esbuild or eslint. Eslint with such wonderful dependencies like is-glob smh
arigatoarigato 1y ago
[dead]
brentm 1y ago
I've been using Roam Research since about 2020. Is Obsidian better?
- photon_garden 1y ago
  Haven’t used Roam, but what I like about Obsidian: - All your data is just plain files on your file system. Automation and interop are great, including with tools like Claude Code. - It’s local-first, so performance is good. - It’s extensible. Write extensions in HTML, CSS, and JS. - It’s free. - Syncing files is straightforward. Use git, Syncthing, Google Drive, or pay for their cheap sync service which is quite good. - Product development is thoughtful and well done. - They’re explicitly not trying to lock you in or own your data. They define open specs and build on them when Markdown doesn’t cut it. Things you might not like: - Their collaboration story isn’t great yet. No collaborative editing. - It’s an Electron app.
  - TiredOfLife 1y ago
    In what universe is their sync service cheap? It's literally at least 100 times more expensive that Dropbox/OneDrive/Google Drive/iCloud sync
    - photon_garden 1y ago
      My assumption is that most people on HN are making programmer money. $4 - 5 USD per month is affordable even on a junior engineer’s salary in many parts of the world. The price per GB isn’t as good as the services you mentioned, but their storage limits are fine for the primary use case — storing a lot of plain text notes. I’ve also had no problems with it, in contrast with iCloud which has routinely gotten stuck for me. And if price per GB is what you care most about, use something else. That’s one of the great things about Obsidian.
  - deafpolygon 1y ago
    The plain text thing is more of a feel-good argument than a practical one. If there’s a solid export path, the format isn’t really the issue... what matters is whether the app actually works the way you need it to. At the end of the day, your workflow lives or dies on how the software behaves... not on the file extension.
withinrafael 1y ago
Was hoping they outlined their approach to handling potentially compromised packages running on dev machines prior to even shipping. That seems like a much harder problem to solve.
mikeocool 1y ago
> We don’t rush upgrades. Can’t wait for “implements mechanism to delay application of new patches” to start showing up compliance checklists. My procrastination will finally pay off!
aborsy 1y ago
I installed an AppArmor profile for Obsidian. For an application that displays text files, it needed a lot of permissions. It would refuse to run without network access. You can install Obsidian flatpak and lock it down with flatseal.
neilv 1y ago
These practices are very similar to what I've done in the past, for a large, sensitive system, and they worked very well. (IIUC, we actually were the first to get a certain certification for cloud deployment, maybe because we had a good handle on this and other factors.) From the language-specific network package manager, I pulled the small number of third-party packages we used into the filesystem tree of system's repo, and audited each new version. And I disabled the network package manager in the development and deployment environments, to make it much harder for people to add in dependencies accidentally. Dependencies outside this were either from the Linux distro (nice, because well-managed security updates), or go in the `vendor` or `ots` (off-the-shelf) trees of the repo (and are monitored for security updates). Though, I look at some of the Python, JS, or Rust dependency explosions I sometimes see -- all dependent on being hooked up to the language's network package manager, with many people adding these cavalierly -- and it becomes a much harder problem.
joshdavham 1y ago
There’s some advice that’s been going around lately that I’ve been having trouble understanding: the idea that you should not be updating your dependencies when new patches are released (e.g., X.X.PATCH). I understand that not updating your dependencies when new patches are released reduces the chance of accidentally installing malware, but aren’t patches regularly released in order to improve security? Wouldn’t it generally be considered unwise to not install new patches?
- flanbiscuit 1y ago
  I believe it's about waiting a bit before a new patch is released, not fully avoiding installing updates. Seems like compromises are being caught quickly these days, usually within hours. There are multiple companies monitoring npm package releases because they sell security scanning products and so it's part of their business to be on top of it. pnpm has a setting that you can tell it that a package needs to be at least X minutes old in order to install it. I would wait at least 24 hours just to be safe https://pnpm.io/settings#minimumreleaseage https://pnpm.io/settings#minimumreleaseage
- RadiozRadioz 1y ago
  There's a key missing piece to this puzzle: being informed about _why_ you're updating and what the patches are. Nobody has time to read source code, but there are many tools and services that will tell you brief summaries of release notes. Npm Audit lists security vulnerabilities in your package versions for example. I do adopt the strategy of not updating unless required, as updates are not only an attack vector, but also an extremely common source of bugs that'd I'd prefer to avoid. But importantly I stay in the loop about what exploits I'm vulnerable to. Packages are popping up with vulnerabilities constantly, but if it's a ReDoS vulnerability in part of the package I definitely don't use or pass user input to? I'm happy to leave that alone with a notice. If it's something I'm worried another package might use unsafely, with knowledge of the vulnerability I can decide how important it is, and if I need to update immediately, or if I can (preferably) wait some time for the patch to cook in the wild. That is the important thing to remember about security in this context: it is an active, continuous, process. It's something that needs to be tuned to the risk tolerance and risk appetite of your organisation, rather than a blanket "never update" or "always update" - for a well-formed security stance, one needs more information than that.
eviks 1y ago
No mention of plugins, which are a core differentiator of Obsidian, so part of the overall "supply chain" for the app.
xenator 1y ago
To be honest, right now I'm thinking about isolating of build process for frontend on my local environment. It is seems not hard to send my local environment variables like OPENAI_API_KEY or .ssh/* to some remote machine. I know it is not very different comparing to python or projects in any other language. But I don't feel that I cannot trust node/js community at this point.
- hahn-kev 1y ago
  Running vite inside a docker container would probably get you what you want
  - N2yhWNXQN3k9 1y ago
    I don't think you even need a container for that type of containment. You could do it with namespaces. I think node/whatever-js-run-time/package-manger could allow for namespaced containment for packages with simple modern linux things. The realms proposal was a step towards that at one time.
- mark_and_sweep 1y ago
  Switching to Deno might help. It's sandboxed by default and offers granular escape hatches. So if a script needs access to a specific environment variable or read or write specific files, it's simple to configure that only those accesses are allowed.
darkamaul 1y ago
> We do not run postinstall scripts. This prevents packages from executing arbitrary code during installation. I get the intent, but I’m not sure this really buys much. If a package is compromised, the whole thing is already untrustworthy and skipping postinstall doesn’t suddenly make the rest of the code safe. If it isn’t compromised, then you risk breaking legitimate installation steps. From a security perspective, it feels like an odd tradeoff. I don’t have hard data, but I’d wager we see far more vulnerabilities patched through regular updates than actual supply-chain compromises. Delaying or blocking updates in general tends to increase your exposure rather than reduce it.
- jcgl 1y ago
  It does protect the build machine though. Seems like quality, low-hanging security fruit to me. If I want to casually hack on some random web app, I don’t have to worry about giving arbitrary scripts running from the ~4 gazillion dependencies.
- mnahkies 1y ago
  I agree but there's a bit of nuance here. Today scanning steps typically happen post install, which is wild but the status quo. Therefore preventing anything from running during install is desirable. I'd like to see the ability to scan/restrict as part of the installation step become popular, there are some proprietary tools that do this already but it's not yet a common capability.
  - MetaWhirledPeas 1y ago
    Yes. For instance when we had that crypto malware npm fiasco a few days back I happened to be updating one of my packages. The audit lit up with dozens of critical issues, but of course this was after it installed everything. Luckily I had disabled install scripts so it became a matter of not running the code until I could get it reverted back.
User23 1y ago
Has there been a supply chain attack with an LLM conduit yet? Because that would be spicy and is assuredly possible and plausible too.
deleted 1y ago
[deleted]
oulipo2 1y ago
"The other packages help us build the app and never ship to users, e.g. esbuild or eslint." Still, they can present a security risk by injecting malware at build time
testfrequency 1y ago
It has been so rewarding and timely to see this post. I just decided on Thursday after years of covering my ears and eyes from my obsidian-obsessed friends and coworkers that the tool just didn’t make sense to me, and I felt like I’d be in plugin purgatory on my computer for eternity. I’ve ended up going with Reflect, after ~forever using Apple Notes primarily. So far so good, but I genuinely felt for so long I was supposed to love Obsidian because that’s the trope - appears that’s changing.
OhMeadhbh 1y ago
I've been focused on writing software the last couple of weeks. What is obsidian again? I can't find a simple "what is obsidian?" FAQ on their site. Is it a browser or a node replacement like deno? Or an AI library? Clearly obsidian has plugins, but what are they in service of? If it's a browser, they should have something on their web site that says "obsidian is a really cool browser." I think there are a lot of people out there who are ignoring the hype-train and it would do the community a service if they just started with answering that simple question. I mean sure, I get it, it's a "sharpen your thinking app," but I'm not sure what that means.
- smodo 1y ago
  It’s a notetaking app.
  - OhMeadhbh 1y ago
    Thanks.
dankobgd 1y ago
It's kind of weird to use word "less" for software that does million things instead of being a simple note taking tool.
nylonstrung 1y ago
How much supply chain vulnerability can be mitigated just by pinning known safe versions of dependencies Did anyone need the newest xz version in the first place? What negative tradeoffs would have come from pinning a 2022 release for example
- deafpolygon 1y ago
  Depends on the pinned version. The pinned version might even have vulnerabilities themselves. The problem is trusting the ecosystem.
hexo 1y ago
Really? Is this some kind of perverted joke? Electron based thing wants to brag about less being safer? Get rid of the browser, then we can talk about less. Unbelievable
ptx 1y ago
An alternative for those who want a native application and/or even less supply-chain risk is Zim [1], which uses GTK and is packaged by the major Linux distributions. [1] https://zim-wiki.org/ https://zim-wiki.org/
- huimang 1y ago
  Zim doesn't have a native phone app and syncing, though, and that's a big draw of Obsidian. It's plenty secure if you don't install plugins all willy-nilly.
Mikhail_K 1y ago
[flagged]
- selfmodruntime 1y ago
  It also looks and feels the exact same on every platform I use it on and natively supports accessibility.
  - deleted 1y ago
    [deleted]
  - abdullahkhalids 1y ago
    It's amazing how Google, Mozilla, Apple, etc can collaborate to come up with web standards, so they can ship browsers that display apps/webpages pretty much the same across multiple platforms. But Microsoft, Apple, Canonical, Google, etc can't collaborate to come up with apis that allow everyone to make desktop apps once and they display mostly the same on all platforms.
CMay 1y ago
On the other hand, their actual dependency list looks closer to this, and this is definitely not comprehensive: https://github.com/ionic-team/capacitor https://github.com/ionic-team/capacitor https://github.com/Microsoft/tslib https://github.com/Microsoft/tslib https://github.com/codemirror https://github.com/codemirror https://github.com/codemirror/autocomplete https://github.com/codemirror/autocomplete https://github.com/codemirror/language https://github.com/codemirror/language https://github.com/marijnh/style-mod https://github.com/marijnh/style-mod https://github.com/marijnh/crelt https://github.com/marijnh/crelt https://github.com/marijnh/find-cluster-break https://github.com/marijnh/find-cluster-break https://github.com/marijnh/w3c-keyname https://github.com/marijnh/w3c-keyname https://github.com/cure53/DOMPurify https://github.com/cure53/DOMPurify https://github.com/electron/electron https://github.com/electron/electron https://github.com/electron/get https://github.com/electron/get https://github.com/debug-js/debug https://github.com/debug-js/debug https://github.com/vercel/ms https://github.com/vercel/ms https://github.com/sindresorhus/env-paths https://github.com/sindresorhus/env-paths https://github.com/sindresorhus/got https://github.com/sindresorhus/got https://github.com/sindresorhus/is https://github.com/sindresorhus/is https://github.com/visionmedia/node-progress https://github.com/visionmedia/node-progress https://github.com/npm/node-semver https://github.com/npm/node-semver https://github.com/malept/sumchecker https://github.com/malept/sumchecker https://github.com/szmarczak/http-timer https://github.com/szmarczak/http-timer https://github.com/szmarczak/defer-to-connect https://github.com/szmarczak/defer-to-connect https://github.com/szmarczak/cacheable-lookup https://github.com/szmarczak/cacheable-lookup https://github.com/jaredwray/cacheable https://github.com/jaredwray/cacheable https://github.com/biomejs/biome https://github.com/biomejs/biome https://github.com/sindresorhus/decompress-response https://github.com/sindresorhus/decompress-response https://github.com/sindresorhus/mimic-response https://github.com/sindresorhus/mimic-response https://github.com/octet-stream/form-data-encoder https://github.com/octet-stream/form-data-encoder https://github.com/szmarczak/http2-wrapper https://github.com/szmarczak/http2-wrapper https://github.com/szmarczak/resolve-alpn https://github.com/szmarczak/resolve-alpn https://github.com/sindresorhus/lowercase-keys https://github.com/sindresorhus/lowercase-keys https://github.com/sindresorhus/p-cancelable https://github.com/sindresorhus/p-cancelable https://github.com/sindresorhus/responselike https://github.com/sindresorhus/responselike https://github.com/sindresorhus/type-fest https://github.com/sindresorhus/type-fest https://github.com/sindresorhus/tagged-tag https://github.com/sindresorhus/tagged-tag https://github.com/max-mapper/extract-zip https://github.com/max-mapper/extract-zip https://github.com/sindresorhus/get-stream https://github.com/sindresorhus/get-stream https://github.com/Sec-ant/readable-stream https://github.com/Sec-ant/readable-stream https://github.com/sindresorhus/is-stream https://github.com/sindresorhus/is-stream https://github.com/thejoshwolfe/yauzl https://github.com/thejoshwolfe/yauzl https://github.com/brianloveswords/buffer-crc32 https://github.com/brianloveswords/buffer-crc32 https://github.com/andrewrk/node-pend https://github.com/andrewrk/node-pend https://github.com/i18next/i18next https://github.com/i18next/i18next https://github.com/babel/babel https://github.com/babel/babel https://github.com/microsoft/TypeScript https://github.com/microsoft/TypeScript https://github.com/lezer-parser https://github.com/lezer-parser https://github.com/lucide-icons/lucide https://github.com/lucide-icons/lucide https://github.com/mathjax/MathJax https://github.com/mathjax/MathJax https://github.com/mermaid-js/mermaid https://github.com/mermaid-js/mermaid https://github.com/moment/moment https://github.com/moment/moment https://github.com/mozilla/pdf.js https://github.com/mozilla/pdf.js https://github.com/pixijs/pixijs https://github.com/pixijs/pixijs https://github.com/mapbox/earcut https://github.com/mapbox/earcut https://github.com/primus/eventemitter3 https://github.com/primus/eventemitter3 https://github.com/matt-way/gifuct-js https://github.com/matt-way/gifuct-js https://github.com/matt-way/jsBinarySchemaParser https://github.com/matt-way/jsBinarySchemaParser https://github.com/kaimallea/isMobile https://github.com/kaimallea/isMobile https://github.com/browserslist/caniuse-lite https://github.com/browserslist/caniuse-lite https://github.com/jkroso/parse-svg-path https://github.com/jkroso/parse-svg-path https://github.com/avoidwork/tiny-lru https://github.com/avoidwork/tiny-lru https://github.com/PrismJS/prism/ https://github.com/PrismJS/prism/ https://github.com/mourner/rbush https://github.com/mourner/rbush https://github.com/mourner/quickselect https://github.com/mourner/quickselect https://github.com/remarkjs/remark https://github.com/remarkjs/remark https://github.com/hakimel/reveal.js https://github.com/hakimel/reveal.js https://github.com/barrysteyn/node-scrypt https://github.com/barrysteyn/node-scrypt https://github.com/nodejs/nan https://github.com/nodejs/nan https://github.com/mixmark-io/turndown https://github.com/mixmark-io/turndown https://github.com/mixmark-io/domino https://github.com/mixmark-io/domino https://github.com/webpack/webpack https://github.com/webpack/webpack https://github.com/acornjs/acorn https://github.com/acornjs/acorn https://github.com/nicolo-ribaudo/acorn-import-phases https://github.com/nicolo-ribaudo/acorn-import-phases https://github.com/browserslist/browserslist https://github.com/browserslist/browserslist https://github.com/web-platform-dx/baseline-browser-mapping https://github.com/web-platform-dx/baseline-browser-mapping https://github.com/kilian/electron-to-chromium https://github.com/kilian/electron-to-chromium https://github.com/chicoxyzzy/node-releases https://github.com/chicoxyzzy/node-releases https://github.com/browserslist/update-db https://github.com/browserslist/update-db https://github.com/lukeed/escalade https://github.com/lukeed/escalade https://github.com/alexeyraspopov/picocolors https://github.com/alexeyraspopov/picocolors https://github.com/samccone/chrome-trace-event https://github.com/samccone/chrome-trace-event https://github.com/webpack/enhanced-resolve https://github.com/webpack/enhanced-resolve https://github.com/isaacs/node-graceful-fs https://github.com/isaacs/node-graceful-fs https://github.com/webpack/tapable https://github.com/webpack/tapable https://github.com/guybedford/es-module-lexer https://github.com/guybedford/es-module-lexer https://github.com/eslint/js https://github.com/eslint/js https://github.com/browserify/events https://github.com/browserify/events https://github.com/fitzgen/glob-to-regexp https://github.com/fitzgen/glob-to-regexp https://github.com/isaacs/node-graceful-fs https://github.com/isaacs/node-graceful-fs https://github.com/npm/json-parse-even-better-errors https://github.com/npm/json-parse-even-better-errors https://github.com/webpack/loader-runner https://github.com/webpack/loader-runner https://github.com/jshttp/mime-types https://github.com/jshttp/mime-types https://github.com/jshttp/mime-db https://github.com/jshttp/mime-db https://github.com/suguru03/neo-async https://github.com/suguru03/neo-async https://github.com/webpack/schema-utils https://github.com/webpack/schema-utils https://github.com/ajv-validator/ajv https://github.com/ajv-validator/ajv https://github.com/epoberezkin/fast-deep-equal https://github.com/epoberezkin/fast-deep-equal https://github.com/fastify/fast-uri https://github.com/fastify/fast-uri https://github.com/epoberezkin/json-schema-traverse https://github.com/epoberezkin/json-schema-traverse https://github.com/floatdrop/require-from-string https://github.com/floatdrop/require-from-string https://github.com/ajv-validator/ajv-formats https://github.com/ajv-validator/ajv-formats https://github.com/ajv-validator/ajv-keywords https://github.com/ajv-validator/ajv-keywords https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/webpack-contrib/terser-webpack-plugin https://github.com/webpack-contrib/terser-webpack-plugin https://github.com/jridgewell/sourcemaps https://github.com/jridgewell/sourcemaps https://github.com/jestjs/jest https://github.com/jestjs/jest https://github.com/yahoo/serialize-javascript https://github.com/yahoo/serialize-javascript https://github.com/browserify/randombytes https://github.com/browserify/randombytes https://github.com/terser/terser https://github.com/terser/terser https://github.com/tj/commander.js https://github.com/tj/commander.js https://github.com/evanw/node-source-map-support https://github.com/evanw/node-source-map-support https://github.com/LinusU/buffer-from https://github.com/LinusU/buffer-from https://github.com/mozilla/source-map https://github.com/mozilla/source-map https://github.com/webpack/watchpack https://github.com/webpack/watchpack https://github.com/webpack/webpack-sources https://github.com/webpack/webpack-sources https://github.com/eemeli/yaml https://github.com/eemeli/yaml
bergheim 1y ago
> Obsidian has a low number of dependencies compared to other apps in our category Whataboutism. Relative comparisons don't address absolute risk. I checked three random packages: prism pulls 22, remark pulls 51, pixijs 179! So that's 250+ transitive dependencies just from those. > Features like Bases and Canvas were implemented from scratch instead of importing off-the-shelf libraries. This gives us full control over what runs in Obsidian. Full control? There are still hundreds of dependencies. > This approach keeps our dependency graph shallow with few sub-dependencies. A smaller surface area lowers the chance of a malicious update slipping through. Really? Again, this is just one package: https://npmgraph.js.org/?q=pixijs https://npmgraph.js.org/?q=pixijs > The other packages help us build the app and never ship to users, e.g. esbuild or eslint. Build tools like esbuild don't ship to users, but a compromised build tool can still inject malicious code during compilation. This is supply chain security 101. > All dependencies are strictly version-pinned and committed with a lockfile Version pinning is, I would hope, standard practice in any professional development team years and years ago. It prevents accidental updates but doesn't stop compromised existing versions. > When we do dependency updates, we: > [snip] While these practices are better than nothing, they don't fundamentally address the core issue. > That gap acts as an early-warning window: the community and security researchers often detect malicious versions quickly According to whom? Heartbleed, a vulnerability in a package with far more scrutiny than a typical npm module took what, 2 years to be found? The "community detection" assumption is flawed. I'm not trying to put Obsidian down here - I sympathize, aside from implementing everything themselves, what can they do! I'm trying to point out that while their intent is good, this is a serious problem and their solution is not a solution. Of course, it's the same in any project with dependencies. It's the same in other languages as well - if they have a convenient package manager. Like Rust and Cargo. This problem came with the convenience of package managers and it should be fixed there, not by every application like Obsidian. I'm not sure how but maybe once a package is starting to become popular, additional security measures must be put in place for the author to be able to continue to commit to it. Signing requirements, reproducible builds, 2fa, community reputation systems, who knows. Individual applications can't solve supply chain security through wishful thinking and version pinning. Package managers need to solve this at the infrastructure level through measures like mandatory code signing, automated security auditing, dependency isolation, or similar system level approaches. Obsidian's practices are reasonable given the current tooling limitations, but they don't eliminate the fundamental risks that the package managers bring to modern dependency ecosystems.
saltserv 1y ago
[dead]
zvmaz 1y ago
I use Emacs and Org-Roam, and some Emacs packages. It is hosted in a VM that is not connected to the internet (a Qube in Qubes OS). I just cannot review all the code running in Emacs.
doodlesdev 1y ago
> Only a handful of packages are part of the app you run, e.g. Electron, CodeMirror, moment.js. So they ship an extremely bloated package to ship a WebView based on one of the most complex pieces of software ever written, an entire code editor for text editing, and a deprecated time library that could be substituted by newer APIs and some glue code? Honestly, it doesn't seem impressive at all. What Obsidian does is the bare minimum of how we should manage packages in any piece of software, not a testament to a serious security policy. They do security audits, though, which I find to be a good practice.
runningmike 1y ago
“ Supply chain attacks are malicious updates that sneak into open source code used by many apps.” No! This should be: Supply chain attacks are malicious updates that sneak into source code used by many apps. Stop blaming FOSS. Too many people still have the perception that FOSS software is insecure
mooreds 1y ago
I was talking to our chief architect about a blog post about our zero dependency home grown HTTP server[0]; the project just hit 1.2 and uses virtual threads. I'm generally a fan of "don't reinvent the wheel"[1], but I think there are some cases where that control is worth the cost. Defending against security vulnerabilities is definitely one of them, as long as you make the proper investments to harden what you write. Joel Spolsky write about some other reasons too[2]. 0: https://github.com/FusionAuth/java-http https://github.com/FusionAuth/java-http 1: https://en.wikipedia.org/wiki/Reinventing_the_wheel https://en.wikipedia.org/wiki/Reinventing_the_wheel 2: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...
elcapitan 1y ago
I went from Evernote to Joplin to Obsidian and really like the model of md files with some logic added on top. Initially I used a lot of plugins mostly out of curiosity, but now it's mostly RemotelySave for syncing and some small convenience plugins, so I hope my exposure isn't too high. The app doesn't have the bloaty feel of other Electron apps, but if there was a good more native alternative that fits my bill (md files editable in a graphical mode with good wikilink-syntax support and similar search etc), then I would actually consider switching.
daft_pink 1y ago
I’m pretty sure them rewriting things themselves has resulted in its speed. The great thing about obsidian is how fast it is compared to Notion.
gchamonlive 1y ago
Wonder if we could make the case that simpler always leads to less in favor of lean apps

522 points by saeedesmaili 1y ago

amai 1y ago

Is that the reason why Obsidian does not support the https://textbundle.org/ https://textbundle.org/ format for import/export like any other markdown editor?

kepano 1y ago
for import it does: https://help.obsidian.md/import/textbundle https://help.obsidian.md/import/textbundle for export it's the same reason many features don't exist yet — the team only has 3 full time developers

apitman 1y ago

Love it. Jonathan Blow had a nice thread about dependencies a while back: https://x.com/Jonathan_Blow/status/1924509394416632250 https://x.com/Jonathan_Blow/status/1924509394416632250

brandonspark 1y ago

missed opportunity for "less is secure"

mpalmer 1y ago
"Secure" is a different, harder promise than safeR.
- brandonspark 1y ago
  but still along the same lines as "safer". the stresses are different, "safer" has the stress as "SAY-fer" and "secure" has the stress as "sih-KYOOR". the latter sounds more similar (and rhymes better) with "more", the originator of the phrase "less is more"
  - mpalmer 1y ago
    Well uh sure if meter's all you're going for here

system7rocks 1y ago

I’ve been using other apps than Obsidian for notes and sharing, so this is nice to read and consider. But isn’t Obsidian an electron app or whatever? Electron has always seemed resource intensive and not native. JavaScript has never struck me as “secure”. Am I just out of touch?

GabeIsko 1y ago
If you have to render html, which is what markdown ultimately becomes, you might as well use a web broswer.
anon7000 1y ago
JavaScript is a very secure language. The browser is a massive success at running secure JavaScript on a global scale. Every website you use is running JavaScript and not able to read other site data. Electron is the same, running v8 to sandbox JavaScript. Assuming you aren't executing user input inside that sandbox (something many programming languages allow, including JS), it's very secure. The problem with supply chain attacks is specifically related to npm, and not related to JS. npm as an organization needs to be taking more responsibility for the recent attacks and essentially forcing everyone to use more strict security controls when publishing their dependencies.
- asgraham 1y ago
  Doesn’t this mean browser sandboxing is secure, not JS? Or are you referring to some specific aspect of JS I’m not aware of? (I’m not aware of a lot of JS) It’s maybe a nit-pick, since most JS is run sandboxed, so it’s sort of equivalent. But it was explicitly what GP asked for. Would it be more accurate to say Electron is secure, not JS?
  - dalmo3 1y ago
    I'm really curious about this comment. What would it mean for a programming language to be secure? Any two Turing-complete programming languages are equally secure, no? Surely the security can only ever come from whatever compiles/interprets it? You can run JavaScript on a piece of paper.

montroser 1y ago

Yes, you are responsible for all the code you ship to your users. Not pinning dependencies is asking for trouble. It is literally, "download random code from the Internet and hope for the best."

lelandfe 1y ago
Pinned dependencies usually have their own dependencies so you are generally always downloading random code and hoping. I mean, jeeze, how much code comes along for the ride with Electron...
- cosmic_cheese 1y ago
  The real answer is to minimize dependencies (and subdependencies) to the greatest extent practical. In some cases you can get by with surprisingly few without too much pain (and in the long run, maybe less pain than if you'd pulled in more).
  - Scramblejams 1y ago
    Yep, and for the rest I've gotten a lot of mileage, when shipping server apps, by deploying on Debian or Ubuntu* and trying to limit my dependencies to those shipped by the distro (not snap). The distro security team worries about keeping my dependencies patched and I'm not forced to take new versions until I have to upgrade to the next OS version, which could be quite a long time. It's a great way to keep lifecycle costs down and devops QoL up, especially for smaller shops. *Insert favorite distro here that backports security fixes to stable package versions for a long period of time.
- chrisweekly 1y ago
  No. "Always downloading random code and hoping" is not the only option. Even w/ the supply-chain shitshow that the public npmjs registry has become, using pnpm and a private registry makes it possible to leverage a frozen lockfile that represents the entire dependency graph and supports vulnerability-free reproducible builds. EDIT to add: Of course, reaching a state where the whole graph is free of CVEs is a fleeting state of affairs. Staying reasonably up-to-date and using only scanned dependencies is an ongoing process that takes more effort and attention to detail than many projects are willing or able to apply; but it is possible.

platers 1y ago

What about the third party extensions?

montroser 1y ago

This is obviously the way to do it, assuming you have the skills and resources to operate in this manner. If you don't, then godspeed, but you have to know going in that you are trading expediency now for risk later. Risk of performance issues, security vulnerabilities, changes in behavior, etc. And when the mess inevitably comes, at whatever inopportune time, you don't really get to blame other people...

doesnt_know 1y ago

Going to preface this post by saying I use and love Obsidian, my entire life is effectively in an Obsidian vault, I pay for sync and as a user I'm extremely happy with it. But as a developer this post is nonsense and extremely predictable [1]. We can expect countless others like it that explains how their use of these broken tools is different and just don't worry about it! By their own linked Credits page there are 20 dependencies. Let's take one of those, electron, which itself has 3 dependencies according to npm. Picking one of those electron/get has 7 dependencies. One of those dependencies got, has 11 dependencies, one of those cacheable-request has 7 dependencies etc etc. Now go back and pick another direct dependency of Obsidian and work your way down the dependency tree again. Does the Obsidian team review all these and who owns them? Do they trust each layer of the chain to pick up issues before it gets to them? Any one of these dependencies can be compromised. This is what it means to be. supply chain attack, you only have to quietly slip something into any one of these dependencies to have access to countless critical user data. [1] https://drewdevault.com/2025/09/17/2025-09-17-An-impossible-future-for-JS.html https://drewdevault.com/2025/09/17/2025-09-17-An-impossible-...

dsissitka 1y ago
Coincidentally I did that yesterday. Mermaid pulls in 137 dependencies. I love Obsidian and the Obsidian folks seem like good people but I did end up sandboxing it.
PhilipRoman 1y ago
To be fair, the electron project likely invests some resources in reviewing it's own dependencies, because of its scale. But yeah this is a good exercise, I think we need more systems like Yocto which prioritize complete understanding of the entire product from source.

deleted 1y ago

[deleted]

gejose 1y ago

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".

justsomehnguy 1y ago
> Obsidian plugins have full, unrestricted access to all files in the vault. And how exactly you can solve that? I don't want to press 'allow access' on the every file some plugin is accessing.
- schmichael 1y ago
  One of the large dependencies they call out is an excellent example: pdf.js. There is no reason for pdf.js to ever access anything other than the files you wish to export. The Export to PDF process could spawn a containerized subprocess with 0 filesystem or network access and constrained cpu and memory limits. Files could sent to the Export process over stdin, and the resulting PDF could be streamed back over stdout with stderr used for logging. There are lots of plugin systems that work this way. I wish it were commodofied and universally available. AFAIK there's very little cross-platform tooling to help you solve this problem easily, and that's a pity.
- gejose 1y ago
  Specific permissions declared in a manifest much like browser extensions could be a good first step.
gjsman-1000 1y ago
That just sounds like Linux packages; also not a system known for security of desktop apps and scripts especially compared to MacOS, shoot me.

scuff3d 1y ago

This doesn't make any sense to me. I've always been told you don't write anything yourself unless you absolutely have to and having a million micro-dependencies is a good thing. JavaScript and now Rust devs have been saying this for years. Surely they know what they're doing...

elric 1y ago
There is a balance to be struck. NPM in particular has been a veritable dependency hell for a long time. I don't know if it just attracts inexperienced developers, or if its security model is fundamentally flawed, but there have been soooo many supply chain attacks using NPM that being extra careful is very much warranted.
- scuff3d 1y ago
  Right, I get that. I was just making a joke because I really dislike the micro-dependency approach. Honestly bothers me more in Rust then JavaScript, but that's probably just because I'm not a web dev. From my buddies who have worked in JS my understanding is that a lot of it is rooted in JavaScript having a really shitty standard library for a long time. So that lead to a culture of code sharing early on since everyone was rewriting the same utilities and what not. Which evolved into the package management ecosystem over time. Why that came about in something like JavaScript but not C, which also obviously has a really small std is super interesting. My only guess is that JavaScript came up in the internet when package managers started to take on a new meaning, and web dev is more relavent to a broader range of (nontech) companies and they're more likely to put a huge focus on quality over quantity.

profsummergig 1y ago

I love Obsidian and wish I could make it my default markdown handler on Windows. While we're on the topic: what's your default markdown handler on Windows?

password4321 1y ago
Not my favorite but I was surprised recently when Windows 11 Notepad popped up something mentioning markdown support.

system2 1y ago

I wish they could add Google Drive support to their mobile app. I'd be happy to pay $100+ for one-time-only Google Drive support.

qntmfred 1y ago

If the obsidian team did a 2 hour q&a livestream every week, I'd watch every one (or at least get the AI summary). One of my favorite pieces of software ever.

callc 1y ago
I recently had a similar experience using Libby for the first time. An absolutely incredible piece of software. If anyone here on HN works on it, you deserve to be proud of your work.
- 2dvisio 1y ago
  Fully agree. Libby is awesome!

groby_b 1y ago

I love Obsidian dearly, but if you build an app that's only really useful with plugins, and that has a horrifyingly bad security model for plugins and little to no assurance of integrity of the plugins... Maybe, just maybe, don't give fullmouthed advice on reducing risk in the supply chain.

MonaroVXR 1y ago
But what about VScode?
- groby_b 1y ago
  Do you hear the VSCode team talk about supply chain security?

kid64 1y ago

'It may sound obvious but the primary way we reduce the risk of supply chain attacks is to avoid depending on third-party code." What a horribly disingenuous statement, for a product that isn't remotely usable without 3rd-party plugins. The "Obsidian" product would be more aptly named "Mass Data Exfiltration Facilitator Pro".

freddie_mercury 1y ago
I've used Obsidian for years without a single 3rd party plugin. It is possible to make your same point without histrionic excess.
- kid64 1y ago
  Yeah, this is always the response. Usability can be assessed objectively, so you just have low standards.
  - Capricorn2481 1y ago
    I have to agree that I don't find plugins necessary, and I'm not sure why you're so down on people using a solid backlinking note taker. I don't think I have low standards, I think Roam and Logseq aren't that great and Obsidian is all I need.
  - maxbond 1y ago
    A more charitable interpretation would be that that have different needs. My keyboard costs more than my computer, but most people probably spend $15-$50 on a keyboard. Even my mouse is well outside that range. Do I have high standards or do I have tendonitis?
    - kid64 1y ago
      Software usability, in this context, is measured objectively, there is no interpretation. This is separate from a specific user's preferences, the ergonomics of their hardware, etc.. As for your high standards vs tendonitis distinction, I'd say these things are not mutually exclusive, and the comparison is not related to what we're talking about.

deleted 1y ago

[deleted]

Mountain_Skies 1y ago

Absolutely love Obsidian but had to stop using it because Electron apps don't play well with Wayland. After lots of tinkering around with flags and settings for compatibility layers, it became obvious that it would never work seamlessly like it did on Windows (and probably does on x11). So it was either give up Wayland compositors or give up Obsidian. Luckily I don't use any plugins, so moving to other software was easy, but I still would prefer Obsidian. Electron's "works everywhere" works about as good as Java's "works everywhere", which is to say it works great, until it doesn't, at which point it's a mess of tinkering. If you use Wayland and it works for you, that's great, but it's not my experience.

lyu07282 1y ago
In my experience electron + Wayland was absolutely god awful for a long time, but it got dramatically better in the last 4-5ish months. So depending on when you last tried it, might be worth a revisit. Heavily depends on which GPU+DE though, Nvidia+Plasma here.
yoavm 1y ago
What issues are you seeing? Haven't noticed the slightest glitch here, using Sway.

pier25 1y ago

I also recommend using this site to evaluate the dependencies of your dependencies: https://npmgraph.js.org/?q=express https://npmgraph.js.org/?q=express

lyu07282 1y ago

> The other packages help us build the app and never ship to users, e.g. esbuild or eslint. Eslint with such wonderful dependencies like is-glob smh

arigatoarigato 1y ago

[dead]

brentm 1y ago

I've been using Roam Research since about 2020. Is Obsidian better?

photon_garden 1y ago
Haven’t used Roam, but what I like about Obsidian: - All your data is just plain files on your file system. Automation and interop are great, including with tools like Claude Code. - It’s local-first, so performance is good. - It’s extensible. Write extensions in HTML, CSS, and JS. - It’s free. - Syncing files is straightforward. Use git, Syncthing, Google Drive, or pay for their cheap sync service which is quite good. - Product development is thoughtful and well done. - They’re explicitly not trying to lock you in or own your data. They define open specs and build on them when Markdown doesn’t cut it. Things you might not like: - Their collaboration story isn’t great yet. No collaborative editing. - It’s an Electron app.
- TiredOfLife 1y ago
  In what universe is their sync service cheap? It's literally at least 100 times more expensive that Dropbox/OneDrive/Google Drive/iCloud sync
  - photon_garden 1y ago
    My assumption is that most people on HN are making programmer money. $4 - 5 USD per month is affordable even on a junior engineer’s salary in many parts of the world. The price per GB isn’t as good as the services you mentioned, but their storage limits are fine for the primary use case — storing a lot of plain text notes. I’ve also had no problems with it, in contrast with iCloud which has routinely gotten stuck for me. And if price per GB is what you care most about, use something else. That’s one of the great things about Obsidian.
- deafpolygon 1y ago
  The plain text thing is more of a feel-good argument than a practical one. If there’s a solid export path, the format isn’t really the issue... what matters is whether the app actually works the way you need it to. At the end of the day, your workflow lives or dies on how the software behaves... not on the file extension.

withinrafael 1y ago

Was hoping they outlined their approach to handling potentially compromised packages running on dev machines prior to even shipping. That seems like a much harder problem to solve.

mikeocool 1y ago

> We don’t rush upgrades. Can’t wait for “implements mechanism to delay application of new patches” to start showing up compliance checklists. My procrastination will finally pay off!

aborsy 1y ago

I installed an AppArmor profile for Obsidian. For an application that displays text files, it needed a lot of permissions. It would refuse to run without network access. You can install Obsidian flatpak and lock it down with flatseal.

neilv 1y ago

These practices are very similar to what I've done in the past, for a large, sensitive system, and they worked very well. (IIUC, we actually were the first to get a certain certification for cloud deployment, maybe because we had a good handle on this and other factors.) From the language-specific network package manager, I pulled the small number of third-party packages we used into the filesystem tree of system's repo, and audited each new version. And I disabled the network package manager in the development and deployment environments, to make it much harder for people to add in dependencies accidentally. Dependencies outside this were either from the Linux distro (nice, because well-managed security updates), or go in the `vendor` or `ots` (off-the-shelf) trees of the repo (and are monitored for security updates). Though, I look at some of the Python, JS, or Rust dependency explosions I sometimes see -- all dependent on being hooked up to the language's network package manager, with many people adding these cavalierly -- and it becomes a much harder problem.

joshdavham 1y ago

There’s some advice that’s been going around lately that I’ve been having trouble understanding: the idea that you should not be updating your dependencies when new patches are released (e.g., X.X.PATCH). I understand that not updating your dependencies when new patches are released reduces the chance of accidentally installing malware, but aren’t patches regularly released in order to improve security? Wouldn’t it generally be considered unwise to not install new patches?

flanbiscuit 1y ago
I believe it's about waiting a bit before a new patch is released, not fully avoiding installing updates. Seems like compromises are being caught quickly these days, usually within hours. There are multiple companies monitoring npm package releases because they sell security scanning products and so it's part of their business to be on top of it. pnpm has a setting that you can tell it that a package needs to be at least X minutes old in order to install it. I would wait at least 24 hours just to be safe https://pnpm.io/settings#minimumreleaseage https://pnpm.io/settings#minimumreleaseage
RadiozRadioz 1y ago
There's a key missing piece to this puzzle: being informed about _why_ you're updating and what the patches are. Nobody has time to read source code, but there are many tools and services that will tell you brief summaries of release notes. Npm Audit lists security vulnerabilities in your package versions for example. I do adopt the strategy of not updating unless required, as updates are not only an attack vector, but also an extremely common source of bugs that'd I'd prefer to avoid. But importantly I stay in the loop about what exploits I'm vulnerable to. Packages are popping up with vulnerabilities constantly, but if it's a ReDoS vulnerability in part of the package I definitely don't use or pass user input to? I'm happy to leave that alone with a notice. If it's something I'm worried another package might use unsafely, with knowledge of the vulnerability I can decide how important it is, and if I need to update immediately, or if I can (preferably) wait some time for the patch to cook in the wild. That is the important thing to remember about security in this context: it is an active, continuous, process. It's something that needs to be tuned to the risk tolerance and risk appetite of your organisation, rather than a blanket "never update" or "always update" - for a well-formed security stance, one needs more information than that.

eviks 1y ago

No mention of plugins, which are a core differentiator of Obsidian, so part of the overall "supply chain" for the app.

xenator 1y ago

To be honest, right now I'm thinking about isolating of build process for frontend on my local environment. It is seems not hard to send my local environment variables like OPENAI_API_KEY or .ssh/* to some remote machine. I know it is not very different comparing to python or projects in any other language. But I don't feel that I cannot trust node/js community at this point.

hahn-kev 1y ago
Running vite inside a docker container would probably get you what you want
- N2yhWNXQN3k9 1y ago
  I don't think you even need a container for that type of containment. You could do it with namespaces. I think node/whatever-js-run-time/package-manger could allow for namespaced containment for packages with simple modern linux things. The realms proposal was a step towards that at one time.
mark_and_sweep 1y ago
Switching to Deno might help. It's sandboxed by default and offers granular escape hatches. So if a script needs access to a specific environment variable or read or write specific files, it's simple to configure that only those accesses are allowed.

darkamaul 1y ago

> We do not run postinstall scripts. This prevents packages from executing arbitrary code during installation. I get the intent, but I’m not sure this really buys much. If a package is compromised, the whole thing is already untrustworthy and skipping postinstall doesn’t suddenly make the rest of the code safe. If it isn’t compromised, then you risk breaking legitimate installation steps. From a security perspective, it feels like an odd tradeoff. I don’t have hard data, but I’d wager we see far more vulnerabilities patched through regular updates than actual supply-chain compromises. Delaying or blocking updates in general tends to increase your exposure rather than reduce it.

jcgl 1y ago
It does protect the build machine though. Seems like quality, low-hanging security fruit to me. If I want to casually hack on some random web app, I don’t have to worry about giving arbitrary scripts running from the ~4 gazillion dependencies.
mnahkies 1y ago
I agree but there's a bit of nuance here. Today scanning steps typically happen post install, which is wild but the status quo. Therefore preventing anything from running during install is desirable. I'd like to see the ability to scan/restrict as part of the installation step become popular, there are some proprietary tools that do this already but it's not yet a common capability.
- MetaWhirledPeas 1y ago
  Yes. For instance when we had that crypto malware npm fiasco a few days back I happened to be updating one of my packages. The audit lit up with dozens of critical issues, but of course this was after it installed everything. Luckily I had disabled install scripts so it became a matter of not running the code until I could get it reverted back.

User23 1y ago

Has there been a supply chain attack with an LLM conduit yet? Because that would be spicy and is assuredly possible and plausible too.

deleted 1y ago

[deleted]

oulipo2 1y ago

"The other packages help us build the app and never ship to users, e.g. esbuild or eslint." Still, they can present a security risk by injecting malware at build time

testfrequency 1y ago

It has been so rewarding and timely to see this post. I just decided on Thursday after years of covering my ears and eyes from my obsidian-obsessed friends and coworkers that the tool just didn’t make sense to me, and I felt like I’d be in plugin purgatory on my computer for eternity. I’ve ended up going with Reflect, after ~forever using Apple Notes primarily. So far so good, but I genuinely felt for so long I was supposed to love Obsidian because that’s the trope - appears that’s changing.

OhMeadhbh 1y ago

I've been focused on writing software the last couple of weeks. What is obsidian again? I can't find a simple "what is obsidian?" FAQ on their site. Is it a browser or a node replacement like deno? Or an AI library? Clearly obsidian has plugins, but what are they in service of? If it's a browser, they should have something on their web site that says "obsidian is a really cool browser." I think there are a lot of people out there who are ignoring the hype-train and it would do the community a service if they just started with answering that simple question. I mean sure, I get it, it's a "sharpen your thinking app," but I'm not sure what that means.

smodo 1y ago
It’s a notetaking app.
- OhMeadhbh 1y ago
  Thanks.

dankobgd 1y ago

It's kind of weird to use word "less" for software that does million things instead of being a simple note taking tool.

nylonstrung 1y ago

How much supply chain vulnerability can be mitigated just by pinning known safe versions of dependencies Did anyone need the newest xz version in the first place? What negative tradeoffs would have come from pinning a 2022 release for example

deafpolygon 1y ago
Depends on the pinned version. The pinned version might even have vulnerabilities themselves. The problem is trusting the ecosystem.

hexo 1y ago

Really? Is this some kind of perverted joke? Electron based thing wants to brag about less being safer? Get rid of the browser, then we can talk about less. Unbelievable

ptx 1y ago

An alternative for those who want a native application and/or even less supply-chain risk is Zim [1], which uses GTK and is packaged by the major Linux distributions. [1] https://zim-wiki.org/ https://zim-wiki.org/

huimang 1y ago
Zim doesn't have a native phone app and syncing, though, and that's a big draw of Obsidian. It's plenty secure if you don't install plugins all willy-nilly.

Mikhail_K 1y ago

[flagged]

selfmodruntime 1y ago
It also looks and feels the exact same on every platform I use it on and natively supports accessibility.
- deleted 1y ago
  [deleted]
- abdullahkhalids 1y ago
  It's amazing how Google, Mozilla, Apple, etc can collaborate to come up with web standards, so they can ship browsers that display apps/webpages pretty much the same across multiple platforms. But Microsoft, Apple, Canonical, Google, etc can't collaborate to come up with apis that allow everyone to make desktop apps once and they display mostly the same on all platforms.

CMay 1y ago

On the other hand, their actual dependency list looks closer to this, and this is definitely not comprehensive: https://github.com/ionic-team/capacitor https://github.com/ionic-team/capacitor https://github.com/Microsoft/tslib https://github.com/Microsoft/tslib https://github.com/codemirror https://github.com/codemirror https://github.com/codemirror/autocomplete https://github.com/codemirror/autocomplete https://github.com/codemirror/language https://github.com/codemirror/language https://github.com/marijnh/style-mod https://github.com/marijnh/style-mod https://github.com/marijnh/crelt https://github.com/marijnh/crelt https://github.com/marijnh/find-cluster-break https://github.com/marijnh/find-cluster-break https://github.com/marijnh/w3c-keyname https://github.com/marijnh/w3c-keyname https://github.com/cure53/DOMPurify https://github.com/cure53/DOMPurify https://github.com/electron/electron https://github.com/electron/electron https://github.com/electron/get https://github.com/electron/get https://github.com/debug-js/debug https://github.com/debug-js/debug https://github.com/vercel/ms https://github.com/vercel/ms https://github.com/sindresorhus/env-paths https://github.com/sindresorhus/env-paths https://github.com/sindresorhus/got https://github.com/sindresorhus/got https://github.com/sindresorhus/is https://github.com/sindresorhus/is https://github.com/visionmedia/node-progress https://github.com/visionmedia/node-progress https://github.com/npm/node-semver https://github.com/npm/node-semver https://github.com/malept/sumchecker https://github.com/malept/sumchecker https://github.com/szmarczak/http-timer https://github.com/szmarczak/http-timer https://github.com/szmarczak/defer-to-connect https://github.com/szmarczak/defer-to-connect https://github.com/szmarczak/cacheable-lookup https://github.com/szmarczak/cacheable-lookup https://github.com/jaredwray/cacheable https://github.com/jaredwray/cacheable https://github.com/biomejs/biome https://github.com/biomejs/biome https://github.com/sindresorhus/decompress-response https://github.com/sindresorhus/decompress-response https://github.com/sindresorhus/mimic-response https://github.com/sindresorhus/mimic-response https://github.com/octet-stream/form-data-encoder https://github.com/octet-stream/form-data-encoder https://github.com/szmarczak/http2-wrapper https://github.com/szmarczak/http2-wrapper https://github.com/szmarczak/resolve-alpn https://github.com/szmarczak/resolve-alpn https://github.com/sindresorhus/lowercase-keys https://github.com/sindresorhus/lowercase-keys https://github.com/sindresorhus/p-cancelable https://github.com/sindresorhus/p-cancelable https://github.com/sindresorhus/responselike https://github.com/sindresorhus/responselike https://github.com/sindresorhus/type-fest https://github.com/sindresorhus/type-fest https://github.com/sindresorhus/tagged-tag https://github.com/sindresorhus/tagged-tag https://github.com/max-mapper/extract-zip https://github.com/max-mapper/extract-zip https://github.com/sindresorhus/get-stream https://github.com/sindresorhus/get-stream https://github.com/Sec-ant/readable-stream https://github.com/Sec-ant/readable-stream https://github.com/sindresorhus/is-stream https://github.com/sindresorhus/is-stream https://github.com/thejoshwolfe/yauzl https://github.com/thejoshwolfe/yauzl https://github.com/brianloveswords/buffer-crc32 https://github.com/brianloveswords/buffer-crc32 https://github.com/andrewrk/node-pend https://github.com/andrewrk/node-pend https://github.com/i18next/i18next https://github.com/i18next/i18next https://github.com/babel/babel https://github.com/babel/babel https://github.com/microsoft/TypeScript https://github.com/microsoft/TypeScript https://github.com/lezer-parser https://github.com/lezer-parser https://github.com/lucide-icons/lucide https://github.com/lucide-icons/lucide https://github.com/mathjax/MathJax https://github.com/mathjax/MathJax https://github.com/mermaid-js/mermaid https://github.com/mermaid-js/mermaid https://github.com/moment/moment https://github.com/moment/moment https://github.com/mozilla/pdf.js https://github.com/mozilla/pdf.js https://github.com/pixijs/pixijs https://github.com/pixijs/pixijs https://github.com/mapbox/earcut https://github.com/mapbox/earcut https://github.com/primus/eventemitter3 https://github.com/primus/eventemitter3 https://github.com/matt-way/gifuct-js https://github.com/matt-way/gifuct-js https://github.com/matt-way/jsBinarySchemaParser https://github.com/matt-way/jsBinarySchemaParser https://github.com/kaimallea/isMobile https://github.com/kaimallea/isMobile https://github.com/browserslist/caniuse-lite https://github.com/browserslist/caniuse-lite https://github.com/jkroso/parse-svg-path https://github.com/jkroso/parse-svg-path https://github.com/avoidwork/tiny-lru https://github.com/avoidwork/tiny-lru https://github.com/PrismJS/prism/ https://github.com/PrismJS/prism/ https://github.com/mourner/rbush https://github.com/mourner/rbush https://github.com/mourner/quickselect https://github.com/mourner/quickselect https://github.com/remarkjs/remark https://github.com/remarkjs/remark https://github.com/hakimel/reveal.js https://github.com/hakimel/reveal.js https://github.com/barrysteyn/node-scrypt https://github.com/barrysteyn/node-scrypt https://github.com/nodejs/nan https://github.com/nodejs/nan https://github.com/mixmark-io/turndown https://github.com/mixmark-io/turndown https://github.com/mixmark-io/domino https://github.com/mixmark-io/domino https://github.com/webpack/webpack https://github.com/webpack/webpack https://github.com/acornjs/acorn https://github.com/acornjs/acorn https://github.com/nicolo-ribaudo/acorn-import-phases https://github.com/nicolo-ribaudo/acorn-import-phases https://github.com/browserslist/browserslist https://github.com/browserslist/browserslist https://github.com/web-platform-dx/baseline-browser-mapping https://github.com/web-platform-dx/baseline-browser-mapping https://github.com/kilian/electron-to-chromium https://github.com/kilian/electron-to-chromium https://github.com/chicoxyzzy/node-releases https://github.com/chicoxyzzy/node-releases https://github.com/browserslist/update-db https://github.com/browserslist/update-db https://github.com/lukeed/escalade https://github.com/lukeed/escalade https://github.com/alexeyraspopov/picocolors https://github.com/alexeyraspopov/picocolors https://github.com/samccone/chrome-trace-event https://github.com/samccone/chrome-trace-event https://github.com/webpack/enhanced-resolve https://github.com/webpack/enhanced-resolve https://github.com/isaacs/node-graceful-fs https://github.com/isaacs/node-graceful-fs https://github.com/webpack/tapable https://github.com/webpack/tapable https://github.com/guybedford/es-module-lexer https://github.com/guybedford/es-module-lexer https://github.com/eslint/js https://github.com/eslint/js https://github.com/browserify/events https://github.com/browserify/events https://github.com/fitzgen/glob-to-regexp https://github.com/fitzgen/glob-to-regexp https://github.com/isaacs/node-graceful-fs https://github.com/isaacs/node-graceful-fs https://github.com/npm/json-parse-even-better-errors https://github.com/npm/json-parse-even-better-errors https://github.com/webpack/loader-runner https://github.com/webpack/loader-runner https://github.com/jshttp/mime-types https://github.com/jshttp/mime-types https://github.com/jshttp/mime-db https://github.com/jshttp/mime-db https://github.com/suguru03/neo-async https://github.com/suguru03/neo-async https://github.com/webpack/schema-utils https://github.com/webpack/schema-utils https://github.com/ajv-validator/ajv https://github.com/ajv-validator/ajv https://github.com/epoberezkin/fast-deep-equal https://github.com/epoberezkin/fast-deep-equal https://github.com/fastify/fast-uri https://github.com/fastify/fast-uri https://github.com/epoberezkin/json-schema-traverse https://github.com/epoberezkin/json-schema-traverse https://github.com/floatdrop/require-from-string https://github.com/floatdrop/require-from-string https://github.com/ajv-validator/ajv-formats https://github.com/ajv-validator/ajv-formats https://github.com/ajv-validator/ajv-keywords https://github.com/ajv-validator/ajv-keywords https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/webpack-contrib/terser-webpack-plugin https://github.com/webpack-contrib/terser-webpack-plugin https://github.com/jridgewell/sourcemaps https://github.com/jridgewell/sourcemaps https://github.com/jestjs/jest https://github.com/jestjs/jest https://github.com/yahoo/serialize-javascript https://github.com/yahoo/serialize-javascript https://github.com/browserify/randombytes https://github.com/browserify/randombytes https://github.com/terser/terser https://github.com/terser/terser https://github.com/tj/commander.js https://github.com/tj/commander.js https://github.com/evanw/node-source-map-support https://github.com/evanw/node-source-map-support https://github.com/LinusU/buffer-from https://github.com/LinusU/buffer-from https://github.com/mozilla/source-map https://github.com/mozilla/source-map https://github.com/webpack/watchpack https://github.com/webpack/watchpack https://github.com/webpack/webpack-sources https://github.com/webpack/webpack-sources https://github.com/eemeli/yaml https://github.com/eemeli/yaml

bergheim 1y ago

> Obsidian has a low number of dependencies compared to other apps in our category Whataboutism. Relative comparisons don't address absolute risk. I checked three random packages: prism pulls 22, remark pulls 51, pixijs 179! So that's 250+ transitive dependencies just from those. > Features like Bases and Canvas were implemented from scratch instead of importing off-the-shelf libraries. This gives us full control over what runs in Obsidian. Full control? There are still hundreds of dependencies. > This approach keeps our dependency graph shallow with few sub-dependencies. A smaller surface area lowers the chance of a malicious update slipping through. Really? Again, this is just one package: https://npmgraph.js.org/?q=pixijs https://npmgraph.js.org/?q=pixijs > The other packages help us build the app and never ship to users, e.g. esbuild or eslint. Build tools like esbuild don't ship to users, but a compromised build tool can still inject malicious code during compilation. This is supply chain security 101. > All dependencies are strictly version-pinned and committed with a lockfile Version pinning is, I would hope, standard practice in any professional development team years and years ago. It prevents accidental updates but doesn't stop compromised existing versions. > When we do dependency updates, we: > [snip] While these practices are better than nothing, they don't fundamentally address the core issue. > That gap acts as an early-warning window: the community and security researchers often detect malicious versions quickly According to whom? Heartbleed, a vulnerability in a package with far more scrutiny than a typical npm module took what, 2 years to be found? The "community detection" assumption is flawed. I'm not trying to put Obsidian down here - I sympathize, aside from implementing everything themselves, what can they do! I'm trying to point out that while their intent is good, this is a serious problem and their solution is not a solution. Of course, it's the same in any project with dependencies. It's the same in other languages as well - if they have a convenient package manager. Like Rust and Cargo. This problem came with the convenience of package managers and it should be fixed there, not by every application like Obsidian. I'm not sure how but maybe once a package is starting to become popular, additional security measures must be put in place for the author to be able to continue to commit to it. Signing requirements, reproducible builds, 2fa, community reputation systems, who knows. Individual applications can't solve supply chain security through wishful thinking and version pinning. Package managers need to solve this at the infrastructure level through measures like mandatory code signing, automated security auditing, dependency isolation, or similar system level approaches. Obsidian's practices are reasonable given the current tooling limitations, but they don't eliminate the fundamental risks that the package managers bring to modern dependency ecosystems.

saltserv 1y ago

[dead]

zvmaz 1y ago

I use Emacs and Org-Roam, and some Emacs packages. It is hosted in a VM that is not connected to the internet (a Qube in Qubes OS). I just cannot review all the code running in Emacs.

doodlesdev 1y ago

> Only a handful of packages are part of the app you run, e.g. Electron, CodeMirror, moment.js. So they ship an extremely bloated package to ship a WebView based on one of the most complex pieces of software ever written, an entire code editor for text editing, and a deprecated time library that could be substituted by newer APIs and some glue code? Honestly, it doesn't seem impressive at all. What Obsidian does is the bare minimum of how we should manage packages in any piece of software, not a testament to a serious security policy. They do security audits, though, which I find to be a good practice.

runningmike 1y ago

“ Supply chain attacks are malicious updates that sneak into open source code used by many apps.” No! This should be: Supply chain attacks are malicious updates that sneak into source code used by many apps. Stop blaming FOSS. Too many people still have the perception that FOSS software is insecure

mooreds 1y ago

I was talking to our chief architect about a blog post about our zero dependency home grown HTTP server[0]; the project just hit 1.2 and uses virtual threads. I'm generally a fan of "don't reinvent the wheel"[1], but I think there are some cases where that control is worth the cost. Defending against security vulnerabilities is definitely one of them, as long as you make the proper investments to harden what you write. Joel Spolsky write about some other reasons too[2]. 0: https://github.com/FusionAuth/java-http https://github.com/FusionAuth/java-http 1: https://en.wikipedia.org/wiki/Reinventing_the_wheel https://en.wikipedia.org/wiki/Reinventing_the_wheel 2: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...

elcapitan 1y ago

I went from Evernote to Joplin to Obsidian and really like the model of md files with some logic added on top. Initially I used a lot of plugins mostly out of curiosity, but now it's mostly RemotelySave for syncing and some small convenience plugins, so I hope my exposure isn't too high. The app doesn't have the bloaty feel of other Electron apps, but if there was a good more native alternative that fits my bill (md files editable in a graphical mode with good wikilink-syntax support and similar search etc), then I would actually consider switching.

daft_pink 1y ago

I’m pretty sure them rewriting things themselves has resulted in its speed. The great thing about obsidian is how fast it is compared to Notion.

gchamonlive 1y ago

Wonder if we could make the case that simpler always leads to less in favor of lean apps