Keamanan di qub

Tanggal efektif: 23 September 2026 Versi: 1.1 — tinjauan akurasi implementasi

Untuk peneliti — referensi cepat:

• Ke mana mengirim laporan: support@qub.social dengan awalan subjek [SECURITY].
• Apa yang harus disertakan: kerentanan, langkah-langkah untuk mereproduksi, dan bukti-konsep apa pun.
• Respons kami: kami mengakui penerimaan dalam 3 hari kerja dan berusaha mengirim perbaikan dalam 90 hari.
• Safe Harbor: kami tidak akan mengajukan tindakan hukum terhadap penelitian iktikad baik yang mengikuti aturan dalam §12 (tidak ada akses ke data yang bukan milik Anda, tidak ada degradasi layanan, tidak ada penyimpanan data yang diperoleh di luar yang diperlukan untuk menunjukkan masalah, beri kami jendela pengungkapan yang wajar).

Detail lengkap ada di §12 (Pengungkapan Terkoordinasi).

Tentang Kami

qub.social dioperasikan oleh VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. Acuan "qub", "kami", dan "milik kami" merujuk pada entitas tersebut.

Kontak keamanan: support@qub.social dengan awalan subjek [SECURITY].

1. Pendekatan Kami

qub adalah infrastruktur kepercayaan. Produk tidak berharga jika tidak aman, sehingga keamanan bukan fitur — ia adalah substratnya. Halaman ini menjelaskan, secara konkret, bagaimana kami menjaga tumpukan, data Anda, dan integritas konten tersegel.

Nilai komitmen temporal yang dapat diverifikasi tumbuh seiring makin banyak bagian internet dihasilkan mesin. Transaksi penyimpanan atau tambatan log transparansi yang terverifikasi dapat menetapkan bahwa ciphertext sudah ada paling lambat pada waktu bloknya; artefak tersegel secara terpisah membuktikan integritas konten, pengikatan putaran drand, dan tanda tangan kepenulisan apa pun. Pemisahan klaim-klaim tersebut menjadi standar yang menjadi tolok ukur halaman ini.

Kami tidak meminta Anda untuk memercayai kami. Kami merancang sehingga kepercayaan yang dibutuhkan dari kami sekecil mungkin, dan di mana kepercayaan diperlukan, kami menjelaskan dengan tepat apa yang dipercayai dan mengapa.

Tiga prinsip mendorong setiap keputusan desain:

• Minimalkan apa yang dapat dilihat server. Dalam alur pesan peramban default, teks polos dan kunci pembungkus tetap berada di perangkat Anda. Penyegelan Builder sisi server, penandatanganan bersama pakta, dan pemulihan yang diaktifkan secara eksplisit memiliki batas kepercayaan berbeda yang dijelaskan di bawah. Ketika kami menyimpan metadata, kami membatasinya pada hal yang diperlukan oleh fitur yang dipilih.
• Buat kompromi terkontainerisasi secara lokal. Pelanggaran salah satu komponen (server kami, penyedia email, simpul drand) tidak boleh mengungkapkan konten tersegel yang belum mencapai waktu pengungkapannya.
• Buat protokol dapat diaudit. Artefak tersegel dapat diverifikasi ujung-ke-ujung dengan kriptografi publik. Anda tidak perlu memercayai layanan qub untuk memverifikasi artefak qub.

2. Model Ancaman

2.1 Apa yang Kami Lindungi

• Penyerang yang mendapatkan akses baca ke data sisi server kami yang tersimpan sebelum waktu pengungkapan. Dalam alur peramban privat default, mereka memperoleh metadata dan bita terbungkus yang buram, bukan teks polos atau K. Perlindungan ini tidak berlaku bagi K yang secara eksplisit disimpan untuk pemulihan, pengiriman publik/tanpa pembungkus setelah putaran drand-nya, atau teks polos yang sementara diberikan ke alur Builder /api/v1/seal dan pakta.
• Penyerang yang mencegat lalu lintas antara peramban Anda dan infrastruktur kami. TLS berakhir di edge CDN kami; muatan tersegel sudah dienkripsi sebelum transit.
• Penyerang yang merusak muatan tersimpan. Autentikasi pembungkus luar (jika ada), dekode kanonik, hash badan, penurunan ulang qub_id, pengikatan putaran, dan tanda tangan opsional membuat perusakan gagal diverifikasi; pembaca menolak merendernya.
• Penyerang yang mencoba mengikat email penulis palsu ke kunci penandatanganan. Atestasi email memerlukan kepemilikan kunci penandatanganan privat dan kode sekali pakai yang dikirim ke kotak masuk email.
• Operator beacon drand yang terkompromi. Jaringan drand menggunakan tanda tangan ambang BLS di beberapa operator independen; minoritas tidak dapat memalsukan tanda tangan rilis-awal.

2.2 Apa yang Tidak Dapat Kami Lindungi

