Sicurezza su qub

Data di efficacia: 23 settembre 2026 Versione: 1.1 — revisione dell'accuratezza rispetto all'implementazione

Per i ricercatori — riferimento rapido:

• Dove inviare le segnalazioni: support@qub.social con il prefisso oggetto [SECURITY].
• Cosa includere: la vulnerabilità, i passi per riprodurla e qualsiasi proof-of-concept.
• La nostra risposta: confermiamo la ricezione entro 3 giorni lavorativi e miriamo a rilasciare una correzione entro 90 giorni.
• Safe Harbor: non perseguiremo azioni legali contro ricerche in buona fede che seguono le regole nel §12 (nessun accesso a dati non Suoi, nessuna degradazione del servizio, nessuna conservazione di dati ottenuti oltre quanto necessario per dimostrare il problema, dateci una finestra di divulgazione ragionevole).

I dettagli completi sono nel §12 (Divulgazione Coordinata).

Chi Siamo

qub.social è gestito da VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. I riferimenti a "qub", "noi", "nostro" indicano tale entità.

Contatto sicurezza: support@qub.social con il prefisso oggetto [SECURITY].

1. Il Nostro Approccio

qub è infrastruttura di fiducia. Il prodotto è privo di valore se non è sicuro, quindi la sicurezza non è una funzionalità — è il substrato. Questa pagina descrive, in termini concreti, come tuteliamo il nostro stack, i Suoi dati e l'integrità dei contenuti sigillati.

Il valore di un impegno temporale verificabile cresce man mano che una parte maggiore di internet diventa generata da macchine. Una transazione di archiviazione verificata o un ancoraggio del log di trasparenza può stabilire che il ciphertext esisteva non oltre il relativo tempo di blocco; l'artefatto sigillato dimostra separatamente l'integrità del contenuto, il binding al drand round e le eventuali firme di autorialità. Tenere distinte queste affermazioni è il livello a cui questa pagina è tenuta.

Non Le chiediamo di fidarsi di noi. Progettiamo in modo che la fiducia richiesta a noi sia la più piccola possibile, e dove la fiducia è richiesta spieghiamo esattamente cosa viene affidato e perché.

Tre principi guidano ogni decisione di progettazione:

• Minimizzare ciò che il server può vedere. Nel flusso predefinito dei messaggi nel browser, il plaintext e la chiave del wrapper restano sul Suo dispositivo. La sigillatura Builder lato server, la cofirma dei patti e il recupero abilitato esplicitamente hanno confini di fiducia diversi, descritti qui sotto. Quando deteniamo metadati, li limitiamo a ciò che richiede la funzionalità scelta.
• Rendere il compromesso localmente contenuto. Una violazione di qualsiasi singolo componente (il nostro server, il fornitore email, un nodo drand) non dovrebbe rivelare contenuti sigillati che non hanno ancora raggiunto la loro ora di rivelazione.
• Rendere il protocollo verificabile. L'artefatto sigillato è verificabile end-to-end con crittografia pubblica. Non è necessario fidarsi di qub il servizio per verificare un qub l'artefatto.

2. Modello di Minaccia

2.1 Da Cosa Proteggiamo

• Un attaccante che ottiene accesso in lettura ai nostri dati memorizzati lato server prima dell'ora di rivelazione. Nel flusso privato predefinito del browser ottiene metadati e byte avvolti opachi, non il plaintext né K. Questa protezione non si applica a una K conservata esplicitamente per il recupero, alla consegna pubblica/nuda dopo il relativo drand round o al plaintext fornito transitoriamente ai flussi Builder /api/v1/seal e dei patti.
• Un attaccante che intercetta il traffico tra il Suo browser e la nostra infrastruttura. TLS termina al nostro edge CDN; i payload sigillati sono già cifrati prima del transito.
• Un attaccante che manomette un payload memorizzato. L'autenticazione del wrapper esterno (quando presente), la decodifica canonica, l'hash del corpo, la ri-derivazione di qub_id, il binding del round e le firme facoltative fanno fallire la verifica; il visualizzatore rifiuta di renderizzare il qub.
• Un attaccante che cerca di legare un'email autore falsificata a una chiave di firma. L'attestazione email richiede il possesso sia della chiave di firma privata sia di un codice monouso consegnato all'inbox email.
• Un operatore di beacon drand compromesso. La rete drand utilizza firme BLS a soglia attraverso molteplici operatori indipendenti; una minoranza non può falsificare firme di rilascio anticipato.

