Sekuriteit by qub

Effektiewe datum: 23 September 2026 Weergawe: 1.1 — hersiening vir implementeringsakkuraatheid

Vir navorsers — vinnige verwysing:

• Waar om verslae te stuur: support@qub.social met die onderwerp-voorvoegsel [SECURITY].
• Wat om in te sluit: die kwesbaarheid, stappe om te reproduseer, en enige bewys-van-konsep.
• Ons reaksie: ons erken ontvangs binne 3 besigheidsdae en mik om 'n regstelling binne 90 dae te stuur.
• Veilige Hawe: ons sal nie regsaksie teen goeie-trou-navorsing voortsit wat die reëls in §12 volg nie (geen toegang tot data wat nie joune is nie, geen diensagteruitgang nie, geen behoud van data verkry buite wat nodig is om die kwessie te demonstreer nie, gee ons 'n redelike openbaarmaking-venster).

Volle besonderhede is in §12 (Gekoördineerde Openbaarmaking).

Wie Ons Is

qub.social word bedryf deur VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australië. Verwysings na "qub", "ons", en "onse" verwys na daardie entiteit.

Sekuriteit-kontak: support@qub.social met die onderwerp-voorvoegsel [SECURITY].

1. Ons Benadering

qub is vertrou-infrastruktuur. Die produk is waardeloos as dit nie veilig is nie, so sekuriteit is nie 'n kenmerk nie — dit is die substraat. Hierdie bladsy beskryf, in konkrete terme, hoe ons ons stapel, jou data, en die integriteit van verseëlde inhoud beskerm.

Die waarde van 'n verifieerbare temporele verbintenis groei namate meer van die internet masjiengegenereer word. 'n Geverifieerde bergingstransaksie of deursigtigheidslog-anker kan vasstel dat syferteks nie later as sy bloktyd bestaan het nie; die verseëlde artefak bewys afsonderlik inhoudintegriteit, drand-rondtebinding en enige outeurskaphandtekeninge. Om daardie stellings van mekaar te onderskei, is die standaard waaraan hierdie bladsy gemeet word.

Ons vra jou nie om ons te vertrou nie. Ons ontwerp sodat die vertroue wat van ons vereis word so klein moontlik is, en waar vertroue vereis word, verduidelik ons presies wat vertrou word en hoekom.

Drie beginsels dryf elke ontwerpbesluit:

• Minimaliseer wat die bediener kan sien. In die verstek-blaaierboodskapvloei bly skoonteks en die omhulselsleutel op jou toestel. Bediener-kant Builder-verseëling, verbond-mede-ondertekening en uitdruklik geaktiveerde herwinning het ander vertrouensgrense wat hieronder uiteengesit word. Waar ons metadata hou, beperk ons dit tot wat die gekose funksie benodig.
• Maak kompromie plaaslik bevat. 'n Inbreuk van enige een komponent (ons bediener, die e-posverskaffer, 'n drand-knooppunt) moet nie verseëlde inhoud wat nog nie sy onthullingstyd bereik het nie, openbaar nie.
• Maak die protokol ouditteerbaar. Die verseëlde artefak is einde-tot-einde verifieerbaar met openbare kriptografie. Jy hoef nie qub die diens te vertrou om 'n qub die artefak te verifieer nie.

2. Bedreigingsmodel

2.1 Waarteen Ons Beskerm

• 'n Aanvaller wat voor onthullingstyd leestoegang tot ons gestoorde bediener-kant-data kry. In die verstek-private-blaaiervloei kry hulle metadata en ondeursigtige omhulde grepe, nie skoonteks of K nie. Hierdie beskerming geld nie vir K wat uitdruklik vir herwinning behou is nie, vir openbare/kaal aflewering ná die drand-rondte, of vir skoonteks wat kortstondig aan die Builder-/api/v1/seal- en verbondwerkvloeie verskaf word nie.
• 'n Aanvaller wat verkeer tussen jou blaaier en ons infrastruktuur onderskep. TLS termineer by ons CDN-rand; verseëlde ladings is reeds voor vervoer geënkripteer.
• 'n Aanvaller wat met 'n gestoorde lading peuter. Buitenste-omhulsel-verifikasie (waar dit teenwoordig is), kanonieke dekodering, die liggaam-hash, herafleiding van qub_id, rondtebinding en opsionele handtekeninge laat peutering die verifikasie druip; die kyker weier om dit te lewer.
• 'n Aanvaller wat probeer 'n vervalste outeur-e-pos aan 'n ondertekeningsleutel bind. E-pos-attestasie vereis besit van beide die privaat ondertekeningsleutel en 'n eenmalige kode gelewer aan die e-pos-inboks.
• 'n Gekompromitteerde drand-baken-operateur. Die drand-netwerk gebruik drempel-BLS-handtekeninge oor verskeie onafhanklike operateurs; 'n minderheid kan nie vroeg-vrystellings-handtekeninge vervals nie.

