What Counts as “American” in a Global Internet?

After deciding to move away from US-based services, a problem becomes apparent: the internet doesn’t divide neatly along national lines.

Ownership, hosting, infrastructure, and governance rarely live in the same place. A service can look European, be American in ownership, and global in infrastructure, while still being subject to US law.

So before replacing anything, I needed a simple way to decide what actually matters to me.

What counts isn’t branding or geography. It’s control.

Who owns the company? Which laws apply? Where the data is hosted. How hard it is to leave?

That’s where risk comes from.

One distinction I think is too often ignored is the difference between hosted services and local software.

Hosted services store data on their own servers and operate under their own legal jurisdiction. Email providers, cloud platforms, SaaS tools, and social networks create direct jurisdictional exposure because your data lives inside someone else’s legal system.

Local software runs on your own devices and stores data locally, or only on services you explicitly choose. In those cases, the software provider doesn’t control the data; you do. Jurisdiction is defined by where you host, not who wrote the code.

That difference keeps the focus on where risk actually lives.

Risk Assessment Map

I’m not trying to achieve some sort of privacy nirvana. The goal here is risk reduction.

The point of laying down some rules around this is to be deliberate about how I identify what should be migrated. Convenience creeps back in, and decisions drift back to habit instead of intent.

A simple framework creates consistency. It turns unease into structure.

The goal isn’t isolation or ideological separation. It’s diversification, resilience, and control — avoiding single points of legal, political, and infrastructural failure.

In the next post, I’ll start the audit and try to map out my current digital services and identify which of these risks apply to them and see what I can do about it.

The why

This project didn’t start as a technical experiment. It started as a gradual loss of trust.

For too long, I tolerated the current realities of modern digital life, such as the idea that big platforms were unavoidable. I hoped that regulation would improve over time, and that privacy violations would eventually be constrained by oversight and law, and if not, that consumers would get fed up and move to alternative solutions. The problems were obvious, such as surveillance capitalism, data extraction, and platform monopolies, but they felt distant and abstract, more theoretical than personal.

That changed.

Not because of one scandal or one breach, but because of a pattern: repeated violations, symbolic fines, and no meaningful structural change. The same companies collect the data, control the infrastructure, shape the standards, and influence the regulations meant to constrain them. At some point, convenience stopped feeling neutral and started feeling like dependency.

It also became impossible to ignore the political layer.

American tech companies operate inside American law, American surveillance frameworks, and American political power structures. Oversight is weak. Enforcement is inconsistent. Lobbying power is massive. Privacy protections exist, but they are fragile and easily subordinated to national security and political priorities.

Recently, this stopped being abstract for me.

When the US president publicly dismisses democratic principles, mocks European countries, portrays them as adversaries, and frames allies as enemies, as he recently did during the World Economic Forum in Davos, that rhetoric becomes a risk factor when your data, identity, communication, and work are hosted inside that jurisdiction.

This is a structural problem; because data lives in legal systems, infrastructure, and jurisdiction.

Where your data lives determines which laws apply, who can access it, who can compel disclosure, what rights you actually have, and what recourse exists.

For Europeans, this has already been tested.

The Safe Harbour agreement failed.
The Privacy Shield agreement failed.

Both were political compromises that promised protection while leaving US surveillance law untouched.

The CLOUD Act made the reality explicit: US companies can be compelled to provide access to data regardless of where it is physically stored.

And the Schrems I and Schrems II rulings confirmed what many suspected — that high-level agreements between the EU and the US are not sufficient to protect European citizens’ data when the underlying legal systems are incompatible.

In other words, diplomatic agreements don’t override legal architecture.

It also isn’t abstract.

Over time, I’ve realised how much of my life is effectively hosted by a foreign jurisdiction.

My communication.
My identity.
My files.
My work.
My memories.

All dependent on companies I can’t vote for, governments I can’t influence, and legal systems where I have limited standing.

That’s not paranoia. It’s infrastructure.

Most large platforms are not neutral services. They are extraction systems. Data is the product. Behaviour is the product. Prediction is the product. Privacy violations aren’t accidents; they are business logic.

This series isn’t about purity or total disconnection. It’s not about digital isolation or ideological statements.

It’s about reducing structural risk, limiting jurisdictional exposure, breaking dependency, diversifying infrastructure, and regaining control.

Over the following posts, I’ll try to document the process of auditing my digital life, identifying jurisdictional risks, migrating services, replacing platforms, and accepting the trade-offs that come with that.

