Bezpečnost u qub

Datum účinnosti: 23. září 2026 Verze: 1.1 — revize přesnosti vůči implementaci

Pro výzkumníky — rychlá reference:

• Kam zasílat hlášení: support@qub.social s předponou předmětu [SECURITY].
• Co zahrnout: zranitelnost, kroky k reprodukci a jakýkoli proof-of-concept.
• Naše reakce: přijetí potvrdíme do 3 pracovních dnů a snažíme se dodat opravu do 90 dnů.
• Bezpečný přístav (Safe Harbor): nepodnikneme právní kroky proti výzkumu v dobré víře, který dodržuje pravidla v §12 (žádný přístup k datům, která nejsou vaše, žádné zhoršování služby, žádné uchovávání získaných dat nad rámec toho, co je potřeba k prokázání problému, poskytnutí přiměřeného okna pro zveřejnění).

Úplné podrobnosti jsou v §12 (Koordinované zveřejnění).

Kdo jsme

qub.social provozuje společnost VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Austrálie. Odkazy na „qub“, „my“, „nás“ a „naše“ znamenají tento subjekt.

Kontakt pro bezpečnost: support@qub.social s předponou předmětu [SECURITY].

1. Náš přístup

qub je infrastruktura důvěry. Produkt je bezcenný, pokud není bezpečný, takže bezpečnost není funkcí — je substrátem. Tato stránka konkrétně popisuje, jak chráníme náš stack, vaše data a integritu zapečetěného obsahu.

Hodnota ověřitelného časového závazku roste, jak se stále větší část internetu stává strojově generovanou. Ověřená transakce úložiště nebo kotva logu transparentnosti může doložit, že šifrovaný text existoval nejpozději v čase příslušného bloku; zapečetěný artefakt samostatně prokazuje integritu obsahu, vazbu na kolo drand a případné podpisy autorství. Laťkou této stránky je důsledné oddělení těchto tvrzení.

Nežádáme vás, abyste nám důvěřovali. Navrhujeme tak, aby důvěra po nás požadovaná byla co nejmenší, a tam, kde je důvěra vyžadována, přesně vysvětlujeme, čemu se důvěřuje a proč.

Tři principy řídí každé rozhodnutí o návrhu:

• Minimalizujte, co může server vidět. Ve výchozím prohlížečovém toku zpráv zůstávají prostý text a obalovací klíč ve vašem zařízení. Serverové pečetění Builder, spolupodepisování paktů a výslovně povolená obnova mají odlišné hranice důvěry, které popisujeme níže. Kde uchováváme metadata, omezujeme je na údaje nutné pro zvolenou funkci.
• Učiňte kompromitaci lokálně omezenou. Narušení kterékoli jednotlivé komponenty (našeho serveru, poskytovatele e-mailu, uzlu drand) by nemělo odhalit zapečetěný obsah, který ještě nedosáhl svého času odhalení.
• Učiňte protokol auditovatelným. Zapečetěný artefakt je ověřitelný od začátku do konce pomocí veřejné kryptografie. Nemusíte důvěřovat qub jako službě, abyste ověřili qub jako artefakt.

2. Model hrozeb

2.1 Proti čemu chráníme

• Útočník, který před časem odhalení získá přístup pro čtení k datům uloženým na serveru. Ve výchozím soukromém prohlížečovém toku získá metadata a neprůhledné zabalené bajty, nikoli prostý text ani K. Tato ochrana se nevztahuje na K výslovně uchovaný pro obnovu, na veřejné/nezabalené doručení po příslušném kole drand ani na prostý text dočasně předaný tokům Builder /api/v1/seal a paktů.
• Útočník, který zachytí provoz mezi vaším prohlížečem a naší infrastrukturou. TLS končí na okraji naší CDN; zapečetěné datové úlohy jsou před přenosem již zašifrovány.
• Útočník, který manipuluje s uloženou datovou úlohou. Autentizace vnějšího obalu (je-li přítomen), kanonické dekódování, hash těla, nové odvození qub_id, vazba na kolo a volitelné podpisy způsobí selhání ověření; divák odmítne qub vykreslit.
• Útočník, který se pokusí svázat zfalšovaný e-mail autora s podpisovým klíčem. Atestace e-mailu vyžaduje držení jak soukromého podpisového klíče, tak jednorázového kódu doručeného do e-mailové schránky.
• Kompromitovaný provozovatel majáku drand. Síť drand používá prahové podpisy BLS napříč více nezávislými provozovateli; menšina nemůže zfalšovat podpisy předčasného uvolnění.

2.2 Proti čemu chránit nemůžeme

