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

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

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

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

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

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

للاطّلاع على مزيد من المعلومات عن الضوضاء وتأثيرها في بيانات التقارير، يُرجى الاطّلاع على مقالة فهم الضوضاء في التقارير التلخيصية.

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

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

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

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

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

قاعدة "عدم السماح بنسخ مكرّرة"

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

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

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

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

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

الدفعات غير المتّصلة

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

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

في المثالَين التاليَين لـ التقرير1 والتقرير2، تكون قيمة 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.

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

إذا تم تجميع التقرير 1 في مجموعة تمّت بنجاح سابقًا وتمت معالجة التقرير 2 في مجموعة لاحقة، ستتعذّر المجموعة التي تتضمّن التقرير 2 بسبب خطأ PRIVACY_BUDGET_EXHAUSTED. في حال حدوث ذلك، عليك إزالة التقارير التي تتضمّن المعرّف المشترَك والتي تم تجميعها بنجاح في دفعات سابقة وإعادة المحاولة. لمزيد من المعلومات عن هذا الخطأ، يُرجى الاطّلاع على رموز الخطأ والتدابير الوقائية لخدمة التجميع.

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

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

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

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

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

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

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

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