ความปลอดภัยที่ qub

วันที่มีผลบังคับใช้: 23 กันยายน 2026 เวอร์ชัน: 1.1 — การทบทวนความแม่นยำในการดำเนินงาน

สำหรับนักวิจัย — แหล่งอ้างอิงด่วน:

รายละเอียดทั้งหมดอยู่ในข้อ §12 (การเปิดเผยข้อมูลแบบประสานงาน)

เราคือใคร

qub.social ดำเนินการโดย VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, ออสเตรเลีย การอ้างอิงถึง "qub", "เรา", "พวกเรา" และ "ของเรา" หมายถึงนิติบุคคลนั้น

ผู้ติดต่อด้านความปลอดภัย: support@qub.social พร้อมคำนำหน้าหัวข้อ [SECURITY]

1. แนวทางของเรา

qub คือโครงสร้างพื้นฐานแห่งความไว้วางใจ ผลิตภัณฑ์ไร้ค่าหากไม่ปลอดภัย ดังนั้นความปลอดภัยจึงไม่ใช่คุณสมบัติ — มันเป็นพื้นฐาน หน้านี้อธิบาย ในรูปแบบที่เป็นรูปธรรม วิธีที่เราปกป้องสแตกของเรา ข้อมูลของคุณ และความถูกต้องของเนื้อหาที่ผนึก

คุณค่าของความมุ่งมั่นด้านเวลาแบบตรวจสอบได้เพิ่มขึ้นเมื่ออินเทอร์เน็ตมากขึ้นถูกสร้างโดยเครื่องจักร การทำธุรกรรมการจัดเก็บที่ตรวจสอบได้หรือสมอของบันทึกความโปร่งใสสามารถยืนยันได้ว่าข้อความเข้ารหัสมีอยู่ไม่ช้ากว่าเวลาของบล็อกนั้น สิ่งประดิษฐ์ที่ปิดผนึกจะแสดงให้เห็นถึงความสมบูรณ์ของเนื้อหา การผูกกับรอบ drand และลายเซ็นผู้สร้างเนื้อหา การแยกข้อเรียกร้องเหล่านั้นออกจากกันคือมาตรฐานที่หน้านี้ถูกยึดถือ

เราไม่ขอให้คุณไว้วางใจเรา เราออกแบบให้ความไว้วางใจที่จำเป็นจากเรามีน้อยที่สุด และในกรณีที่ความไว้วางใจเป็นสิ่งจำเป็น เราอธิบายอย่างชัดเจนว่ากำลังถูกไว้วางใจอะไรและทำไม

หลักการสามประการขับเคลื่อนทุกการตัดสินใจในการออกแบบ:

2. แบบจำลองภัยคุกคาม

2.1 สิ่งที่เราป้องกัน

2.2 สิ่งที่เราป้องกันไม่ได้

เราซื่อสัตย์เกี่ยวกับขีดจำกัดของเรา qub ไม่สามารถป้องกันต่อ:

3. การเข้ารหัสฝั่งไคลเอนต์

ในการไหลของข้อความของเบราว์เซอร์เริ่มต้น การเข้ารหัสเนื้อหาจะเกิดขึ้นก่อนคำขออัปโหลด มีสองเส้นทางที่ชัดเจนที่แตกต่างกัน: Builder /api/v1/seal ส่งข้อความธรรมดาและ K ที่ผู้เรียกสร้างขึ้นไปยัง Worker โดยเจตนาเพื่อทำการปิดผนึกในหน่วยความจำ และการจัดเตรียม/ลงนามร่วม pact ส่ง pact ที่มีโครงสร้างและลงนามแล้วไปยังบริการเพื่อให้สามารถสรุปผลผลิตทางทวิภาคีได้ ทั้งสองข้อยกเว้นไม่ควรถูกเข้าใจผิดว่าเป็นการเข้ารหัสตั้งแต่ต้นจนจบของเส้นทางเบราว์เซอร์

3.1 การเข้ารหัสแบบ Timelock

qub ใช้ tlock — การเข้ารหัสตามตัวตนที่ผูกกับรอบบีคอน drand ในอนาคต การเข้ารหัสดำเนินการในเบราว์เซอร์ของคุณโดยใช้คีย์สาธารณะของเครือข่าย drand คีย์ถอดรหัสถูกปล่อยสาธารณะโดยเครือข่าย drand เฉพาะเมื่อถึงรอบเป้าหมาย ไม่มีใคร รวมทั้งเรา สามารถสร้างคีย์ถอดรหัสล่วงหน้าได้

เราเล็งที่เชน quicknet:

คีย์สาธารณะของเชน quicknet และเวลา genesis ถูกคอมไพล์เข้ากับไคลเอนต์ เราไม่ดึงพารามิเตอร์เชนในเวลารัน ดังนั้นโหนดที่เป็นอันตรายไม่สามารถแทนที่เชนที่เราควบคุม

3.2 การเข้ารหัสแบบสมมาตร

scheme tlock ห่อหุ้มคีย์เนื้อหา AES-256-GCM AES-GCM ให้การเข้ารหัสที่รับรองความถูกต้อง: บิตเดียวที่กลับด้านใน ciphertext ทำให้การถอดรหัสล้มเหลว แทนที่จะสร้างข้อความธรรมดาที่เสียหายเงียบๆ

3.3 การ Serialise แบบ Canonical

