💻 computer science

Privacy in Theory, Bugs in Practice: Grey-Box Auditing of Differential Privacy Libraries

تقدم هذه الورقة Re:cord-play، وهو إطار عمل للتدقيق بنظام الصندوق الرمادي (gray-box) يقوم بفحص الحالة الداخلية لخوارزميات الخصوصية التفاضلية للكشف عن انتهاكات الخصوصية وتزييفها، حيث نجح في كشف 13 خطأً في 12 مكتبة مفتوحة المصدر تخل بضماناتها النظرية.

المؤلفون الأصليون: Tudor Cebere, David Erb, Damien Desfontaines, Aurélien Bellet, Jack Fitzsimons

نُشر 2026-02-20

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Tudor Cebere, David Erb, Damien Desfontaines, Aurélien Bellet, Jack Fitzsimons

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

إليك شرح لورقة البحث بعنوان "الخصوصية في النظرية، والأخطاء في الممارسة: التدقيق الرمادي للصناديق في مكتبات الخصوصية التفاضلية" باستخدام لغة بسيطة وتشبيهات إبداعية.

الصورة الكبيرة: "الوصفة المثالية" مقابل "المطبخ الفوضوي"

تخيل أن الخصوصية التفاضلية (Differential Privacy) هي وصفة مثالية ومثبتة رياضياً لصنع كعكة لذيذة الطعم (بيانات مفيدة) ولكنها لا تحتوي على أي مكونات سرية من أي شخص بمفرده (خصوصية).

النظرية: يقول كتاب الوصفات: "إذا اتبعت هذه الخطوات بدقة، ستكون الكعكة آمنة بنسبة 100%".
الواقع: عندما يحاول المطورون خبز هذه الكعكة في مطبخ حقيقي (كود البرمجيات)، فإنهم غالباً ما يرتكبون أخطاء. قد ينسون قياس السكر بشكل صحيح، أو يستخدمون درجة حرارة فرن خاطئة، أو يتركون مكوناً سرياً مرئياً على الطاولة عن طريق الخطأ.

تجادل هذه الورقة بأنه بينما تكون الوصفة (الرياضيات) مثالية، فإن الخبازين (مكتبات البرمجيات) يرتكبون أخطاءً دقيقة تفسد الخصوصية. لقد بنى المؤلفون أداة جديدة تسمى Re:cord-play لتعمل كـ "محقق خصوصية" يمكنه الدخول إلى المطبخ، ومراقبة الخباز، وتحديد مكان الخطأ بالضبط.

المشكلة: لماذا تفشل عمليات التحقق الحالية؟

قبل هذه الورقة، كانت هناك طريقتان للتحقق مما إذا كانت كعكة الخصوصية آمنة:

"اختبار التذوق" للصندوق الأسود: تخبز الكعكة، وتعطيها لقاضٍ معصوب العينين، وتسأله: "هل يمكنك معرفة ما إذا كانت هذه الكعكة مصنوعة ببيض 'أليس' أم ببيض 'بوب'؟"
- العيب: هذا أمر صعب للغاية. إذا كانت الكعكة معقدة، سيحتاج القاضي لتذوق آلاف الكعكات ليتأكد. وحتى لو قال القاضي: "هذه الكعكة غير آمنة!"، فإنه لا يستطيع إخبارك لماذا. هل كان السبب البيض؟ أم الدقيق؟ أم الفرن؟ إنها عملية بطيئة وغامضة جداً لمطوري البرمجيات.
"فحص الإثبات الرسمي": توظف عالم رياضيات لقراءة الوصفة وإثبات صحتها على الورق.
- العيب: هذا مكلف وصارم للغاية. يتطلب الأمر إعادة كتابة المطبخ بالكامل بلغة خاصة لا يتحدثها إلا علماء الرياضيات. معظم البرمجيات في العالم الحقيقي مكتوبة بلغات شائعة مثل Python، لذا فهذا لا يعمل بشكل جيد.

الحل: المحقق "Re:cord-Play"

قدم المؤلفون نهج "الصندوق الرمادي" (Grey-Box). تخيل محققاً يمكنه رؤية تخطيط المطبخ (هيكل الكود) ولكنه لا يحتاج لتذوق كل لقمة. إنهم يستخدمون خدعة ذكية تسمى "التسجيل وإعادة التشغيل" (Record and Replay).