Kami jujur tentang batas kami. qub tidak dapat bertahan terhadap:

• Kompromi perangkat Anda sebelum Anda menyegel. Keylogger lokal, ekstensi peramban berbahaya, atau akses fisik ke perangkat yang tidak terkunci dapat menangkap plaintext pada titik penyusunan.
• Keruntuhan ambang drand. Beberapa organisasi independen menjalankan jaringan drand secara khusus untuk mempersulit ini, tetapi secara kriptografi tidak mustahil: jika operator yang cukup banyak berkolusi, mereka dapat menurunkan kunci kunci-waktu lebih awal.
• Properti rilis dari salinan yang valid. qub publik/tanpa pembungkus dapat didekripsi setelah putaran drand-nya. qub privat/terbungkus juga memerlukan K; siapa pun yang memperoleh bita tersimpan dan K dapat mendekripsinya setelah putaran tersebut. Catatan penyimpanan permanen dan log tertambat tidak dapat ditarik kembali hanya dengan menghapusnya dari permukaan produk qub.
• Lawan global yang menembus kriptografi yang mendasarinya (AES-GCM, asumsi pasangan BLS12-381, SHA3-256, ML-DSA-65). Jika primitif ini jatuh, ekosistem kriptografi pada umumnya memiliki masalah yang lebih besar.

3. Kriptografi Sisi-Klien

Dalam alur pesan peramban default, enkripsi konten terjadi sebelum permintaan unggah. Dua jalur eksplisit berbeda: Builder /api/v1/seal sengaja mengirim teks polos dan K yang dibuat pemanggil ke Worker untuk penyegelan dalam memori, sedangkan penyiapan/penandatanganan bersama pakta mengirim pakta terstruktur yang ditandatangani ke layanan agar artefak bilateral dapat difinalkan. Kedua pengecualian ini tidak boleh disalahartikan sebagai enkripsi ujung-ke-ujung pada jalur peramban.

3.1 Enkripsi Kunci-Waktu

qub menggunakan tlock — enkripsi berbasis identitas yang dikunci pada putaran beacon drand masa depan. Enkripsi berlangsung di peramban Anda menggunakan kunci publik jaringan drand; kunci dekripsi dirilis secara publik oleh jaringan drand hanya ketika putaran target tercapai. Tidak seorang pun, termasuk kami, dapat merekonstruksi kunci dekripsi terlebih dahulu.

Kami menargetkan rantai quicknet:

• Periode putaran 3 detik
• Mode unchained (setiap putaran independen)
• Tanda tangan BLS12-381 G1
• Hash rantai 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

Kunci publik dan waktu genesis rantai quicknet dikompilasi ke dalam klien. Kami tidak mengambil parameter rantai pada runtime, sehingga simpul berbahaya tidak dapat mengganti rantai yang kami kontrol.

3.2 Enkripsi Simetris

Skema tlock membungkus kunci konten AES-256-GCM. AES-GCM menyediakan enkripsi terotentikasi: satu bit yang dibalik dalam ciphertext menyebabkan dekripsi gagal, alih-alih menghasilkan plaintext yang rusak secara diam-diam.

3.3 Serialisasi Kanonik

Struktur protokol diserialisasi menggunakan CBOR deterministik (RFC 8949 §4.2 core deterministic encoding). Dua implementasi yang mengodekan struktur logis yang sama menghasilkan CBOR identik. Muatan tersegel lengkap tidak deterministik: enkripsi tlock dan pembungkus luar menggunakan keacakan baru. Hash badan dihitung atas bita badan mentah, sedangkan pengodean kanonik membuat struktur bertanda tangan/wire di sekelilingnya tidak ambigu.

Kami menulis encoder CBOR dengan tangan untuk implementasi klien dan server daripada mengandalkan library serialisasi generik — persyaratannya adalah ketepatan, bukan ergonomi, dan tes properti berjalan di kedua implementasi untuk memverifikasi bahwa mereka sepakat.

Tes regresi menegaskan bahwa format wire kanonik tidak berisi urutan byte merek-qub di luar kunci bidang qub_id primitif-protokol. Format wire sengaja agnostik-merek — pembaca yang sesuai (kami atau pihak ketiga) dapat merender qub apa pun dari penyimpanan permanen, terlepas dari penerapan mana yang menyegelnya. Tes adalah tripwire yang mencegah perubahan masa depan dari secara tidak sengaja memanggang referensi merek ke dalam byte yang, setelah di penyimpanan permanen, tidak dapat ditulis ulang.

3.4 Pencirian Badan dan Integritas Pra-Pengungkapan

Setiap muatan tersegel membawa hash SHA3-256 dari bita badan mentahnya. Hash terikat ke qub_id dan, ketika penandatanganan kepenulisan diaktifkan, ke input tanda tangan V2. Pembaca menghitungnya ulang setelah dekripsi dan menolak jika tidak cocok.

