On the security of plugins | Hacker News Reader

On the security of plugins

blog.standardnotes.com

59 pointsmoughxyz28 comments

> I take occupational offense to misuse of the term private because we’ve spent the last half decade building Standard Notes to be private without any ambiguity to what that term means.

> [..]

> Using the word “private” as “anything that isn’t on a cloud” is misleading, in my opinion. We know this is not the definition of private we want.

I don't know, for me that is a very acceptable definition since anything on the cloud is not private. If anything...

> When we think private, and when software products typically use the word private, they mean it to say privacy is a primary focus of the application, as enacted and permeated through mission, culture, code and operation.

...that definition could be applied to stuff on the cloud too since a cloud app can claim to care about privacy being "its primary focus" and its "culture, code and operation".

Of course something being local doesn't mean that it is 100% watertight proven that it is private, but the default state of a computer (at least as far as regular PCs go) is that and it is only after your actions as a user that state can be compromised.

As such the advice "don't download stuff that run `rm -f` on your hard drive" is a perfectly valid advice.

TBH this looks like some product's blog claiming why another competing product is inferior and theirs is better.

Hmm, I wonder if swapping "private" for "secure" would change the framing. Would an application touting "secure" in their tagline, but offering an insecure plugin architecture, be disjointed? I ask because the interchangeability of "private" and "secure" has always been a fascinating dilemma to me. Their definitions are precisely what I try to poke into in this post.

I don't know that the layperson sees them as interchangeable. Private, to me, merely says that the goal is for this to be for my eyes only. Secure tells me that they've gone to extra steps to ensure that that privacy is upheld.

It's like if someone has a private office versus a secure office. One is a room with a door on it, the other is a room with a security guard.

Privacy and security seem orthogonal to me.

Privacy is only one thing of many that could be assured via security. Imagine an office with glass walls, very little sound insulation, and a security guard at the door. The security guard and walls prevent physical attacks on the office occupant, thus ensuring their physical security, but it'd be difficult to say that office is private.

Is iPhone private? Apple says it is. Yet Apple also has the keys to user iCloud data. I agree that with proper metaphor the distinction becomes very clear, but in the open I’m not so sure if this distinction is well-defined, well-used, or well-understood.

I do not see much difference between 'application' and 'plugin'. Both are just some code one installs one on one's computer that somehow work together. There is risk that plugin does 'rm -rf ~/', but the same risk is for the application, both are mitigated through distribution infrastructure. So i do not see why application should have any kind of responsibility for plugins.

"Secure" is a much better word to discuss, because it's obviously a relative term that only has meaning against a threat model. So, yes, if the author kept using "secure" on his article, we would see a much better conversation, about how he is changing the goalposts instead of simply arguing that the goal is on a place where the posts are not.

I think you are responding to the author actually. But I agree, I think the author is mixing up privacy and security here.

While I'm generally in favor of innovation for secure computing, I think this category of "vulnerability" is not that bad. Applications have managed to use natively compiled plugins for decades without much in the way of `rm -rf /`ing users machines - and those that do don't get installed.

Like for example I haven't yet seen a post that decries the security vulnerabilities of VST plugins or Unreal engine plugins, but they actually have slightly worse surface areas that are harder to secure than something running on top of a JS engine.

At a certain point you have to accept that running code someone else wrote may do bad things. Zero trust doesn't have zero cost. Don't run random programs you download off the internet without accountability.

It’s like the whole universe of MS Office macro malware never existed.

There’s a world of difference between plugins that you actively install on your desktop and script code that gets executed as part of a document.

Two things I disagree with in this article.

1) I think the author is mixing up privacy and security here. At least to me, security is about whether the program has any bugs that allow access to data that the developer didn't intend. Developer's intent is important here, since a program itself does not have any intention, it always behaves exactly as it should.

Privacy on the other hand, is whether the user has control over who has access to their data, assuming that the program is secure. So say, if iOS exfiltrated data to Apple, but was intentionally coded that way, then iOS might still be secure, despite not being private. On the other hand, I consider Linux private, because while you could always install malicious packages, it's still your choice to install those packages.

