Sikkerhet hos qub

Ikrafttredelsesdato: 23. september 2026 Versjon: 1.1 — gjennomgang av implementeringsnøyaktighet

For forskere — rask referanse:

• Hvor sende rapporter: support@qub.social med subjektprefikset [SECURITY].
• Hva du bør inkludere: sårbarheten, trinnene for å gjenskape den, og eventuelle bevis på konseptet.
• Vårt svar: vi bekrefter mottak innen 3 virkedager og har som mål å sende en løsning innen 90 dager.
• Trygg havn: vi vil ikke forfølge rettslige skritt mot forskning i god tro som følger reglene i §12 (ingen tilgang til data som ikke tilhører deg, ingen tjenestenedgang, ingen lagring av innhentede data utover det som er nødvendig for å demonstrere problemet, gi oss en rimelig frist for offentliggjøring).

Fullstendige detaljer finnes i §12 (Koordinert offentliggjøring).

Hvem vi er

qub.social drives av VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. Henvisninger til "qub", "vi", "oss" og "vår" betyr den enheten.

Sikkerhetskontakt: support@qub.social med emneprefiks [SECURITY].

1. Vår tilnærming

qub er tillitsinfrastruktur. Produktet er verdiløst hvis det ikke er sikkert, så sikkerhet er ikke en funksjon — det er substratet. Denne siden beskriver, i konkrete termer, hvordan vi beskytter stacken vår, dataene dine, og integriteten til forseglet innhold.

Verdien av en verifiserbar tidsmessig forpliktelse øker ettersom mer av internett blir maskingenerert. En verifisert lagringstransaksjon eller en forankring i en transparenslogg kan fastslå at kryptert tekst eksisterte senest på blokk-tiden; det forseglede artefaktet beviser separat innholdsintegritet, drand-runde-binding og eventuelle forfattersignaturer. Å holde disse påstandene atskilt er standarden denne siden blir vurdert etter.

Vi ber deg ikke om å stole på oss. Vi designer slik at tilliten som kreves av oss er så liten som mulig, og der tillit kreves forklarer vi nøyaktig hva som blir stolt på og hvorfor.

Tre prinsipper driver hver designbeslutning:

• Minimer hva serveren kan se. I standard nettlesermeldingsflyt forblir ren tekst og innpakningsnøkkelen på enheten din. Server-side Builder-forsegling, paktmedsignering og eksplisitt aktivert gjenoppretting har forskjellige tillitsgrenser, som er beskrevet nedenfor. Når vi lagrer metadata, begrenser vi det til det valgte funksjonen trenger.
• Gjør kompromiss lokalt begrenset. Et brudd på en hvilken som helst komponent (vår server, e-postleverandøren, en drand-node) bør ikke avsløre forseglet innhold som ennå ikke har nådd sin avsløringstid.
• Gjør protokollen reviderbar. Den forseglede gjenstanden kan verifiseres ende-til-ende med offentlig kryptografi. Du trenger ikke å stole på qub tjenesten for å verifisere en qub artefakten.

2. Trusselmodell

2.1 Hva vi beskytter mot

• En angriper som får leseadgang til våre lagrede server-side data før avsløringstidspunktet. I standard privat nettleserflyt henter de metadata og ugjennomsiktige innpakkede bytes, ikke klartekst eller K. Denne beskyttelsen gjelder ikke for en K som eksplisitt bevares for gjenoppretting, for offentlig/ren levering etter DRAND-runden, eller for klartekst som midlertidig leveres til Byggeren /api/v1/seal og avtale arbeidsflyter.
• En angriper som avskjærer trafikk mellom nettleseren din og vår infrastruktur. TLS avsluttes ved vår CDN-kant; forseglede nyttelaster er allerede kryptert før overføring.
• En angriper som tukler med en lagret last. Autentisering av ytterskall (når den er tilstede), kanonisk dekoding, kroppshash, qub_id ny-derivasjon, rund binding og valgfrie signaturer gjør at manipulering mislykkes ved verifisering; viseren nekter å gjengi det.
• En angriper som prøver å knytte en forfalsket forfatter-e-post til en signeringsnøkkel. E-postattestering krever besittelse av både den private signeringsnøkkelen og en engangskode levert til e-postinnboksen.
• En kompromittert drand-beaconoperatør. Drand-nettverket bruker terskel-BLS-signaturer på tvers av flere uavhengige operatører; et mindretall kan ikke forfalske tidlig-utgivelsessignaturer.

2.2 Hva vi ikke kan beskytte mot