I’m not really writing this series as a guide for others, but mostly as a log for myself, and hopefully someone else can find it useful. If not, at least I have somewhere to point to when someone asks, “Why the heck are you putting yourself through all this hassle!?”

An honest record of what it actually takes to reclaim some digital autonomy and what it costs in convenience to do it, if you will.

Phew, let’s get on with it.

This blog series will document my attempt to migrate as much as practically possible of my digital life away from services owned by American companies or governed by US jurisdiction. It’s a record about trust, data safety, legal exposure, and long-term digital risk. I’m writing this as a practical, personal record of what it actually takes to reduce dependency on US tech infrastructure as a European citizen.

1. The Why
2. The Rules

A couple of years ago, I started buying a few photo books. I enjoy viewing the work of photographers of various genres and generations. After too long of mostly enjoying these works only on the web or at the (very rare) exhibition, I decided to get a few books. Photo books come in different types and forms, from those made by the photographer him- or herself, which have been carefully curated and laid out to present the work as the artist wants us to see it, to collections that put the artist’s work in the context of other artists. As well as many other types.

I enjoyed this experience so much that I started buying books quite frequently, eventually reaching one a month and, lately, even more. This leads to some challenges. Firstly, I’m running out of bookshelf space. I’m already considering remediating this, but that’s a more significant project. Secondly, how to keep track of the books you have, the books you want, the ones you lent out to friends, and where you left off each one. Photo books aren’t like novels; you might start on several in parallel and leave each for periods as your mood and focus change.

I accidentally stumbled across a personal library management program for desktops, which got me thinking this was something I wanted. But it was old-fashioned, clunky, and not very inspirational at all. I’m an old guy with old habits, so I tend to think of computing solutions from a desktop-first perspective, but in this case, I thought something with a mobile client might be more suitable. When I started looking into this, the options weren’t plentiful, but I found one that seemed to have the features I needed, and it was good-looking and effortless to use.

Handy Library is a well-designed Android app that’s really easy to use in terms of intuitive UI and effortless functionality. You can add a book simply by scanning its ISBN barcode or entering the ISBN number by hand. It will then try to look up information about the book online, on sites such as Goodreads, and then fill that in for you. It also provides really quick and easy ways of finding and adding book covers. You might need or want to correct or supplement that information (we all know that data quality on the internet isn’t always the best), but it’s usually pretty good off the bat, and it’s always a great starting point.

You can do various organisational actions, such as registering each book on which shelf it’s located, reading progress, whether it’s lent out and to whom, etc.

If you have a substantial library, going through and registering all your books is not a small task, despite the time-saving features of the app. That’s why it’s essential that the app also offers solid export options. Handy Library will let you export to XLS, CSV, or a zip file containing the SQLite database file. This means that even if the developer stops supporting the app, you move to an unsupported platform, or you find a different product that you like better, you can at the very least export the information you’ve added in a standard format and maybe even be able to import it into another program. You may even create your own projects using the data like I have. But more on that later.
With anything requiring a significant investment of your time, always ensure there’s a way to get that data out again.

One small caveat here is that the XLS export contains a bug. I believe it’s an unescaped / in the Lend/Borrow sheet that causes Excel and some other programs to see it as corrupt. The developer seems reluctant to fix this for some reason, but it can be fixed and worked around, so it’s not a dealbreaker.

To be able to share the contents of my library with others, I decided to use the export feature to import the data into an SQL Server database and then create a simple web page that lists the books, displays the covers, and includes a bit of the book description. Frontend web stuff is my kryptonite, so, for now, it’s mostly a proof of concept, but I hope to improve it to something half-decent in the not-too-distant future. But you can check out my online bookshelf already

If you’re interested, you can try it out for free, up to 100 books, and then upgrade if you want to keep using it beyond that. Also, you might need to pay a small fee for the Google API requests it uses to look up the covers. Always make sure you read the current conditions in the app or in Google Play.

After 26 years of being a customer without any major issues other than being overcharged, it’s odd that the end of my customer relationship comes with such a strong sense of relief and freedom.