2.2 Da Cosa Non Possiamo Proteggere

Siamo onesti sui nostri limiti. qub non può difendersi da:

• Un compromesso del Suo dispositivo prima della sigillatura. Keylogger locali, estensioni del browser dannose o accesso fisico a un dispositivo sbloccato possono catturare il testo in chiaro al punto di composizione.
• Un collasso della soglia drand. Molteplici organizzazioni indipendenti gestiscono la rete drand specificamente per rendere questo difficile, ma non è crittograficamente impossibile: se abbastanza operatori colludono, potrebbero derivare chiavi timelock in anticipo.
• Le proprietà di rilascio di una copia valida. Un qub pubblico/nudo diventa decifrabile dopo il relativo drand round. Un qub privato/avvolto richiede inoltre K; chiunque ottenga sia i byte memorizzati sia K può decifrarlo dopo il round. I record dell'archivio permanente e del log ancorato non possono essere richiamati semplicemente rimuovendoli dalla superficie del prodotto qub.
• Un avversario globale che rompe la crittografia sottostante (AES-GCM, assunzioni di pairing BLS12-381, SHA3-256, ML-DSA-65). Se queste primitive cadono, l'ecosistema crittografico in generale ha problemi più grandi.

3. Crittografia Lato Client

Nel flusso predefinito dei messaggi nel browser, la cifratura del contenuto avviene prima della richiesta di upload. Due percorsi espliciti differiscono: Builder /api/v1/seal invia deliberatamente al Worker il plaintext e la K generata dal chiamante per la sigillatura in memoria, mentre lo staging e la cofirma dei patti inviano al servizio il patto strutturato firmato affinché possa finalizzare l'artefatto bilaterale. Nessuna delle due eccezioni deve essere confusa con la cifratura end-to-end del percorso browser.

3.1 Timelock Encryption

qub utilizza tlock — cifratura basata su identità chiavizzata a un round beacon drand futuro. La cifratura procede nel Suo browser utilizzando la chiave pubblica della rete drand; la chiave di decifratura viene rilasciata pubblicamente dalla rete drand solo quando viene raggiunto il round target. Nessuno, inclusi noi, può ricostruire la chiave di decifratura in anticipo.

Puntiamo alla catena quicknet:

• Periodo del round di 3 secondi
• Modalità unchained (ogni round è indipendente)
• Firme BLS12-381 G1
• Chain hash 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

La chiave pubblica della catena quicknet e il tempo di genesis sono compilati nel client. Non recuperiamo i parametri della catena a runtime, quindi un nodo malevolo non può sostituire una catena che controlliamo.

3.2 Cifratura Simmetrica

Lo schema tlock incapsula una chiave di contenuto AES-256-GCM. AES-GCM fornisce cifratura autenticata: un singolo bit invertito nel ciphertext causa il fallimento della decifratura, anziché produrre testo in chiaro silenziosamente corrotto.

3.3 Serializzazione Canonica

Le strutture del protocollo sono serializzate utilizzando CBOR deterministico (RFC 8949 §4.2 core deterministic encoding). Due implementazioni che codificano la stessa struttura logica producono CBOR identico. I payload sigillati completi non sono deterministici: la cifratura tlock e quella del wrapper esterno usano casualità fresca. L'hash del corpo viene calcolato sui byte grezzi del corpo, mentre la codifica canonica rende non ambigue le strutture firmate e wire circostanti.

Abbiamo scritto il codificatore CBOR a mano sia per la nostra implementazione client che server piuttosto che fare affidamento su una libreria di serializzazione generica — il requisito è l'esattezza, non l'ergonomia, e i property test funzionano in entrambe le implementazioni per verificare che siano d'accordo.

Un test di regressione afferma che il formato wire canonico non contiene alcuna sequenza di byte di brand qub oltre la chiave campo qub_id primitiva del protocollo. Il formato wire è intenzionalmente agnostico al brand — qualsiasi visualizzatore conforme (nostro o di terze parti) può renderizzare qualsiasi qub dall'archivio permanente, indipendentemente da quale deployment l'abbia sigillato. Il test è un cavo d'allarme che impedisce a una modifica futura di cuocere accidentalmente un riferimento al brand in byte che, una volta nell'archivio permanente, non possono essere riscritti.

3.4 Hashing del Corpo e Integrità Pre-Rivelazione

