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

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

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

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

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

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

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

תקציב התרומה

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

מידע נוסף על הגדרת תקציבי תרומות לכל ממשק API זמין בקטעים הבאים במסמכי העזרה של ממשקי ה-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, ולהשתמש בהם כדי לקודד מאפיינים שאחריהם רוצים לעקוב.

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

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

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