โครงสร้างของโปรโตคอลถูกจัดลำดับเป็นซีเรียลโดยใช้ CBOR แบบกำหนดผลลัพธ์แน่นอน (RFC 8949 §4.2 การเข้ารหัสแบบกำหนดผลลัพธ์หลัก) การใช้งานสองตัวที่เข้ารหัสโครงสร้างตรรกะเดียวกันจะสร้าง CBOR ที่เหมือนกัน ข้อมูลที่ปิดผนึกครบถ้วนคือ ไม่ เชิงกำหนด: การเข้ารหัส tlock และ outer-wrapper ใช้อินทิกรัลแบบสุ่มใหม่ แฮชของเนื้อหาจะถูกคำนวณจากไบต์เนื้อหาดิบ ในขณะที่การเข้ารหัสแบบ canonical ทำให้โครงสร้างที่ลงลายมือชื่อ/โครงสร้างสื่อรอบ ๆ ชัดเจนไม่กำกวม

เราเขียน encoder CBOR ด้วยมือสำหรับการนำไปใช้ทั้งไคลเอนต์และเซิร์ฟเวอร์ของเรา แทนที่จะพึ่งพาไลบรารีการ serialise ทั่วไป — ข้อกำหนดคือความแม่นยำ ไม่ใช่ความสะดวกในการใช้งาน และการทดสอบคุณสมบัติทำงานในทั้งสองการนำไปใช้เพื่อตรวจสอบว่าพวกเขาสอดคล้องกัน

การทดสอบ regression ยืนยันว่ารูปแบบ wire แบบ canonical ไม่มีลำดับไบต์ของแบรนด์ qub เกินกว่าคีย์ฟิลด์ qub_id ที่เป็นพื้นฐานของโปรโตคอล รูปแบบ wire ออกแบบมาให้ไม่ขึ้นกับแบรนด์ — ตัวดูที่สอดคล้องใด (ของเราหรือของบุคคลที่สาม) สามารถเรนเดอร์ qub ใดจากพื้นที่เก็บถาวรโดยไม่คำนึงถึงการ deploy ใดที่ผนึก การทดสอบเป็น tripwire ที่ป้องกันการเปลี่ยนแปลงในอนาคตจากการอบการอ้างอิงแบรนด์โดยไม่ตั้งใจลงในไบต์ที่ เมื่ออยู่ในพื้นที่เก็บถาวร ไม่สามารถเขียนใหม่ได้

3.4 การ Hashing เนื้อความและความถูกต้องก่อนการเปิดเผย

ทุก payload ที่ถูกปิดผนึกจะมีค่าแฮช SHA3-256 ของไบต์ตัวเนื้อดิบของมัน ค่าฮาชถูกผูกเข้ากับ qub_id และ เมื่อเปิดใช้งานการลงชื่อผู้แต่ง จะเข้าสู่ช่องป้อนลายเซ็น V2 ผู้ชมจะคำนวณใหม่หลังจากถอดรหัสและปฏิเสธหากไม่ตรงกัน

ตัวระบุเนื้อหา 32 ไบต์ qub_id ถูกสกัดมาจากภาพต้นฉบับขนาด 108 ไบต์ที่ครอบคลุมเวอร์ชันโปรโตคอล ประเภทเนื้อหา เวลาที่สร้างและปลดล็อก เวลาผลลัพธ์ตามทางเลือก (หรือค่าเซนติเนลเป็นศูนย์) รอบ drand เป้าหมาย แฮชเนื้อหา และ SHA3-256 ของชื่อที่ทำให้อยู่ในรูปแบบ NFC ตามทางเลือก เกตเวย์หรือ CDN ไม่สามารถเปลี่ยนแปลงฟิลด์ที่ผูกมัดใด ๆ ได้อย่างสม่ำเสมอและยังผ่านการสกัดใหม่ ชื่อถูกจำกัดไม่เกิน 100 จุดรหัส NFC และจะถูกปฏิเสธสำหรับคลาสรหัสควบคุม/เป็นศัตรูร่วม (รวมถึงการโอเวอร์ไรด์ทิศทาง ตัวอักขระความกว้างศูนย์ บล็อกแท็ก BOM C0 C1 และ DEL)

3.5 การลงนาม (ML-DSA-65)

การลงนามการประพันธ์ใช้ ML-DSA-65 (FIPS 204) ซึ่งเป็น scheme ลายเซ็นหลังควอนตัมที่ NIST ทำให้เป็นมาตรฐาน เราเลือก primitive หลังควอนตัมโดยตั้งใจสำหรับการลงนามเพราะเนื้อหาที่ผนึกถาวร: ลายเซ็นที่ตรวจสอบได้วันนี้ต้องยังคงตรวจสอบได้ทศวรรษจากนี้ รวมถึงหลังจากคอมพิวเตอร์ควอนตัมขนาดใหญ่ใช้งานได้จริง

