Bezpieczeństwo w qubie

Data wejścia w życie: 23 września 2026 Wersja: 1.1 — przegląd dokładności wdrożenia

Dla badaczy — szybki przewodnik:

• Gdzie wysyłać raporty: support@qub.social z przedrostkiem podmiotu [SECURITY].
• Co uwzględnić: luka, kroki do odtworzenia oraz wszelkie dowody koncepcji.
• Nasza odpowiedź: Potwierdzamy otrzymanie w ciągu 3 dni roboczych i dążymy do wysłania poprawki w ciągu 90 dni.
• Bezpieczna przystań: nie będziemy podejmować działań prawnych przeciwko badaniom w dobrej wierze, które przestrzegają zasad w §12 (brak dostępu do danych, które do Ciebie nie należą, brak pogorszenia działania usługi, brak przechowywania uzyskanych danych dłużej niż to konieczne do wykazania problemu, zapewnij nam rozsądny okres na ujawnienie).

Pełne informacje znajdują się w §12 (Koordynowane ujawnianie).

Kim jesteśmy

qub.social jest obsługiwany przez VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. Odniesienia do "qub", "my", "nas" i "nasz" oznaczają ten podmiot.

Kontakt bezpieczeństwa: support@qub.social z prefiksem tematu [SECURITY].

1. Nasze podejście

qub jest infrastrukturą zaufania. Produkt jest nic niewart, jeśli nie jest bezpieczny, więc bezpieczeństwo nie jest funkcją — jest substratem. Ta strona opisuje, w konkretnych terminach, jak chronimy nasz stos, Twoje dane i integralność zapieczętowanej treści.

Wartość weryfikowalnego zobowiązania czasowego rośnie w miarę, jak coraz większa część internetu staje się generowana przez maszyny. Zweryfikowana transakcja przechowywania lub kotwica w dzienniku przejrzystości może ustalić, że szyfrogram istniał nie później niż w czasie jego bloku; zapieczętowany artefakt osobno udowadnia integralność treści, powiązanie z rundą drand i wszelkie podpisy autorów. Utrzymywanie tych twierdzeń oddzielnie jest standardem, do którego odnosi się ta strona.

Nie prosimy Cię o zaufanie nam. Projektujemy tak, by zaufanie wymagane od nas było tak małe, jak to możliwe, a tam, gdzie zaufanie jest wymagane, wyjaśniamy dokładnie, co jest zaufane i dlaczego.

Trzy zasady napędzają każdą decyzję projektową:

• Zminimalizuj to, co serwer może zobaczyć. W domyślnym przepływie wiadomości w przeglądarce, tekst zwykły i klucz opakowujący pozostają na twoim urządzeniu. Uszczelnianie po stronie serwera w Builderze, współpodpisywanie paktu i wyraźnie włączona procedura odzyskiwania mają różne granice zaufania, przedstawione poniżej. Tam, gdzie przechowujemy metadane, ograniczamy je do tego, czego potrzebuje wybrana funkcja.
• Dokonaj kompromisu ograniczonego lokalnie. Naruszenie któregokolwiek z komponentów (nasz serwer, dostawca poczty elektronicznej, węzeł dranda) nie powinno ujawniać zaszyfrowanej treści, która jeszcze nie osiągnęła swojego czasu ujawnienia.
• Uczyń protokół możliwym do audytu. Zapieczętowany artefakt można zweryfikować od początku do końca za pomocą kryptografii publicznej. Nie musisz ufać qub usługa weryfikacji qub artefakt.

2. Model zagrożeń

2.1 Przed czym chronimy

• Atakujący, który uzyska dostęp do odczytu naszych przechowywanych danych po stronie serwera przed czasem ujawnienia. W domyślnym przepływie prywatnej przeglądarki uzyskują metadane i nieprzezroczyste opakowane bajty, a nie tekst jawny ani K. Ta ochrona nie dotyczy K wyraźnie zachowanego do odzyskiwania, jawnej/publicznej dostawy po jego rundzie drand ani tekstu jawnego tymczasowo dostarczonego do Buildera /api/v1/seal i przepływy pracy paktu.
• Atakujący, który przechwytuje ruch między Twoją przeglądarką a naszą infrastrukturą. TLS kończy się na naszym węźle brzegowym CDN; zapieczętowane ładunki są już zaszyfrowane przed przesyłem.
• Napastnik, który manipuluje przechowywaną ładunkiem. Uwierzytelnianie zewnętrznej otoczki (gdy obecne), dekodowanie kanoniczne, skrót treści, qub_id ponowne wyprowadzenie, powtarzające się powiązania i opcjonalne podpisy powodują, że manipulacja nie przechodzi weryfikacji; przeglądarka odmawia jej renderowania.
• Atakujący, który próbuje powiązać sfałszowany adres e-mail autora z kluczem podpisującym. Poświadczenie e-mail wymaga posiadania zarówno prywatnego klucza podpisującego, jak i jednorazowego kodu dostarczonego na skrzynkę e-mail.
• Skompromitowany operator sygnału drand. Sieć drand używa progowych podpisów BLS wśród wielu niezależnych operatorów; mniejszość nie może sfałszować podpisów wczesnego uwolnienia.