2.2 Waarteen Ons Nie Kan Beskerm Nie

Ons is eerlik oor ons grense. qub kan nie verdedig teen:

• 'n Kompromie van jou toestel voordat jy verseël. Plaaslike toetsaanlokkers, kwaadwillige blaaier-uitbreidings, of fisiese toegang tot 'n ontsluite toestel kan gewone teks by die punt van saamstel vasvang.
• 'n Ineenstorting van die drand-drempel. Verskeie onafhanklike organisasies bedryf die drand-netwerk spesifiek om dit moeilik te maak, maar dit is nie kriptografies onmoontlik nie: as genoeg operateurs saamspan, kan hulle tydslot-sleutels vroeg aflei.
• Die vrystellingseienskappe van 'n geldige kopie. 'n Openbare/kaal qub word ná sy drand-rondte ontsleutelbaar. 'n Private/omhulde qub vereis boonop K; enigiemand wat beide die gestoorde grepe en K bekom, kan dit ná die rondte ontsleutel. Rekords in permanente berging en geankerde logboeke kan nie bloot herroep word deur hulle van qub se produkoppervlak te verwyder nie.
• 'n Globale teenstander wat die onderliggende kriptografie breek (AES-GCM, BLS12-381 paring-aannames, SHA3-256, ML-DSA-65). As hierdie primitiewe val, het die kriptografiese ekosisteem op groot skaal groter probleme.

3. Kliënt-kant Kriptografie

In die verstek-blaaierboodskapvloei vind inhoud-enkripsie voor die oplaaiversoek plaas. Twee uitdruklike paaie verskil: Builder-/api/v1/seal stuur doelbewus skoonteks en K wat die oproeper gegenereer het na die Worker vir verseëling in geheue, en verbond-opvoering/-mede-ondertekening stuur die ondertekende gestruktureerde verbond na die diens sodat dit die bilaterale artefak kan finaliseer. Geen uitsondering moet met einde-tot-einde-enkripsie van die blaaierpad verwar word nie.

3.1 Tydslot-Enkripsie

qub gebruik tlock — identiteit-gebaseerde enkripsie gekoppel aan 'n toekomstige drand-baken-rondte. Enkripsie verloop in jou blaaier met die drand-netwerk se openbare sleutel; die dekripsie-sleutel word slegs deur die drand-netwerk in die openbaar vrygestel wanneer die teiken-rondte bereik word. Niemand, insluitend ons, kan die dekripsie-sleutel vooraf rekonstruktueer nie.

Ons teiken die quicknet-ketting:

• 3-sekonde rondte-tydperk
• Onverkettede modus (elke rondte is onafhanklik)
• BLS12-381 G1-handtekeninge
• Ketting-hash 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

Die quicknet-ketting se openbare sleutel en genesis-tyd word in die kliënt gekompileer. Ons haal nie ketting-parameters by looptyd nie, sodat 'n kwaadwillige knooppunt nie 'n ketting wat ons beheer, kan vervang nie.

3.2 Simmetriese Enkripsie

Die tlock-skema omvou 'n AES-256-GCM-inhoudsleutel. AES-GCM bied geverifieerde enkripsie: 'n enkele bit wat in die cijferteks omgeruil word, veroorsaak dat dekripsie misluk, in plaas daarvan om stilweg-korrupte gewone teks te produseer.

3.3 Kanonieke Serialisering

Protokolstrukture word met deterministiese CBOR (RFC 8949 §4.2 kern-deterministiese kodering) geserialiseer. Twee implementasies wat dieselfde logiese struktuur enkodeer, produseer identiese CBOR. Volledige verseëlde ladings is nie deterministies nie: tlock- en buitenste-omhulsel-enkripsie gebruik vars ewekansigheid. Die liggaam-hash word oor die rou liggaamgrepe bereken, terwyl kanonieke enkodering die omliggende ondertekende/draadstrukture ondubbelsinnig maak.

Ons het die CBOR-enkodeerder met die hand vir beide ons kliënt- en bediener-implementasies geskryf eerder as om op 'n generiese serialiseringbibliotheek staat te maak — die vereiste is presiesheid, nie ergonomie nie, en eienskap-toetse loop in beide implementasies om te verifieer hulle stem saam.

'n Regressietoets verseker die kanonieke draadformaat bevat geen qub-handelsmerk byte-volgorde buite die protokol-primitiewe qub_id veld-sleutel nie. Die draadformaat is doelbewus handelsmerk-agnosties — enige ooreenstemmende kyker (ons s'n of 'n derde party s'n) kan enige qub van permanente berging lewer, ongeag watter ontplooiing dit verseël het. Die toets is 'n struikeldraad wat 'n toekomstige verandering verhoed om per ongeluk 'n handelsmerk-verwysing in bytes te bak wat, sodra in permanente berging, nie herskryf kan word nie.

3.4 Liggaam-Hashing en Voor-Onthulling Integriteit