K našim limitům jsme upřímní. qub se nedokáže bránit proti:

• Kompromitaci vašeho zařízení dříve, než zapečetíte. Lokální keyloggery, škodlivá rozšíření prohlížeče nebo fyzický přístup k odemčenému zařízení mohou zachytit prostý text v okamžiku skládání.
• Kolapsu prahu drand. Více nezávislých organizací provozuje síť drand právě proto, aby to bylo obtížné, ale není to kryptograficky nemožné: pokud se domluví dostatek provozovatelů, mohli by odvodit klíče časového zámku předčasně.
• Vlastnostem uvolnění platné kopie. Veřejný/nezabalený qub lze dešifrovat po jeho kole drand. Soukromý/zabalený qub navíc vyžaduje K; kdokoli, kdo získá uložené bajty i K, jej může po příslušném kole dešifrovat. Záznamy trvalého úložiště a ukotveného logu nelze odvolat pouhým odstraněním z produktového rozhraní qub.
• Globálnímu protivníkovi, který prolomí podkladovou kryptografii (AES-GCM, předpoklady párování BLS12-381, SHA3-256, ML-DSA-65). Pokud tato primitiva padnou, kryptografický ekosystém jako celek má větší problémy.

3. Kryptografie na straně klienta

Ve výchozím prohlížečovém toku zpráv probíhá šifrování obsahu před požadavkem na nahrání. Dvě výslovné cesty se liší: Builder /api/v1/seal záměrně posílá prostý text a volajícím vygenerovaný K Workeru pro pečetění v paměti a příprava/spolupodepisování paktu posílá službě podepsaný strukturovaný pakt, aby mohla dokončit dvoustranný artefakt. Ani jednu výjimku nelze zaměňovat s end-to-end šifrováním prohlížečové cesty.

3.1 Šifrování s časovým zámkem

qub používá tlock — šifrování založené na identitě, klíčované k budoucímu kolu majáku drand. Šifrování probíhá ve vašem prohlížeči pomocí veřejného klíče sítě drand; dešifrovací klíč je sítí drand veřejně uvolněn pouze tehdy, když je dosaženo cílového kola. Nikdo, včetně nás, nemůže dešifrovací klíč zrekonstruovat předem.

Cílíme na řetězec quicknet:

• 3sekundové období kola
• Nezřetězený režim (každé kolo je nezávislé)
• Podpisy BLS12-381 G1
• Hash řetězce 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

Veřejný klíč a čas geneze řetězce quicknet jsou zkompilovány do klienta. Parametry řetězce za běhu nestahujeme, takže škodlivý uzel nemůže nahradit řetězec, který ovládáme.

3.2 Symetrické šifrování

Schéma tlock obaluje obsahový klíč AES-256-GCM. AES-GCM poskytuje autentizované šifrování: jediný překlopený bit v šifrovaném textu způsobí selhání dešifrování, místo aby vytvořil tiše poškozený prostý text.

3.3 Kanonická serializace

Protokolové struktury se serializují pomocí deterministického CBOR (RFC 8949 §4.2, základní požadavky na deterministické kódování). Dvě implementace kódující stejnou logickou strukturu vytvoří identický CBOR. Úplné zapečetěné datové úlohy nejsou deterministické: šifrování tlock i vnějšího obalu používá čerstvou náhodnost. Hash těla se počítá ze surových bajtů těla, zatímco kanonické kódování jednoznačně určuje okolní podepsané a přenosové struktury.

Kodér CBOR jsme napsali ručně jak pro naši klientskou, tak serverovou implementaci, místo abychom spoléhali na obecnou serializační knihovnu — požadavkem je přesnost, nikoli ergonomie, a vlastnostní testy běží v obou implementacích, aby ověřily, že se shodují.

Regresní test tvrdí, že kanonický formát na drátě neobsahuje žádnou bajtovou sekvenci značky qub nad rámec klíče protokolově-primitivního pole qub_id. Formát na drátě je záměrně agnostický vůči značce — jakýkoli vyhovující divák (náš nebo třetí strany) může vykreslit jakýkoli qub z trvalého úložiště, bez ohledu na to, které nasazení jej zapečetilo. Test je nástraha, která brání budoucí změně v náhodném zapečení odkazu na značku do bajtů, které, jednou v trvalém úložišti, nelze přepsat.

3.4 Hašování těla a integrita před odhalením

Každá zapečetěná datová úloha nese hash SHA3-256 surových bajtů svého těla. Hash je svázán do qub_id a při zapnutém podepisování autorství také do vstupu podpisu V2. Divák jej po dešifrování přepočítá a při neshodě datovou úlohu odmítne.

