Hvelvet
Funn tribunalet har dømt for skarpe til å publiseres ennå. Hashene er offentlige. Innholdet er kryptert.
Etter sektor
Tribunalet forsegler funn som er systemisk viktige, men der bevisgrunnlaget ennå ikke bærer publisering. Det forseglede innholdet lagres kryptert og privat — det offentlige er beviset for at funnet fantes, i en gitt form, på et gitt tidspunkt. Forseglede funn identifiserer aldri privatpersoner.
Forseglingene
Tittel, sektor, hash og ankerreferanser er offentlige for hvert forseglet funn — tittelen står på funnets egen side, resten i oppføringen under: SHA-256-hashen av det kanoniske artefaktet, sektor, tidspunkt og ankerreferansene. Selve artefaktets innhold — analysen, kildene, prediksjonene — er kryptert og publiseres først ved opplåsing.
SHA-256 av det kanoniske artefaktet
e7655f809b8463a607edc685931eddf6d320a90ccd5e01cd38b04f07f1d3af1f
Ankerforpliktelse: 9f61b3e02b4161d666dbb48a86e6afc7003bb3bd
OpenTimestamps-bevis: vault/87e67e86-65d9-4bca-b973-5e70ef970a04.txt.ots
SHA-256 av det kanoniske artefaktet
0aeb8109b7a13c93e48cf051e4a913a5642eb00734e33529a418680168010858
Ankerforpliktelse: 5cf41cea3a9879a8dc78f0c1574a6cb9841cbef9
OpenTimestamps-bevis: vault/e50eede1-6801-48ae-8fde-ec9b51a514a7.txt.ots
Avforseglinger
En avforsegling er en ny publiseringsbeslutning, ikke en mekanisk utløser: tribunalet prøver artefaktet på nytt mot dagens fakta. Bekreftelse og avkreftelse publiseres begge — med samme synlighet.
Ingen forseglinger er åpnet ennå. Den første avforseglingen — enten den bekrefter eller avkrefter det forseglede funnet — publiseres her, med lenke til hele artefaktet.
Etterprøv selv
Alt du trenger er en terminal med node og git. Instruksene under er de samme som er publisert i det offentlige ankerarkivet — et forseglet funn kan først etterprøves fullt ut når det avforsegles eller publiseres, for det er da det kanoniske artefaktet blir offentlig. Fram til da kan du kontrollere at hash, ankerforpliktelse og tidsstempel allerede står fast.
Publiserte og avforseglede funn serveres som kanonisk JSON fra API-et. Feltet canonical i svaret er selve artefaktet som ble hashet.
curl -s https://www.folkefakta.no/api/findings/FUNN-ID -o svar.jsonHashen tas over en kanonisk serialisering, ikke over rå JSON. Protokollregelen, ordrett fra protokollfilen (scripts/institution/lib/canonical.js): "JSON with object keys sorted by UTF-16 code-unit order, arrays in given order, no whitespace, hashed as SHA-256 over UTF-8 bytes." Altså: objektnøkler sortert i UTF-16-kodeenhetsrekkefølge (vanlig JavaScript-sortering), arrayer i sin opprinnelige rekkefølge, ingen mellomrom — rekursivt gjennom hele objektet. Lagre snutten under som kanonisk.js og kjør den eksakte kommandoen:
// node kanonisk.js < svar.json | shasum -a 256
function kanonisk(v) {
if (v === null || typeof v !== 'object') return JSON.stringify(v);
if (Array.isArray(v)) return '[' + v.map(kanonisk).join(',') + ']';
return '{' + Object.keys(v).sort().map(function (k) {
return JSON.stringify(k) + ':' + kanonisk(v[k]);
}).join(',') + '}';
}
var raw = '';
process.stdin.on('data', function (c) { raw += c; });
process.stdin.on('end', function () {
var svar = JSON.parse(raw);
process.stdout.write(kanonisk(svar.canonical || svar));
});node kanonisk.js < svar.json | shasum -a 256 skriver ut heksadesimalhashen. Snutten gjør det samme som verify.js i ankerarkivets README — den skriver den kanoniske serialiseringen til stdout, og shasum -a 256 hasher UTF-8-bytene.
Resultatet skal være tegn for tegn likt sha256-verdien på denne siden — og sha256-linjen i filen vault/FUNN-ID.txt i ankerarkivet. Stemmer det ikke, er innholdet endret etter forseglingen. Det er hele poenget med hvelvet: et avvik er et bevis, ikke en bortforklaring.
Hashene skrives ved forsegling til et offentlig append-only ankerarkiv — bare hasher og journalrøtter, ingen kode, intet innhold. Klon det og se når posten faktisk ble skrevet til historikken. Commit-datoen er depoteierens påstand om tidspunkt; neste steg viser hvorfor du ikke må stole blindt på den.
git clone https://github.com/monscorps/folkefakta-anker
cd folkefakta-anker
git log --follow -- vault/FUNN-ID.txtAnkerforpliktelsen som er oppgitt for hver forsegling ovenfor, skal finnes i denne historikken og inneholde nettopp den filen.
Dette er beviset som er uavhengig av depoteieren: en .ots-fil forankrer postfilen til Bitcoin-blokkjeden. To måter å sjekke den på — dra postfilen og .ots-nabofilen inn på opentimestamps.org, eller bruk kommandolinjen:
ots verify vault/FUNN-ID.txt.otsFerske .ots-bevis kan i en periode vise "pending" — beviset er sendt til en kalendertjeneste, men ennå ikke bekreftet i en Bitcoin-blokk. Det gjelder blant annet det nyeste beviset i arkivet i dag. Det blir gyldig og verifiserbart automatisk når blokken kommer, uten at noen i Folkefakta gjør noe. Fram til da er tidsstempelet for den posten sporbart i git-historikken, men ikke uavhengig bevist.
Git-historikk under depoteierens kontroll er i prinsippet forfalskbar av depoteieren: den som har skriverettigheter, kan i teorien slette og skrive om historikken. Det er derfor OpenTimestamps-bevisene finnes — de forankrer en post til Bitcoin-blokkjeden på et tidspunkt hvem som helst kan etterprøve uavhengig, uten å stole på GitHub eller på Folkefakta.
Den operative databasen bak Folkefakta er mutable: rader kan endres, rettes og slettes — blant annet fordi persondata skal kunne slettes på ekte. Ankerarkivet beviser derfor ikke at databasen til enhver tid er "riktig". Det beviser om historikken har endret seg siden forrige ankring. En hash som ikke lenger stemmer, er bevis for at noe er endret — ikke bevis for hva som opprinnelig var sant.
Ankerforpliktelsene er per i dag usignerte (nøkkelen som er publisert i allowed_signers er passordbeskyttet, og den ubemannede ankringsjobben verken har eller skal ha passordet). Sjekk git log --show-signature på en aktuell commit for å se om signering er aktiv akkurat nå — og les datostemplene deretter.
Hele tillitsmodellen og de nøyaktige postformatene står i ankerarkivets README — samme instruks som på denne siden.