กุญแจสำหรับการเซ็นชื่อถูกสร้างขึ้นในเบราว์เซอร์ ความลับภายในเครื่องจะถูกห่อไว้ภายใต้กุญแจ WebCrypto ที่ไม่สามารถสกัดออกได้ก่อนจัดเก็บลง IndexedDB หากใช้คุณสมบัติการกู้คืนข้ามอุปกรณ์ที่ระบุบัญชี จะมีการจัดเก็บไฟล์กุญแจพกพาที่เข้ารหัสแบบ AEAD ไว้ที่ฝั่งเซิร์ฟเวอร์; ข้อความเข้ารหัสกุญแจลับถูกผูกกับรหัสบัญชีที่ไม่สามารถเปลี่ยนแปลงได้ และบริการจะตรวจสอบซองสาธารณะแต่ไม่สามารถถอดรหัสข้อมูลลับได้ ไบต์ของกุญแจส่วนตัวดิบจะไม่ถูกส่งไปยังเซิร์ฟเวอร์ กุญแจสาธารณะและบันทึกการรับรองถูกจัดเก็บเพื่อการตรวจสอบและแสดงตัวตน

การถอดรหัส tlock ในเบราว์เซอร์เดียวกันใช้บังคับภายในการฝัง qub: เมื่อ qub ที่ผนึกถูกเรนเดอร์ผ่าน <qub-embed> บนหน้าเว็บของบุคคลที่สาม การถอดรหัสยังคงเกิดขึ้นใน iframe การฝังในเบราว์เซอร์ของผู้ชม การฝังไม่เปลี่ยนแบบจำลองความไว้วางใจ — ข้อความธรรมดาไม่เคยถูกถอดรหัสบนเซิร์ฟเวอร์ qub

3.6 การระบุที่มาสาธารณะ — Opt-In

qub ที่ผนึกไม่มีตัวชี้บนเชนถึงผู้สร้างเว้นแต่ผู้สร้างเลือกที่จะแนบหนึ่งอย่างชัดแจ้ง เมื่อคุณผนึก qub แอปผู้สร้างอ้างอิงปล่อยแท็กการจัดเก็บ Author (fingerprint ฐาน 16 ขนาด 64 อักขระของคีย์สาธารณะลงนามของคุณ) เฉพาะเมื่อ "การระบุที่มาสาธารณะ" เปิดอยู่ในขั้นตอนการเลือกวันที่ เมื่อสวิตช์ปิด — ค่าเริ่มต้น — ไม่มีแท็ก Author ถูกเขียนและ qub ไม่ระบุที่มาในพื้นที่เก็บถาวร: ไม่มีอะไรในที่จัดเก็บเชื่อมโยงการอัปโหลดกับ handle ของคุณ อีเมลของคุณ หรือ qub อื่นของคุณ เมื่อสวิตช์เปิด fingerprint จะแก้ไขเป็น @handle ของคุณผ่านห่วงโซ่การรับรองใน §6.3 / §10 และการนับถอยหลังของตัวดูแสดง "ผนึกโดย @{handle}" ก่อนการเปิดเผย

นี่เป็นการป้องกันโดยตั้งใจต่อความเสี่ยงในการแจกแจงที่แท็ก Author ที่เปิดเสมอจะสร้าง: บุคคลที่สามที่เรียนรู้ fingerprint ของผู้สร้างสามารถค้นหาพื้นที่เก็บถาวรโดยแท็กและสร้างผลงานในประวัติศาสตร์เต็มรูปแบบของผู้สร้างใหม่ การระบุที่มาแบบ opt-in ปิดช่องทางนั้น — เฉพาะ qub ที่ผู้สร้างเลือกระบุที่มาอย่างชัดแจ้งเท่านั้นที่ปรากฏภายใต้ fingerprint ในพื้นที่เก็บถาวร

หน้าโปรไฟล์ /u/{handle} คือบัตรตัวตนที่ได้รับการตรวจสอบ — handle, display name + URL เสริม, ป้าย "ยืนยันอีเมล" (ไม่มีที่อยู่) และรูปแบบสั้นของ fingerprint การเข้ารหัส มันไม่ระบุรายการ qub ของผู้สร้าง ผู้เข้าชมที่ต้องการดู qub เฉพาะจากผู้สร้างตาม URL ส่ง qub โดยตรง

3.7 ชั้นการเข้ารหัสภายนอก

แม้หลังจากการถอดรหัส timelock จะเป็นไปได้ทางคณิตศาสตร์—เมื่อมีการเผยแพร่ลายเซ็น drand สำหรับรอบที่ผูกไว้—ชั้น timelock มาตรฐานเพียงอย่างเดียวก็จะอนุญาตให้นักดัชนีถอดรหัสแบบรวมจำนวนมากของ qubs ที่ค้นพบได้ การจัดส่งแบบส่วนตัวจะปิดช่องทางนั้นด้วยชั้นสมมาตรเพิ่มเติมรอบไบต์ที่เข้ารหัสด้วย timelock (มาตรฐาน Protocol §13) การจัดส่งสาธารณะเจตนาไม่ใส่ชั้นห่อหุ้มเพื่อให้การแจ้งเตือน การฝัง และลิงก์การค้นพบสามารถทำงานได้โดยไม่ต้องใช้ชิ้นส่วนลับ

ตัวห่อหุ้มใช้ AES-256-GCM ซึ่งเป็นรหัสที่รับรองความถูกต้องที่ NIST ทำให้เป็นมาตรฐาน ด้วยคีย์ K ขนาด 256 บิตใหม่ที่สร้างขึ้นต่อ qub โดย CSPRNG ของเบราว์เซอร์ของคุณ K ถูกผูกกับ qub_id ของ qub เป็นข้อมูลเพิ่มเติมที่รับรองความถูกต้อง ดังนั้นคีย์จาก qub หนึ่งไม่สามารถถูกนำกลับมาใช้เพื่อถอดรหัส qub อื่น

