Crafting Privacy

A labor of love. Updates and insights from the Standard Notes team.

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.

Problem Solving - Episode 1

I want to experiment with sharing bite-sized tidbits and stories of how we solve problems, from the simple to the more complex. A sort of behind-the-scenes or a “day in the life” of our team.

In this episode, Karol and I discuss how to best position the new files server in our infrastructure in a way that is scalable and reliable for us, while also maintaining a user-friendly self-hosting experience for users who self-host the backend infrastructure, but not the frontend applications. The goal is allowing users to self-host their own encrypted files server and use it with our official applications on desktop, web, and mobile.

Why is the files server not behind the API Gateway?


Hmm so the files server host is set via an ENV variable in the clients. This means that if I sign into a custom server using app.standardnotes.com, I won't be able to upload files correctly, because the files server will be hardcoded to files.standardnotes.com, but my account is on a custom server.

This means that a user will not be able to self-host the files server and use our apps at the same time. Because again the value they enter into Custom Sync Server when signing in does not apply to files.

My first guess as to why files is separated from the broad api-gateway infra is because files is resource intensive and routing a lot of file bytes through api-gateway may bog it down. If there is no way around this, then it seems that when a user signs in we will have to add another input field for the files server. But this UX stands to get confusing.

Any possible solutions?

What about putting the files server up at api.standardnotes.com/files 🤔 So the client will just append /files to the user’s existing server path.


My first guess is that this is because files is resource intensive and routing a lot of file bytes through api-gateway may bog it down.

Yes, that is precisely the reason. File operations will be high memory consuming ones and could potentially bring a container down until we have everything super tweaked. So that is a risk that we don't want to take. Essentially we are rendering it impossible for the files service to bring down the entire infrastructure.

This also means that a user will not be able to self-host the files server and use our apps at the same time. Because again the value they enter into Custom Sync Server when signing in does not apply to files.

Hmm yeah, but then again if they're self hosting the app they'll have to provide the env var upon starting. So, it's part of the setup that you already have to go through if you're self-hosting.

What about putting the files server up at api.standardnotes.com/files 🤔 So the client will just append /files to the user’s existing server path.

Technically possible but that would have to be a reroute on the load balancer so that the traffic would not hit the API Gateway. Also this is something that we will not be able to mimic on the self-hosting setup since we don't have a load balancer there. It's possible but creates a different set of issues altogether.


Regarding self hosting, most users self host the server and not the clients. So there is no opportunity for them to configure the env vars on the client to point to their files server.

In general though our clients are meant to be server agnostic regarding data endpoints and meant to be fully configurable from a UX perspective. So if your company for example is self hosting the SN infra and you want to use our mobile app from the App Store, we’d have to have an input field on sign in to specify the files server.

Any other possible solutions you could think of?

What if the api-gateway advertised its respective files server to clients in the meta response?


Hmm that would mean that the file server would have to somehow "register" with the api-gateway right? Something like sending an HTTP request upon container boot with "my host" to the "api gateway" url. Then we might do a model of ServerSettings just like we have UserSettings which could be retrieved by the client. So the app would fetch let's say api.standardnotes.com/v1/server/settings/FILES_SERVER_URL?


Hmm I was thinking more that the api-gateway would just have a FILES_HOST env var, and then clients can just request that via either a new endpoint or piggybacking on the meta response included in all requests?


Hmm yeah, that could work too. Much easier to implement I think. I'll put something together.

And here’s the result of our conversation: https://github.com/standardnotes/api-gateway/commit/3bc84a8ca8c21241a20feae17d861370b26a7ae4

I hope you enjoyed this behind the scenes of how we tackle everyday problems. If interesting, we can definitely share more tales like this 🙂

Why so many editors?

Most people love that we offer them the choice of editor to use to edit or craft their notes. If you want rich text, like highlighting and colors, you’ll need to use a rich text editor, and almost all web-based rich text editors use HTML as the under-the-hood markup language. But forcing all of our users to have their notes converted to HTML is nowhere near our modus operandi. We promised you portability, so we default to plaintext. If you want rich-text, you must opt in.

Ok, well, what about Markdown—why do you offer like 5 different Markdown editors?

Because writing is a vibe. There are many ways to do it. There are a hundred different configuration options and ambiances you want when writing. Do you want the Markdown syntax to be visible while you type, or do you want it hidden? Do you want the Markdown to render in the same view you're typing in, or do you want a split-pane between raw and preview? Do you want a toolbar, or are you a Markdown pro who knows all the syntactical tricks by heart? There is no one Markdown editor to rule them all.

Ok, but, why not have just one big editor that does everything, instead of ten different editors that fragment the experience?

