C-NDAPROTOCOL
Inizia ora

Fiducia e sicurezza

Che cosa protegge la tua prova, e che cosa non dichiariamo

C-NDA esiste per produrre una prova che regga senza che nessuno debba crederci sulla parola. Lo stesso metro vale per questa pagina: qui sotto ci sono le misure che stanno nel codice, i luoghi in cui i dati vivono davvero e, dette in chiaro, le certificazioni che non abbiamo.

Dove vivono i dati
Unione Europea — Francoforte
Accesso al database
Row-level security su ogni tabella
La prova
Ricalcolabile da chiunque, senza il nostro software
Certificazioni
Nessuna. Non ne abbiamo, e non ne mostriamo.

Dove vivono i tuoi dati

Niente sta «nel cloud» come astrazione. Ogni categoria di dati ha un luogo, e un luogo è una giurisdizione.

Database, accesso e documenti

Supabase, Unione Europea, regione Francoforte. La regione non è un'impostazione che qualcuno può cambiare: è scritta nelle regole del progetto come non spostabile, perché spostarla sposterebbe il terreno giuridico sotto ogni record.

Registrazioni e fotogrammi di una sessione

Cloudflare R2, in un bucket creato con giurisdizione UE. Su R2 la giurisdizione si sceglie alla creazione del bucket e non si cambia più — non c'è un'impostazione da correggere dopo, c'è solo un bucket da rifare — perciò la nostra configurazione controlla l'endpoint che riceve e si rifiuta di tacere quando non è quello europeo.

Il portale e il testimone

Il portale gira su Vercel. Il testimone che entra in riunione e registra gira in un container ospitato da Railway, ad Amsterdam.

Le segnalazioni di errore

Sentry, regione UE. Intestazioni di autorizzazione, cookie, corpi delle richieste, link di riunione e codici usa-e-getta sono rimossi prima che qualcosa esca dal processo, e non registriamo la sessione di navigazione di nessuno.

I dati della carta

Da noi, mai. Il pagamento e la gestione dell'abbonamento avvengono sulle pagine di Stripe; il numero di una carta non entra nei nostri sistemi.

L'elenco completo dei responsabili del trattamento, con ciò che ciascuno riceve e perché, è nell'Informativa privacy. Leggi l'Informativa privacy

Come sono protetti

Tre domande decidono la sicurezza di un sistema come questo: chi può leggere che cosa, come sappiamo chi sei, e che cosa succede alle cose che attraversano la rete.

Chi può leggere che cosa

  • La row-level security è attiva su ogni tabella. Dove una tabella è raggiungibile da un browser, le sue regole guardano il proprietario: la query di un altro account non restituisce una versione filtrata dei tuoi dati, non restituisce niente.
  • La tabella dei partecipanti non ha alcuna regola lato client — non una restrittiva: nessuna. I token d'invito e le impronte dei codici usa-e-getta si raggiungono solo attraverso endpoint del server, e perfino il titolare di una protocollazione, interrogandola dal browser, ottiene zero righe.
  • Sulla tabella dei profili i permessi sono per colonna: un browser non può scrivere il proprio piano, il proprio identificativo di fatturazione o la propria scadenza, nemmeno con una sessione perfettamente valida.
  • I file — certificati, NDA caricati, registrazioni, loghi — vivono in bucket privati. Nessuno di essi è mai un URL pubblico: ogni scaricamento è un link firmato di vita breve, emesso dal server dopo aver verificato chi lo chiede.

Come sappiamo chi sei

  • Un link d'invito porta un segreto di 32 byte. Noi ne conserviamo solo l'impronta, funziona una volta sola e scade dopo sette giorni.
  • Il codice usa-e-getta inviato per email è salato per invito, conservato come impronta, confrontato a tempo costante, scade in dieci minuti e si blocca dopo tre tentativi sbagliati. Quel blocco non dipende da alcun limite di frequenza: per questo regge anche nella giornata storta del limitatore.
  • L'autenticazione a due fattori è imposta nel middleware, non nell'interfaccia. La sola password apre una sessione ma non la dashboard, e reimpostare la password non è una scorciatoia per aggirare il secondo fattore.

