The small print¶

Before the move, the terms of several US services had been accepted by clicking, and nobody had looked up which law governed them or where an appeal would go. This is the layer where the graph acquires lawyers, terms of service, compliance teams and the occasional button labelled “appeal”. It is less technical than the layers before it, and it is where technical independence becomes conditional. A server can be in Milan, the company European, the domain .eu, and the ability to keep the server, pay for it, resolve its name, maintain its certificates and recover the account can still depend on contracts, jurisdictions, subprocessors and policies elsewhere. The scraps for this layer say that whether a thing is European is the wrong question. Who has the legal or contractual power to say no, under which rules, and what happens afterwards, is the right one.

The sentence to find¶

Every provider has rules for what the account can do and what the provider can do to the account. Enough of each one’s terms got read to establish:

• the contracting party, and where it is incorporated

• which law governs, and where disputes go

• what triggers suspension or termination, and what happens to data afterwards

• how much notice is given, and whether the provider can change the service or the terms

• how the provider complies with external legal demands

• whether an account can be suspended before an investigation

The sentence to find is rarely the one saying the service is available in Europe. It is the one explaining what happens when somebody decides that it is not.

Where the contract lives¶

A provider can run infrastructure in one country while the contract belongs to another. For each provider the scrap holds the contracting entity, its country of incorporation, the governing law, the dispute jurisdiction, the operational location and the data location, and they are different things. A European datacentre does not make the service subject only to European law, and a company with international operations is not subject to every jurisdiction it touches. Law enters through provider domicile, customer domicile, where the service runs, where data is processed, the contract, the courts, sanctions regimes, export controls, financial regulation, sector rules, and orders directed at the provider or its suppliers. Nobody has to become a travelling lawyer. Finding where a provider has a legal obligation that can override the technical arrangement is enough.

“Hosted in Europe” says little about the chain. A provider uses other companies for cloud, storage, backups, email, payments, fraud detection, support, monitoring, analytics, identity verification, security and certificates, and those belong in the graph. For each provider the scrap holds the external suppliers it names, what they receive, where each sits, the terms and DPA governing it, and how the data and the service can be moved. A long subprocessor list is not a problem. An invisible one is.

“I pay a European company” does not describe the payment path either. The provider may use a European bank, SEPA, Visa or Mastercard, a US processor, a foreign fraud service, a foreign acquiring bank or a correspondent bank. For each provider the chain got written down from provider to billing entity to processor to rail to bank or card network to applicable jurisdiction, and the hosting subscription turned out to run through an Irish subsidiary of a US processor on a payment labelled SEPA. SEPA removes some intermediaries for ordinary European payments. It does not turn the financial system into a Luxembourgian monastery.

The DPA¶

The contract itself is a dependency: governing law, competent courts, arbitration, termination and suspension rights, notice periods, liability limits, and the provisions for data return, deletion and portability. A disposable static host and a deeply integrated identity provider have very different contractual profiles. Where personal data is involved, the DPA sits beside the service and not in a folder called legal: controller and processor roles, processing location, subprocessors, international transfers, retention, deletion, security obligations, breach notification, data return. What the agreement has to answer is what happens to the data, and to the legal basis for processing it, if the provider disappears, changes jurisdiction or changes its subprocessors.

Sanctions¶

Here the concern behind the whole section becomes operational. A service can be technically and commercially available today with conditions attached to tomorrow. Sanctions lead to a provider compliance decision, an account restriction, a payment restriction, a suspension, and the loss of infrastructure. An export restriction makes software or a service unavailable and takes a build or an administration capability with it. The dependency need not be direct: a provider can be perfectly willing to serve a customer while another provider in its chain is not permitted to. Ownership, jurisdiction, infrastructure and legal exposure are separate lines in the scraps for that reason.

The button labelled appeal¶

Providers have machinery for deciding that something is suspicious, prohibited or legally awkward: automated abuse detection, fraud scoring, sanctions screening, copyright complaints, security investigations, acceptable-use enforcement, identity verification, manual review, automated suspension. Every provider has such processes; what happens when one catches the account is the part to know. For each provider the scrap holds the trigger, the notification method, the immediate effect, the evidence requested, the deadline, the appeal channel, the escalation path, the consequences for data access, and the recovery path. Then the failure path got drawn: account, suspension, notification, evidence, appeal, restoration, and what happens if the appeal fails. Can the domain still be managed, the repository cloned, the files deployed, the mailbox reached, the provider paid, and the account recovered without another suspended account? This is where the authentication graph joins the legal one.

An appeal process is a dependency of its own. Where appeals go, which identity is required, which address receives the reply, whether another account can submit it, whether support works without logging in, what evidence may be asked for, how long it takes, and what happens to the data meanwhile. The nasty arrangement: the account is suspended, the appeal requires a login, the login requires a second factor, the second factor requires the suspended account’s device, and the recovery email is hosted by another suspended service. Technically everything still exists. Practically it is a decorative collection of locked doors.

The graph¶

The contracting parties are what the providers’ own pages say they are:

Three Swiss contracts, one Swedish, one German, and under two of them a German datacentre company that none of them owns. The layer exists for that last column.

The legal layer connects to almost every other. The domain reaches the registrar, and through it a contract, a jurisdiction, a payment route and a recovery identity. Email reaches the provider, and through it a DPA, subprocessors, payment and a suspension process. CodeFloe reaches its hosting provider, the webhook, the repository, a contract, a jurisdiction and a compliance process. statichost reaches its infrastructure, the datacentre, the upstream network, subprocessors, payment and jurisdiction. And then the uncomfortable arrows:

• provider, subprocessor, foreign jurisdiction

• payment, card network or processor, foreign jurisdiction

• contract, governing law, court system

• service, compliance policy, suspension

• suspension, recovery identity, another provider

The graph cannot stop at “where is the server”. The server is one node.

Signed¶

For each provider the contracting entity, jurisdiction, governing law, subprocessors and payment route are known, the DPA is saved, the suspension and appeal procedures are known, the recovery identity is independent, the important data is exportable, a replacement provider is identifiable, and no single provider controls every recovery path. Not every non-European dependency has to go. Removing them all would turn a one-woman company into a procurement department with a severe personality problem. What has to be known is which dependencies are structural, which incidental, which contractual, and which have a practical way out.

What could go wrong? For each provider the question was: if a US designation, sanctions decision, export restriction or related compliance action affected this provider, its owner, its payment route or one of its critical suppliers, what exactly would stop working.

• A provider designated, the account frozen, deployment stops.

• A processor restricted, the renewal fails, the domain or hosting expires.

• A subprocessor restricted, the provider loses a capability, the service degrades.

• A compliance decision, the account suspended, the appeal on the same identity chain, recovery blocked.

The result is not a declaration of independence. It is a list of actual failure paths and their alternatives. One provider suspended the account today, with no explanation, what now? Can the contracting entity and the governing law be identified, the suspension and appeal procedure found, support reached without the suspended account, the important data recovered, the other services paid, the service moved, the domain and DNS kept working, the site rebuilt and redeployed, and the identity that administers everything recovered? If yes, the provider is a dependency. If no, it is a dependency with a trapdoor. The server can be in Milan. What decides it is who owns the keys to the door, who wrote the rules on it, who can change them, and whether there is another door.

The witches of Lancre answer to nobody, and the King of Lancre has decided to regard that as a form of loyalty.