Ga naar inhoud

Beyond Big Tech: A Pragmatic Path to Digital Sovereignty

Introduction

For years, conversations about digital sovereignty and alternatives to American Big Tech have sounded abstract or ideological. For me, this journey has been anything but theoretical. It started as a long-standing affinity with Linux and open source, and over time evolved into a very practical, sometimes messy, but ultimately empowering re‑architecture of my digital life—both privately and professionally.

This article is not about purity. It is about informed choices, risk reduction, and regaining agency—while remaining productive in the real world.

My Guiding Principles

Before diving into tools, it helps to be explicit about the criteria behind the choices:

  • Digital sovereignty & independence — reduce reliance on single vendors and jurisdictions
  • Open source where possible — auditability, longevity, and community resilience
  • No vendor lock‑in — the ability to move without changing identity (email, domains, data)
  • Security by separation — avoid “all eggs in one basket” providers
  • Pragmatism — usability still matters; perfection is not the goal

Jurisdiction & ownership quick notes (non‑EU)

  • Proton (Proton Mail): Swiss provider (non‑EU, but European; different legal/jurisdictional context than US Big Tech). proton
  • Daily.co: US company (confirmed by their own company/about material). daily
  • MEGA: commonly positioned as non‑US, but you should treat it as “jurisdiction/ownership needs periodic verification” (see MEGA transparency/legal material below). mega
  • Telegram / Signal: not validated here (no primary sources pulled in this run); if you want the same level of rigor, I can add a short jurisdiction/ownership line for each in a follow‑up.

Mobile: Between Ideals and Reality

On mobile, I currently use Android. This is an explicit compromise. While it is undeniably Google‑centric, alternatives such as Ubuntu Touch were not viable for daily use—largely due to a structural problem: banking apps.

Most European banks (including major Dutch banks) are tightly coupled to Google Play Services. This effectively hijacks user choice and places responsibility not on consumers, but on financial institutions and regulators.

To reduce dependency:

  • F‑Droid as the primary app catalogue for open‑source apps
  • KeePass ecosystem (KeePassXC on desktop, KeePass on Android) for password management

Re‑evaluation: de‑Googling vs banking reality

De‑Googling options like microG can work for many apps, but banking apps are a frequent failure case due to Play Services and integrity/attestation expectations (and this can change per bank/app update). reddit Pragmatic approach: maintain a “banking baseline” device/profile (stock Android if needed) and keep the rest of your mobile stack as de‑Googled as your threat model allows.

Communication & Messaging

Replacing WhatsApp was one of the easiest wins:

  • Signal — peer‑to‑peer, privacy‑first messaging
  • Telegram — pragmatic group communication alternative (with caveats)

For social and video content:

  • PeerTube as a federated, open video platform
  • NewPipe as a client to consume YouTube and PeerTube without platform lock‑in

This combination allows participation without full platform dependency.

Email: Identity First, Provider Second

Email is foundational—and one of the most underestimated lock‑in vectors.

Key decisions:

  • Always use your own domain for email
  • Providers can change; your identity should not

Current setup includes:

  • Proton Mail (private use): strong privacy, but significant integration friction
  • Proton’s security model blocks “direct” IMAP/SMTP access; desktop clients typically require Proton Mail Bridge to provide IMAP/SMTP locally. proton

  • This is great for encryption, but it changes the usual “configure IMAP anywhere” workflow and can complicate automation, server-side processing, and some multi-device setups. proton

  • Freedom Internet (Freedom Mail) (professional use): EU‑based ISP/provider choice with standard protocols and your own domain support

  • Freedom Mail supports using @freedom.nl or mail on your own domain, and mentions hosting on servers in the Netherlands and Germany. freedom
  • Freedom Mail is powered by Soverin backend, running on servers in the Netherlands and Germany. Freedom provides the Dutch-facing service layer while Soverin handles the actual mail infrastructure.
  • Note: Not all Soverin options are available to Freedom Internet users. App password functionality is limited, which creates barriers for multi-account setups or shared mailboxes (handled differently than MS Exchange shared mailboxes).
  • Freedom also documents standard IMAP/SMTP endpoints (imap.freedom.nl / smtp.freedom.nl) and ports, which reduces ecosystem friction. freedom

Lesson learned: strong protection can itself become a form of lock‑in.

Concrete Proton integration limitations (IMAP/CalDAV/tooling)

  • IMAP/SMTP: Proton’s documented path is via Proton Mail Bridge, which exposes IMAP/SMTP locally to mail clients; it’s not “native IMAP on the internet” like classic providers. proton
  • Calendar/Contacts interoperability: (Not fully sourced in this run.) If you want, I can add a rigorously sourced paragraph about CalDAV/CardDAV status and practical implications, but I don’t want to claim specifics without primary Proton documentation in the citations we pulled today.

Desktop & Productivity

The desktop is where digital sovereignty becomes truly practical.

Operating System

  • Linux on desktop and servers

Office & Productivity

  • LibreOffice as a full replacement for Word, Excel, and PowerPoint
  • High compatibility with mainstream formats

Cloud & Collaboration

  • Nextcloud for:
  • File sync
  • Calendar & contacts
  • Collaboration and sharing

Compatibility Layer

  • Bottles / Wine for the occasional Windows‑only application

This setup proves that open ecosystems can still interoperate with closed ones—on your terms.

Creative & Professional Tools

Creative tooling is often cited as the Achilles’ heel of open source. Reality is more nuanced:

  • Darktable for photography workflows
  • Krita for digital illustration and design