There are a few reasons:

  1. It's impossible. It’s like asking Microsoft to combine Excel, Powerpoint, and Word into one app. Those poor engineers.

  2. You decrease overall stability. If we built one editor that did everything, from rich text, to spreadsheets, to Markdown, tasks, and code rendering, this editor would be eternally restless and bombarded with updates. Because of the tight coupling, a fix made to code rendering would somehow break spreadsheet functionality, and a fix made to task rendering would somehow make the bold function begin rendering italics. Of course there are ways to properly build modular code, but nonetheless, we quite like the idea of specialization amongst editors. Each of our editors is good at doing one thing and one thing only. Our Markdown editors never ever have to worry about presenting a spreadsheet. They shudder in fear at the thought of some product manager one day forcing consolidation.

  3. I’m going to be fully honest with you: we’re not an editor building company. The surface area of our passions as a team is wide, but no one on our team is particularly passionate about building editors. It’s hard stuff. Which is why we rely mostly on open-source components for most of our editors. The editors we do like building end up not really being “editors” but kind of just specialized applications. Like TokenVault, which is my absolute favorite “editor”. It’s more of an app to manage your 2FA secrets for other applications, and generates 6 digit codes for you to sign in on other services. It's a direct replacement to Google Authenticator, with the added benefit of not losing all your entries when you get a new device.

  4. Building a mega-editor means producing a super proprietary format that you will never be able to escape from. Perhaps a Notion-like block system is what some might be after, but I can only imagine what monstrosity of a data schema those documents produce. Don’t get me wrong: it’s super cool. But it’s not what we’re building.

Editors kind of behave inconsistently between desktop and mobile.

Sigh—yes, editors are most certainly biased towards a desktop experience. Essentially our editor experience is akin to taking Microsoft Excel and shrinking it down to mobile size and hoping for the best. We get pretty good results on mobile 90% of the time. But there will be edge cases. And in most cases, we’re at the mercy of the open-source maintainer for fixes. If mobile is your primary use case, it’s best if you try out the editors you’re interested in there first to see if their UX fits well with your expectations. To be quite honest, the best answer I can give regarding this is: yes, editors are not a mobile-first experience, but given the constraints and goals of our system, it gets the job done.

What does the future of editors look like?

More editors. Believe it or not, we actually have another Markdown editor coming soon. But again, it does something a little different than the other Markdown editors. And we don’t build it from scratch—it’s based on an open-source component.

We’re also eager to push the “app” concept more in the future, similar to TokenVault. Concepts like a password manager, a contacts database, a recipe manager, and other specialty concepts.

And, most importantly, we're investing heavily in an end-to-end encrypted, private Wordle clone, directly in Standard Notes. /s

Roadmap Update — March 2022

Late last year, we shared an update on our plans and roadmap for 2022. I wanted to share with you some of the great progress we've made on our goals and highlight some of these achievements, as well as share what’s in store for the months to come.

Things we've delivered:

✅ Native, built-in tag folders. This replaces the previous folders extension, which felt disconnected from the core app experience. This refactor is part of our overall direction of moving away from using extensions for core behavior to instead letting these elements arise naturally from our core application codebase. We’ll discuss this in more detail below.

✅ Offline editors on mobile. This long-standing request was shipped to what I can only imagine as a standing ovation from on-the-go mobile users who relied on using specialty editors while in areas of low network connectivity. Editors on mobile in general now load in a snap. In addition, their signatures are compared with a precompiled list of signatures for greater security.

✅ Large database load improvements for mobile. Our mobile apps are built with React Native, and our encryption library relies on accessing low-level cryptography methods. Previously, our implementation of the crypto native module for React Native used the default React Native bridge, which involved JSON serializing and deserializing every message to and from native-land. This created a bottleneck which was especially visible on load. In version 3.11.0 of the mobile application, we shipped a new implementation of our crypto bridge library which relies on a new technology called the React Native JSI, which interfaces directly with system-level functions without needing to cross the JSON bridge. We've seen as much as a 3x decrease in startup load times!

✅ Listed for mobile. You can now manage your Listed blog on the go, no matter where inspiration strikes. You can publish public and private posts, notify subscribers, manage your blog settings, as well as create a brand new blog altogether.

✅ Continuing to improve our UI/UX. Our web and desktop apps have received consistent updates over the last several months that have pushed the UI and UX further than in some years combined. If it's been a while since you've last seen us in person, we recommend coming in and taking another look!

Things we’re making good progress on:

🔗 Built-in encrypted files. Possibly one of the most important features we’ve worked on to date. We’re making excellent progress here, particularly on the backend, infrastructure, and client libraries. Our timing is fortuitous, given the new FileSystem Access API which makes chunked file operations seamless. We’ve successfully tested uploading and downloading a 1GB file with almost no tangible impact on CPU or memory usage. This new API is only available in Chrome and Chromium (which includes our desktop app), and is a work in progress on other browsers like Firefox and Safari. For those browsers, we’ll fallback to classic methods of uploading and downloading, but because those methods don’t allow for streaming a local file chunk-by-chunk and instead load the file completely into memory, we’ll likely need to limit file operations in those browsers to 50MB.

