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

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…

The demise of my digital brain

A little while ago my QNAP TS-1079 Pro which has served me faithfully for nearly a decade as my main NAS, started complaining that it had lost the disk in bay 7. This would be the first time a disk in this unit died since I set it up, and it’s been running 24/7 without spindown for the whole time (I ran my vSphere virtual servers using it as shared storage). A tribute to the lovely HGST 4TBs, I suppose. No worries, since I fairly early on had swapped out one of the 10 disks for a SSD to use as a cache drive, I had a spare disk in a drawer. So I replaced the drive, and it rebuilt the raid to that drive and all seemed well. For about a day. Then I got the same error. Hmmm… well, the disk *had* been used for a while, then left in a drawer for 8 years or so. Some HDDs don’t like that. So I bought a 4TB WD Red, mounted it to the caddy and inserted it. Same error.

So I used the excellent Helpdesk app on the QNAP to open a support ticket, and after a bit back and forth the support tech said it was most likely a problem with the backplane – possibly the motherboard. I inquired about a replacement backplane, but while I didn’t get a clear answer, it seemed none were available to purchase. After a brief look at eBay, AliExpress, etc, I started accepting that the safest option with the least downtime was probably to replace it.

I had already started thinking about this, but of course, the timing wasn’t ideal. It never is, is it? However, since this is my main storage for everything in my digital life, I couldn’t risk running it in this degraded state for too long either. With RAID6 I could only afford to lose one more drive.

The requirements

My needs for my main NAS are quite simple, but unfortunately also quite diverse. On one side it needs to hold large volumes of data: Various backup sets from my client computers, backups of my VMs, some repositories of various rubbish, media files including my ripped Bluray and CD collection, and of course personal files, photos, etc.

On the other, it has to serve as shared storage for my running VMs in my home lab. This demands some IO performance, but it doesn’t make up a lot of data. maybe around 500GB currently.

For a while, I considered a separate unit for the high-performance stuff but I already have more than enough units spinning away in my computer room, generating both heat and noise.

Narrowing down the options

A long time ago I used to run my own fileservers with assorted types of software- or hardware raids, but after failures of different kinds and the headaches of trying to sort them out and recover data, I decided this was not what I wanted. At the time I also did enterprise storage at work and felt I had enough of dealing with storage there

When the first types of SOHO-style NASes as we know them today appeared, I figured this would be the perfect solution for me. A standardized, tested and verified hardware and software combination that is being run by hundreds or thousands of others and with a support organisation to lean on. Since then I’ve been through units from Infrant (later Netgear), Synology and QNAP and have generally been very happy with this approach.

So when looking to replace the TS-1079 Pro, it was natural to look at the offerings from Synology and QNAP.