2.2 Przed czym nie możemy chronić

Jesteśmy uczciwi co do naszych granic. qub nie może obronić przed:

• Kompromis twojego urządzenia przed jego zamknięciem. Lokalne keyloggery, złośliwe rozszerzenia przeglądarki lub fizyczny dostęp do odblokowanego urządzenia mogą przechwycić tekst jawny w momencie jego tworzenia.
• Załamanie progu drand. Wiele niezależnych organizacji prowadzi sieć drand, aby to utrudnić, ale nie jest to kryptograficznie niemożliwe: jeśli wystarczająca liczba operatorów dojdzie do porozumienia, mogliby wcześniej odtworzyć klucze timelock.
• Właściwości wydania prawidłowej kopii. Publiczny/nieosłonięty qub staje się możliwy do odszyfrowania po jego rundzie drand. Prywatny/owinięty qub wymaga dodatkowo K; każdy, kto uzyska zarówno zapisane bajty, jak i K, może odszyfrować po rundzie. Rekordy w trwałej pamięci i w zalogowanym dzienniku nie mogą zostać przywołane jedynie przez usunięcie ich z powierzchni produktu qub.
• Globalny przeciwnik, który łamie podstawową kryptografię (AES-GCM, założenia dotyczące parowania BLS12-381, SHA3-256, ML-DSA-65). Jeśli te prymitywy zawiodą, cały ekosystem kryptograficzny będzie miał poważniejsze problemy.

3. Kryptografia po stronie klienta

W domyślnym przepływie wiadomości przeglądarki szyfrowanie treści odbywa się przed żądaniem przesyłania. Dwa wyraźne ścieżki różnią się: Builder /api/v1/seal celowo wysyła tekst jawny i klucz generowany przez dzwoniącego do Pracownika w celu zamknięcia w pamięci, a etapowanie/podpisywanie paktu wysyła podpisany ustrukturyzowany pakt do serwisu, aby mógł sfinalizować dwustronny artefakt. Żadnego z tych wyjątków nie należy mylić z end-to-end szyfrowaniem ścieżki przeglądarki.

3.1 Szyfrowanie czasowe

qub używa tlock — szyfrowania opartego na tożsamości kluczowanego do przyszłej rundy beaconu drand. Szyfrowanie postępuje w Twojej przeglądarce z użyciem klucza publicznego sieci drand; klucz deszyfrujący jest uwalniany publicznie przez sieć drand tylko wtedy, gdy zostaje osiągnięta docelowa runda. Nikt, w tym my, nie może zrekonstruować klucza deszyfrującego z wyprzedzeniem.

Celujemy w łańcuch quicknet:

• 3-sekundowy okres rundy
• Tryb unchained (każda runda jest niezależna)
• Podpisy G1 BLS12-381
• Hash łańcucha 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

Klucz publiczny łańcucha quicknet i czas genesis są skompilowane do klienta. Nie pobieramy parametrów łańcucha w czasie wykonania, więc złośliwy węzeł nie może podstawić łańcucha, który kontrolujemy.

3.2 Szyfrowanie symetryczne

Schemat tlock opakowuje klucz treści AES-256-GCM. AES-GCM zapewnia uwierzytelnione szyfrowanie: pojedynczy bit przełączony w szyfrogramie powoduje, że deszyfrowanie zawodzi, zamiast produkować po cichu uszkodzony tekst jawny.

3.3 Kanoniczna serializacja

Struktury protokołu są serializowane przy użyciu deterministycznego CBOR (RFC 8949 §4.2 podstawowe deterministyczne kodowanie). Dwie implementacje kodujące tę samą strukturę logiczną produkują identyczny CBOR. Kompletnie zapieczętowane ładunki są nie deterministyczny: tlock i zewnętrzna osłona szyfrowania używają świeżej losowości. Skrót ciała jest obliczany na surowych bajtach ciała, podczas gdy kodowanie kanoniczne sprawia, że otaczające podpisane/strukturę przewodową są jednoznaczne.

Napisaliśmy enkoder CBOR ręcznie zarówno dla naszych implementacji klienta, jak i serwera, zamiast polegać na generycznej bibliotece serializacji — wymóg to dokładność, nie ergonomia, a testy własności działają w obu implementacjach, by zweryfikować, że się zgadzają.

Test regresyjny twierdzi, że kanoniczny format na drucie nie zawiera żadnej sekwencji bajtów marki qub poza kluczem pola qub_id prymitywu protokołu. Format na drucie jest celowo neutralny względem marki — każdy zgodny widz (nasz lub strony trzeciej) może renderować każdy qub z trwałego magazynu, niezależnie od tego, które wdrożenie go zapieczętowało. Test jest tripwirem, który zapobiega przyszłej zmianie przed przypadkowym zaszyciem odniesienia marki w bajty, które, gdy są w trwałym magazynie, nie mogą być przepisane.

3.4 Haszowanie ciała i integralność przed ujawnieniem

