IP protection in xWise software

The engineering, in detail — what is access-controlled, what is checked on every request, and what we explicitly do not claim.

The introduction states what we protect. This page states how, and — more usefully — how you could check it yourself. Everything below is a mechanism, a measurement, or a limitation we are naming before you find it.

One rule, consulted in every place

There is a single function that decides what a person may see. The catalogue listing calls it. The audio request calls it. The chart file calls it. The chart timings call it.

That is a deliberate choice and it is the most important thing on this page, because the usual way access control fails is not a missing check — it is a second check that was written later and drifted from the first. A catalogue that hides a track while its audio stays fetchable is protection that looks applied and is not. So the single-item check does not restate the rules; it delegates to the same query the listing uses. They cannot disagree, because there is only one of them.

Licensed audio has no address you can type

A licensed file is not stored where the web server will serve it. The private area is marked internal in the web server's own configuration, which means it will refuse a request that arrives from outside — not a permissions failure, an outright refusal to route.

Reaching one goes through our application instead: the request arrives with a track id, we check who is asking, and only then do we hand the file back to the web server to deliver. The file is still served by the web server — so seeking, looping and playing from the middle of a track all work normally — but the decision was made in code first.

You can check both halves right now. A real private file at its storage path returns 404, because the path will not route. The same track through the checked route returns 403 when nobody is signed in. And a public file returns 200, and 206 with a range request — which is the part that matters, because a system that refuses everything looks identical to a working one until you prove the permitted case still serves.

The catalogue does not name your files

A private track's entry in the data feed does not carry a storage path at all. It carries an address built from the track's id, pointing at the checked route. As of today, zero entries in the public feed contain a private storage path — there is nothing to guess at, because nothing is published to guess from.

Access is granted by a verified email, not a typed one

When you give us a list of addresses, a person gets access when they sign in with an address they have proven they control — the one they confirmed by clicking a link in their mail.

This distinction is not pedantry. An account's email field is free text that anyone can type at signup. If access were granted on that, a stranger could enter a subscriber's address and inherit your catalogue. We match only against confirmed addresses.

Progressions: the chords are open, the names are not

A bare sequence of chords — a twelve-bar blues with a quick IV — is the common vocabulary of the music, and we do not claim ownership of it for anybody. That has not changed.

What changed is that we noticed the name can disclose what the chords cannot. A progression worked out for one recording is usually named after it, and "Raising Sand" sitting in a public menu tells the world what is inside a course somebody paid for. "145 Dominant Blues (quick IV)" tells them nothing.

So progressions now carry access control of their own, and it is decided by what refers to them rather than by anything about the music: a progression is listed publicly if something public uses it, and otherwise it is not.

The referrer rule, which is what keeps this safe when things change

Access control usually fails slowly. A setting is right on the day it is written and quietly wrong six months later, after a track was published or a person was added.

So a stored setting is treated as a floor, not an answer. Anything reachable through something you can already see, you can see. If you can open a track, you can read its chords — whatever the progression's own setting says. If you can open a track, you can open its chart — which is why a chart needs no separate setting at all; it inherits its track's.

The effect is that the stored values can go stale and nobody is ever stranded: you cannot end up holding a track whose chords have vanished. Measured today across three kinds of visitor — signed out, an instructor with access to their own material, and an administrator — the number of tracks referencing something the viewer could not see was zero in every case.

That property is checked, not assumed. The routine that set today's values refuses to run at all if it would leave a public track without its chords.

What the numbers are today

A signed-out visitor sees 36 tracks, 37 progressions, and no restricted rows at all.

How you could check this yourself

You do not have to take any of it on trust, and you do not need an account for most of it.

1. Load the public catalogue and count what is there. It is a plain data feed at /api/data/ on either app. If a restricted track of yours appears in it, that is a fault and we want to hear about it the same day.
2. Try a private file directly. Take a track only you should reach, and request its storage path. You should get nothing.
3. Then try a public one, and confirm it plays. This is the step people skip and it is the one that proves the mechanism is a gate rather than a wall.
4. Sign in and repeat. Your own material should appear, and it should play.
5. Ask us to show our working. We will run the checks with you against the live system rather than describing them.

What we do not claim

We cannot stop a person you have authorized from keeping a copy. This is worth stating precisely rather than softly: a browser can be opened to its developer tools and the audio file saved directly. Not re-recorded — the actual file. That is true of every streaming system on the web, ours included, and no amount of engineering changes it. What access control decides is who reaches that point at all, and that is a real and enforceable line: a person who is not authorized cannot get to the file to save it. Everything on this page is about that line. None of it is about what an authorized person does afterwards, and we would rather say so plainly than let the rest imply a protection nobody can offer.

We do not fingerprint or match audio. If two people upload the same recording, we do not detect it and do not link them. Access comes from a relationship you granted, never from a guess about content.

There is no export and no format conversion. The apps do not offer a download of your audio. A backing track can be written to a looper pedal connected to the machine, and that is the only path out.

Verifying a gate is not the same as proving there is no other door. This is worth stating because we learned it the hard way: it is possible for every access check to pass while a file sits somewhere it should not, put there by a process that never went through a check at all. We now audit what is actually present in the directories the web server can reach, not only what our code decides to serve. It is a different question and it needs asking separately.

A rule that has only ever applied to one person is not really a rule yet. Several of the mechanisms here were built while one person held every permission. We have since separated them — the ability to see your own material is a property of the material, not of being an administrator — but we mention it because it is the kind of thing worth asking about rather than assuming.

If something looks wrong

Use the Feedback button in any xWise app. It needs no account, so you can reach us before signing in.

If you believe material of yours is reachable by someone who should not reach it, say so and we will restrict it first and investigate second. Restricting takes minutes and is reversible; it is never a trade against convenience.

Next: Licence agreement