32bajtový identifikátor obsahu qub_id je odvozen ze 108bajtového předobrazu pokrývajícího verzi protokolu, typ obsahu, časová razítka vytvoření a odemčení, volitelné časové razítko výsledku (nebo jeho nulovou zarážku), cílové kolo drand, hash těla a SHA3-256 volitelného názvu normalizovaného do NFC. Brána ani CDN nemůže konzistentně změnit žádné svázané pole a současně projít novým odvozením. Názvy jsou omezeny na 100 kódových bodů NFC a odmítají sdílenou třídu nepřátelských a řídicích kódových bodů (včetně obousměrných přepisů, znaků s nulovou šířkou, bloku tagů, BOM, C0, C1 a DEL).

3.5 Podepisování (ML-DSA-65)

Podepisování autorství používá ML-DSA-65 (FIPS 204), schéma postkvantového podpisu standardizované NIST. Záměrně jsme pro podepisování zvolili postkvantové primitivum, protože zapečetěný obsah je trvalý: podpis, který se ověří dnes, se musí stále ověřovat za desítky let, včetně poté, co se rozsáhlé kvantové počítače stanou praktickými.

Podpisové klíče se generují v prohlížeči. Místní tajemství je před uložením do IndexedDB obaleno neexportovatelným klíčem WebCrypto. Při použití funkce obnovy mezi zařízeními vázané na účet se na server uloží přenosný blok klíče zašifrovaný pomocí AEAD; šifrovaný text tajného klíče je svázán s neměnným ID účtu a služba ověřuje veřejnou obálku, ale nedokáže tajný materiál dešifrovat. Surové bajty soukromého klíče se serveru neposílají. Veřejné klíče a záznamy atestací se ukládají pro ověření a zobrazení identity.

Stejné dešifrování tlock v prohlížeči se uplatní uvnitř embedu qub: když je zapečetěný qub vykreslen prostřednictvím <qub-embed> na stránce třetí strany, dešifrování stále probíhá v iframe embedu v prohlížeči diváka. Embed nemění model důvěry — prostý text nikdy není dešifrován na serveru qub.

3.6 Veřejné přiznání autorství — dobrovolné

Zapečetěné quby nenesou žádný ukazatel v řetězci na svého tvůrce, pokud se tvůrce výslovně nerozhodne jeden připojit. Když zapečetíte qub, referenční aplikace vyšle úložištní značku Author (64znakový hexadecimální otisk vašeho podpisového veřejného klíče) pouze tehdy, když je v kroku výběru data povoleno „Veřejné přiznání autorství“. S přepínačem vypnutým — výchozí stav — se nezapíše žádná značka Author a qub je v trvalém úložišti nepřiznaný: nic v úložišti nespojuje nahrání s vaší přezdívkou, vaším e-mailem nebo vašimi ostatními quby. S přepínačem zapnutým se otisk prostřednictvím atestačního řetězce v §6.3 / §10 přeloží na vaši @přezdívku a odpočítávání pro diváka zobrazí „Zapečetil(a) @{handle}“ před odhalením.

To je záměrná ochrana proti riziku enumerace, které by trvale zapnutá značka Author vytvořila: třetí strana, která se dozví otisk tvůrce, by jinak mohla prohledat trvalé úložiště podle značky a zrekonstruovat celý historický výstup toho tvůrce. Dobrovolné přiznání tento kanál uzavírá — pouze quby, které tvůrce výslovně rozhodne přiznat, se objeví pod otiskem v trvalém úložišti.

Profilová stránka /u/{handle} je kartou ověřené identity — přezdívka, volitelné zobrazované jméno + URL, odznak „ověřený e-mail“ (žádná adresa) a krátká forma kryptografického otisku. Neuvádí quby tvůrce. Návštěvníci, kteří chtějí vidět konkrétní qub od tvůrce, sledují URL doručení toho qubu přímo.

3.7 Vnější šifrovací obal

I poté, co je dešifrování časovým zámkem matematicky možné — jakmile je zveřejněn podpis drand pro svázané kolo — by samotná kanonická vrstva časového zámku umožnila indexeru hromadně dešifrovat dohledatelné quby. Soukromé doručení tento kanál uzavírá další symetrickou vrstvou kolem bajtů šifrovaných časovým zámkem (Protokol §13). Veřejné doručení obal záměrně vynechává, aby mohly bez tajného fragmentu fungovat odkazy pro oznámení, vložení a vyhledávání.

