Can You Actually Leave? — Stefandango.dev

I run a stack of self-hosted services on hardware I control: DNS, passwords, notes, RSS, push notifications, vector search, the reverse proxy in front of all of it -- behind a mesh network I operate, in jurisdictions I chose on purpose. I have written a three-part series on this blog about why geography is not jurisdiction and why EU companies should care where their AI vendors answer subpoenas.

My calendar is on Google. It has been the whole time.

This spring I finally set out to fix that -- or at least to wire it into my self-hosted morning brief while I worked out where it should actually live. What followed was a prolonged investigation that ended somewhere I did not expect: I kept the Google calendar, killed the integration I had already designed and priced, and walked away having learned that the most privacy-respecting calendar vendor in Europe would have been harder to leave than Google. Somewhere in that failure is a question too few buyers ask before adopting a service, and it is a better sovereignty metric than anything I covered in the jurisdiction series: not where is my data -- but what does it cost me to take it back?

The question the jurisdiction series didn't ask

The earlier series argued that hosting region and legal jurisdiction are independent axes -- that a Frankfurt data centre owned by a US company answers to US law, and that "EU cloud region" is a geography claim wearing a jurisdiction costume. That argument still stands.

But jurisdiction is a question about where your data sits. There is a second axis, and it is independent of the first: what it costs to take your data back. Call it exit cost. It is a measurable property, not a vibe -- it lives in protocols, export formats, and credential models, and you can evaluate it before you sign up. Too few of us do. I didn't, and I write about this for a hobby.

The uncomfortable finding of this post is that the two axes are not just independent -- for at least one pair of vendors I tested, they point in opposite directions.

Trying to leave Google Calendar

The trigger was small. My morning brief -- a scheduled agent that assembles weather, homelab health, and the day's tasks into a push notification -- wanted a calendar section. Reading the calendar meant deciding where the calendar should live, which meant finally confronting the Google dependency.

The candidate I wanted to win was Proton Calendar. I already pay for Proton Mail, so it would have added no new vendor and no new service to run, and it is end-to-end encrypted at rest. On paper: the privacy-respecting choice, from the vendor privacy people recommend by reflex.

The investigation killed it in an afternoon. As of August 2026, checked against a paid Proton Mail subscription, Proton Calendar supports no CalDAV and no public API -- deliberately. The only sanctioned way for anything outside Proton's own apps to read your calendar is a read-only share link. This is exactly the kind of capability that changes; if you are reading this much later, verify it against Proton's own documentation before repeating it. Unofficial reverse-engineered bridges exist, but then you are running and trusting an unsupported bridge to reach your own appointments. This is not an oversight. A server that is architecturally blind to your events -- which is the entire point of end-to-end encryption -- cannot service a protocol that needs to read them server-side.

Now the other side of the ledger. Google Calendar exposes a full CalDAV interface. Point any standards-compliant client at it and walk away with your event data -- every event, every recurrence rule -- unilaterally, this afternoon. It also hands out a per-calendar secret iCal address that any consumer can poll. To be precise about what that buys: CalDAV carries the events, not the surrounding sharing and permission structure -- which, as we will get to, is where the real trouble lives anyway.

Which leaves the two vendors ranked in the opposite order from the one every privacy guide implies:

The advertising company is easier to leave than the privacy company. Google's export and sync of your event data runs over a standard protocol that any second implementation speaks. Proton's exit is a manual export and a read-only link.

Why the inversion is not a paradox

The reflex is to read this as hypocrisy on Proton's part. It isn't. It is a genuine engineering consequence: the privacy architecture is the lock-in. End-to-end encryption removes the server's ability to read your data, and CalDAV, sync APIs, and rich export surfaces all require exactly that ability.

CalDAV is not blob storage with a calendar icon. The protocol obliges the server to answer questions about the contents: give me the events that overlap Tuesday, expand this recurrence rule into dates, compute this person's availability for scheduling. Every one of those operations requires parsing event data server-side. A server holding only ciphertext can do exactly two things -- store blobs and hand them back whole -- which is why Proton can offer an export and a share link but not a sync protocol. Export is "hand back the blob"; CalDAV is "answer questions about what is inside it." You could, in principle, design a sync protocol where the clients do all the thinking and the server stays blind -- but it would not be CalDAV, no standard for it exists, and a protocol with no second implementation fails question one of the rubric below anyway.

Which yields the general lesson: respects your data and lets your data go are different virtues, and vendors are almost never sold on the second. They do not have to be correlated. A vendor can be excellent at one and poor at the other in either combination -- and the marketing around privacy actively obscures the difference, because "encrypted" and "yours" sound like synonyms and are not. Encrypted data you cannot programmatically retrieve is yours in roughly the sense that money in a vault with no door is yours.