Vi er ærlige om begrensningene våre. qub kan ikke forsvare mot:

• En kompromittering av enheten din før du forsegler. Lokale keyloggere, skadelige nettleserutvidelser eller fysisk tilgang til en ulåst enhet kan fange opp tekst i klartekst på tidspunktet for komponering.
• En kollaps av drand-tærskelen. Flere uavhengige organisasjoner driver drand-nettverket spesifikt for å gjøre dette vanskelig, men det er ikke kryptografisk umulig: hvis nok operatører samarbeider, kunne de utlede tidslås-nøkler tidlig.
• Utgivelseselementene til en gyldig kopi. En offentlig/ren qub blir dekrypterbar etter sin drand-runde. En privat/innpakket qub krever i tillegg K; alle som får tak i både de lagrede bytene og K kan dekryptere etter runden. Permanent-lagring og forankrede-loggposter kan ikke hentes tilbake bare ved å fjerne dem fra qubens produktoverflate.
• En global motstander som bryter den underliggende kryptografien (AES-GCM, BLS12-381 paringsantagelser, SHA3-256, ML-DSA-65). Hvis disse primitive faller, har det kryptografiske økosystemet generelt større problemer.

3. Klient-side kryptografi

I standard nettlesermeldingsflyt skjer innholds-kryptering før opplastingsforespørselen. To eksplisitte stier er forskjellige: Builder /api/v1/seal bevisst sender klartekst og caller-generert K til Arbeideren for inn-minne-forsegling, og pact staging/co-signing sender den signerte strukturerte avtalen til tjenesten slik at den kan fullføre det bilaterale artefaktet. Ingen av unntakene bør forveksles med ende-til-ende-kryptering via nettleserstien.

3.1 Timelock-kryptering

qub bruker tlock — identitetsbasert kryptering nøklet til en framtidig drand-beacon-runde. Kryptering fortsetter i nettleseren din ved bruk av drand-nettverkets offentlige nøkkel; dekrypteringsnøkkelen frigis offentlig av drand-nettverket kun når målrunden er nådd. Ingen, inkludert oss, kan rekonstruere dekrypteringsnøkkelen på forhånd.

Vi sikter mot quicknet-kjeden:

• 3-sekunders runde-periode
• Uchained-modus (hver runde er uavhengig)
• BLS12-381 G1-signaturer
• Kjede-hash 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

Quicknet-kjedens offentlige nøkkel og genesistid er kompilert inn i klienten. Vi henter ikke kjedeparametre ved runtime, så en ondsinnet node kan ikke erstatte en kjede vi kontrollerer.

3.2 Symmetrisk kryptering

tlock-skjemaet pakker en AES-256-GCM innholdsnøkkel. AES-GCM gir autentisert kryptering: en enkelt bit snudd i chiffer-teksten får dekrypteringen til å mislykkes, i stedet for å produsere stille-korrupt klartekst.

3.3 Kanonisk serialisering

Protokollstrukturer serialiseres ved bruk av deterministisk CBOR (RFC 8949 §4.2 kjernedeterministisk koding). To implementasjoner som koder den samme logiske strukturen produserer identisk CBOR. Fullstendige forseglede nyttelaster er ikke deterministisk: tlock og outer-wrapper-kryptering bruker fersk tilfeldig verdi. Kroppens hash beregnes over de rå kroppsbytene, mens kanonisk koding gjør de omkringliggende signerte/trådet strukturene entydige.

Vi skrev CBOR-koderen for hånd for både klient- og serverimplementeringene våre i stedet for å stole på et generisk serialiseringsbibliotek — kravet er nøyaktighet, ikke ergonomi, og egenskapstester kjører i begge implementeringer for å verifisere at de stemmer overens.

En regresjonstest hevder at det kanoniske wire-formatet inneholder ingen qub-merke-byte-sekvens utover den protokoll-primitive qub_id-feltnøkkelen. Wire-formatet er tilsiktet merke-agnostisk — enhver konformerende leser (vår eller en tredjeparts) kan gjengi enhver qub fra permanent lagring, uavhengig av hvilken utplassering som forseglet den. Testen er en snubletråd som hindrer en fremtidig endring fra ved et uhell å bake en merkereferanse inn i bytes som, en gang i permanent lagring, ikke kan omskrives.

3.4 Kropp-hashing og pre-avsløringsintegritet

Hver forseglet last bærer en SHA3-256-hash av sine rå kroppsbiter. Hashen er bundet inn i qub_id og, når forfatterskaps-signering er aktivert, inn i V2-signaturfeltet. En seer beregner det på nytt etter dekryptering og avviser en uoverensstemmelse.

