Seguridad sa qub

Epektibong petsa: 23 Setyembre 2026 Bersyon: 1.1 — pagsusuri ng katumpakan ng pagpapatupad

Para sa mga mananaliksik — mabilisang sanggunian:

• Saan magpapadala ng mga ulat: support@qub.social kasama ang panlapi ng paksa [SECURITY].
• Ano ang isasama: ang kahinaan, mga hakbang upang ulitin, at anumang patunay-ng-konsepto.
• Ang aming tugon: Kinikilala namin ang pagtanggap sa loob ng 3 araw ng negosyo at layunin naming ipadala ang isang pagkukumpuni sa loob ng 90 araw.
• Ligtas na Daungan: hindi namin isusulong ang legal na aksyon laban sa pananaliksik na may mabuting intensyon na sumusunod sa mga patakaran sa §12 (huwag kumuha ng data na hindi sa iyo, huwag pahinain ang serbisyo, huwag panatilihin ang nakuha na data lampas sa kinakailangan upang ipakita ang isyu, bigyan kami ng makatwirang panahon para sa paglalahad).

Ang buong detalye ay nasa §12 (Pinagsamang Pagbubunyag).

Sino Kami

Ang qub.social ay pinapatakbo ng VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. Ang mga tukoy sa "qub", "kami", "amin", at "atin" ay tumutukoy sa entity na iyon.

Security contact: support@qub.social gamit ang subject prefix na [SECURITY].

1. Aming Pananaw

Ang qub ay imprastruktura ng tiwala. Walang halaga ang produkto kung hindi ito secure, kaya ang seguridad ay hindi isang feature — ito ang substrate. Inilalarawan ng pahinang ito, sa konkretong mga termino, kung paano namin pinangangalagaan ang aming stack, ang iyong data, at ang integridad ng isinelyong nilalaman.

Ang halaga ng isang napatunayan na pansamantalang pangako ay lumalaki habang mas maraming bahagi ng internet ang nagiging machine-generated. Ang isang napatunayang transaksyon sa imbakan o transparency-log anchor ay maaaring magpatunay na ang ciphertext ay umiiral hindi lalampas sa oras ng kanyang block; ang selyadong artifact ay hiwalay na nagpapatunay ng integridad ng nilalaman, drand-round binding, at anumang lagda ng may-akda. Ang pagpapanatiling hiwalay ng mga pahayag na iyon ang pamantayan na sinusunod ng pahinang ito.

Hindi namin hinihiling sa iyo na magtiwala sa amin. Idinisenyo namin upang ang tiwalang kinakailangan sa amin ay sa pinakamaliit na maaari, at kung saan kinakailangan ang tiwala ay ipinapaliwanag namin nang eksakto kung ano ang pinagkakatiwalaan at bakit.

Tatlong prinsipyo ang nagtutulak sa bawat design decision:

• Bawasan kung ano ang makikita ng server. Sa default na daloy ng mensahe ng browser, nananatili sa iyong aparato ang plaintext at ang wrapper key. Ang server-side na pagtatalaga ng Builder, pag-pirma sa kasunduan, at tahasang pinagana na pag-recover ay may iba't ibang hangganan ng tiwala, na inilalahad sa ibaba. Kung saan namin hinahawakan ang metadata, nililimitahan namin ito sa kung ano ang kailangan ng napiling tampok.
• Gawin ang kompromiso na lokal na nakapaloob. Ang paglabag sa kahit isang bahagi (ang aming server, ang email provider, isang drand node) ay hindi dapat magbunyag ng selyadong nilalaman na hindi pa nakarating sa oras ng pagpapahayag nito.
• Gawing ma-audit ang protocol. Ang selyadong artefact ay maaaring beripikahin mula simula hanggang katapusan gamit ang pampublikong kriptograpiya. Hindi mo kailangan magtiwala qub ang serbisyo para beripikahin ang isang qub ang artepakto.

2. Threat Model

2.1 Ano ang Pinoprotektahan Namin

• Isang umaatake na nakakakuha ng karapatang magbasa sa aming naka-imbak na data sa server bago ang oras ng pagpapakita. Sa default na pribadong daloy ng browser, nakakakuha sila ng metadata at opaque na balot na bytes, hindi plaintext o K. Ang proteksyon na ito ay hindi naaangkop sa isang K na tahasang pinananatili para sa pagbawi, sa pampubliko/o direktang paghahatid pagkatapos ng drand round nito, o sa plaintext na pansamantalang ibinibigay sa Builder /api/v1/seal at mga workflow ng kasunduan.
• Isang umaatake na pumipigil sa trapiko sa pagitan ng iyong browser at ng aming imprastruktura. Nagtatapos ang TLS sa aming CDN edge; ang mga naka-seal na payload ay naka-encrypt na bago ang paglipat.
• Isang umaatake na nagmamanipula ng nakaimbak na payload. Pagpapatunay ng panlabas na pambalot (kung naroroon), pamantayang dekoding, ang hash ng katawan, qub_id Ang muling pag-derive, round binding, at opsyonal na mga pirma ay nagiging sanhi na mabigo ang beripikasyon sa pagsasamantala; tumatanggi ang viewer na i-render ito.
• Isang umaatake na sumusubok na itali ang pekeng email ng may-akda sa isang signing key. Ang pagpapatunay sa email ay nangangailangan ng pagkakaroon ng parehong pribadong susi sa paglagda at isang beses na code na ipinadala sa inbox ng email.
• Isang drand beacon operator na nakompromiso. Ang drand network ay gumagamit ng threshold BLS signatures sa maraming independiyenteng operator; ang isang minorya ay hindi makapagpalsipika ng mga maagang release na pirma.