Che cosa attraversa la rete

  • Ogni evento che il testimone manda al portale è firmato HMAC-SHA256 sul corpo grezzo, rifiutato fuori da una finestra di cinque minuti ed elaborato esattamente una volta — un evento rigiocato non cambia niente.
  • Gli eventi di fatturazione sono verificati con la firma di Stripe, conservati grezzi prima che qualcuno li interpreti, e sono idempotenti sull'identificativo dell'evento.
  • Gli endpoint pubblici che si possono martellare — inviti, codici usa-e-getta, verifica pubblica — hanno limiti di frequenza tenuti nel database e non in memoria, perché sul serverless due richieste consecutive possono non essere la stessa macchina e un contatore in memoria sarebbe un limite solo di nome.
  • Ciò che arriva al tuo browser dopo un errore è un codice di dominio. Il messaggio del database, quello dello storage e quello del fornitore restano nei log, dove sono utili e innocui.
  • Le risposte portano una content security policy che vieta del tutto l'inquadramento in un frame, più nosniff, una referrer policy stretta, una permissions policy e HSTS — e il server non annuncia con che cosa è costruito.

Il link che non esiste

È l'invariante attorno a cui è costruito tutto il prodotto, ed è una proprietà di sicurezza prima ancora che giuridica.

  1. 01

    In una sessione certificata il link della riunione è cifrato at-rest nel database.

  2. 02

    Finché un partecipante non si è identificato e non ha accettato l'NDA, quel link non gli è nascosto, non è oscurato, non è in grigio: non gli viene mai inviato. È assente dai payload delle API, dall'HTML, dagli eventi realtime, dai log e dai messaggi d'errore. Nessuna ispezione della pagina rivela ciò che non è mai stato trasmesso.

  3. 03

    L'unica risposta che lo restituisce è quella che registra l'accettazione — e solo finché la sessione è aperta. A sessione chiusa, scaduta o certificata, anche chi aveva accettato non riceve nulla.

Un test browser apre la pagina d'invito e verifica che il link sia assente dal documento. Non è un commento nel codice: è un lucchetto, e fa diventare rossa la suite.

L'integrità della prova

Un certificato vale esattamente quanto è difficile cambiare, dopo, ciò che certifica.

  1. 01

    La forma canonica

    Il pacchetto probatorio viene serializzato in forma canonica RFC 8785. Canonico vuol dire deterministico: lo stesso contenuto produce gli stessi byte, nello stesso ordine, su qualunque macchina, finché lo standard esiste. Senza, «ricalcola l'impronta» sarebbe un invito e non una procedura.

  2. 02

    L'impronta

    Lo SHA-256 di quei byte esatti è l'impronta del pacchetto. Cambia un carattere in un punto qualsiasi e l'impronta diventa irriconoscibile.

  3. 03

    L'ancoraggio

    L'impronta viene scritta su Polygon PoS con una transazione pubblica. Da quel momento il record è fuori dalla nostra portata: non possiamo spostarlo, correggerlo o ritirarlo, e nemmeno può farlo nessun altro.

  4. 04

    L'ordine, che non cambia mai

    Identificazione, accettazione, sessione, impronta, ancoraggio. Nessun passo si salta, si riordina o si esegue in parallelo col successivo — non per rendere più veloce una schermata, non in collaudo.

Immutabile, con revisioni invece di correzioni

Dopo l'ancoraggio il pacchetto non si modifica. Una correzione emette un nuovo certificato che si dichiara revisione del precedente, e restano entrambi. Non ci sono modifiche silenziose: per costruzione, non per regolamento.

I vuoti si dichiarano, non si nascondono

Dove il testimone non ha potuto coprire qualcosa — un'interruzione della registrazione, un partecipante che non ha potuto identificare — il certificato lo scrive. Un vuoto dichiarato è ancora prova; un vuoto nascosto renderebbe inutile l'intero documento.

Sulla catena non arriva nulla di non ricalcolabile

Esiste un controllo permanente che ricostruisce dal database il pacchetto di ogni certificato e ne ricalcola l'impronta, usando le stesse funzioni che l'hanno prodotto. È il cancello che deve passare prima dell'ancoraggio, e fa fallire l'esecuzione invece di stampare un avviso: ciò che non si riproduce non viene ancorato, si riemette come revisione.

Controllaci da solo, con strumenti che hai già

Tutto quello che c'è sopra è il racconto che noi facciamo del nostro sistema. Questa è la sezione in cui smetti di doverne credere una parola.

01

Ricalcola l'impronta

L'archivio probatorio contiene evidence.json già in forma canonica, quindi un semplice SHA-256 di quel file È l'impronta del pacchetto. Confrontala con l'impronta stampata sul certificato: o coincidono, o la prova non è quella che è stata certificata.

02

Leggi l'ancoraggio sulla catena

Apri la transazione di ancoraggio su un block explorer pubblico e guarda l'evento Anchored. L'impronta contenuta lì dentro deve essere quella che hai appena calcolato. In questo passo non entra niente di nostro.

