Live data from Hacker News

Less is safer: Reducing the risk of supply chain attacks

obsidian.md

241–250 of 274 posts

Re: Less is safer: Reducing the risk of supply chain attacks

#241
post #16

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,…

As someone who specifically started building Octarine, just for this reason, I understand.

Having to rely on random devs for the most basic functionality and passing it off as `community does what it wants` is weird. Either add it in yourselves, or accept the fact that given your app requires external contributors to work at a little above the basic level, there are going to be security issues.

Writing a whole blog post, and throwing shade on "other apps" that have far more dependencies than Obsidian is weird to me.

Anyway, it seems like you can't really talk bad about them, since there's a huge following that just comes at you, and that feels weird, cause they apparently can throw shade, others can't just talk back.

Re: Less is safer: Reducing the risk of supply chain attacks

#242

Earlier quoted context omitted.

This app deals with very critical, personal, and intimate data – personal notes and professional/work-related notes, but proudly has an Electron app. This alone has seemed like a massive red flag to me.

Until there is a better alternative you’re left with electron. Nothing come close to obsidian.

Give Octarine (https://octarine.app) a try?

Built with tauri & rust, and is more performant, and doesn't rely on random contributions for basic things as plugins.

Disclaimer - I build it.

Re: Less is safer: Reducing the risk of supply chain attacks

#243
post #133

Earlier quoted context omitted.

I’ve been of the opinion that every hard problem in CS shows up somewhere in gamedev. It’s a great space for inspo.

Game dev also rewards people for applying the 80/29 rule effectively and you see less of that in commercial software. In each game generation there’s a game that would be easy to write on the next or subsequent generation of hardware and is damned difficult to implement on the current one. Cleverness and outright cheating make it work, after all fashion.

It reaches a dead end eventually. That's where we are, edge of speed, where the only mods left are aesthetics veering at photorealism.

Re: Less is safer: Reducing the risk of supply chain attacks

#244

Earlier quoted context omitted.

Game dev also rewards people for applying the 80/29 rule effectively and you see less of that in commercial software. In each game generation there’s a game that would be easy to write on the next or subsequent generation of hardware and is damned difficult to implement on the current one. Cleverness and outright cheating make it work, after all fashion.

It reaches a dead end eventually. That's where we are, edge of speed, where the only mods left are aesthetics veering at photorealism.

The game simulation will get more detailed/granular as aesthetics dial down in perceived value. You can always go bigger/wider/more procedural/more multiplayer.

This is also why every hard problem eventually shows up — games are just simulation + interaction, and eventually everything that can be simulated will have some attempted implementation out there, struggling along. (For some reason, this does not appear to stop at “interesting” things to simulate — see all the literal simulators on steam)

Re: Less is safer: Reducing the risk of supply chain attacks

#245
post #244

Earlier quoted context omitted.

It reaches a dead end eventually. That's where we are, edge of speed, where the only mods left are aesthetics veering at photorealism.

The game simulation will get more detailed/granular as aesthetics dial down in perceived value. You can always go bigger/wider/more procedural/more multiplayer. This is also why every hard problem eventually shows up — games are just simulation + interaction, and eventually everything that can be simulated will have some attempted implementation out there, struggling along. (For some reason, this does not appear to s…

The simulations have yet to release photo-realism in lieu of event-perception, where simulation parallels reality, but that's not really playable as a game, only as a view.

Re: Less is safer: Reducing the risk of supply chain attacks

#246

Earlier quoted context omitted.

There are better alternatives. It's just that people have convinced themselves they need the features Obsidian offers - because it makes them feel smart and important. At the end of the day, you're just taking notes. If you write a journal, don't put it in something like Obsidian. Even Apple Notes is better (in security, privacy, etc) in this regards.

How do I use Apple Notes cross-platform?

You can't. But that wasn't the point, was it?

Point is, you don't need Obsidian (or all of its plugin). People have been making do with Dropbox and plain text (.txt) files perfectly fine for years.

Re: Less is safer: Reducing the risk of supply chain attacks

#247
post #5

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?

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…

None of this makes or is a result of the language js (being) secure. Security is far and away predominantly a matter of how it's used, not a character of them language itself. "Safety" helps, but you can still easily write and package unsafe and insecure code in "safe" languages like rust, just as you can in C, JS, python, etc etc etc.

Re: Less is safer: Reducing the risk of supply chain attacks

#248

Earlier quoted context omitted.

Game dev also rewards people for applying the 80/29 rule effectively and you see less of that in commercial software. In each game generation there’s a game that would be easy to write on the next or subsequent generation of hardware and is damned difficult to implement on the current one. Cleverness and outright cheating make it work, after all fashion.

80/29 rule is the paretypo principle?

Typo but yeah.

Re: Less is safer: Reducing the risk of supply chain attacks

#249

Earlier quoted context omitted.

You're wrong. The obsidian flatpak ships by default with access to /home. https://github.com/flathub/md.obsidian.Obsidian/blob/5e594a4...

I „love” such sandboxing defaults. Apps like Docker Desktop also share the whole home by default [1], which is pretty interesting if a big selling point is to keep stuff separated. No idea why node_packages need to have access to my tax returns :). Of course you can change that, but I bet many users keeps the default paths intact. [1] https://docs.docker.com/desktop/settings-and-maintenance/set...

Needed for volume mounting to work easily I assume.

Re: Less is safer: Reducing the risk of supply chain attacks

#250
post #87
post #16

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,…

> Obsidian plugins have full, unrestricted access to all files in the vault. Unless something has changed, it's worse than that. Plugins have unrestricted access to any file on your machine. When I brought this up in discord a while back they brushed it aside.

To be fair it also ships with the ability to install community plugins disabled.
Post reply on HN