Obal používá AES-256-GCM, autentizovanou šifru standardizovanou NIST, s čerstvým 256bitovým klíčem K generovaným pro každý qub CSPRNG vašeho prohlížeče. K je svázán s qub_id qubu jako autentizovaná dodatečná data, takže klíč z jednoho qubu nelze znovu použít k dešifrování jiného qubu.

K se ve výchozím soukromém prohlížečovém toku nikdy nedostane na naše servery. Je zakódován do fragmentu URL sdíleného odkazu (https://qub.social/c/<tx_id>#<base64url(K)>). Prohlížeče fragmenty URL na servery nepřenášejí — RFC 3986 umisťuje fragment mimo požadavek — takže qub.social, úložištní brány, CDN a monitorování požadavků jsou v tomto toku vůči K slepé. Uložený OuterWrapper je rozpoznatelný strukturovaný CBOR, ale jeho autentizované pole šifrového textu skrývá vnitřní strukturu SealedQub a bez K je nelze otevřít.

Čisté důsledky:

• qub.social nemůže ze samotných uložených dat dešifrovat výchozí soukromá prohlížečová pečetění. Kompromitace datového úložiště získá bez K pouze neprůhledný šifrovaný text. Veřejné quby a quby s povolenou obnovou mají záměrně odlišnou expozici.
• Bez dobrovolně povoleného kanálu obnovy je ztráta fragmentu neopravitelná. Pokud uložíte soukromý odkaz bez fragmentu a nepovolili jste obnovu, qub se prostřednictvím tohoto odkazu stane nečitelným. Tok pečetění z tohoto důvodu zobrazuje výslovné sdělení „uložte tuto URL“.
• Dobrovolná obnova. Když se přihlásíte k odběru e-mailů o životním cyklu tvůrce pro qub A e-mail odpovídá vaší ověřené identitě, přijmeme K s nahráním, uložíme úplnou URL doručení na záznam zapečetěné historie vaší identity a použijeme ji jako odkaz v e-mailu o potvrzení pečetění. Tato výměna — serverový kanál obnovy výměnou za část end-to-end čistoty — se zapojí pouze na výslovné přihlášení a pouze pro ten qub. Výchozím postojem je kryptografické skartování.

Serverový koncový bod Workeru /api/v1/seal (používaný AI agenty a jinými volajícími API) vyžaduje, aby volající vygeneroval K pomocí CSPRNG, uchoval jej lokálně a dodal jej jako wrapper_key_b64url. Worker na této výslovně důvěryhodné cestě nutně vidí v paměti prostý text i K, ale neuchovává ani jedno. Povinný Idempotency-Key brání tomu, aby ztracená odpověď vytvořila druhý účtovaný qub, zatímco K uchovaný volajícím lze zkombinovat s přehranou URL bez fragmentu. To se liší od výchozí cesty v prohlížeči, kde se K nikdy nedostane k Workeru, ledaže tvůrce výslovně povolí obnovu.

4. Přenos a okraj

4.1 TLS

Provoz prohlížeče ke qub je obsluhován přes HTTPS na okraji Cloudflare. Odpovědi nastavují HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). Přesnou vyjednanou verzi TLS a sadu šifer určuje aktivní konfigurace okraje, nikoli aplikační kód. Nezpřístupňujeme samostatně dosažitelný původní server.

4.2 Zabezpečení obsahu

Zkompilovaný klient je obsluhován s přísnými hlavičkami content-type a cache. Skořápka SPA je jediným původem. Nevkládáme skripty třetích stran pro analytiku nebo reklamu. Dva dotykové body třetích stran v produktu jsou oba úzce vymezené: nákupní tok zcela opouští SPA celostránkovým přesměrováním na placení hostované Stripe (https://checkout.stripe.com/…) — UI Stripe se nikdy nespouští v našem původu a my nikdy nevidíme data karty — a tok pečetění načítá widget Turnstile od Cloudflare, alternativu CAPTCHA chránící soukromí, kterou Cloudflare vykresluje uvnitř svého vlastního izolovaného iframe. Ani jedna strana nemůže přečíst zbytek stránky.

Iframe embedu qub (obsluhovaný z qub.social/embed/{tx_id} a načítaný do stránek třetích stran pomocí embed.js) nese vlastní Content-Security-Policy. Jeho seznam povolených zdrojů connect-src je 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh a https://drand.cloudflare.com. Iframe běží s sandbox="allow-scripts allow-top-navigation-by-user-activation" (bez allow-same-origin): hostitelská stránka nemůže číst jeho DOM a iframe nemůže navigovat hostitele bez akce uživatele.

4.3 CORS a rozsah fetch

Prohlížečový klient činí požadavky fetch pouze na:

• Naše vlastní API (api.qub.social a ekvivalenty staging)
• Úložištní brány (pouze pro čtení, pro načítání obalených soukromých nebo nezabalených veřejných bajtů — §3.6)
• Koncové body majáku drand (pouze pro čtení, pro podpisy kol v čase odhalení)

Destinace embedu vynucuje jeho CSP. Zamýšlené destinace hlavní SPA jsou pevně stanoveny v kódu a konfiguraci a ověřují je prohlížečové a integrační kontroly; Subresource Integrity není nástrojem pro řízení síťových destinací.

Embed načítá uložené bajty přes povolené zdroje qub/úložiště, rozbaluje soukromé datové úlohy v prohlížeči pomocí K z fragmentu své URL a načítá podpisy kol pro čas odhalení ze dvou povolených zdrojů drand. Hlavní SPA používá čtyřbodovou záložní sadu v config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh a api3.drand.sh), aby výpadek jednoho endpointu neblokoval odhalení. CSP embedu zakazuje připojení mimo svůj výslovný seznam.

