Do not take
our word for it

Everywhere else on this site we make promises. Here is what enforces each one, and how to check it without trusting us.

Your master comes back byte for byte

Every file gets a fingerprint when it arrives. It is a SHA-256, a long number derived from the contents, and changing a single byte anywhere in the file changes it completely. We show it on every version and next to every file in your export. Check any download against it:

macOS      shasum -a 256 "your file.wav"
Linux      sha256sum "your file.wav"
Windows    Get-FileHash -Algorithm SHA256 "your file.wav"

Matching numbers mean the file on your disk is identical to the one you uploaded, down to the byte. We are not part of that comparison.

Check the file in storage on any version re-reads the object and rehashes it, so it answers whether the file is intact today. If it ever disagrees we record it, show you, and tell you.

Files uploaded before checksums existed have none yet. Those versions say so and offer to compute one.

And that it existed on the day we say

A checksum proves the file is intact. It does not prove when it existed, because the date beside it is ours, and you are entitled to point out that we could write any date we liked.

So every night we take the checksum of every master recorded that day, fold them into a single number called a Merkle root, and publish it. The roots are public and permanent, and the table they live in refuses to be edited or deleted:

https://api.eu.northwestfalls.com/api/proof/roots

To prove a file was in our records on a given day, you need three things: your file, the short list of sibling hashes we hand you, and that day's published root. Hash your file, combine it with each sibling in turn, and you arrive at the root. If it matches the published one, your file was there.

https://api.eu.northwestfalls.com/api/proof/checksum/<your-sha256>

We are not part of that check. The root was published before the dispute existed, the arithmetic is SHA-256, and anyone can run it. It works after you close your account, and it works if you no longer trust us at all, which is the only kind of proof worth the name.

A root is only published for days that have ended and that had at least one upload. Yours appears the night after your first master arrives.

Nothing can publish your unreleased music

Masters and streaming copies live in separate buckets. The server behind every northlink.cc page has no connection to the masters bucket, so a bug in it cannot serve one. The capability is absent, not guarded.

There is no browse page, feed or directory. A track is reachable only through a link you made, and those carry X-Robots-Tag: noindex and about sixty bits of randomness.

A deleted master survives fourteen days

People delete the wrong take and notice a week later. The window is not enforced by our code. It is a retention rule on the bucket:

$ wrangler r2 bucket lock list nw-masters

name:       masters-14d
enabled:    Yes
prefix:     (all prefixes)
condition:  after 14 days

Cloudflare refuses to delete anything in that bucket younger than fourteen days. If our code is wrong, if a deploy is broken, if somebody takes control of our systems and orders the deletion, the answer is still no. That includes us: inside the window we cannot destroy your work even if you ask.

You can leave without asking us

Settings, then Export everything. It works on the free tier, over quota, past due, and mid-cancellation.

You get your catalogue as JSON and as a spreadsheet, plus a script that downloads every master and checks each against its checksum. Links last twelve hours and there is a Revoke button, because an export file is working access to your masters.

This page previously described an export that did not exist. The promise was written before the button was.

No model is trained on your work

This one is a commitment, not a mechanism. It sits in the terms, where it binds us, rather than only in marketing copy.

What we can do is bound it. The licence you grant lists four things and training is not among them, and it ends when you delete the file. Every company we pay to help run this is named on the sub-processors page. If we are ever sold, those terms bind the buyer as a condition of the sale, with 30 days notice first.

If we are broken into, you hear it in three days

In plain words, whether or not the law requires it. The incident log was published before there was anything to put on it.

What is not proved here

• The checksum proves your file is intact. It does not prove nobody read it, and nothing we could show you would.
• A published root proves a file with that checksum was in our records that day. It does not prove you wrote it, and no timestamp anywhere can. What it does is put a date beyond our reach to change.
• The bucket split protects masters from the public server. The app server has to reach them to work.
• "We do not listen to your music" is a commitment. We check an uploaded file really is audio and nothing analyses the music itself, but you are taking our word for that.
• This describes how it works today. Anything that reduces your rights comes with 30 days notice by email first.