Każdy zapieczętowany ładunek zawiera skrót SHA3-256 surowych bajtów swojego ciała. Skrót jest powiązany z qub_id a kiedy włączone jest podpisywanie autorstwa, do pola podpisu V2. Przeglądarka ponownie oblicza go po odszyfrowaniu i odrzuca niezgodność.

32-bajtowy identyfikator zawartości qub_id pochodzi z 108-bajtowego wstępnego obrazu obejmującego wersję protokołu, typ treści, znaczniki czasu utworzenia i odblokowania, opcjonalny znaczek czasowy wyniku (lub jego zerowy sentinel), docelową rundę drand, skrót treści oraz SHA3-256 opcjonalnego tytułu znormalizowanego według NFC. Bramka lub CDN nie mogą zmienić żadnego powiązanego pola w sposób spójny i nadal przejść ponownego wyprowadzenia. Tytuły są ograniczone do 100 punktów kodowych NFC i odrzucane, jeśli należą do wspólnej wrogiej/sterowania klasą punktów kodowych (w tym nadpisania bidi, znaki o zerowej szerokości, blok tagów, BOM, C0, C1 i DEL).

3.5 Podpisywanie (ML-DSA-65)

Podpisywanie autorstwa używa ML-DSA-65 (FIPS 204), znormalizowanego przez NIST schematu podpisu postkwantowego. Celowo wybraliśmy prymityw postkwantowy do podpisywania, ponieważ zapieczętowana treść jest trwała: podpis, który weryfikuje dzisiaj, musi nadal weryfikować dekady później, w tym po tym, jak duże komputery kwantowe staną się praktyczne.

Klucze podpisywania są generowane w przeglądarce. Lokalny sekret jest owinięty w nieekstrakcyjalny klucz WebCrypto przed zapisaniem w IndexedDB. Jeśli używana jest funkcja odzyskiwania po urządzeniu związana z kontem, zaszyfrowany AEAD przenośny pakiet kluczy jest przechowywany po stronie serwera; jego zaszyfrowany klucz tajny jest powiązany z niezmiennym identyfikatorem konta, a serwis weryfikuje publiczną powłokę, ale nie może odszyfrować materiału tajnego. Surowe bajty klucza prywatnego nie są wysyłane na serwer. Klucze publiczne i rekordy poświadczeń są przechowywane w celu weryfikacji i wyświetlania tożsamości.

To samo in-browser deszyfrowanie tlock stosuje się wewnątrz qub embed: gdy zapieczętowany qub jest renderowany przez <qub-embed> na stronie strony trzeciej, deszyfrowanie nadal dzieje się w iframe embed w przeglądarce widza. Embed nie zmienia modelu zaufania — tekst jawny nigdy nie jest odszyfrowywany na serwerze qub.

3.6 Publiczne przypisanie — opt-in

Zapieczętowane quby nie niosą wskaźnika on-chain do swojego twórcy, chyba że twórca wyraźnie wybierze, by go dołączyć. Gdy pieczętujesz quba, aplikacja referencyjna emituje tag magazynu Author (64-znakowy szesnastkowy odcisk palca Twojego klucza publicznego podpisującego) tylko wtedy, gdy "Publiczne przypisanie" jest włączone na etapie wyboru daty. Z wyłączonym przełącznikiem — domyślnie — żaden tag Author nie jest pisany, a qub jest nieprzypisany w trwałym magazynie: nic w magazynie nie łączy uploadu z Twoim pseudonimem, Twoim e-mailem ani Twoimi innymi qubami. Z włączonym przełącznikiem odcisk palca rozwiązuje się do Twojego @handle przez łańcuch atestacji w §6.3 / §10, a odliczanie widza pokazuje "Zapieczętowane przez @{handle}" przed ujawnieniem.

To jest celowa ochrona przed ryzykiem wyliczania, jakie stworzyłby zawsze-włączony tag Author: strona trzecia, która pozna odcisk palca twórcy, mogłaby inaczej przeszukiwać trwały magazyn po tagu i zrekonstruować pełen historyczny dorobek tego twórcy. Opt-in przypisanie zamyka ten kanał — tylko quby, które twórca wyraźnie zdecyduje się przypisać, pojawiają się pod odciskiem palca w trwałym magazynie.

Strona profilu /u/{handle} jest kartą zweryfikowanej tożsamości — pseudonim, opcjonalna nazwa wyświetlana + URL, plakietka "verified email" (bez adresu) i krótka forma kryptograficznego odcisku palca. Nie wymienia qubów twórcy. Odwiedzający, którzy chcą zobaczyć konkretnego quba od twórcy, podążają bezpośrednio za URL dostarczenia tego quba.

3.7 Zewnętrzna warstwa szyfrowania

Nawet po tym, jak deszyfrowanie timelock stanie się matematycznie możliwe — gdy podpis drand dla powiązanej rundy zostanie opublikowany — sama kanoniczna warstwa timelock pozwala indeksatorowi na masowe odszyfrowanie wykrywalnych qubów. Prywatna dostawa zamyka ten kanał poprzez dodatkową warstwę symetryczną wokół danych zaszyfrowanych timelock (Protokół §13). Publiczna dostawa celowo pomija ten wrapper, aby powiadomienia, osadzenia i linki odkrywania mogły działać bez tajnego fragmentu.

