דומיינים של צד ראשון (FPS) נועדו לתמוך בחוויית הגלישה של המשתמשים באינטרנט אחרי ההוצאה משימוש של קובצי cookie של צד שלישי ב-Chrome. ההצעה התפתחה באופן משמעותי בפורומים פתוחים באינטרנט במהלך הדגמת FPS, תחילה בקבוצת קהילת הפרטיות של W3C ועכשיו בקבוצת הקהילה של Web Incubator.
בפוסט הזה בבלוג נסכם את תהליך האבולוציה, נדגיש את השינויים העיקריים ונסביר למה אנחנו סבורים שהשינויים האלה משפרים את הפרטיות באינטרנט וממשיכים לתמוך בסביבה העסקית.
רקע
אתרים מסתמכים לעיתים קרובות על גישה לקובצי ה-cookie שלהם בהקשר של צד שלישי כדי לספק למשתמשים חוויות מותאמות אישית בצורה חלקה. נוסף על ממשקי ה-API של שימור הפרטיות (Topics, Protected Audience API ו-Attribution), צוות Chrome ביקש להבין את היקף התרחישים שבהם נעשה שימוש בקובצי cookie של צד שלישי, מעבר להתאמה אישית של מודעות ולמטרות מדידה, כדי לספק למשתמשים חוויית גלישה משופרת.
גילינו שארגונים עשויים להסתמך על קובצי cookie של צד שלישי כי ארכיטקטורת האינטרנט שלהם מיועדת לשימוש במספר דומיינים. לדוגמה, לארגון יכול להיות דומיין אחד לבלוג בנושא טיולים ודומיין אחר לחנות הקמפינג, והוא מעוניין לתמוך בתהליכים שעוברים המשתמשים באתרים האלה. ארגונים יכולים גם לתחזק מספר דומיינים של קודי מדינות עם תשתית משותפת של שירות האינטרנט. במקרים כאלה, המטרה שלנו הייתה ליצור פתרון שתואם לצרכים של ארגונים כאלה, תוך שמירה על הציפיות של המשתמשים לפרטיות שלהם באינטרנט.
איפה התחלנו
מכיוון שהדפדפן משתמש כרגע בגבולות ברמת האתר כדי לפרש 'צד ראשון' לעומת 'צד שלישי' על מנת להביא בחשבון את מגוון הדומיינים שארגון יכול לנהל, נראה היה שצריך להחליף את הגבול הטכני הזה בהגדרה מפורטת יותר.
בשנת 2021, Chrome הציע בהתחלה את מאפיין קובצי ה-cookie SameParty לקבוצות של צד ראשון, כדי שאתרים יוכלו להגדיר קובצי cookie שמקורם באתרים
מאותו גורם. השתמשנו במדיניות של סוכן משתמש כדי להגדיר מה נחשב בתור "אותו צד". הגדרת המדיניות הזו ניסתה להתבסס על מסגרות קיימות של ה "מפלגה" (לדוגמה, על סמך מפרט W3C DNT), וגם שילבה המלצות מהדיון הרלוונטי בנושא פרטיות (כמו הדוח של ועדת הסחר הפדרלית לשנת 2012 שנקרא "Protecting Consumer Privacy in an Rapid Change" (הגנה על פרטיות הצרכן בעידן של שינוי מהיר)).
בזמנו חשבנו שהגישה הזו מספקת מספיק גמישות לסוגים שונים של ארגונים בכל ענפי התעשייה, ובמקביל עמדה ביעד היסודי שלנו לצמצום המעקב הנרחב באמצעות קובצי cookie של צד שלישי.
משוב על ההצעה הראשונית
במהלך שיחות רבות עם בעלי עניין בסביבה העסקית באינטרנט, גילינו שיש מגבלות על העיצוב הראשוני הזה.
אתגרי פרטיות עם גישה פסיבית לקובצי cookie דרך המאפיין SameParty
ספקי דפדפנים אחרים מעדיפים להשתמש בגישה פעילה לקובצי cookie של צד שלישי שדורשת הפעלה מפורשת של API, במקום להגדיר גבול שניתן לשמור בו גישה פסיבית לקובצי cookie. בקשות פעילות לגישה לקובצי cookie מספקות הרשאות גישה ושליטה בדפדפן, כדי לצמצם את הסיכון למעקב סמוי דרך קובצי cookie של צד שלישי. בנוסף, החשיפה הזו תאפשר לדפדפנים לספק למשתמשים את האפשרות אם לאשר או לחסום גישה לקובצי cookie כאלה.
כדי לשמור על יכולת פעולה הדדית באינטרנט בין דפדפנים ולשפר את היתרונות לשמירה על הפרטיות, החלטנו לפעול בכיוון הזה.
אתגרי הטמעה של המדיניות המוצעת
המדיניות המקורית הציעה שלוש דרישות לדומיינים צריכות להיות בקבוצה אחת: 'בעלות משותפת', 'מדיניות פרטיות משותפת' ו'זהות קבוצה משותפת'.
מהסביבה העסקית הרחבה יותר, קיבלנו את המשוב שקיבלנו על המדיניות לפי ארבעה נושאים עיקריים.
הגדרת הבעלות המשותפת מגבילה מדי
לגבי הדרישה "בעלות משותפת", קיבלנו משוב על כך שההגדרה של FPS שהתמקדה אך ורק בבעלות ארגונית תעניק לחברות גדולות יותר יכולת טובה יותר לרכז נתונים במגוון רחב של דומיינים ושירותים שמיועדים למשתמשים, בהשוואה לחברות קטנות יותר. המטרה שלנו היא ליצור את ארגז החול לפרטיות בסביבה העסקית בכללותה, ולכן קיבלנו את המשוב הזה ברצינות וחשבנו על פתרון שמעודד יותר את קבלת האחר.
מדיניות אחת מגבילה את יכולת ההרחבה לשימוש בתרחישים לדוגמה
המטרה של מדיניות מקיפה לשליטה על תחום הייתה לספק גמישות לסוגים שונים של דומיינים שצריכים להיות ב-FPS של הארגון, אבל גילינו שחלק מהתרחישים הקריטיים לא יכולים לעמוד בתכנון המדיניות הזו. לדוגמה, ייתכן שדומיינים של שירותים (כמו דומיינים שמארחים תוכן שנוצר על ידי משתמשים) תידרש גישה לקובצי ה-cookie שלהם בהקשר של צד שלישי כדי לאמת או לזהות משתמשים. לדומיינים כאלה יש דף בית שנגיש למשתמשים לעיתים רחוקות, ולכן לא ניתן לעמוד בדרישות של 'זהות קבוצה משותפת' או 'מדיניות פרטיות משותפת' עם דומיינים אחרים באותו FPS.
תפיסת המשתמשים וההבנה שלהם לגבי זהות הקבוצה עשויות להיות שונות
במקור הצענו שכבות הגנה להגדרה של 'זהות קבוצתית משותפת' כניסיון להגדיר דומיינים בקבוצה אחת לאלה שאפשר לשייך אותם בקלות לזהות משותפת של הקבוצה. עם זאת, לא הצלחנו להגדיר אמצעים טכניים למדידה ולהערכה אם זהות הקבוצה המשותפת יכולה להיות "גלויה למשתמשים בקלות". בעקבות זאת נותר פוטנציאל לניצול לרעה ולשאלות לגבי אכיפה.
נוסף לכך, קיבלנו משוב על כך שהבנת המשמעות של גבולות 'בעלות משותפת' עשויה להשתנות ממשתמש למשתמש, ולכן קשה יותר ליצור הנחיות שאפשר להחיל על כל האתרים.
קשה לאכוף מדיניות סובייקטיבית בקנה מידה נרחב
קיבלנו בקשות רבות להנחיות מפורטות יותר, בגלל האופי הסובייקטיבי של דרישות מסוימות (כמו 'זהות קבוצתית משותפת'), והצורך לכסות חריגים או מקרים קיצוניים עבור אחרים (לגבי 'מדיניות פרטיות משותפת').
כדי להבטיח שהמדיניות תיושם באופן שווה ועקבי, Chrome היה צריך לספק למחברי אתרים הנחיות הרבה יותר ספציפיות. הגענו למסקנה שניסיון לקבוע הנחיות מחמירות יותר עלול לפגוע רק בסביבה העסקית.
בשלב הראשון הצענו שיש ישות אכיפה עצמאית את התפקיד לחקור ולאכוף ציות למדיניות, אבל בסביבה העסקית הנוכחית היה קשה למצוא ישות אכיפה עצמאית עם המומחיות המתאימה כדי לבצע את המשימות האלה בצורה חסרת משוא פנים. במקום זאת, עשינו שינוי במדיניות שאפשר לאכוף מבחינה טכנית, כדי להבטיח שאפשר יהיה ליישם את המדיניות באופן עקבי ואובייקטיבי.
האבולוציה
בתגובה למשוב, עיצבנו מחדש את FPS. חזרנו לבעיות הספציפיות שניסינו לטפל בהן, והחלטנו לבחון באופן ישיר יותר את ההצעה בנוגע לתרחישים ספציפיים שאנחנו פותרים.
פתרון תרחישים לדוגמה עיקריים
כדי לענות על תרחישי שימוש מרכזיים באינטרנט, פיתחנו ב-Chrome שלוש 'קבוצות משנה' ייעודיות למטרה שונות. הגישה של קבוצות משנה שיפרה את הגישה הישנה באמצעות גישה פרטית, ספציפית יותר וקלה יותר לאכיפה באופן עקבי.
- 'ccTLD' (דומיינים ברמה העליונה של קוד מדינה) – ארגונים יכולים לתחזק אתרים עם שמות דומיין אחרים מסוג ccTLD כדי לספק חוויות מקומיות, וייתכן שלאתרים האלה עדיין תידרש גישה לתשתיות ולשירותים משותפים.
- דומיינים של 'שירות' – אתרים עשויים להשתמש בדומיינים נפרדים למטרות אבטחה או ביצועים, ואתרים כאלה עשויים לדרוש גישה לזהות המשתמש כדי לבצע את הפעולות שלהם.
- דומיינים "משויכים" - ארגונים יכולים לתחזק אתרים מרובים עבור מותגים או מוצרים קשורים ושונים. הם עשויים לרצות לקבל גישה לקובצי cookie באתרים שונים לצורך תרחישים לדוגמה, כמו ניתוח של התהליכים שעוברים המשתמשים באתרים קשורים כדי להבין טוב יותר את האינטראקציה של בסיס המשתמשים בארגון עם האתרים שלהם, או לזכור את מצב ההתחברות של המשתמש באתר קשור שמבוסס על אותה תשתית התחברות.
בכל אחד מתרחישי השימוש האלו יש דרישות מדיניות נפרדות, בדיקות אימות טכניות תואמות והתנהגות ספציפית של הדפדפן (הנחיות לשליחה). השינויים האלה מטפלים במגבלות של ההצעה המקורית – הם נוטשים את העיצוב של "one size fits all" ומעדיפים מסגרת ממודרת ומבוססת-רישיות.
הזדמנות ליכולת פעולה הדדית באמצעות בקשות פעילות לגישה לקובצי cookie של צד שלישי
אנחנו ב-Chrome רוצים לקדם יכולת פעולה הדדית עם דפדפנים אחרים כדי לשמור על התקינות של פלטפורמת האינטרנט. מכיוון שדפדפנים אחרים כמו Safari, Firefox ו-Edge משתמשים כרגע ב-Storage Access API (SAA) כדי לאפשר בקשות פעילות לקובצי cookie, בחרנו להשתמש ב-SAA ב-Chrome לא רק כדי לטפל במשוב שקיבלנו מפתחות, אלא גם כדי לתמוך ביכולת הפעולה ההדדית באינטרנט.
כדי לספק למפתחים יותר גמישות ולטפל במגבלות ידועות של SAA, הצענו גם את requestStorageAccessForOrigin API.
הזדמנות להשתמש ב-Storage Access API וב-FPS ביחד
כשמטמיעים את Storage Access API (SAA), הדפדפנים יכולים לבקש הרשאה ישירות ממשתמשים, ואנשים אחרים יכולים לאשר מספר מוגבל של בקשות בלי להציג בקשה להרשאה.
ב-Chrome מאמינים ש-FPS יכול לספק שכבה שקופה מעל SAA, על ידי הגבלת החיכוך של המשתמשים ומניעת עייפות ההנחיות בתרחישים לדוגמה מוגבלים. השימוש ב-FPS גם מאפשר לדפדפנים לספק למשתמשים הקשר נוסף לגבי חברות בקבוצה, אם הם יבחרו לבקש הרשאה.
במסגרת השימוש ב-FPS, מפתחים יכולים לזהות את האתרים שלהם שהושפעו, שמשמשים בתרחישים חשובים לדוגמה. כך המפתחים יכולים לצפות מראש איך האתרים שלהם יתפקדו עבור המשתמשים, ולנקוט צעדים כדי להגביל את ההשפעה על חוויית המשתמש על ידי שימוש ב-FPS או בחלופה לקובצי cookie של צד שלישי. בנוסף, השימוש ב-FPS מאפשר חיזוי בפלטפורמות של המפתחים, בניגוד להיוריסטיקה שיכולה להשתנות עם הזמן או להוביל להתנהגות שונה אצל משתמשים שונים.
לבסוף, מפתחים שמטמיעים את SAA כדי לעבוד עם FPS ב-Chrome יוכלו להשתמש ב-SAA גם כדי לשפר את ביצועי האתרים שלהם בדפדפנים אחרים, גם אם הם לא שולחים FPS.
דיון מתמשך
אנחנו מאמינים שההצעה האחרונה שלנו יוצרת את האיזון הנכון במרחב סחר מאתגר המתחשב בצרכים של המשתמשים והמפתחים. אנחנו מעריכים את המשוב שקיבלנו מבעלי עניין בתחום הסביבה העסקית של האינטרנט, שעזר לנו לפתח את הצעת ה-FPS.
ברור לנו שבעלי העניין בסביבה העסקית באינטרנט עדיין מכירים את ההצעה המעודכנת. אנו מזמינים אתכם ליצור איתנו קשר כדי שנוכל להמשיך לשפר את העיצוב באופן שיועיל יותר למפתחים ונמשיך לשפר את הפרטיות באינטרנט. Google גם תמשיך לעבוד עם רשות התחרות והשווקים (CMA) של בריטניה כדי להבטיח עמידה בדרישות ההתחייבויות.
כדי לעודד מעורבות, מומלץ לעיין במשאבים הבאים:
עבודה עם הסביבה העסקית
זה נהדר לראות חברות כמו Salesforce ו-CafeMedia לגבי משוב חשוב ופיתוח של דומיינים של צד ראשון. הם עזרו מאוד לקדם את הטכנולוגיה. כמה אנשים אחרים גם שיתפו את דעתם על דומיינים של צד ראשון ואת המאמצים של Chrome לעבוד עם הסביבה העסקית של האינטרנט:
"ב-Chrome אנחנו מפתחים קבוצות של נתונים מאינטראקציה ישירה (First-Party) כדי להתאים לרבים מתרחישי השימוש שלנו, כמו שימור התהליכים שעוברים המשתמשים. זה מראה לנו שצוות Google פועל כדי להבין את הסוגים השונים של הצרכים של בעלי אתרים באינטרנט". - Mercado Libre
"ב-VWO אנחנו מעריכים את המאמצים של Google להעלות את הסטנדרטים בנושא פרטיות, תוך הקפדה על טיפול במקרי שימוש אמיתיים. זה נהדר שהצוות משתף פעולה עם הסביבה העסקית של המפתחים, ומשפר באופן קבוע את היישום של ההצעות לקבוצות של צד ראשון על סמך המשוב מבעלי עניין באינטרנט. אנחנו נרגשים להיות חלק מתהליך הבדיקה של ההצעה, ומצפים להטמעה בדפדפן". - ניטיש מיטאל, מנהל הנדסה, VWO