Sikkerhed hos qub

Ikrafttrædelsesdato: 23. september 2026 Version: 1.1 — gennemgang af implementeringsnøjagtighed

For forskere — hurtig reference:

• Hvor rapporter skal sendes: support@qub.social med emnepræfikset [SECURITY].
• Hvad der skal inkluderes: sårbarheden, trin til reproduktion og enhver proof-of-concept.
• Vores svar: vi bekræfter modtagelse inden for 3 hverdage og sigter mod at levere en rettelse inden for 90 dage.
• Safe Harbor: vi forfølger ikke retlige skridt mod god-tros-forskning, der følger reglerne i §12 (ingen adgang til data, der ikke er dine, ingen forringelse af tjenesten, ingen opbevaring af opnåede data ud over det, der er nødvendigt for at demonstrere problemet, giv os et rimeligt offentliggørelsesvindue).

Fulde detaljer er i §12 (Koordineret offentliggørelse).

Hvem vi er

qub.social drives af VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australien. Henvisninger til "qub", "vi", "os" og "vores" betyder den enhed.

Sikkerhedskontakt: support@qub.social med emnepræfikset [SECURITY].

1. Vores tilgang

qub er tillidsinfrastruktur. Produktet er værdiløst, hvis det ikke er sikkert, så sikkerhed er ikke en funktion — det er substratet. Denne side beskriver i konkrete termer, hvordan vi beskytter vores stack, dine data og integriteten af forseglet indhold.

Værdien af en verificerbar tidsbestemt forpligtelse vokser, efterhånden som mere af internettet bliver maskingenereret. En verificeret lagringstransaktion eller en forankring i transparensloggen kan fastslå, at ciphertext eksisterede senest på blokkens tidspunkt; det forseglede artefakt beviser separat indholdsintegritet, binding til drand-runden og eventuelle forfatterskabssignaturer. At holde disse påstande adskilt er den standard, denne side holdes op imod.

Vi beder dig ikke om at stole på os. Vi designer, så den tillid, der kræves af os, er så lille som muligt, og hvor tillid kræves, forklarer vi præcis, hvad der bliver stolet på, og hvorfor.

Tre principper driver enhver designbeslutning:

• Minimér, hvad serveren kan se. I browserens standardbeskedflow bliver klartekst og indpakningsnøglen på din enhed. Serversideforsegling med Builder, medunderskrift af pagter og udtrykkeligt aktiveret genoprettelse har andre tillidsgrænser, som beskrives nedenfor. Når vi opbevarer metadata, begrænser vi dem til det, den valgte funktion kræver.
• Gør kompromis lokalt indeholdt. Et brud på en hvilken som helst komponent (vores server, e-mailudbyderen, en drand-node) bør ikke afsløre forseglet indhold, der endnu ikke har nået sin afsløringstid.
• Gør protokollen reviderbar. Det forseglede artefakt kan verificeres end-to-end med offentlig kryptografi. Du behøver ikke at stole på qub tjenesten for at verificere en qub artefakten.

2. Trusselsmodel

2.1 Hvad vi beskytter imod

• En angriber, der får læseadgang til vores lagrede serversidedata før afsløringstidspunktet. I browserens private standardflow får angriberen metadata og uigennemsigtige indpakkede bytes, ikke klartekst eller K. Denne beskyttelse gælder ikke for en K, der udtrykkeligt opbevares til genoprettelse, for offentlig/bar levering efter dens drand-runde eller for klartekst, der midlertidigt leveres til Builder-/api/v1/seal- og pagtflows.
• En angriber, der opfanger trafik mellem din browser og vores infrastruktur. TLS termineres ved vores CDN-edge; forseglede payloads er allerede krypterede før transit.
• En angriber, der manipulerer med en lagret payload. Autentificering af den ydre indpakning (når den findes), kanonisk afkodning, body-hashet, genudledning af qub_id, rundebinding og valgfrie signaturer får manipulation til at fejle verifikationen; læseren nægter at gengive den.
• En angriber, der forsøger at binde en forfalsket forfatter-e-mail til en signeringsnøgle. E-mail-attestering kræver besiddelse af både den private signeringsnøgle og en engangskode leveret til e-mail-indbakken.
• En kompromitteret drand-beacon-operatør. drand-netværket bruger threshold BLS-signaturer på tværs af flere uafhængige operatører; et mindretal kan ikke forfalske tidlige udløsnings-signaturer.

2.2 Hvad vi ikke kan beskytte imod