Opakowanie używa AES-256-GCM, znormalizowanego przez NIST uwierzytelnionego szyfru, ze świeżym 256-bitowym kluczem K generowanym per qub przez CSPRNG Twojej przeglądarki. K jest związany z qub_id quba jako uwierzytelnione dane dodatkowe, więc klucz z jednego quba nie może być ponownie użyty do deszyfrowania innego quba.

K nigdy nie dociera do naszych serwerów w domyślnym trybie prywatnej przeglądarki. Jest kodowane w fragmencie URL linku do udostępnienia (https://qub.social/c/<tx_id>#<base64url(K)>). Przeglądarki nie przesyłają fragmentów URL do serwerów—RFC 3986 umieszcza fragment poza żądaniem—więc qub.social, bramy magazynowania, CDN i monitorowanie żądań są ślepe na K w tym przepływie. Przechowywane OuterWrapper jest rozpoznawalnym, ustrukturyzowanym CBOR, ale jego uwierzytelnione pole szyfrogramu ukrywa wnętrze SealedQub strukturę i nie można jej otworzyć bez K.

Konsekwencje netto:

• qub.social nie może odszyfrować domyślnych pieczęci prywatnej przeglądarki jedynie z przechowywanych danych. Naruszenie magazynu danych sięga nieprzezroczystego szyfrogramu bez klucza. Publiczne quby i quby z możliwością odzyskiwania mają z założenia różną ekspozycję.
• Utrata fragmentu jest nieodwracalna bez wybranego kanału odzyskiwania. Jeśli zapiszesz prywatny link bez fragmentu i nie włączyłeś odzyskiwania, qub staje się nieczytelny przez ten link. Proces seal ujawnia wyraźne powiadomienie „zapisz ten adres URL” z tego powodu.
• Odzyskiwanie opcjonalne. Kiedy zdecydujesz się na otrzymywanie e-maili dotyczących cyklu życia twórcy dla quba ORAZ e-mail pasuje do Twojej zweryfikowanej tożsamości, akceptujemy K przy przesyłaniu, przechowujemy pełny URL dostawy w zaszyfrowanym zapisie historii Twojej tożsamości i używamy go jako linku w e-mailu potwierdzającym zapieczętowanie. Ta wymiana — kanał odzyskiwania po stronie serwera w zamian za pewną czystość end-to-end — działa tylko po wyraźnym wyrażeniu zgody i tylko dla tego quba. Domyślne ustawienie to kryptograficzne niszczenie.

Endpoint Worker'a po stronie serwera /api/v1/seal (używany przez agentów AI i innych klientów API) wymaga, aby wywołujący wygenerował K za pomocą CSPRNG, zachował go lokalnie i dostarczył jako wrapper_key_b64url. Worker z konieczności widzi w pamięci zarówno tekst jawny, jak i K na tej wyraźnie zaufanej ścieżce, ale nie utrwala żadnego z nich. Obowiązkowy Idempotency-Key zapobiega utworzeniu drugiego rozliczonego quba przez utraconą odpowiedź, podczas gdy zachowany przez wywołującego K można połączyć z odtworzonym URL bez fragmentu. Różni się to od domyślnej ścieżki przeglądarki, gdzie K nigdy nie dociera do Worker'a, chyba że twórca wyraźnie włączy odzyskiwanie.

4. Transport i krawędź

4.1 TLS

Ruch przeglądarki do qub jest obsługiwany przez HTTPS na krawędzi Cloudflare. Odpowiedzi ustalają HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). Dokładna negocjowana wersja TLS i zestaw szyfrów są określane przez aktywną konfigurację edge, a nie przez kod aplikacji. Nie udostępniamy osobno dostępnego serwera źródłowego.

4.2 Bezpieczeństwo treści

Skompilowany klient jest serwowany ze ścisłymi nagłówkami content-type i cache. Powłoka SPA jest pojedynczym originem. Nie osadzamy skryptów stron trzecich dla analityki ani reklamy. Dwa touchpoints stron trzecich w produkcie są obydwa wąsko ograniczone: przepływ zakupu opuszcza SPA całkowicie z pełno-stronicowym przekierowaniem do checkout hostowanego przez Stripe (https://checkout.stripe.com/…) — UI Stripe nigdy nie wykonuje się w naszym originie i nigdy nie widzimy danych karty — a przepływ pieczęci ładuje widget Turnstile Cloudflare, prywatnościowo-zachowującą alternatywę CAPTCHA, którą Cloudflare renderuje wewnątrz własnego sandboxowanego iframe. Żadna ze stron nie może odczytać reszty strony.

Ten qub osadź iframe (serwowany z qub.social/embed/{tx_id} i załadowano na strony osób trzecich przez embed.js) posiada własną Politykę Bezpieczeństwa Treści (Content-Security-Policy). Jej connect-src lista dozwolonych 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh, i https://drand.cloudflare.com. Ramka iframe działa z sandbox="allow-scripts allow-top-navigation-by-user-activation" (nie allow-same-origin): strona gospodarza nie może odczytać swojego DOM i nie może nawigować po gospodarzu, chyba że po akcji użytkownika.

4.3 CORS i zakres pobierania

Klient przeglądarki wykonuje żądania fetch tylko do:

• Nasze własne API (api.qub.social i odpowiedniki sceniczne)
• Bramy magazynowe (tylko do odczytu, do pobierania bajtów w formie opakowanej-prywatnej lub czystej-publicznej — §3.6)
• punkty końcowe drand beacon (tylko do odczytu, dla podpisów rund w czasie ujawnienia)

Cele osadzenia są egzekwowane przez jego CSP. Docelowe miejsca głównej SPA są ustalone w kodzie i konfiguracji oraz testowane przez przeglądarkę i kontrole integracji; Integralność podzasobów nie jest kontrolą celu sieciowego.

Osadzenie pobiera przechowywane bajty przez dozwolone pochodzenia qub/storage, odsłania prywatne dane w przeglądarce używając K z fragmentu URL, oraz pobiera podpisy rund w czasie ujawnienia z dwóch dozwolonych pochodzeń drand. Główna SPA używa zestawu czterech punktów końcowych jako awaryjnego config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh, i api3.drand.sh) tak więc awaria jednego punktu końcowego nie blokuje ujawniania. Osadzony CSP odrzuca połączenia spoza swojej jawnej listy.

