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

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

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

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

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

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

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

תקציב תרומות

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

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

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

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

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

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

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

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

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

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

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