Vi er ærlige om vores begrænsninger. qub kan ikke forsvare sig mod:

• Et kompromis af din enhed, før du forsegler. Lokale keyloggere, ondsindede browser-udvidelser eller fysisk adgang til en ulåst enhed kan opfange klartekst på kompositionstidspunktet.
• Et sammenbrud af drand-tærsklen. Flere uafhængige organisationer driver drand-netværket specifikt for at gøre dette vanskeligt, men det er ikke kryptografisk umuligt: hvis nok operatører samarbejder, kunne de udlede timelock-nøgler tidligt.
• Udgivelsesegenskaberne for en gyldig kopi. En offentlig/bar qub kan dekrypteres efter dens drand-runde. En privat/indpakket qub kræver desuden K; enhver, der får både de lagrede bytes og K, kan dekryptere efter runden. Optegnelser på permanent lager og i en forankret log kan ikke tilbagekaldes blot ved at fjerne dem fra qub's produktoverflade.
• En global modstander, der bryder den underliggende kryptografi (AES-GCM, BLS12-381 paring-antagelser, SHA3-256, ML-DSA-65). Hvis disse primitiver falder, har det kryptografiske økosystem som helhed større problemer.

3. Klient-side kryptografi

I browserens standardbeskedflow sker indholdskryptering før uploadanmodningen. To udtrykkelige stier er anderledes: Builder-/api/v1/seal sender bevidst klartekst og en K, som kalderen har genereret, til Workeren til forsegling i hukommelsen, og faseinddeling/medunderskrift af pagter sender den signerede strukturerede pagt til tjenesten, så den kan færdiggøre det bilaterale artefakt. Ingen af undtagelserne må forveksles med end-to-end-kryptering i browserstien.

3.1 Timelock-kryptering

qub bruger tlock — identitetsbaseret kryptering nøglet til en fremtidig drand-beacon-runde. Kryptering forløber i din browser ved hjælp af drand-netværkets offentlige nøgle; dekrypteringsnøglen frigives offentligt af drand-netværket, kun når mål-runden nås. Ingen, inklusive os, kan rekonstruere dekrypteringsnøglen på forhånd.

Vi sigter mod quicknet-kæden:

• 3-sekunders runde-periode
• Unchained-tilstand (hver runde er uafhængig)
• BLS12-381 G1-signaturer
• Chain-hash 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

quicknet-kædens offentlige nøgle og genesis-tid er kompileret ind i klienten. Vi henter ikke kæde-parametre ved kørselstid, så en ondsindet node kan ikke substituere en kæde, vi kontrollerer.

3.2 Symmetrisk kryptering

tlock-skemaet ombryder en AES-256-GCM-indholdsnøgle. AES-GCM giver autentificeret kryptering: en enkelt bit vendt i ciphertext'en får dekryptering til at mislykkes, snarere end at producere stille-korrumperet klartekst.

3.3 Kanonisk serialisering

Protokolstrukturer serialiseres ved hjælp af deterministisk CBOR (RFC 8949 §4.2 core deterministic encoding). To implementeringer, der koder den samme logiske struktur, producerer identisk CBOR. Komplette forseglede payloads er ikke deterministiske: tlock og krypteringen af den ydre indpakning bruger frisk tilfældighed. Body-hashet beregnes over de rå body-bytes, mens den kanoniske kodning gør de omgivende signerede strukturer og wire-strukturer entydige.

Vi skrev CBOR-encoderen i hånden for både vores klient- og serverimplementeringer i stedet for at stole på et generisk serialiseringsbibliotek — kravet er nøjagtighed, ikke ergonomi, og property-tests kører i begge implementeringer for at verificere, at de stemmer overens.

En regressionstest bekræfter, at det kanoniske wire-format ikke indeholder nogen qub-brand byte-sekvens ud over protokol-primitive qub_id-feltnøglen. Wire-formatet er bevidst brand-agnostisk — enhver konform læser (vores eller en tredjeparts) kan gengive enhver qub fra permanent lager, uanset hvilken implementering der forseglede den. Testen er en snubletråd, der forhindrer en fremtidig ændring i utilsigtet at bage en brand-reference ind i bytes, der, når de først er i permanent lager, ikke kan omskrives.

3.4 Body-hashing og integritet før afsløring

Hver forseglet payload bærer et SHA3-256-hash af sine rå body-bytes. Hashet er bundet ind i qub_id og, når forfatterskabssignering er aktiveret, i V2-signaturinputtet. En læser genberegner det efter dekryptering og afviser en uoverensstemmelse.