K ไม่เคยเข้าถึงเซิร์ฟเวอร์ของเราในโฟลว์เบราว์เซอร์ส่วนตัวเริ่มต้น มันถูกเข้ารหัสลงในส่วนของ URL fragment ของลิงก์แชร์ (https://qub.social/c/<tx_id>#<base64url(K)>). เบราว์เซอร์จะไม่ส่งชิ้นส่วนของ URL ไปยังเซิร์ฟเวอร์—RFC 3986 กำหนดให้ชิ้นส่วนอยู่ภายนอกคำขอ—ดังนั้น qub.social, เกตเวย์การจัดเก็บ, CDN และการตรวจสอบคำขอจึงไม่สามารถเห็น K ในขั้นตอนนั้นได้ ข้อมูลที่ถูกจัดเก็บ OuterWrapper เป็น CBOR ที่มีโครงสร้างสามารถจดจำได้ แต่ฟิลด์รหัสลับที่ได้รับการรับรองของมันซ่อนข้อมูลภายใน SealedQub โครงสร้างและไม่สามารถเปิดได้โดยไม่ใช้ K.

ผลลัพธ์สุทธิ:

endpoint /api/v1/seal ฝั่งเซิร์ฟเวอร์ของ Worker (ใช้โดยเอเจนต์ AI และผู้เรียก API อื่น) กำหนดให้ผู้เรียกสร้าง K ด้วย CSPRNG เก็บรักษาไว้ในเครื่อง และจัดหาให้ในรูป wrapper_key_b64url Worker จำเป็นต้องเห็นทั้งข้อความธรรมดาและ K ในหน่วยความจำบนเส้นทางที่ได้รับความไว้วางใจอย่างชัดแจ้งนี้ แต่ไม่คงเก็บทั้งสองอย่าง Idempotency-Key ที่บังคับใช้ป้องกันไม่ให้การตอบสนองที่สูญหายสร้าง qub ที่เรียกเก็บเงินเป็นรายการที่สอง ขณะที่ K ที่ผู้เรียกเก็บรักษาไว้สามารถนำมารวมกับ URL ที่ไม่มี fragment ซึ่งถูกเล่นซ้ำได้ สิ่งนี้แตกต่างจากเส้นทางเบราว์เซอร์เริ่มต้น ซึ่ง K ไม่เคยเข้าถึง Worker เว้นแต่ผู้สร้างเปิดใช้การกู้คืนอย่างชัดแจ้ง

4. การขนส่งและขอบ

4.1 TLS

การรับส่งข้อมูลของเบราว์เซอร์ไปยัง qub จะให้บริการผ่าน HTTPS ที่ฝั่ง Cloudflare การตอบสนองตั้งค่า HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). เวอร์ชัน TLS และชุดรหัสที่เจรจาต่อรองอย่างแม่นยำถูกกำหนดโดยการกำหนดค่าขอบที่ใช้งานอยู่แทนที่จะระบุโดยโค้ดแอปพลิเคชัน เราไม่เปิดเผยเซิร์ฟเวอร์ต้นทางที่สามารถเข้าถึงได้แยกต่างหาก

4.2 ความปลอดภัยของเนื้อหา

