الأمان في qub

تاريخ السريان: 23 سبتمبر 2026 الإصدار: 1.1 — مراجعة دقة التنفيذ

للباحثين — مرجع سريع:

• أين تُرسل البلاغات: support@qub.social مع بادئة الموضوع [SECURITY].
• ما تُرفقه: الثغرة، خطوات الإنتاج، وأيّ إثبات مفهوم.
• استجابتنا: نُقرّ بالاستلام خلال 3 أيّام عمل ونهدف إلى شحن إصلاح خلال 90 يومًا.
• الملاذ الآمن: لن نُلاحق قضائيًّا الأبحاث حسنة النيّة التي تتّبع القواعد في §12 (لا وصول إلى بيانات ليست لك، لا تدهور الخدمة، لا الاحتفاظ بالبيانات المُحصَّلة بما يتجاوز ما يلزم لإظهار المشكلة، أعطنا نافذة إفصاح معقولة).

التفاصيل الكاملة في §12 (الإفصاح المُنسَّق).

من نحن

qub.social تُشغَّل بواسطة VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330)، Level 38, 71 Eagle Street, Brisbane QLD 4000, Australia. تشير عبارات "qub" و"نحن" و"لنا" إلى هذا الكيان.

التواصل بشأن الأمان: support@qub.social مع بادئة الموضوع [SECURITY].

1. نهجنا

qub بنية ثقة. المنتج بلا قيمة إن لم يكن آمنًا، لذا الأمان ليس ميزة — هو الركيزة. تصف هذه الصفحة، بعبارات ملموسة، كيف نحمي مكدّسنا، وبياناتك، ونزاهة المحتوى المختوم.

تنمو قيمة الالتزام الزمني القابل للتحقّق كلّما أصبح المزيد من الإنترنت مولّدًا آليًا. يمكن لمعاملة تخزين مُتحقَّق منها أو مرساة في سجل الشفافية أن تثبت أن النص المشفر كان موجودًا في موعد أقصاه وقت كتلتها؛ وتثبت القطعة المختومة، بصورة منفصلة، نزاهة المحتوى وربطه بجولة drand وأي توقيعات نسب. إبقاء هذه الادعاءات منفصلة هو المعيار الذي تُمسَك به هذه الصفحة.

لا نطلب منك أن تثق بنا. نُصمّم بحيث تكون الثقة المطلوبة منّا أصغر ما يمكن، وحيث تكون الثقة مطلوبة نشرح بالضبط ما هو موضع الثقة ولماذا.

ثلاثة مبادئ تُوجّه كلّ قرار تصميمي:

• تقليل ما يستطيع الخادم رؤيته. في تدفّق رسائل المتصفح الافتراضي، يبقى النص الواضح ومفتاح الغلاف على جهازك. للختم عبر Builder من جانب الخادم، والتوقيع المشترك على المواثيق، والاسترداد المفعّل صراحةً حدود ثقة مختلفة موضحة أدناه. وحيث نحتفظ ببيانات، نقصرها على ما تحتاج إليه الميزة المختارة.
• جعل التسوية مُحتواةً محلّيًّا. اختراق أيّ مكوّن (خادمنا، مزوّد البريد، عقدة drand) لا ينبغي أن يكشف محتوى مختومًا لم يصل بعد إلى وقت كشفه.
• جعل البروتوكول قابلًا للتدقيق. القطعة المختومة قابلة للتحقّق من طرفٍ إلى طرف بتشفيرٍ عام. لا تحتاج إلى الوثوق بـ qub الخدمة للتحقّق من qub القطعة.

2. نموذج التهديد

2.1 ما الذي نحمي منه

• مهاجم يحصل على وصول قراءة إلى بياناتنا المخزنة على جانب الخادم قبل وقت الكشف. في تدفّق المتصفح الخاص الافتراضي، يحصل على بيانات وصفية وبايتات مغلّفة معتمة، لا على النص الواضح أو K. لا تنطبق هذه الحماية على K المحتفظ به صراحةً للاسترداد، أو التسليم العام/المجرّد بعد جولة drand، أو النص الواضح المقدَّم مؤقتًا إلى /api/v1/seal في Builder وتدفّقات المواثيق.
• مهاجم يعترض حركة المرور بين متصفّحك وبنيتنا التحتيّة. يُنهي TLS عند حافّة CDN لدينا؛ الحمولات المختومة مُشفَّرة بالفعل قبل النقل.
• مهاجم يعبث بحمولة مخزنة. تجعل مصادقة الغلاف الخارجي (عند وجوده)، وفك الترميز القانوني، وتجزئة المتن، وإعادة اشتقاق qub_id، وربط الجولة، والتوقيعات الاختيارية العبث يفشل التحقق؛ ويرفض العارض تصيير qub.
• مهاجم يحاول ربط بريد إلكتروني مُزوَّر لمؤلّف بمفتاح توقيع. يتطلّب إقرار البريد الإلكتروني حيازة كلٍّ من مفتاح التوقيع الخاصّ ورمز مرّة واحدة يُسلَّم إلى صندوق البريد الإلكتروني.
• مُشغِّل منارة drand مُختَرَق. تستخدم شبكة drand توقيعات BLS عتبيّة عبر عدّة مُشغّلين مستقلّين؛ لا تستطيع أقلّيّة تزوير توقيعات إصدار مبكّر.

2.2 ما لا نستطيع الحماية منه