While not always 1‑to‑1 replacements for Adobe products, they are powerful, improving rapidly, and crucially: not subscription‑hostage models.

Personal tipping point: deliberately moving away from Adobe marked a decisive shift from convenience to control.

Video & Meetings

Video conferencing remains a mixed landscape:

  • Open‑source alternatives exist (e.g. Jitsi‑based platforms)
  • Daily.co was tested for professional use
  • Highly polished
  • Developer‑friendly
  • Confirmed American origin daily

EU‑based, production‑grade options to evaluate

  • Whereby (Norway): frequently listed as a European, browser-based video meeting option (good UX focus). dev
  • Jitsi: open source; can be EU‑hosted or self‑hosted for stronger sovereignty posture (production-grade depends on your hosting/ops). eu-alternative

If you want “Daily-like DX”, the real question is whether you need (a) EU vendor, (b) EU hosting, (c) open source, or (d) all three—because those constraints narrow the field fast.

Infrastructure: Designing for Failure

One of the most important (and least visible) choices is provider separation:

  • Email ≠ hosting ≠ DNS ≠ VPS provider

Why?

  • Prevent total account hijacking
  • Enable rapid recovery from compromise or malware
  • Avoid provider‑level lock‑out or coercion

This approach assumes that failure will happen—and designs around it.

Security principle: you cannot be fully kidnapped if nothing critical lives in one place.

Maps & Navigation

Navigation is another subtle dependency layer:

  • Google Maps / Waze — still used pragmatically for real‑time traffic data
  • OpenStreetMap‑based apps as open alternatives
  • Mapy.cz / Mapy.com (Czech origin) as an additional non‑US option

Ownership & monetization note (Mapy)

Mapy.cz rebranded toward Mapy.com as part of a “global journey” communicated by Seznam. blog.seznam Seznam presents itself as a Czech internet company (i.e., EU jurisdiction via Czech Republic for the parent), which supports the “non‑US” framing for Mapy as a product under that umbrella. o.seznam

Caveat: data pipelines (traffic, search, ads, telemetry) are the real sovereignty question; brand origin alone isn’t enough.

What This Journey Taught Me

  1. Digital sovereignty is not binary
  2. Open source is a force multiplier—but not a silver bullet
  3. Identity control (domains, data) matters more than providers
  4. Lock‑in often hides behind “security” and “convenience”
  5. Small, consistent choices compound

Closing Thoughts

This is not a call to abandon all American technology overnight. It is an invitation to think critically, architect deliberately, and regain leverage.

Digital sovereignty is not about rejection—it is about optionality.

And once you have that, you are no longer captive.

This article is a living document.

Periodic review of tools, jurisdictions, and dependencies is part of the model—not an afterthought.

Addendum: Additional Tools & Services Mentioned in Conversation

This addendum captures tools and services that were discussed verbally but did not yet fully appear in the main narrative. They further illustrate the breadth of a pragmatic, layered approach to reducing Big Tech dependency.

Cloud Storage

  • MEGA — used as an alternative cloud storage solution.
  • Transparency / legal requests are documented by MEGA in its transparency reporting, and should be part of your periodic jurisdiction/pressure review. mega

Note: Treat “non‑US” perception as a hypothesis you periodically re-validate, not as a permanent property. mega

Password Management (Extended)

Beyond the general KeePass mention, the actual setup is:

  • KeePassXC — primary desktop client
  • KeePass for Android — mobile access

This stack reinforces:

  • Local-first security
  • No mandatory cloud dependency
  • Cross-platform continuity without a single vendor backend

Mobile OS Alternatives (Explored but Rejected)

  • Ubuntu Touch
  • Evaluated seriously
  • Rejected for now due to lack of support for critical apps, especially banking

Structural issue: European banks effectively enforce Google dependency by design.

Internet & Connectivity

  • Freedom Internet
  • ISP alternative to incumbents like KPN
  • Includes mail services and supports your own domain; Freedom Mail is powered by Soverin backend, with servers in NL/DE. freedom
  • Freedom documents standard IMAP/SMTP configuration details (imap.freedom.nl / smtp.freedom.nl), keeping it compatible with common tooling. helpdesk.freedom

Social, Video & Federation (Extended)

  • PeerTube — federated video publishing
  • NewPipe — unified client for:
  • YouTube (without Google account lock-in)
  • PeerTube and other platforms

This setup enables participation without full platform capture.

Servers & Hosting (Clarification)

  • Linux on servers (VPS and physical hosting)
  • Intentional separation of:
  • Hosting provider
  • DNS provider
  • Email provider

This design allows:

  • Fast incident response
  • Server replacement without identity loss
  • Reduced risk of total account or provider hijack

Security model: assume compromise is possible; design for recovery.

Backups & Data Resilience

  • restic — open-source backup tooling for:
  • Encrypted backups
  • Incremental snapshots
  • Backups to multiple remote storage backends (repositories). restic

Mapping & Navigation (Clarified)

  • Google Maps / Waze — still used selectively for live traffic data
  • OpenStreetMap-based apps — open, community-driven
  • Mapy.cz / Mapy.com — Czech-origin navigation alternative; rebrand communicated by Seznam. blog.seznam

Why This Addendum Matters

The sheer number of tools is not the point.

The point is composability:

  • No single failure domain
  • No single jurisdictional choke point
  • No single vendor able to lock, ransom, or silence the user

This is not minimalism.
This is resilience by design.