Mitigating Risk of Online Service Failure
Oyzark. email@example.com. Twitter @oyzark
In the privacy community, we experience a higher risk than most people of having the online services we rely on suddenly become unavailable to us. There are several reasons for this: we tend to use smaller, newer and lesser established platforms such as ProtonMail instead of the behemoths such as Gmail used by the masses; government actions can force sudden closing of privacy-oriented services (think LavaBit); and in pursuing privacy we tend to exhibit non-typical behaviour patterns that can trigger alerts on our accounts.
There have been several reminders of this recently, including the sudden closure of the CTemplar email service, and Michael's experience with Telnyx phone service as described in a recent podcast. Personally, I just lost my SudoMax 9-phone number account for a couple of days due to some kind of system glitch. Fortunately their excellent support got be back up and running quickly, but it serves as a reminder that all systems are vulnerable.
In this article, I describe steps I have taken to mitigate risks to some of my most important online services – email, contacts, calendar, notes, messaging and phone. These are somewhat specific to my situation but I think the steps are generic enough they could be implemented by others.
Email, Contacts and Calendars
A ProtonMail Professional account (protonmail.com) is the hub for all my personal email activity, as well as personal contacts and calendar. If the account disappeared one day without mitigation, it would have a pretty significant negative impact, including losing friends and family contact information, losing precious old emails, missing new emails coming in, and having no idea what events I am supposed to be at in the future. This is all important enough that I need to keep a backup, but also get back on my feet again within hours if my ProtonMail account were to disappear. Here I describe a validated approach to using Tutanota as my alternate provider in case of loss of ProtonMail. The first steps are to ensure that all my important information is backed up somewhere regularly outside of ProtonMail; then comes ensuring I have an alternate, tested system that would get me back on my feet using email, contacts and calendar in hours, even with ProtonMail gone. Here are the steps I took:
Switch to a custom domain in ProtonMail. Rather than use firstname.lastname@example.org, I have ProtonMail host my own domain, so my email is more like email@example.com. This has several advantages including avoiding problems caused by services not liking ProtonMail domains, and meaning I can quickly switch my email provider to another one without changing my address. You do need a paid ProtonMail account for this, and you do need to buy a domain from a registrar like GoDaddy or NameCheap. ProtonMail has instructions on setting up a custom domain in ProtonMail (https://protonmail.com/support/knowledge-base/set-up-a-custom-domain/)
Create an offline backup process for existing email. The easiest way to do this is to run Proton Bridge (only available on paid accounts) and use an offline email program such as Thunderbird to archive mail. Thunderbird will ingest email continuously (when open) and save it locally in your profile folder. This profile folder can be copied to backup storage. To find the profile folder location in Thunderbird go to Help –> More Troubleshooting Information and click About Profiles. You will then see the root directory that is used for your current profile. The beauty of this approach is that Thunderbird has excellent offline search capabilities, so you get some helpful functionality beyond backup; and if I did lose my ProtonMail I probably would just leave old email in Thunderbird and access it there. An alternative is to use the ProtonMail Import-Export app (https://protonmail.com/import-export, also only available for paid accounts) that saves an MBOX file to your local storage. This is a manual process, but you can create a full backup just once, then create incremental backups of your mail by setting date ranges in the backup dialog. Most email software and providers allow import of MBOX files, so you are relatively safe here. I decided do to both Thunderbird and MBOX files. Do be aware that this can really use up some disk space, and exporting to the MBOX file can take several hours if you have a lot of mail.
Create an offline backup process for contacts. This is a simple, but manual process. Click on the contacts icon in ProtonMail, then Settings, then Export Contacts. Your contacts will be decrypted and saved in the standard VCard (.vcf) format.
Create an offline backup process for calendar. Similarly, in calendar go to Settings then Calendars. Beside each calendar is a dropbox with the option Export ICS. This will save a standard .ics calendar file with all your appointments. An alternative is to create a calendar link under Share outside Proton. This will give you a URL you can use to ingest your calendar into another calendar app, such as the one in Thunderbird. Make sure this app keeps an offline copy of your calendar entries. The link also gives you a quick way to save an ICS file without being in ProtonMail – just paste the URL into a browser and it will prompt you to save the file.
Set up Tuanota as backup provider for email, contacts and calendar. It was very straightforward to make a new Tutanota account. I could have gotten away with just keeping a free account and upgrading later if needed, but I wanted to test the domain hosting capability, so decided to purchase the “Business Premium” account (€24/year) which allows multiple custom domains. Privacy.com payment was accepted.
Test it out! This is the most important step. If you don't fully test your mitigation plan, you can be sure there will be a fatal flaw when you really need it. So I went through the whole process of hosting a test domain in Tutanota, then ingesting my contacts and calendar entries. The testing brought up two issues. First, Tutonota does not currently have the ability to import emails (it is on the roadmap). This is not a showstopper, as I am okay leaving my old mail in Thunderbird and accessing it there when needed. I did note though that Tutanota does not have a batch export capability either which could be an issue down the road (also on roadmap, although you can export individual emails). Second, Tutanota gave an error when trying to import the contacts exported from ProtonMail. After some exploration, this seems to be because ProtonMail is exporting VCard version 4.0, whereas Tutanota seems to be expecting an earlier version. I was able to fix this with the sed tool on Linux, to replace the version number in the file (replace the filenames with yours):
sed 's/VERSION:4.0/VERSION:3.0/' 'protonContacts-X.vcf' > protonContacts-X-Tutanota.vcf. Other than that, importing the contacts and calendar into Tutanota was straightforward. Adding a custom domain is explained briefly at https://tutanota.com/faq#custom-domain. Cliking on Global settings –> Custom email domains –> Show then clicking the add button will get you strated. I did this, and it worked well.
I use Standard Notes (standardnotes.com) for organizing a lot of fairly random but important textual information. Standard Notes has excellent backup options, including options to save encrypted or unencrypted backups directly to disk, or have them sent regularly to you by email. Encrypted backups can be decrypted back into text or an unencrypted Standard Notes import file using an offline browser-based decryption script available at https://github.com/standardnotes/decrypt. Of course just having lots of plain text isn't super useful, and I need to be able to quickly restore a Standard-Notes-Like interface should Standard Notes become non-functional. For this I chose Joplin (joplinapp.org) an open source note app. It's not quite as flexible as Standard Notes, but would do the trick in a pinch.
Getting notes from a Standard Notes backup into Joplin takes a couple of steps, made much easier with a Python script available at https://github.com/tanrax/standard-notes-to-evernote-or-joplin. This script transforms an unencrypted Standard Notes backup file into an EverNote ENEX file called notes.enex, that can be imported directly into Joplin. If, like me, you like to store your Standard Notes backups as encrypted, you have to do a bit of wrangling to get the output of the decryption script into a format that works for the Evernote script. Specifically, the Evernote script expects the text to be in a file called “Standard Notes Backup and Import File.txt” that is in a compressed (ZIP) container. So the steps you need to do starting with an encrypted Standard Notes Backup file are as follows (for Linux, you can do similar on other operating systems):
Decrypt the backup file using the web-based decryption script, and choose “download as decrypted import file”. This will create a file called decrypted-sn-data.txt
Rename this file:
mv decrypted-sn-data.txt 'Standard Notes Backup and Import File.txt'
Compress this renamed file:
zip sn.zip ./Standard\ Notes\ Backup\ and\ Import\ File.txt
Run the conversion to ENEX script (you will need Python installed):
python3 standard-notes-to-enex.py ./sn.zip
Import the notes.enex file into Joplin (File –> Import –> ENEX (as Markdown))
Messaging and phone
Messaging is quite straightforward, as like most people I only use text messaging for ephemeral communications that I don't need to persist for long. Thus backups and archiving are not really necessary, but redundancy of service is. I currently use Signal and Wire as my primary messengers, and have a few others like Element/Matrix and Session for experimental or backup use. While their usage is differentiated, they do all serve as a backup to each other. So for really important contacts, I try to connect with them on at least two messenger services, so if one goes away, then we can use the other. I also where possible ensure I have an email address for anyone I am contacting on a messenger, so if, for instance, my account gets disabled on one of the messaging services, I can easily correspond by email once I have a new account set up. Signal does, of course, have a critical dependency on a phone number, which I think is a vulnerability as the number itself is under the control of a third party (see below). So I am starting to favor messengers that don't require a phone number linkage.
Unlike messaging, phone numbers are a real headache for risk mitigation. The problem stems from two realities that are at odds with each other. The first reality is that keeping a phone number, if you are a privacy enthusiast, is actually quite a lot of work and to a large degree out of your control. Your phone number is owned not by you, but by whatever VoIP, landline, or cellular provider you lease it from. If that provider goes out of business, has a technical failure, or simply decides they don't want to do business with you anymore, you either lose the number, or if you are lucky you manage to port it to another provider through an unreliable, clunky process called porting. The second competing reality is the legacy social expectaion that you will have a “phone number” and that this number will persist for years or even decades. So you have to act as if your phone number is virtually part of your identity, yet you have little control over its persistence.
It's 2022, why do we need to loan a 10-digit number in order to be able to communicate with people? The truth is we don't. We are so conditioned to our “contact information” being name, email address and phone number, that we don't think about how silly it really is given the many communications options available to us. So the shift I am making is as much a pushback of social expectations than a technical mitigation.
Here's my strategy. I own a longstanding Google Voice number. This number forwards to whatever VoIP number I am using currently, along with my office phone. SMS messages are sent to my email. Of course Google could pull this number at any time, but given all the options available to me I think it is the most stable number I have, even if it's not the most private. When someone asks for my phone number, I respond with something like: “I'm in the midst of switching providers right now (always true!) so the best way to contact me is by (email/messenger). If you really need to use the phone you can try calling my Google Voice number XXX and I should get the message”. In this way, I am minimizing the expectation that using a phone number for me will be effective, while giving a modestly reliable option if they absolutely have to use a phone. This means I have a somewhat stable personal phone number when needed, freeing me to use VoIP services for more “disposable” numbers, such as for forwarding from my main nunber or for temporary aliases. This is not perfect, and I'm constantily adjusting my strategy here.
What I most want you to get out of this article is a sense of the importance of planning in detail an alternate strategy for the online services that are important to you. It's only a matter of time until you experience a service failure, and if you plan for and mitigate such a failure you can minimize the disruption to your life. I can now sleep well knowing I have a tried and tested mitigation strategy for my most important stuff.
This article was originally posted in Unredacted Magazine Issue 003.