Pengenal konten 32-byte qub_id diturunkan dari preimage 108-byte yang mencakup versi protokol, jenis konten, cap waktu pembuatan dan pembukaan kunci, cap waktu hasil opsional (atau sentinel nolnya), putaran drand target, hash badan, dan SHA3-256 dari judul opsional yang dinormalisasi NFC. Gateway atau CDN tidak dapat mengubah bidang terikat mana pun secara konsisten sambil tetap lolos penurunan ulang. Judul dibatasi pada 100 titik kode NFC dan ditolak jika mengandung kelas titik kode bermusuhan/kontrol bersama (termasuk override bidi, karakter lebar-nol, blok tag, BOM, C0, C1, dan DEL).

3.5 Penandatanganan (ML-DSA-65)

Penandatanganan kepenulisan menggunakan ML-DSA-65 (FIPS 204), skema tanda tangan pasca-kuantum yang distandarkan NIST. Kami sengaja memilih primitif pasca-kuantum untuk penandatanganan karena konten tersegel bersifat permanen: tanda tangan yang diverifikasi hari ini harus tetap diverifikasi puluhan tahun dari sekarang, termasuk setelah komputer kuantum berskala besar menjadi praktis.

Kunci penandatanganan dihasilkan di peramban. Rahasia lokal dibungkus dengan kunci WebCrypto yang tidak dapat diekstrak sebelum disimpan di IndexedDB. Jika fitur pemulihan lintas-perangkat yang tercakup akun digunakan, blob kunci portabel terenkripsi AEAD disimpan di sisi server; ciphertext kunci rahasianya terikat ke id akun yang tidak dapat diubah, dan layanan memvalidasi amplop publik tetapi tidak dapat mendekripsi materi rahasia. Bita kunci privat mentah tidak dikirim ke server. Kunci publik dan catatan atestasi disimpan untuk verifikasi dan tampilan identitas.

Dekripsi tlock dalam peramban yang sama berlaku di dalam sematan qub: ketika qub tersegel dirender melalui <qub-embed> pada halaman pihak ketiga, dekripsi masih terjadi di iframe sematan di peramban pembaca. Sematan tidak mengubah model kepercayaan — plaintext tidak pernah didekripsi di server qub.

3.6 Atribusi Publik — Opt-In

qub yang tersegel tidak membawa penunjuk on-chain ke pembuatnya kecuali pembuat secara eksplisit memilih untuk melampirkannya. Ketika Anda menyegel qub, aplikasi referensi mengeluarkan tag penyimpanan Author (sidik jari hex 64 karakter dari kunci publik penandatanganan Anda) hanya ketika "Atribusi publik" diaktifkan pada langkah pemilih tanggal. Dengan toggle mati — default — tidak ada tag Author yang ditulis dan qub tidak teratribusi di penyimpanan permanen: tidak ada di penyimpanan yang menautkan unggahan ke handle Anda, email Anda, atau qub Anda lainnya. Dengan toggle aktif, sidik jari diselesaikan ke @handle Anda melalui rantai atestasi di §6.3 / §10 dan hitung mundur pembaca menampilkan "Disegel oleh @{handle}" sebelum pengungkapan.

Ini adalah penjaga yang disengaja terhadap risiko enumerasi yang akan diciptakan oleh tag Author yang selalu aktif: pihak ketiga yang mempelajari sidik jari pembuat dapat sebaliknya menelusuri penyimpanan permanen dengan tag dan merekonstruksi seluruh keluaran historis pembuat tersebut. Atribusi opsi-aktif menutup saluran itu — hanya qub yang secara eksplisit dipilih pembuat untuk diatribusikan yang muncul di bawah sidik jari di penyimpanan permanen.

Halaman profil /u/{handle} adalah kartu identitas terverifikasi — handle, nama tampilan + URL opsional, lencana "email terverifikasi" (tanpa alamat), dan bentuk pendek sidik jari kriptografi. Ia tidak mencantumkan qub seorang pembuat. Pengunjung yang ingin melihat qub tertentu dari pembuat mengikuti URL pengiriman qub itu secara langsung.

3.7 Pembungkus Enkripsi Luar

Bahkan setelah dekripsi kunci-waktu secara matematis mungkin—setelah tanda tangan drand untuk putaran terikat diterbitkan—lapisan kunci-waktu kanonik saja akan memungkinkan pengindeks mendekripsi qub yang dapat ditemukan secara massal. Pengiriman privat menutup saluran itu dengan lapisan simetris tambahan di sekeliling bita terenkripsi kunci-waktu (Protokol §13). Pengiriman publik sengaja menghilangkan pembungkus agar tautan notifikasi, sematan, dan penemuan dapat berfungsi tanpa fragmen rahasia.