5. Infrastruktura po stronie serwera

5.1 Serverless Edge

Nasze API działa w całości na zarządzanym środowisku serverless na krawędzi. Nie ma żadnych maszyn wirtualnych, kontenerów ani trwałych procesów serwera, którymi administrujemy. To dramatycznie redukuje powierzchnię ataku, za którą jesteśmy odpowiedzialni: nie utrzymujemy systemu operacyjnego, serwera WWW ani środowiska uruchomieniowego aplikacji, które musimy łatać.

Stosowany jest osobny middleware public-CORS Access-Control-Allow-Origin: * do następującego ustawionego ścieżki: /embed.js, /embed/v1.js, wszystko pod /embed/; /api/v1/telemetry; /api/v1/openapi.json; wszystko pod /api/v1/qub/ (w tym bajty, metadane, dowód, zaangażowanie, powiadomienie i subtrasy push); wszystko pod /api/v1/log/; publiczne obsługiwanie wyszukiwań pod /api/v1/handle/; a publiczny awatar czyta poniżej /api/v1/identity/avatar/. Jej pozwolenia na lot testowy GET, POST, i OPTIONS z Content-Type nagłówek żądania. Ta powierzchnia oparta na prefiksie jest szersza niż tylko wywołania, które obecnie wykonuje osadzenie, więc każdy obsługujący poniżej tych prefiksów musi nadal wymuszać własną walidację, uwierzytelnianie, limity prędkości i kontrolę nadużyć. Inne ścieżki API zachowują politykę CORS ograniczoną do qub.social.

5.2 Magazyn

• Magazyny metadanych i koordynacji przechowywać rekordy tożsamości i poświadczeń, uprawnienia i odniesienia do faktur, rekordy kluczy API, wpisy na liście odmów, sesje, stan niezmienności, kolejki oraz stan limitów szybkości / współbieżności. Różne potrzeby spójności wykorzystują KV, D1 i Durable Objects zamiast jednego uniwersalnego magazynu.
• Nasze repozytorium obiektów jest również podłożem trwałości. Przechowuje dokładnie zapakowane lub nieopakowane bajty qub potwierdzone przez przesyłanie, wpisy do dziennika transparentności i węzły Merkle kluczowane współrzędnymi, materiał kotwiczący, strukturalne dzienniki zdarzeń oraz pamięci podręczne odpowiedzi/metadanych.
• Stałe publiczne przechowywanie przechowuje kotwice dziennika przejrzystości oraz, dla ścieżki T3 lub odroczonej publikacji, pojedyncze transakcje qub. Nie obsługujemy tej sieci. Prywatne ładunki przeglądarki pozostają tam nieprzezroczyste, chyba że posiadacz ma również K; publiczne/ogolone ładunki celowo nie mają tej dodatkowej warstwy zdolności łączenia.

Domyślny przepływ komunikatów przeglądarki nie przechowuje tekstu nieszyfrowanego na infrastrukturze qub. Builder /api/v1/seal obsługuje zwykły tekst i K w pamięci, ale nie przechowuje żadnego z nich. Etapowanie Paktu musi przechowywać podpisany, ustrukturyzowany pakt aż do jego współpodpisania, wycofania lub wygaśnięcia. Opcjonalne odzyskiwanie przechowuje zdolność dostarczenia (pełny link zawierający fragment), aby można było ją później odzyskać. W związku z tym nie opisujemy całej warstwy przechowywania jako „tylko metadane”.

5.3 Sekrety

Sekrety (portfele do podpisywania, tokeny dostawcy i klucze HMAC) są dostarczane poprzez powiązania sekretów/platformy/środowiska, a nie przez kontrolę źródła. Komponenty w czasie wykonywania otrzymują tylko te powiązania, których potrzebują. Procedury rotacji i nakładania się są specyficzne dla komponentu; nie twierdzimy, że istnieje jeden uniwersalny mechanizm rotacji automatycznej lub audytowanej.