5. Serverová infrastruktura

5.1 Bezserverový okraj

Naše API běží zcela na spravovaném bezserverovém runtime na okraji. Neexistují žádné VM, žádné kontejnery a žádné trvalé serverové procesy, které spravujeme. To dramaticky snižuje útočný povrch, za který jsme odpovědni: neprovozujeme OS, webový server ani aplikační runtime, které musíme záplatovat.

Aplikace samostatného veřejného CORS middleware Access-Control-Allow-Origin: * na následující nastavenou cestu: /embed.js, /embed/v1.js, všechno pod /embed/; /api/v1/telemetry; /api/v1/openapi.json; všechno pod /api/v1/qub/ (včetně bajtů, metadat, důkazu, zapojení, oznámení a push podtras); vše pod /api/v1/log/; veřejné zpracování vyhledávání /api/v1/handle/; a veřejný avatar čte dole /api/v1/identity/avatar/. Jeho povolení k předešlému letu GET, POST, a OPTIONS s Content-Type hlavička požadavku. Tato povrchová vrstva založená na předponách je širší než pouze volání, která embed aktuálně provádí, takže každý handler pod těmito předponami musí nadále uplatňovat vlastní ověřování, autentizaci, limity rychlosti a kontrolu zneužití. Ostatní cesty API si zachovávají CORS politiku qub.social-restricted.

5.2 Úložiště

• Úložiště metadat a koordinace drží záznamy identit a atestací, nároky a platební reference, záznamy API klíčů, položky seznamu zakázaných, relace, stav idempotence, fronty a stav omezení rychlosti či souběhu. Odlišné požadavky na konzistenci používají KV, D1 a Durable Objects namísto jediného univerzálního úložiště.
• Naše objektové úložiště je také vrstvou trvanlivosti. Uchovává přesné zabalené nebo nezabalené bajty qubu potvrzené při nahrání, listy logu transparentnosti a souřadnicově klíčované uzly stromu Merkle, materiál kotev, strukturované protokoly událostí a cache odpovědí či metadat.
• Trvalé veřejné úložiště drží kotvy logu transparentnosti a u cesty T3 nebo odloženého publikování také jednotlivé transakce qubů. Tuto síť neprovozujeme. Soukromé prohlížečové datové úlohy tam zůstávají neprůhledné, pokud držitel nemá také K; veřejné/nezabalené datové úlohy záměrně nemají tuto dodatečnou vrstvu přístupovou přes odkaz.

Výchozí prohlížečový tok zpráv neuchovává prostý text v infrastruktuře qub. Builder /api/v1/seal zpracovává prostý text a K v paměti, ale neuchovává ani jedno. Příprava paktu nutně uchovává podepsaný strukturovaný pakt, dokud není spolupodepsán, stažen nebo nevyprší. Dobrovolná obnova uchovává doručovací oprávnění (úplný odkaz s fragmentem), aby je bylo možné později obnovit. Celou úložištní vrstvu proto nepopisujeme jako „pouze metadata“.

5.3 Tajemství

Tajemství (podpisové peněženky, tokeny poskytovatelů a klíče HMAC) jsou dodávána prostřednictvím vazeb tajemství či prostředí spravovaných platformou, nikoli přes správu zdrojového kódu. Komponenty za běhu dostávají pouze vazby, které potřebují. Postupy rotace a překryvu jsou specifické pro jednotlivé komponenty; netvrdíme, že existuje jediný univerzální automatický nebo auditovaný mechanismus rotace.

5.4 Protokolování a telemetrie