Pembungkus menggunakan AES-256-GCM, sandi terotentikasi standar NIST, dengan kunci K 256-bit segar yang dihasilkan per qub oleh CSPRNG peramban Anda. K terikat ke qub_id qub sebagai data tambahan terotentikasi, sehingga kunci dari satu qub tidak dapat digunakan kembali untuk mendekripsi qub yang berbeda.

K tidak pernah mencapai server kami dalam alur peramban privat default. K dienkode ke dalam fragmen URL tautan bagikan (https://qub.social/c/<tx_id>#<base64url(K)>). Peramban tidak mengirimkan fragmen URL ke server—RFC 3986 menempatkan fragmen di luar permintaan—sehingga qub.social, gateway penyimpanan, CDN, dan pemantauan permintaan tidak dapat melihat K dalam alur tersebut. OuterWrapper yang tersimpan adalah CBOR terstruktur yang dapat dikenali, tetapi field ciphertext terautentikasinya menyembunyikan struktur SealedQub dalam dan tidak dapat dibuka tanpa K.

Konsekuensi bersih:

• qub.social tidak dapat mendekripsi segel peramban privat default hanya dari data tersimpan. Kompromi penyimpanan data mencapai ciphertext buram tanpa K. qub publik dan qub dengan pemulihan diaktifkan memiliki paparan berbeda sesuai rancangan.
• Kehilangan fragmen tidak dapat dipulihkan tanpa saluran pemulihan yang dipilih. Jika Anda menyimpan tautan privat tanpa fragmen dan tidak mengaktifkan pemulihan, qub menjadi tidak dapat dibaca melalui tautan tersebut. Alur penyegelan memunculkan pengungkapan "simpan URL ini" eksplisit karena alasan ini.
• Pemulihan opt-in. Ketika Anda memilih opsi-aktif email siklus hidup pembuat untuk qub DAN email cocok dengan identitas terverifikasi Anda, kami menerima K dengan unggahan, menyimpan URL pengiriman lengkap pada catatan riwayat tersegel identitas Anda, dan menggunakannya sebagai tautan di email konfirmasi segel. Pertukaran ini — saluran pemulihan sisi-server dengan imbalan kemurnian ujung-ke-ujung — hanya aktif pada opsi-aktif eksplisit dan hanya untuk qub itu. Postur default adalah crypto-shredding.

Endpoint /api/v1/seal sisi-server Worker (digunakan oleh agen AI dan penelepon API lainnya) mengharuskan penelepon menghasilkan K dengan CSPRNG, menyimpannya secara lokal, dan menyediakannya sebagai wrapper_key_b64url. Worker mau tidak mau melihat baik plaintext maupun K di memori pada jalur yang secara eksplisit tepercaya ini, tetapi tidak menyimpan keduanya. Idempotency-Key yang wajib mencegah respons yang hilang menciptakan qub kedua yang tertagih, sementara K yang disimpan penelepon dapat digabungkan dengan URL tanpa-fragmen yang diputar ulang. Ini berbeda dari jalur peramban default, di mana K tidak pernah mencapai Worker kecuali pembuat secara eksplisit mengaktifkan pemulihan.

4. Transport dan Edge

4.1 TLS

Lalu lintas peramban ke qub disajikan melalui HTTPS di edge Cloudflare. Respons menetapkan HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). Versi TLS dan rangkaian sandi yang dinegosiasikan ditentukan oleh konfigurasi edge aktif, bukan diklaim oleh kode aplikasi. Kami tidak mengekspos server origin yang dapat dijangkau secara terpisah.

4.2 Keamanan Konten

Klien yang dikompilasi disajikan dengan header content-type dan cache yang ketat. Shell SPA adalah satu origin. Kami tidak menyematkan skrip pihak ketiga untuk analitik atau iklan. Dua titik sentuh pihak ketiga dalam produk keduanya sempit cakupannya: alur pembelian meninggalkan SPA sepenuhnya dengan pengalihan halaman penuh ke pembayaran yang dihosting Stripe (https://checkout.stripe.com/…) — UI Stripe tidak pernah dieksekusi dalam origin kami dan kami tidak pernah melihat data kartu — dan alur penyegelan memuat widget Turnstile Cloudflare, alternatif CAPTCHA yang menjaga privasi yang Cloudflare render di dalam iframe sandbox-nya sendiri. Tidak ada pihak yang dapat membaca sisa halaman.

iframe sematan qub (disajikan dari qub.social/embed/{tx_id} dan dimuat ke situs pihak ketiga oleh embed.js) membawa Content-Security-Policy-nya sendiri. Daftar izin connect-src-nya adalah 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh, dan https://drand.cloudflare.com. iframe berjalan dengan sandbox="allow-scripts allow-top-navigation-by-user-activation" (bukan allow-same-origin): halaman host tidak dapat membaca DOM-nya, dan iframe tidak dapat menavigasi host kecuali setelah tindakan pengguna.

4.3 CORS dan Lingkup Fetch

Klien peramban membuat permintaan fetch hanya ke:

• API kami sendiri (api.qub.social dan padanan staging)
• Gateway penyimpanan (hanya-baca, untuk mengambil bita privat yang dibungkus atau bita publik tanpa pembungkus — §3.6)
• Endpoint beacon drand (hanya-baca, untuk tanda tangan putaran waktu-pengungkapan)

Tujuan sematan diberlakukan oleh CSP-nya. Tujuan yang dimaksudkan untuk SPA utama ditetapkan dalam kode dan konfigurasi serta dijalankan oleh pemeriksaan peramban dan integrasi; Subresource Integrity bukan kontrol tujuan jaringan.

Sematan mengambil bita tersimpan melalui origin qub/penyimpanan yang diizinkan, membuka bungkus muatan privat di peramban menggunakan K dari fragmen URL-nya, dan mengambil tanda tangan putaran waktu pengungkapan dari dua origin drand yang diizinkan. SPA utama menggunakan set fallback empat endpoint di config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh, dan api3.drand.sh) agar gangguan satu endpoint tidak memblokir pengungkapan. CSP sematan menolak koneksi di luar daftar eksplisitnya.

