How a promise gets checked

Claims are cheap to write and expensive to verify. What separates one method from another is what you can open, run or read without taking a word on trust.

Evidence comes in grades, and they are easy to tell apart once named. The four below run from what anyone can type to what nobody can break quietly.

The grade decides who the evidence is useful to. A check that fails the build protects the reader who will never open a file.

• A sentence

  Written by the seller, checked by nobody, changed without notice.

• Open source

  Readable by anyone willing to read it, which is few people.

• A reading you repeat

  A page that reports what your own browser answers on your machine.

• A check that fails the build

  Behaviour drifts and the build turns red before it can reach you.

An empty cell means the line does not exist for that method, not that the method is bad. A tool that promised nothing owes no proof.

The fourth column is the one people read last, and it decides the most: a promise nobody can watch break is a promise that quietly stops being true.

Three of the four below need nothing installed and no account.

None of them sends your readings anywhere. The check on this site reads values in your browser and leaves them there.

• The fingerprint check

  12 values read in your browser, with nothing sent anywhere.

• The leak check

  What escapes around a proxy, read on your own connection.

• The self test in the app

  29 readings taken inside a profile, with no call outside the page.

• The promise registry

  One row per claim: what is promised, where it is in the app and how it is checked.

Passed or failed looks like the whole story, and it is not. A third state exists for the case where nothing failed and the decisive comparison was skipped.

That state leaves with the same non zero code as a failure. Acceptance that calls a build proven without measuring the thing it claims is worth nothing.

• Passed

  Everything ran, and two profiles were compared against each other.

• Failed

  Something ran and came back wrong.

• Not proven

  Nothing failed, and the comparison that proves the patches are alive was skipped.

The engine ships with a list of what it can do, and the app switches its launch arguments by that list. Declaring a capability the build lacks is worse than declaring none, because those fields then answer with the host machine's values.

So the list is taken off the source tree rather than copied from code. One file is read per capability and one marker looked for, and a capability without its marker never reaches the list.