التشبيه: خدعة "المخرجات المجمدة"

تخيل أنك تخبز كعكتين جنباً إلى جنب:

الكعكة (أ): تستخدم مكونات من أليس.
الكعكة (ب): تستخدم مكونات من بوب (الذي يشبه أليس تماماً، باستثناء بيضة واحدة فقط).

في نظام خصوصية مثالي، يجب أن يكون الفرق الوحيد بين الكعكة (أ) والكعكة (ب) هو "الضجيج" (noise) الذي تمت إضافته بواسطة "آلية الخصوصية" (خلاط المكونات السرية). بقية العملية (الخلط، وقت الخبز، حجم القالب) يجب أن تكون متطابقة تماماً.

تعمل أداة Re:cord-play كالتالي:

المرحلة الأولى: التسجيل (التشغيل الأول)
يراقب المحقق الخباز وهو يصنع الكعكة (أ). يسجل كل خطوة: "ضع كوبين من الدقيق"، "شغل الفرن على 350"، "أضف الضجيج". والأهم من ذلك، يقوم بـ تجميد مخرج "خلاط الضجيج". لنقل مثلاً أن الخلاط أضاف بالضبط +5.2 إلى الخليط. يسجل المحقق هذا الرقم.
المرحلة الثانية: إعادة التشغيل (التشغيل الثاني)
يراقب المحقق الخباز وهو يصنع الكعكة (ب) (ببيضة بوب). ولكن هذه المرة لديهم لوحة تحكم سحرية. عندما يصل الخباز إلى "خلاط الضجيج"، يقوم المحقق بـ إجبار الآلة على إخراج نفس الرقم تماماً (+5.2) كما في المرة السابقة، بغض النظر عما تريد الآلة فعله.
التحقق:
الآن، يقارن المحقق بين الكعكتين.
- إذا كان الخباز أميناً: يجب أن يكون الفرق الوحيد بين الكعكتين هو البيضة الواحدة. وبما أن الضجيج تم فرضه ليكون متطابقاً، فإن بقية العملية (الخلط، التوقيت، إلخ) يجب أن تكون متطابقة.
- إذا كان الخباز لديه خطأ برمي (Buggy): سيرى المحقق أن الخباز قام بتغيير درجة حرارة الفرن أو سرعة الخلط لمجرد أنه استخدم بيضة بوب بدلاً من أليس.
- الحكم: "مهلاً! لقد غيرت درجة حرارة الفرن بناءً على البيضة! هذا تسريب للخصوصية! الكود ينظر إلى البيانات الخاصة عندما لا ينبغي له ذلك."

ماذا وجدوا؟

استخدم المؤلفون أداة المحقق هذه لتدقيق 12 مكتبة خصوصية شهيرة (مثل SmartNoise و Opacus و Diffprivlib). ووجدوا 13 خطأً برمجياً رئيسياً كان من شأنها أن تسمح بتسريب البيانات الخاصة.

إليك بعض الأمثلة على هذه "الأخطاء" مترجمة إلى تشبيه المطبخ الخاص بنا:

"كوب القياس الخاطئ" (سوء معايرة الحساسية): الوصفة تقول: "أضف كوباً واحداً من الضجيج". لكن الخباز كان يستخدم في الواقع كوب قياس بسعة كوبين لأنه نسي حساب خطوة حيث تضاعفت المكونات. كانت الكعكة أقل خصوصية مما هو موعود به.
"الملاحظة السرية" (انتهاك الثوابت): كتب الخباز ملاحظة على الطاولة: "إذا كانت البيضة من بوب، ارفع درجة حرارة الفرن إلى 400". كانت هذه الملاحظة مرئية للجميع. حتى لو كانت الكعكة بنفس الطعم، فإن الفعل المتمثل في رفع درجة الحرارة كشف هوية صاحب البيضة.

"الرياضيات المعطلة" (أخطاء المحاسبة): احتفظ الخباز بسجل يقول: "لقد صرفت دولاراً واحداً من الخصوصية". ولكن في الواقع، صرف 5 دولارات لأنه نسي إضافة رسوم ضريبية. ظن النظام أنه آمن، لكنه كان في الواقع مفلساً.

لماذا هذا مهم؟