5.4 Logowanie i telemetria

Strukturyzowane logi JSON są pisane na każde żądanie API z ID korelacji powierzchnionym w nagłówku odpowiedzi X-Request-Id. Telemetria klienta jest anonimowa — bez identyfikatora urządzenia, bez adresu IP, bez podglądu treści. Zdarzenia są buforowane w pamięci i opróżniane w trybie best-effort; nieudane opróżnienie jest odrzucane, nie ponawiane. Telemetria jest zaprojektowana, by być wyłączalna w warstwie sieci bez wpływu na produkt.

6. Uwierzytelnianie

6.1 Logowanie magic-link

Logowanie odbywa się przy użyciu jednorazowego tokena podpisanego HMAC, wysyłanego na Twój adres e-mail. Link jest ważny przez 15 minut, a jego wykorzystanie jest atomowo rejestrowane, więc jednoczesne lub powtórne użycie kończy się niepowodzeniem. W przypadku sukcesu przeglądarka otrzymuje nieprzezroczysty __Host-qub_session ciastko z Secure, HttpOnly, SameSite=Strict, i Path=/ atrybuty.

Sesje mają 30-dniowy limit bezczynności i 90-dniowy absolutny limit, obracają się po 24 godzinach i akceptują tylko bezpośrednio poprzednią generację w ramach 120-sekundowego okresu łaski dla utraconej odpowiedzi. Wrażliwe zmiany konta wymagają uwierzytelnienia w ciągu poprzednich 10 minut. Tajny klucz podpisu HMAC jest powiązaniem z platformą; samo odczytanie tylko metadanych nie generuje ważnego tokena.

6.2 Klucze API (poziom programisty)

Klucze API programisty używają prefiksu qub_sk_ dla łatwego rozpoznania i grepowalności. Każdy klucz:

• Jest powiązany z kontem, zakresami i opcjonalną listą dozwolonych adresów IP w formacie CIDR
• Jest wyświetlany w formie surowej raz; trwałe zapisy przechowują jego skrót SHA-256, a nie sekret posiadacza
• Może być obracany z jednugodzinnym okresem przejściowym, w którym stary klucz odnosi się do zamiennika
• Ma niezależny stan limitu ilości i prędkości
• Nigdy nie jest w pełni rejestrowany; dzienniki zapisują tylko kluczowy identyfikator

Endpointy zarządzania kluczami admin są ogrodzone za oddzielnym poświadczeniem admin.

6.3 Atestacja e-mail (podpisywanie autorstwa)

Powiązanie adresu e-mail z kluczem podpisującym wymaga:

1. Posiadania prywatnego klucza podpisującego (podpisujesz wyzwanie)
2. Posiadania skrzynki e-mail (wpisujesz 6-cyfrowy kod dostarczony e-mailem)

Każdy sam w sobie jest niewystarczający. Odwołanie jest podpisanym rekordem na Twoim własnym koncie i działa natychmiast; widzowie pobierający atestację widzą stan odwołany i wyświetlają odpowiednio.

7. Płatności

Wprowadzanie i przetwarzanie kart działa w ramach kasy hostowanej przez Stripe. Nigdy nie otrzymujemy numerów kart, dat ważności ani kodów CVC. Przechowujemy identyfikatory klientów i subskrypcji Stripe, stan subskrypcji oraz dane okresowe w rekordach uprawnień/kluczy API, aby można było uzgadniać dostęp, odnowienia, pomiar, anulowania i zwroty. Oświadczenia o prywatności i bezpieczeństwie Stripe regulują sposób przetwarzania danych płatności.

Endpoint pieczęci krzyżowo sprawdza rekord uprawnień przeciwko identyfikatorowi urządzenia i, dla zalogowanych użytkowników, przeciwko powiązanej tożsamości. Uprawnienie nie może być ponownie użyte między urządzeniami bez tego, by użytkownik wyraźnie je przywrócił przez logowanie magic-link.

8. Odporność na nadużycia

8.1 Wykrywanie botów

Przepływ pieczęci jest ogrodzony przez prywatnościowo-zachowującą alternatywę CAPTCHA, która nie używa ciasteczek do śledzenia i nie odciska palca dla reklamy. Nieudane wyzwanie jest odrzucane przez nasz edge Worker przed jakimkolwiek przetwarzaniem po stronie pieczęci.

8.2 Ograniczanie częstotliwości

Ograniczenia częstotliwości są egzekwowane na kilku warstwach:

• Per-IP i per-klucz ograniczenia na endpointy pieczęci, odczytu i uwierzytelnienia
• Per-e-mail ograniczenia na żądania magic-link (zapobiega zalewaniu skrzynki)
• Per-kontrahent ograniczenia na e-maile zaproszeń do paktów (dziesięć na adres odbiorcy na dzień UTC, główne łagodzenie spam-relay; uczciwe pakty prawie nigdy nie zbliżają się do limitu)
• Per-IP ograniczenia na przesyłanie telemetrii