2.2 Ano ang Hindi Namin Mapoprotektahan

Tapat kami tungkol sa aming mga limitasyon. Ang qub ay hindi makakaprotekta laban sa:

• Isang kompromiso ng iyong aparato bago mo ito selyuhan. Ang mga lokal na keylogger, malisyosong extension ng browser, o pisikal na pag-access sa isang unlocked na device ay maaaring makuha ang plaintext sa punto ng pagsulat.
• Isang pagbagsak ng drand threshold. Maraming independiyenteng organisasyon ang nagpapatakbo ng drand network partikular upang maging mahirap ito, ngunit hindi ito kriptograpikong imposible: kung maraming operator ang magtatagumpay na magtulungan, maaari nilang makuha ang mga timelock key nang maaga.
• Ang mga katangian ng pagpapalaya ng isang wastong kopya. Ang pampubliko/napakaliit na qub ay nagiging decryptable pagkatapos ng kanyang drand round. Ang pribado/naka-wrap na qub ay nangangailangan din ng K; sinumang makakakuha ng parehong naka-imbak na bytes at K ay maaaring mag-decrypt pagkatapos ng round. Ang mga talaan ng permanent-storage at anchored-log ay hindi basta maibabalik sa pamamagitan lamang ng pagtanggal sa kanila mula sa ibabaw ng produkto ng qub.
• Isang pandaigdigang kalaban na sumisira sa pangunahing kriptograpiya (AES-GCM, mga palagay sa BLS12-381 na pagpapares, SHA3-256, ML-DSA-65). Kung bumagsak ang mga primitif na ito, mas malalaking problema ang kakaharapin ng kabuuang ekosistema ng kriptograpiya.

3. Client-Side Cryptography

Sa default na daloy ng mensahe ng browser, nangyayari ang encryption ng nilalaman bago ang upload na kahilingan. Dalawang malinaw na landas ang magkakaiba: Builder /api/v1/seal sinasadyang ipinapadala ang plaintext at K na ginawa ng tumatawag sa Worker para sa in-memory na pag-seal, at ang pact staging/co-signing ay ipinapadala ang pinirmahang naka-istrukturang pact sa serbisyo upang makumpleto nito ang bilateral na artifact. Walang alinman sa mga eksepsyon na ito ang dapat ipagkamali sa end-to-end encryption ng browser-path.

3.1 Timelock Encryption

Gumagamit ang qub ng tlock — identity-based encryption na naka-key sa hinaharap na drand beacon round. Nagaganap ang encryption sa iyong browser gamit ang public key ng drand network; ang decryption key ay inilalabas pampubliko ng drand network lamang kapag naabot ang target round. Walang sinuman, kabilang kami, ang maaaring magbuo muli ng decryption key bago ang oras.

Tina-target namin ang quicknet chain:

• 3-segundong round period
• Unchained mode (bawat round ay independyente)
• BLS12-381 G1 signatures
• Chain hash 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

Ang public key at genesis time ng quicknet chain ay naka-compile sa client. Hindi kami kumukuha ng chain parameters sa runtime, kaya hindi maaaring magpalit ang isang malisyosong node ng chain na kontrolado namin.

3.2 Symmetric Encryption

Bina-wrap ng tlock scheme ang isang AES-256-GCM content key. Nagbibigay ang AES-GCM ng authenticated encryption: ang isang bit na napalitan sa ciphertext ay nagdudulot ng pagkabigo sa decryption, sa halip na maglabas ng tahimik na corrupted plaintext.

3.3 Canonical Serialisation

Ang mga istruktura ng protocol ay sinusunod sa serialisado gamit ang deterministic na CBOR (RFC 8949 §4.2 core deterministic encoding). Dalawang implementasyon na nag-eencode ng parehong lohikal na istruktura ay nagbubunga ng magkaparehong CBOR. Kumpletong selyadong mga payload ay hindi deterministiko: ang tlock at panlabas na wrapper na encryption ay gumagamit ng bagong randomness. Ang body hash ay kinukwenta sa mga raw na body bytes, habang ang canonical encoding ay ginagawang malinaw ang kalapit na signed/wire na mga istruktura.

Isinulat namin ang CBOR encoder nang manu-mano para sa parehong client at server implementations sa halip na umasa sa generic serialisation library — ang kinakailangan ay eksaktitud, hindi ergonomics, at ang mga property test ay tumatakbo sa parehong implementasyon upang i-verify na sumasang-ayon sila.

Ang regression test ay nagpapahayag na ang canonical wire format ay walang qub-brand byte sequence lampas sa protocol-primitive qub_id field key. Ang wire format ay sinadyang brand-agnostic — anumang sumusunod na mambabasa (aming o ng third party) ay maaaring mag-render ng anumang qub mula sa permanenteng storage, anuman ang deployment na nag-seal. Ang test ay isang tripwire na pumipigil sa hinaharap na pagbabago na hindi sinasadyang magluto ng brand reference sa byte na, kapag nasa permanenteng storage na, ay hindi na maaaring isulat muli.