I registered my first domain (this one) in 1997 and my second one only shortly after. At the time, there weren’t a lot of options around. Actually, the only option for most was the semi-official Internic. Since then, of course, there’s been many and different kinds of revisions to how domain name assignments have been handled. Internic itself was replaced, and the domain registration was contracted to Network Solutions, and later to a myriad of different registrars. Through all these changes, I decided to just stay with Network Solutions simply because I viewed it as trustworthy and reliable, while I heard lots of stories, including of losing their domains from friends. This was despite the fact that I knew I was increasingly paying a higher premium for this basic service.

An unwelcome gift

Fast forward to June 2022, and while I’m off travelling, Network Solutions sends me a mail. They’ve decided to give me a glorious gift. A domain loosely similar to my primary domain, using an obscure and presumably cheap TLD. Hidden far down in the message, they note that if I don’t want this domain that I didn’t request, I would have to let them know within 7 days. It was summer, I was travelling and only skimmed through my mail. This was around the time of renewal for my other domains, which I had already paid for, but they were still spamming me about, so I assumed it was related to these.

Shortly after, this new domain showed up in my account. I got annoyed. No, I got angry. A domain isn’t just any product; this isn’t like giving you a free tube of toothpaste on the way out of the store. A domain is something that comes with possible implications both in association if people look at which domains are registered to you, but more dangerously, a domain can land you in trademark and copyright disputes. So simply automatically attaching a domain to you with a shrouded opt-out possibility is dodgy. Heck, I’d say it’s pretty close to a scam. After all, the obvious motivation for this is to hope you don’t pay attention and automatically renew it once the first year has passed.

The escape

Any remaining trust in Network Solutions was immediately lost. I started looking for a better and cheaper registrar. That wasn’t hard, and I immediately proceeded to move my two domains to the new provider. As a bonus, I got access to a number of innovative and useful features. For free.

Next, I contacted Network Solutions to cancel my account, including the unwanted domain. Then things got really bad. And Network Solutions turned me from a customer who was annoyed and moved away but could possibly come back if the situation changed to someone that was so fed up and genuinely disgusted with them that I will never consider coming back. Or use them in any professional capacity where I have a say.

First of all, dealing with Network Solutions customer care is not easy. They really want you to call them on the phone (I’m not paying for transatlantic calls for support) but reluctantly offer a chat service with significant limitations. I get through on chat and tell them I want the domain deleted and my account closed.

The empire strikes back

They’re sorry, but they can’t delete a domain registered to me; I’ll have to let it expire. WTH… OK, at least remove my credit card info, so I don’t get charged with renewal by “accident”, then. They’re sorry, but they can’t remove the last method of payment from an account with an active product. Well, at least I get them to remove all sorts of renewal and automatic functions. Then I have to wait… for nearly a year…

As soon as the domain expires, I’m back with chat to have the domain deleted from my account. The chat agents don’t have permission for this, so they have to refer it to “admins”, and I need to send a confirmation reply to an e-mail. The mail reply-to is to the wrong address. I only notice by chance.

Finally, the domain is gone; I log in and can delete my credit card info. Then contact them again to have the account deleted. I don’t want unused accounts hanging around; they’re a security risk. No, they can’t do that. I have to call (on the phone, transatlantic) their customer loyalty team for this. I explain how this is unacceptable. Then they suddenly come up with a URL to a support site while stressing that this is ONLY to be used by non-US customers. I file a ticket.

Someone gets back to me and tells me they can’t delete the account. It will be deleted automatically after “a period of inactivity”. They can’t tell me what the period is. They can’t tell me if trying to log in to see if it has been deleted will count as activity and resetting the countdown to the unknown time.

And so I’ve decided to leave it there. But I’m so pissed off. It’s quite amazing how easily a company managed to turn me from an indifferent, overpaying, loyal customer for nearly 30 years to a very annoyed ex-customer with a strong feeling of having been exploited and attempted scammed.

Good riddance!

One of the first apps I set up on my Photon Docker host was Nextcloud. It’s an excellent solution for synchronizing and sharing files and comes as an official docker image. However, since I first set it up, I’ve been troubled that the clients start getting disconnected from the server after a short while (hours, a couple of days). The web UI works fine, but the clients on desktop and mobile show up grey with a 500 error.

Checking the logs on the container, I get something like this:

PHP Fatal error: Nesting level too deep - recursive dependency? in /var/www/html/lib/private/Log/ExceptionSerializer.php on line 215

Unfortunately, even after several new builds, this error seems to persist, so I guess I’ll record the workaround here, so I know how to reapply it if it’s overwritten in the future.

I’ll probably do this from within Portainer. If so, change the command to open the console to