⏳ Multiple account support. Account switching functionality has already been present in our web and desktop app for quite some time, but hidden behind an experimental feature flag (adding account_switcher as a root localStorage entry then reloading the app). We’re working on exposing the ability to enable experimental features via a “Labs” preferences section.

🗓 Tabbed editor support, or the ability to open and edit more than one note at a time, each in a separate tab, similar to how code editors or web browsers work today. We haven’t yet begun work on this.

New from our blog

What’s next

Files. This lives heavy in our minds right now. The ability to drag and drop a file seamlessly from your desktop, have it end-to-end encrypted, then synced to all your devices is a dream coming slowly true. The ability to snag a video from your phone and have it encrypted, uploaded, and available on all your Standard Notes applications—we gleam at the possibility. The freedom. The peace of mind. It’ll be a whole new world.

But we have to build it first. We can't say exactly when we’ll finish, but there’s no stopping us now. The world will come to learn what it means to have truly private, encrypted files, as easily accessible as a piece of text in your favorite note-taking app.

2FA as a free feature

Yes, two-factor authentication is a paid feature for Standard Notes now. We've gotten a lot of negativity about this, and it is understandable. I think however if one understood—perhaps viscerally—the difficultly of building a profitable company from scratch, with no outside capital injection, you painfully come to realize the default mode of user operation is a very strong reluctance to part with their credit card.

In fact, about 92% of our users use Standard Notes without paying a single dollar. And sincerely, we're quite lucky to have them! We hold the trust placed in us for protection of your most sensitive secrets very dearly, and of course, firmly. But without applying some pressure to convert to a paying account, that tendency of users to not pay gets only higher. And of course, the closer to a 100% free user rate you get, the more you jeopardize sustainability.

However, in thinking back to what made Standard Notes the relative success it is today, I'm reminded of one factor that catapulted our growth above all else: the community. The good-will. The appreciation of our transparency, business model, and open-sourcing. We've spent close to $0 on marketing over the last half decade. The rest has been pretty much good will.

So, sometime after or close to the release of files, we're going to make 2FA a free feature for all accounts.

Self-hosting the new extension-less architecture

Some of our users like to self-host their own infrastructure for a fully sovereign, synced, and end-to-end encrypted note-taking architecture, particularly our backend syncing server. This allows you to use our official web, desktop, and mobile applications, but have those applications seamlessly sync with your own server and database. Some users also self-hosted the extensions, particularly the now defunct folders extension. For the reasons mentioned in our blog post on transitioning from an extensions architecture to a native one, leaving behind the primitive architecture required to display folders as an extension in our application was not a viable option. However, because the ability to nest tags as folders is a paid feature, users not self-hosting their own client applications found that the architectural change of moving away from extensions for core functionality was quite disruptive to their setup.

Indeed, this change was quite disruptive to our own architecture as well, which is why it took so long! But, this is the way forward towards a more cohesive, secure, and unified architecture. We’re enlivened by the feedback we’ve received about the implementation of this new direction—users really love the new built-in folders feature! But, without a clear migration path, we let down some of our loyal self-hosters whose workflows were disrupted because of this change. In the near future, we'll share a guide on how to self-host the new architecture, and gain access to all of Standard Notes' features with no restrictions on your own self-hosted server.

Folders: From Extension to Native

If you’ve been present in our community Discord, Slack, or forum, you’ve likely already read about our long-standing goal of moving away from extensions for core functionality to native implementations. We've made near complete progress in this area. In previous major versions of our application, behavior like autocomplete tags, folders, and even duplicating a note were all implemented as external extensions that were loaded into the core application via an iframe mechanism. The philosophy behind this architecture was that implementing “extra” behavior behind extensions allows us to keep the core app slim and easier to maintain.

However, the observed effect was precisely the opposite. Extensions began drifting away from core app improvements and changes, and became more difficult to maintain over time. Because extensions communicated with the core app via a JSON message bridge, any new functionality extensions needed to gain required new messaging mechanisms, which made the API more bloated and less rigid. Extensions also needed to implement their own UI from scratch, and while we took advantage of a shared library for common styles and components, the effect was nonetheless that the look and feel of extensions drifted away from that of the parent application.

Moreover, extensions living in their own island meant a general disconnect in UX, and an unpleasant “first-time” experience whereby users needed to understand what extensions were, how to install them, how to enable them, and how to disable them if they wanted to revert to the out-of-box experience, which was usually a more primitive form of the extension experience.

Lastly, building functionality such as tag folders behind an extension meant that our communication bridge between the core application and extensions needed a permissioning system for streaming batch items. This meant that third party extensions could also take advantage of these same mechanisms. We felt this architecture increased the surface area of potential misuse of the API. While extensions could not batch request access to all your notes, we felt that a batch request of any kind should be disallowed by our API to maintain a stricter environment and a less worrisome surface area for our engineers.