Den 32-byt lange innholdsidentifikatoren qub_id er avledet fra et 108-byte forbilde som dekker protokollversjonen, innholdstype, opprettelses- og låsetidsstempler, valgfritt resultatstidsstempel (eller dets null-sendtinal), mål drand-runde, kroppshash og SHA3-256 av den valgfrie NFC-normaliserte tittelen. En gateway eller CDN kan ikke endre noen bundet felt konsekvent og fortsatt passere ny-avledning. Titler er begrenset til 100 NFC-kodepunkter og avvises for den delte fiendtlige/kontrollkodepunkt-klassen (inkludert bidi-overstyringer, nullbredde-tegn, tag-blokk, BOM, C0, C1, og DEL).

3.5 Signering (ML-DSA-65)

Forfatterskaps-signering bruker ML-DSA-65 (FIPS 204), et NIST-standardisert post-kvante signaturskjema. Vi valgte bevisst en post-kvante-primitiv for signering fordi forseglet innhold er permanent: en signatur som verifiserer i dag må fortsatt verifisere flere tiår fra nå, inkludert etter at storskala kvantemaskiner blir praktiske.

Signeringsnøkler genereres i nettleseren. Den lokale hemmeligheten pakkes inn under en ikke-ekstraherbar WebCrypto-nøkkel før lagring i IndexedDB. Hvis gjenopprettingsfunksjonen for tvers-enheter med konto-skala brukes, lagres en AEAD-kryptert bærbar nøkkelblob på serversiden; dens hemmelige nøkkelkryptert tekst er bundet til den uforanderlige konto-ID-en, og tjenesten validerer den offentlige konvolutten, men kan ikke dekryptere det hemmelige materialet. Rå private nøkkel-bytter sendes ikke til serveren. Offentlige nøkler og attesteringsoppføringer lagres for verifisering og visning av identitet.

Den samme tlock-dekrypteringen i nettleseren gjelder inni qub-embedden: når en forseglet qub gjengis gjennom <qub-embed> på en tredjepartsside, skjer dekryptering fortsatt i embed-iframen i leserens nettleser. Embedden endrer ikke tillitsmodellen — klartekst dekrypteres aldri på en qub-server.

3.6 Offentlig tilskrivning — opt-in

Forseglede qub-er bærer ingen på-kjede-peker til sin skaper med mindre skaperen eksplisitt velger å feste en. Når du forsegler en qub sender referanseappen ut en Author lagringstag (et 64-tegns hex-fingeravtrykk av din signerings-offentlige nøkkel) kun når "Offentlig tilskrivning" er aktivert på datovelgersteget. Med veksleren av — standard — skrives ingen Author-tag og qub-en er ikke-tilskrevet i permanent lagring: ingenting i lagringen lenker opplastingen til handle-et ditt, e-posten din, eller dine andre qub-er. Med veksleren på løser fingeravtrykket seg til ditt @handle via attestkjeden i §6.3 / §10 og lesernedtellingen viser "Forseglet av @{handle}" før avsløring.

Dette er en bevisst beskyttelse mot enumeration-risikoen en alltid-på Author-tag ville opprette: en tredjepart som lærer en skapers fingeravtrykk kunne ellers søke i permanent lagring etter taggen og rekonstruere den skaperens fulle historiske produksjon. Opt-in-tilskrivning lukker den kanalen — kun qub-er skaperen eksplisitt velger å tilskrive vises under et fingeravtrykk i permanent lagring.

/u/{handle}-profilsiden er et verifisert-identitetskort — handle, valgfritt visningsnavn + URL, "verifisert e-post"-pill (ingen adresse), og det kryptografiske fingeravtrykk-kortformen. Den lister ikke en skapers qub-er. Besøkende som vil se en spesifikk qub fra en skaper følger den qub-ens leverings-URL direkte.

3.7 Ytre krypteringsinnpakning

Selv etter at tidslås-dekryptering er matematisk mulig—når drand-signaturen for den bundne runden er publisert—vil det kanoniske tidslås-laget alene la en indekserer masse-dekryptere oppdagbare qubs. Privat levering lukker den kanalen med et ekstra symmetrisk lag rundt de tidslås-krypterte byteene (Protokoll §13). Offentlig levering utelater med vilje innpakningen slik at varsling, innbygging og oppdagelseslenker kan fungere uten en hemmelig fragment.