Elke verseëlde lading dra 'n SHA3-256-hash van sy rou liggaamgrepe. Die hash is in qub_id gebind en, wanneer outeurskapondertekening geaktiveer is, in die V2-handtekeninginvoer. 'n Kyker herbereken dit ná ontsleuteling en verwerp 'n wanpassing.

Die 32-greep-inhoudidentifiseerder qub_id word afgelei van 'n 108-greep-preimage wat die protokolweergawe, inhoudstipe, skeppings- en ontsluittydstempels, die opsionele uitkoms-tydstempel (of sy nul-sentinel), die teiken-drand-rondte, liggaam-hash en SHA3-256 van die opsionele NFC-genormaliseerde titel dek. 'n Poort of CDN kan geen gebinde veld konsekwent verander en steeds herafleiding slaag nie. Titels is tot 100 NFC-kodepunte beperk en word verwerp vir die gedeelde klas vyandige/kontrolekodepunte (insluitend bidi-omkerings, nulwydtekarakters, die merkblok, BOM, C0, C1 en DEL).

3.5 Ondertekening (ML-DSA-65)

Outeurskap-ondertekening gebruik ML-DSA-65 (FIPS 204), 'n NIST-gestandaardiseerde post-kwantum handtekening-skema. Ons het doelbewus 'n post-kwantum-primitief vir ondertekening gekies omdat verseëlde inhoud permanent is: 'n handtekening wat vandag verifieer, moet steeds dekades van nou af verifieer, insluitend nadat grootskaalse kwantumrekenaars prakties geword het.

Ondertekeningsleutels word in die blaaier gegenereer. Die plaaslike geheim word onder 'n nie-onttrekbare WebCrypto-sleutel omhul voordat dit in IndexedDB gestoor word. Indien die rekeninggebonde kruistoestel-herwinningsfunksie gebruik word, word 'n AEAD-geënkripteerde draagbare sleutelblob aan die bediener-kant gestoor; sy geheimesleutel-syferteks is aan die onveranderlike rekening-id gebind, en die diens valideer die openbare omhulsel maar kan nie die geheime materiaal ontsleutel nie. Rou privaatsleutelgrepe word nie na die bediener gestuur nie. Openbare sleutels en attestasie-rekords word vir verifikasie en identiteitsvertoon gestoor.

Dieselfde in-blaaier tlock-dekripsie geld binne die qub inbed: wanneer 'n verseëlde qub deur <qub-embed> op 'n derdeparty-bladsy gelewer word, gebeur dekripsie steeds in die inbed-iframe in die kyker se blaaier. Die inbed verander nie die vertroue-model nie — gewone teks word nooit op 'n qub-bediener gedekripteer nie.

3.6 Openbare Toeskrywing — Opt-In