3.4 Body Hashing at Pre-Reveal Integrity

Bawat selyadong payload ay naglalaman ng SHA3-256 na hash ng hilaw nitong mga byte ng katawan. Ang hash ay nakakabit sa qub_id at, kapag pinagana ang pagpirma ng may-akda, sa input ng pirma ng V2. Muling kinakalkula ito ng isang manonood pagkatapos ng decryption at tinatanggihan ang hindi pagtutugma.

Ang 32-byte na tagakakilanlan ng nilalaman qub_id ay nagmula sa isang 108-byte na preimage na sumasaklaw sa bersyon ng protocol, uri ng nilalaman, nilikhang at i-unlock na timestamp, opsyonal na outcome timestamp (o ang zero sentinel nito), target na drand round, body hash, at SHA3-256 ng opsyonal na NFC-normalised na pamagat. Hindi maaaring baguhin ng isang gateway o CDN ang anumang naka-bind na field nang pare-pareho at mapasailalim pa rin sa re-derivation. Ang mga pamagat ay limitado sa 100 NFC code points at tinatanggihan para sa shared hostile/control-codepoint class (kasama ang bidi overrides, zero-width na mga karakter, ang tag block, BOM, C0, C1, at DEL).

3.5 Signing (ML-DSA-65)

Gumagamit ang authorship signing ng ML-DSA-65 (FIPS 204), isang NIST-standardized post-quantum signature scheme. Sinadya naming pumili ng post-quantum primitive para sa signing dahil permanente ang isinelyong nilalaman: ang signature na nag-verify ngayon ay dapat pa rin nag-verify pagkalipas ng mga dekada, kabilang pagkatapos maging praktikal ang large-scale quantum computers.

Ang mga signing key ay nililikha sa browser. Ang lokal na sikreto ay inilalagay sa ilalim ng isang non-extractable na WebCrypto key bago i-imbak sa IndexedDB. Kung ginagamit ang account-scoped cross-device recovery feature, isang AEAD-encrypted na portable key blob ang iniimbak sa server; ang ciphertext ng secret key nito ay naka-bind sa immutable na account id, at sinusuri ng serbisyo ang public envelope ngunit hindi maaaring i-decrypt ang secret na materyal. Ang raw private-key bytes ay hindi ipinapadala sa server. Ang mga public key at tala ng atestasyon ay iniimbak para sa bersipikasyon at pagpapakita ng identidad.

Ang parehong in-browser tlock decryption ay naaangkop sa loob ng qub embed: kapag ang isang isinelyong qub ay nire-render sa pamamagitan ng <qub-embed> sa third-party page, ang decryption ay nangyayari pa rin sa embed iframe sa browser ng mambabasa. Hindi binabago ng embed ang trust model — ang plaintext ay hindi kailanman na-decrypt sa qub server.

3.6 Public Attribution — Opt-In

Ang isinelyong qubs ay hindi nagdadala ng on-chain pointer sa kanilang tagalikha maliban kung malinaw na piliin ng tagalikha na magkabit ng isa. Kapag nag-seselyo ka ng qub, naglalabas ang reference app ng Author storage tag (isang 64-char hex fingerprint ng iyong signing public key) kapag ang "Public attribution" ay enabled sa date-picker step. Sa toggle na off — ang default — walang Author tag na isinulat at ang qub ay hindi attributed sa permanenteng storage: walang anuman sa storage ang nag-link ng upload sa iyong handle, iyong email, o iyong iba pang qub. Sa toggle na on, ang fingerprint ay tumutugma sa iyong @handle sa pamamagitan ng attestation chain sa §6.3 / §10 at ipinapakita ng viewer countdown ang "Isinelyo ni @{handle}" bago mag-reveal.

Ito ay isang sadyang guard laban sa enumeration risk na malilikha ng always-on Author tag: ang isang third party na natutuhan ang fingerprint ng isang tagalikha ay maaaring maghanap sa permanenteng storage sa pamamagitan ng tag at muling buuin ang buong historical output ng tagalikhang iyon. Sinasara ng opt-in attribution ang channel na iyon — tanging ang mga qub na malinaw na pinili ng tagalikha na i-attribute ang lalabas sa ilalim ng fingerprint sa permanenteng storage.

Ang /u/{handle} profile page ay isang verified-identity card — handle, opsyonal na display name + URL, "verified email" pill (walang address), at ang maikling form ng cryptographic fingerprint. Hindi nito inililista ang mga qub ng tagalikha. Ang mga bisitang gustong makita ang partikular na qub mula sa tagalikha ay sumusunod sa delivery URL ng qub na iyon nang direkta.

3.7 Outer Encryption Wrapper

Kahit na pagkatapos ay matematikal na posible ang timelock decryption—kapag nai-publish na ang drand signature para sa bound round—ang karaniwang timelock layer lamang ay magpapahintulot sa isang indexer na mag-bulk-decrypt ng mga discoverable qubs. Pinipigilan ng private delivery ang channel na iyon sa pamamagitan ng karagdagang symmetric layer sa paligid ng timelock-encrypted na mga bytes (Protocol §13). Sinasadya namang hindi isama ng public delivery ang wrapper upang ang notification, embed, at discovery links ay gumana nang walang secret fragment.

