לארגונים רבים יש אתרים קשורים עם שמות דומיינים שונים, כמו brandx.site ו-fly-brandx.site, או דומיינים במדינות שונות, כמו example.com, example.rs, example.co.uk וכו'.
הדפדפנים הולכים להוציא משימוש את קובצי ה-cookie של צד שלישי כדי לשפר את הפרטיות באינטרנט, אבל אתרים כאלה מסתמכים לעיתים קרובות על קובצי cookie לצורך פונקציות שדורשות שמירה של מצב והרשאה לגשת אליו בתחומים שונים (למשל, כניסה יחידה לחשבון וניהול הסכמה).
קבוצות מאינטראקציה ישירה מאפשרות להתייחס לשמות דומיינים קשורים שבבעלות אותה ישות ובניהולה כאל צד ראשון במצבים שבהם צד ראשון וצד שלישי מקבלים יחס שונה. שמות הדומיינים בקבוצה של צד ראשון נחשבים לצד ראשון, והם יכולים לתייג את קובצי ה-Cookie שמיועדים להגדרה או לשליחה בהקשר של צד ראשון. המטרה היא למצוא איזון בין מניעת מעקב באתרים שונים על ידי צדדים שלישיים, לבין שמירה על נתיב שלא מפר תרחישי שימוש תקפים.
ההצעה של 'קבוצות נתונים מאינטראקציה ישירה' נמצאת כרגע בשלבי בדיקה. בהמשך מוסבר איך היא פועלת ואיך אפשר לנסות אותה.
מה ההבדל בין קובצי cookie מהדומיין הנוכחי לבין קובצי cookie של צד שלישי?
קובצי cookie הם לא תמיד קובצי cookie מהדומיין הנוכחי או קובצי cookie של צד שלישי. זה תלוי בהקשר הנוכחי שבו קובץ ה-cookie נכלל. אפשר להגדיר את הערך בבקשה בכותרת cookie או באמצעות document.cookie ב-JavaScript.
לדוגמה, אם באתר video.site יש קובץ cookie מסוג theme=dark, כשאתם גולשים ב-video.site ונשלחת בקשה אל video.site, מדובר בהקשר באותו אתר והקובץ cookie שכלול הוא מהדומיין הנוכחי.
עם זאת, אם אתם נמצאים באתר my-blog.site שבו מוטמע נגן iframe של video.site, כשהבקשה נשלחת מ-my-blog.site אל video.site, מדובר בהקשר בין אתרים וקובץ ה-cookie theme הוא של צד שלישי.
ההכללה של קובץ ה-Cookie נקבעת לפי המאפיין SameSite של קובץ ה-Cookie:
- הקשר באותו אתר עם
SameSite=Lax,StrictאוNoneהופך את קובץ ה-cookie לקובץ cookie מהדומיין הנוכחי. - הקשר בכמה אתרים עם
SameSite=Noneהופך את קובץ ה-cookie לצד שלישי.
עם זאת, לא תמיד העניין פשוט כל כך. נניח ש-brandx.site הוא אתר להזמנת נסיעות, והם משתמשים גם ב-fly-brandx.site וב-drive-brandx.site כדי להפריד בין טיסות לבין השכרת רכב. במהלך תהליך ההזמנה, המבקרים עוברים בין האתרים האלה כדי לבחור את האפשרויות השונות – הם מצפים ש'עגלת הקניות' של הבחירות שלהם תישאר באתרים האלה. brandx.siteמנהל את הסשן של המשתמש באמצעות קובץ cookie מסוג SameSite=None כדי לאפשר לו לפעול בהקשרים שונים באתרים שונים. עם זאת, החיסרון הוא שכעת לא תהיה לקובץ ה-cookie הגנה מפני זיוף בקשות בין אתרים (CSRF). אם evil.site כולל בקשה ל-brandx.site, הוא יכלול את קובץ ה-cookie הזה.
קובץ ה-cookie פועל בכמה אתרים, אבל כל האתרים האלה נמצאים בבעלות של אותו ארגון ופועלים על ידו. המבקרים גם מבינים שמדובר באותו ארגון ורוצים להשתמש באותו סשן, כלומר בזהות משותפת.
המדיניות בנושא קבוצות מאינטראקציה ישירה (First-Party Sets)
קבוצות של דומיינים של צד ראשון מציעות שיטה להגדרה מפורשת של הקשר הזה במספר אתרים שנמצאים בבעלות ובניהול של אותו צד. כך brandx.site תוכל להגדיר את הקשר שלה עם fly-brandx.site, drive-brandx.site וכן הלאה מאינטראקציה ישירה (First-Party).
מודל הפרטיות שמנחה את ההצעות השונות של ארגז החול לפרטיות מבוסס על הרעיון של חלוקת זהויות כדי למנוע מעקב בכמה אתרים בו-זמנית – יצירת גבול בין אתרים שמגביל את הגישה לכל מידע שאפשר להשתמש בו כדי לזהות משתמשים.
אפשרות ברירת המחדל היא חלוקה לפי אתר, והיא פותרת הרבה תרחישים לדוגמה של אינטראקציה ישירה (First-Party). עם זאת, הדוגמה brandx.site מראה שצד ראשון יכול להיות גדול יותר מאתר אחד.
חלק חשוב מהצעה של 'קבוצות של צד ראשון' הוא להבטיח שהמדיניות בדפדפנים השונים תמנע ניצול לרעה או שימוש לרעה. לדוגמה, אסור להשתמש בקבוצות של דומיינים של צד ראשון כדי להחליף מידע על משתמשים בין אתרים לא קשורים, או כדי לקבץ אתרים שלא בבעלות של אותו ישות. הרעיון הוא לוודא שקבוצה מאינטראקציה ישירה (First-Party) ממופה למשהו שאדם מבין כגורם מאינטראקציה ישירה, ולא משמשת כדרך לשיתוף זהות בין גורמים שונים.
אחת מהדרכים האפשריות שבהן אתר יכול לרשום קבוצה של נתונים מאינטראקציה ישירה היא לשלוח את הקבוצה המוצעת של הדומיינים למעקב ציבורי (כמו מאגר ייעודי ב-GitHub) יחד עם המידע הנדרש כדי לעמוד בדרישות המדיניות של הדפדפן.
אחרי שההצהרה על קבוצת הצד הראשון מאומתת בהתאם למדיניות, הדפדפנים יכולים לאחזר רשימות של קבוצות באמצעות תהליך עדכון.
לתוכנית הניסוי למקורות יש מדיניות מוגדרת, שעדיין לא סופית, אבל סביר להניח שהעקרונות לא ישתנו:
- הדומיינים בקבוצה של צד ראשון צריכים להיות בבעלות של אותו ארגון, והוא צריך לנהל אותם.
- המשתמשים צריכים לזהות את הדומיינים כקבוצה.
- הדומיינים צריכים לשתף מדיניות פרטיות משותפת.
איך מגדירים קבוצה מאינטראקציה ישירה
אחרי שמזהים את המשתתפים ואת הבעלים של הקבוצה של הנתונים מהצד הראשון של הארגון, השלב החשוב הוא לשלוח את הקבוצה המוצעת לאישור. התהליך המדויק עדיין נמצא בבדיקה.
כדי להצהיר על קבוצת צד ראשון, צריך לארח משאבי JSON סטטיים שמפרטים את החברים והבעלים בכתובת /.well-known/first-party-set ברמה העליונה של כל דומיין שכלול בקבוצה.
בדוגמה של קבוצת הצד ה-brandx, הדומיין של הבעלים מארח את הנתונים הבאים ב-https://brandx.site/.well-known/first-party-set:
{
"owner": "brandx.site",
"version": 1,
"members": ["fly-brandx.site", "drive-brandx.site"]
}
כל חבר בקבוצה מארח גם משאב JSON סטטי שמצביע חזרה לבעלים של הקבוצה.
ב-https://fly-brandx.site/.well-known/first-party-set יש לנו:
{ "owner": "brandx.site" }
וגם ב-https://drive-brandx.site/.well-known/first-party-set:
{ "owner": "brandx.site" }
יש כמה אילוצים לגבי קבוצות מאינטראקציה ישירה:
- לכל קבוצה יכול להיות רק בעלים אחד.
- כל חבר יכול להשתייך רק לקבוצה אחת, בלי חפיפה או שילוב.
- רשימת המשתתפים אמורה להישאר קריאה יחסית לבני אדם ולא להיות גדולה מדי.
איך קבוצות מאינטראקציה ישירה משפיעות על קובצי cookie?
המרכיב התואם לקובצי cookie הוא המאפיין SameParty שהצעתם. ציון הערך SameParty מציין לדפדפן לכלול את קובץ ה-cookie כשההקשר שלו הוא חלק מאותה קבוצה של צד ראשון כמו ההקשר ברמה העליונה.
כלומר, אם brandx.site מגדיר את קובץ ה-cookie הזה:
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
לאחר מכן, כשהמבקרים נמצאים ב-fly-brandx.site ובקשה נשלחת אל brandx.site, קובץ ה-cookie session ייכלל בבקשה הזו.
אם אתר אחר שאינו חלק מהקבוצה של הדומיין הנוכחי, למשל hotel.xyz, שולח בקשה אל brandx.site, קובץ ה-cookie לא ייכלל.
עד ש-SameParty יקבל תמיכה רחבה, מומלץ להשתמש במאפיין SameSite יחד איתו כדי להגדיר התנהגות חלופית לקובצי cookie. אפשר לחשוב על המאפיין SameParty כמגדיר הגדרה בין SameSite=Lax ל-SameSite=None.
SameSite=Lax; SamePartyמורחבת את הפונקציונליות שלLaxכך שתכלול הקשרים של אותו צד, אם יש תמיכה בכך, אבל חוזרת להגבלות שלLaxאם אין תמיכה.SameSite=None; SamePartyיגביל את הפונקציונליות שלNoneרק להקשרים של אותו צד, אם יש תמיכה בכך, אבל יעבור להרשאותNoneרחבות יותר אם לא.
יש כמה דרישות נוספות:
- קובצי ה-cookie מסוג
SamePartyחייבים לכלול אתSecure. - אסור לכלול את
SameSite=Strictבקובצי ה-cookie שלSameParty.
Secure נדרש כי עדיין מדובר באתרים שונים, וצריך לצמצם את הסיכונים האלה על ידי הבטחת חיבורים מאובטחים (HTTPS). כמו כן, מכיוון שזוהי יחסים בין אתרים, הערך SameSite=Strict לא תקף כי הוא עדיין מאפשר הגנה הדוקה על CSRF מבוססת-אתר בתוך קבוצה.
באילו תרחישים לדוגמה כדאי להשתמש בקבוצות מאינטראקציה ישירה?
קבוצות של דומיינים של צד ראשון מתאימות למקרים שבהם לארגון יש צורך בזהות משותפת באתרים שונים ברמה העליונה. במקרה הזה, זה יכול להיות כל דבר, החל מפתרון מלא של כניסה יחידה ועד לצורך פשוט להגדרת העדפה משותפת בין אתרים.
יכול להיות לארגון שלכם יש דומיינים ברמה עליונה שונים לצורך:
- דומיינים של אפליקציות:
office.com,live.com,microsoft.com - דומיינים ממותגים:
amazon.com, audible.com/disney.com, pixar.com - דומיינים ספציפיים למדינה כדי להפעיל את התכונה 'תרגום':
google.co.in,google.co.uk - דומיינים של שירותים שמשתמשים אף פעם לא מבצעים איתם אינטראקציה ישירה, אבל מספקים שירותים באתרים של אותו ארגון:
gstatic.com,githubassets.com, fbcdn.net - דומיינים של ארגז חול שמשתמשים אף פעם לא מבצעים איתם אינטראקציה ישירה, אבל הם קיימים מסיבות אבטחה:
googleusercontent.com, githubusercontent.com
איך אפשר להצטרף?
אם יש לכם קבוצה של אתרים שעומדים בקריטריונים שלמעלה, יש כמה אפשרויות להצטרף לתוכנית. ההשקעה הקטנה ביותר היא לקרוא את שתי ההצעות ולהצטרף לדיון עליהן:
בשלב הבדיקה, תוכלו לנסות את הפונקציונליות באמצעות הדגל --use-first-party-set בשורת הפקודה, ולציין רשימה של אתרים שמופרדים בפסיקים.
אפשר לנסות את זה באתר ההדגמה בכתובת https://fps-member1.glitch.me/ אחרי שמפעילים את Chrome עם הדגל הבא:
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
האפשרות הזו שימושית אם רוצים לבדוק בסביבת הפיתוח, או אם רוצים לנסות להוסיף את המאפיין SameParty בסביבה פעילה כדי לראות איך קבוצה של צד ראשון תשפיע על קובצי ה-cookie.
אם יש לכם את רוחב הפס להרצת ניסויים ולקבלת משוב, תוכלו גם להירשם לגרסת הניסיון של Origin לקבוצות מאינטראקציה ישירה ול-SameParty, שזמינה ב-Chrome מגרסה 89 עד 93.
איך מעדכנים את קובצי ה-cookie לתקופת הניסיון במקור
אם אתם מצטרפים לגרסת המקור לניסיון ובודקים את המאפיין SameParty בקובצי ה-cookie, כדאי לכם לשקול את שני הדפוסים הבאים.
אפשרות 1
קודם כול, אם יש לכם קובצי cookie שסימנתם בתווית SameSite=None אבל אתם רוצים להגביל אותם להקשרים מהדומיין הנוכחי, תוכלו להוסיף להם את המאפיין SameParty. בדפדפנים שבהם גרסת המקור של הניסוי פעילה, קובץ ה-cookie לא יישלח בהקשרים של אתרים שונים מחוץ לקבוצה.
עם זאת, ברוב הדפדפנים מחוץ לגרסת הניסיון המקורית, קובץ ה-cookie ימשיך להישלח בין אתרים כרגיל. כדאי להתייחס לכך כגישה של שיפור הדרגתי.
לפני:
set-cookie: cname=cval; SameSite=None; Secure
אחרי:
set-cookie: cname=cval; SameSite=None; Secure; SameParty
אפשרות 2
האפשרות השנייה מחייבת יותר עבודה, אבל מאפשרת להפריד לחלוטין את גרסת ה-Origin לניסיון מהפונקציונליות הקיימת, ומאפשרת לבדוק במיוחד את השילוב של SameSite=Lax; SameParty.
לפני:
set-cookie: cname=cval; SameSite=None; Secure
אחרי:
set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty
כשבודקים את ה-cookie בבקשות נכנסות, צריך לצפות לראות את ה-cookie cname-fps בבקשה מאתרים שונים רק אם האתרים הרלוונטיים נמצאים בקבוצה והדפדפן נמצא בגרסת הטרום-השקה של המקור. אפשר להתייחס לגישה הזו כאל השקה בו-זמנית של תכונה מעודכנת לפני השבתת הגרסה הקודמת.
למה יכול להיות שלא תצטרכו קבוצה של צד ראשון?
ברוב האתרים, גבול האתר הוא מקום מקובל לציור המחיצה או גבול הפרטיות. זהו המסלול שאנחנו מציעים באמצעות CHIPS (קובצי cookie עם מצב מפוצל עצמאי), שיעניק לאתרים מסלול להצטרפות באמצעות המאפיין Partitioned, כדי שיוכלו להמשיך להשתמש בשירותים, בממשקי ה-API וברכיבי ההטמעה החיוניים האלה באתרים שונים, תוך מניעת זליגת מידע מזהה בין אתרים.
יש כמה דברים נוספים שחשוב להביא בחשבון, שיכולים להצביע על כך שהאתר שלכם לא זקוק לקבוצה:
- אתם מארחים מקורדים שונים, ולא אתרים שונים. בדוגמה שלמעלה, אם
brandx.siteהכיל אתfly.brandx.siteואתdrive.brandx.site, אלה תתי-דומיינים שונים באותו אתר. קובצי ה-cookie יכולים להשתמש ב-SameSite=Laxואין צורך להגדיר אותם. - אתם מספקים הטמעות של צד שלישי לאתרים אחרים. בפתיח, הדוגמה לסרטון מ-
video.siteשמוטמע ב-my-blog.siteהיא דוגמה ברורה לצד שלישי. האתרים מופעלים על ידי ארגונים שונים, והמשתמשים רואים אותם כישויות נפרדות. אסור לכלול את שני האתרים האלה באותה קבוצה. - אתם מספקים שירותי כניסה באמצעות רשתות חברתיות של צד שלישי. ספקי זהויות שמשתמשים ב-OAuth או ב-OpenId Connect לרוב מסתמכים על קובצי Cookie של צד שלישי כדי לספק למשתמשים חוויית כניסה חלקה יותר. זהו תרחיש לדוגמה תקף, אבל הוא לא מתאים לקבוצות מאינטראקציה ראשונה כי יש הבדל ברור בין ארגונים. הצעות מוקדמות כמו WebID בוחנות דרכים להפעלת התרחישים לדוגמה האלה.