Innpakningen bruker AES-256-GCM, et NIST-standardisert autentisert chiffer, med en fersk 256-bits nøkkel K generert per qub av nettleserens CSPRNG. K er bundet til qub-ens qub_id som autentisert tilleggsdata, så en nøkkel fra en qub kan ikke gjenbrukes for å dekryptere en annen qub.

K når aldri våre servere i standard privat nettleserflyt. Det er kodet inn i URL-fragmentet til delingslenken (https://qub.social/c/<tx_id>#<base64url(K)>). Nettlesere sender ikke URL-fragmenter til servere—RFC 3986 plasserer fragmentet utenfor forespørselen—så qub.social, lagringsgateways, CDN-er og forespørselsmonitorering er blinde for K i den flyten. Den lagrede OuterWrapper er gjenkjennelig strukturert CBOR, men dets autentiserte chiffertekstfelt skjuler det indre SealedQub struktur og kan ikke åpnes uten K.

Nettokonsekvenser:

• qub.social kan ikke dekryptere standard private nettleserforseglinger kun fra lagrede data. Et datalagringsbrudd når uigjennomsiktig kryptert tekst uten K. Offentlige qubs og gjenopprettingsaktiverte qubs har forskjellig eksponering etter design.
• Fragmenttap kan ikke gjenopprettes uten en valgt gjenopprettingskanal. Hvis du lagrer en privat lenke uten fragmentet og ikke aktiverte gjenoppretting, blir quben uleselig gjennom den lenken. Seal-flyten viser en eksplisitt «lagre denne URL-en»-melding av denne grunn.
• Frivillig gjenoppretting. Når du velger å motta e-poster om skaperlivssyklus for en qub OG e-posten samsvarer med din verifiserte identitet, godtar vi K med opplastingen, lagrer den fullstendige leverings-URL-en på identitetens forseglede historikkoppføring, og bruker den som lenken i forseglingsbekreftelses-e-posten. Denne handelen — en server-side gjenopprettingskanal i bytte mot noe ende-til-ende renhet — skjer kun ved eksplisitt samtykke og kun for den quben. Standardoppførselen er kryptodestruksjon.

Workerens server-side /api/v1/seal-endepunkt (brukt av KI-agenter og andre API-kallere) krever at kalleren genererer K med en CSPRNG, beholder den lokalt og oppgir den som wrapper_key_b64url. Workeren ser nødvendigvis både klartekst og K i minnet på denne eksplisitt betrodde banen, men vedvarer ingen av dem. En obligatorisk Idempotency-Key hindrer at et tapt svar oppretter enda en fakturert qub, mens K som kalleren beholder kan kombineres med den fragmentløse URL-en som spilles av på nytt. Dette skiller seg fra den standard nettleserbanen, der K aldri når Workeren med mindre skaperen eksplisitt aktiverer gjenoppretting.

4. Transport og kant

4.1 TLS

Nettlesertrafikk til qub blir servert over HTTPS på Cloudflare-kanten. Svar setter HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). Den nøyaktige forhandlede TLS-versjonen og krypteringssettet styres av den aktive edge-konfigurasjonen i stedet for å bli angitt av applikasjonskoden. Vi eksponerer ikke en separat tilgjengelig origin-server.

4.2 Innholdssikkerhet

Den kompilerte klienten serveres med strenge innholdstype- og mellomlager-overskrifter. SPA-skallet er en enkelt opphav. Vi bygger ikke inn tredjepartsskripter for analyse eller reklame. De to tredjepartsberøringspunktene i produktet er begge smalt avgrenset: kjøpsflyten forlater SPA-en helt med en fullside-omdirigering til Stripe-hostet kasse (https://checkout.stripe.com/…) — Stripes UI eksekverer aldri i opphavet vårt og vi ser aldri kortdata — og forseglingsflyten laster Cloudflares Turnstile-widget, et personvernbevarende CAPTCHA-alternativ som Cloudflare gjengir inni sin egen sandkasse-iframe. Ingen av partene kan lese resten av siden.

Den qub bygg inn iframe (servert fra qub.social/embed/{tx_id} og lastet inn på tredjeparts nettsteder av embed.js) har sin egen Content-Security-Policy. Dens connect-src tillatelsesliste 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 kjører med sandbox="allow-scripts allow-top-navigation-by-user-activation" (ikke allow-same-origin): vertsiden kan ikke lese sin DOM, og den kan ikke navigere verten bortsett etter en brukerhandling.

4.3 CORS og fetch-omfang

Nettleserklienten gjør fetch-forespørsler kun til:

• Vår egen API (api.qub.social og staging-ekvivalenter)
• Lagringsporter (kun lesing, for hentning av innpakkede-private eller rene-offentlige byte — §3.6)
• drand-beacon-endepunkter (kun lesing, for avsløringstids rundesignaturer)

Destinasjonene til innebyggingen håndheves av dens CSP. Hoved-SPAens tiltenkte destinasjoner er fastsatt i kode og konfigurasjon og testes av nettleser- og integrasjonssjekker; Subresource Integrity er ikke en kontroll av nettverksdestinasjoner.

Inbeddet henter lagrede bytes gjennom de tillatte qub/storage-opprinnelsene, pakker ut private payloads i nettleseren ved å bruke K fra URL-fragmentet, og henter avslørings-tid rundesignaturer fra de to tillatte drand-opprinnelsene. Hoved-SPAen bruker settet med fire endepunkt som tilbakefall i config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh, og api3.drand.sh) slik at ett endepunktutfall ikke blokkerer avsløringen. Den innebygde CSP blokkerer tilkoblinger utenfor dens eksplisitte liste.

