←back to thread

Less is safer: How Obsidian reduces the risk of supply chain attacks

(obsidian.md)
429 points saeedesmaili | 3 comments | 19 Sep 25 22:02 UTC | HN request time: 0.002s | source
Show context
system7rocks ◴[19 Sep 25 23:16 UTC] No.45307929[source]▶
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?
replies(7): >>45307982 #>>45308069 #>>45308141 #>>45308336 #>>45308343 #>>45308406 #>>45310096 #
anon7000 ◴[19 Sep 25 23:22 UTC] No.45307982[source]▶
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.

replies(2): >>45308100 #>>45311387 #
asgraham ◴[19 Sep 25 23:37 UTC] No.45308100[source]▶
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?

replies(2): >>45308410 #>>45311411 #
1. dalmo3 ◴[20 Sep 25 00:18 UTC] No.45308410[source]▶
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.

replies(2): >>45308662 #>>45309468 #
2. zdragnar ◴[20 Sep 25 00:51 UTC] No.45308662[source]▶
A number of operating system security features, such as ASLR, exist because low level languages allow reading and writing memory that they didn't create.

Conversely, barring a bug in the runtime or compiler, higher level languages don't enable those kinds of shenanigans.

See for example the heart bleed bug, where openssl would read memory it didn't own when given a properly malformed request.

3. chowells ◴[20 Sep 25 02:06 UTC] No.45309468[source]▶
Turing completeness is irrelevant, as it only addresses computation. Security has to do with system access, not computational capacity. Brainfuck is Turing complete, but lacks any primitives to do more than read from a single input stream and write to a single output stream. Unless someone hooks those streams up to critical files, you can't use it to attack a system.

Language design actually has a lot of impact on security, because it defines what primitives you have available for interacting with the system. Do you have an arbitrary syscall primitive? Then the language is not going to help you write secure software. Is your only ability to interact with the system via capability objects that must be provided externally to authorize your access? Then you're probably using a language that put a lot of thought into security and will help out quite a lot.