Ogni payload sigillato porta un hash SHA3-256 dei byte grezzi del proprio corpo. L'hash è legato a qub_id e, quando la firma di autorialità è abilitata, all'input della firma V2. Un visualizzatore lo ricalcola dopo la decifratura e rifiuta una mancata corrispondenza.

L'identificatore di contenuto a 32 byte qub_id è derivato da un preimage di 108 byte che copre la versione del protocollo, il tipo di contenuto, le marcature temporali di creazione e sblocco, la marcatura temporale facoltativa dell'esito (o la sua sentinella zero), il drand round di destinazione, l'hash del corpo e lo SHA3-256 del titolo facoltativo normalizzato NFC. Un gateway o una CDN non può modificare coerentemente alcun campo vincolato e superare comunque la ri-derivazione. I titoli sono limitati a 100 punti di codice NFC e vengono rifiutati se contengono la classe condivisa di code point ostili/di controllo (inclusi override bidi, caratteri a larghezza zero, blocco dei tag, BOM, C0, C1 e DEL).

3.5 Firma (ML-DSA-65)

La firma di autoria utilizza ML-DSA-65 (FIPS 204), uno schema di firma post-quantum standardizzato dal NIST. Abbiamo scelto deliberatamente una primitiva post-quantum per la firma perché i contenuti sigillati sono permanenti: una firma che verifica oggi deve ancora verificare decenni da ora, anche dopo che i computer quantistici su larga scala diventino pratici.

Le chiavi di firma sono generate nel browser. Il segreto locale viene avvolto sotto una chiave WebCrypto non estraibile prima di essere memorizzato in IndexedDB. Se viene usata la funzionalità di recupero cross-device limitata all'account, un blob di chiave portabile cifrato con AEAD viene memorizzato lato server; il ciphertext della chiave segreta è legato all'id immutabile dell'account e il servizio convalida l'envelope pubblico, ma non può decifrare il materiale segreto. I byte grezzi della chiave privata non vengono inviati al server. Le chiavi pubbliche e i record di attestazione vengono memorizzati per la verifica e la visualizzazione dell'identità.

La stessa decifratura tlock nel browser si applica all'interno dell'embed qub: quando un qub sigillato viene renderizzato tramite <qub-embed> su una pagina di terze parti, la decifratura avviene comunque nell'iframe embed nel browser del visualizzatore. L'embed non cambia il modello di fiducia — il testo in chiaro non viene mai decifrato su un server qub.

3.6 Attribuzione Pubblica — Opt-In

I qub sigillati non portano alcun puntatore on-chain al loro creatore a meno che il creatore non scelga esplicitamente di allegarne uno. Quando sigilla un qub l'app di riferimento emette un tag Author dell'archivio (un fingerprint esadecimale di 64 caratteri della Sua chiave pubblica di firma) solo quando "Attribuzione pubblica" è attivata nel passaggio del selettore data. Con l'interruttore disattivato — l'impostazione predefinita — nessun tag Author viene scritto e il qub è non attribuito nell'archivio permanente: nulla sulla rete collega il caricamento al Suo handle, alla Sua email o agli altri Suoi qub. Con l'interruttore attivato, il fingerprint risolve al Suo @handle tramite la catena di attestazione nei §6.3 / §10 e il conto alla rovescia del visualizzatore mostra "Sigillato da @{handle}" prima della rivelazione.

Questa è una protezione deliberata contro il rischio di enumerazione che un tag Author sempre attivo creerebbe: una terza parte che apprende il fingerprint di un creatore potrebbe altrimenti effettuare grep sull'archivio permanente per il tag e ricostruire l'intera produzione storica di quel creatore. L'attribuzione opt-in chiude quel canale — solo i qub che il creatore sceglie esplicitamente di attribuire appaiono sotto un fingerprint nell'archivio permanente.

La pagina di profilo /u/{handle} è una scheda di identità verificata — handle, nome visualizzato opzionale + URL, badge "email verificata" (nessun indirizzo), e la forma breve del fingerprint crittografico. Non elenca i qub di un creatore. I visitatori che vogliono vedere un qub specifico di un creatore seguono direttamente l'URL di consegna di quel qub.

3.7 Wrapper di Cifratura Esterno

Anche dopo che la decifratura timelock diventa matematicamente possibile, cioè quando viene pubblicata la firma drand del round vincolato, il solo livello timelock canonico permetterebbe a un indicizzatore di decifrare in massa i qub individuabili. La consegna privata chiude quel canale con un livello simmetrico aggiuntivo attorno ai byte cifrati con timelock (Protocollo §13). La consegna pubblica omette deliberatamente il wrapper, così i link di notifica, embed e individuazione possono funzionare senza un frammento segreto.