Liczniki i atomowe żądania są rozproszone między KV, Durable Objects oraz powiązania limitu szybkości platformy zgodnie z wymaganiami spójności punktu końcowego. Żądania objęte limitem szybkości zwracają 429; punkty końcowe, które mogą obliczyć okno ponownej próby, obejmują Retry-After.

8.3 Moderacja treści

Domyślna trasa przesyłania przeglądarki nie może skanować ciała: otrzymuje tylko klienta-zapieczętowany artefakt. Budowniczy /api/v1/seal trasa widzi jawny tekst tymczasowo, a etap przygotowawczy paktu utrzymuje uporządkowane warunki aż do finalizacji, ale te wyjątki zaufania nie przekształcają ogólnej ścieżki przesyłania niewidomej na bajty w skaner treści. Moderacja operacyjna jest lista blokowanych na warstwie przeglądarki: qub znajdujący się na liście odmów jest odrzucany przez naszą przeglądarkę niezależnie od tego, czy przechowywana zawartość jest nadal dostępna. Umieszczenie na liście odmów nie cofa trwałych bajtów, wpisów w dzienniku przejrzystości ani danych w stałej sieci, które zostały już opublikowane.

Zgłoszenia nadużyć są ograniczane częstotliwościowo z użyciem jednokierunkowego hashu IP zgłaszającego; nie przechowujemy IP w jasny sposób w tym celu.

9. Łańcuch dostaw i integralność budowania

9.1 Przypinanie toolchaina

Wersje kompilatora i środowiska uruchomieniowego są przypięte w konfiguracji repozytorium, a zależności są rozwiązywane za pomocą zatwierdzonych plików blokady. CI sprawdza aktualność plików generowanych oraz invariatywność wrażliwą na powtarzalność. Nie twierdzimy jednak, że każdy czysty build jest identyczny bit po bicie na wszystkich obsługiwanych maszynach.

9.2 Linty i analiza statyczna

Workspace włącza nasze najściślejsze grupy lintów na poziomie deny. CI traktuje każde ostrzeżenie — w tym ostrzeżenia o linkach dokumentacji — jako awarię budowania. To jest celowe: używamy ścisłości lintów jako tripwire dla subtelnych regresji.

9.3 Bramki CI

Proces CI obejmuje formatowanie i rygorystyczne lintery; testy Rust, WASM/przeglądarka, Worker, embed i API; sprawdzanie typów; pokrycie kodu; sprawdzanie mutacji/inwariantów; analizę statyczną zależności i procesów; sprawdzanie kluczy i18n, pokrycia, odchyleń i wrogich punktów kodu; świeżość wygenerowanej dokumentacji/API/bazy wiedzy; kontrolę inwentarza dokumentów i linków wewnętrznych; budżety arkuszy stylów i pakietów; oraz walidację OpenAPI. Niektóre kosztowne zadania związane z mutacją są planowane zamiast uruchamiane przy każdym pushu.

Pojedynczy wymagany ci Podsumowanie pozostaje czerwone, jeśli jakiekolwiek wymagane zadanie nie powiedzie się. Workflowy chronionych gałęzi i wdrażania wykorzystują ten wynik zamiast powielania mniejszej bramki bezpieczeństwa.

9.4 Testowanie mutacji

Cotygodniowe zadanie uruchamia testowanie mutacji wobec krytycznych pod względem bezpieczeństwa czystych modułów: haszowanie, kanoniczny CBOR, pieczęć, odblokowanie, newtypes formatu na drucie, walidatory typów protokołu i przestrzeń nazw pseudonimów. Testowanie mutacji odpowiada na pytanie "czy nasz zestaw testów łapie subtelnie zły kod?" — jeśli zmutowana implementacja wciąż przechodzi wszystkie testy, wiemy, że mamy lukę pokrycia testami i adresujemy ją.

9.5 Git hooks

Lokalne hooki (pre-commit, pre-push) odzwierciedlają bramki CI, więc regresje są łapane zanim opuszczą maszynę programisty. Hooki są instalowane przez skrypt repo; nie są obchodzone w naszym workflow, a CI jest autorytatywną bramką, jeśli są pominięte.

10. Testowanie

Krytyczny dla bezpieczeństwa kod niesie trzy rodzaje testów:

• Testy jednostkowe weryfikują oczekiwane zachowanie na znanych wejściach, w tym wektory testowe wyprowadzone ze specyfikacji protokołu.
• Testy własności generują tysiące arbitralnych wejść i twierdzą niezmienniki: kanoniczne CBOR round-trips, round-trips weryfikacji podpisu, predykaty powiązania e-mail, determinizm potwierdzenia paktu.
• Testy międzyimplementacyjne weryfikują, że nasze implementacje klienta i serwera zgadzają się bajt-w-bajt na kanonicznych kodowaniach. To łapie rozbieżność między dwiema implementacjami zanim dotrze do produkcji.

11. Higiena gałęzi i wydań

Gałęzie funkcji postępują staging tylko przez pull request Gate 1: wymagane ci zielony, brak nierozwiązanych próśb o zmianę, brak konfliktu scalenia i czyste, sprawdzone drzewo; scalenie jest typu squash-and-delete. main posuwa się naprzód tylko przez Bramę 2 staging → main pull request i zachowuje historię przodków za pomocą commita scalającego. Bezpośrednie wypychanie na gałąź nie jest procesem wydania.