Den 32-byte indholdsidentifikator qub_id udledes fra et 108-byte preimage, der dækker protokolversionen, indholdstypen, oprettelses- og oplåsningstidsstempler, et valgfrit udfaldstidsstempel (eller dets nulsentinel), den ønskede drand-runde, body-hashet og SHA3-256 af den valgfrie NFC-normaliserede titel. En gateway eller et CDN kan ikke ændre et bundet felt konsistent og stadig bestå genudledningen. Titler er begrænset til 100 NFC-kodepunkter og afvises ved den fælles klasse af fjendtlige kodepunkter og kontrolkodepunkter (herunder bidi-overrides, tegn uden bredde, tagblokken, BOM, C0, C1 og DEL).

3.5 Signering (ML-DSA-65)

Forfatter-signering bruger ML-DSA-65 (FIPS 204), et NIST-standardiseret post-kvante-signaturskema. Vi valgte bevidst en post-kvante-primitiv til signering, fordi forseglet indhold er permanent: en signatur, der verificerer i dag, skal stadig verificere årtier fra nu, herunder efter at storskala-kvantecomputere bliver praktiske.

Signeringsnøgler genereres i browseren. Den lokale hemmelighed indpakkes under en ikke-eksporterbar WebCrypto-nøgle før lagring i IndexedDB. Hvis funktionen til kontoomfanget genoprettelse på tværs af enheder bruges, lagres en AEAD-krypteret portabel nøgleblob på serversiden; dens ciphertext for den hemmelige nøgle bindes til det uforanderlige konto-id, og tjenesten validerer den offentlige konvolut, men kan ikke dekryptere det hemmelige materiale. Rå bytes fra den private nøgle sendes ikke til serveren. Offentlige nøgler og attesteringsoptegnelser opbevares til verifikation og identitetsvisning.

Samme in-browser tlock-dekryptering gælder inde i qub-embeddet: når en forseglet qub gengives gennem <qub-embed> på en tredjepartsside, sker dekryptering stadig i embed-iframen i læserens browser. Embeddet ændrer ikke tillidsmodellen — klartekst dekrypteres aldrig på en qub-server.

3.6 Offentlig tilskrivning — opt-in

Forseglede qubs bærer ingen on-chain-pointer til deres skaber, medmindre skaberen eksplicit vælger at vedhæfte en. Når du forsegler en qub, udsender reference-appen et Author lager-tag (et 64-tegns hex-fingeraftryk af din offentlige signeringsnøgle), kun når "Offentlig tilskrivning" er aktiveret på datovælger-trinnet. Med kontakten slået fra — standard — skrives intet Author-tag, og qub'en er utilskrevet i permanent lager: intet i lageret forbinder uploaden med din handle, din e-mail eller dine andre qubs. Med kontakten slået til, opløses fingeraftrykket til din @handle via attesteringskæden i §6.3 / §10, og læser-nedtællingen viser "Forseglet af @{handle}" før afsløring.

Dette er en bevidst sikring mod den enumeration-risiko, et altid-aktiveret Author-tag ville skabe: en tredjepart, der lærer en skabers fingeraftryk, kunne ellers gennemsøge permanent lager efter tagget og rekonstruere skaberens fulde historiske output. Opt-in-tilskrivning lukker den kanal — kun qubs, skaberen eksplicit vælger at tilskrive, dukker op under et fingeraftryk i permanent lager.

/u/{handle}-profilsiden er et verificeret-identitets-kort — handle, valgfrit visningsnavn + URL, "verificeret e-mail"-pille (ingen adresse) og det kryptografiske fingeraftryks korte form. Den lister ikke en skabers qubs. Besøgende, der vil se en specifik qub fra en skaber, følger den qub's leverings-URL direkte.

3.7 Ydre krypteringsindpakning

Selv efter at timelock-dekryptering er matematisk mulig — når drand-signaturen for den bundne runde er offentliggjort — ville det kanoniske timelock-lag alene lade en indekseringstjeneste massedekryptere qubs, der kan findes. Privat levering lukker den kanal med et yderligere symmetrisk lag omkring de timelock-krypterede bytes (Protokol §13). Offentlig levering udelader bevidst indpakningen, så notifikations-, embed- og opdagelseslinks kan fungere uden et hemmeligt fragment.