Ang wrapper ay gumagamit ng AES-256-GCM, isang NIST-standardized authenticated cipher, na may fresh 256-bit key K na nabuo kada qub ng CSPRNG ng iyong browser. Nakatali ang K sa qub_id ng qub bilang authenticated additional data, kaya hindi maaaring magamit muli ang key mula sa isang qub upang mag-decrypt ng ibang qub.

Hindi nararating ng K ang aming mga server sa default na pribadong daloy ng browser. Ito ay naka-encode sa fragment ng URL ng link na maibabahagi (https://qub.social/c/<tx_id>#<base64url(K)>). Hindi ipinapadala ng mga browser ang mga fragment ng URL sa mga server—iniwan ng RFC 3986 ang fragment sa labas ng kahilingan—kaya ang qub.social, mga storage gateway, CDN, at pagmamanman ng kahilingan ay hindi nakikita ang K sa daloy na iyon. Ang nakaimbak OuterWrapper ay nakikilala na nakaayos na CBOR, ngunit ang na-verify na ciphertext na patlang nito ay nagtatago ng loob SealedQub istruktura at hindi maaaring buksan nang walang K.

Mga net consequences:

• Hindi mai-decrypt ng qub.social ang mga default na privacy seal ng browser batay lamang sa nakaimbak na data. Ang paglabag sa imbakan ng datos ay umaabot sa hindi malinaw na ciphertext nang walang K. Ang mga pampublikong qubs at mga qubs na may recovery-enabled ay may magkaibang antas ng pagkakalantad ayon sa disenyo.
• Ang pagkawala ng piraso ay hindi na mababawi nang walang piniling recovery channel. Kung ise-save mo ang isang pribadong link nang walang fragment at hindi pinagana ang recovery, magiging hindi mababasa ang qub sa pamamagitan ng link na iyon. Ang seal flow ay nagpapakita ng isang tahasang pahayag na "i-save ang URL na ito" dahil sa kadahilanang ito.
• Pagbawi na kusang-loob. Kapag pumili ka sa mga email ng lifecycle ng creator para sa isang qub AT ang email ay tumutugma sa iyong na-verify na pagkakakilanlan, tinatanggap namin ang K kasama ang upload, iniimbak ang buong URL ng paghahatid sa naka-seal na talaan ng kasaysayan ng iyong pagkakakilanlan, at ginagamit ito bilang link sa email ng kumpirmasyon ng selyo. Ang palitang ito — isang server-side recovery channel kapalit ng ilang end-to-end na kalinisan — ay nagaganap lamang sa tuwirang pagpili at para lamang sa qub na iyon. Ang default na posisyon ay crypto-shredding.

Ang server-side /api/v1/seal endpoint ng Worker (na ginagamit ng AI agents at iba pang API caller) ay nangangailangan na ang caller ang bumuo ng K gamit ang isang CSPRNG, panatilihin ito nang lokal, at ibigay ito bilang wrapper_key_b64url. Kinakailangang nakikita ng Worker ang parehong plaintext at K sa memorya sa tahasang pinagkakatiwalaang path na ito, ngunit wala itong pinapanatili sa dalawa. Ang isang sapilitang Idempotency-Key ay pumipigil sa isang nawalang response na makalikha ng pangalawang qub na sinisingil, habang ang napanatili-ng-caller na K ay maaaring pagsamahin sa na-replay na URL na walang fragment. Naiiba ito sa default na browser path, kung saan ang K ay hindi umaabot sa Worker maliban kung tahasang paganahin ng tagalikha ang recovery.

4. Transport at Edge

4.1 TLS

Ang trapiko ng browser papunta sa qub ay hinahatid sa HTTPS sa Cloudflare edge. Ang mga tugon ay nagtatakda ng HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). Ang eksaktong na-negotiate na bersyon ng TLS at cipher suite ay pinamamahalaan ng aktibong edge configuration kaysa ipahayag ng application code. Hindi namin inilalantad ang hiwalay na maaring ma-access na origin server.

4.2 Content Security