For all the reasons above, and several other untold intricacies of bundling core functionality as extensions, we decided, perhaps as early as 2019, to move in the direction of building a more cohesive out-of-box experience that “just works” without you having to think about how it works, or how to enable the it just works feature. Because the extensions architecture was so ingrained in our ecosystem, it took time to get here. But we've finally arrived at a point where the only extension concepts that remain are themes and editors.

Editors is a concept we believe lends itself really well to extensions. There are a thousand and one ways to edit a document. And surely no matter how prescient we are, we could not build nor bundle all of those ways into one editor. We believe the ability to replace the built-in plaintext editor with custom editors like Spreadsheets, TokenVault, or the variety of other hyper-specialized editors we offer, is essential to an experience that doesn’t lock you into one format, and grows and adapts with the popular editing formats of the time.

Deprecation Notice: FileSafe

Starting February 9, 2022, FileSafe will be deprecated and no longer offered to new users. For existing users who have the FileSafe extension installed, FileSafe will remain accessible indefinitely.

FileSafe was launched in 2018 as our concept file storage solution, and uses a bring-your-own-cloud model to store your files. This means that files are encrypted by us but stored in your Dropbox or Google Drive. This architecture allowed us to focus on building a frontend solution without requiring the heavy infrastructure required to build a scalable backend file-hosting architecture, which we weren't yet ready to undertake in 2018.

Much has changed since then, and we're glad to announce we're now in a position to invest in our own secure files solution, which is well underway and in development.

While keeping FileSafe around seems like a viable option, FileSafe's reliance on third parties like Dropbox for core functionality results in a precarious and fragile arrangement resulting in sudden API shifts that break our integrations and require recalibration at unannounced intervals.

While still early, we're excited to continue development on our in-house encrypted file storage solution, and will share updates on our progress along the way.

An update on early pricing and roadmap

This is a trimmed down version of an email that was sent out to our users on November 3, 2021.

The End of Early Pricing

Early Pricing is our 5-year plan, which was marked down at a steep discount as a sort of "capital raise" program---you give us a single relatively large sum in advance, and we give you prolonged service. But because the program was offered at such a discount, it couldn't be sustainable in the long run.

We're glad to announce the time has finally come to graduate out of early pricing, and into a more long-term focused, sustainable pricing model.

Next week, we'll be launching our new subscription plan lineup, which features different plans which offer different features at different price points.

Before we describe those to you, it's important to note that if you already have a pre-existing subscription, these changes or prices do not affect you. Existing subscribers are always taken care of.

What's Changing

Currently, we only have 1 subscription plan offered at different time commitments. However, we often get the feedback that some users want only one particular feature, and don't want to pay for the whole offering.

Our new subscription system consists of 3 different plans that each cater to a different use case.

Existing Subscribers

If you are an existing subscriber, whether monthly, yearly, or 5-yearly, you automatically get the highest Pro Plan, with no price increase! You're locked into the price you signed up with, and your plan will continue to renew at that price indefinitely until you cancel. You can also extend your plan today with another X years at current pricing.

New Release

Our new release next week also features our brand new unified subscription architecture, so that you no longer need two (potentially confusing) accounts to use Standard Notes. And you no longer need to manually activate your paid benefits and install them one-by-one---everything just works seamlessly! It's taken a tremendous amount of architectural and engineering efforts to pull this off, and we couldn't be happier to finally be shipping this.

With this new architecture, we're now able to finally begin shipping and working on user-facing features which we can rightfully charge for depending on complexity. This takes us to our roadmap.


We have a few major things we have our sights on for the very near future:

1. Built-in encrypted files. Our current solution for files uses FileSafe with third-party cloud providers, which isn't the best out-of-box user experience. Our new experience will focus on built-in file handling available on all our applications and synced directly to your existing Standard Notes account. Your storage capacity will depend on your plan. For example, the Plus Plan might allow for 5GB of storage, while the Pro Plan might allow for 25GB storage (exact storage specifications TBD).

2. Native folders for web, desktop, and mobile. The current nestable folders solution requires an extension that isn't available on mobile. Nativizing this feature will allow for a much more pleasant user experience.

3. Multiple account support. The ability to quickly and easily switch between multiple accounts, perhaps if you have one account you use for work and one account for personal notes.

4. Tabbed editor support. The ability to open and edit more than one note at a time, each in a separate tab, similar to how code editors or web browsers work today.

5. Offline editors on mobile. Currently you need an online connection to use our speciality editors (non-plaintext) on mobile. Offline editors on mobile will download editors to your device, like we do on desktop.

6. Large database load improvements for mobile. Currently when you have many thousand notes on mobile, startup decryption experience may vary depending on your device specifications. New advancements in React Native have however potentially opened the door for drastic performance improvement opportunities.

7. Continuing to improve our UI/UX. You may have already noticed new design elements in our web and desktop app. This includes a redesigned account menu and a brand new general purpose Preferences pane to accommodate the variety of configuration options we have now and will expand into in the future. The rest of our applications have already been redesigned in our private Figma, just waiting to be implemented in code! We can't wait to continue gradually releasing small doses of this redesign, until it is fully complete.

