הגנות על פרטיות בדוחות שאפשר לצבור

שירות הצבירה יוצר דוחות סיכום של נתוני המרות מפורטים ומדידות של פוטנציאל החשיפה מדוחות גולמיים שניתן לצבור. כדי לשמור על פרטיות ואבטחה של נתוני המשתמשים, שירות הצבירה משתמש במסגרת שתומכת בפרטיות דיפרנציאלית (DP) כדי למדוד ולהגביל את כמות המידע שמוצג בדוחות האלה לגבי משתמשים ספציפיים.

במדריך הזה נסביר על כלים ואסטרטגיות ליצירת דוחות שאפשר לצבור, שיעזרו לשמור על אבטחת הנתונים של משתמשים ספציפיים:

• יצירת דוחות סיכום עם רעש נוסף
• הגדרת תקציב תרומות
• אסטרטגיות לצבירה של דוחות
  • טיפול בדוחות כפולים בקבוצות
  • טיפול בדוחות עם מזהה משותף
• שימוש במפתחות צבירת נתונים שהוגדרו מראש

דוחות סיכום עם רעשי רקע

כשמקבצים דוחות שאפשר לצבור, שירות הצבירה יוצר דוח סיכום. דוח הסיכום הזה הוא צביר של כל התרומות של כל מפתחות הדומיין שהוגדרו מראש, עם רעש סטטיסטי נוסף.

הרעש שנוסף לדוחות לא תלוי במספר הדוחות שנצברו, בערכי דוחות ספציפיים או בערכי דוחות מצטברים. הרעשים נשלפים מגרסה דיסקרטית של התפלגות Laplace, והם מותאמים לתקציב התרומה (רגישות L1) שהלקוח אוכף בהתאם ל-Measurement API המתאים ולפרמטר הפרטיות epsilon.

מידע נוסף על רעש וההשלכות שלו על נתוני הדוחות זמין במאמר הסבר על רעש בדוחות סיכום.

תקציב התרומה

כדי לשלוט ברמת הרגישות של דוח סיכום, מספר התרומות שמועברות בקריאה מקושר למגבלה ספציפית של הגבלת תרומות, שנקראת גם תקציב התרומות. תקציב התרומה משתנה בהתאם לשימוש שלכם ב-Attribution Reporting API או ב-Private Aggregation API.

מידע נוסף על הגדרת תקציבי תרומות לכל ממשק API זמין בקטעים הבאים במסמכי העזרה של ממשקי ה-API:

• הגדרת תקציב ומגבלות על תרומות ב-Attribution Reporting API
• מגבלות על תרומות ל-Private Aggregation API
• הגדרת תקציב ומגבלות על התרומות ב-Private Aggregation API

אסטרטגיות לצבירה של דוחות

כשמקבצים דוחות שאפשר לצבור, חשוב לבצע אופטימיזציה של אסטרטגיות הקיבוץ כדי שלא לחרוג מהמגבלות שקשורות לפרטיות. שני מושגים חשובים ליצירת קבוצות של דוחות בצורה נכונה הם הכלל 'ללא כפילויות' והרעיון של קבוצות נפרדות.

הכלל 'ללא כפילויות'

Aggregation Service אוכף את הכלל 'ללא כפילויות'. הכלל הזה קובע שדוח שניתן לצבור, שמזוהה באופן ייחודי באמצעות report_id, יכול להופיע רק פעם אחת בקבוצה אחת. אם דוח שניתן לצבירה מופיע יותר מפעם אחת בכל אצווה, הדוח הראשון נכלל בצבירה, דוחות הבאים עם אותו report_id יימחקו והאצווה תושלם בהצלחה.

הכלל קובע גם שאותו מזהה משותף לא יכול להופיע ביותר מקבוצה אחת. אם מזהה משותף כבר נכלל בקבוצה קודמת שהעברתם בהצלחה, קבוצה מאוחרת יותר שכוללת גם את אותו מזהה משותף תיכשל.

איור 1. אם דוח מופיע יותר מפעם אחת בקבוצה, הצבירה כוללת את המופע הראשון ומבטלת דוחות מאוחרים יותר עם אותו מזהה.

בלי הכלל 'ללא כפילויות', תוקף יכול לקבל תובנות לגבי התוכן של קבוצת קבצים ספציפית על ידי מניפולציה של התוכן של קבוצות הקבצים, באמצעות הכללת עותקים כפולים של דוח בקבוצת קבצים אחת או בכמה קבוצות קבצים.

