למה הוספנו את Attribution Reporting API ל-Chrome

Attribution Reporting API הוא ממשק ה-API של Chrome שמאפשר לתמוך בתרחישים לדוגמה של דיווח שיוך תוך שיפור הפרטיות של המשתמשים. זוהי אחת מהצעות רבות (1,‏ 2,‏ 3,‏ 4 ועוד) שמנסות לפתור את אותה בעיה.

במסמך הזה נסביר למה השקנו את Attribution Reporting API בזמן שהוא עדיין נמצא בתוכנית החממה של קבוצת הקהילה של Web Incubator. אנחנו ב-Chrome מחויבים לחלוטין להשתתף בתהליכים הרלוונטיים של W3C, וצוותים של Chrome עובדים בקבוצת הקהילה של טכנולוגיות פרסום פרטיות (PATCG) כדי לזהות פתרון שיהלום את רוב מנועי הדפדפנים. השקת ה-API במקביל תאפשר לנו לבדוק ולשפר את תרחיש השימוש החשוב הזה.

תרחישי השימוש ש-Attribution Reporting API תומך בהם חשובים כדי לספק תמיכה יעילה בצרכים של הסביבה העסקית לפני ההוצאה משימוש של קובצי cookie של צד שלישי.

אנחנו מאמינים שתרחישי השימוש של Attribution Reporting הם קריטיים לסביבה עסקית משגשגת באינטרנט. אנחנו גם מאמינים שהסרת קובצי cookie של צד שלישי מ-Chrome חיונית לשיפור הפרטיות של המשתמשים באינטרנט.

כדי לענות על הצרכים של הסביבה העסקית ולשפר את ההגנה על פרטיות המשתמשים, אנחנו סבורים שצריך להשיק את ממשק ה-API הזה כדי לאפשר בדיקה וכיול לפני ההוצאה משימוש של קובצי Cookie של צד שלישי. העמדה הזו תואמת למחויבויות שלנו כלפי רשות התחרות והשווקים (CMA) בבריטניה בנוגע לארגז החול לפרטיות ולהסרת קובצי ה-cookie של צד שלישי ב-Chrome.

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

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

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

השקת Attribution Reporting API מציעה יתרונות מוכחים מבחינת הנחת היסודות לעתיד המדידה בפלטפורמת האינטרנט:

  • מחקר: הפעלת ה-API תספק ל-Chrome ולספקי דפדפנים אחרים תובנות חשובות שיעזרו להם לתכנן ממשק API עתידי עם יכולת פעולה הדדית. נשתף את התובנות המוקדמות שלנו עם גופים כמו PATCG כדי לשפר את התקנים העתידיים.
  • שינוי פרדיגמה בפיתוח: מפתחים שעוברים ל-Attribution Reporting API יצטרכו להשתמש במושגים טכניים חדשים, כמו הוספת רעש, שצפויים להיות מפתח למדידות עתידיות לשמירה על הפרטיות, ללא קשר לממשק ה-API הספציפי. מפתחים יתחילו גם להתאים את המערכות האחרות שלהם לנתונים רועשים. אנחנו נעשה כמיטב יכולתנו כדי לספק למפתחים את המסמכים והתמיכה הנדרשים להם כדי לטפל ברעשי רקע ובמושגים שסביר להניח שאפשר להעביר.

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

ב-Chrome יתבצע מעבר זהיר לכל תחליף אפשרי עם יכולת פעולה הדדית.

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

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

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

שיתוף משוב ויצירת אינטראקציה

אנחנו מחויבים להמשיך ולשפר את ה-API, וכבר ביצענו כמה שינויים בתגובה למשוב מהמפתחים (כמו 1,‏ 2,‏ 3,‏ 4,‏ 5 ועוד). נשמח לקבל משוב נוסף, ומצפים להמשיך לעבוד בשיתוף פעולה הדוק עם הקהילה.