New Website

We have a new website! Check it out at standardnotes.com.

Join our Discord

We caved and now we have a Discord. We still have Slack too. But that's ok. Each platform encourages a different culture and invites a new audience. Standard Notes is crypto friendly, and the crypto community loves Discord, so we'd love to open our doors to them.

You can also follow us on Twitter (@StandardNotes). We don't tweet much because we're always working. But maybe one day we'll hire one of those hip social media people that tweet in lowercase and pick internet fights with Wendy's.

That's all for now.

Thanks for being on this journey with us. We look forward to continuing to build out the best, most secure encrypted note-taking application available. It's hard work. But we're doing it. And we love every second of it.

Why TokenVault is going public source

In investing time and resources into improving TokenVault and other editors, we felt uncertain about the fact that there are already open-source clones offering free (but untrusted) distribution of our paid extensions. This is certainly within their rights, as our custom editors are licensed with AGPLv3.

For context, Standard Notes clients and sync server have always been released under an open-source license. Extensions have had a different history, as their primary purpose is precisely a way to monetize without impeding on core experience. They started as public-source, later changed to open-source, and today take another shift, but one we think is nuanced, reasonable, and hopefully, fair.

Editors that we develop in-house mostly from scratch will house a public-source, but not open-source presence. This means you can browse the source code online, and even use it for personal use, but you cannot redistribute it for free or for profit.

Editors that are derived and are mostly wrappers on top of existing open-source software will retain either the license of the majority share library, or AGPLv3.

Allowing us to protect our investments in resources allocated to improving editors also allows us to further re-invest revenue into improving our primary-focus open-source clients and server. Our goal is building the best way to store and manage your personal notes and data. End-to-end encryption, open-source, and business sustainability are fundamental pillars of our product, and we hope you’ll continue to trust us to adjust the levers in ways we deem important to our business, while keeping the scales tipped at-large towards open-source.

Standard Notes 3.6 Update

We’re excited to launch version 3.6 of our applications on every platform. This release focuses on simplifying access control measures, as well as giving you the power to review and revoke other devices signed into your account.

Session Management

You’ll now have the ability to review which devices are currently signed into your account. You can choose to Revoke an existing session. This will prevent that device from having access to your account. Revoking a session also removes all account data from that device. (Data removal feature requires all devices to be running v3.6+)


Prior to version 3.6, protecting certain actions, like viewing protected notes or downloading a backup, required you to configure complicated settings under the Manage Privileges screen. These actions were not protected by default until you went out of your way to properly enable them.

In version 3.6, we’re happy to introduce a change that will make protections a much more seamless experience. There are no longer any settings required to make protection work. Instead, the following actions are automatically protected:

• Viewing a protected note
• Downloading an account backup
• Other important actions, such as removing your application passcode or revoking a session

This means that to perform any of the above actions, you’ll be asked to enter your application passcode (or biometrics on mobile) first. If an application passcode is not configured, you’ll be asked to verify with your account password. (If you are not using Standard Notes with an account, and you do not have a passcode/biometrics configured, then these actions will proceed without verification.)

You’ll also have the option of “remembering” a protected session for a period of time, like 5 minutes or 1 week. When you choose for the application to remember, you won’t be asked to authenticate protected actions again until the selected time period has elapsed. If you choose to remember for 1 week, but change your mind afterward and want protections to be re-enabled immediately, you can do so from the Account/Settings menu.

Protected Notes

Prior to version 3.6, when you protected a note, we displayed a very prominent indicator on that note in your list of notes:

However, it’s often the case that when you protect a note, it’s more sensitive than usual. In that case, rather than drawing attention to it, you would in fact desire the opposite: if not totally hidden, then at least not vibrant and conspicuous. In 3.6, Protected notes have a much more subtle indicator:

The ideal experience is essentially that when scrolling through your long list of notes, your eyes shouldn’t be able to immediately pick out which notes are protected and which aren’t. This can be a particularly useful privacy feature if you have your application open in a public space, such as a school or workplace.

You might be wondering, as we did, why not take this a step further and make protected notes completely indistinguishable from regular notes, and not have any indicator at all? The reason primarily is for your own peace of mind: it can be somewhat alarming if you protect a note, return to it a week later, not see any special status on it in your list of notes, panic, and think, did I not protect this!? So for now we find the more subtle approach to be the most balanced one.

Security Audits

In case you missed it, we also announced the completion of two new major third-party security audits performed by Trail of Bits and Cure53. These extensive audits focused on both our application and server codebases, as well as our detailed encryption specification and protocol.

Read more: Standard Notes Completes Penetration Test and Cryptography Audit

What’s Next