ไคลเอนต์ที่คอมไพล์ถูกให้บริการพร้อม header ประเภทเนื้อหาและแคชที่เข้มงวด เชลล์ SPA เป็นต้นกำเนิดเดียว เราไม่ฝังสคริปต์บุคคลที่สามสำหรับการวิเคราะห์หรือโฆษณา จุดสัมผัสของบุคคลที่สามสองจุดในผลิตภัณฑ์มีขอบเขตแคบทั้งคู่: โฟลว์การซื้อออกจาก SPA โดยสมบูรณ์ด้วยการเปลี่ยนเส้นทางหน้าเต็มไปยังจุดชำระเงินที่โฮสต์โดย Stripe (https://checkout.stripe.com/…) — UI ของ Stripe ไม่เคยทำงานในต้นกำเนิดของเราและเราไม่เคยเห็นข้อมูลบัตร — และโฟลว์การผนึกโหลด widget Turnstile ของ Cloudflare ซึ่งเป็นทางเลือก CAPTCHA ที่รักษาความเป็นส่วนตัวที่ Cloudflare เรนเดอร์ภายใน iframe ที่แซนด์บ็อกซ์ของตนเอง ไม่มีฝ่ายใดสามารถอ่านส่วนที่เหลือของหน้าได้

นั้น คิวบ์ ฝัง iframe (ให้บริการจาก qub.social/embed/{tx_id} และถูกโหลดเข้าไปยังเว็บไซต์ของบุคคลที่สามโดย embed.js) มีนโยบายการรักษาความปลอดภัยเนื้อหาของตัวเอง เนื้อหาของมัน connect-src รายการอนุญาตคือ 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh, และ https://drand.cloudflare.com. iframe ทำงานด้วย sandbox="allow-scripts allow-top-navigation-by-user-activation" (ไม่ allow-same-origin): หน้าโฮสต์ไม่สามารถอ่าน DOM ของมันได้ และไม่สามารถนำทางโฮสต์ได้ ยกเว้นหลังจากการกระทำของผู้ใช้

4.3 CORS และขอบเขตการดึง

ไคลเอนต์เบราว์เซอร์ทำคำขอดึงเฉพาะไปยัง:

จุดหมายปลายทางของ embed ถูกบังคับโดย CSP ของมัน จุดหมายปลายทางที่ตั้งใจไว้ของ SPA หลักถูกกำหนดไว้ในโค้ดและการกำหนดค่า และถูกตรวจสอบโดยเบราว์เซอร์และการตรวจสอบการรวม; Subresource Integrity ไม่ใช่การควบคุมจุดหมายปลายทางเครือข่าย

การฝังดึงไบต์ที่จัดเก็บผ่านแหล่งกำเนิด qub/storage ที่อนุญาต เปิดข้อมูลส่วนตัวในเบราว์เซอร์โดยใช้ K จากส่วนของ URL ของมัน และดึงลายเซ็นเวลาการเปิดเผยจากแหล่งกำเนิด drand สองแห่งที่อนุญาต SPA หลักใช้ชุด fallback สี่จุดสิ้นสุดที่กำหนดใน config/drand-endpoints.json (drand.cloudflare.com, api.drand.sh, api2.drand.sh, และ api3.drand.sh) ดังนั้นการหยุดทำงานของจุดสิ้นสุดหนึ่งจุดจะไม่บล็อกการเปิดเผย CSP ที่ฝังอยู่จะปฏิเสธการเชื่อมต่อที่อยู่นอกเหนือจากรายการที่ระบุไว้อย่างชัดเจน

5. โครงสร้างพื้นฐานฝั่งเซิร์ฟเวอร์

5.1 Serverless Edge

API ของเราทำงานทั้งหมดบน serverless runtime ที่จัดการที่ขอบ ไม่มี VMs ไม่มีคอนเทนเนอร์ และไม่มีกระบวนการเซิร์ฟเวอร์ที่ต่อเนื่องที่เราดูแล นี่ลดพื้นผิวการโจมตีที่เรารับผิดชอบอย่างมาก: เราไม่ดำเนินการ OS เว็บเซิร์ฟเวอร์ หรือ application runtime ที่เราต้อง patch

มีตัวกลางสาธารณะ-CORS แยกต่างหากใช้งานอยู่ Access-Control-Allow-Origin: * ไปยังชุดเส้นทางที่ได้ดำเนินการดังต่อไปนี้: /embed.js, /embed/v1.js, ทุกอย่างภายใต้ /embed/; /api/v1/telemetry; /api/v1/openapi.json; ทุกอย่างอยู่ใต้ /api/v1/qub/ (รวมถึงไบต์ เมทาดาต้า หลักฐาน การมีส่วนร่วม การแจ้งเตือน และเส้นทางย่อยแบบพุช); ทุกอย่างภายใต้ /api/v1/log/; การจัดการการค้นหาภายใต้สาธารณะ /api/v1/handle/; และอวตารสาธารณะอ่านอยู่ใต้ /api/v1/identity/avatar/. ใบอนุญาตก่อนบินของมัน GET, POST, และ OPTIONS กับ Content-Type ส่วนหัวของคำขอ พื้นผิวที่อิงตามคำนำหน้านี้กว้างกว่าการเรียกที่ฝังในปัจจุบันทำ ดังนั้นตัวจัดการทุกตัวภายใต้คำนำหน้าเหล่านั้นต้องยังคงบังคับใช้การตรวจสอบ การยืนยันตัวตน ข้อจำกัดการใช้งาน และการควบคุมการละเมิดของตนเองเสมอ เส้นทาง API อื่น ๆ ยังคงรักษานโยบาย CORS ที่ถูกจำกัดของ qub.social

5.2 การจัดเก็บ

การไหลของข้อความเบราว์เซอร์เริ่มต้นจะไม่เก็บข้อความธรรมดาบนโครงสร้างพื้นฐาน qub Builder /api/v1/seal จัดการข้อความธรรมดาและ K ในหน่วยความจำแต่ไม่เก็บถาวรทั้งคู่ การจัดเตรียม Pact จำเป็นต้องเก็บ pact ที่มีโครงสร้างและลงนามแล้วจนกว่าจะถูกลงนามร่วม ยกเลิก หรือหมดอายุ การกู้คืนแบบเลือกเข้าร่วมจะเก็บความสามารถในการส่ง (ลิงก์ที่มีชิ้นส่วนทั้งหมด) เพื่อให้สามารถกู้คืนได้ภายหลัง ดังนั้นเราจึงไม่อธิบายชั้นการจัดเก็บทั้งหมดว่าเป็นเพียง “เมตาดาต้าเท่านั้น”

5.3 ความลับ

ความลับ (กระเป๋าเงินสำหรับการเซ็น, โทเค็นของผู้ให้บริการ และกุญแจ HMAC) จะถูกจัดเตรียมผ่านการเชื่อมโยงความลับ/สภาพแวดล้อมของแพลตฟอร์ม แทนที่จะอยู่ในการควบคุมซอร์สโค้ด ส่วนประกอบที่ทำงานขณะรันเวลาได้รับเฉพาะการเชื่อมโยงที่พวกเขาต้องการเท่านั้น กระบวนการหมุนเวียนและการซ้อนทับเป็นลักษณะเฉพาะของแต่ละส่วนประกอบ เราไม่ได้อ้างว่ามีกลไกหมุนเวียนอัตโนมัติหรือได้รับการตรวจสอบเพียงแบบสากลเดียว

5.4 การบันทึกและการวัดประสิทธิภาพ

บันทึก JSON ที่มีโครงสร้างถูกเขียนในทุกคำขอ API ด้วย correlation ID ที่ปรากฏใน header การตอบสนอง X-Request-Id การวัดประสิทธิภาพไคลเอนต์เป็นแบบไม่ระบุตัวตน — ไม่มีตัวระบุอุปกรณ์ ไม่มีที่อยู่ IP ไม่มีการแสดงตัวอย่างเนื้อหา เหตุการณ์ถูกบัฟเฟอร์ในหน่วยความจำและส่งบนพื้นฐานความพยายามที่ดีที่สุด; การส่งที่ล้มเหลวถูกทิ้ง ไม่ลองอีกครั้ง การวัดประสิทธิภาพถูกออกแบบมาให้สามารถปิดใช้งานได้ที่ชั้นเครือข่ายโดยไม่กระทบต่อผลิตภัณฑ์

6. การยืนยันตัวตน

6.1 การลงชื่อเข้าใช้ด้วย Magic-Link

การเข้าสู่ระบบใช้โทเค็นที่ใช้ครั้งเดียว ซึ่งมีลายเซ็น HMAC ส่งไปที่กล่องอีเมลของคุณ ลิงก์นี้มีอายุ 15 นาทีและการไถ่ถอนจะถูกเรียกร้องทันที ดังนั้นการใช้งานพร้อมกันหรือนำกลับมาใช้ซ้ำจะล้มเหลว เมื่อสำเร็จ เบราว์เซอร์จะได้รับข้อมูลโปร่งใส __Host-qub_session คุกกี้กับ Secure, HttpOnly, SameSite=Strict, และ Path=/ คุณลักษณะ

เซสชันมีข้อจำกัดความว่าง 30 วันและข้อจำกัดสูงสุด 90 วัน หมุนเวียนหลังจาก 24 ชั่วโมง และยอมรับเฉพาะรุ่นก่อนหน้าทันทีสำหรับช่วงเวลายอมความตอบกลับที่หายไป 120 วินาที การเปลี่ยนแปลงบัญชีที่ละเอียดอ่อนต้องการการตรวจสอบตัวตนภายใน 10 นาทีที่ผ่านมา ความลับการลงชื่อ HMAC เป็นการผูกกับแพลตฟอร์ม; การอ่านเฉพาะเมทาดาต้าไม่ทำให้เกิดโทเค็นที่ถูกต้องโดยตัวมันเอง

6.2 API Keys (ระดับนักพัฒนา)

API key ของนักพัฒนาใช้คำนำหน้า qub_sk_ เพื่อการรู้จำและ grepability ที่ง่าย แต่ละคีย์:

endpoint การจัดการคีย์ของผู้ดูแลถูกล้อมรอบด้วยข้อมูลรับรองผู้ดูแลแยกต่างหาก

6.3 การรับรองอีเมล (การลงนามการประพันธ์)

การผูกที่อยู่อีเมลกับคีย์ลงนามต้องการ:

  1. การครอบครองคีย์ลงนามส่วนตัว (คุณลงนามคำท้าทาย)
  2. การครอบครองกล่องอีเมล (คุณป้อนรหัส 6 หลักที่ส่งทางอีเมล)

อย่างใดอย่างหนึ่งเพียงอย่างเดียวไม่เพียงพอ การเพิกถอนเป็นบันทึกที่ลงนามบนบัญชีของคุณเองและมีผลทันที; ตัวดูที่ดึงการรับรองเห็นสถานะที่ถูกเพิกถอนและแสดงตามนั้น

7. การชำระเงิน

การป้อนบัตรและการประมวลผลดำเนินการภายในหน้าเช็คเอาต์ที่โฮสต์โดย Stripe เราไม่เคยได้รับหมายเลขบัตร วันหมดอายุ หรือ CVC ของบัตร เราจะเก็บข้อมูลตัวระบุลูกค้าและการสมัครสมาชิกของ Stripe สถานะการสมัครสมาชิก และข้อมูลรอบระยะเวลาไว้ในระเบียนสิทธิ์/คีย์ API เพื่อให้สามารถตรวจสอบการเข้าถึง การต่ออายุ การวัด การยกเลิก และการคืนเงินได้ ข้อความความเป็นส่วนตัวและความปลอดภัยของ Stripe จะควบคุมการจัดการข้อมูลการชำระเงินของมัน

endpoint การผนึกตรวจสอบบันทึกสิทธิประโยชน์เทียบกับตัวระบุอุปกรณ์และ สำหรับผู้ใช้ที่ลงชื่อเข้าใช้ เทียบกับตัวตนที่เชื่อมโยง สิทธิประโยชน์ไม่สามารถถูกใช้ซ้ำในอุปกรณ์ต่างๆ โดยไม่ที่ผู้ใช้ฟื้นฟูอย่างชัดแจ้งผ่านการลงชื่อเข้าใช้ด้วย magic-link

8. การต้านทานการละเมิด

8.1 การตรวจจับบอท

โฟลว์การผนึกถูกล้อมรอบด้วยทางเลือก CAPTCHA ที่รักษาความเป็นส่วนตัวที่ไม่ใช้คุกกี้สำหรับการติดตามและไม่สร้าง fingerprint สำหรับการโฆษณา ความท้าทายที่ล้มเหลวถูกปฏิเสธโดย edge Worker ของเราก่อนที่จะมีการประมวลผลฝั่งการผนึกใด

8.2 การจำกัดอัตรา

การจำกัดอัตราถูกบังคับใช้ที่หลายชั้น:

ตัวนับและการอ้างสิทธิ์อะตอมจะถูกแจกจ่ายไปทั่ว KV, Durable Objects และการผูกอัตรา จำกัด ของแพลตฟอร์มตามข้อกำหนดความสอดคล้องของจุดสิ้นสุด คำขอที่ถูกจำกัดอัตราจะส่งกลับ 429; จุดสิ้นสุดที่สามารถคำนวณหน้าต่างการลองใหม่ได้รวมถึง Retry-After.

8.3 การจัดการเนื้อหา

เส้นทางการอัปโหลดผ่านเบราว์เซอร์เริ่มต้นไม่สามารถสแกนเนื้อหาได้: มันรับเพียงสิ่งประดิษฐ์ที่ถูกผนึกโดยลูกค้าเท่านั้น ผู้สร้าง /api/v1/seal เส้นทางเห็นข้อความธรรมดาเป็นการชั่วคราว และการจัดเตรียมข้อตกลงถือเงื่อนไขที่มีโครงสร้างจนกว่าจะสรุป แต่ข้อยกเว้นความไว้วางใจเหล่านั้นไม่ทำให้เส้นทางอัปโหลดที่ไม่ตรวจเนื้อหาโดยทั่วไปกลายเป็นตัวสแกนเนื้อหา การดูแลปฏิบัติการคือ รายการปฏิเสธ ที่ชั้นผู้ชม: qub ที่อยู่ในรายการปฏิเสธจะถูกผู้ชมของเราปฏิเสธไม่ว่าข้อมูลที่จัดเก็บจะยังสามารถเข้าถึงได้หรือไม่ การใส่ในรายการปฏิเสธไม่ได้ถอนข้อมูลไบต์ที่คงทน รายการในบันทึกความโปร่งใส หรือข้อมูลเครือข่ายถาวรที่เผยแพร่แล้ว

รายงานการละเมิดถูกจำกัดอัตราโดยใช้ hash ทางเดียวของ IP ของผู้รายงาน; เราไม่จัดเก็บ IP แบบไม่ได้เข้ารหัสสำหรับวัตถุประสงค์นี้

9. ห่วงโซ่อุปทานและความสมบูรณ์ของ Build

9.1 การ Pin Toolchain

เวอร์ชันของคอมไพเลอร์และรันไทม์ถูกกำหนดไว้ในการกำหนดค่าที่เก็บ และการพึ่งพาได้รับการแก้ไขผ่านไฟล์ล็อกที่ถูกคอมมิต ระบบ CI ตรวจสอบความสดใหม่ของไฟล์ที่สร้างขึ้นและความไม่เปลี่ยนแปลงที่ไวต่อการทำซ้ำ เราไม่ได้อ้างอย่างเข้มงวดว่าการสร้างที่สะอาดทุกครั้งจะเหมือนกันทุกบิตบนเครื่องที่รองรับทั้งหมด

9.2 Lints และการวิเคราะห์แบบสถิต

workspace เปิดใช้กลุ่ม lint ที่เข้มงวดที่สุดของเราที่ระดับ deny CI ถือทุกคำเตือน — รวมถึงคำเตือนลิงก์เอกสาร — เป็นความล้มเหลวของ build นี่เป็นโดยตั้งใจ: เราใช้ความเข้มงวดของ lint เป็น tripwire สำหรับการ regression ที่เล็กน้อย

9.3 CI Gates

กระบวนการทำงาน CI ครอบคลุมการจัดรูปแบบและการตรวจสอบ lint อย่างเข้มงวด การทดสอบ Rust, WASM/เบราว์เซอร์, Worker, embed, และ API การตรวจสอบชนิดข้อมูล การตรวจสอบความครอบคลุมของโค้ด การตรวจสอบการเปลี่ยนแปลง/ค่าคงที่ การวิเคราะห์โค้ดและเวิร์กโฟลว์แบบสแตติก การตรวจสอบคีย์ i18n ความครอบคลุม ความคลาดเคลื่อน และจุดโค้ดที่เป็นอันตราย ความสดใหม่ของเอกสารที่สร้าง/API/ฐานความรู้ การตรวจสอบเอกสารภายในลิงก์และรายการเอกสาร งบประมาณของสไตล์ชีตและบันเดิล และการตรวจสอบความถูกต้องของ OpenAPI งาน mutation บางงานที่ใช้ทรัพยากรมากจะถูกตั้งเวลาแทนที่จะรันทุกครั้งที่มีการ push

จำเป็นเพียงหนึ่งรายการ ci การรวบรวมยังคงเป็นสีแดงหากงานที่จำเป็นใด ๆ ล้มเหลว งาน workflow ของสาขาที่ได้รับการป้องกันและการปรับใช้จะใช้ผลลัพธ์นั้นแทนที่จะทำซ้ำเกตความปลอดภัยขนาดเล็ก

9.4 การทดสอบ Mutation

งานรายสัปดาห์รันการทดสอบ mutation ต่อโมดูลที่บริสุทธิ์ที่สำคัญด้านความปลอดภัย: hashing, canonical CBOR, การผนึก, การปลดล็อก, newtypes รูปแบบ wire, ตัวตรวจสอบประเภทโปรโตคอล และ namespace handle การทดสอบ mutation ตอบ "ชุดการทดสอบของเราจับโค้ดที่ผิดเล็กน้อยหรือไม่?" — หากการนำไปใช้ที่กลายพันธุ์ยังคงผ่านการทดสอบทั้งหมด เรารู้ว่าเรามีช่องว่างในการครอบคลุมการทดสอบและแก้ไข

9.5 Git Hooks

hooks ในเครื่อง (pre-commit, pre-push) สะท้อน CI gates ดังนั้น regression ถูกจับก่อนที่จะออกจากเครื่องของนักพัฒนา hooks ถูกติดตั้งผ่านสคริปต์ repo; ไม่ถูกข้ามใน workflow ของเราและ CI เป็น gate ที่เป็นทางการหากถูกข้าม

10. การทดสอบ

โค้ดที่สำคัญด้านความปลอดภัยถือการทดสอบสามประเภท:

11. สุขภาพของสาขาและการปล่อย

สาขาฟีเจอร์ก้าวหน้า staging เฉพาะผ่านคำขอดึง Gate 1: จำเป็น ci สีเขียว, ไม่มีคำขอเปลี่ยนแปลงที่ยังไม่ได้แก้ไข, ไม่มีความขัดแย้งในการรวม, และมีต้นไม้ที่ได้รับการตรวจสอบอย่างเรียบร้อย; การรวมเป็นแบบ squash และลบ main ก้าวหน้าได้เฉพาะผ่านประตู 2 staging → main คำขอการดึงและรักษาบรรพบุรุษด้วยคอมมิตการรวม การผลักสาขาโดยตรงไม่ใช่วิธีการทำงานของการปล่อย

การปรับใช้ในสเตจและการผลิตจะถูกเรียกใช้จากการป้องกันที่เกี่ยวข้อง staging และ main สาขาหลังจาก CI รหัส pull-request และข้อมูลรับรอง fork จะไม่ได้รับความลับในการปรับใช้

ความลับที่ใช้ใน workflows การ deploy ถูกขอบเขตไปยังสภาพแวดล้อมการ deploy โดยแพลตฟอร์ม CI ของเรา ไม่มีให้สำหรับ workflows ของ pull request จาก forks

12. การเปิดเผยที่ประสานงาน

หากคุณเชื่อว่าคุณพบช่องโหว่ด้านความปลอดภัยใน qub เราต้องการได้ยินจากคุณอย่างรวดเร็วและเรามุ่งมั่นที่จะจัดการรายงานอย่างมืออาชีพ

เรารับทราบการรับภายในสามวันทำการและทำให้คุณได้รับข้อมูลในขณะที่เราตรวจสอบ ด้วยความยินยอมของคุณ เราให้เครดิตผู้รายงานในบันทึกการปล่อย

12.1 Safe Harbor

หากการวิจัยของคุณปฏิบัติตามกฎข้างต้น (การสอบสวนโดยสุจริต ไม่เป็นอันตรายต่อผู้ใช้อื่นหรือบริการ กรอบเวลาการเปิดเผยที่เหมาะสม) เราจะไม่ดำเนินคดีทางกฎหมายต่อคุณ และเราจะไม่ขอให้การบังคับใช้กฎหมายทำ เราถือว่างานของคุณเป็นการทดสอบที่ได้รับอนุญาตและเราอยากให้คุณพบบั๊กมากกว่าใครคนอื่น

Safe Harbor นี้ใช้บังคับกับ:

ไม่ใช้บังคับกับการ social engineering ของสมาชิกทีม qub การทดสอบ denial-of-service หรือการเข้าถึงข้อมูลของผู้ใช้คนอื่นเกินกว่าที่จำเป็นในการแสดงให้เห็นถึงปัญหา หากคุณไม่แน่ใจว่ามีอะไรอยู่ภายใน Safe Harbor หรือไม่ ถามก่อนโดยใช้คำนำหน้าหัวข้อ [SECURITY] เดียวกัน

13. ข้อจำกัดที่ซื่อสัตย์

ความปลอดภัยคือการปฏิบัติ ไม่ใช่สถานะ ข้อจำกัดบางอย่างควรค่าแก่การตั้งชื่อโดยตรง:

14. การเปลี่ยนแปลงหน้านี้

การเปลี่ยนแปลงที่สำคัญถูกระบุโดยการอัปเดตวันที่มีผลที่ด้านบน ในกรณีที่การเปลี่ยนแปลงสะท้อนการปรับปรุงด้านความปลอดภัยที่เป็นรูปธรรม เราอธิบายโดยย่อใน changelog สาธารณะ ในกรณีที่การเปลี่ยนแปลงสะท้อนการชี้แจงนโยบาย เราอธิบายว่าอะไรเปลี่ยนแปลงและทำไม

สำหรับคำถามเกี่ยวกับสิ่งใดบนหน้านี้ อีเมล support@qub.social พร้อมคำนำหน้าหัวข้อ [SECURITY]

15. บันทึกการเปลี่ยนแปลง

รุ่น วันที่มีผลบังคับใช้ สรุป
1.1 23 กันยายน 2026 ปรับให้ข้อเรียกร้องทางด้านการเข้ารหัส วิธีการจัดส่ง การจัดเก็บ CSP เซสชัน คีย์ API การชำระเงิน CI และกระบวนการปล่อยงานสอดคล้องกับระบบที่นำไปใช้
1.0 2 พฤษภาคม 2026 การตีพิมพ์เริ่มต้น