5. Server-side infrastruktur

5.1 Serverløs kant

API-et vårt kjører helt på en administrert serverløs runtime ved kanten. Det er ingen VMer, ingen containere, og ingen vedvarende serverprosesser vi administrerer. Dette reduserer dramatisk angrepsoverflaten vi er ansvarlige for: vi driver ikke et OS, en webserver, eller en applikasjonsruntime som vi må patche.

En separat offentlig CORS-mellomvare brukes Access-Control-Allow-Origin: * til den følgende implementerte stien som er satt: /embed.js, /embed/v1.js, alt under /embed/; /api/v1/telemetry; /api/v1/openapi.json; alt under /api/v1/qub/ (inkludert bytes, metadata, bevis, engasjement, varsle og push-underruter); alt under /api/v1/log/; offentlige håndtakoppslag under /api/v1/handle/; og offentlig avatar leser under /api/v1/identity/avatar/. Dens preflight-tillatelser GET, POST, og OPTIONS med den Content-Type forespørselshode. Dette prefiksbaserte grensesnittet er bredere enn bare de kallene innebyggingen for øyeblikket gjør, så hver håndterer under disse prefiksene må fortsatt håndheve sin egen validering, autentisering, ratebegrensninger og misbruksregler. Andre API-stier beholder qub.social-begrenset CORS-policy.

5.2 Lagring

• Metadata- og koordinasjonslagre holde identitet og attesteringsregistre, rettigheter og faktureringsreferanser, API-nøkkelregistre, oppføringer på svarteliste, økter, idempotensstatus, køer og tilstandsdata for hastighetsbegrensning / samtidighet. Ulike behov for konsistens bruker KV, D1 og Durable Objects i stedet for én universell lagring.
• Vår objektlagring er også et slitesterkt substrat. Det holder de eksakt innpakkede eller nakne qub-bytene som er anerkjent av opplasting, transparenslogg-blader og koordinatnøkkel-baserte Merkle-noder, ankerstoff, strukturerte hendelseslogger og respons-/metadata-buffere.
• Permanent offentlig lagring holder gjennomsiktighets-logg-anker og, for T3-stien eller utsatt publisering, individuelle qub-transaksjoner. Vi driver ikke det nettverket. Private nettleser-payloads forblir ugjennomsiktige der med mindre innehaveren også har K; offentlige/rene payloads har bevisst ikke det ekstra lenke-laget.

Standard nettlesermeldingsflyt lagrer ikke ren tekst på qub-infrastrukturen. Builder /api/v1/seal håndterer klartekst og K i minnet, men lagrer ingen av delene. Pact staging lagrer nødvendigvis den signerte strukturerte pakt til den enten medsigneres, trekkes tilbake eller utløper. Valgfri gjenoppretting lagrer en leveringskapabilitet (den fullstendige fragmentbærende lenken) slik at den kan gjenopprettes senere. Vi beskriver derfor ikke hele lagringsnivået som “kun metadata.”

5.3 Hemmeligheter

Hemmelige opplysninger (signeringslommebøker, tilbydertokener og HMAC-nøkler) leveres gjennom plattformhemmeligheter/miljøbindinger i stedet for versjonskontroll. Kjøretidskomponenter mottar kun bindingene de trenger. Roterings- og overlappingsprosedyrer er komponentspesifikke; vi hevder ikke å ha én universell automatisk eller revidert roteringsmekanisme.

5.4 Logging og telemetri