Version 3.6 completes another round of “foundational” updates we’ve been eager to ship. These updates focus on features that improve the core experience centered around privacy and security. Our roadmap for the remaining year consists of two major projects:

  • Unifying our systems and architecture so that services such as Extended, our website, and Listed can communicate with each other in a more seamless manner. Currently you may notice that signing up for Extended, our paid subscription service, requires you to enter a separate email on our website (that may or may not be the same email you use to register for a notes account), then import a code into your app that activates your Extended benefits. We’d like for this process to be much simpler, so that there aren’t many parts that you have to worry about. Unifying this architecture will have many numerous benefits and solve several long-standing issues with the upgrade experience. But, as you can imagine, it’s a really big project. And we’re already well underway.
  • Files. This is a very important focus for us this year and beyond. Files are presently somewhat of a second-class citizen in our ecosystem, and requires configuring a few settings and linking an external cloud provider. We’d like to bring the same great user experience and reliability you’ve come to expect for your notes, to files. Imagine being able to open Standard Notes on your phone and seamlessly record a video or snap a photo that’s fully encrypted, and then have that file appear and securely synced to all your other devices instantly? Imagine being able to tag these encrypted files, attach them to notes, and more. We’re really excited about files, but, it may be our largest undertaking yet.

This wraps up our new releases and roadmap update. We hope you enjoy using our most secure and private experience yet on all your devices.

If you’d like to support our work and development—and unlock our full suite of productivity-enhancing features—you can purchase Extended, our paid subscription service. Extended unlocks editors including Secure Spreadsheets, TokenVault Authenticator, and a suite of Markdown and Code editors, as well as other powerful services such as daily email backups, extended note history, and more.

As always, please don’t hesitate to get in touch if you have any questions. You’re also welcome to join our community Slack group and follow us on Twitter for more frequent updates.

Standard Notes Completes Penetration Test and Cryptography Audit

We are pleased to announce the latest release of our encryption suite. This release uses the latest state-of-the-art, cryptographer-recommended algorithms for modern day encryption and key generation, designed to withstand the latest advances in cryptographic attacks and brute-forcing.

For data encryption, our latest cryptography suite uses the XChaCha20-Poly1305 algorithm. This algorithm is presently the preferred algorithm in many modern-day encryption contexts, and ranks above any of the AES-suite algorithms, like AES-GCM and AES-CBC.

For password based key derivation, our new release uses Argon2, a memory-hard algorithm. This is in comparison to PBKDF2, the previously and commonly used algorithm that has proven to be vulnerable to recent technological advances in specialized computer hardware, as demonstrated by cryptocurrency mining equipment, that can compute hashes very quickly. Because Argon2 is memory hard, each single guess at a hash requires around 70MB of memory. This makes it very, very expensive to mount a large scale attack and try to guess trillions of hashes. Guessing trillions of hashes using PBKDF2, however, is not nearly as expensive.

The implementation of the latest advances in encryption technology make Standard Notes more robust, powerful, and secure than ever. These new releases are backed by two new security audits conducted by two of the world’s leading cryptography research and testing firms: Cure53 and Trail of Bits. We engaged with Cure53 to conduct a penetration test of our entire ecosystem, including our cross-platform applications and server. Cure53 conducted a rigorous and thorough test, lasting multiple weeks, that helped ensure confidence in our ecosystem by finding any vulnerabilities in our environment. We also engaged with Trail of Bits to audit our new encryption release. This entailed auditing our specification, algorithms, and code implementation of the shared library we use in our applications to sync data and perform encryption and key generation.

We are very pleased with the results of both audits, and their impact on making Standard Notes the most secure note-taking application available. You can visit our Audits page to learn more about these, and other, audits.

What is a pull request?

One of the main ways software developers contribute to free and open-source projects is by creating pull requests to fix bugs, add features, clarify documentation, and to address other issues. A pull request is a proposal to make specific changes to the source code of a project.

Projects usually have multiple versions of their source code, and one of them is the main version. The maintainers of the main version often encourage other developers to contribute to their projects by creating pull requests.

How do pull requests work?

Pull requests typically have five parts: the issue, changes, discussion, approval, and merge.

The first step to creating a pull request is to identify an issue with the existing source code for a project. Pull requests are meant to be reversible, so developers are encouraged to make each pull request focus on one issue or topic. For example, fixing a website's styling and updating its content can and should be separated into two separate pull requests.

After identifying the issue, a developer creates a complete copy of the project's source code on their own computer. Since their copy is derived from another copy, their copy is known as a fork. The developer then proceeds to change their copy of the source code to address the issue they identified.

When the developer is finished with their changes, they write a summary of their changes. The summary may include details about which issue the changes are meant to fix, an explanation for their approach to the issue, and a description of any testing they performed to ensure that the changes worked as intended.

Then, the developer requests the maintainers to review and accept their changes. The developer and maintainers discuss any remaining questions about the pull request, such as whether the changes can be optimized or need further improvements.

If the maintainers think that the pull request is ready, they can approve it and merge the changes into the main copy of the source code. The developer’s pull request is granted and the developers “pull” the changes into the main copy.