هذه الورقة هي بمثابة جرس إنذار. فهي تظهر أن الرياضيات وحدها لا تكفي. يمكنك امتلاك أجمل وأكمل نظرية خصوصية، ولكن إذا كان الكود الذي ينفذها يحتوي على خطأ مطبعي أو خطأ منطقي، فإن الخصوصية ستضيع.

لقلّد المؤلفون أداتهم كـ برمجيات مفتوحة المصدر. وهذا يعني أن أي مطور يمكنه الآن دمج "محقق الخصوصية" هذا في مسار اختبار البرمجيات الخاص به (مثل مصحح الأخطاء الإملائية للخصوصية). بدلاً من انتظار هكر لاكتشاف التسريب، يمكن للمطورين الإمساك بهذه الأخطاء قبل إصدار برامجهم.

الملخص

المشكلة: برمجيات الخصوصية مليئة بالأخطاء الدقيقة التي تكسر القواعد الرياضية.
الطريقة القديمة: بطيئة جداً (اختبار التذوق) أو صعبة للغاية (الإثباتات الرياضية).
الطريقة الجديدة (Re:cord-play): أداة "تسجيل وإعادة تشغيل" تجبر البرنامج على التصرف بشكل متطابق على مجموعتين مختلفتين قلي-تساً من البيانات. إذا تصرف البرنامج بشكل مختلف، فهو يسرب الأسرار.
النتيجة: وجدوا أخطاءً حقيقية في مكتبات برمجية كبرى، وقدموا للعالم أداة مجانية لمنع هذه الأخطاء في المستقبل.

باختيرة: لقد صنعوا طريقة لـ "تصحيح أخطاء" (Debug) الخصوصية، لضمان أن البرمجيات تفعل حقاً ما تعد به الرياضيات.

إليك ملخص تقني مفصل لورقة البحث "الخصوصية في النظرية، الأخطاء في الممارسة: التدقيق الرمادي للصناديق (Grey-Box Auditing) لمكتبات الخصوصية التفاضلية" من قبل Cebere وآخرون.

1. بيان المشكلة

تعد الخصوصية التفاضلية (DP) المعيار الفعلي لتحليل البيانات الخاصة، حيث توفر ضمانات رياضية صارمة. ومع ذلك، هناك فجوة كبيرة بين الضمانات النظرية والتطبيقات العملية.

المشكلة: من المعروف أن تطبيقات الخصوصية التفاضلية عرضة للأخطاء الدقيقة (مثل الحسابات الخاطئة للحساسية، أو التحكم في التدفق المعتمد على البيانات، أو سوء معايرة الضجيج، أو التركيب المعيب)، مما يبطل ضمانات الخصوصية النظرية.
محدودية الطرق الحالية:
- التحقق الرسمي (Formal Verification): مقيد للغاية؛ يتطلب إعادة كتابة الكود باستخدام لغات متخصصة (DSLs)، مما يخلق حاجزاً عالياً أمام مكتبات Python/C++ الحالية.
- التدقيق بنظام الصندوق الأسود (Black-Box Auditing): يعتمد على التحليل التوزيعي الإحصائي (هجمات استنتاج العضوية). ورغم قوته، إلا أنه غير قابل للتطبيق حسابياً للمسارات المعقدة، ويتطلب أحجام عينات ضخمة، ويفشل في تحديد المصدر المحدد للخطأ (على سبيل المثال، ما إذا كان الخطأ في المعالجة المسبقة، أو حساب الحساسية، أو المعالجة اللاحقة).

2. المنهجية: نهج "الصندوق الرمادي" (Grey-Box)

يقترح المؤلفون نموذجاً جديداً للتدقيق يسمى Re:cord-play، والذي يقع في منطقة وسطى بين نهجي الصندوق الأسود والصندوق الأبيض. يفترض هذا النهج إمكانية الوصول إلى تدفق التحكم (control flow) والمتغيرات الوسيطة للخوارزمية، لكنه يعامل المنطق الداخلي لعمليات الخصوصية الأولية (مثل آلية Laplace) كصنادي_ك_سوداء.

يعمل الإطار بناءً على رؤيتين أساسيتين:

التفكيك الهيكلي: تقوم خوارزميات الخصوصية التفاضلية بدمج العمليات المعتمدة على البيانات مع المنطق غير المعتمد على البيانات (التدفق، المعالجة المسبقة/اللاحقة). في التنفيذ الصحيح، يجب أن يظل المنطق غير المعتمد على البيانات ثابتاً عند تغير مجموعة البيانات (من $D$ إلى جارتها $D'$ )، بشرط تجميد مخرجات عمليات الخصوصية الأولية.
التحقق الحتمي: من خلال تجميد مخرجات عمليات الخصوصية الأولية أثناء التنفيذ على مجموعة بيانات مجاورة، فإن أي تباين في حالة البرنامج (التدفق أو المتغيرات الوسيطة) يشير إلى تسريب للخصوصية.

المكونات الأساسية

يتكون الإطار من أداتين رئيسيتين:

أ. Re:cord-play (التحقق الحتمي)
تقوم هذه الأداة بإجراء تحليل "التسجيل وإعادة التشغيل" (Record and Replay) لاكتشاف أخطاء المنطق دون الحاجة لأخذ عينات إحصائية.

المرحلة الأولى (التسجيل - Record): يتم تشغيل الخوارزمية المزودة بأدوات مراقبة على مجموعة البيانات $D$ . يقوم "خطاف" (hook) باعتراض استدعاءات عمليات الخصوصية الأولية، وتسجيل نوع الآلية، والمعلمات، والبيانات المدخلة، وحالة مولد الأرقام العشوائية (PRNG)، والمخرجات. كما يسجل عمليات "التحقق من التساوي" (ensure_equality) للمتغيرات التي يجب أن تكون مستقلة عن البيانات.
المرحلة الثانية (إعادة التشغيل - Replay): يتم تشغيل الخوارزمية على مجموعة بيانات مجاورة $D'$ $D^{'}$ .
- فحص تدفق التحكم: يتحقق الخطاف من أن تسلسل الاستدعاءات يطابق الأثر المسجل. أي عدم تطابق يشير إلى وجود تدفق تحكم معتمد على البيانات.
- فحص الثبات: بالنسبة لعقد ensure_equality ، يتحقق الخطاف من أن المدخلات تظل متطابقة.
- المخرج المجمد: يقوم الخطاف بفرض عودة عمليات الخصوصية الأولية إلى نفس المخرج تماماً الذي تم تسجيله في المرحلة الأولى (مع استعادة حالة الـ PRNG لضمان الحتمية).
- فحص الحساسية: يقارن الإطار بين المسافة التجريبية بين المدخلات ( $q_D$ و $q_{D'}$ ) مقابل الحساسية المعلنة. إذا تجاوزت المسافة الحساسية المعلنة، يتم رصد مخالفة.

ب. Re:cord-play-sample (التدقيق الإحصائي)
يتعامل هذا الامتداد مع السيناريوهات التي تكون فيها عمليات الخصوصية الأولية نفسها غير موثوقة أو مصممة بشكل مخصص.

العزل: باستخدام الآثار الناتجة عن Re:cord-play، يعزل الإطار عمليات الخصوصية الأولية ومدخلاتها الحساسة المحددة.
الاختبار الإحصائي: بدلاً من تدقيق المسار بأكمله، يقوم بإجراء تدقيق إحصائي بنظام الصندوق الأسود على كل عملية أولية $N$ من المرات لتوليد توزيعات المخرجات التجريبية.
تركيب PLD: يقوم بتقدير توزيع فقدان الخصوصية (PLD) لكل عملية أولية، وتركيبها عددياً لاستخلاص حد $(\varepsilon, \delta)$ النهائي. يسمح هذا بتدقيق المسارات المعقدة عبر اختبار المكونات بشكل فردي، مما يقلل التكلفة الحسابية بشكل كبير.

3. المساهمات الرئيسية

نموذج تدقيق مبتكر: تقديم نهج "الصندوق الرمادي" الذي يستفيد من فحص الحالة الداخلية لاكتشاف الأخطاء بشكل حتمي، متجنباً التعقيد الإحصائي لطرق الصندوق الأسود.
الأدوات (Re:cord-play & Re:cord-play-sample):
- مكتبة Python تتكامل مع pytest لضمان التكامل السلس مع عمليات التطوير المستمر (CI/CD).
- قادرة على اكتشاف أربع فئات محددة من الأخطاء: (1) التسريب المعتمد على البيانات إلى الكود العام، (2) حسابات الحساسية الخاطئة، (3) سوء معايرة الضجيج، و(4) تنفيذ العمليات الأولية المعيب.
الإصدار مفتوح المصدر: تم إصدار الإطار كحزمة مفتوحة المصدر، مما يقلل الحواجز أمام المطورين لدمج اختبارات الخصوصية في دورة حياة تطوير البرمجيات.

4. النتائج: التقييم التجريبي

قام المؤلفون بتدقيق 12 مكتبة مفتوحة المصدر للخصوصية التفاضلية (بما في ذلك SmartNoise SDK، وOpacus، وDiffprivlib، وSynthcity، وMOSTLY AI) وكشفوا عن 13 انتهاكاً متميزاً للخصوصية.

نتائج بارزة:

SmartNoise SDK: وجد خطأ في معايرة الحساسية حيث استخدم حساب التباين (covariance) بيانات غير معالجة (غير مقصورة) رغم أن الحساسلة المعلنة تعتمد على بيانات مقصورة.
SmartNoise SQL: رصد نقصاً في عامل $\log(1/\delta)$ في عداد الخصوصية (privacy odometer)، مما جعل المحاسب يعود إلى حدود محافظة ويفشل في تطبيق التركيب المتقدم بشكل صحيح.
Synthcity (Privayes):
- انتهاك الثبات: استخدم مخرجات "آلية الأس" (Exponential Mechanism) لفهرسة قائمة خاصة، مما أدى لتسريب المعلومات عبر تدفق التحكم.
- سوء معايرة الضجيج: حالة "القسمة على صفر" أدت إلى تعطيل إضافة الضجيج تماماً تحت إعدادات معينة.
Diffprivlib:
- وجد خطأ في حساب الحساسية في الانحدار الخطي (Linear Regression) حيث تم استخدام الحد الأدنى فقط لحساب الحساسية.
- رصد انتهاكاً للثبات في الانحدار اللوجستي (Logistic Regression) حيث تغيرت مجموعة الملصقات المستنتجة بناءً على وجود عينة واحدة (تسريب لوجود الملصق).
Opacus: حدد خطأً حيث استُخدم حجم مجموعة البيانات (وهو كمية خاصة بموجب تعريف الجوار إضافة/حذف) لحساب عوامل التطبيع، مما سرب حجم مجموعة البيانات.
MOSTLY AI: وجد ازدواجية في حساب ميزانيات الخصوصية وتفرعاً في التحكم يعتمد على البيانات بناءً على إحصائيات غير خاصة.
المدخلات المرضية (Pathological Inputs): فشلت العديد من المكتبات في التعامل مع قيم $\pm \infty$ أو NaN بشكل صحيح، مما أدى إلى سلوك غير محدد أو تسريب للمعلومات.

الكفاءة: الإطار خفيف حسابياً، ومناسب للتنفيذ المتكرر في مسارات CI/CD، على عكس التدقيق بنظام الصندوق الأسود الذي يتطلب موارد حسابية هائلة.

5. الأهمية والأثر

سد الفجوة: تثبت الورقة أن الصحة النظرية لا تضمن الخصوصية العملية. فهي توفر "مصحح أخطاء خصوصية" عملي لاكتشاف أخطاء التنفيذ التي تغفل عنها البراهين الرسمية.
تغذية راجعة قابلة للتنفيذ: على عكس عمليات تدقيق الصندوق الأسود التي تخبرك فقط بأن "الخصوصية قد انتهكت"، تحدد هذه الأداة أين و لماذا (مثلاً: "تجاوزت الحساسية في الخطوة X" أو "تغير تدفق التحكم في الخطوة Y").
التبني الصناعي: من خلال التكامل مع أطر الاختبار القياسية (pytest)، يشجع المؤلفون على اعتماد اختبار الخصوصية كجزء قياسي من دورة حياة تطوير البرمجيات، مما ينقل ضمان الخصوصية من نشاط بحثي لاحق إلى ممارسة هندسية روتينية.
التوصيات: يدعو المؤلفون إلى استخدام لغات متخصصة (DSLs) مختبرة (مثل OpenDP)، والترميز الصريح لتعريفات الجوار، والعزل الهيكلي بين الكود المعتمد على البيانات والكود غير المعتمد على البيانات لمنع هذه الفئات من الأخطاء.

في الختام، يمثل Re:cord-play تقدماً كبيراً في هندسة الخصوصية، حيث يقدم طريقة قابلة للتوسع والتحقق والآلية للتحقق من تنفيذ أنظمة الخصوصية التفاضلية.