Primo passo, sulla tua macchina

shasum -a 256 evidence.json

Il contratto di ancoraggio — Polygon PoS, chain 137

0x5CceC6F5806b7C949eB90D61fB9D13Cb639AC203

Sorgente verificato su Polygonscan. Emette Anchored(hash, timestamp, sender) per una transazione dedicata e BatchAnchored(merkleRoot, …) per un batch giornaliero.

Apri il contratto su Polygonscan

Sul verificatore di riferimento

Manteniamo anche un verificatore a riga di comando che automatizza entrambi i passi, prove Merkle dei certificati in batch comprese. È sotto licenza MIT, e non è ancora pubblicato su alcun registro pubblico — quindi oggi non hai modo di procurartelo, e la procedura di questa pagina, deliberatamente, non usa niente di nostro. Quando il verificatore sarà pubblicato questa pagina dirà dove prenderlo, non un giorno prima.

La verificabilità non costa riservatezza

La verifica pubblica legge una vista dedicata del database che non porta nomi, né titoli, né indirizzi. Un terzo può confermare che un pacchetto esiste e che la sua impronta coincide, e non apprende nulla su chi ha firmato che cosa.

Come si verifica, passo per passo

I limiti, dichiarati

Una pagina di sicurezza che elenca solo i punti di forza è una pubblicità. Questi sono i confini. Stanno qui perché l'alternativa è che tu li scopra dopo.

Non abbiamo alcuna certificazione di sicurezza

Non siamo SOC 2 Type II. Non siamo ISO 27001. Non siamo conformi HIPAA. Nessun auditor ci ha valutati rispetto a nessuno di quei quadri, e non mostreremo un bollino che non possediamo. Il GDPR è cosa di natura diversa: una legge che siamo obbligati a rispettare, non un certificato che qualcuno rilascia — ed è per questo che qui trovi una pagina sulla protezione dei dati e nessun sigillo.

Il prodotto non è open source; la parte che ci controlla dovrebbe esserlo

Il nostro codice di server non si può leggere, e non dovresti averne bisogno. Ciò che deve essere degno di fiducia è la possibilità di controllare il nostro risultato senza di noi — e quella possibilità, oggi, poggia su uno standard pubblicato e su una blockchain pubblica, non su una nostra promessa.

Il limitatore di frequenza cede in apertura

Se il contatore stesso non è raggiungibile, la richiesta passa e l'anomalia finisce nei log. È una scelta deliberata: un guasto del contatore chiuderebbe altrimenti la porta a firmatari legittimi, e la difesa che conta davvero contro chi tenta di indovinare un codice — il blocco a tre tentativi — non dipende da lui.

Cancellare l'account non cancella i certificati emessi

Rimuove i tuoi dati personali, le tue bozze e ciò che avevi in sospeso. I certificati già emessi restano verificabili, perché sono anche la prova dell'altra parte: distruggerli su richiesta di un solo firmatario vanificherebbe la ragione per cui esistono.

Distruggere una registrazione non è istantaneo dappertutto

I file li cancelliamo. Per un'ora una cache dello storage può ancora servirne una copia, e le copie già scaricate da chi ne aveva diritto restano dove sono. Ciò che non viene mai toccato è la prova: l'impronta dell'audio, il pacchetto probatorio e l'ancoraggio restano intatti, quindi distruggere una registrazione non cambia mai ciò che è stato certificato.

Non c'è un bug bounty

Leggiamo ogni segnalazione e correggiamo ciò che è reale, ma non abbiamo un programma a pagamento e preferiamo che tu non te lo aspetti.

Preferiamo che tu li legga qui, invece di scoprirli dopo. Nessuno di essi tocca la cosa che conta di più — se un certificato si possa verificare senza di noi — e quella parte sta qui sopra, con i comandi per farlo.

Segnalare una vulnerabilità

Se hai trovato qualcosa, vogliamo saperlo da te prima che da chiunque altro.

  • Scrivi a hub@witup.ai. Raccontaci che cosa hai fatto, che cosa è successo e come si riproduce. Una riga sull'impatto aiuta più del rapporto di uno scanner.
  • Prova solo sul tuo account e sui tuoi dati. Non toccare protocollazioni, sessioni o certificati di altri, e non eseguire test di carico o di negazione del servizio contro il servizio.
  • Non pubblichiamo un impegno sui tempi di risposta, perché non siamo ancora in condizione di garantirlo. Preferiamo dirlo, piuttosto che promettere un numero che potremmo mancare.
hub@witup.ai

Dove andare adesso