Why do people create pull requests?

Each developer has their own reasons for contributing to free and open-source software. Here are a few common reasons:

  • Prestige. When the maintainer of a project merges a developer's pull request into the source code of a project, the developer is permanently attributed as a contributor to that project. For example, the Standard Notes web app repository has 23 contributors at the time of this writing. Developers can accumulate fame and prestige within the developer community by making significant contributions to important and valuable open-source projects. This can help them build an audience and find more employment opportunities.
  • Experience. Junior developers can gain experience and build their resumes by contributing to open-source projects with pull requests, and experienced developers can use them to practice their skills. This can also help developers find future employment.
  • Generosity. Software developers are problem-solvers at heart and often enjoy sharing solutions for others to use. By sharing the solutions, more people can benefit from them. Contributing to free and open-source projects with pull requests is a way to give back to a community or project.
  • Compatibility. Developers can create new features and fix bugs by modifying their own copy of a project to suit their own needs. However, they can ensure that the new features and bug fixes are compatible with future versions of the project by implementing them into its main source code. Pull requests also allow their feature to receive more critical review and attention.

Further reading:

This post was originally published on the Standard Notes Knowledge Base. Standard Notes is a free, open-source, and end-to-end encrypted notes app.

Join our Slack and follow us on Twitter to get all the latest updates about Standard Notes.

Encryption is for Everyone

People with wealth and power have many things that normal people do not. When they are sick, they have access to many of the best doctors and the best medical treatments. When they are well, they can afford to attend the most prestigious private universities and pay for their children to do the same. When they are in trouble, they can buy their way out with the help of big law firms. All the while, they leverage their private social networks to influence giant corporations and government officials to create laws, policies, and products that maintain their wealth and power generation after generation.

The lives of normal people are much more difficult. They struggle to pay for their healthcare and education, and they rely on the free legal guidance provided by the government, if any at all. They influence the government with only their spare change, voices, and votes. The rich and powerful thrive while normal people struggle to survive.

But there is one thing that people with wealth and power do not have better than normal people: encryption.

In 2001, the United States National Institute of Standards and Technology (NIST) announced the Advanced Encryption Standard (AES) as a cryptographic algorithm that can be used by the U.S. government to protect sensitive electronic data. Today, AES is still widely used to protect personal data, digital communications, and other important information technology infrastructure. There are many ways to implement AES, and they are named in part after the sizes of their keys. The version that uses 256-bit keys is known as AES-256 and is the strongest version.

Many free and open-source software programs such as Standard Notes and Cryptomator make it easy for people to use AES-256 to protect their privacy and personal information. With these programs, encryption can be used by anyone regardless of their sex, gender, race, ethnic group, religion, economic class, political party, criminal record, or national origin. In other words, encryption is a way for normal people to keep information from the economic and political elite. Such information could include facts and personal data that normal people could use to prevent the elite from further suppressing or infringing upon their rights. Encryption is a way for normal people to maintain what little power they have.

Furthermore, people with wealth and power cannot buy better encryption. The world's largest computer networks cannot break AES-256 even though the algorithms were invented over two decades ago and there have been great advances in computing technology. The wealthy and powerful may be able to hire mathematicians, cryptographers, and computer scientists to create new algorithms and implement them in proprietary software programs, but no amount of money can give them better encryption. Algorithms need to be tested with time and software needs to be inspected by communities in order to be trustworthy. Practically speaking, the elite cannot create better encryption software than what is already free, fast, easy to use, and impossible to break.

The widespread use and availability of a defensive tool as unbreakable as encryption software threatens the technological dominance that the economic and political elite have held for so long. Governments use it for themselves to protect their own secrets, such as those vital to "national security," but many of them try to limit access to encryption technology in order to surveill, censor, and otherwise control their constituents. Since they do not have the technical capacity to break encryption, they have to use social means to prevent its use. They create laws that ban its import and export and punish people who use it. They make software companies liable for how people use their products.

Governments usually create these policies under the guise of trying to prevent criminals from doing bad things, but they are also the ones who determine who is a "criminal" and who is not. The policies they create also affect the technologies that normal people have access to, but normal people can use encryption in a variety of ways that are not harmful or morally wrong. As a result, the economic and political elite determine the rules of acceptable behavior for everyone except themselves. Therefore, attempts to limit access to encryption are attempts to further undermine the power of normal people.

If you believe that normal people should have the power to protect their own private personal information, then you can help us maintain our power by acting on your beliefs. You can exercise your rights to freedom of speech, privacy, and encryption. You can tell your government representatives to reject legislation that would prevent its use. You can use, support, and share encryption technologies with others to spread awareness. Software programs like Standard Notes, Cryptomator, and Bitwarden are designed to protect your personal notes, files, and passwords with AES-256 encryption. They are all free to use and open-source.

The right to use encryption is a fundamental human right as inalienable as the right to think freely in one’s own mind. It is a tool that belongs to everyone, not just the economic and political elite. Help us protect our right to keep personal information private and our freedoms to think, speak, and communicate by standing up for encryption.