Strukturerte JSON-logger skrives ved hver API-forespørsel med en korrelasjons-ID overflatet i X-Request-Id-svaroverskriften. Klienttelemetri er anonym — ingen enhetsidentifikator, ingen IP-adresse, ingen innholdsforhåndsvisning. Hendelser bufres i minnet og tømmes på et best-mulig-grunnlag; en mislykket tømming kastes, ikke prøves på nytt. Telemetri er designet til å kunne deaktiveres på nettverkslaget uten å påvirke produktet.

6. Autentisering

6.1 Magic-link-innlogging

Pålogging bruker en engangs HMAC-signert token som sendes til din e-postinnboks. Lenken er gyldig i 15 minutter, og innløsningen kreves atomisk slik at samtidig eller gjentatt bruk mislykkes. Ved suksess mottar nettleseren en ugjennomsiktig __Host-qub_session kjeks med Secure, HttpOnly, SameSite=Strict, og Path=/ egenskaper.

Økter har en 30-dagers inaktivgrense og en 90-dagers absolutt grense, roter etter 24 timer, og godtar kun den umiddelbart forrige generasjonen for en 120-sekunders tapt-respons frist. Følsomme kontoomstillinger krever autentisering innen de foregående 10 minuttene. HMAC-signeringshemmeligheten er en plattformbinding; en metadata-only lesing genererer ikke i seg selv et gyldig token.

6.2 API-nøkler (utviklernivå)

Utvikler-API-nøkler bruker prefikset qub_sk_ for enkel gjenkjennelse og grepbarhet. Hver nøkkel:

• Er bundet til en konto, scopes, og en valgfri IP CIDR-tillateliste
• Vises i rå form én gang; vedvarende poster beholder dens SHA-256-hash, ikke bærerhemmeligheten
• Kan roteres med en times fristkartlegging der den gamle nøkkelen løses opp til erstatningen
• Har uavhengig kvote- og hastighetsbegrensningstilstand
• Blir aldri logget i sin helhet; logger registrerer bare nøkkelidentifikatoren

Admin-nøkkeladministrasjonsendepunkter er gated bak en separat admin-legitimasjon.

6.3 E-postattest (forfatterskapssignering)

Å binde en e-postadresse til en signeringsnøkkel krever:

1. Besittelse av den private signeringsnøkkelen (du signerer en utfordring)
2. Besittelse av e-postinnboksen (du skriver inn en 6-sifret kode levert per e-post)

Hver alene er utilstrekkelig. Tilbakekall er en signert post på din egen konto og trer i kraft umiddelbart; lesere som henter attesten ser den tilbakekalte tilstanden og viser deretter.

7. Betalinger

Kortinnlegging og behandling skjer inne i Stripe-hostet kassesystem. Vi mottar aldri kortnumre, utløpsdatoer eller CVC. Vi lagrer imidlertid Stripe-kunde- og abonnementsidentifikatorer, abonnementsstatus og periodedata på rettighets-/API-nøkkelposter slik at tilgang, fornyelser, måling, kansellering og refusjoner kan avstemmes. Stripes personvern- og sikkerhetserklæringer styrer håndteringen av betalingsdata.

Forseglingsendepunktet kryss-sjekker berettigelsesposten mot enhetsidentifikatoren og, for innloggede brukere, mot den lenkede identiteten. En berettigelse kan ikke gjenbrukes på tvers av enheter uten at brukeren eksplisitt gjenoppretter den via magic-link-innlogging.

8. Misbruksresistens

8.1 Botdeteksjon

Forseglingsflyten er gated av et personvernbevarende CAPTCHA-alternativ som ikke bruker informasjonskapsler til sporing og ikke fingeravtrykker for reklame. En mislykket utfordring avvises av vår kant-Worker før noen forseglingside-behandling skjer.

8.2 Hastighetsbegrensning

Hastighetsgrenser håndheves på flere lag:

• Per-IP og per-nøkkel-grenser på forseglings-, lese- og auth-endepunkter
• Per-e-post-grenser på magic-link-forespørsler (forhindrer postkasseoversvømmelse)
• Per-motpart-grenser på paktinvitasjons-e-poster (ti per mottakeradresse per UTC-dag, den primære spam-relé-mitigeringen; ærlige pakter nærmer seg nesten aldri taket)
• Per-IP-grenser på telemetri-innsending

Tellere og atomære krav er distribuert på tvers av KV, Durable Objects og plattformens hastighetsbegrensningsbindinger i henhold til endepunktets konsistenskrav. Forespørsler som overstiger grensen returnerer 429; endepunkter som kan beregne et nytt forsøk-vindu inkluderer Retry-After.