/bin/bash -u 33

Then run this as a workaround in Circles:

./occ config:app:set circles route_to_circle --value ''

Then if needed, enable Circles again

./occ app:enable circles

This seems to have fixed the problem for me. At least it’s been working so far.

This is just a quick update to my setting up Photon OS as a docker host post. I use VS Code to both (try to) write code and edit configuration files, such as YAML files for Docker Compose. So to make configuring containers faster and easier, I’d like to be able to edit the files directly on the Photon VM using VS Code with the Remote Development pack on my desktop.

To do this, VS Code wants to deploy a small component on the destination server, and that doesn’t run entirely smoothly on Photon OS minimal out of the box due to its small footprint. So here’s what I need to adjust.

First, it needs tar to untar the addon, so

tdnf -y install tar

Next, the sshd demon needs to allow TCP forwarding, which it doesn’t out of the box.

sed -i "s/AllowTcpForwarding no/AllowTcpForwarding yes/g" /etc/ssh/sshd_config

Then restart the sshd, and we’re good to go!

systemctl restart sshd

And then VS Code is ready to connect straight to the Photon OS VM! If you remembered to install the extensions, obviously…

This is a follow-up to my post on setting up Photon OS on vSphere as a lightweight VM to run containers on. By the end of that post, I have the OS up and running with Docker Engine in place and enabled. This post will add simple, graphical container management to the host through Portainer.

You might ask, “Isn’t the point of containerized workloads, infrastructure as code, etc., that you can use the command line to manage your workloads?”. And you might be right. But right now, I’m not building dev environments; I’m bringing up relatively static components, prepackaged containers, that will deliver some sort of service in my network. And I won’t be deploying, destroying and redeploying these daily. And since my memory has always been terrible, and I have more than enough I need to remember from my actual work, I’d have to be looking up these things all the time. So sometimes, a friendly, intuitive GUI is just a better option. The nice thing here, of course, is that I can still do both, choosing whatever works best for me at any given time.

Portainer comes in two different flavours, the free Community Edition, and the commercial Business Edition. The Business Edition is available for free for fewer than 5 nodes; for now, I’m installing Community Edition, but I might look at the BE too eventually.

Because I want the host VM to be “disposable” so I can rebuild it and the contents for whatever reason, I needed somewhere to put the persistent data of the containers, including the Portainer management container. So I made an NFS share on my NAS called conda because it’s for container data, but I’m too lazy to type it out.

Since the minimal install of Photon OS that you get when deploying the OVA doesn’t include the nfs-utils package that I need to mount the share, the first step is to install that using tdnf:

tdnf install nfs-utils

With that done, I can make somewhere to mount the NFS share; mkdir/var/conda ought to do the trick. If my NAS has IP 198.51.0.10, this will accomplish what I want:

mount -t nfs 198.51.0.10:/conda /var/conda

Now we have somewhere persistent to store the configuration or user data of the containers, it’s time to deploy Portainer.

docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/conda/portainer_data:/data portainer/portainer-ce:latest

This will pull the latest community edition of Portainer, and store the config data in /portainer_data on my NAS share, mounted in /var/conda on the VM. Once done, it should be accessible on port 9443 on the IP I assigned to the Photon OS instance. Set a password, and you’re up and running:

From here, you can deploy and manage both single containers, and you can do Docker Compose installs using what Portainer calls stacks. I’m not going to do an in-depth discussion on Portainer features, mainly since I just started using it, but their Youtube channel is an excellent source of info. Once I have stuff to discuss, I might do another post.

I’d like to highlight the Stacks feature, which is basically a UI for Docker Compose, where you can type your YAML right in their web editor, upload it as a file, or connect to a repository.

No one will believe me, but I was pretty surprised to find that VMware’s Photon OS seemed to be the perfect fit. Of course, we have it as the base of many VMware appliances, and it’s also commonly used as the OS inside the containers deployed in Tanzu Kubernetes Grid, such as the supervisor nodes. That it also comes as a standalone OS with the Docker Engine in place and ready to go hadn’t registered with me before. And, of course, it’s already optimized to run on a hypervisor with as small a footprint as possible.

This is primarily for my own reference to know what I did when I need to redo this; here’s the process.