Indpakningen bruger AES-256-GCM, en NIST-standardiseret autentificeret cipher, med en frisk 256-bit nøgle K genereret pr. qub af din browsers CSPRNG. K er bundet til qub'ens qub_id som autentificerede yderligere data, så en nøgle fra én qub ikke kan genbruges til at dekryptere en anden qub.

K når aldrig vores servere i browserens private standardflow. Den er kodet ind i URL-fragmentet af delelinket (https://qub.social/c/<tx_id>#<base64url(K)>). Browsere transmitterer ikke URL-fragmenter til servere—RFC 3986 placerer fragmentet uden for anmodningen—så qub.social, lagergateways, CDN'er og anmodningsovervågning er blinde over for K i dette flow. Den lagrede OuterWrapper er genkendelig struktureret CBOR, men dens autentificerede ciphertext-felt skjuler den indre SealedQub-struktur og kan ikke åbnes uden K.

Netto-konsekvenser:

• qub.social kan ikke dekryptere private standardforseglinger fra browseren alene ud fra lagrede data. Et kompromis af datalageret giver uigennemsigtig ciphertext uden K. Offentlige qubs og qubs med aktiveret genoprettelse har bevidst en anden eksponering.
• Tab af fragmentet kan ikke genoprettes uden en tilvalgt genoprettelseskanal. Hvis du gemmer et privat link uden fragmentet og ikke aktiverede genoprettelse, bliver qub'en ulæselig via det link. Forseglingsflowet viser derfor en udtrykkelig "gem denne URL"-oplysning.
• Opt-in-genoprettelse. Når du opt-in'er til skaber-livscyklus-e-mails for en qub OG e-mailen matcher din verificerede identitet, accepterer vi K med uploaden, gemmer den fulde leverings-URL på din identitets forseglede-historik-optegnelse og bruger den som linket i forseglings-bekræftelses-e-mailen. Denne handel — en server-side genoprettelseskanal i bytte for noget end-to-end-renhed — engageres kun ved eksplicit opt-in og kun for den qub. Standardholdningen er krypto-strimling.

Workerens server-side /api/v1/seal-endpoint (brugt af AI-agenter og andre API-opkaldere) kræver, at opkalderen genererer K med en CSPRNG, beholder den lokalt og leverer den som wrapper_key_b64url. Workeren ser nødvendigvis både klartekst og K i hukommelsen på denne eksplicit betroede sti, men persisterer ingen af dem. En obligatorisk Idempotency-Key forhindrer et tabt svar i at skabe endnu en faktureret qub, mens den K, som opkalderen har beholdt, kan kombineres med den genafspillede, fragmentløse URL. Dette adskiller sig fra standard-browser-stien, hvor K aldrig når Workeren, medmindre skaberen eksplicit aktiverer genoprettelse.

4. Transport og edge

4.1 TLS

Browsertrafik til qub leveres over HTTPS ved Cloudflare-edge. Svar angiver HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). Den nøjagtigt forhandlede TLS-version og cipher suite styres af den aktive edge-konfiguration og hævdes ikke af applikationskoden. Vi eksponerer ikke en separat origin-server, der kan nås direkte.

4.2 Indholdssikkerhed

Den kompilerede klient serveres med strenge content-type- og cache-headere. SPA-skallen er en enkelt origin. Vi indlejrer ikke tredjepartsscripts til analyser eller reklame. De to tredjeparts-berøringspunkter i produktet er begge snævert afgrænset: købsflowet forlader SPA'en helt med en fuld sideomdirigering til Stripe-hostet checkout (https://checkout.stripe.com/…) — Stripes UI udføres aldrig i vores origin, og vi ser aldrig kortdata — og forseglingsflowet indlæser Cloudflares Turnstile-widget, et privatlivs-bevarende CAPTCHA-alternativ, som Cloudflare gengiver inde i sin egen sandboxede iframe. Ingen af parterne kan læse resten af siden.

qub-embed-iframen (serveret fra qub.social/embed/{tx_id} og indlæst i tredjepartssider af embed.js) har sin egen Content-Security-Policy. Dens connect-src-tilladelsesliste er 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh og https://drand.cloudflare.com. Iframen kører med sandbox="allow-scripts allow-top-navigation-by-user-activation" (ikke allow-same-origin): værtssiden kan ikke læse dens DOM, og den kan ikke navigere værten, medmindre brugeren har foretaget en handling.

4.3 CORS og fetch-omfang

Browser-klienten foretager fetch-anmodninger kun til:

• Vores eget API (api.qub.social og staging-ækvivalenter)
• Lager-gateways (skrivebeskyttet, til hentning af indpakkede private eller uindpakkede offentlige bytes — §3.6)
• drand-beacon-endpoints (skrivebeskyttet, til afslørings-runde-signaturer)

Embeddets destinationer håndhæves af dets CSP. Hoved-SPA'ens tilsigtede destinationer ligger fast i kode og konfiguration og afprøves af browser- og integrationstjek; Subresource Integrity er ikke en kontrol af netværksdestinationer.

Embeddet henter lagrede bytes gennem de tilladte qub-/lager-origins, pakker private payloads ud i browseren med K fra sit URL-fragment og henter rundesignaturer til afsløringstidspunktet fra de to tilladte drand-origins. Hoved-SPA'en bruger fallback-sættet med fire endpoints i config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh og api3.drand.sh), så et udfald af ét endpoint ikke blokerer afsløring. Embed-CSP'en afviser forbindelser uden for sin udtrykkelige liste.

5. Server-side infrastruktur

5.1 Serverløs edge

Vores API kører helt på en administreret serverløs runtime ved edge. Der er ingen VM'er, ingen containere og ingen vedvarende serverprocesser, vi administrerer. Dette reducerer dramatisk den angrebsoverflade, vi er ansvarlige for: vi kører ikke et OS, en webserver eller en applikations-runtime, vi skal patche.

En separat public-CORS middleware anvendes Access-Control-Allow-Origin: * til den følgende implementerede sti-sæt: /embed.js, /embed/v1.js, alt under /embed/; /api/v1/telemetry; /api/v1/openapi.json; alt under /api/v1/qub/ (inklusive bytes, metadata, bevis, engagement, underret, og push-underveje); alt under /api/v1/log/; offentlige håndtag opslag under /api/v1/handle/; og offentlig avatar læser under /api/v1/identity/avatar/. Dets preflight-tilladelser GET, POST, og OPTIONS med Content-Type anmodningshoved. Denne præfiksbaserede overflade er bredere end kun de kald, som embed i øjeblikket foretager, så hver handler under disse præfikser skal fortsat håndhæve sin egen validering, autentificering, grænser for forespørgsler og misbrugsstyring. Andre API-stier beholder den qub.social-begrænsede CORS-politik.

5.2 Lagring

• Metadata- og koordineringslagre indeholder identitets- og attesteringsoptegnelser, berettigelser og faktureringsreferencer, API-nøgleoptegnelser, denylisteposter, sessioner, idempotensstatus, køer samt rate-limit- og samtidighedstilstand. Forskellige konsistensbehov bruger KV, D1 og Durable Objects i stedet for ét universelt lager.
• Vores objektlager er også et holdbarhedssubstrat. Det indeholder de nøjagtige indpakkede eller bare qub-bytes, som uploaden har kvitteret for, blade i transparensloggen og koordinatnøglede Merkle-noder, forankringsmateriale, strukturerede hændelseslogs samt svar- og metadatacaches.
• Permanent offentligt lager indeholder forankringer fra transparensloggen og, for T3-stien eller udskudt offentliggørelse, individuelle qub-transaktioner. Vi driver ikke det netværk. Private browserpayloads forbliver uigennemsigtige dér, medmindre indehaveren også har K; offentlige/bare payloads har bevidst ikke dette ekstra lag af linkbaseret adgang.

Browserens standardbeskedflow opbevarer ikke klartekst på qub-infrastruktur. Builder-/api/v1/seal håndterer klartekst og K i hukommelsen, men opbevarer ingen af delene. Faseinddeling af pagter opbevarer nødvendigvis den signerede strukturerede pagt, indtil den medunderskrives, trækkes tilbage eller udløber. Tilvalgt genoprettelse opbevarer en leveringskapabilitet (det fulde link med fragment), så den senere kan genoprettes. Derfor beskriver vi ikke hele lagringstien som »kun metadata«.

5.3 Hemmeligheder

Hemmeligheder (signerings-wallets, udbydertokens og HMAC-nøgler) leveres gennem platformens secret-/miljøbindingsmekanismer i stedet for kildekontrol. Runtime-komponenter modtager kun de bindinger, de har brug for. Procedurer for rotation og overlapning er komponentspecifikke; vi hævder ikke, at der findes én universel automatisk eller revideret rotationsmekanisme.

5.4 Logning og telemetri