מידע נוסף על אכיפת הכלל 'ללא כפילויות' בתוך קבוצה של דוחות או במספר קבוצות מפורט במאמר דוחות כפולים בקבוצות.

קבוצות נפרדות

כדי למנוע מצבים שבהם יש חפיפה בין קבוצות, שירות הצבירה אוכף קבוצות נפרדות. המשמעות היא שאי אפשר ליצור שתי קבוצות או יותר של דוחות שיש להם מזהה משותף. מזהה משותף הוא שילוב של נתונים שנאספים מהשדה shared_info של דוח שניתן לצבור, יחד עם המזהה לסינון מבקשת המשימה. אם לא צוין מזהה סינון, המערכת משתמשת בערך ברירת המחדל 0.

בדוגמה הבאה לשדה shared_info, אפשר לראות את ה-API, 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 מקוצר לפי שעה, יש דוחות שיש להם את אותו מזהה משותף. בדוגמה הזו, לדוחות Report1 ו-Report2 יש שדות מידע משותפים. לשני הדוחות יש את אותו API, גרסה, 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 בשעה 21:08:10' עבור Report1 ו'19 בפברואר 2024 בשעה 21:55:10' עבור Report2. מאחר שהערך בשדה scheduled_report_time נקטע לשעה, בשני הדוחות הערך בשדה scheduled_report_time הוא 1708376890 (הערך המקודד של '19 בפברואר 2024 בשעה 21:00').

כל שאר השדות ומזהה הסינון זהים, ולשני הדוחות יש את אותו מזהה משותף. מכיוון שלשני הדוחות יש אותו מזהה משותף, צריך לכלול את שניהם באותו קבוצה.

אם Report1 צורף לאוסף בעבר והעיבוד שלו הסתיים בהצלחה, ו-Report2 מעובד באוסף מאוחר יותר, האוסף עם Report2 ייכשל עם שגיאה מסוג PRIVACY_BUDGET_EXHAUSTED. במקרה כזה, מסירים את הדוחות עם המזהה המשותף שצורפו בהצלחה לאוספים קודמים ומנסים שוב. מידע נוסף על השגיאה הזו זמין במאמר קודי שגיאה והקלות על Service Aggregation.

איור 2. קבוצה 2 מכילה דוח שיש לו מזהה משותף עם דוח בקבוצה 1, ולכן קבוצה 2 נכשלת.

מפתחות צבירת נתונים שהוגדרו מראש

כששולחים קבוצה ל-Aggregation Service, היא חייבת לכלול גם את הדוחות שניתנים לצבירה שמתקבלים ממקור הדיווח וגם את קובץ הדומיין של הפלט. דומיין הפלט מכיל את המפתחות או הקטגוריות שאוחזרו מהדוחות שניתן לצבור.

מבחינת פרטיות, המערכת מוסיפה רעש לכל המפתחות שהוגדרו מראש בדומיין הפלט, גם אם אין דוח אמיתי שמתאים למפתח מסוים. ציון הדומיין של הפלט מגן מפני התקפה שבה נוכחות המפתח בפלט חושפת משהו על משתמש או אירוע יחיד. לדוגמה, אם הצגתם קמפיין רק למשתמש אחד, קבלת מפתח בפלט מראה שהמשתמש השלים המרה מאוחר יותר, גם אם נוספה רעש. כשמציינים את הדומיין הזה קודם, אפשר להיות בטוחים שהוא לא חושף מידע על התרומות של המשתמש.

אפשר להצהיר על המפתחות האלה באורך 128 ביט ב-Attribution Reporting API או ב-Private Aggregation API, ולהשתמש בהם כדי לקודד מאפיינים שאחריהם רוצים לעקוב.

רק מפתחות שהוצהרו מראש נלקחים בחשבון לצורך צבירת נתונים ונכללים בדוח הסיכום. הערכים המצטברים של הקטגוריות בדוח הסיכום כוללים רעש סטטיסטי, שמשתקף בדוח הסיכום שנוצר.

איור 3. דוח סיכום מכיל רק מפתחות שהוגדרו מראש, שנקראים גם קטגוריות.

אם מפתח צביר נכלל בקובץ הדומיין של הפלט אבל לא נמצא בדוח באצווה, גם אם הערך המצטבר הוא אפס, סביר להניח שדוח הסיכום הסופי לא יהיה אפס בגלל הרעשי הרקע שנוספו כדי לשמור על הפרטיות.