5. Infrastruktur Sisi-Server

5.1 Edge Serverless

API kami berjalan sepenuhnya pada runtime serverless terkelola di edge. Tidak ada VM, tidak ada container, dan tidak ada proses server persisten yang kami kelola. Ini secara dramatis mengurangi permukaan serangan yang menjadi tanggung jawab kami: kami tidak menjalankan OS, server web, atau runtime aplikasi yang harus kami tambal.

Middleware public-CORS terpisah diterapkan Access-Control-Allow-Origin: * ke set jalur yang diterapkan berikut: /embed.js, /embed/v1.js, semuanya di bawah /embed/; /api/v1/telemetry; /api/v1/openapi.json; semuanya di bawah /api/v1/qub/ (termasuk bytes, metadata, bukti, keterlibatan, notifikasi, dan subrute push); semuanya di bawah /api/v1/log/; tangani pencarian publik di bawah /api/v1/handle/; dan avatar publik membaca di bawah /api/v1/identity/avatar/. Izin penerbangan awalnya GET, POST, dan OPTIONS dengan Content-Type header permintaan. Permukaan berbasis awalan ini lebih luas daripada hanya panggilan yang saat ini dilakukan oleh embed, jadi setiap penangan di bawah awalan tersebut harus terus menegakkan validasi, otentikasi, batasan tingkat, dan kontrol penyalahgunaan mereka sendiri. Jalur API lainnya mempertahankan kebijakan CORS qub.social-restricted.

5.2 Penyimpanan

• Penyimpanan metadata dan koordinasi menyimpan catatan identitas dan atestasi, referensi hak dan penagihan, catatan kunci API, entri daftar tolak, sesi, status idempotensi, antrean, serta status batas laju/konkurensi. Kebutuhan konsistensi yang berbeda menggunakan KV, D1, dan Durable Objects, bukan satu penyimpanan universal.
• Penyimpanan objek kami juga merupakan substrat ketahanan. Penyimpanan ini memuat bita qub terbungkus atau tanpa pembungkus persis seperti yang diakui saat unggah, daun log transparansi dan simpul Merkle berkunci koordinat, materi tambatan, log peristiwa terstruktur, serta cache respons/metadata.
• Penyimpanan publik permanen memuat tambatan log transparansi dan, untuk jalur T3 atau penerbitan tertunda, transaksi qub individual. Kami tidak mengoperasikan jaringan itu. Muatan peramban privat tetap buram di sana kecuali pemegangnya juga memiliki K; muatan publik/tanpa pembungkus memang tidak memiliki lapisan kapabilitas-tautan tambahan itu.

Alur pesan peramban default tidak menyimpan teks polos secara persisten di infrastruktur qub. Builder /api/v1/seal menangani teks polos dan K dalam memori tetapi tidak menyimpan keduanya. Penyiapan pakta harus menyimpan pakta terstruktur yang ditandatangani hingga ditandatangani bersama, ditarik kembali, atau kedaluwarsa. Pemulihan opt-in menyimpan kapabilitas pengiriman (tautan lengkap yang memuat fragmen) agar dapat dipulihkan kemudian. Karena itu, kami tidak menggambarkan seluruh tingkat penyimpanan sebagai "hanya metadata".

5.3 Rahasia

Rahasia (dompet penandatanganan, token penyedia, dan kunci HMAC) diberikan melalui binding rahasia/lingkungan platform, bukan kontrol sumber. Komponen runtime hanya menerima binding yang diperlukannya. Prosedur rotasi dan masa tumpang tindih bersifat khusus per komponen; kami tidak mengklaim satu mekanisme rotasi universal yang otomatis atau diaudit.