Strukturerede JSON-logs skrives ved hver API-anmodning med et korrelations-ID overfladiseret i X-Request-Id-svarheaderen. Klient-telemetri er anonym — ingen enhedsidentifikator, ingen IP-adresse, ingen indholdsforhåndsvisning. Begivenheder bufres i hukommelsen og flushes på best-effort-basis; en mislykket flush kastes, ikke genforsøgt. Telemetri er designet til at kunne deaktiveres på netværkslaget uden at påvirke produktet.

6. Godkendelse

6.1 Magic-link-login

Login bruger et engangs-, HMAC-signeret token leveret til din e-mail-indbakke. Linket er gyldigt i 15 minutter, og indløsningen kræves atomisk, så samtidig eller genafspillet brug afvises sikkert. Når det lykkes, modtager browseren en uigennemsigtig __Host-qub_session-cookie med attributterne Secure, HttpOnly, SameSite=Strict og Path=/.

Sessioner har en grænse på 30 dages inaktivitet og en absolut grænse på 90 dage, roteres efter 24 timer og accepterer kun den umiddelbart foregående generation i en 120-sekunders henstandsperiode for mistede svar. Følsomme kontoændringer kræver godkendelse inden for de foregående 10 minutter. HMAC-signeringshemmeligheden er en platformsbinding; en isoleret læseadgang til metadata kan ikke i sig selv udstede et gyldigt token.

6.2 API-nøgler (udvikler-tier)

Udvikler-API-nøgler bruger præfikset qub_sk_ for nem genkendelse og grepability. Hver nøgle:

• Er bundet til en konto, scopes og en valgfri IP CIDR-tilladelsesliste
• Vises i rå form én gang; vedvarende optegnelser beholder dens SHA-256-hash, ikke Bearer-hemmeligheden
• Kan roteres med en henvisning i en times henstandsperiode, hvor den gamle nøgle opløses til erstatningen
• Har uafhængig kvote- og rate-limit-tilstand
• Logges aldrig i fuld; logs registrerer kun nøgleidentifikatoren

Admin-nøglehåndteringens endpoints er gated bag en separat admin-legitimering.

6.3 E-mail-attestering (forfatter-signering)

Binding af en e-mailadresse til en signeringsnøgle kræver:

1. Besiddelse af den private signeringsnøgle (du signerer en udfordring)
2. Besiddelse af e-mail-indbakken (du indtaster en 6-cifret kode leveret via e-mail)

Begge alene er utilstrækkelige. Tilbagekaldelse er en signeret optegnelse på din egen konto og træder i kraft øjeblikkeligt; læsere, der henter attesteringen, ser den tilbagekaldte tilstand og viser tilsvarende.

7. Betalinger

Kortindtastning og -behandling foregår i Stripes hostede checkout. Vi modtager aldrig kortnumre, udløbsdatoer eller CVC'er. Vi opbevarer Stripe-kunde- og abonnementsidentifikatorer, abonnementsstatus og periodedata i berettigelses-/API-nøgleoptegnelser, så adgang, fornyelser, måling, opsigelser og refusioner kan afstemmes. Stripes privatlivs- og sikkerhedserklæringer regulerer deres håndtering af betalingsdata.

Forseglings-endpointet krydstjekker berettigelses-optegnelsen mod enhedsidentifikatoren og, for loggede-ind-brugere, mod den tilknyttede identitet. En berettigelse kan ikke genbruges på tværs af enheder, uden at brugeren eksplicit gendanner den via magic-link-login.

8. Misbrugsmodstand

8.1 Botdetektion

Forseglingsflowet er gated af et privatlivs-bevarende CAPTCHA-alternativ, der ikke bruger cookies til sporing og ikke fingeraftrykker til reklame. En mislykket udfordring afvises af vores edge-Worker, før nogen forseglings-side-behandling sker.

8.2 Rate-limiting

Rate-limits håndhæves i flere lag:

• Per-IP- og per-nøgle-grænser på seal-, read- og auth-endpoints
• Per-e-mail-grænser på magic-link-anmodninger (forhindrer indbakke-oversvømmelse)
• Per-modpart-grænser på pagt-invite-e-mails (ti pr. modtageradresse pr. UTC-dag, den primære spam-relæ-mitigering; ærlige pagter nærmer sig næsten aldrig grænsen)
• Per-IP-grænser på telemetri-indsendelse