First, go to the download page and grab the latest version. Since I’m deploying this on ESXi, I’m getting the OVA with virtual HW version 13, which VMware describes as a “Pre-installed minimal environment, customized for VMware hypervisor environments. These customizations include a highly sanitized and optimized kernel to give improved boot and runtime performance for containers and Linux applications.”. There’s also an ISO installer and images for other hypervisors and clouds. Some of the stuff here is covered in the installation docs, but some of it is not. Surprisingly.

Deploy the OVA as you would any other OVF/OVA. There’s not much to decide on during the deployment, but I make sure to set the disk to thin-provisioned as I’m starting to run out of space on my SSD datastore.

Once deployed, it’s set up with 1 vCPU and 2GB RAM. The disk footprint with thin provisioning is an impressive 670MB. I increase this to 2 CPUs and 4GB RAM and fire it up. As instructed, you need to change the root password from “changeme” on the first login.

Welcome to Photon 4.0 (x86_64) - Kernel 5.10.83-6.ph4-esx (ttyl)
photon-machine login: root
Password :
You are required to change your password immediately (administrator enforced). 

The next step is to set a static IP address. Find the name of your Ethernet interface:

root@photon-machine [~]# networkctl
IDX LINK TYPE     OPERATIONAL SETUP
1   lo   loopback carrier     unmanaged
2   ethO ether    routable    configured
2 links 1isted.

Then create a network configuration file and fill out the info for the name of the Ethernet interface:

root@photon-machine [~]# cat > /etc/systemd/network/10-static-en.network << "EOF"

>[Match]
>Name=eth0

>
>[Network]
>Address=198.51.0.2/24
>Gateway=198.51.0.1
>EOF

Change the permissions of the file

chmod 644 10-static-en.network

And apply the new network config

systemctl restart systemd-networkd

While we’re at it, we might as well set the hostname to keep things nice and tidy and help identify resources on the network:

hostnamectl set-hostname MyComputerName

Check that your VM has the static IP. Now it’s time to get it up to date and secure. First, see which packages are available:

tdnf check-update

Or, if you’re curious about the relevant security advisories:

tdnf updateinfo info

Then run the upgrade command to apply the patches

tdnf upgrade

OK, so the OS is running, connected to the internet and up to date. Let’s get Docker up and running. I initialize the docker engine:

 systemctl start docker

And then make sure it’ll run on boot:

 systemctl enable docker

Let’s check out what the status is

docker version

Looks great! I could start to deploy containers right now. But let’s get some management functionality up and running to make things easier. I think that’s suitable for a separate post; read on here.

At work, I’ve been involved in projects over the last few years to deliver a private cloud experience to our users. One of the cornerstones in the latest endeavour has been to provide a solid container platform based on Kubernetes. This is quite a challenging adjustment for someone who has done primarily IT operations around traditional workloads, first physical servers and later virtual machines but still running conventional operating systems like Linux and Windows.

Kubernetes and software-defined infrastructure require a different approach to IT operations and blur lines between traditional roles. It requires developers to take greater responsibility for security and infrastructure elements and network, storage and server admins to better understand how code is built, delivered, and updated. While I’ve written some basic web applications through the years, I certainly don’t consider myself a developer, and I’m struggling to fully grasp some of the concepts and ideas.

I’m a practical guy; I need to try stuff, really use it, to fully understand something genuinely new and different. So, therefore, I decided to bring containers into my home lab and bring up a Kubernetes environment that I can test stuff on.

Running a bunch of QNAP NASes at home, the easiest and quickest way to start tinkering with containers was to deploy them using the included Container Station, which offers the Docker engine underneath. The first application I brought up here was a Crashplan cloud backup application. The person who had been building QNAP native packages of Crashplan was retiring the project, and to back up the NAS content directly, the docker image was the best-supported option. This has been running for at least a year and works very well.

Since then, I’ve added two more docker containers to Containers Station on my primary NAS. But running all sorts of containers is not what I want to use the NAS for, so I’m looking for a more suitable platform even though it’s a reasonably well-specced unit with 4 cores and 32GB RAM.

So instead of the next natural step, which would be to get something to run Docker on, I took a leap and started looking for a way to run Kubernetes. Since we’re using Tanzu Kubernetes Grid on top of a vSphere platform at work, I tried to find something similar, but without all the requirements of TKGs, which would massively complicate my little lab. After a lot of tinkering, I managed to bring up a management cluster using Tanzu Community Edition. Then I realized I really needed some infrastructure components up before proceeding with a workload cluster, so I had to return to planning for a Docker environment after all.

Which probably qualifies for its own post…