Goodbye Google! For the past couple of years I’ve been using the company’s services extensively, but with the amount of scandals and privacy issues it was time to cut ties.
It was November 2011 when I first signed up for what was then called Google Apps for Your Domain. Google marketed their suite as kind of a cool new centralized platform for your mail, calendars, contacts and documents, at a time when the only viable solutions were either Microsoft’s Exchange (plus Sharepoint), Lotus Domino/Notes or some half-baked open source platforms like Zimbra or Scalix (a.k.a. Open-Xchange with commercial support). Everything else was basically just multiple open source components glued together into something that would very likely allow you to send and retrieve e-mails, maybe manage contacts and calendars but most definitely not deal with meeting invitations or allow for connecting mobile devices (since it usually required ActiveSync compatibility, which back then was really hard to get). From an integrative standpoint, Google offered all the niceties for example MS Exchange had, without any of the pain-points involved in actually maintaining an own Exchange infrastructure. Also, by allowing customers to bring their own domains, connect them to different mailboxes and have good filtering options in place, it was convenient to use Google Apps for business as well as private purposes. Additionally, with their SSO it was easy to integrate and use other services like Google Analytics and later Google Cloud Platform as well. And with the product being available for five years already at that time, I was confident that it wouldn’t become another Google Wave.
At that time, Google was still carrying the reputation they got from their founder’s “Don’t Be Evil” manifesto and therefore it seemed like an okay choice to jump their bandwagon. Unfortunately, over the past ten years things changed and so did Google’s policy and behavior. But with Google Apps (or G Suite or Google Workspace or whatever it’s called these days) becoming more feature-rich and convenient to use, it slowly blended into my daily workflow. At some point it became so invisible to me that I often forgot that an uncomfortably large portion of my digital identity was stored on proprietary servers.
However, every now and then, when Google screwed up so badly that media outlets and online communities reported on it – be it either due to privacy issues or simply because of awkward company policies or blocking of people’s accounts – it came back on my mind and had me re-think my own setup. Believe it or not, but I’m someone who’s really concerned about privacy. On the other hand it’s e-mail that we’re talking about – something that lacks of any privacy and security by design. Then again I should probably not upload my whole address book to Google’s servers only to have it available across every device I own. But then again probably 90% of the people in that address book do the same on their sides, meaning that even without me uploading my address book, Google still knows relationships very well. And it’s pretty much the same story with calendars, as well as with other services like Analytics and GCP. Google’s stuff is everywhere these days, powering large parts of the internet. So why even bother to invest time and effort into migrating years of mails, contacts, calendars, domains and other platform data, especially if that might mean jeopardizing on reliability and comfort?
I guess, from a purely pragmatic standpoint, it doesn’t make any sense. Google Workspace, like many of Google’s services, is great. However, it became very clear that while their software works, their intentions and policies don’t. Moving from Google therefore is not a pragmatic step to take, but rather a conscientious one. I asked myself “Do I want to continue giving my money and my data to a company that definitely won’t do ’the right thing’ with either?”. And the answer to that is clearly no.
One year ago I therefore took on the task of unplugging the cables from anything Google, one by one. This is how far I got.
In one mile, turn left: Leaving Google, heading… where exactly?
Ten years ago I would have probably gone with a self-brewed setup, using components like Cyrus or Dovecot, Postfix, DAVical or Funambol only to cover my basic requirements for mails, contacts and calendars – not even considering the efforts that would have gone into running something even remotely comparable to Google Cloud or Analytics. Luckily, these days there are more and better options to either DIY Google’s services or at least pay for someone else to do that for you. And most setups and service work significantly better on a variety of platforms than they did years go. Some even provide their own client implementations in cases in which the off-the-shelf stuff won’t do the job (thinking E2EE here).
The challenge today is not finding something that works but finding a setup or service that works best for one’s specific needs. In order to do that, I had to re-evaluate my needs. The stuff I found relevant ten years ago when I signed up on Google Apps isn’t as relevant today anymore. Partially because it became standard equipment for every service and partially because times have changed and the way I work with mails, contacts and calendars also has changed.
Back at the time, mail was crucial, because it was one of the very few options for long-term communication – especially in the business area. Today e-mail is more of a sideshow in correspondence. I communicate with a few dozen people across multiple platforms and messengers, but I barely know anyone’s e-mail addresses. At least for me, mail today is mainly what the physical mailbox was a century ago: A place where documents like offers, orders, invoices, contracts and statements are being sent from or to. I rarely write mails and if I do, they’re usually related to one of these topics. 90% of my actual communication happens over messengers.
Considering that my inbox is basically a document storage, I started wondering whether I should maybe treat it like. Some of the questions I asked myself were:
- Do I really care whether the service offers a smart compose feature, when most of my communication does not happen via e-mail?
- Do I have to have an intelligent inbox where invitations and bookings are added to my calendar, considering that every meeting and booking app already provides similar features on their own?
- Do I need to have an integration into a payment platform in order to send money by mail?!
- Do I need the ability to schedule e-mails, considering that e-mail in itself is already asynchronous enough?
- Does it make sense to have all sort of highlighting and displaying options for mails, considering that I’m using a separate to-do list anyway?
- Wouldn’t it make sense, if the service provided some sort of confidentiality, considering that most mails contain documents which in turn contain my personal data?
- Do I really want for AI to scan all my mail’s content in order to provide me a questionably small set of benefits? Shouldn’t I rather prefer a service which instead will not look into my mails?
It became clear to me that the set of feature I got used to on Google Mail
wasn’t exactly what I needed anymore. Instead, it turned out that it’s more
important to me to keep my data safe from prying eyes and attackers and that I’d
rather have someone take care of my mails who won’t try to sell information about
me to advertisers. And as it turns out, these days there are companies that
specialize in just that: Encrypted e-mail inboxes for the masses. Companies like
Fastmail, ProtonMail, Tutanota and others cater to the kind of people that prefer
that little bit of extra security over feature-richness or compatibility.
I compared a few of them and wrote down my thoughts on each. If you’re not interested in the details, simply skip the following section.
Fastmail seems to be one of the more popular providers on the market. However, don’t be tricked by their marketing: Fastmail is not a privacy-focused e-mail provider. Fastmail is more like Google Mail but without selling your data to advertisers. And while your mails are encrypted at rest, mails and inboxes are not end-to-end encrypted between your client and the Fastmail server, meaning that it’s possible for them to access your mails and simply read them. In fact they openly point it out in their own documentation.
Fastmail is a sufficient alternative if your main goal is just to get rid of Google Mail. It’s comfortable because you can continue using any desktop and mobile client you were using before. Just don’t expect it to be privacy-respecting, due to the lack of end-to-end security. Also keep in mind that Fastmail is an Australian company with servers located in the USA – two of the least ideal jurisdictions from a privacy standpoint.
Mailfence is lesser known, although they have been around for over a decade. It’s a true E2EE mail service where your mails and data are not only encrypted at rest but at any time, using OpenPGP to encrypt/decrypt mails in the client before they send/request them to/from the server. However, while they make statements like “we have done everything (humanly) possible to mitigate such threats” regarding Powerful state-funded attacks I’m still a bit puzzled about them not having mobile clients for any platform and prefer their customers to simply use mobile browsers (which might have been tampered with) to access their mails on the go.
Mailfence is located in Brussels (that’s where the EU headquarters are), which might not be an ideal jurisdiction as well, especially considering the latest developments in regard of data privacy throughout Europe.
Posteo is a German e-mail provider that also paints itself green (literally) in terms of security and privacy. While they do have additional software in place to keep your mails encrypted at all time on the server-side, for the brief moment of you requesting an e-mail (e.g. through the web interface or your IMAP client) they will automagically decrypt it (on the server-side) and transfer the unencrypted mail over a secure connection. While this approach goes a notch further than what Fastmail does for example, it still won’t cover thread-models in which government-backed actors or similarly high-profile adversaries take part.
Posteo is located in Berlin, Germany, which, just like Mailfence, subjects to the EU jurisdiction and additionally has a scary track-record of privacy-infringing policy attempts. See Tutanota for more info on that.
Disroot is more of a movement rather than a company or service provider. While their cause is honorable, the e-mail service lacks of any real security features whatsoever. It’s unclear whether they even encrypt mails at rest.
Most people have probably heard of this one by now. ProtonMail is partially funded by the EU’s own Horizon 2020 programm, is headquartered in Geneva, Switzerland and has additional offices in San Francisco, USA as well as Skopje, North Macedonia. Like Mailfence, ProtonMail also makes use of OpenPGP in order to perform E2EE and keep mail data encrypted at any time. In addition, they open source many of the components they use to provide their service, gaining a few points in terms of transparency. Unlike Mailfence, ProtonMail has dedicated iOS and Android apps that users can download from the app stores. Additionally, ProtonMail has something called a bridge which allows people to continue using their existing mail clients (like Apple Mail or Thunderbird). The bridge acts as an intermediary between the client (which only speaks IMAP) and the ProtonMail server (which only speaks encrypted-mails-gibberish).
All in all ProtonMail provides a very solid service with really cool features. For most people, ProtonMail will likely be a perfect fit. However, while the Swiss jurisdiction might appear like a solid turf for your data, ProtonMail will cooperate with Swiss law enforcement if required. And Swiss law enforcement as well as other institutions also had their fair share of skeletons in their closets. Also take in consideration US/Swiss MLATs.
In addition, the investment from the EU might be considered as getting a foot in ProtonMail’s door. In fact, if you take a look at the Horizon 2021-2022 programme agenda you will see on page 20 for example, that the EU actively allocates funding for HORIZON-CL3-2021-FCT-01-02: Lawful interception using new and emerging technologies (5G & beyond, quantum computing and encryption), among others. The German journalists from Netzpolitik.org have already reported on how the EU is actively trying to gain access to encrypted communication, e.g. 5G. Not mentioning the disturbing ideas EU legislation has taken on.
And if that’s not enough, just considering the popularity of ProtonMail, we might assume that it is a very attractive target for individual adversaries as well as state-backed attackers.
Tutanota is basically Germany’s version of ProtonMail. They sport a similar set of features, they operate using similar technologies, they do some OSS and they are presumably as secure and privacy-focused as their Swiss counterpart. The only difference is really just the name, which, frankly speaking, I find incredibly awkward to pronounce without drifting into a famous Italian plumber stereotype.
Having that said, Tutanota has a significant disadvantage over ProtonMail: The German jurisdiction. Not so long ago, Tutanota was already forced by a regional court ruling to monitor an account. In addition, only a few days later news broke that the EU Council adopted a resolution that supports lawful access to encrypted data. Shit hit the fan so badly that the privacy-focused companies ProtonMail, Threema, Tresorit and Tutanota openly spoke out against this. “But wait, ProtonMail, Threema and Tresorit are Swiss companies. They won’t be affected by the outcomes of this EU resolution?” you might ask, to which I would reply: Hey, remember Swiss banking secrecy?
CTemplar is a service very similar to ProtonMail
While it does not (yet?) have all the bells and whistles its
European counterparts have, CTemplar provides a solid set of basic features,
paired with a similar focus on privacy and
transparency. Mails on CTemplar are also fully
E2EE using OpenPGP and they have a web client, as well as iOS and Android
client apps that support push notifications for new mails.
However, the really interesting part is that CTemplar is neither a US- nor an EU-based company. Instead, they’re incorporated on the Seychelles – a place with a constitutionally guaranteed right to privacy, no mandatory data retention requirements, and an independent legal system – and they operate their servers in Iceland. And yes, of course they have a Warrant Canary.
Update: After several months of (paid) use, I do not recommend CTemplar to anyone who is depending on their e-mail account. While smaller issues get solved right away, there are a couple of real show-stoppers.
First and foremost, their web and mobile clients. The UI is barely usable, most of the time it’s even impossible to read e-mails or download attachments. Additionally it suffers from glitches and performance issues, making it really tiring to navigate through mails, let alone reply to conversations.
CTemplar still does not offer a bridge that would let one connect with any IMAP/SMTP client. And since it’s not even possible to download an export of all mails (oh hi vendor lock-in!) you’re basically stuck, which doesn’t help with the overall confidence in their service.
Another show-stopper for me was the fact that apparently certain functionalities might lead to an unannounced loss of all mails. The fact that an occurrence like this is being brushed off lighthearted doesn’t increase confidence in their service either.
I tried hard to use CTemplar - and more importantly enjoy using it - but it simply didn’t let me. For a service for which I pay as much as for Google’s whole suite of services combined, such issues aren’t neglectable.
Update 2: It was announced that CTemplar had an incident in which they lost all customer mails. Apparently they did not backup any of the data, hence no mailbox could be restored. The account that I still had and contained a couple of mails is now completely empty.
This event wouldn’t be as bad if CTemplar would have had a bridge in place by now, so people could have backed up all their mails on their local machines. I too have had a couple of mails in my account for which I only have a backup of the attached files but not the mails themselves.
After evaluating three of the services by setting up paid accounts, I decided to
go with CTemplar. From a feature-perspective it’s definitely not a front-runner
and I even had trouble setting up UTF-8 domains – spoiler, use puny-code. Also
decrypting sender-encrypted GPG mails through their front-end didn’t work –
spoiler, they don’t support that (yet), but it’s possible to simply
introspect the HTTP request, get the GPG encrypted content of the mail and
decrypt it yourself using GPG on the CLI. Nevertheless, I value the effort they have put into setting up the company
structure and I value their stand on privacy. Of course, a bridge like
ProtonMail has would have been nice. That way I could have continued using
mutt and other e-mail clients. But that’s also not a deal-breaker.
TODO: Switch from CTemplar to a different service.
I have read many threads and comments on various privacy-focused services and there seems to be a general misconception. Neither of them offer real zero-knowledge-type of privacy. At best, users can only trust a service to not store data in plain-text or have something in place that allows them to decrypt their own E2EE communication.\ These services are nevertheless technically able to read every single mail that is sent from or to either of their users, simply because that’s the nature of e-mail. The only solution to this issue is real E2EE where two communicating peers use GPG to encrypt/decrypt the messages on their ends, instead of trusting ProtonMail, Tutanota or any other service to automagically do that for them - which will only work if both peers use the same service.
The privacy I am talking about here mostly refers to trusting a service to not spy on your communication for their own profit and trusting a service to store data encrypted, so in case someone gains access to it through whichever means, they won’t be able to make use of the data. In the end however, it really comes down to trust, since neither of these services are auditable by anyone else but them.
That is also the reason why the jurisdiction is an important part here. Ideally, such a service would be subject to laws that would prohibit anyone from pressuring them into sharing your data with any other instances. Also, these laws should hinder foreign as well as local governments from monitoring or requesting decryption of user data.
Contacts and Calendars
While CTemplar has an integrated, encrypted address book, it’s not possible to connect it as CardDAV account to my computer and my phone. Therefore, the first step for me to get rid of Google was to move all contacts and calendars from Google Workspace to my already existing iCloud account.
This is an intermediary step until I have the time to dig deeper into the possibilities of keeping these two data pools in sync across multiple devices and ideally different operating systems. So far I briefly looked at Fruux and EteSync and both seem promising. But since contact information and calendar entries are actively synced into iOS apps built and maintained by Apple (the contacts app, the phone app, the calendar app), I don’t really see that much of a benefit in finding a more privacy-focused storage for those, to be honest. But you know…
… once you get locked into a serious
drugprivacy collection, the tendency is to push it as far as you can. — Hunter S. Thompson
The accounts I used on Google Workspace had custom domains configured, which I registered through various domain registrars. I decided to go the full mile and take care of the domains as well. Since I’m not willing to pay registrars a whole year for a transfer when the domain is still registered for several months to come, this process is going to take a little longer to complete.
I checked different well-known registrars like Cloudflare, GoDaddy, Namecheap, Hover, etc. but they all operate similarly. If you’d like your domain to be private you add another $20 to $30 per year (per domain!) and activate a so called privacy guard. This feature basically replaces all personal contact information usually provided by the registrar to ICANN with generic data, protecting the registrars client from appearing in WHOIS requests with his private contact information. However, usually only little persuasion is required to get the registrar to release the private contact information. Most of the time a simple phone call or cease and desist letter will do the job. Not exactly what one might expect from a privacy guard.
Therefore, instead of paying for basically nothing, I decided to move all my domains to a Nevis-based company named 1337 LLC, that operates a service called Njalla. Njalla is a domain proxy that registers the domain in their name, meaning that they will be the actual owners of the domain. Obviously some trust is required to operate domains this way, because it allows Njalla to basically do whatever they’d like with your domain. On the other hand, unless you happen to own motionpictures.org I don’t believe there’s enough motivation to displease a paying customer only to snatch up a domain name.
Since registrations on Njalla are possible over VPN/Tor and payment via Monero is available, it can be used as truly private domain registrar. And just in case things should go sideways some day, they seem to enjoy dealing with requests of all sorts.
Google Cloud Platform
I used GCP for many personal as well as business projects, not necessary because I liked it. GCP actually sucked heavily and still does in many ways. It was however cheaper than AWS while still offering features like serverless execution environments and fully-managed databases. Moving from GCP meant to either find a different service that supported serverless architectures or move to a different stack for most things.
Unfortunately, there really aren’t many cloud service providers that offer serverless architectures that are billed by exact duration/requests. I decided to migrate everything (yeah, no shit) to a managed Kubernetes environment and give DigitalOcean a try. Today, roughly one year later, I know that it wasn’t my best idea. Apart from the additional administrative effort (which is pretty intense with Kubernetes & Helm charts) the costs for running my infrastructure are threefold the costs of running it on a serverless environment. Unless there will eventually be more companies providing services comparable to Google’s Cloud Functions or AWS’ Lambda, I will very likely have to return to either GCP or AWS.
Last but not least, Google’s analytics platform. This one was pretty easy to get rid of - mainly because I don’t depend heavily on the data in neither my personal nor my business related services. In fact, I give so few fscks about SEO that I deliberately chose to use a domain name for this journal that only about 1.92% of people on earth will be able to actually write. Everyone else might feel free to memorize mrus.me instead.
Initially, I replaced Google’s overly complex service with Fathom – which I then replaced only recently with Plausible. Both, Fathom as well as Plausible, provide a very privacy-respecting way of measuring page views and such data. That’s also the reason you don’t need to click away any of the GDPR cookie consent BS on this site, btw.
Additionally, both services are open source, so one could DIY their own analytics service or simply use Fathom’s or Plausible’s hosted (but paid) variants. The reason I ended up switching from Fathom to Plausible was simply because I found Plausible to move slightly faster than Fathom, in terms of development speed. Also, Plausible’s paid offer is slightly cheaper than Fathom’s. Oh, and Plausible is built with Elixir, which is pretty cool.
While I accomplished to migrate (or at least begin the transition) away from
Google for individual services I was using, I’m still far from done. Not because
I’m still using Google-owned services – I’m not. But there are more service that
I use and that are either powered by Google or at least make a profit off of selling
my data one way or the other. Those I’m looking forward to replace in the long
run as well. For example, with
Journalist I already began writing my own
RSS aggregator in order to be able to leave Feedly behind as soon as possible.
Similarly I’m working on yet to be open sourced services to replace the
closed-source and privacy-concerning variants of other services that I’m
currently still using.
In order to better keep track of all this info, I will publish a dedicated page that neatly lists all the services I’m currently using, which I will update every time I manage to replace another dodgy service with a more privacy-respecting solution. If you’re interested in switching from all sorts of different software yourself, have a look there from time to time and check out the following additional resources:
published [ ] · updated [ ]