5.4 Pencatatan dan Telemetri

Log JSON terstruktur ditulis pada setiap permintaan API dengan ID korelasi yang dimunculkan di header respons X-Request-Id. Telemetri klien bersifat anonim — tidak ada pengenal perangkat, tidak ada alamat IP, tidak ada pratinjau konten. Peristiwa disangga dalam memori dan di-flush atas dasar best-effort; flush yang gagal dibuang, tidak dicoba ulang. Telemetri dirancang agar dapat dinonaktifkan pada lapisan jaringan tanpa memengaruhi produk.

6. Autentikasi

6.1 Masuk Magic-Link

Masuk menggunakan token sekali pakai yang ditandatangani HMAC dan dikirim ke kotak masuk email Anda. Tautan valid selama 15 menit dan penebusan diklaim secara atomik sehingga penggunaan serentak atau pemutaran ulang ditolak secara aman. Jika berhasil, peramban menerima cookie buram __Host-qub_session dengan atribut Secure, HttpOnly, SameSite=Strict, dan Path=/.

Sesi memiliki batas tidak aktif 30 hari dan batas absolut 90 hari, dirotasi setelah 24 jam, dan hanya menerima generasi tepat sebelumnya selama masa tenggang 120 detik untuk respons yang hilang. Mutasi akun sensitif memerlukan autentikasi dalam 10 menit terakhir. Rahasia penandatanganan HMAC merupakan binding platform; akses baca metadata saja tidak dapat mencetak token valid.

6.2 Kunci API (Tingkat Pengembang)

Kunci API pengembang menggunakan awalan qub_sk_ untuk pengenalan mudah dan kemampuan grep. Setiap kunci:

• Terikat ke akun, cakupan, dan daftar izin IP CIDR opsional
• Ditampilkan dalam bentuk mentah satu kali; catatan persisten menyimpan hash SHA-256-nya, bukan rahasia bearer
• Dapat dirotasi dengan pemetaan tenggang satu jam sehingga kunci lama diselesaikan ke penggantinya
• Memiliki status kuota dan batas laju independen
• Tidak pernah dicatat secara penuh; log mencatat hanya pengenal kunci

Endpoint manajemen kunci admin dijaga di belakang kredensial admin terpisah.

6.3 Atestasi Email (Penandatanganan Kepenulisan)

Mengikat alamat email ke kunci penandatanganan memerlukan:

1. Kepemilikan kunci penandatanganan privat (Anda menandatangani tantangan)
2. Kepemilikan kotak masuk email (Anda memasukkan kode 6 digit yang dikirim melalui email)

Salah satu saja tidak cukup. Pencabutan adalah catatan ditandatangani pada akun Anda sendiri dan berlaku segera; pembaca yang mengambil atestasi melihat status yang dicabut dan menampilkannya sesuai.

7. Pembayaran

Entri dan pemrosesan kartu berjalan di dalam checkout yang dihosting Stripe. Kami tidak pernah menerima nomor kartu, tanggal kedaluwarsa, atau CVC. Kami menyimpan pengenal pelanggan dan langganan Stripe, status langganan, serta data periode pada catatan hak/kunci API agar akses, perpanjangan, pengukuran, pembatalan, dan pengembalian dana dapat direkonsiliasi. Pernyataan privasi dan keamanan Stripe mengatur penanganan data pembayaran oleh Stripe.

Endpoint penyegelan memeriksa silang catatan hak terhadap pengenal perangkat dan, untuk pengguna yang masuk, terhadap identitas tertaut. Hak tidak dapat digunakan kembali di seluruh perangkat tanpa pengguna secara eksplisit memulihkannya melalui masuk magic-link.

8. Ketahanan terhadap Penyalahgunaan

8.1 Deteksi Bot

Alur penyegelan dijaga oleh alternatif CAPTCHA yang menjaga privasi yang tidak menggunakan cookie untuk pelacakan dan tidak mengambil sidik jari untuk iklan. Tantangan yang gagal ditolak oleh Worker edge kami sebelum pemrosesan sisi-segel apa pun terjadi.

8.2 Pembatasan Laju

Batas laju diberlakukan di beberapa lapisan:

• Batas per-IP dan per-kunci pada endpoint seal, read, dan auth
• Batas per-email pada permintaan magic-link (mencegah banjir kotak surat)
• Batas per-pihak-lawan pada email undangan pakta (sepuluh per alamat penerima per hari UTC, mitigasi utama relay spam; pakta yang jujur hampir tidak pernah mendekati batas)
• Batas per-IP pada pengiriman telemetri

Penghitung dan klaim atomik tersebar di KV, Durable Objects, dan binding batas laju platform sesuai kebutuhan konsistensi endpoint. Permintaan yang dibatasi laju mengembalikan 429; endpoint yang dapat menghitung jendela coba ulang menyertakan Retry-After.

