[HN Gopher] On the security of plugins
___________________________________________________________________
On the security of plugins
Author : moughxyz
Score : 46 points
Date : 2022-06-03 12:48 UTC (10 hours ago)
(HTM) web link (blog.standardnotes.com)
(TXT) w3m dump (blog.standardnotes.com)
| woojoo666 wrote:
| 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.
| Rygian wrote:
| 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.
| woojoo666 wrote:
| 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.
| EleanorKonik wrote:
| > 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?
| [deleted]
| mst wrote:
| 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.
| Rygian wrote:
| 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.
| pjmlp wrote:
| 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.
| throwaway92394 wrote:
| > 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.
| mst wrote:
| 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.
| pjmlp wrote:
| 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.
| codetrotter wrote:
| 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.
| [deleted]
| LinAGKar wrote:
| 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.
| LinAGKar wrote:
| Now they've fixed it.
| zzyzxd wrote:
| > 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.
| mst wrote:
| 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")
| badsectoracula wrote:
| > 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.
| moughxyz wrote:
| 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.
| mcluck wrote:
| 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.
| giaour wrote:
| 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.
| zajio1am wrote:
| 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.
| marcosdumay wrote:
| "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.
| woojoo666 wrote:
| I think you are responding to the author actually. But I
| agree, I think the author is mixing up privacy and security
| here.
| duped wrote:
| 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.
| numbsafari wrote:
| It's like the whole universe of MS Office macro malware never
| existed.
| pavlov wrote:
| 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.
___________________________________________________________________
(page generated 2022-06-03 23:02 UTC)