Further reading:

Join our Slack and follow us on Twitter to get all the latest updates about Standard Notes.

How to block ads and trackers in Safari for iOS

Ads on the web are annoying and most trackers betray our privacy by giving third-parties information about the sites we visit and the topics we are interested in. These third-parties can then track us around the internet to sell us more ads, distort our search results, and give our browsing history to governments. When we block ads and trackers, websites are easier to read and faster to load, so we save time and bandwidth (data).

Blocking ads and trackers is easy on desktop browsers thanks to extensions like uBlock Origin and Privacy Badger. These extensions are not available on iOS, but we can still block ads and trackers in Safari by downloading additional apps and enabling them in the Settings.

The installation process is the same for each app. After installing the app from the App Store, visit Settings > Safari > Content Blockers and enable them. In the Settings, you may information about content blockers:

Content blockers affect what content is loaded while using Safari. They cannot send any information about what was blocked back to the app.

The following apps seem to be reliable content blockers for Safari:

‎Firefox Focus: Privacy browser App StoreMozilla
‎Better Blocker App StoreInd.ie
‎AdBlock Pro for Safari App StoreCrypto, Inc.

Firefox Focus is free and open-source and is also available on Android. The source code for the Android and iOS apps are available on GitHub.

Better Blocker is also free and open-source. Its source code is available on GitLab.

Adblock Pro is not open-source, but it does not require account registration and it does not require any special permissions. Their privacy policy states that the "App does not collect any personal information" and that the "App uses Apple's native Content Blocking API - it only supplies blocking rules to Safari, without having any access to your browsing data."

You can use each of these apps on their own or all together to maximize the number of trackers blocked. Better Blocker is the simplest to use, but Adblock Pro provides the most customization.

Join our Slack and follow us on Twitter to get all the latest updates about Standard Notes.

What is Free and Open-Source Software?

Software programs, like other creative works, are released to its users under certain terms and conditions called licenses. When a license gives its users the rights/freedoms to use, study, copy, modify, improve, and redistribute it, then the software is considered free, or libre, and open-source software (FOSS).

Background: In software development, companies and developers write software as a collection of many files called the source code or the code base. When the software is ready for use, they compile the source code into executable files. For example, applications on Windows and macOS typically have the file extensions .exe and .app, respectively. These executable files are usually unreadable and recovering the source from them is usually impossible.

  • If the developers keep their source code private, then the software is said to be proprietary or closed-source.
  • If the developers publish the source code for the public to study it, but do not grant them the all freedoms of open-source software, then software is called source-available.

In conventional software development, companies release proprietary software and they require you to purchase a license or subscription in order to use it. This sometimes works well for consumers, but there are important restrictions to be aware of when using proprietary software. If a software program prevents you from exporting your data and using it in another compatible program, then you are forced to maintain a subscription for it in order to maintain access to your work. This tactic, known in economics as vender lock-in or consumer lock-in, is a way for technology companies to make it difficult for you to stop using their services.

Free and open-source software avoids locking-in consumers and instead provides them with several valuable rights:

  • Users of free and open-source software are permitted to use it for any purpose (except for those prohibited by law).
  • Users and third-parties can independently study and inspect FOSS programs to verify the authenticity of claims regarding its privacy and security. By making the software transparent, it has the potential to be safer and more trustworthy.
  • After obtaining copies of the source code, users can modify it to fit their needs. These modifications may include improvements on the original code or removals of existing features (e.g., those that invade privacy, create security vulnerabilities, or are simply unnecessary).
  • Users of FOSS can choose to redistribute their software, modified or not, to other people without fee or for profit. The right to redistribution allows users to share their modifications and improvements with others.

Some FOSS licenses require that any redistribution of the software must also be licensed with the same license as the original software or at least be licensed in a way that does not revoke any of the rights granted by the original license. These licenses are known as copyleft licenses and are meant to guarantee that any modifications of FOSS remain part of the community as FOSS.

Example: The strongest copyleft license for FOSS is considered to be GNU Affero General Public License Version 3.0, or AGPLv3, because it requires that anyone who uses the software to provide a service over a network must also provide its complete source code, even if it's modified.

Standard Notes publishes the source code for its web, desktop, and mobile apps as well as its syncing server and extensions under AGPLv3. This means that any individual or company can legally use all our free and open-source software for their own commercial purposes and therefore potentially drive us out of business. However, the AGPLv3 license requires that they must also release their software under AGPLv3, so any improvements that they make to it ultimately return to the Standard Notes community. This means that if Standard Notes were to disappear for whatever reason, then the community would be able to maintain the service and your notes would continue to be safe.

Further reading:

This post was originally published on the Standard Notes Knowledge Base. Standard Notes is a free, open-source, and end-to-end encrypted notes app.

Join our Slack and follow us on Twitter to get all the latest updates about Standard Notes.