Il wrapper utilizza AES-256-GCM, un cifrario autenticato standardizzato dal NIST, con una chiave fresca a 256 bit K generata per qub dal CSPRNG del Suo browser. K è legato al qub_id del qub come dati aggiuntivi autenticati, quindi una chiave da un qub non può essere riutilizzata per decifrare un qub diverso.

K non raggiunge mai i nostri server nel flusso privato predefinito del browser. È codificata nel frammento URL del link di condivisione (https://qub.social/c/<tx_id>#<base64url(K)>). I browser non trasmettono i frammenti URL ai server — l'RFC 3986 colloca il frammento al di fuori della richiesta — quindi qub.social, i gateway di archiviazione, le CDN e il monitoraggio delle richieste non vedono K in quel flusso. L'OuterWrapper memorizzato è CBOR strutturato riconoscibile, ma il suo campo ciphertext autenticato nasconde la struttura SealedQub interna e non può essere aperto senza K.

Conseguenze nette:

• qub.social non può decifrare i sigilli privati predefiniti del browser dai soli dati memorizzati. Un compromesso dell'archivio dati raggiunge ciphertext opaco senza K. I qub pubblici e quelli con recupero abilitato hanno un'esposizione diversa per scelta progettuale.
• La perdita del frammento è irrecuperabile senza un canale di recupero opt-in. Se salva un link privato senza il frammento e non ha abilitato il recupero, il qub diventa illeggibile tramite quel link. Il flusso di sigillatura mostra una divulgazione esplicita "salva questo URL" per questo motivo.
• Recupero opt-in. Quando opta per le email di ciclo di vita del creatore per un qub E l'email corrisponde alla Sua identità verificata, accettiamo K con il caricamento, memorizziamo l'URL di consegna completo sul record di cronologia sigillata della Sua identità, e lo usiamo come link nell'email di conferma di sigillatura. Questo scambio — un canale di recupero lato server in cambio di una certa purezza end-to-end — si attiva solo su opt-in esplicito e solo per quel qub. La postura predefinita è crypto-shredding.

L'endpoint server-side /api/v1/seal del Worker (utilizzato da agenti IA e altri chiamanti API) richiede che il chiamante generi K con un CSPRNG, la conservi localmente, e la fornisca come wrapper_key_b64url. Il Worker vede necessariamente sia il plaintext sia K in memoria su questo percorso esplicitamente fidato, ma non persiste nessuno dei due. Un Idempotency-Key obbligatorio impedisce che una risposta persa crei un secondo qub fatturato, mentre la K conservata dal chiamante può essere combinata con l'URL riprodotto e privo di frammento. Questo differisce dal percorso browser predefinito, dove K non raggiunge mai il Worker a meno che il creatore non abiliti esplicitamente il recupero.

4. Trasporto ed Edge

4.1 TLS

Il traffico del browser verso qub viene servito via HTTPS all'edge Cloudflare. Le risposte impostano HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). La versione TLS e la suite crittografica negoziate esattamente sono governate dalla configurazione attiva dell'edge, anziché essere asserite dal codice applicativo. Non esponiamo un server di origine raggiungibile separatamente.

4.2 Content Security

Il client compilato viene servito con header content-type e cache rigorosi. La shell SPA è una singola origine. Non incorporiamo script di terze parti per analytics o pubblicità. I due touchpoint di terze parti nel prodotto sono entrambi a portata ristretta: il flusso di acquisto lascia la SPA interamente con un redirect a pagina intera al checkout ospitato da Stripe (https://checkout.stripe.com/…) — l'UI di Stripe non viene mai eseguita nella nostra origine e non vediamo mai i dati della carta — e il flusso di sigillatura carica il widget Turnstile di Cloudflare, un'alternativa CAPTCHA che preserva la privacy che Cloudflare renderizza all'interno del proprio iframe sandboxato. Nessuna delle due parti può leggere il resto della pagina.

L'iframe embed qub (servito da qub.social/embed/{tx_id} e caricato in siti di terze parti da embed.js) porta la propria Content-Security-Policy. La allowlist di connect-src è 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh e https://drand.cloudflare.com. L'iframe funziona con sandbox="allow-scripts allow-top-navigation-by-user-activation" (non allow-same-origin): la pagina host non può leggerne il DOM e l'iframe non può navigare l'host salvo dopo un'azione dell'utente.

4.3 CORS e Ambito Fetch

Il client del browser effettua richieste fetch solo a:

• La nostra API (api.qub.social ed equivalenti di staging)
• Gateway di archiviazione (sola lettura, per recuperare byte privati avvolti o pubblici nudi — §3.6)
• Endpoint beacon drand (sola lettura, per le firme dei round al momento della rivelazione)

Le destinazioni dell'embed sono imposte dalla sua CSP. Le destinazioni previste della SPA principale sono fissate nel codice e nella configurazione e vengono esercitate dai controlli del browser e di integrazione; Subresource Integrity non è un controllo delle destinazioni di rete.

L'embed recupera i byte memorizzati tramite le origini qub/di archiviazione nella allowlist, scarta nel browser il wrapper dei payload privati usando K dal frammento URL e recupera le firme del round di rivelazione dalle due origini drand consentite. La SPA principale usa il set di fallback a quattro endpoint in config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh e api3.drand.sh), così il guasto di un endpoint non blocca la rivelazione. La CSP dell'embed nega le connessioni al di fuori della propria lista esplicita.

5. Infrastruttura Lato Server

5.1 Edge Serverless

La nostra API funziona interamente su un runtime serverless gestito all'edge. Non ci sono VM, container, o processi server persistenti che amministriamo. Questo riduce drasticamente la superficie d'attacco di cui siamo responsabili: non gestiamo un OS, un server web, o un runtime applicativo che dobbiamo patchare.

Si applica un middleware CORS pubblico separato Access-Control-Allow-Origin: * al percorso impostato seguente: /embed.js, /embed/v1.js, tutto sotto /embed/; /api/v1/telemetry; /api/v1/openapi.json; tutto sotto /api/v1/qub/ (inclusi byte, metadati, prova, coinvolgimento, notifica e sottoroute push); tutto sotto /api/v1/log/; gestione pubblica delle ricerche di handle sotto /api/v1/handle/; e l'avatar pubblico legge sotto /api/v1/identity/avatar/. I suoi permessi di pre-volo GET, POST, e OPTIONS con il Content-Type intestazione della richiesta. Questa superficie basata su prefisso è più ampia rispetto alle sole chiamate che l'embed effettua attualmente, quindi ogni gestore al di sotto di quei prefissi deve continuare a far rispettare la propria validazione, autenticazione, limiti di velocità e controlli sugli abusi. Altri percorsi API mantengono la politica CORS qub.social-restricted.

5.2 Archiviazione

• Gli archivi di metadati e coordinamento detengono record di identità e attestazione, abilitazioni e riferimenti di fatturazione, record di chiavi API, voci di denylist, sessioni, stato di idempotenza, code e stato di limite di frequenza/concorrenza. Esigenze diverse di coerenza usano KV, D1 e Durable Objects anziché un unico archivio universale.
• Il nostro archivio oggetti è anche un substrato di durabilità. Contiene gli esatti byte avvolti o nudi del qub confermati dall'upload, le foglie del log di trasparenza e i nodi Merkle indicizzati per coordinate, materiale di ancoraggio, log di eventi strutturati e cache di risposte/metadati.
• L'archivio pubblico permanente contiene gli ancoraggi del log di trasparenza e, per il percorso T3 o la pubblicazione differita, singole transazioni qub. Non gestiamo tale rete. I payload privati del browser restano opachi lì salvo che il detentore abbia anche K; i payload pubblici/nudi deliberatamente non hanno tale livello aggiuntivo di capability legata al link.

Il flusso predefinito dei messaggi nel browser non persiste plaintext sull'infrastruttura qub. Builder /api/v1/seal gestisce plaintext e K in memoria, ma non persiste nessuno dei due. Lo staging dei patti memorizza necessariamente il patto strutturato firmato finché non viene cofirmato, ritirato o scade. Il recupero opt-in memorizza una capability di consegna (il link completo con frammento) affinché possa essere recuperata in seguito. Non descriviamo quindi l'intero livello di archiviazione come "solo metadati".

5.3 Segreti

I segreti (wallet di firma, token dei fornitori e chiavi HMAC) vengono forniti tramite binding di segreti/ambiente della piattaforma anziché tramite il controllo sorgente. I componenti runtime ricevono soltanto i binding di cui hanno bisogno. Le procedure di rotazione e sovrapposizione sono specifiche per componente; non rivendichiamo un unico meccanismo universale di rotazione automatica o sottoposta ad audit.

5.4 Logging e Telemetria

I log JSON strutturati vengono scritti su ogni richiesta API con un ID di correlazione mostrato nell'header di risposta X-Request-Id. La telemetria del client è anonima — nessun identificatore di dispositivo, nessun indirizzo IP, nessuna anteprima del contenuto. Gli eventi sono memorizzati in buffer di memoria e svuotati su base best-effort; uno svuotamento fallito viene scartato, non ritentato. La telemetria è progettata per essere disabilitabile a livello di rete senza influire sul prodotto.

6. Autenticazione

6.1 Accesso Magic-Link

L'accesso utilizza un token monouso firmato con HMAC consegnato alla Sua inbox email. Il link è valido per 15 minuti e il riscatto viene rivendicato atomicamente, così un uso concorrente o ripetuto fallisce in modo sicuro. In caso di successo, il browser riceve un cookie opaco __Host-qub_session con gli attributi Secure, HttpOnly, SameSite=Strict e Path=/.

Le sessioni hanno un limite di inattività di 30 giorni e un limite assoluto di 90 giorni, ruotano dopo 24 ore e accettano soltanto la generazione immediatamente precedente per un periodo di grazia di 120 secondi in caso di risposta persa. Le modifiche sensibili all'account richiedono un'autenticazione avvenuta nei 10 minuti precedenti. Il segreto di firma HMAC è un binding della piattaforma; una lettura dei soli metadati non consente di coniare un token valido.

6.2 Chiavi API (Livello Sviluppatore)

Le chiavi API sviluppatore utilizzano il prefisso qub_sk_ per facilitarne il riconoscimento e la ricerca con grep. Ogni chiave:

• È legata a un account, ad ambiti e a una allowlist facoltativa di CIDR IP
• Viene mostrata in forma grezza una sola volta; i record persistenti ne conservano l'hash SHA-256, non il segreto bearer
• Può essere ruotata con una mappatura di grazia di un'ora in cui la vecchia chiave risolve a quella sostitutiva
• Ha uno stato indipendente di quota e limite di frequenza
• Non viene mai registrata per intero; i log registrano solo l'identificatore della chiave

Gli endpoint admin di gestione chiavi sono protetti da una credenziale admin separata.

6.3 Attestazione Email (Firma di Autoria)

Legare un indirizzo email a una chiave di firma richiede:

1. Possesso della chiave di firma privata (firma una challenge)
2. Possesso dell'inbox email (inserisce un codice a 6 cifre consegnato per email)

Uno solo è insufficiente. La revoca è un record firmato sul Suo account e ha effetto immediato; i visualizzatori che recuperano l'attestazione vedono lo stato revocato e visualizzano di conseguenza.

7. Pagamenti

L'inserimento e l'elaborazione dei dati della carta avvengono nel checkout ospitato da Stripe. Non riceviamo mai numeri di carta, date di scadenza o CVC. Memorizziamo gli identificatori cliente e abbonamento Stripe, lo stato dell'abbonamento e i dati del periodo nei record di abilitazione/chiave API, così da poter riconciliare accesso, rinnovi, misurazione, cancellazione e rimborsi. Le dichiarazioni di privacy e sicurezza di Stripe regolano la gestione dei dati di pagamento da parte di Stripe.

L'endpoint di sigillatura controlla l'incrocio del record di abbonamento contro l'identificatore di dispositivo e, per gli utenti autenticati, contro l'identità collegata. Un abbonamento non può essere riutilizzato attraverso i dispositivi senza che l'utente lo ripristini esplicitamente tramite accesso magic-link.

8. Resistenza agli Abusi

8.1 Rilevamento Bot

Il flusso di sigillatura è protetto da un'alternativa CAPTCHA che preserva la privacy che non utilizza cookie per il tracciamento e non effettua fingerprinting per la pubblicità. Una challenge fallita viene rifiutata dal nostro Worker edge prima che avvenga qualsiasi elaborazione lato sigillatura.

8.2 Limitazione di Frequenza

I limiti di frequenza sono applicati a diversi livelli:

• Limiti per IP e per chiave su endpoint di sigillatura, lettura e auth
• Limiti per email su richieste magic-link (previene l'inondazione delle inbox)
• Limiti per controparte su email di invito patti (dieci per indirizzo destinatario per giorno UTC, la principale mitigazione anti-spam-relay; i patti onesti non si avvicinano quasi mai al limite)
• Limiti per IP sull'invio di telemetria

I contatori e le rivendicazioni atomiche sono distribuiti tra KV, Durable Objects e binding di limite di frequenza della piattaforma in base alle esigenze di coerenza dell'endpoint. Le richieste soggette a limite restituiscono 429; gli endpoint che possono calcolare una finestra di nuovo tentativo includono Retry-After.

8.3 Moderazione dei Contenuti

Il percorso predefinito di caricamento del browser non può scansionare il corpo: riceve solo l'artefatto sigillato dal client. Il Builder /api/v1/seal il percorso vede il testo in chiaro transitoriamente, e il staging di pact mantiene i termini strutturati fino alla finalizzazione, ma quelle eccezioni di fiducia non trasformano il percorso di caricamento generalmente cieco ai byte in uno scanner di contenuti. La moderazione operativa è un lista di esclusione al livello del visualizzatore: un qub nella lista di esclusione viene rifiutato dal nostro visualizzatore indipendentemente dal fatto che il payload memorizzato rimanga accessibile. L'inserimento nella lista di esclusione non revoca byte durevoli, voci del registro della trasparenza o dati permanenti della rete già pubblicati.

Le segnalazioni di abuso sono limitate per frequenza utilizzando un hash unidirezionale dell'IP del segnalatore; non memorizziamo gli IP in chiaro per questo scopo.

9. Catena di Fornitura e Integrità della Build

9.1 Pinning del Toolchain

Le versioni del compilatore e del runtime sono pinnate nella configurazione del repository e le dipendenze vengono risolte tramite lockfile sottoposti a commit. CI controlla che i file generati siano aggiornati e verifica gli invarianti sensibili alla riproducibilità. Non sosteniamo l'affermazione più forte secondo cui ogni build pulita sia identica bit per bit su tutte le macchine supportate.

9.2 Lint e Analisi Statica

Il workspace abilita i nostri gruppi di lint più rigorosi al livello deny. CI tratta ogni warning — inclusi i warning sui link della documentazione — come un fallimento della build. Questo è deliberato: utilizziamo la rigorosità del lint come cavo d'allarme per regressioni sottili.

9.3 Gate CI

Il workflow CI copre formattazione e lint rigorosi; test Rust, WASM/browser, Worker, embed e API; type checking; copertura del codice; controlli di mutazione/invarianti; analisi statica delle dipendenze e dei workflow; controlli di chiavi, copertura, drift e code point ostili i18n; aggiornamento di documenti generati, API e knowledge base; inventario dei documenti e link interni; budget di fogli di stile e bundle; e convalida OpenAPI. Alcuni job di mutazione costosi sono pianificati anziché eseguiti a ogni push.

Un unico roll-up richiesto ci resta rosso se fallisce qualsiasi job obbligatorio. I workflow dei rami protetti e di deploy consumano quel risultato anziché duplicare un gate di sicurezza più piccolo.

9.4 Mutation Testing

Un job settimanale esegue mutation testing contro i moduli puri critici per la sicurezza: hashing, CBOR canonico, seal, unlock, i newtype di formato wire, i validatori di tipo protocollo, e il namespace degli handle. Il mutation testing risponde a "la nostra suite di test cattura codice sottilmente errato?" — se un'implementazione mutata supera comunque tutti i test, sappiamo di avere una lacuna nella copertura dei test e la affrontiamo.

9.5 Git Hook

Gli hook locali (pre-commit, pre-push) rispecchiano i gate CI in modo che le regressioni siano catturate prima di lasciare la macchina dello sviluppatore. Gli hook vengono installati tramite uno script repo; non vengono bypassati nel nostro workflow e CI è il gate autoritativo se vengono saltati.

10. Testing

Il codice critico per la sicurezza porta tre tipi di test:

• Unit test verificano il comportamento atteso su input noti, inclusi vettori di test derivati dalla specifica del protocollo.
• Property test generano migliaia di input arbitrari e affermano invarianti: round-trip CBOR canonico, round-trip di verifica della firma, predicati di binding email, determinismo di acknowledgement dei patti.
• Test cross-implementation verificano che le nostre implementazioni client e server siano d'accordo byte per byte sulle codifiche canoniche. Questo cattura la divergenza tra le due implementazioni prima che raggiunga la produzione.

11. Igiene del Ramo e del Rilascio

I rami di funzionalità fanno avanzare staging soltanto attraverso una pull request Gate 1: ci obbligatorio verde, nessuna richiesta di modifica irrisolta, nessun conflitto di merge e albero revisionato pulito; il merge usa squash ed elimina il ramo. main avanza soltanto attraverso la pull request Gate 2 staging → main e conserva la genealogia con un merge commit. I push diretti ai rami non sono il workflow di rilascio.

I deploy di staging e produzione vengono attivati dai corrispondenti stati dei rami protetti staging e main dopo CI. Il codice delle pull request e le credenziali dei fork non ricevono i segreti di deploy.

12. Divulgazione Coordinata

Se ritiene di aver trovato una vulnerabilità di sicurezza in qub, vogliamo saperlo rapidamente e ci impegniamo a gestire la segnalazione professionalmente.

• Invii un'email a support@qub.social con il prefisso oggetto [SECURITY].
• Descriva la vulnerabilità, i passi per riprodurla, e qualsiasi proof-of-concept.
• Ci dia una finestra di divulgazione ragionevole (tipicamente 90 giorni) prima di rendere pubblico.
• Non acceda a dati che non Le appartengono, non degradi il servizio per altri utenti, o non conservi dati ottenuti durante la ricerca oltre quanto necessario per dimostrare il problema.

Confermiamo la ricezione entro tre giorni lavorativi e La teniamo informato mentre indaghiamo. Con il Suo consenso, accreditiamo i segnalatori nelle note di rilascio.

12.1 Safe Harbor

Se la Sua ricerca segue le regole sopra (indagine in buona fede, nessun danno ad altri utenti o al servizio, finestra di divulgazione ragionevole), non perseguiremo azioni legali contro di Lei, e non chiederemo alle forze dell'ordine di farlo. Trattiamo il Suo lavoro come testing autorizzato e preferiamo che trovi il bug Lei piuttosto che qualcun altro.

Questo Safe Harbor si applica a:

• Ricerca sul servizio live qub.social (non su fixture di test che pubblichiamo per quello scopo).
• Reverse-engineering dei nostri binari pubblicati e dei crate open-source qub-core / qub-app.
• Qualsiasi classe di vulnerabilità — protocollo, applicazione, infrastruttura, catena di fornitura — che influisce su qub.

Non si applica all'ingegneria sociale dei membri del team qub, ai test di denial-of-service, o all'accesso ai dati di altri utenti oltre quanto necessario per dimostrare il problema. Se non è sicuro se qualcosa rientra nel Safe Harbor, chieda prima usando lo stesso prefisso oggetto [SECURITY].

13. Limitazioni Oneste

La sicurezza è una pratica, non uno stato. Alcune limitazioni meritano di essere nominate direttamente:

• Siamo un team piccolo. La profondità della nostra revisione non corrisponde alla funzione dedicata di sicurezza applicativa di una grande corporation. Compensiamo con gate automatici rigorosi e una superficie d'attacco minima, ma non rivendichiamo infallibilità.
• La permanenza del nostro backend di archiviazione è una porta a senso unico. Se un errore causa che il contenuto sigillato diventi decifrabile prima del previsto, non possiamo annullarlo. Trattiamo il flusso di sigillatura con cura commisurata.
• La rete drand è una dipendenza esterna. Un guasto catastrofico di drand influenzerebbe il comportamento di rivelazione di ogni qub. Monitoriamo la salute di drand e abbiamo documentazione di contingenza per la migrazione di catena se richiesto. Per date di sblocco a più di 2 anni, la modale di conferma al momento della sigillatura mostra una divulgazione esplicita: i qub a lungo orizzonte dipendono dalla durabilità della catena drand, e una futura migrazione di catena drand può richiedere passi di recupero per sbloccare il qub. Per date di sblocco a più di 5 anni, deve controllare una casella extra che conferma di aver letto e accettato questo rischio prima che la sigillatura proceda.
• Le primitive crittografiche su cui facciamo affidamento sono standardizzate e ampiamente revisionate, ma la crittografia evolve. Dove abbiamo scelte (firma post-quantum, cifratura autenticata), scegliamo l'opzione più conservativa.

14. Modifiche a Questa Pagina

Le modifiche sostanziali sono indicate aggiornando la data di efficacia in cima. Dove una modifica riflette un miglioramento concreto di sicurezza, la descriviamo brevemente nel changelog pubblico. Dove una modifica riflette un chiarimento di politica, descriviamo cosa è cambiato e perché.

Per domande su qualsiasi cosa in questa pagina, invii un'email a support@qub.social con il prefisso oggetto [SECURITY].

15. Registro delle Modifiche