Strukturované protokoly JSON jsou zapisovány při každém požadavku API s korelačním ID zobrazeným v hlavičce odpovědi X-Request-Id. Klientská telemetrie je anonymní — žádný identifikátor zařízení, žádná IP adresa, žádný náhled obsahu. Události jsou bufferovány v paměti a vyprazdňovány na základě nejlepšího úsilí; neúspěšné vyprázdnění je zahozeno, nikoli opakováno. Telemetrie je navržena tak, aby ji bylo možné zakázat na síťové vrstvě bez ovlivnění produktu.

6. Ověřování

6.1 Přihlášení přihlašovacím odkazem

Přihlášení používá jednorázový token podepsaný HMAC doručený do vaší e-mailové schránky. Odkaz je platný 15 minut a jeho uplatnění se atomicky nárokuje, takže souběžné nebo opakované použití bezpečně selže. Po úspěchu dostane prohlížeč neprůhledný soubor cookie __Host-qub_session s atributy Secure, HttpOnly, SameSite=Strict a Path=/.

Relace mají limit nečinnosti 30 dnů a absolutní limit 90 dnů, po 24 hodinách se obměňují a pouze bezprostředně předchozí generaci přijímají během 120sekundové lhůty pro ztracenou odpověď. Citlivé změny účtu vyžadují ověření v předchozích 10 minutách. Tajemství podpisu HMAC je vazbou platformy; samotné čtení metadat nestačí k vytvoření platného tokenu.

6.2 API klíče (úroveň pro vývojáře)

API klíče pro vývojáře používají předponu qub_sk_ pro snadné rozpoznání a vyhledatelnost. Každý klíč:

• Je svázán s účtem, rozsahy oprávnění a volitelným seznamem povolených rozsahů CIDR IP
• V surové podobě se zobrazí jednou; trvalé záznamy uchovávají jeho hash SHA-256, nikoli tajný bearer token
• Lze jej obměnit s jednohodinovým přechodným mapováním, během nějž se starý klíč překládá na náhradu
• Má nezávislý stav kvót a omezení rychlosti
• Není nikdy protokolován celý; protokoly zaznamenávají pouze identifikátor klíče

Administrátorské koncové body pro správu klíčů jsou hlídány za samostatným administrátorským pověřením.

6.3 Atestace e-mailu (podepisování autorství)

Svázání e-mailové adresy s podpisovým klíčem vyžaduje:

1. Držení soukromého podpisového klíče (podepíšete výzvu)
2. Držení e-mailové schránky (zadáte 6místný kód doručený e-mailem)

Kterékoli samostatně je nedostatečné. Odvolání je podepsaný záznam na vašem vlastním účtu a nabývá účinnosti okamžitě; diváci načítající atestaci vidí odvolaný stav a zobrazí jej odpovídajícím způsobem.

7. Platby

Zadávání a zpracování karty probíhá v pokladně hostované společností Stripe. Nikdy nedostáváme čísla karet, data vypršení ani CVC. Na záznamech nároků/API klíčů uchováváme identifikátory zákazníka a předplatného Stripe, stav předplatného a údaje o období, aby bylo možné sladit přístup, obnovení, měření, zrušení a vrácení plateb. Nakládání Stripe s platebními údaji se řídí jeho prohlášeními o soukromí a zabezpečení.

Koncový bod pečetění křížově kontroluje záznam o nároku oproti identifikátoru zařízení a, u přihlášených uživatelů, oproti propojené identitě. Nárok nelze znovu použít napříč zařízeními, aniž by jej uživatel výslovně obnovil prostřednictvím přihlášení přihlašovacím odkazem.

8. Odolnost vůči zneužití

8.1 Detekce botů

Tok pečetění je hlídán alternativou CAPTCHA chránící soukromí, která nepoužívá cookies ke sledování a nesnímá otisky pro reklamu. Neúspěšná výzva je odmítnuta naším okrajovým Workerem dříve, než nastane jakékoli zpracování na straně pečetění.

8.2 Omezování rychlosti

Omezení rychlosti jsou vynucována na několika vrstvách:

• Omezení na IP a na klíč u koncových bodů pečetění, čtení a ověřování
• Omezení na e-mail u požadavků přihlašovacího odkazu (brání zaplavení schránky)
• Omezení na protistranu u e-mailů s pozvánkou k paktu (deset na adresu příjemce za UTC den, primární zmírnění relé spamu; poctivé pakty se k hranici téměř nikdy nepřiblíží)
• Omezení na IP u odesílání telemetrie

Počitadla a atomické nároky jsou podle požadavků endpointu na konzistenci rozděleny mezi KV, Durable Objects a platformní vazby omezení rychlosti. Omezené požadavky vracejí stav 429; endpointy, které dokážou vypočítat interval opakování, zahrnují Retry-After.