Tællere og atomiske krav fordeles mellem KV, Durable Objects og platformens rate-limit-bindinger efter endpointets konsistenskrav. Rate-begrænsede anmodninger returnerer 429; endpoints, der kan beregne et nyt forsøgsinterval, medtager Retry-After.

8.3 Indholdsmoderation

Standardbrowser-upload-ruten kan ikke scanne kroppen: den modtager kun det klient-forseglede artefakt. Byggeren /api/v1/seal ruten ser klartekst midlertidigt, og aftalestaging holder strukturerede vilkår indtil færdiggørelse, men de tillid undtagelser gør ikke den generelle byte-blinde uploadsti til en indholdsscanner. Operationel moderation er en afvise liste på brugerlagsniveau: en afvist qub nægtes af vores viewer uanset, om den gemte payload stadig er tilgængelig. Afvisning fjerner ikke holdbare bytes, poster i gennemsigtighedslog eller permanentnetværksdata, der allerede er offentliggjort.

Misbrugsrapporter rate-limites ved hjælp af et envejs-hash af rapportørens IP; vi gemmer ikke IP'er i klartekst til dette formål.

9. Forsyningskæde og build-integritet

9.1 Toolchain-pinning

Compiler- og runtime-versioner fastgøres i repository-konfigurationen, og afhængigheder opløses gennem committede lockfiles. CI kontrollerer, at genererede filer er opdaterede, og at reproducerbarhedsfølsomme invarianter overholdes. Vi fremsætter ikke den stærkere påstand, at ethvert rent build er bit for bit identisk på alle understøttede maskiner.

9.2 Lints og statisk analyse

Workspacen aktiverer vores strengeste lint-grupper på deny-niveauet. CI behandler hver advarsel — inklusive dokumentationslink-advarsler — som et build-svigt. Dette er bevidst: vi bruger lint-strengheden som en snubletråd for subtile regressioner.

9.3 CI-porte

CI-workflowet dækker formatering og strenge lints; Rust-, WASM-/browser-, Worker-, embed- og API-tests; typekontrol; codedækning; mutations-/invariantkontroller; statisk analyse af afhængigheder og workflows; i18n-nøgler, -dækning, -drift og kontrol af fjendtlige kodepunkter; aktualitet af genererede dokumenter, API'er og vidensbase; dokumentinventar og interne linkkontroller; stylesheet- og bundtbudgetter samt OpenAPI-validering. Nogle dyre mutationsjobs er planlagte i stedet for at køre ved hvert push.

En enkelt påkrævet samlet ci-status forbliver rød, hvis et påkrævet job fejler. Workflows for beskyttede grene og deploy bruger dette resultat i stedet for at duplikere en mindre sikkerhedsport.

9.4 Mutationstest

Et ugentligt job kører mutationstest mod de sikkerhedskritiske rene moduler: hashing, kanonisk CBOR, seal, unlock, wire-format-newtypes, protokol-type-validatorer og handle-namespace. Mutationstest besvarer "fanger vores test-suite subtilt forkert kode?" — hvis en muteret implementering stadig består alle tests, ved vi, at vi har et test-coverage-hul og adresserer det.

9.5 Git-hooks

Lokale hooks (pre-commit, pre-push) spejler CI-portene, så regressioner fanges, før de forlader udviklerens maskine. Hooks installeres via et repo-script; de bypasses ikke i vores workflow, og CI er den autoritative port, hvis de springes over.

10. Test

Sikkerhedskritisk kode bærer tre slags tests:

• Enhedstest verificerer forventet adfærd på kendte input, inklusive testvektorer udledt fra protokolspecifikationen.
• Property-tests genererer tusindvis af vilkårlige input og hævder invarianter: kanonisk CBOR round-trips, signaturverifikation-round-trips, e-mail-bindings-prædikater, pagt-anerkendelse-determinisme.
• Cross-implementation-tests verificerer, at vores klient- og serverimplementeringer stemmer overens byte-for-byte om kanoniske kodninger. Dette fanger divergens mellem de to implementeringer, før det når produktion.

11. Branch- og release-hygiejne

Featuregrene fremmer kun staging gennem en Gate 1-pull request: påkrævet grøn ci, ingen uløste ændringsanmodninger, ingen mergekonflikt og et rent gennemgået træ; mergingen bruger squash, og grenen slettes. main fremmes kun gennem Gate 2-pull requesten staging → main og bevarer afstamningen med en mergecommit. Direkte push til grenene er ikke release-workflowet.