8.3 Innholdsmoderering

Standard nettleser-opplastingsrutene kan ikke skanne innholdet: den mottar bare den klient-forseglede artefakten. Byggeren /api/v1/seal ruten ser klartekst midlertidig, og avtale staging holder strukturerte vilkår til ferdigstilling, men de tillitsunntakene gjør ikke den generelle byte-blinde opplastingsveien til en innholdsskanner. Operasjonell moderering er en avvise liste på visningslaget: en nektet qub blir avvist av vår visningsapp uavhengig av om den lagrede nyttelasten fortsatt er tilgjengelig. Nektelisting trekker ikke tilbake varige bytes, oppføringer i transparensloggen eller permanent nettverksdata som allerede er publisert.

Misbruksrapporter er hastighetsbegrenset ved bruk av en envegs-hash av rapportørens IP; vi lagrer ikke IPer i klartekst for dette formålet.

9. Forsyningskjede og bygge-integritet

9.1 Verktøykjede-festing

Kompilator- og kjøretidsversjoner er fastsatt i depotkonfigurasjonen, og avhengigheter løses gjennom forpliktede låsefiler. CI sjekker generert fils ferskhet og reproduserbarhetsfølsomme invariants. Vi gjør ikke den sterkere påstanden om at hver ren bygging er bit-for-bit identisk på alle støttede maskiner.

9.2 Lints og statisk analyse

Arbeidsområdet aktiverer våre strengeste lint-grupper på deny-nivå. CI behandler hver advarsel — inkludert dokumentasjons-lenke-advarsler — som en bygge-svikt. Dette er bevisst: vi bruker lint-strenghet som en snubletråd for subtile regresjoner.

9.3 CI-porter

CI-arbeidsflyten dekker formatering og strenge linter; Rust-, WASM/browser-, Worker-, innebygd- og API-tester; typekontroll; kodedekning; mutasjons-/invariantkontroller; avhengighets- og arbeidsflytstatisk analyse; i18n-nøkler, dekning, drift og kontroller av fiendtlige tegn; friskhet for generert dokumentasjon/API/kunnskapsbase; dokumentinventar og interne lenkekontroller; stilark- og bundtebudsjetter; og OpenAPI-validering. Noen kostbare mutasjonsjobber er planlagt i stedet for å kjøres ved hver push.

Én enkelt nødvendig ci roll-up forblir rød hvis noen nødvendig jobb feiler. Protected-branch og deploy-arbeidsflyter bruker det resultatet i stedet for å duplisere en mindre sikkerhetskontroll.

9.4 Mutasjonstesting

En ukentlig jobb kjører mutasjonstesting mot de sikkerhetskritiske rene modulene: hashing, kanonisk CBOR, forsegling, opplåsing, wire-format-newtypes, protokolltypevalidatorene, og handle-navnerommet. Mutasjonstesting svarer på "fanger testsuiten vår subtilt feil kode?" — hvis en mutert implementering fortsatt passerer alle tester, vet vi at vi har et testdeknings-gap og adresserer det.

9.5 Git-hooks

Lokale hooks (pre-commit, pre-push) speiler CI-portene slik at regresjoner fanges før de forlater utviklerens maskin. Hooks installeres via et repo-skript; de omgås ikke i arbeidsflyten vår og CI-en er den autoritative porten hvis de hoppes over.

10. Testing

Sikkerhetskritisk kode bærer tre typer tester:

• Enhetstester verifiserer forventet atferd på kjente innspill, inkludert testvektorer avledet fra protokollspesifikasjonen.
• Egenskapstester genererer tusenvis av vilkårlige innspill og hevder invarianter: kanonisk CBOR rundturer, signaturverifisering rundturer, e-postbinding-prediktater, paktbekreftelsesdeterminisme.
• Tverr-implementeringstester verifiserer at klient- og serverimplementeringene våre stemmer overens byte-for-byte på kanoniske kodinger. Dette fanger divergens mellom de to implementeringene før det når produksjon.

11. Gren- og utgivelses-hygiene

Funksjonsgrener går fremover staging kun gjennom en Gate 1 pull request: påkrevd ci grønn, ingen uavklarte endringsforespørsler, ingen sammenføyningskonflikt, og et ryddig gjennomgått tre; sammenføringen er squash-og-slett. main fremmer bare gjennom Port 2 staging → main pull request og bevarer opphav med en merge-commit. Direkte push til gren er ikke utgivelsesflyten.