Verseëlde qubs dra geen op-ketting-wyser na hul skepper tensy die skepper uitdruklik kies om een aan te heg nie. Wanneer jy 'n qub verseël, stuur die verwysing-toepassing 'n Author bergingsmerker uit ('n 64-karakter-hex-vingerafdruk van jou ondertekenende openbare sleutel) slegs wanneer "Openbare toeskrywing" geaktiveer is op die datum-kieser-stap. Met die skakelaar af — die verstek — word geen Author-merker geskryf nie en die qub is ongeattribueer in permanente berging: niks in berging koppel die oplaai aan jou handvatsel, jou e-pos, of jou ander qubs nie. Met die skakelaar aan, los die vingerafdruk op na jou @handle via die attestasie-ketting in §6.3 / §10 en die kyker-aftelling wys "Verseël deur @{handle}" voor onthulling.

Dit is 'n doelbewuste waarborg teen die opsomming-risiko wat 'n altyd-aan Author-merker sou skep: 'n derde party wat 'n skepper se vingerafdruk leer ken, kon andersins permanente berging per die merker grep en daardie skepper se volle historiese uitset rekonstruktueer. Opt-in toeskrywing sluit daardie kanaal — slegs qubs wat die skepper uitdruklik kies om toe te skryf, verskyn onder 'n vingerafdruk in permanente berging.

Die /u/{handle} profielbladsy is 'n geverifieerde-identiteit-kaart — handvatsel, opsionele vertoonnaam + URL, "geverifieerde e-pos"-pil (geen adres), en die kriptografiese vingerafdruk-kortvorm. Dit lys nie 'n skepper se qubs nie. Besoekers wat 'n spesifieke qub van 'n skepper wil sien, volg daardie qub se afleweringskakel direk.

3.7 Buitenste Enkripsie-Omhulsel

Selfs nadat tydslot-ontsleuteling wiskundig moontlik is—sodra die drand-handtekening vir die gebinde rondte gepubliseer is—sou die kanonieke tydslotlaag alleen 'n indekseerder toelaat om ontdekbare qubs in grootmaat te ontsleutel. Private aflewering sluit daardie kanaal met 'n bykomende simmetriese laag om die tydslot-geënkripteerde grepe (Protokol §13). Openbare aflewering laat die omhulsel doelbewus weg sodat kennisgewing-, inbed- en ontdekkingskakels sonder 'n geheime fragment kan werk.

Die omhulsel gebruik AES-256-GCM, 'n NIST-gestandaardiseerde geverifieerde cijfer, met 'n vars 256-bit-sleutel K gegenereer per qub deur jou blaaier se CSPRNG. K is aan die qub se qub_id gebind as geverifieerde bykomende data, sodat 'n sleutel van een qub nie hergebruik kan word om 'n ander qub te dekripteer nie.

K bereik nie ons bedieners in die verstek-private-blaaiervloei nie. Dit word in die URL-fragment van die deelskakel (https://qub.social/c/<tx_id>#<base64url(K)>) geënkodeer. Blaaiers stuur nie URL-fragmente na bedieners nie—RFC 3986 plaas die fragment buite die versoek—dus is qub.social, bergingspoorte, CDNs en versoekmonitering blind vir K in daardie vloei. Die gestoorde OuterWrapper is herkenbare gestruktureerde CBOR, maar sy geverifieerde ciphertext-veld verberg die binneste SealedQub-struktuur en kan nie sonder K oopgemaak word nie.

Netto gevolge:

• qub.social kan nie verstek-private-blaaierverseëlings uit gestoorde data alleen ontsleutel nie. 'n Datastoor-kompromie bereik ondeursigtige syferteks sonder K. Openbare qubs en herwinning-geaktiveerde qubs het doelbewus ander blootstelling.
• Fragmentverlies is sonder 'n geaktiveerde herwinningskanaal onherwinbaar. As jy 'n private skakel sonder die fragment stoor en nie herwinning geaktiveer het nie, word die qub deur daardie skakel onleesbaar. Die verseëlvloei wys om hierdie rede 'n uitdruklike "stoor hierdie URL"-bekendmaking.
• Opt-in herstel. Wanneer jy inteken op skepper lewensiklus-e-posse vir 'n qub EN die e-pos pas by jou geverifieerde identiteit, aanvaar ons K met die oplaai, stoor die volle afleweringskakel op jou identiteit se verseëlde-geskiedenis-rekord, en gebruik dit as die skakel in die seël-bevestiging-e-pos. Hierdie handel — 'n bediener-kant herstelkanaal in ruil vir 'n bietjie einde-tot-einde-suiwerheid — koppel slegs by eksplisiete opt-in en slegs vir daardie qub. Die verstek-houding is kripto-versnippering.

Die Worker se bediener-kant /api/v1/seal-eindpunt (gebruik deur KI-agente en ander API-bellers) vereis dat die beller K met 'n CSPRNG genereer, dit plaaslik behou, en dit as wrapper_key_b64url verskaf. Die Worker sien noodwendig beide gewone teks en K in geheue op hierdie eksplisiet-vertroude pad, maar behou geeneen nie. 'n Verpligte Idempotency-Key verhoed dat 'n verlore respons 'n tweede gefaktureerde qub skep, terwyl die beller-behoue K met die herspeelde fragmentlose URL gekombineer kan word. Dit verskil van die verstek-blaaierpad, waar K nooit die Worker bereik nie tensy die skepper herstel uitdruklik aktiveer.

4. Vervoer en Rand

4.1 TLS

Blaaierverkeer na qub word oor HTTPS by die Cloudflare-rand bedien. Antwoorde stel HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). Die presiese onderhandelde TLS-weergawe en syferstel word deur die aktiewe randkonfigurasie beheer eerder as deur toepassingskode verklaar. Ons stel geen afsonderlik bereikbare oorsprongbediener bloot nie.

4.2 Inhoudsekuriteit

Die saamgestelde kliënt word bedien met streng inhoud-tipe en kas-koptekste. Die SPA-skil is 'n enkele oorsprong. Ons bed nie derdeparty-skripte vir analise of advertensie in nie. Die twee derdeparty-aanrakingspunte in die produk is albei nou-gerig: die aankoopvloei verlaat die SPA heeltemal met 'n volle-bladsy-herleiding na Stripe-aangebiede uitcheck (https://checkout.stripe.com/…) — Stripe se UI loop nooit in ons oorsprong nie en ons sien nooit kaart-data nie — en die seël-vloei laai Cloudflare se Turnstile-widget, 'n privaatheid-bewarende CAPTCHA-alternatief wat Cloudflare binne sy eie sandboks-iframe lewer. Geen party kan die res van die bladsy lees nie.

Die qub-inbed-iframe (bedien vanaf qub.social/embed/{tx_id} en deur embed.js in derdeparty-webwerwe gelaai) dra sy eie Content-Security-Policy. Sy connect-src-toelaatlys is 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh en https://drand.cloudflare.com. Die iframe loop met sandbox="allow-scripts allow-top-navigation-by-user-activation" (nie allow-same-origin nie): die gasheerbladsy kan nie sy DOM lees nie, en dit kan die gasheer slegs ná 'n gebruikersaksie navigeer.

4.3 CORS en Haal-Omvang

Die blaaier-kliënt maak haal-versoeke slegs na:

• Ons eie API (api.qub.social en stadium-ekwivalente)
• Bergingspoorte (lees-alleen, vir herwinning van omhulde private of kaal openbare grepe — §3.6)
• drand-baken-eindpunte (lees-alleen, vir onthul-tyd rondte-handtekeninge)

Die inbed se bestemmings word deur sy CSP afgedwing. Die hoof-SPA se beoogde bestemmings is in kode en konfigurasie vasgelê en word deur blaaier- en integrasiekontroles getoets; Subresource Integrity is nie 'n netwerkbestemmingsbeheer nie.

Die inbed haal gestoorde grepe deur die toegelate qub-/bergingsoorspronge, pak private ladings in die blaaier met K uit sy URL-fragment uit en haal onthullingstyd-rondtehandtekeninge by die twee toegelate drand-oorspronge. Die hoof-SPA gebruik die vier-eindpunt-terugvalstel in config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh en api3.drand.sh) sodat een eindpunt-onderbreking nie onthulling blokkeer nie. Die inbed-CSP weier verbindings buite sy uitdruklike lys.

5. Bediener-Kant Infrastruktuur

5.1 Bedienerlose Rand

Ons API loop heeltemal op 'n bestuurde bedienerlose looptyd by die rand. Daar is geen VMs nie, geen houers nie, en geen volgehoue bediener-prosesse wat ons administreer nie. Dit verminder dramaties die aanvaloppervlak waarvoor ons verantwoordelik is: ons bedryf nie 'n bedryfstelsel, 'n webbediener, of 'n toepassing-looptyd wat ons moet plak nie.

’n Afsonderlike openbare CORS-middleware geld Access-Control-Allow-Origin: * na die volgende geïmplementeerde padstel: /embed.js, /embed/v1.js, alles onder /embed/; /api/v1/telemetry; /api/v1/openapi.json; alles onder /api/v1/qub/ (insluitend grepe, metadata, bewys, betrokkenheid, kennisgewing, en push-subroetes); alles onder /api/v1/log/; openbare hanteer opsoek onder /api/v1/handle/; en openbare avatar lees onder /api/v1/identity/avatar/. Dit se voorvlug permits GET, POST, en OPTIONS met die Content-Type versoekopskrif. Hierdie voorvoegsel-gebaseerde oppervlak is hoër as net die oproepe wat die inbedde tans maak, so elke handler onder daardie voorvoegsels moet steeds sy eie validering, verifikasie, koerslimiete en misbruikbeheer afdwing. Ander API-paaie behou die qub.social-beperkte CORS-beleid.

5.2 Berging

• Metadata- en koördinasiestore hou identiteits- en attestasie-rekords, geregtighede en faktureringsverwysings, API-sleutelrekords, weierlys-inskrywings, sessies, idempotensietoestand, rye en tarief-/gelyktydigheidstoestand. Verskillende konsekwentheidsbehoeftes gebruik KV, D1 en Durable Objects eerder as een universele stoor.
• Ons voorwerpstoor is ook 'n duursaamheidsubstraat. Dit hou die presiese omhulde of kaal qub-grepe wat by oplaai erken is, deursigtigheidslog-blare en koördinaat-gesleutelde Merkle-knope, ankermateriaal, gestruktureerde gebeurtenislogboeke en antwoord-/metadatakasgeheues.
• Permanente openbare berging hou deursigtigheidslog-ankers en, vir die T3-pad of uitgestelde publisering, individuele qub-transaksies. Ons bedryf nie daardie netwerk nie. Private blaaierladings bly daar ondeursigtig tensy die houer ook K het; openbare/kaal ladings het doelbewus nie daardie bykomende skakelbevoegdheidslaag nie.

Die verstek-blaaierboodskapvloei hou geen skoonteks op qub-infrastruktuur vol nie. Builder-/api/v1/seal hanteer skoonteks en K in geheue maar hou geeneen vol nie. Verbond-opvoering stoor noodwendig die ondertekende gestruktureerde verbond totdat dit mede-onderteken, teruggetrek of verval is. Opsionele herwinning stoor 'n afleweringsbevoegdheid (die volledige skakel met fragment) sodat dit later herwin kan word. Ons beskryf dus nie die hele bergingslaag as “net metadata” nie.

5.3 Geheime

Geheime (ondertekeningsbeursies, verskaffertekens en HMAC-sleutels) word deur platformgeheime/-omgewingsbindings verskaf eerder as deur bronbeheer. Looptydkomponente ontvang slegs die bindings wat hulle benodig. Rotasie- en oorvleuelingsprosedures is komponentspesifiek; ons beweer nie dat daar een universele outomatiese of geouditeerde rotasiemeganisme is nie.

5.4 Logging en Telemetrie

Gestruktureerde JSON-logboeke word op elke API-versoek geskryf met 'n korrelasie-ID wat in die X-Request-Id-respons-koptekst oppervlak. Kliënt-telemetrie is anoniem — geen toestel-identifiseerder, geen IP-adres, geen inhoud-voorskou nie. Gebeure word in geheue gebuffer en op 'n beste-poging-grondslag gespoel; 'n misluk-spoel word weggegooi, nie herprobeer nie. Telemetrie is ontwerp om by die netwerklaag uitskakelbaar te wees sonder om die produk te beïnvloed.

6. Verifikasie

6.1 Magic-Link Aanmelding

Aanmelding gebruik 'n eenmalige, HMAC-getekende teken wat aan jou e-pos-inboks gelewer word. Die skakel is 15 minute geldig en inruiling word atomies opgeëis sodat gelyktydige of herspeelde gebruik veilig misluk. By sukses ontvang die blaaier 'n ondeursigtige __Host-qub_session-koekie met die eienskappe Secure, HttpOnly, SameSite=Strict en Path=/.

Sessies het 'n 30-dae-ledigheidsperk en 'n 90-dae-absolute perk, roteer ná 24 uur en aanvaar slegs die onmiddellik vorige generasie vir 'n 120-sekonde-grasietydperk vir verlore antwoorde. Sensitiewe rekeningmutasies vereis verifikasie binne die voorafgaande 10 minute. Die HMAC-ondertekeningsgeheim is 'n platformbinding; 'n metadata-alleen-leesaksie kan nie op sigself 'n geldige teken skep nie.

6.2 API-Sleutels (Ontwikkelaar-Vlak)

Ontwikkelaar-API-sleutels gebruik die voorvoegsel qub_sk_ vir maklike herkenning en grepbaarheid. Elke sleutel:

• Is aan 'n rekening, omvang en 'n opsionele IP-CIDR-toelaatlys gebind
• Word een keer in rou vorm vertoon; volgehoue rekords behou sy SHA-256-hash, nie die draergeheim nie
• Kan met 'n eenuur-grasiekartering geroteer word waarin die ou sleutel na sy plaasvervanger oplos
• Het onafhanklike kwota- en tarief-beperkingstoestand
• Word nooit volledig gelog nie; logboeke teken slegs die sleutel-identifiseerder op

Admin-sleutelbestuur-eindpunte word agter 'n aparte admin-geloofsbrief gehekel.

6.3 E-pos Attestasie (Outeurskap-Ondertekening)

Om 'n e-pos-adres aan 'n ondertekeningsleutel te bind, vereis:

1. Besit van die privaat ondertekeningsleutel (jy teken 'n uitdaging)
2. Besit van die e-pos-inboks (jy voer 'n 6-syfer-kode in wat per e-pos gelewer is)

Een alleen is onvoldoende. Herroeping is 'n getekende rekord op jou eie rekening en tree onmiddellik in werking; kykers wat die attestasie haal, sien die herroepte staat en vertoon dienooreenkomstig.

7. Betalings

Kaartinvoer en -verwerking vind binne Stripe se aangebode betaalpunt plaas. Ons ontvang nooit kaartnommers, vervaldatums of CVC's nie. Ons stoor wel Stripe-klant- en intekeningidentifiseerders, intekeningstatus en tydperkdata op geregtigheids-/API-sleutelrekords sodat toegang, hernuwings, meting, kansellasie en terugbetalings gerekonsilieer kan word. Stripe se privaatheid- en sekuriteitsverklarings beheer sy hantering van betalingsdata.

Die seël-eindpunt kruis-kontroleer die geregtigheidsrekord teen die toestel-identifiseerder en, vir aangemelde gebruikers, teen die gekoppelde identiteit. 'n Geregtigheid kan nie oor toestelle hergebruik word nie sonder dat die gebruiker dit uitdruklik via magic-link aanmelding herstel.

8. Misbruikweerstand

8.1 Bot-Opsporing

Die seël-vloei word gehekel deur 'n privaatheid-bewarende CAPTCHA-alternatief wat nie koekies vir naspoor gebruik nie en nie vingerdruk vir advertensies nie. 'n Misluk-uitdaging word deur ons rand-Worker verwerp voor enige seël-kant verwerking gebeur.

8.2 Tarief Beperking

Tarief-perke word op verskeie lae afgedwing:

• Per-IP en per-sleutel perke op seël-, lees-, en verifikasie-eindpunte
• Per-e-pos perke op magic-link-versoeke (verhoed inboks-vloed)
• Per-teen-party perke op verbond-uitnodig-e-posse (tien per ontvanger-adres per UTC-dag, die primêre gemorspos-aflaai-versagting; eerlike verbonde benader byna nooit die plafon nie)
• Per-IP perke op telemetrie-indiening

Tellers en atomiese eise is volgens elke eindpunt se konsekwentheidsbehoeftes oor KV, Durable Objects en platform-tarief-beperkingsbindings versprei. Tarief-beperkte versoeke gee 429 terug; eindpunte wat 'n herprobeeervenster kan bereken, sluit Retry-After in.

8.3 Inhoudmodering

Die standaard blaaier-oplaai-roete kan nie die liggaam skandeer nie: dit ontvang slegs die kliënt-versiegelde artefak. Die Bouer /api/v1/seal roete sien plaainteks tydelik, en ooreenkoms staging hou gestruktureerde terme tot finalisering, maar daardie vertroue-uitspansels verander nie die algemene bis-blinde oplaai-pad in ’n inhoudsskandeerder nie. Operasionele moderering is ’n weierlys by die kykerlaag: 'n weggelysde qub word deur ons kyker geweier ongeag of die gestoorde vrag steeds bereikbaar is. Weglysing trek nie volhoubare bytes, deursigtigheid-loginskrywings of permanent-netwerkdata wat reeds gepubliseer is, terug nie.

Misbruikverslae word tarief-beperk met 'n eenrigting-hash van die verslaggewer se IP; ons stoor nie IPs in die helder vir hierdie doel nie.

9. Voorsieningsketting en Build-Integriteit

9.1 Toolchain-Vasspelding

Saamsteller- en looptydweergawes word in bewaarplekkonfigurasie vasgespeld en afhanklikhede word deur vasgelegde slotlêers opgelos. CI kontroleer dat gegenereerde lêers vars is en dat reproduseerbaarheidsensitiewe invariante hou. Ons maak nie die sterker aanspraak dat elke skoon bouwerk grepe-vir-grepe identies oor alle ondersteunde masjiene is nie.

9.2 Pluise en Statiese Analise

Die werkruimte aktiveer ons strengste pluis-groepe op die deny-vlak. CI behandel elke waarskuwing — insluitend dokumentasie-skakel-waarskuwings — as 'n build-mislukking. Dit is doelbewus: ons gebruik die pluis-strengheid as 'n struikeldraad vir subtiele regressies.

9.3 CI-Hekke

Die CI-werkvloei dek formatering en streng pluise; Rust-, WASM-/blaaier-, Worker-, inbed- en API-toetse; tipe-kontrolering; kodedekking; mutasie-/invariantkontroles; afhanklikheids- en werkvloei-statiese ontleding; i18n-sleutel-, dekking-, dryf- en vyandigekodepunt-kontroles; varsheid van gegenereerde dokumente/API/kennisbasis; dokumentinventaris en interneskakel-kontroles; stylblad- en bondelbegrotings; en OpenAPI-validering. Sommige duur mutasietake loop volgens 'n skedule eerder as by elke stoot.

'n Enkele vereiste ci-samevatting bly rooi indien enige vereiste taak misluk. Beskermde-tak- en ontplooiwerkvloeie gebruik daardie resultaat eerder as om 'n kleiner sekuriteitshek te dupliseer.

9.4 Mutasietoetsing

'n Weeklikse werk loop mutasietoetsing teen die sekuriteit-kritieke suiwer modules: hashing, kanonieke CBOR, seël, ontsluit, die draadformaat-nuwetipes, die protokoltipe-valideerders, en die handvatsel-naamruimte. Mutasietoetsing antwoord "vang ons toetsstel subtiel-verkeerde kode?" — as 'n gemuteerde implementasie steeds alle toetse slaag, weet ons ons het 'n toetsdekking-gaping en spreek dit aan.

9.5 Git-Hake

Plaaslike hake (pre-commit, pre-push) weerspieël die CI-hekke sodat regressies gevang word voordat hulle die ontwikkelaar se masjien verlaat. Hake word via 'n repo-skrip geïnstalleer; hulle word nie in ons werkvloei omseil nie en die CI is die gesaghebbende hek as hulle oorgeslaan word.

10. Toetsing

Sekuriteit-kritieke kode dra drie soorte toetse:

• Eenheidstoetse verifieer verwagte gedrag op bekende insette, insluitend toetsvektore afgelei van die protokol-spesifikasie.
• Eienskap-toetse genereer duisende arbitrêre insette en bevestig invariante: kanonieke CBOR rond-trips, handtekening-verifikasie rond-trips, e-pos-binding-predikate, verbond-erkenning-determinisme.
• Kruis-implementasie-toetse verifieer dat ons kliënt- en bediener-implementasies byte-vir-byte saamstem oor kanonieke koderings. Dit vang afwyking tussen die twee implementasies voor dit produksie bereik.

11. Tak en Vrystelling-Higiëne

Funksietakke bevorder staging slegs deur 'n Gate 1-trekversoek: vereiste ci groen, geen onopgeloste veranderingsversoek nie, geen saamvoegkonflik nie en 'n skoon hersiene boom; die saamvoeging word saamgepers en die tak verwyder. main vorder slegs deur die Gate 2-staging → main-trekversoek en behou afstamming met 'n saamvoegcommit. Direkte takstote is nie die vrystellingswerkvloei nie.

Staging- en produksie-ontplooiings word vanaf die ooreenstemmende beskermde staging- en main-taktoestande ná CI geaktiveer. Trekversoekkode en fork-geloofsbriewe ontvang nie ontplooiingsgeheime nie.

Geheime gebruik in ontplooi-werkvloeie word deur ons CI-platform tot die ontplooi-omgewing beperk. Hulle is nie beskikbaar vir pull-versoek-werkvloeie vanaf forks nie.

12. Gekoördineerde Openbaarmaking

As jy glo jy het 'n sekuriteit-kwesbaarheid in qub gevind, wil ons vinnig daarvan hoor en ons verbind ons om die verslag professioneel te hanteer.

• E-pos support@qub.social met die onderwerp-voorvoegsel [SECURITY].
• Beskryf die kwesbaarheid, stappe om te reproduseer, en enige bewys-van-konsep.
• Gee ons 'n redelike openbaarmaking-venster (tipies 90 dae) voor jy in die openbaar gaan.
• Moenie toegang kry tot data wat nie aan jou behoort nie, diens vir ander gebruikers verminder nie, of data wat tydens navorsing verkry is, behou buite wat nodig is om die kwessie te demonstreer nie.

Ons erken ontvangs binne drie besigheidsdae en hou jou ingelig terwyl ons ondersoek instel. Met jou toestemming krediteer ons verslaggewers in vrystellingsaantekeninge.

12.1 Veilige Hawe

As jou navorsing die reëls hierbo volg (goeie-trou-ondersoek, geen skade aan ander gebruikers of die diens, redelike openbaarmaking-venster), sal ons nie regsaksie teen jou voortsit nie, en ons sal nie wetstoepassing vra om dit te doen nie. Ons behandel jou werk as gemagtigde toetsing en ons sou liewer hê jy moet die fout vind as iemand anders.

Hierdie Veilige Hawe geld vir:

• Navorsing op die lewendige qub.social-diens (nie op toetsvasstellings wat ons vir daardie doel publiseer nie).
• Omgekeerde-ingenieursaktiwiteite van ons gepubliseerde binêres en die open-bron qub-core / qub-app kratte.
• Enige kwesbaarheidsklas — protokol, toepassing, infrastruktuur, voorsieningsketting — wat qub beïnvloed.

Dit geld nie vir sosiale ingenieurswese van qub-spanlede nie, ontkenning-van-diens-toetse nie, of toegang tot ander gebruikers se data buite wat nodig is om die kwessie te demonstreer nie. As jy onseker is of iets binne die Veilige Hawe val, vra eers met dieselfde [SECURITY] onderwerp-voorvoegsel.

13. Eerlike Beperkings

Sekuriteit is 'n praktyk, nie 'n staat nie. Sommige beperkings is die moeite werd om direk te noem:

• Ons is 'n klein span. Ons hersieningsdiepte stem nie ooreen met 'n groot korporasie se toegewyde toepassing-sekuriteit-funksie nie. Ons vergoed met streng outomatiese hekke en 'n minimale aanvaloppervlak, maar ons eis nie onfeilbaarheid nie.
• Die permanensie van ons bergings-agterkant is 'n een-rigting-deur. As 'n fout sealed inhoud vroeër as bedoel dekripteerbaar maak, kan ons dit nie ongedaan maak nie. Ons behandel die seël-vloei met ooreenstemmende sorg.
• Die drand-netwerk is 'n eksterne afhanklikheid. 'n Katastrofiese mislukking van drand sou elke qub se onthullingsgedrag beïnvloed. Ons monitor drand-gesondheid en het noodgeval-dokumentasie vir ketting-migrasie indien nodig. Vir ontsluitdatums meer as 2 jaar uit, wys die seël-tyd-bevestiging-modaal 'n eksplisiete openbaarmaking: lang-horison qubs hang van drand-ketting-duursaamheid af, en 'n toekomstige drand-ketting-migrasie mag herwinningstappe vereis om die qub te ontsluit. Vir ontsluitdatums meer as 5 jaar uit, moet jy 'n ekstra boks merk wat bevestig jy het hierdie risiko gelees en aanvaar voordat die seël voortgaan.
• Kriptografiese primitiewe waarop ons staatmaak, is gestandaardiseer en wyd hersien, maar kriptografie ontwikkel. Waar ons keuses het (post-kwantum-ondertekening, geverifieerde enkripsie), kies ons die meer konserwatiewe opsie.

14. Veranderings aan Hierdie Bladsy

Wesenlike veranderings word aangedui deur die effektiewe datum bo-aan op te dateer. Waar 'n verandering 'n konkrete sekuriteitsverbetering weerspieël, beskryf ons dit kortliks in die openbare veranderingsboek. Waar 'n verandering 'n beleidsverduideliking weerspieël, beskryf ons wat verander het en hoekom.

Vir vrae oor enigiets op hierdie bladsy, e-pos support@qub.social met die onderwerp-voorvoegsel [SECURITY].

15. Veranderingsboek