Ang compiled client ay inihahatid sa mahigpit na content-type at cache headers. Ang SPA shell ay isang origin. Hindi kami nag-embed ng third-party scripts para sa analytics o advertising. Ang dalawang third-party touchpoint sa produkto ay parehong makitid na saklaw: ang purchase flow ay umaalis ng SPA nang buo sa full-page redirect sa Stripe-hosted checkout (https://checkout.stripe.com/…) — ang UI ng Stripe ay hindi kailanman tumatakbo sa aming origin at hindi kami kailanman nakakakita ng card data — at ang seal flow ay nag-lo-load ng Turnstile widget ng Cloudflare, isang privacy-preserving CAPTCHA alternative na nire-render ng Cloudflare sa loob ng sariling sandboxed iframe. Walang panig ang nakakabasa ng natitirang bahagi ng pahina.

Ang qub i-embed ang iframe (hinihiling mula sa qub.social/embed/{tx_id} at inilagay sa mga third-party na site ng embed.js) may dala ang sarili nitong Content-Security-Policy. Ang connect-src pinapayagang listahan ay 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh, at https://drand.cloudflare.com. Ang iframe ay tumatakbo kasama sandbox="allow-scripts allow-top-navigation-by-user-activation" (hindi allow-same-origin): hindi mabasa ng host page ang kanyang DOM, at hindi nito maaaring i-navigate ang host maliban na lang pagkatapos ng aksyon ng gumagamit.

4.3 CORS at Fetch Scope

Gumagawa lang ang browser client ng fetch requests sa:

• Ang sariling API namin (api.qub.social at mga katumbas ng pagtatanghal)
• Mga storage gateway (read-only, para sa wrapped-private o bare-public na retrieval ng byte — §3.6)
• mga endpoint ng drand beacon (pang-basa lamang, para sa mga pirma ng reveal-time round)

Ang mga destinasyon ng embed ay pinapatupad ng CSP nito. Ang mga itinakdang destinasyon ng pangunahing SPA ay nakapirmi sa code at konfigurasyon at sinusuri ng browser at mga pagsasamang tsek; Ang Subresource Integrity ay hindi kontrol sa destinasyon ng network.

Kinukuha ng embed ang naka-imbak na bytes sa pamamagitan ng allowlisted na qub/storage origins, binubuksan ang mga pribadong payload sa browser gamit ang K mula sa fragment ng URL nito, at kinukuha ang reveal-time na mga round signature mula sa dalawang allowlisted na drand origins. Ginagamit ng pangunahing SPA ang apat na-endpoint na fallback set sa config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh, at api3.drand.sh) kaya't ang pagkakaroon ng outage sa isang endpoint ay hindi humahadlang sa reveal. Ang embed CSP ay tumatanggi ng mga koneksyon sa labas ng malinaw na listahan nito.

5. Server-Side Infrastructure

5.1 Serverless Edge

Tumatakbo ang aming API nang buo sa pinamamahalaang serverless runtime sa edge. Walang VM, walang container, at walang persistent server processes na inaadmin namin. Pinapababa nito ang attack surface na responsibilidad namin: hindi kami nagpapatakbo ng OS, web server, o application runtime na dapat naming i-patch.

Isang hiwalay na pampublikong CORS middleware ang ipinapatupad Access-Control-Allow-Origin: * sa sumusunod na ipinatupad na itinakdang landas: /embed.js, /embed/v1.js, lahat sa ilalim /embed/; /api/v1/telemetry; /api/v1/openapi.json; lahat sa ilalim /api/v1/qub/ (kasama ang bytes, metadata, patunay, pakikilahok, abisuhin, at push subroutes); lahat ng nasa ilalim /api/v1/log/; pampublikong panghawak ng mga paghahanap sa ilalim /api/v1/handle/; at ang pampublikong avatar ay nagbabasa sa ilalim /api/v1/identity/avatar/. Ang mga permiso nito para sa preflight GET, POST, at OPTIONS kasama ang Content-Type header ng kahilingan. Ang ibabaw na batay sa prefix na ito ay mas malawak kaysa sa mga tawag lamang na kasalukuyang ginagawa ng embed, kaya bawat handler sa ilalim ng mga prefix na iyon ay kailangang ipagpatuloy ang pagpapatupad ng sariling pagpapatunay, pagpapatotoo, limitasyon sa rate, at mga kontrol sa pang-aabuso. Ang iba pang mga landas ng API ay nananatili sa patakaran ng qub.social-restricted CORS.

5.2 Storage

• Mga tindahan ng metadata at koordinasyon hawakan ang mga talaan ng pagkakakilanlan at pagpapatunay, mga karapatan at sanggunian sa pagsingil, mga talaan ng API-key, mga entry sa denylist, mga session, estado ng idempotency, mga queue, at estado ng rate-limit / concurrency. Iba't ibang pangangailangan sa consistency ang gumagamit ng KV, D1, at Durable Objects sa halip na isang unibersal na imbakan.
• Ang aming imbakan ng bagay ay isang matibay na substrate din. Pinapanatili nito ang eksaktong nakabalot o walang pambalot na qub bytes na kinikilala ng upload, mga transparency-log leaves at coordinate-keyed Merkle nodes, anchor material, mga structured event logs, at mga response/metadata caches.
• Pangmatagalang pampublikong imbakan humahawak ng mga anchoring ng transparency-log at, para sa T3 na path o deferred publication, mga indibidwal na transaksiyon ng qub. Hindi namin pinapatakbo ang network na iyon. Nanatiling opaque ang mga private browser payloads doon maliban kung ang humahawak ay mayroon ding K; ang mga pampubliko/o naked na payloads ay sadyang walang karagdagang layer ng kakayahan sa link.

Ang default na daloy ng mensahe ng browser ay hindi nag-iingat ng plain text sa qub infrastructure. Tagabuo /api/v1/seal pinangangasiwaan ang plaintext at K sa memorya ngunit wala ni isa ang pinapanatili. Ang Pact staging ay kinakailangang nag-iimbak ng pinirmahang nakaayos na pact hanggang ito ay mapirmaan nang sabay, bawiin, o mag-expire. Ang opsyonal na pag-recover ay nag-iimbak ng kakayahan sa paghahatid (ang buong link na may fragment) upang ito ay maaaring ma-recover sa kalaunan. Kaya't hindi namin inilalarawan ang buong storage tier bilang “metadata-only.”