نحن صادقون بشأن حدودنا. لا يستطيع qub الدفاع ضدّ:

• اختراق جهازك قبل أن تختم. برامج تسجيل المفاتيح المحلّيّة، أو امتدادات المتصفّح الخبيثة، أو الوصول الفيزيائي إلى جهاز غير مقفل يمكنه التقاط النصّ الواضح عند نقطة التأليف.
• انهيار عتبة drand. عدّة منظّمات مستقلّة تُشغّل شبكة drand خصّيصًا لجعل ذلك صعبًا، لكنّه ليس مستحيلًا تشفيريًّا: إن تواطأ عدد كافٍ من المُشغّلين، يمكنهم اشتقاق مفاتيح القفل الزمني مبكّرًا.
• خصائص الإصدار لنسخة صالحة. يصبح qub العام/المجرّد قابلًا لفك التشفير بعد جولة drand الخاصة به. ويتطلب qub الخاص/المغلّف K أيضًا؛ ويمكن لمن يحصل على البايتات المخزنة وK معًا أن يفك التشفير بعد الجولة. ولا يمكن استدعاء سجلات التخزين الدائم أو السجل المُرسى بمجرد إزالتها من سطح منتج qub.
• عدوّ عالمي يكسر التشفير الأساسي (AES-GCM، افتراضات الإقران BLS12-381، SHA3-256، ML-DSA-65). إن سقطت هذه البدائيّات، فلدى النظام البيئي التشفيري الأوسع مشاكل أكبر.

3. التشفير على جانب العميل

في تدفّق رسائل المتصفح الافتراضي، يحدث تشفير المحتوى قبل طلب الرفع. ويختلف مساران صريحان: يرسل /api/v1/seal في Builder عمدًا النص الواضح وK المولّد لدى المستدعي إلى Worker للختم في الذاكرة، ويرسل تجهيز الميثاق وتوقيعه المشترك الميثاق المهيكل الموقّع إلى الخدمة كي تُنجز القطعة الثنائية. ولا ينبغي الخلط بين أي من هذين الاستثناءين وبين التشفير من طرف إلى طرف في مسار المتصفح.

3.1 تشفير القفل الزمني

يستخدم qub tlock — تشفير قائم على الهويّة مُفتاحه جولة منارة drand مستقبليّة. يجري التشفير في متصفّحك باستخدام المفتاح العامّ لشبكة drand؛ يُفرَج عن مفتاح فكّ التشفير علنيًّا من شبكة drand فقط عند بلوغ الجولة المستهدفة. لا أحد، بما فيه نحن، يستطيع إعادة بناء مفتاح فكّ التشفير مُسبقًا.

نستهدف سلسلة quicknet:

• فترة جولة 3 ثوانٍ
• وضع غير مُتسلسل (كلّ جولة مستقلّة)
• توقيعات BLS12-381 G1
• تجزئة السلسلة 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

المفتاح العامّ لسلسلة quicknet ووقت التكوين مُجمَّعان في العميل. لا نجلب معاملات السلسلة وقت التشغيل، لذا لا يمكن لعقدة خبيثة استبدال سلسلة نتحكّم بها.

3.2 التشفير المتماثل

يُغلّف مخطّط tlock مفتاح محتوى AES-256-GCM. يوفّر AES-GCM تشفيرًا مُصادَقًا: بِتٌّ واحد مقلوب في النصّ المُشفَّر يُسبّب فشل فكّ التشفير، بدلًا من إنتاج نصّ واضح فاسد بصمت.

3.3 التسلسل القانوني

تُسلسَل هياكل البروتوكول باستخدام CBOR الحتمي (RFC 8949 §4.2 الترميز الحتمي الأساسي). يُنتج تطبيقان يرمزان البنية المنطقية نفسها CBOR متطابقًا. أما الحمولات المختومة الكاملة فليست حتمية: يستخدم تشفير tlock والغلاف الخارجي عشوائية جديدة. تُحسب تجزئة المتن على بايتات المتن الخام، بينما يجعل الترميز القانوني الهياكل الموقعة وهياكل السلك غير ملتبسة.

كتبنا مُرمِّز CBOR يدويًّا لكلٍّ من تطبيق العميل والخادم بدلًا من الاعتماد على مكتبة تسلسل عامّة — المتطلَّب هو الدقّة، لا الأرغونوميّة، وتجري اختبارات الخواصّ في كلا التطبيقَين للتحقّق من توافقهما.

يُؤكّد اختبار انحدار أنّ صيغة الإرسال القانونيّة لا تحتوي على أيّ تسلسل بايت لعلامة qub التجاريّة بما يتجاوز مفتاح الحقل البدائي للبروتوكول qub_id. صيغة الإرسال محايدة للعلامة التجاريّة عمدًا — أيّ عارض مُتوافق (لنا أو لطرفٍ ثالث) يستطيع تصيير أيّ qub من التخزين الدائم، بغضّ النظر عن أيّ نشرٍ ختمه. الاختبار سلك تعثّر يمنع تغييرًا مستقبليًّا من خَبْز مرجع علامة تجاريّة بالخطأ في بايتات، بمجرّد أن تكون في التخزين الدائم، لا يمكن إعادة كتابتها.

3.4 تجزئة المتن والنزاهة قبل الكشف

