How not to build a secure plugins architecture

I was taking a look at Obsidian the other day, having seen someone mention it on my timeline. I’d taken a look before, but was especially curious about their plugin architecture: it seemed particularly powerful, and I was impressed they had found a way to implement extensions securely without needing to render extensions separately in their own sandbox.

I installed a few extensions on my local instance, like a calendar plugin, and was bewildered—how on earth are you rendering external code directly in your application, as if it were part of your application!? I couldn't believe they cracked the problem of implementing a secure plugins architecture.

But then I saw this thread. Oh. Well, it’s not secure at all. They render external code directly in the application as if it were a part of the application because they really do treat external, network-downloaded code as first-party! You could seemingly download a plugin that runs rm -rf ~/, and it would proceed to delete your entire home directory. The advice I’ve seen on how to avoid issues like that is essentially “don’t download plugins that run rm -rf on your entire hard drive.”

I felt sort of deceived. A lot of these new networked, local-only note-taking apps tout themselves as “privacy focused” simply by virtue of the fact that they operate on local data. And of course it’s well accepted that if you want a powerful plugins architecture, plugins have to run with about the same privileges as the parent application. But what does privacy really even mean anymore, if apps that allow unfettered plugins without so much of a hint of a sandbox are allowed to use that term?

(Logseq was one I saw pop up the other day, which describes itself as "privacy-first”; I have not yet peered into its plugins architecture, but I imagine it’s more of the same. Obsidian also offers end-to-end encrypted sync, and claims that prevents them from reading your notes; I wonder however if plugin developers could easily extract encryption keys, given they run with about the same permissions as the parent application?)

I take offense to misuse of the term private because we’ve spent the last half decade at Standard Notes building something that truly tries to be as private as possible, without any ambiguity around what that term means.

We built a custom sandboxed environment for our extensions to run in using a two-way JSON communication bridge. Extensions can absolutely NOT access anything you wouldn’t want them to access. They certainly can’t access your filesystem. Our extensions are primarily related to editors and themes, and not general application extensibility. So there is definitely a tradeoff with regards to user experience. Extensions for us can’t add custom toolbar buttons, or implement custom behavior outside the context of an isolated editor frame. For us, this is an easy decision. Security first, always. I’m not sure everyone who uses other super-extensible note-taking apps understands this tradeoff.

There’s definitely room in this world for a lot of different types of note-taking apps. I’ve come to appreciate just how different we are, and the use case we cater to, than the recent surge of local-only, mind-mapping note-taking tools. As long as terminologies don’t get conflated, Standard Notes remains an excellent place for secure and private note-taking. A place you can store passwords, keys, notes, documents, thoughts, and todos all the same, and never have to worry about our priorities as engineers.

Using the word “private” as “anything that isn’t on a cloud” is a low bar, in my opinion. We all know this is not the definition of private we want. When we think private, and when software products typically use the word private, they mean it to say that privacy is a primary focus of the application, as demonstrated through code and practices. Using “private” to refer to something that is local-first is like slapping a “gluten-free” label on a water bottle. Sure, it’s true in a sense, but that’s not how that label is supposed to be applied.

Given the misuse of this term by software products who claim to be private yet implement architectures that are inherently insecure, I become reluctant to use this term myself to describe our own product. Perhaps “secure” is the better term, which is much more difficult to misuse.

Networked mind-mapping document editors like Roam and Obsidian are super cool, and I truly don’t see them as competitors. If there is anything more ambiguous than the word private, it would seemingly be “note-taking app.” When it comes to privacy and security however, it’s deadly important to be as unambiguous as possible. You could hardly over-communicate. Ideally, you’d let your code speak for itself, but closed, proprietary source seems to be the trend amongst these types of tools.

When you close-source your encryption software, you have a lot of compensating to do. I haven’t yet seen this from these types of products. Documentation on how data is secured is sparse and frugal.

But the decade is young.

You'll only receive email when they publish something new.

More from Crafting Privacy
All posts