I want to be fair to Proton here: for a threat model centred on the vendor reading your data, their architecture is the honest one and Google's is the compromised one. But sovereignty, as I have been using the word across this blog, is about control -- and control includes the ability to walk. On that axis, the ranking flips.

The option with a perfect exit

There is an obvious third candidate, and if you read this blog you have already thought of it: self-host the calendar. Radicale or Baikal on the Raspberry Pi, CalDAV over the mesh network, done. I evaluated it seriously -- it was the option that best fit everything else I run.

On the exit axis it is not merely better; it is the theoretical optimum. A self-hosted CalDAV server speaks the standard protocol by definition, and underneath the protocol your events are files on a disk you own. Leaving Radicale means copying a directory. There is no vendor to negotiate with because there is no vendor. If exit cost were the only axis, this post would be one paragraph long.

But exit cost is not the only axis, and self-hosting makes its payment on a different one: it is another service to run, back up, monitor, and sync to every phone that needs it -- an operational cost that recurs monthly whether or not the calendar earns it. That trade can absolutely be worth it; half my stack is exactly that trade, taken deliberately. For the calendar, it never added up -- and the reason has nothing to do with operations.

The dependency other people own

The calendar I actually live by is a shared household calendar. The other people on it did not sign up for my threat model. Whatever I think about Google, most of that calendar's value is that everyone on it edits it, from their own phones, with zero friction -- and no protocol on earth migrates other people's consent. Radicale could hold my personal events by tomorrow evening and achieve precisely nothing: a shared calendar stays where its participants are. The option with the perfect exit solves the half of the problem that was never the problem.

We talk about lock-in as if it were a technical property -- something a better API or an EU interoperability mandate could dissolve. Some of it is. But the deepest lock-in is social: the shared calendar, the family photo library, the group chat. Exit is a coordination problem wearing a file format as a disguise. Every self-hosting guide I have read prices the hardware and the sysadmin hours. I have yet to see one price the conversation where you ask your household to change how it plans the week.

What I did instead

Here is the part that separates this post from a vendor comparison. Having designed the Google-reading integration -- source decided, mechanism investigated down to the recurrence-expansion library, deployment script written -- I killed it at the gate. It never ran.

Not because reading Google would have made anything worse: the events were already there, and a read-only feed adds no new data to Google. I killed it because the investigation had quietly reframed the cost side. The integration needed a credential with no scoping and no expiry, recurrence handling that fails in silent ways, and one more running service on a stack whose value is that I understand every part of it -- all to display, each morning, a calendar whose contents I mostly already know. When I asked the only question that matters at a deployment gate -- would I miss it? -- the honest answer was no.

So the current state, stated plainly: my calendar is on Google, nothing I run reads it, and there is a written record of what would change that -- if the shared calendar ever moves, if a real need for two-way sync appears, if the dependency starts to bite. That last part matters more than it sounds. A dependency you have priced, documented, and given explicit exit triggers is a different object from a dependency by default. The first is a decision you can revisit. The second is just sediment.

The rubric I now run before adopting any service, in the order the failures taught me:

Does it speak a standard protocol, or a proprietary surface? CalDAV, IMAP, SFTP, plain files -- anything a second implementation exists for. A beautiful API that only the vendor's SDK speaks is a corridor, not a door.
Can you bulk-export in a format something else imports? Test it. An export button that produces a proprietary archive is compliance theatre.
Can you migrate unilaterally? Or does leaving require other people -- family, colleagues, the other half of a shared calendar -- to move with you? This is the question the other three hide behind, and it is the one that decided my case.
What does the vendor's own leaving-documentation look like? A company that documents your exit clearly is telling you something about how it expects to keep you. A company whose export docs are a support-forum thread is telling you something too.

Google Calendar passes the first two cleanly and fails the third completely. Proton fails the first two by architectural design -- for reasons that are defensible, but that its marketing does not volunteer. Self-hosting passes the first two by definition and makes the fourth irrelevant -- there is no vendor whose exit documentation could be graded -- and runs into exactly the same wall on the third, plus an operational bill the other two never send. Neither vendor result was the one I expected before I looked, which is rather the point of looking.

Can I actually leave?

Partially -- and I can now tell you exactly where the partial is, which I would argue is the real deliverable of this whole self-reliance project. I can leave my VPS provider in an afternoon; everything on it is declarative config and encrypted archives. I can leave my DNS, my password manager, my RSS reader without anyone else noticing. I cannot leave Google Calendar this year, because that calendar is shared -- and its other participants did not sign up for my threat model.

The evangelists will tell you to leave everything. I am telling you to price the exit before you need it -- because the day you need it is the worst possible day to discover which doors were painted on.