Staging- og produktionsdeploys udløses fra tilstanden på de tilsvarende beskyttede grene staging og main efter CI. Pull request-kode og legitimationsoplysninger fra forks modtager ikke deploy-hemmeligheder.

Hemmeligheder brugt i deploy-workflows er afgrænset til deploy-miljøet af vores CI-platform. De er ikke tilgængelige for pull-request-workflows fra forks.

12. Koordineret offentliggørelse

Hvis du tror, du har fundet en sikkerhedssårbarhed i qub, vil vi gerne høre om det hurtigt, og vi forpligter os til at håndtere rapporten professionelt.

• Send e-mail til support@qub.social med emnepræfikset [SECURITY].
• Beskriv sårbarheden, trin til reproduktion og enhver proof-of-concept.
• Giv os et rimeligt offentliggørelsesvindue (typisk 90 dage), før du går offentlig.
• Tilgå ikke data, der ikke tilhører dig, forring ikke tjenesten for andre brugere, eller bevar data opnået under forskning ud over det, der er nødvendigt for at demonstrere problemet.

Vi bekræfter modtagelse inden for tre hverdage og holder dig informeret, mens vi undersøger. Med dit samtykke krediterer vi rapportører i release-notater.

12.1 Safe Harbor

Hvis din forskning følger reglerne ovenfor (god-tros-undersøgelse, ingen skade på andre brugere eller tjenesten, rimeligt offentliggørelsesvindue), forfølger vi ikke retlige skridt mod dig, og vi vil ikke bede retshåndhævelse om det. Vi behandler dit arbejde som autoriseret testning, og vi vil hellere have, at du finder fejlen, end at nogen anden gør det.

Denne Safe Harbor gælder for:

• Forskning på den live qub.social-tjeneste (ikke på testfixtures, vi offentliggør til det formål).
• Reverse-engineering af vores offentliggjorte binærer og open-source qub-core / qub-app-crates.
• Enhver sårbarhedsklasse — protokol, applikation, infrastruktur, forsyningskæde — der påvirker qub.

Den gælder ikke for social engineering af qub-teammedlemmer, denial-of-service-tests eller adgang til andre brugeres data ud over det, der er nødvendigt for at demonstrere problemet. Hvis du er i tvivl om, hvorvidt noget falder inden for Safe Harbor, så spørg først ved hjælp af samme [SECURITY]-emnepræfiks.

13. Ærlige begrænsninger

Sikkerhed er en praksis, ikke en tilstand. Nogle begrænsninger er værd at nævne direkte:

• Vi er et lille team. Vores gennemgangsdybde matcher ikke en stor virksomheds dedikerede applikations-sikkerheds-funktion. Vi kompenserer med strenge automatiserede porte og en minimal angrebsoverflade, men vi hævder ikke ufejlbarlighed.
• Permanensen af vores lager-backend er en envejs-dør. Hvis en fejl forårsager, at forseglet indhold bliver dekrypterbart tidligere end tilsigtet, kan vi ikke fortryde det. Vi behandler forseglingsflowet med tilsvarende omhu.
• drand-netværket er en ekstern afhængighed. Et katastrofalt drand-svigt ville påvirke hver qub's afsløringsadfærd. Vi overvåger drand-sundhed og har beredskabsdokumentation til kæde-migration, hvis det kræves. For oplåsningsdatoer mere end 2 år ude viser forseglings-bekræftelses-modalen en eksplicit oplysning: lang-horisont-qubs afhænger af drand-kædens holdbarhed, og en fremtidig drand-kæde-migration kan kræve genoprettelsestrin for at låse qub'en op. For oplåsningsdatoer mere end 5 år ude skal du afkrydse en ekstra boks, der bekræfter, at du har læst og accepterer denne risiko, før forseglingen fortsætter.
• Kryptografiske primitiver, vi er afhængige af, er standardiserede og bredt gennemgåede, men kryptografi udvikler sig. Hvor vi har valg (post-kvante-signering, autentificeret kryptering), vælger vi den mere konservative mulighed.

14. Ændringer af denne side

Væsentlige ændringer noteres ved at opdatere ikrafttrædelsesdatoen øverst. Hvor en ændring afspejler en konkret sikkerhedsforbedring, beskriver vi den kort i det offentlige ændringslog. Hvor en ændring afspejler en politisk afklaring, beskriver vi, hvad der ændrede sig, og hvorfor.

For spørgsmål om noget på denne side, send e-mail til support@qub.social med emnepræfikset [SECURITY].

15. Ændringslog