كل حمولة مختومة تحمل تجزئة SHA3-256 لبايتات متنها الخام. ترتبط التجزئة بـ qub_id، وعند تفعيل توقيع النسب، بمدخل توقيع V2. يعيد العارض حسابها بعد فك التشفير ويرفض عدم التطابق.

يُشتق معرّف المحتوى qub_id بطول 32 بايت من صورة أولية بطول 108 بايت تغطي إصدار البروتوكول، ونوع المحتوى، وطابعي وقت الإنشاء والفتح، وطابع وقت النتيجة الاختياري (أو الحارس الصفري)، وجولة drand المستهدفة، وتجزئة المتن، وتجزئة SHA3-256 للعنوان الاختياري المُطبَّع NFC. لا تستطيع بوابة أو CDN تغيير أي حقل مرتبط بصورة متسقة واجتياز إعادة الاشتقاق. تُحدَّد العناوين بـ 100 نقطة شيفرة NFC وتُرفض إذا احتوت الفئة المشتركة من نقاط الشيفرة العدائية أو التحكّمية (بما فيها تجاوزات bidi، والأحرف صفرية العرض، وكتلة الوسوم، وBOM، وC0، وC1، وDEL).

3.5 التوقيع (ML-DSA-65)

يستخدم توقيع النَّسب ML-DSA-65 (FIPS 204)، مخطّط توقيع ما بعد كمومي مُوحَّد من NIST. اخترنا عمدًا بدائيّة ما بعد كموميّة للتوقيع لأنّ المحتوى المختوم دائم: توقيع يُتحقَّق منه اليوم يجب أن يُتحقَّق منه بعد عقود من الآن، بما في ذلك بعد أن تصبح أجهزة الحوسبة الكموميّة الواسعة عمليّة.

تُولَّد مفاتيح التوقيع في المتصفح. يُغلَّف السر المحلي تحت مفتاح WebCrypto غير قابل للاستخراج قبل تخزينه في IndexedDB. وإذا استُخدمت ميزة الاسترداد عبر الأجهزة المحددة بنطاق الحساب، يُخزَّن على جانب الخادم كائن مفتاح محمول مشفّر بـ AEAD؛ ويرتبط نص مفتاحه السري المشفر بمعرّف الحساب الثابت، وتتحقق الخدمة من الظرف العام لكنها لا تستطيع فك تشفير المادة السرية. لا تُرسل بايتات المفتاح الخاص الخام إلى الخادم. وتُخزَّن المفاتيح العامة وسجلات الإقرار للتحقق وعرض الهوية.

ينطبق فكّ تشفير tlock في المتصفّح نفسه داخل تضمين qub: حين يُصيَّر qub مختوم عبر <qub-embed> على صفحة طرف ثالث، يحدث فكّ التشفير في إطار التضمين iframe في متصفّح المُشاهد. التضمين لا يُغيّر نموذج الثقة — لا يُفكّ تشفير النصّ الواضح أبدًا على خادم qub.

3.6 النَّسب العامّ — اختياري

لا تحمل qubs المختومة أيّ مؤشّر على السلسلة إلى مُنشِئها ما لم يختر المُنشِئ صراحةً إرفاق واحد. حين تختم qub، يُصدر التطبيق المرجعي وسم تخزين Author (بصمة hex بطول 64 حرفًا لمفتاح التوقيع العامّ الخاصّ بك) فقط عند تفعيل "النَّسب العامّ" في خطوة منتقي التاريخ. مع إيقاف التبديل — الافتراضي — لا يُكتب وسم Author ويكون qub بلا نسبٍ في التخزين الدائم: لا شيء في التخزين يربط الرفع بـ handle، أو بريدك الإلكتروني، أو qubs الأخرى الخاصّة بك. مع تشغيل التبديل، تُحلّ البصمة إلى @handle الخاصّ بك عبر سلسلة الإقرار في §6.3 / §10 ويُظهر العدّ التنازلي للعارض "مختوم بواسطة @{handle}" قبل الكشف.

هذا ضمان متعمّد ضدّ مخاطر التعداد التي سيُنشئها وسم Author دائم التشغيل: طرف ثالث يتعلّم بصمة مُنشِئ يمكنه بطريقةٍ أخرى البحث في التخزين الدائم بالوسم وإعادة بناء كامل النتاج التاريخي لذلك المُنشِئ. النَّسب الاختياري يُغلق تلك القناة — فقط qubs التي يختار المُنشِئ صراحةً نسبها تظهر تحت بصمة في التخزين الدائم.

صفحة الملفّ التعريفي /u/{handle} بطاقة هويّة مُحقَّقة — handle، اسم عرض اختياري + URL، شارة "بريد إلكتروني مُحقَّق" (دون عنوان)، والشكل القصير للبصمة التشفيريّة. لا تُدرج qubs المُنشِئ. الزوّار الذين يريدون رؤية qub مُحدّد من مُنشِئ يتّبعون URL تسليم ذلك qub مباشرةً.

3.7 غلاف التشفير الخارجي

حتى بعد أن يصبح فك تشفير القفل الزمني ممكنًا رياضيًا—عند نشر توقيع drand للجولة المرتبطة—تسمح طبقة القفل الزمني القانونية وحدها للمفهرس بفك تشفير qubs القابلة للاكتشاف بالجملة. يُغلق التسليم الخاص تلك القناة بطبقة متماثلة إضافية حول البايتات المشفرة بالقفل الزمني (البروتوكول §13). أما التسليم العام فيحذف الغلاف عمدًا كي تعمل روابط الإشعارات والتضمين والاكتشاف بلا جزء سري.