5.3 Secrets

Ang mga lihim (pag-sign ng wallets, provider tokens, at HMAC keys) ay ipinamamahagi sa pamamagitan ng platform secret/environment bindings sa halip na sa source control. Ang mga runtime component ay tumatanggap lamang ng mga binding na kailangan nila. Ang mga pamamaraan ng rotation at overlap ay espesipiko sa bawat component; hindi namin inaangkin ang isang iisang unibersal na awtomatiko o na-audit na mekanismo ng rotation.

5.4 Logging at Telemetry

Ang structured JSON logs ay isinusulat sa bawat API request na may correlation ID na inilalabas sa X-Request-Id response header. Anonymous ang client telemetry — walang device identifier, walang IP address, walang content preview. Naka-buffer ang mga event sa memory at iniisahod sa best-effort basis; ang nabigong flush ay itinatapon, hindi muling sinusubukan. Ang telemetry ay dinisenyo upang maaaring i-disable sa network layer nang hindi naaapektuhan ang produkto.

6. Authentication

6.1 Magic-Link Sign-In

Ang pag-sign-in ay gumagamit ng isang beses lang gamitin, HMAC-na-napirmahang token na ipinapadala sa iyong email inbox. Ang link ay may bisa sa loob ng 15 minuto at ang pagtubos ay agarang inaangkin kaya ang sabay-sabay o paulit-ulit na paggamit ay nabibigo. Sa tagumpay, tumatanggap ang browser ng isang opaque __Host-qub_session cookie na may Secure, HttpOnly, SameSite=Strict, at Path=/ mga katangian.

Ang mga sesyon ay may 30-araw na limitasyon sa pagiging walang ginagawa at 90-araw na ganap na limitasyon, umiikot pagkatapos ng 24 na oras, at tinatanggap lamang ang agarang nakaraang henerasyon para sa 120-segundong grace period ng nawalang tugon. Ang mga sensitibong pagbabago sa account ay nangangailangan ng pagpapatunay sa loob ng nakaraang 10 minuto. Ang HMAC signing secret ay isang platform na pagtali; ang pagbabasa lamang ng metadata ay hindi sa kanyang sarili naglilikha ng isang wastong token.

6.2 API Keys (Developer Tier)

Gumagamit ang mga developer API key ng prefix na qub_sk_ para sa madaling pagkilala at grepability. Ang bawat key:

• Nakakabit sa isang account, mga saklaw, at opsyonal na IP CIDR allowlist
• Ipinapakita sa hilaw na anyo nang isang beses; ang mga persistenteng tala ay nagtatago ng SHA-256 hash nito, hindi ang lihim ng taglay nito
• Maaaring i-ikot gamit ang isang oras na grace mapping kung saan ang lumang susi ay nagreresolba sa kapalit
• May sarili nitong quota at estado ng rate-limit
• Hindi kailanman nai-log nang buo; ang mga log ay nagtatala lamang ng pangunahing pagkakakilanlan

Ang admin key-management endpoints ay naka-gate sa likod ng hiwalay na admin credential.

6.3 Email Attestation (Authorship Signing)

Ang pag-bind ng email address sa signing key ay nangangailangan ng:

1. Pag-aari ng private signing key (pinipirmahan mo ang isang challenge)
2. Pag-aari ng email inbox (ipinapasok mo ang 6-digit code na inihahatid sa email)

Hindi sapat ang alinman lamang. Ang revocation ay signed record sa iyong sariling account at agad na nagkakabisa; ang mga mambabasang kumukuha ng attestation ay nakikita ang revoked state at nagpapakita nang naaayon.

7. Mga Pagbabayad

Ang pagpasok at pagproseso ng card ay isinasagawa sa loob ng Stripe-hosted checkout. Hindi namin natatanggap ang mga numero ng card, petsa ng pag-expire, o CVC. Nagtatago kami ng mga identifier ng Stripe customer at subscription, estado ng subscription, at datos ng panahon sa mga tala ng entitlement/API-key upang maayos ang access, pag-renew, pag-meter, pagkansela, at refund. Ang mga pahayag tungkol sa privacy at seguridad ng Stripe ang namamahala sa paghawak nito ng mga datos ng pagbabayad.

Ang seal endpoint ay cross-check ang entitlement record laban sa device identifier at, para sa mga naka-sign in na user, laban sa naka-link na identity. Ang entitlement ay hindi maaaring magamit muli sa iba't ibang device nang walang malinaw na pag-restore sa pamamagitan ng magic-link sign-in.

8. Pagkalaban sa Pang-aabuso

8.1 Bot Detection

Naka-gate ang seal flow ng privacy-preserving CAPTCHA alternative na hindi gumagamit ng cookies para sa tracking at hindi nagfi-fingerprint para sa advertising. Ang nabigong challenge ay tinatanggihan ng aming edge Worker bago ang anumang seal-side processing.

8.2 Rate Limiting

Ipinapatupad ang rate limits sa ilang layer:

• Mga per-IP at per-key limits sa seal, read, at auth endpoints
• Per-email limits sa mga magic-link request (pumipigil sa mailbox flooding)
• Per-counter-party limits sa pact invite emails (sampu kada recipient address kada UTC day, ang pangunahing spam-relay mitigation; halos hindi naaabutan ng tapat na kasunduan ang cap)
• Per-IP limits sa telemetry submission