8.3 Moderasi Konten

Rute unggah browser default tidak dapat memindai tubuh: ia hanya menerima artefak yang disegel oleh klien. Pembuat /api/v1/seal rute melihat teks biasa secara sementara, dan penataan pakta menahan istilah yang terstruktur hingga finalisasi, tetapi pengecualian kepercayaan itu tidak mengubah jalur unggah buta-bait umum menjadi pemindai konten. Moderasi operasional adalah sebuah daftar-tolak di lapisan pemirsa: qub yang masuk daftar penolakan ditolak oleh pemirsa kami terlepas dari apakah muatan yang disimpan tetap dapat diakses. Pembuangan dari daftar penolakan tidak mencabut byte yang tahan lama, entri log transparansi, atau data jaringan permanen yang sudah diterbitkan.

Laporan penyalahgunaan dibatasi laju menggunakan hash satu arah dari IP pelapor; kami tidak menyimpan IP dalam teks polos untuk tujuan ini.

9. Rantai Pasokan dan Integritas Build

9.1 Penyematan Toolchain

Versi compiler dan runtime disematkan dalam konfigurasi repositori, dan dependensi diselesaikan melalui lockfile yang dikomit. CI memeriksa kesegaran berkas yang dihasilkan dan invarian yang sensitif terhadap reproduktibilitas. Kami tidak membuat klaim yang lebih kuat bahwa setiap build bersih identik bit demi bit di semua mesin yang didukung.

9.2 Lint dan Analisis Statis

Workspace mengaktifkan kelompok lint paling ketat kami pada tingkat deny. CI memperlakukan setiap peringatan — termasuk peringatan tautan dokumentasi — sebagai kegagalan build. Ini disengaja: kami menggunakan ketelitian lint sebagai tripwire untuk regresi yang halus.

9.3 Gerbang CI

Alur kerja CI mencakup pemformatan dan lint ketat; pengujian Rust, WASM/peramban, Worker, sematan, dan API; pemeriksaan tipe; cakupan kode; pemeriksaan mutasi/invarian; analisis statis dependensi dan alur kerja; pemeriksaan kunci, cakupan, drift, dan titik kode bermusuhan i18n; kesegaran dokumen/API/basis pengetahuan yang dihasilkan; inventaris dokumen dan pemeriksaan tautan internal; anggaran stylesheet dan bundel; serta validasi OpenAPI. Beberapa pekerjaan mutasi yang mahal dijadwalkan, bukan dijalankan pada setiap push.

Satu rangkuman wajib ci tetap merah jika ada pekerjaan wajib yang gagal. Alur kerja cabang terlindungi dan deploy menggunakan hasil tersebut alih-alih menggandakan gerbang keamanan yang lebih kecil.

9.4 Pengujian Mutasi

Pekerjaan mingguan menjalankan pengujian mutasi terhadap modul murni kritis-keamanan: pencirian, CBOR kanonik, seal, unlock, newtype format-wire, validator tipe protokol, dan namespace handle. Pengujian mutasi menjawab "apakah suite tes kami menangkap kode yang salah secara halus?" — jika implementasi yang dimutasi masih lulus semua tes, kami tahu kami memiliki celah cakupan tes dan menanganinya.

9.5 Git Hook

Hook lokal (pre-commit, pre-push) mencerminkan gerbang CI sehingga regresi tertangkap sebelum meninggalkan mesin pengembang. Hook dipasang melalui skrip repo; mereka tidak dilewati dalam alur kerja kami dan CI adalah gerbang otoritatif jika mereka dilewati.

10. Pengujian

Kode kritis-keamanan membawa tiga jenis tes:

• Tes unit memverifikasi perilaku yang diharapkan pada input yang diketahui, termasuk vektor uji yang berasal dari spesifikasi protokol.
• Tes properti menghasilkan ribuan input sembarang dan menegaskan invarian: round-trip CBOR kanonik, round-trip verifikasi tanda tangan, predikat pengikatan email, determinisme pengakuan pakta.
• Tes lintas-implementasi memverifikasi bahwa implementasi klien dan server kami sepakat byte-untuk-byte pada penyandian kanonik. Ini menangkap divergensi antara dua implementasi sebelum mencapai produksi.

11. Kebersihan Cabang dan Rilis

Cabang fitur hanya memajukan staging melalui pull request Gerbang 1: ci wajib hijau, tidak ada permintaan perubahan yang belum diselesaikan, tidak ada konflik penggabungan, dan tree yang ditinjau bersih; penggabungannya menggunakan squash lalu cabang dihapus. main hanya maju melalui pull request Gerbang 2 staging → main dan mempertahankan ancestry dengan merge commit. Push cabang langsung bukan alur kerja rilis.

Deploy staging dan produksi dipicu dari status cabang terlindungi staging dan main yang sesuai setelah CI. Kode pull request dan kredensial fork tidak menerima rahasia deploy.