يستخدم الغلاف AES-256-GCM، وهو تشفير مُصادَق مُوحَّد من NIST، مع مفتاح طازج بطول 256-بت K يُولَّد لكلّ qub بواسطة CSPRNG في متصفّحك. يرتبط K بـ qub_id لـ qub كبيانات إضافيّة مُصادَقة، لذا لا يمكن إعادة استخدام مفتاح من qub واحد لفكّ تشفير qub مختلف.

لا يصل K إلى خوادمنا في تدفّق المتصفح الخاص الافتراضي. يُرمَّز في جزء URL لرابط المشاركة (https://qub.social/c/<tx_id>#<base64url(K)>). لا ترسل المتصفحات أجزاء URL إلى الخوادم—يضع RFC 3986 الجزء خارج الطلب—لذا لا ترى qub.social، أو بوابات التخزين، أو شبكات CDN، أو مراقبة الطلبات K في ذلك التدفّق. يُعد OuterWrapper المخزّن بنية CBOR قابلة للتمييز، لكن حقل النص المشفّر المُصادَق فيه يخفي بنية SealedQub الداخلية ولا يمكن فتحه من دون K.

النتائج الصافية:

• لا تستطيع qub.social فك تشفير أختام المتصفح الخاصة الافتراضية من البيانات المخزنة وحدها. يصل اختراق مخزن البيانات إلى نص مشفر معتم بلا K. ولـ qubs العامة والمفعّل لها الاسترداد تعرّض مختلف تصميميًا.
• لا يمكن استرداد فقدان الجزء من دون قناة استرداد مختارة. إذا حفظت رابطًا خاصًا دون الجزء ولم تفعّل الاسترداد، يصبح qub غير قابل للقراءة عبر ذلك الرابط. ويعرض تدفّق الختم إفصاحًا صريحًا بـ "احفظ هذا URL" لهذا السبب.
• استرداد اختياري. عند اختيارك لتلقّي رسائل دورة حياة المُنشِئ لـ qub و يطابق البريد الإلكتروني هويّتك المُحقَّقة، نقبل K مع الرفع، ونُخزّن URL التسليم الكامل على سجلّ التاريخ المختوم لهويّتك، ونستخدمه كرابط في بريد تأكيد الخَتْم. هذه المقايضة — قناة استرداد على جانب الخادم مقابل بعض النقاء من طرفٍ إلى طرف — تنخرط فقط عند الاختيار الصريح وفقط لذلك qub. الوضع الافتراضي هو تمزيق التشفير.

نقطة نهاية /api/v1/seal على جانب الخادم لـ Worker (المُستخدَمة من قِبَل وكلاء الذكاء الاصطناعي وسائر مستدعي API) تتطلّب من المُستدعي أن يُولّد K بواسطة CSPRNG، وأن يحتفظ به محلّيًّا، وأن يُقدّمه كـ wrapper_key_b64url. يرى Worker بالضرورة كلًّا من النصّ العادي وK في الذاكرة على هذا المسار الموثوق صراحةً، لكنه لا يستمرّ بأيٍّ منهما. يمنع Idempotency-Key الإلزامي استجابةً مفقودةً من إنشاء qub ثانٍ مُحاسَب عليه، بينما يمكن دمج K الذي احتفظ به المُستدعي مع رابط URL المُعاد الخالي من الجزء. يختلف هذا عن مسار المتصفّح الافتراضي، حيث لا يصل K إلى Worker أبدًا ما لم يُفعّل المُنشئ الاسترداد صراحةً.

4. النقل والحافّة

4.1 TLS

تُقدَّم حركة مرور المتصفح إلى qub عبر HTTPS عند حافة Cloudflare. وتضبط الاستجابات HTTP Strict Transport Security (max-age=63072000; includeSubDomains; preload). تحكم إعدادات الحافة النشطة إصدار TLS ومجموعة التعمية المتفاوض عليهما، بدلًا من أن تدّعيهما شيفرة التطبيق. ولا نكشف خادم أصل يمكن الوصول إليه منفصلًا.

4.2 أمان المحتوى

يُقدَّم العميل المُصرَّف برؤوس content-type وتخزين مُؤقَّت صارمة. غلاف SPA من أصلٍ واحد. لا نُضمِّن سكربتات طرف ثالث للتحليلات أو الإعلانات. نقطتا اللمس مع الطرف الثالث في المنتج كلتاهما محدودتا النطاق: تدفّق الشراء يغادر SPA بالكامل بإعادة توجيه صفحة كاملة إلى الدفع المستضاف من Stripe (https://checkout.stripe.com/…) — واجهة Stripe لا تُنفَّذ أبدًا في أصلنا ولا نرى بيانات البطاقة أبدًا — وتدفّق الخَتْم يُحمّل أداة Turnstile من Cloudflare، بديل CAPTCHA يحفظ الخصوصيّة يُصيّره Cloudflare داخل إطار iframe رمليّ خاصّ به. لا يستطيع أيّ منهما قراءة بقيّة الصفحة.

يحمل إطار تضمين qub iframe (المقدَّم من qub.social/embed/{tx_id} والمحمل في مواقع طرف ثالث بواسطة embed.js) سياسة Content-Security-Policy خاصة به. قائمة connect-src المسموح بها هي 'self'، وhttps://qub.social، وhttps://arweave.net، وhttps://ar-io.dev، وhttps://permagate.io، وhttps://api.drand.sh، وhttps://drand.cloudflare.com. يعمل الإطار بـ sandbox="allow-scripts allow-top-navigation-by-user-activation" (لا بـ allow-same-origin): لا تستطيع الصفحة المضيفة قراءة DOM الخاص به، ولا يستطيع التنقل في المضيف إلا بعد إجراء من المستخدم.

4.3 CORS ونطاق Fetch

يُقدّم عميل المتصفّح طلبات fetch فقط إلى:

• API الخاصّ بنا (api.qub.social ومُعادلات المرحلة)
• بوّابات التخزين (للقراءة فقط، لاسترداد البايتات الخاصة المغلَّفة أو العامة العارية — §3.6)
• نقاط نهاية منارة drand (للقراءة فقط، لتوقيعات جولة وقت الكشف)

تفرض CSP الخاصة بالتضمين وجهاته. أما الوجهات المقصودة لـ SPA الرئيسي فمثبتة في الشيفرة والإعدادات وتمارسها اختبارات المتصفح والتكامل؛ وليست Subresource Integrity أداة تحكم بوجهات الشبكة.

يجلب التضمين البايتات المخزنة عبر أصول qub/التخزين المسموح بها، ويفكّ غلاف الحمولات الخاصة في المتصفح باستخدام K من جزء URL الخاص به، ويجلب توقيعات جولة وقت الكشف من أصلي drand المسموح بهما. ويستخدم SPA الرئيسي مجموعة البدائل ذات النقاط الأربع في config/drand-endpoints.json (drand.cloudflare.com وapi.drand.sh وapi2.drand.sh وapi3.drand.sh) كي لا يمنع تعطل نقطة واحدة الكشف. وتحظر CSP الخاصة بالتضمين الاتصالات خارج قائمتها الصريحة.

5. البنية التحتيّة على جانب الخادم

5.1 حافّة خادمية بلا خوادم

يعمل API الخاصّ بنا بالكامل على بيئة تشغيل مُدارة بلا خوادم عند الحافّة. لا توجد VMs، لا حاويات، ولا عمليّات خادم دائمة نُديرها. هذا يُقلّص بشكلٍ كبير سطح الهجوم الذي نحن مسؤولون عنه: لا نُشغّل OS، أو خادم ويب، أو بيئة تشغيل تطبيق علينا تصحيحها.

يتم تطبيق وسيط 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-restricted.

5.2 التخزين

• مخازن البيانات الوصفية والتنسيق تحمل سجلات الهوية والإقرار، والاستحقاقات ومراجع الفوترة، وسجلات مفاتيح API، وإدخالات قائمة الحظر، والجلسات، وحالة منع التكرار، والطوابير، وحالة تحديد المعدل والتزامن. وتستخدم احتياجات الاتساق المختلفة KV وD1 وDurable Objects بدلًا من مخزن واحد شامل.
• مخزن الكائنات لدينا ركيزة متانة أيضًا. يحمل بايتات qub المغلّفة أو المجرّدة نفسها التي أُقرّ برفعها، وأوراق سجل الشفافية وعُقد Merkle المحددة بالإحداثيات، ومواد المرساة، وسجلات الأحداث المهيكلة، وذاكرات تخزين مؤقت للاستجابات والبيانات الوصفية.
• التخزين العام الدائم يحمل مراسي سجل الشفافية، ويحمل معاملات qub الفردية لمسار T3 أو النشر المؤجل. لا نشغّل تلك الشبكة. وتظل حمولات المتصفح الخاصة معتمة فيها ما لم يملك الحائز K أيضًا؛ أما الحمولات العامة/المجرّدة فلا تملك عمدًا طبقة القدرة المرتبطة بالرابط الإضافية.

لا يحتفظ تدفّق رسائل المتصفح الافتراضي بالنص الواضح في بنية qub التحتية. يعالج /api/v1/seal في Builder النص الواضح وK في الذاكرة لكنه لا يحتفظ بأي منهما. ويخزّن تجهيز الميثاق بالضرورة الميثاق المهيكل الموقّع حتى يُوقّع عليه الطرف الآخر أو يُسحب أو تنتهي صلاحيته. ويخزّن الاسترداد الاختياري قدرة تسليم (الرابط الكامل الحامل للجزء) كي يمكن استردادها لاحقًا. لذلك لا نصف طبقة التخزين كلها بأنها «بيانات وصفية فقط».

5.3 الأسرار

تُقدَّم الأسرار (محافظ التوقيع، ورموز المزوّدين، ومفاتيح HMAC) عبر ارتباطات أسرار/بيئة في المنصة بدلًا من التحكم بالمصدر. ولا تتلقى مكونات بيئة التشغيل إلا الارتباطات التي تحتاج إليها. وإجراءات التدوير والتداخل خاصة بكل مكوّن؛ ولا ندّعي آلية واحدة شاملة تلقائية أو مدققة للتدوير.

5.4 التسجيل والقياس عن بُعد

تُكتب سجلّات JSON مُهيكَلة على كلّ طلب API بمعرّف ارتباط مُعروض في رأس استجابة X-Request-Id. القياس عن بُعد للعميل مجهول الهويّة — لا معرّف جهاز، لا عنوان IP، لا معاينة محتوى. تُخزَّن الأحداث في الذاكرة وتُتدفَّق على أساس بذل الجهد؛ التدفّق الفاشل يُهمَل، لا يُعاد المحاولة. القياس عن بُعد مُصمَّم ليكون قابلًا للتعطيل على طبقة الشبكة دون التأثير على المنتج.

6. المصادقة

6.1 تسجيل الدخول عبر الرابط السحري

يستخدم تسجيل الدخول رمزًا أحادي الاستخدام موقّعًا بـ HMAC يُسلَّم إلى صندوق بريدك الإلكتروني. الرابط صالح لمدة 15 دقيقة، وتُطالَب عملية الاسترداد ذريًا بحيث يفشل الاستخدام المتزامن أو المعاد بصورة مغلقة. وعند النجاح، يتلقى المتصفح ملف تعريف ارتباط معتمًا باسم __Host-qub_session بسمات Secure وHttpOnly وSameSite=Strict وPath=/.

للجلسات حد خمول 30 يومًا وحد مطلق 90 يومًا، وتدور بعد 24 ساعة، ولا تقبل إلا الجيل السابق مباشرةً لمدة سماح 120 ثانية للاستجابة المفقودة. وتتطلب تغييرات الحساب الحساسة مصادقة خلال الدقائق العشر السابقة. سر توقيع HMAC ارتباط في المنصة؛ ولا تكفي قراءة البيانات الوصفية وحدها لسك رمز صالح.

6.2 مفاتيح API (مستوى المطوّر)

تستخدم مفاتيح API للمطوّرين البادئة qub_sk_ للتعرّف السهل وقابليّة grep. كلّ مفتاح:

• مرتبط بحساب ونطاقات وقائمة اختيارية مسموح بها من عناوين IP CIDR
• يُعرض في صورته الخام مرة واحدة؛ وتحتفظ السجلات الدائمة بتجزئة SHA-256 الخاصة به لا بسر الحامل
• يمكن تدويره مع تعيين سماح لمدة ساعة يُحيل فيه المفتاح القديم إلى البديل
• له حالة حصة وتحديد معدل مستقلة
• لا يُسجَّل بالكامل أبدًا؛ تُسجّل السجلّات معرّف المفتاح فقط

نقاط نهاية إدارة المفاتيح الإداريّة مُسوَّرة خلف اعتماد إداري منفصل.

6.3 إقرار البريد الإلكتروني (توقيع النَّسب)

يتطلّب ربط عنوان بريد إلكتروني بمفتاح توقيع:

1. حيازة مفتاح التوقيع الخاصّ (تُوقّع تحدّيًا)
2. حيازة صندوق البريد الإلكتروني (تُدخل رمزًا من 6 أرقام يُسلَّم بالبريد الإلكتروني)

أيّ منهما وحده غير كافٍ. الإلغاء سجلّ مُوقَّع على حسابك ويسري فورًا؛ المُشاهدون الذين يجلبون الإقرار يرون الحالة المُلغاة ويعرضون وفقًا لذلك.

7. المدفوعات

تجري إدخالات البطاقات ومعالجتها داخل الدفع المستضاف من Stripe. لا نتلقى أرقام البطاقات أو تواريخ الانتهاء أو CVCs. لكننا نخزّن معرّفات عميل Stripe والاشتراك، وحالة الاشتراك، وبيانات الفترة في سجلات الاستحقاق/مفتاح API كي يمكن تسوية الوصول والتجديد والقياس والإلغاء والاسترداد. وتحكم بيانات خصوصية وأمان Stripe تعامله مع بيانات الدفع.

تتحقّق نقطة نهاية الخَتْم من سجلّ الاستحقاق ضدّ معرّف الجهاز، وللمستخدمين المُسجَّلين، ضدّ الهويّة المرتبطة. لا يمكن إعادة استخدام استحقاق عبر الأجهزة دون أن يستعيده المستخدم صراحةً عبر تسجيل الدخول بالرابط السحري.

8. مقاومة الإساءة

8.1 كشف الروبوتات

تدفّق الخَتْم مُسوَّر ببديل CAPTCHA يحفظ الخصوصيّة ولا يستخدم ملفّات تعريف الارتباط للتتبّع ولا يأخذ بصمة للإعلانات. تحدٍّ فاشل يُرفض من Worker حافّتنا قبل أيّ معالجة على جانب الخَتْم.

8.2 تحديد المعدّل

تُفرض حدود المعدّل في عدّة طبقات:

• حدود لكلّ IP ولكلّ مفتاح على نقاط نهاية الخَتْم والقراءة والمصادقة
• حدود لكلّ بريد إلكتروني على طلبات الروابط السحريّة (يمنع إغراق صندوق البريد)
• حدود لكلّ طرف مقابل على بريد دعوة الميثاق (عشرة لكلّ عنوان مستلِم لكلّ يوم UTC، التخفيف الأساسي لإعادة توجيه البريد المزعج؛ المواثيق الصادقة نادرًا ما تقترب من الحدّ الأقصى)
• حدود لكلّ IP على تقديم القياس عن بُعد

تتوزع العدادات والمطالبات الذرية على KV وDurable Objects وارتباطات تحديد المعدل في المنصة بحسب متطلبات اتساق نقطة النهاية. تعيد الطلبات المحدودة بالمعدل 429؛ وتضمّن نقاط النهاية القادرة على حساب نافذة إعادة المحاولة Retry-After.

8.3 إدارة المحتوى

مسار تحميل المتصفح الافتراضي لا يمكنه فحص الجسم: فهو يتلقى فقط الأثر المختوم من العميل. الباني /api/v1/seal يرى الطريق النص الصريح مؤقتًا، وتحتفظ مرحلة الاتفاق بالشروط المنظمة حتى الانتهاء، لكن تلك الاستثناءات الموثوقة لا تحول مسار التحميل العام الأعمى للبايت إلى ماسح محتوى. الإشراف التشغيلي هو قائمة المنع في طبقة المشاهد: يتم رفض qub الممنوع من قبل مشاهدنا بغض النظر عما إذا كانت الحمولات المخزنة لا تزال قابلة للوصول. الحظر لا يسحب البايتات الدائمة، أو إدخالات سجل الشفافية، أو بيانات الشبكة الدائمة التي تم نشرها بالفعل.

بلاغات الإساءة محدودة المعدّل باستخدام تجزئة في اتّجاهٍ واحد لـ IP المُبلِغ؛ لا نُخزّن IPs بشكلٍ واضح لهذا الغرض.

9. سلسلة التوريد ونزاهة البناء

9.1 تثبيت سلسلة الأدوات

إصدارات المصرّف وبيئة التشغيل مثبتة في إعداد المستودع، وتُحل التبعيات عبر ملفات قفل ملتزم بها. تتحقق CI من حداثة الملفات المولدة والثوابت الحساسة لقابلية إعادة الإنتاج. ولا ندّعي الادعاء الأقوى بأن كل بناء نظيف متطابق بايتًا بايتًا على جميع الأجهزة المدعومة.

9.2 الـ Lints والتحليل الساكن

تُمكّن مساحة العمل أصرم مجموعات lint لدينا على مستوى deny. تُعامل CI كلّ تحذير — بما فيها تحذيرات روابط التوثيق — كفشل بناء. هذا متعمّد: نستخدم صرامة lint كسلك تعثّر للانحدارات الخفيّة.

9.3 بوّابات CI

يغطي سير عمل CI التنسيق والـ lints الصارمة؛ واختبارات Rust وWASM/المتصفح وWorker والتضمين وAPI؛ وفحص الأنواع؛ وتغطية الشيفرة؛ وفحوص الطفرة والثوابت؛ والتحليل الساكن للتبعيات وسير العمل؛ وفحوص مفاتيح i18n وتغطيتها وانجرافها ونقاط الشيفرة العدائية؛ وحداثة الوثائق المولدة وAPI وقاعدة المعرفة؛ وجرد المستندات والروابط الداخلية؛ وميزانيات أوراق الأنماط والحزمة؛ والتحقق من OpenAPI. وتُجدول بعض مهام الطفرة المكلفة بدل تشغيلها مع كل دفع.

تظل نتيجة ci الإجمالية المطلوبة حمراء إذا فشلت أي مهمة مطلوبة. وتستهلك حماية الفروع وسير عمل النشر تلك النتيجة بدل تكرار بوابة أمان أصغر.

9.4 اختبار الطفرة

يُشغّل عمل أسبوعي اختبار الطفرة ضدّ الوحدات النقيّة الحرجة أمنيًّا: التجزئة، CBOR القانوني، الخَتْم، الفتح، newtypes صيغة الإرسال، مُحقّقات أنواع البروتوكول، ومساحة أسماء handle. يُجيب اختبار الطفرة على "هل تلتقط مجموعة اختباراتنا شيفرة خاطئة بشكلٍ خفيّ؟" — إن تجاوز تطبيق مُتحوَّر كلّ الاختبارات، نعلم أنّ لدينا فجوة تغطية اختبار ونُعالجها.

9.5 Git Hooks

الـ hooks المحلّيّة (pre-commit، pre-push) تُحاكي بوّابات CI بحيث تُلتقَط الانحدارات قبل أن تغادر جهاز المطوّر. تُثبَّت الـ hooks عبر سكربت مستودع؛ لا تُتجاوز في سير عملنا وCI هي البوّابة الرسميّة إن تمّ تخطّيها.

10. الاختبار

تحمل الشيفرة الحرجة أمنيًّا ثلاثة أنواع من الاختبارات:

• اختبارات الوحدة تتحقّق من السلوك المتوقّع على مدخلات معروفة، بما فيها متّجهات اختبار مُشتقّة من مواصفات البروتوكول.
• اختبارات الخواصّ تُولّد آلاف المدخلات العشوائيّة وتُؤكّد الثوابت: رحلات ذهاب وإياب CBOR قانوني، رحلات ذهاب وإياب تحقّق التوقيع، مُسندات ربط البريد الإلكتروني، حتميّة الإقرار بالميثاق.
• اختبارات عبر التطبيقات تتحقّق من توافق تطبيقات العميل والخادم لدينا بايتًا بايتًا على الترميزات القانونيّة. هذا يلتقط التباعد بين التطبيقَين قبل وصوله إلى الإنتاج.

11. نظافة الفرع والإصدار

لا تتقدم فروع الميزات إلى staging إلا عبر طلب سحب Gate 1: نتيجة ci المطلوبة خضراء، ولا طلب تغيير غير محسوم، ولا تعارض دمج، وشجرة نظيفة مُراجعة؛ ثم يُدمج الطلب بالسحق ويُحذف الفرع. ولا يتقدم main إلا عبر طلب سحب Gate 2 من staging إلى main ويحافظ على النسب بدمج ذي التزام. ليست الدفعات المباشرة إلى الفروع سير عمل الإصدار.

تُشغَّل عمليات نشر المرحلي والإنتاج من حالتي فرعي staging وmain المحميين الموافقين بعد CI. ولا تتلقى شيفرة طلبات السحب أو بيانات اعتماد forks أسرار النشر.

الأسرار المُستخدَمة في سير عمل النشر محدودة النطاق ببيئة النشر بواسطة منصّة CI لدينا. غير متاحة لسير عمل pull-request من forks.

12. الإفصاح المُنسَّق

إن اعتقدتَ أنّك وجدتَ ثغرة أمنيّة في qub، نريد أن نسمع عنها بسرعة ونلتزم بمعالجة البلاغ بمهنيّة.

• راسل support@qub.social مع بادئة الموضوع [SECURITY].
• صف الثغرة، خطوات الإنتاج، وأيّ إثبات مفهوم.
• أعطنا نافذة إفصاح معقولة (عادةً 90 يومًا) قبل النشر علنًا.
• لا تصل إلى بيانات ليست لك، أو تُدهور الخدمة للمستخدمين الآخرين، أو تحتفظ بالبيانات المُحصَّلة خلال البحث بما يتجاوز ما يلزم لإظهار المشكلة.

نُقرّ بالاستلام خلال ثلاثة أيّام عمل ونُبقيك على اطّلاع أثناء تحقيقنا. بموافقتك، نُنسب الفضل للمُبلِغين في ملاحظات الإصدار.

12.1 الملاذ الآمن

إن اتّبع بحثك القواعد أعلاه (تحقيق بحسن نيّة، لا ضرر للمستخدمين الآخرين أو الخدمة، نافذة إفصاح معقولة)، لن نُلاحقك قضائيًّا، ولن نطلب من إنفاذ القانون ذلك. نُعامل عملك كاختبارٍ مُصرَّح به ونُفضّل أن تجد أنت الخلل لا شخصٌ آخر.

ينطبق الملاذ الآمن على:

• البحث على خدمة qub.social الحيّة (لا على تجهيزات اختبار ننشرها لذلك الغرض).
• الهندسة العكسيّة لثنائيّاتنا المنشورة وحزم qub-core / qub-app مفتوحة المصدر.
• أيّ فئة ثغرة — البروتوكول، التطبيق، البنية التحتيّة، سلسلة التوريد — تُؤثّر على qub.

لا ينطبق على الهندسة الاجتماعيّة لأعضاء فريق qub، أو اختبارات حجب الخدمة، أو الوصول إلى بيانات مستخدمين آخرين بما يتجاوز ما يلزم لإظهار المشكلة. إن كنتَ غير متأكّد ممّا إذا كان شيء يقع داخل الملاذ الآمن، اسأل أوّلًا باستخدام بادئة الموضوع [SECURITY] نفسها.

13. حدود صادقة

الأمان ممارسة، لا حالة. بعض الحدود تستحقّ التسمية مباشرةً:

• نحن فريق صغير. عمق مراجعتنا لا يطابق وظيفة أمان تطبيقات مُكرَّسة لشركة كبيرة. نُعوّض بقواعد آليّة صارمة وسطح هجوم بحدّ أدنى، لكنّنا لا ندّعي العصمة.
• ديمومة الواجهة الخلفيّة للتخزين الدائم باب باتّجاه واحد. إن سبّب خطأ صيرورة محتوى مختوم قابلًا لفكّ التشفير أبكر ممّا قُصد، لا نستطيع التراجع عنه. نُعامل تدفّق الخَتْم بعناية مُتناسبة.
• شبكة drand تبعيّة خارجيّة. فشل كارثي لـ drand سيُؤثّر على سلوك كشف كلّ qub. نُراقب صحّة drand ولدينا توثيق احتياطي لانتقال السلسلة إن لزم. لتواريخ الفتح بعد أكثر من سنتين، يُظهر نموذج تأكيد وقت الخَتْم إفصاحًا صريحًا: qubs الأفق الطويل تعتمد على ديمومة سلسلة drand، وقد يتطلّب انتقال سلسلة drand المستقبلي خطوات استرداد لفتح qub. لتواريخ الفتح بعد أكثر من 5 سنوات، يجب عليك تحديد مربّع إضافي يُؤكّد قراءتك وقبولك لهذه المخاطر قبل أن يستمرّ الخَتْم.
• البدائيّات التشفيريّة التي نعتمد عليها مُوحَّدة ومُراجَعة على نطاقٍ واسع، لكنّ التشفير يتطوّر. حيث لدينا خيارات (التوقيع ما بعد الكمومي، التشفير المُصادَق)، نختار الخيار الأكثر تحفّظًا.

14. التعديلات على هذه الصفحة

تُذكر التعديلات الجوهريّة بتحديث تاريخ السريان أعلى. حيث يعكس تغيير تحسينًا أمنيًّا ملموسًا، نصفه بإيجاز في سجلّ التغييرات العام. حيث يعكس تغيير توضيح سياسة، نصف ما تغيّر ولماذا.

للأسئلة عن أيّ شيء على هذه الصفحة، راسل support@qub.social مع بادئة الموضوع [SECURITY].

15. سجلّ التغييرات