8.3 Moderování obsahu

Výchozí trasa pro nahrávání přes prohlížeč nemůže skenovat tělo: přijímá pouze klientem zapečetěný artefakt. Stavebník /api/v1/seal trasa dočasně vidí prostý text a příprava paktu uchovává strukturované podmínky až do dokončení, ale tyto výjimky důvěry nezmění obecnou cestu nahrávání slepou k byteům na skener obsahu. Provozní moderace je seznam blokovaných na vrstvě prohlížeče: qub na seznamu odmítnutých je naším prohlížečem odmítnut bez ohledu na to, zda je uložený obsah stále dostupný. Zařazení na seznam odmítnutých neodstraňuje trvalé bajty, záznamy v transparentním registru ani data v trvalé síti, která již byla publikována.

Hlášení o zneužití jsou omezena rychlostí pomocí jednosměrného hashe IP nahlašovatele; IP pro tento účel neukládáme v čitelné podobě.

9. Dodavatelský řetězec a integrita buildu

9.1 Připnutí toolchainu

Verze kompilátoru a runtime jsou připnuté v konfiguraci repozitáře a závislosti se řeší pomocí commitnutých lockfile. CI kontroluje aktuálnost generovaných souborů a invarianty citlivé na reprodukovatelnost. Netvrdíme však, že každý build z čistého checkoutu je na všech podporovaných počítačích bitově identický.

9.2 Linty a statická analýza

Pracovní prostor povoluje naše nejpřísnější skupiny lintů na úrovni deny. CI zachází s každým varováním — včetně varování o odkazech v dokumentaci — jako se selháním buildu. To je záměrné: přísnost lintů používáme jako nástrahu pro nenápadné regrese.

9.3 Brány CI

Workflow CI pokrývá formátování a přísné linty; testy Rustu, WASM/prohlížeče, Workeru, embedu a API; kontrolu typů; pokrytí kódu; mutační a invariantní kontroly; statickou analýzu závislostí a workflow; kontrolu klíčů, pokrytí, driftu a nepřátelských kódových bodů i18n; aktuálnost generované dokumentace, API a znalostní báze; inventář dokumentů a kontrolu interních odkazů; rozpočty stylů a balíčků a validaci OpenAPI. Některé nákladné mutační úlohy se spouštějí podle plánu, nikoli při každém odeslání.

Jediný povinný souhrnný stav ci zůstane červený, pokud selže kterákoli povinná úloha. Workflow chráněných větví a nasazení používají tento výsledek namísto duplikování menší bezpečnostní brány.

9.4 Mutační testování

Týdenní úloha spouští mutační testování oproti bezpečnostně kritickým čistým modulům: hašování, kanonický CBOR, pečetění, odemykání, newtypy formátu na drátě, validátory protokolových typů a jmenný prostor přezdívek. Mutační testování odpovídá na otázku „zachytí naše sada testů nenápadně nesprávný kód?“ — pokud zmutovaná implementace stále projde všemi testy, víme, že máme mezeru v pokrytí testy, a řešíme ji.

9.5 Git hooky

Lokální hooky (pre-commit, pre-push) zrcadlí brány CI, takže regrese jsou zachyceny dříve, než opustí počítač vývojáře. Hooky jsou instalovány prostřednictvím skriptu repozitáře; v našem workflow nejsou obcházeny a CI je autoritativní branou, pokud jsou přeskočeny.

10. Testování

Bezpečnostně kritický kód nese tři druhy testů:

• Jednotkové testy ověřují očekávané chování na známých vstupech, včetně testovacích vektorů odvozených ze specifikace protokolu.
• Vlastnostní testy generují tisíce libovolných vstupů a tvrdí invarianty: kanonické zpáteční cesty CBOR, zpáteční cesty ověření podpisu, predikáty svázání e-mailu, determinismus potvrzení paktu.
• Mezi-implementační testy ověřují, že se naše klientská a serverová implementace shodují bajt po bajtu na kanonických kódováních. To zachytí divergenci mezi oběma implementacemi dříve, než dosáhne produkce.

11. Hygiena větví a vydání

Větve funkcí posouvají staging pouze prostřednictvím pull requestu Gate 1: povinné ci je zelené, není zde nevyřešený požadavek na změnu ani konflikt sloučení a strom je čistý a zkontrolovaný; sloučení probíhá metodou squash a větev se smaže. main se posouvá pouze pull requestem Gate 2 staging → main, který zachovává historii pomocí merge commitu. Přímé odesílání do větví není postupem vydání.

