إجراءات حماية الخصوصية للتقارير القابلة للتجميع

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

يناقش هذا الدليل الأدوات والاستراتيجيات اللازمة لإنشاء تقارير قابلة للتجميع تساعد في الحفاظ على أمان البيانات الخاصة بالمستخدمين الفرديين:

التقارير الموجزة التي تتضمّن ضوضاء مضافة

عند تجميع التقارير القابلة للتجميع، تنشئ "خدمة تجميع البيانات" تقريرًا موجزًا. تقرير الملخّص هذا هو عبارة عن تجميع لكل المساهمات من جميع مفاتيح النطاق المحدّدة مسبقًا، مع إضافة تشويش إحصائي.

لا يعتمد التشويش المُضاف إلى التقارير على عدد التقارير المجمَّعة أو قيم التقارير الفردية أو قيم التقارير المجمَّعة. يتم استخلاص الضوضاء من نسخة منفصلة من توزيع لابلاس، ويتم قياسها وفقًا لميزانية المساهمة (L1 الحساسية) التي يفرضها العميل استنادًا إلى واجهة برمجة التطبيقات المقابلة للقياس ومعلَمة الخصوصية epsilon.

لمزيد من المعلومات حول التشويش وتأثيراته في بيانات التقارير، اطّلِع على فهم التشويش في التقارير الموجزة.

ميزانية المساهمة

للتحكّم في حساسية تقرير الملخّص، يرتبط عدد المساهمات التي يتم إدخالها في طلب بحدّ أقصى معيّن للمساهمة، يُعرف أيضًا باسم ميزانية المساهمة. يختلف حدّ المساهمة استنادًا إلى ما إذا كنت تستخدم Attribution Reporting API أو Private Aggregation API.

لمزيد من المعلومات عن كيفية ضبط ميزانيات المساهمة لكل واجهة برمجة تطبيقات، يُرجى الاطّلاع على أقسام مستندات واجهة برمجة التطبيقات التالية:

استراتيجيات تجميع التقارير

عند تجميع التقارير القابلة للتجميع على شكل دفعات، من المهم تحسين استراتيجيات التجميع على شكل دفعات لكي لا يتم تجاوز حدود الخصوصية. هناك مفهومان مهمّان لتجميع التقارير بشكل صحيح، وهما قاعدة"عدم التكرار" وفكرة المجموعات المنفصلة.

قاعدة "عدم التكرار"

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

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

لا يمكن استخدام التقرير نفسه إلا مرة واحدة لكل مجموعة.
الشكل 1. إذا ظهر تقرير أكثر من مرة في مجموعة، يشمل التجميع المثال الأول ويتجاهل التقارير اللاحقة التي تحمل رقم التعريف نفسه.

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

لمزيد من المعلومات عن فرض قاعدة "عدم التكرار" ضمن مجموعة من التقارير أو على مستوى مجموعات متعددة، يُرجى الاطّلاع على التقارير المكرّرة ضمن المجموعات.

المجموعات غير المتجاورة

لتجنُّب الحالات التي يحدث فيها تداخل بين الدفعات، تفرض "خدمة التجميع" دفعات غير متداخلة. وهذا يعني أنّه لا يمكن أن تحتوي مجموعتان أو أكثر على تقارير تتضمّن معرّفًا مشتركًا. المعرّف المشترك هو مزيج من البيانات التي يتم جمعها من الحقل shared_info في تقرير قابل للتجميع، بالإضافة إلى معرّف الفلترة من طلب الوظيفة. في حال عدم تحديد رقم تعريف الفلترة، يتم استخدام القيمة التلقائية 0.

في مثال حقل shared_info التالي، يمكنك الاطّلاع على واجهة برمجة التطبيقات attribution_destination (لـ Attribution Reporting) وreporting_origin وscheduled_report_time وsource_registration_time (لـ Attribution Reporting) وversion. تساهم هذه الحقول، باستثناء 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 ليس جزءًا من المعرّف المشترَك، يمكنك تجاهل هذا الاختلاف.

في الأمثلة التالية Report1 وReport2، تكون قيمة scheduled_report_time هي نفسها.

المعلومات المشترَكة في Report1:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

المعلومات المشترَكة في Report2:

"shared_info": {
  "API": "attribution-reporting",
  "attribution_destination": "https://shop.dev",
  "report_id": "5b052748-...",
  "reporting_origin": "https://dsp.dev",
  "scheduled_report_time": "1708376890",
  "source_registration_time": "0",
  "version": "0.1"
}

أوقات التقارير المجدوَلة هي "19 فبراير 2024 الساعة 9:08:10 مساءً" للتقرير 1 و "19 فبراير 2024 الساعة 9:55:10 مساءً" للتقرير 2. بما أنّه يتم اقتطاع قيمة الحقل scheduled_report_time إلى الساعة، يتضمّن كلا التقريرَين 1708376890 (القيمة المشفرة للتاريخ "19 فبراير 2024 الساعة 9 مساءً") كقيمة للحقل scheduled_report_time.

مع تطابق جميع الحقول الأخرى ورقم تعريف الفلترة، يتضمّن كلا التقريرَين رقم التعريف المشترك نفسه. وبما أنّ كلا التقريرَين يتضمّنان المعرّف المشترك نفسه، يجب تضمينهما في الدفعة نفسها.

إذا تم تجميع Report1 في مجموعة ناجحة سابقًا وتمت معالجة Report2 في مجموعة لاحقة، ستتعذّر المجموعة التي تتضمّن Report2 بسبب الخطأ PRIVACY_BUDGET_EXHAUSTED. في حال حدوث ذلك، أزِل التقارير التي تتضمّن المعرّف المشترك الذي تم تجميعها بنجاح في عمليات التجميع السابقة، ثم أعِد المحاولة. لمزيد من المعلومات حول هذا الخطأ، يُرجى الاطّلاع على رموز الخطأ وإجراءات التخفيف من تأثيرها في "خدمة التجميع".

يجب تضمين التقارير التي تتضمّن معرّفًا مشتركًا في الدفعة نفسها.
الشكل 2. تحتوي المجموعة 2 على تقرير يتضمّن رقم تعريف مشتركًا مع تقرير في المجموعة 1، لذا يتعذّر إرسال المجموعة 2.

مفاتيح التجميع المُعلَن عنها مسبقًا

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

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

يمكنك الإفصاح عن هذه المفاتيح المكوّنة من 128 بت في Attribution Reporting API أو Private Aggregation API واستخدامها لترميز السمات التي تريد تتبُّعها.

لا يتم أخذ سوى المفاتيح التي تم الإعلان عنها مسبقًا في الاعتبار عند التجميع وإدراجها في التقرير الموجز. تتم إضافة تشويش إحصائي إلى القيم المجمّعة للحِزم في التقرير الموجز، ويظهر ذلك في التقرير الموجز الذي تم إنشاؤه.

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

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