Wdrażanie na środowisko staging i produkcyjne jest wyzwalane z odpowiedniego chronionego staging i main gałęzie stanu po CI. Kod z pull requestów i dane uwierzytelniające fork nie otrzymują sekretów wdrożeniowych.

Sekrety używane w przepływach wdrożenia są ograniczone do środowiska wdrożenia przez naszą platformę CI. Nie są dostępne dla przepływów żądań ściągnięcia z forków.

12. Skoordynowane ujawnienie

Jeśli sądzisz, że w qub istnieje podatność bezpieczeństwa, chcemy o tym usłyszeć szybko i zobowiązujemy się obsłużyć zgłoszenie profesjonalnie.

• Napisz na support@qub.social z prefiksem tematu [SECURITY].
• Opisz podatność, kroki do odtworzenia i każdy proof-of-concept.
• Daj nam rozsądne okno ujawnienia (zwykle 90 dni) przed wyjściem publicznie.
• Nie uzyskuj dostępu do danych, które nie należą do Ciebie, nie degraduj usługi dla innych użytkowników i nie zachowuj danych pozyskanych podczas badania poza tym, co konieczne do zademonstrowania problemu.

Potwierdzamy otrzymanie w ciągu trzech dni roboczych i utrzymujemy Cię informowanym, gdy badamy. Za Twoją zgodą przypisujemy zgłaszających w notach wydania.

12.1 Safe Harbor

Jeśli Twoje badanie przestrzega reguł powyżej (badanie w dobrej wierze, brak szkody dla innych użytkowników lub usługi, rozsądne okno ujawnienia), nie podejmiemy działań prawnych przeciwko Tobie i nie poprosimy o to organów ścigania. Traktujemy Twoją pracę jako autoryzowane testowanie i wolelibyśmy, by błąd znalazł ktoś z badaczy bezpieczeństwa niż atakujący.

Ten Safe Harbor stosuje się do:

• Badań na żywej usłudze qub.social (nie na fikstach testowych, które publikujemy w tym celu).
• Inżynierii odwrotnej naszych opublikowanych plików binarnych i open-source'owych skrzynek qub-core / qub-app.
• Każdej klasy podatności — protokół, aplikacja, infrastruktura, łańcuch dostaw — która dotyczy qub.

Nie stosuje się do socjotechniki członków zespołu qub, testów denial-of-service ani uzyskiwania dostępu do danych innych użytkowników poza tym, co potrzebne do zademonstrowania problemu. Jeśli nie jesteś pewny, czy coś mieści się w Safe Harbor, zapytaj najpierw z tym samym prefiksem tematu [SECURITY].

13. Uczciwe ograniczenia

Bezpieczeństwo jest praktyką, nie stanem. Pewne ograniczenia warto wymienić bezpośrednio:

• Jesteśmy małym zespołem. Nasza głębokość przeglądu nie dorównuje funkcji dedykowanego bezpieczeństwa aplikacji w dużej korporacji. Kompensujemy ścisłymi automatycznymi bramkami i minimalną powierzchnią ataku, ale nie roszczemy nieomylności.
• Trwałość magazynu jest jednokierunkowymi drzwiami. Jeśli błąd powoduje, że zapieczętowana treść staje się odszyfrowywalna wcześniej niż zamierzono, nie możemy tego cofnąć. Traktujemy przepływ pieczęci z odpowiednią ostrożnością.
• Sieć drand jest zależnością zewnętrzną. Katastrofalna awaria drand dotknęłaby zachowanie ujawnienia każdego quba. Monitorujemy zdrowie drand i mamy dokumentację awaryjną dla migracji łańcucha, jeśli wymagana. Dla dat odblokowania ponad 2 lata w przód, modal potwierdzenia w czasie pieczęci pokazuje wyraźne ujawnienie: quby długohoryzontalne zależą od trwałości łańcucha drand, a przyszła migracja łańcucha drand może wymagać kroków odzyskiwania, by odblokować quba. Dla dat odblokowania ponad 5 lat w przód, musisz odhaczyć dodatkowe pole potwierdzające zapoznanie się z tym ryzykiem i jego akceptację przed kontynuowaniem pieczęci.
• Prymitywy kryptograficzne, na których polegamy, są znormalizowane i szeroko przejrzane, ale kryptografia ewoluuje. Tam, gdzie mamy wybory (podpisywanie postkwantowe, uwierzytelnione szyfrowanie), wybieramy bardziej konserwatywną opcję.

14. Zmiany w tej stronie

Materialne zmiany są oznaczone aktualizacją daty wejścia w życie na górze. Tam, gdzie zmiana odzwierciedla konkretne ulepszenie bezpieczeństwa, opisujemy ją krótko w publicznym changelogu. Tam, gdzie zmiana odzwierciedla wyjaśnienie polityki, opisujemy, co się zmieniło i dlaczego.

Dla pytań o cokolwiek na tej stronie, napisz na support@qub.social z prefiksem tematu [SECURITY].

15. Dziennik zmian