Ang mga counter at atomic na claim ay ipinamamahagi sa KV, Durable Objects, at platform rate-limit bindings ayon sa mga kinakailangan sa pagkakapareho ng endpoint. Ang mga request na limitado ang rate ay nagbabalik ng 429; ang mga endpoint na kayang kalkulahin ang isang retry window ay kinabibilangan ng Retry-After.

8.3 Content Moderation

Ang default na ruta ng pag-upload sa browser ay hindi makakapagsuri sa katawan: tumatanggap lamang ito ng client-sealed na artifact. Ang Builder /api/v1/seal nakikita ng ruta ang plaintext pansamantala, at ang pact staging ay humahawak ng mga istrakturang termino hanggang sa finalisation, ngunit ang mga trust exception na iyon ay hindi ginagawang content scanner ang pangkalahatang byte-blind upload path. Ang operational moderation ay isang blacklist sa layer ng viewer: ang isang denylisted na qub ay tinatanggihan ng ating viewer kahit na nananatiling naaabot ang nakaimbak na payload. Ang pag-denylist ay hindi nag-aalis ng matitibay na byte, mga entry sa transparency-log, o permanenteng datos sa network na naisapubliko na.

Ang mga ulat ng pang-aabuso ay rate-limited gamit ang one-way hash ng IP ng nagre-ulat; hindi kami nag-iimbak ng IP sa clear para sa layuning ito.

9. Supply Chain at Build Integrity

9.1 Toolchain Pinning

Ang mga bersyon ng compiler at runtime ay nakatakda sa configuration ng repositoryo at ang mga dependencies ay nalulutas sa pamamagitan ng mga committed na lockfile. Sinusuri ng CI ang pagiging bago ng mga generated-file at mga invariant na sensitibo sa reproducibility. Hindi namin ipinapahayag ang mas matibay na pahayag na ang bawat malinis na build ay bit-for-bit na magkapareho sa lahat ng suportadong makina.

9.2 Lints at Static Analysis

Pinapayagan ng workspace ang aming pinakamahigpit na lint groups sa deny level. Tinatrato ng CI ang bawat warning — kabilang ang documentation-link warnings — bilang build failure. Sadya ito: ginagamit namin ang lint strictness bilang tripwire para sa mga banayad na regression.

9.3 CI Gates

Saklaw ng CI workflow ang pag-format at mahigpit na lint; mga pagsusulit sa Rust, WASM/browser, Worker, embed, at API; type checking; coverage ng code; mutation/invariant checks; dependency at workflow static analysis; i18n keys, coverage, drift, at hostile-codepoint checks; pagiging bago ng generated-doc/API/knowledge-base; pagsusuri ng imbentaryo ng dokumento at internal na link; stylesheet at bundle budgets; at OpenAPI validation. Ang ilang mahal na mutation jobs ay naka-schedule sa halip na patakbuhin sa bawat push.

Isang kinakailangan ci Nanatiling pula ang roll-up kung anumang kinakailangang trabaho ay nabigo. Ang mga protected-branch at deploy na workflow ay gumagamit ng resulta na iyon sa halip na ulitin ang mas maliit na security gate.

9.4 Mutation Testing

Ang weekly job ay nagpapatakbo ng mutation testing laban sa security-critical pure modules: hashing, canonical CBOR, seal, unlock, wire-format newtypes, protocol type validators, at handle namespace. Sumasagot ang mutation testing sa "nahuhuli ba ng aming test suite ang banayad na maling code?" — kung ang mutated implementation ay pumasa pa rin sa lahat ng test, alam naming may test-coverage gap at tinutugunan ito.

9.5 Git Hooks

Ang mga lokal na hook (pre-commit, pre-push) ay sumasalamin sa CI gates kaya nahuhuli ang mga regression bago sila umalis ng makina ng developer. Ang mga hook ay inilalagay sa pamamagitan ng repo script; hindi sila lalampasan sa aming workflow at ang CI ang authoritative gate kung sila ay lalaktawan.

10. Pagsubok

Ang security-critical na code ay nagdadala ng tatlong uri ng test:

• Pinapatunayan ng unit tests ang inaasahang gawi sa mga kilalang input, kabilang ang mga test vector na hango sa protocol specification.
• Ang property tests ay gumagawa ng libu-libong arbitrary input at nagpapahayag ng invariant: canonical CBOR round-trip, signature verification round-trip, email-binding predicates, pact acknowledgement determinism.
• Ang cross-implementation tests ay nag-veverify na sumasang-ayon ang aming client at server implementations byte-for-byte sa canonical encodings. Nahuhuli nito ang divergence sa pagitan ng dalawang implementasyon bago ito umabot sa production.

11. Branch at Release Hygiene

Umuusad ang mga sangay ng tampok staging sa pamamagitan lamang ng Gate 1 pull request: kinakailangan ci berde, walang hindi pa nalulutas na kahilingan sa pagbabago, walang tunggalian sa pagsasanib, at malinis na pinasang-suri na puno; ang pagsasanib ay i-squash-at-burahin. main umuunlad lamang sa pamamagitan ng Gate 2 staging → main Ang pull request ay nagtataguyod ng pinagmulan at nagpapanatili ng kasaysayan gamit ang merge commit. Ang direktang pagtulak sa sangay ay hindi bahagi ng workflow ng release.