Utplasseringer til staging og produksjon utløses fra den tilsvarende beskyttede staging og main branch-branches etter CI. Pull-request-kode og fork-legitimasjon mottar ikke deploy-hemmeligheter.

Hemmeligheter brukt i deploy-arbeidsflyter er avgrenset til deploy-miljøet av CI-plattformen vår. De er ikke tilgjengelige for pull-request-arbeidsflyter fra forks.

12. Koordinert avsløring

Hvis du tror du har funnet en sikkerhetssårbarhet i qub, vil vi gjerne høre om det raskt og vi forplikter oss til å håndtere rapporten profesjonelt.

• Send e-post til support@qub.social med emneprefiks [SECURITY].
• Beskriv sårbarheten, trinn for å reprodusere, og eventuelt proof-of-concept.
• Gi oss et rimelig avsløringsvindu (vanligvis 90 dager) før du går offentlig.
• Ikke få tilgang til data som ikke tilhører deg, ikke degrader tjenesten for andre brukere, og ikke behold data innhentet under forskning utover det som er nødvendig for å demonstrere problemet.

Vi bekrefter mottak innen tre virkedager og holder deg informert mens vi undersøker. Med ditt samtykke krediterer vi rapportører i utgivelsesnotater.

12.1 Safe Harbor

Hvis forskningen din følger reglene over (god-tro-undersøkelse, ingen skade for andre brukere eller tjenesten, rimelig avsløringsvindu), vil vi ikke forfølge rettslige skritt mot deg, og vi vil ikke be rettshåndhevelse om å gjøre det. Vi behandler arbeidet ditt som autorisert testing og vi vil heller at du finner bugen enn at noen andre gjør det.

Denne Safe Harbor gjelder for:

• Forskning på den levende qub.social-tjenesten (ikke på testfixturer vi publiserer for det formålet).
• Reverse-engineering av våre publiserte binærer og de åpen-kilde qub-core / qub-app-cratene.
• Enhver sårbarhetsklasse — protokoll, applikasjon, infrastruktur, forsyningskjede — som påvirker qub.

Den gjelder ikke for sosial manipulering av qub-teammedlemmer, denial-of-service-tester, eller å få tilgang til andre brukeres data utover det som trengs for å demonstrere problemet. Hvis du er usikker på om noe faller innenfor Safe Harbor, spør først ved bruk av samme [SECURITY]-emneprefiks.

13. Ærlige begrensninger

Sikkerhet er en praksis, ikke en tilstand. Noen begrensninger er verdt å navngi direkte:

• Vi er et lite team. Vår gjennomgangsdybde matcher ikke en stor selskaps dedikerte applikasjonssikkerhetsfunksjon. Vi kompenserer med strenge automatiserte porter og en minimal angrepsoverflate, men vi hevder ikke ufeilbarlighet.
• Permanensen av permanent lagring er en envegsdør. Hvis en feil får forseglet innhold til å bli dekrypterbart tidligere enn tiltenkt, kan vi ikke angre det. Vi behandler forseglingsflyten med tilsvarende omhu.
• drand-nettverket er en ekstern avhengighet. En katastrofal svikt i drand ville påvirke hver qubs avsløringsatferd. Vi overvåker drand-helse og har beredskapsdokumentasjon for kjedemigrering hvis nødvendig. For opplåsingsdatoer mer enn 2 år ute viser forseglingstid-bekreftelsesmodalen en eksplisitt opplysning: lang-horisont-qub-er avhenger av drand-kjede-holdbarhet, og en framtidig drand-kjede-migrering kan kreve gjenopprettingstrinn for å låse opp qub-en. For opplåsingsdatoer mer enn 5 år ute må du krysse av en ekstra boks som bekrefter at du har lest og aksepterer denne risikoen før forseglingen fortsetter.
• Kryptografiske primitiver vi stoler på er standardiserte og bredt gjennomgått, men kryptografi utvikler seg. Der vi har valg (post-kvante-signering, autentisert kryptering), velger vi det mer konservative alternativet.

14. Endringer i denne siden

Vesentlige endringer noteres ved å oppdatere ikrafttredelsesdatoen øverst. Der en endring reflekterer en konkret sikkerhetsforbedring, beskriver vi den kort i den offentlige endringsloggen. Der en endring reflekterer en retningslinjeavklaring, beskriver vi hva som endret seg og hvorfor.

For spørsmål om noe på denne siden, send e-post til support@qub.social med emneprefiks [SECURITY].

15. Endringslogg