Nasazení stagingu a produkce se spouští z odpovídajících stavů chráněných větví staging a main po průchodu CI. Kód pull requestu ani přihlašovací údaje forků nedostávají tajemství pro nasazení.

Tajemství používaná v nasazovacích workflow jsou naší platformou CI vymezena na nasazovací prostředí. Nejsou dostupná workflow pull-requestů z forků.

12. Koordinované zveřejnění

Pokud se domníváte, že jste našli bezpečnostní zranitelnost v qub, chceme o ní rychle slyšet a zavazujeme se zpracovat hlášení profesionálně.

• Napište na support@qub.social s předponou předmětu [SECURITY].
• Popište zranitelnost, kroky k reprodukci a jakýkoli proof-of-concept.
• Dejte nám přiměřené okno pro zveřejnění (obvykle 90 dnů), než se vydáte na veřejnost.
• Nepřistupujte k datům, která vám nepatří, nezhoršujte službu pro ostatní uživatele a neuchovávejte data získaná během výzkumu nad rámec toho, co je nezbytné k prokázání problému.

Přijetí potvrdíme do tří pracovních dnů a budeme vás informovat, jak vyšetřujeme. S vaším souhlasem připisujeme nahlašovatele v poznámkách k vydání.

12.1 Bezpečný přístav (Safe Harbor)

Pokud váš výzkum dodržuje výše uvedená pravidla (vyšetřování v dobré víře, žádná újma ostatním uživatelům nebo službě, přiměřené okno pro zveřejnění), nepodnikneme proti vám právní kroky a nepožádáme orgány činné v trestním řízení, aby tak učinily. K vaší práci přistupujeme jako k autorizovanému testování a raději bychom, abyste chybu našli vy, než někdo jiný.

Tento bezpečný přístav se vztahuje na:

• Výzkum na živé službě qub.social (nikoli na testovacích přípravcích, které pro tento účel zveřejňujeme).
• Reverzní inženýrství našich zveřejněných binárních souborů a open-source crate qub-core / qub-app.
• Jakoukoli třídu zranitelnosti — protokol, aplikace, infrastruktura, dodavatelský řetězec — která ovlivňuje qub.

Nevztahuje se na sociální inženýrství vůči členům týmu qub, testy odepření služby ani přístup k datům ostatních uživatelů nad rámec toho, co je potřeba k prokázání problému. Pokud si nejste jisti, zda něco spadá do bezpečného přístavu, zeptejte se nejprve pomocí stejné předpony předmětu [SECURITY].

13. Upřímná omezení

Bezpečnost je praxe, nikoli stav. Některá omezení stojí za přímé pojmenování:

• Jsme malý tým. Hloubka našeho přezkumu neodpovídá specializované funkci bezpečnosti aplikací velké korporace. Kompenzujeme to přísnými automatizovanými branami a minimálním útočným povrchem, ale netvrdíme neomylnost.
• Trvalost našeho úložištního backendu je jednosměrné dveře. Pokud chyba způsobí, že se zapečetěný obsah stane dešifrovatelným dříve, než bylo zamýšleno, nemůžeme to vrátit. K toku pečetění přistupujeme s úměrnou péčí.
• Síť drand je externí závislost. Katastrofické selhání drand by ovlivnilo chování odhalení každého qubu. Sledujeme zdraví drand a máme dokumentaci pro nouzové případy migrace řetězce, pokud by byla potřeba. Pro data odemčení vzdálená více než 2 roky zobrazuje modální okno potvrzení v čase pečetění výslovné sdělení: quby s dlouhým horizontem závisejí na trvanlivosti řetězce drand a budoucí migrace řetězce drand může vyžadovat kroky obnovy k odemčení qubu. Pro data odemčení vzdálená více než 5 let musíte zaškrtnout další pole potvrzující, že jste si toto riziko přečetli a přijímáte jej, než pečetění proběhne.
• Kryptografická primitiva, na která spoléháme, jsou standardizovaná a široce posouzená, ale kryptografie se vyvíjí. Tam, kde máme možnost volby (postkvantové podepisování, autentizované šifrování), vybíráme konzervativnější variantu.

14. Změny této stránky

Závažné změny jsou poznamenány aktualizací data účinnosti v horní části. Tam, kde změna odráží konkrétní zlepšení zabezpečení, ji stručně popíšeme ve veřejném changelogu. Tam, kde změna odráží upřesnění zásad, popíšeme, co se změnilo a proč.

Pro dotazy ohledně čehokoli na této stránce napište na support@qub.social s předponou předmětu [SECURITY].

15. Protokol změn