Rahasia yang digunakan dalam alur kerja deploy dicakupkan ke lingkungan deploy oleh platform CI kami. Mereka tidak tersedia untuk alur kerja pull-request dari fork.

12. Pengungkapan Terkoordinasi

Jika Anda yakin telah menemukan kerentanan keamanan di qub, kami ingin mendengarnya dengan cepat dan kami berkomitmen untuk menangani laporan secara profesional.

• Email support@qub.social dengan awalan subjek [SECURITY].
• Jelaskan kerentanan, langkah-langkah untuk mereproduksi, dan bukti-konsep apa pun.
• Beri kami jendela pengungkapan yang wajar (biasanya 90 hari) sebelum dipublikasikan.
• Jangan mengakses data yang bukan milik Anda, menurunkan layanan untuk pengguna lain, atau menyimpan data yang diperoleh selama penelitian di luar yang diperlukan untuk menunjukkan masalah.

Kami mengakui penerimaan dalam tiga hari kerja dan terus memberi tahu Anda saat kami menyelidikinya. Dengan persetujuan Anda, kami memberi kredit kepada pelapor dalam catatan rilis.

12.1 Safe Harbor

Jika penelitian Anda mengikuti aturan di atas (investigasi iktikad baik, tanpa bahaya kepada pengguna lain atau layanan, jendela pengungkapan yang wajar), kami tidak akan mengajukan tindakan hukum terhadap Anda, dan kami tidak akan meminta penegakan hukum untuk melakukannya. Kami memperlakukan pekerjaan Anda sebagai pengujian yang diotorisasi dan kami lebih suka Anda menemukan bug daripada orang lain.

Safe Harbor ini berlaku untuk:

• Penelitian pada layanan qub.social langsung (bukan pada fixture uji yang kami publikasikan untuk tujuan tersebut).
• Reverse-engineering biner kami yang dipublikasikan dan crate qub-core / qub-app sumber terbuka.
• Kelas kerentanan apa pun — protokol, aplikasi, infrastruktur, rantai pasokan — yang memengaruhi qub.

Tidak berlaku untuk rekayasa sosial anggota tim qub, uji penolakan layanan, atau mengakses data pengguna lain di luar yang diperlukan untuk menunjukkan masalah. Jika Anda tidak yakin apakah sesuatu berada dalam Safe Harbor, tanyakan terlebih dahulu menggunakan awalan subjek [SECURITY] yang sama.

13. Batasan yang Jujur

Keamanan adalah praktik, bukan keadaan. Beberapa batasan layak disebutkan secara langsung:

• Kami adalah tim kecil. Kedalaman peninjauan kami tidak sebanding dengan fungsi keamanan aplikasi khusus dari korporasi besar. Kami mengimbanginya dengan gerbang otomatis yang ketat dan permukaan serangan minimal, tetapi kami tidak mengklaim kekebalan kesalahan.
• Permanensi backend penyimpanan kami adalah pintu satu arah. Jika kesalahan menyebabkan konten tersegel menjadi dapat didekripsi lebih awal dari yang dimaksudkan, kami tidak dapat membatalkannya. Kami memperlakukan alur penyegelan dengan kehati-hatian yang sebanding.
• Jaringan drand adalah dependensi eksternal. Kegagalan katastrofis drand akan memengaruhi perilaku pengungkapan setiap qub. Kami memantau kesehatan drand dan memiliki dokumentasi kontingensi untuk migrasi rantai jika diperlukan. Untuk tanggal pembukaan kunci lebih dari 2 tahun ke depan, modal konfirmasi waktu-segel menunjukkan pengungkapan eksplisit: qub berhorizon panjang bergantung pada daya tahan rantai drand, dan migrasi rantai drand masa depan mungkin memerlukan langkah pemulihan untuk membuka qub. Untuk tanggal pembukaan kunci lebih dari 5 tahun ke depan, Anda harus mencentang kotak ekstra yang mengonfirmasi bahwa Anda telah membaca dan menerima risiko ini sebelum penyegelan dilanjutkan.
• Primitif kriptografi yang kami andalkan distandarkan dan ditinjau secara luas, tetapi kriptografi berkembang. Di mana kami memiliki pilihan (penandatanganan pasca-kuantum, enkripsi terotentikasi), kami memilih opsi yang lebih konservatif.

14. Perubahan pada Halaman Ini

Perubahan material dicatat dengan memperbarui tanggal efektif di bagian atas. Di mana perubahan mencerminkan peningkatan keamanan konkret, kami menjelaskannya secara singkat dalam changelog publik. Di mana perubahan mencerminkan klarifikasi kebijakan, kami menjelaskan apa yang berubah dan mengapa.

Untuk pertanyaan tentang apa pun di halaman ini, kirim email ke support@qub.social dengan awalan subjek [SECURITY].

15. Catatan Perubahan