للحفاظ على خصوصية البيانات وأمانها، تستخدم "خدمة التجميع" إطار عمل يتيح الخصوصية التفاضلية (DP). تم تصميم الأدوات والآليات لتحديد مقدار المعلومات التي يكشف عنها مستخدم فردي والحدّ منها. دعنا نناقش بعضًا من إجراءات حماية الخصوصية هذه.
تمت إضافة بعض التشويش إلى تقارير الملخّص.
عندما تعمل تكنولوجيا الإعلان على تجميع التقارير القابلة للتجميع، تُنشئ "خدمة التجميع" تقريرًا موجزًا. يعد التقرير الملخص إجماليًا لجميع مساهمات جميع مفاتيح النطاق المحددة مسبقًا مع تفاوتات إحصائية إضافية.
لا تعتمد الشوائب المُضافة إلى التقارير على عدد التقارير المجمّعة أو قيم التقارير الفردية أو قيم التقارير المجمّعة.
يتم استخراج الضوضاء من إصدار منفصل من توزيع لابلاسي يتم توسيعه إلى ميزانية المساهمة (حساسية L1) التي يفرضها العميل استنادًا إلى واجهة برمجة التطبيقات للقياس المقابلة ومَعلمة الخصوصية epsilon. اطّلِع على مزيد من المعلومات عن الضوضاء.
حدود المساهمة
تختلف المساهمات التي تم تمريرها في المكالمة الواحدة حسب واجهات برمجة التطبيقات الخاصة بعميل القياس (Attribution Reporting API أو Privacy Aggregation API)، ويتم ربط عدد المساهمات التي تم تمريرها في المكالمة بحد معيّن مرتبط بالمساهمة من أجل التحكّم في حساسية تقرير الملخّص.
لفهم المزيد عن ميزانيات المساهمات لكل واجهة برمجة تطبيقات، يمكنك العثور عليها في الأقسام التالية من كل واجهة برمجة تطبيقات:
قاعدة "عدم السماح بنسخ مكرّرة"
تنص القاعدة على أنّ التقرير القابل للتجميع، الذي يتم تحديده بشكل فريد من خلال report_id، لا يمكن أن يظهر إلا مرة واحدة في دفعة واحدة. في حال ظهور تقرير مجمّع أكثر من مرة لكل دُفعة، سيتم تضمين التقرير الأول في التجميع وسيتم تجاهل التقارير اللاحقة التي تحتوي على report_id نفسها. ستكتمل الدفعة بنجاح.
تنص القاعدة أيضًا على أنّه لا يمكن أن يظهر التقرير نفسه في أكثر من دفعة واحدة. إذا سبق أن تم تجميع تقرير في مجموعة سابقة ناجحة، لا يمكن أن يكون التقرير نفسه في مجموعة لاحقة. ستنتهي المجموعة الأخيرة بتعذُّر إكمالها.
بدون هذه القواعد، يمكن للمهاجمين الحصول على إحصاءات عن محتوى دفعة معيّنة من خلال التلاعب بمحتوى الدفعات من خلال تضمين نُسخ مكرّرة من تقرير في دفعة واحدة أو دفعات متعدّدة.
تقدم خدمة التجميع مفهومًا آخر هو إحدى الدفعات المنفصلة. وهذا يعني أنّه يجب ألا تتضمّن مجموعتَان أو أكثر تقارير تتشارك رقم تعريف مشترَكًا.
رقم التعريف المشترك هو مجموعة من البيانات التي تم جمعها من الحقل shared_info في تقرير قابل للتجميع. يمكنك الاطّلاع على نموذج للحقل shared_info في ما يلي. يمكننا الاطّلاع على واجهة برمجة التطبيقات وversion وattribution_destination (لإعداد تقارير تحديد المصدر) وreporting_origin وscheduled_report_time وsource_registration_time (لإعداد تقارير تحديد المصدر). تساهم جميع هذه الحقول باستثناء report_id في رقم التعريف المشترك.
"shared_info": {
"API": "attribution-reporting",
"attribution_destination": "https://privacy-sandbox-demos-shop.dev",
"report_id": "5b052748-f5fb-4f14-b291-de03484ed59e",
"reporting_origin": "https://privacy-sandbox-demos-dsp.dev",
"scheduled_report_time": "1707786751",
"source_registration_time": "0",
"version": "0.1"
}
بما أنّ source_registration_time يتم اقتطاعه حسب اليوم وscheduled_report_time يتم اقتطاعه حسب الساعة، ستكون هناك تقارير ستشارك رقم التعريف المشترَك نفسه.
اطّلِع على كيفية مشاركة تقريرَين للمعرّف المشترَك نفسه. في ما يلي مثال على حقول "المعلومات المشتركة" من التقرير 1 والتقرير 2.
يتضمّن كلا التقريرَين واجهة برمجة التطبيقات نفسها والإصدار attribution_destination وreporting_origin وsource_registration_time. وبما أنّ report_id ليس جزءًا من المعرّف المشترَك، يمكننا تجاهل هذا الاختلاف. الاختلاف الوحيد الوحيد هو scheduled_report_time. عند النظر في هذه المسألة بمزيد من التفصيل، تبيّن أنّ scheduled_report_time لـ التقرير 1 هو February 19, 2024 9:08:10 PM وFebruary 19, 2024 9:55:10 PM لـ التقرير 2. بما أنّ scheduled_report_time يتم اقتطاعه إلى الساعة، يمكننا أن نرى أنّ كلا التقريرَين يتضمّنان February 19, 2024 9 PM كscheduled_report_time. ولأنّ جميع الحقول متطابقة، يمكننا التأكيد على أنّ كلا التقريرَين لهما رقم التعريف المشترك نفسه.
يمكنك مراقبة scheduled_report_time.
| Report1: المعلومات المشتركة | المعلومات التي تمت مشاركتها في Report2 |
|---|---|
| "shared_info": { | "shared_info": { |
| "واجهة برمجة التطبيقات": "attribution-reporting"، | "واجهة برمجة التطبيقات": "attribution-reporting"، |
| "attribution_destination": "https://shop.dev", | "attribution_destination": "https://shop.dev", |
| "report_id": "5b052748-...", | "report_id": "1a1b25aa-...", |
| "reporting_origin": "https://dsp.dev", | "reporting_origin": "https://dsp.dev", |
| "scheduled_report_time": "1708376890", | "scheduled_report_time": "1708379710", |
| "source_registration_time": "0", | "source_registration_time": "0", |
| "version": "0.1" | "version": "0.1" |
| } | } |
بعد تأكيد أنّ كلا التقريرَين يتضمّنان رقم التعريف المشترَك نفسه، يجب تضمين كلا التقريرَين في الحزمة نفسها.
في حال تجميع التقرير1 في مجموعة تم إكمالها بنجاح سابقًا ومعالجة التقرير2 في مجموعة لاحقة، ستتعذّر إكمال المجموعة التي تتضمّن التقرير2 بسبب خطأ PRIVACY_BUDGET_EXHAUSTED. وفي حال حدوث ذلك، يُرجى إزالة التقارير التي تحتوي على رقم تعريف مشترك والتي تم تجميعها بنجاح على دفعات سابقة وإعادة المحاولة.
يمكنك الانتقال إلى دليل استراتيجية تجميع الطلبات للاطّلاع على مزيد من المعلومات عن تجميع البيانات.
الإعلان مسبقًا عن مفاتيح التجميع
عند إرسال دفعة إلى "خدمة التجميع"، يجب تضمين كلّ من التقارير القابلة للتجميع التي يتمّ تلقّيها من مصدر إعداد التقارير وملف نطاق الإخراج. يحتوي نطاق الإخراج على المفاتيح أو الحِزم التي سيتم استرجاعها من التقارير القابلة للتجميع.
من وجهة نظر الخصوصية، ستتم إضافة تشويش إلى جميع المفاتيح التي تمّ الإعلان عنها مسبقًا في نطاق الإخراج، حتى إذا لم يتطابق أيّ تقرير حقيقي مع مفتاح معيّن. يوفر تحديد نطاق الإخراج الحماية من الهجوم حيث يكشف وجود مفتاح في المخرجات عن شيء ما حول مستخدم أو حدث واحد. على سبيل المثال، إذا عرضت حملة لمستخدم واحد فقط، سيكشف تلقّي مفتاح في النتائج (حتى مع وجود تشويش) أنّ هذا المستخدِم أجرى إحالة ناجحة في وقت لاحق. من خلال تحديد هذا النطاق مسبقًا، يمكننا التأكد من أنه لا يكشف أي شيء عن مساهمات المستخدمين.
المفاتيح أو الحِزم هي مفاتيح بسعة 128 بت تُعلن عنها تكنولوجيا الإعلان في Attribution Reporting API أو Private Aggregation API. ويمكن لتكنولوجيا الإعلان استخدام هذه المفاتيح لتشفير السمات التي تريد تتبُّعها.
سيتم فقط النظر في ما إذا كان سيتم تجميع المفاتيح المعلَن عنها مسبقًا في تقرير الملخّص. ستتضمّن القيم المجمّعة للحِزم في تقرير الملخّص تفاوتًا إحصائيًا، ما سيظهر في تقرير الملخّص الذي تم إنشاؤه.
في الأساس، إذا تم تضمين مفتاح تجميع في ملف نطاق الإخراج، ولكن لم يتم العثور عليه في أي تقرير دفعة، حتى إذا كانت القيمة المجمّعة هي صفر، من المرجّح أن يكون التقرير التلخيصي النهائي غير صفري بسبب التشويش المُضاف للحفاظ على الخصوصية.
تجدر الإشارة إلى أنّه تم أخذ ميزة تُعرف باسم key-Discover في الاعتبار في وقت كتابة هذا النموذج. سيسمح اكتشاف المفاتيح لتكنولوجيا الإعلان بمعالجة الملفات القابلة للتجميع بدون الحاجة إلى مفاتيح مُعلَن عنها مسبقًا، ولكن للحفاظ على الخصوصية في السيناريو المذكور سابقًا، سيتم تنفيذ خطوة حدّ إضافية.