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

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

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

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

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

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

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

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

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

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

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

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

ב-Chrome תתבצע העברה זהירה של כל החלפה אפשרית אפשרית.

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

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

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

עניין ושיתוף משוב

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