Ang pag-deploy ng staging at production ay pinapagana mula sa katumbas na protektadong staging at main mga sangay na estado pagkatapos ng CI. Ang code ng pull-request at mga kredensyal ng fork ay hindi nakakatanggap ng mga lihim sa pag-deploy.

Ang mga secret na ginagamit sa deploy workflows ay naka-scope sa deploy environment ng aming CI platform. Hindi sila available sa pull-request workflows mula sa forks.

12. Coordinated Disclosure

Kung naniniwala kang nakakita ka ng security vulnerability sa qub, gusto naming marinig agad ito at ipinapangako naming hawakan ang ulat nang propesyonal.

• Mag-email sa support@qub.social gamit ang subject prefix na [SECURITY].
• Ilarawan ang vulnerability, mga hakbang upang mag-reproduce, at anumang proof-of-concept.
• Bigyan kami ng makatwirang disclosure window (karaniwang 90 araw) bago maging publiko.
• Huwag mag-access ng data na hindi sa iyo, bawasan ang serbisyo para sa ibang user, o panatilihin ang data na nakuha sa research lampas sa kinakailangan upang ipakita ang isyu.

Kinikilala namin ang pagtanggap sa loob ng tatlong business days at pinapanatiling napapanahon ang iyong impormasyon habang nag-iimbestiga kami. Sa iyong pahintulot, pinarangalan namin ang mga nagre-report sa release notes.

12.1 Safe Harbor

Kung ang iyong research ay sumusunod sa mga panuntunan sa itaas (mabuting kaloobang pagsisiyasat, walang pinsala sa ibang user o sa serbisyo, makatwirang disclosure window), hindi kami magsasagawa ng legal action laban sa iyo, at hindi kami hihiling sa law enforcement na. Itinuturing namin ang iyong trabaho bilang awtorisadong pagsubok at mas gusto naming makita mo ang bug kaysa ibang tao.

Naaangkop ang Safe Harbor na ito sa:

• Research sa live qub.social na serbisyo (hindi sa mga test fixture na ina-publish namin para sa layuning iyon).
• Reverse-engineering ng aming mga ipinathang binary at ng open-source qub-core / qub-app crates.
• Anumang klase ng vulnerability — protocol, application, infrastructure, supply-chain — na nakakaapekto sa qub.

Hindi ito naaangkop sa social engineering ng mga qub team member, denial-of-service tests, o pag-access ng data ng ibang user lampas sa kinakailangan upang ipakita ang isyu. Kung hindi ka sigurado kung ang isang bagay ay nasa loob ng Safe Harbor, magtanong muna gamit ang parehong subject prefix na [SECURITY].

13. Mga Tapat na Limitasyon

Ang seguridad ay isang gawain, hindi isang estado. Ilang limitasyon ang sulit pangalanan nang direkta:

• Maliit kami na koponan. Ang lalim ng aming pagsusuri ay hindi tumutugma sa malaking korporasyon na may nakatuong application-security function. Binabayaran namin sa mahigpit na automated gates at minimal attack surface, ngunit hindi kami inaangkin ang infallibility.
• Ang pagiging permanente ng aming storage backend ay isang one-way door. Kung ang isang pagkakamali ay nagdulot na ang isinelyong nilalaman ay maging decryptable nang mas maaga kaysa nilalayon, hindi namin ito mababawi. Hinahawakan namin ang seal flow na may kaakibat na pag-iingat.
• Ang drand network ay isang external dependency. Ang isang catastrophic failure ng drand ay makakaapekto sa reveal behavior ng bawat qub. Mino-monitor namin ang drand health at may contingency documentation para sa chain migration kung kinakailangan. Para sa mga unlock date na higit sa 2 taon, ang seal-time confirmation modal ay nagpapakita ng malinaw na disclosure: ang mga long-horizon qub ay nakadepende sa drand chain durability, at ang hinaharap na drand chain migration ay maaaring mangailangan ng recovery steps upang i-unlock ang qub. Para sa mga unlock date na higit sa 5 taon, dapat kang mag-check ng karagdagang kahon na nagkukumpirma na nabasa mo at tinatanggap ang panganib na ito bago magpatuloy ang pag-selyo.
• Ang mga cryptographic primitive na inaasahan namin ay standardized at malawak na nasuri, ngunit umuunlad ang cryptography. Kung saan may mga pagpipilian (post-quantum signing, authenticated encryption), pumipili kami ng mas konserbatibong opsyon.

14. Mga Pagbabago sa Pahinang Ito

Ang mga materyal na pagbabago ay tinatandaan sa pamamagitan ng pag-update ng epektibong petsa sa itaas. Kung saan ang isang pagbabago ay nagpapakita ng konkretong pagpapabuti ng seguridad, inilalarawan namin ito nang maikli sa pampublikong changelog. Kung saan ang isang pagbabago ay nagpapakita ng paglilinaw ng patakaran, inilalarawan namin kung ano ang nagbago at bakit.

Para sa mga tanong tungkol sa anuman sa pahinang ito, mag-email sa support@qub.social gamit ang subject prefix na [SECURITY].

15. Change Log