2) The article is specifically discussing security against plugins accessing data / processes outside the application. But this severely cripples the power of plugins. I recognize that this is subjective, but I prefer it when plugins can extend the application in very powerful ways. I think often plugin developers are more creative than the application developer. Chrome, Firefox, VS Code, all have some amazing plugins.

That being said, I do like Standard Notes, and while I only tried the product for a little bit I appreciate rhe overall vision.

The author addresses your point 1 directly: you can't provide acceptable privacy guaranteed is your software is not secure. Developer's intent with regards to privacy is necessary but not sufficient.

My point of #1 is that the author is mainly talking about security but uses the word "privacy". Improving security does not improve privacy, given my definition that privacy assumes good security. I think it's important to disentangle these two concepts because you can have one without the other. We should of course be advocating for both, but each requires their own solutions.

The author is criticizing Obsidian for bad security, which in turn results in bad privacy guarantees.

The two concepts are tightly dependent and should not be disentangled.

Case in point: the GDPR is a privacy law that mandates, among many other things, that the systems involved are conceived, built and maintained with proper security considerations.

https://gdpr-info.eu/art-32-gdpr/

This seems like an obvious argument, so it is a shame it has to be spoken out loud: you can't provide privacy if your software is not secure.

> Using the word “private” as “anything that isn’t on a cloud” is a low bar, in my opinion.

I agree it's not a high bar, and I appreciate that some developers have higher security standard than others.

But I think "anything that isn't on a cloud" is an OK definition for "private". I can cut internet access from my private computer, it will still be able to run malware. I will blame myself for loading the malware into the computer, I will blame the malware's author for their malicious intention, but I will not blame my computer for executing the code.

I look at privacy as user's ability to control their own data, not necessarily the ability to control a software's behavior.

I would much prefer 'local first' as a description of that in theory, but in terms of creating an accurate picture in the head of most users 'private' is probably better in practice.

There is always a tension between communicating pedantically accurately and communicating effectively, and while I really wish there wasn't, said tension's existence requires a selection amongst trade-offs nonetheless.

(i.e. "I agree wrt 'OK definition' but I understand why others don't and I'd prefer to live in a world where believed I was wrong and they were right")

The only way to have secure plugins is sandboxed processes using OS IPC mechanisms, anything less subjects either the host application or $HOME to possible exploits.

Unfortunately only mobile OSes are on the forefront of this.

> Unfortunately only mobile OSes are on the forefront of this.

I'm not sure why the OS would have to manage this. For example when using electron you can use node's vm and run js in a seperate context. Its a seperate process but doesn't require anything special from the os for it.

mobile OSes do sandbox the entire program usually by default though.

Ubuntu sorta tried to with snapd. Windows tried to with UWP.

I think the idea is that the OS has a better chance of keeping the plugin isolated than a VM sandbox.

I'd certainly trust v8's sandboxing over any attempt to do it myself but OS level sandboxing + IPC seems like an even better idea if you're trying to be really sure.

Because that is why the OSes exist in first place, to provide common services to applications, otherwise we could still code like in the old 16 bit days, a bit like Arduino nowadays.

Windows is still trying, hence why now WinUI 3.0, WinAppSDK and packaged applications.

Likewise Ubuntu hasn't given away snapd, rather doubled down on it.

Yet none of them are as enforceable as iOS and Android are. It isn't only the program that is sandboxed, plugins are also required to be installed as separate packages and communicate over IPC with the host.

This website is very dark and very low contrast on iOS for me. Not sure if page is using dark mode media queries and accidentally putting dark text on dark background only then, or if it’s equally dark and low contrast for everyone.

It does indeed seem to use media queries, because it looks like that whenever the browser is set to a dark theme. I'm not usually bothered by what some consider to be low contrast, but this is barely legible, especially the header.

Now they've fixed it.

> When it comes to privacy and security, it’s deathly important to be as unambiguous as possible.

Did ... did they miss the giant, in-your-face warning that happens when you intentionally deactivate safe mode in order to be able to install plugins?

I think it would be a reasonable argument that users aren't going to pay any meaningful level of attention to such a warning, but assuming said warning existed in the version they were testing the article would've been better for making that argument explicitly.

Reply on news.ycombinator.com