לארגונים רבים יש אתרים קשורים עם שמות דומיינים שונים, כמו 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). עם זאת, הדוגמה brandx.site מראה שצד ראשון יכול להיות גדול יותר מאתר אחד.
חלק חשוב מהצעה של 'קבוצות של צד ראשון' הוא להבטיח שהמדיניות בדפדפנים השונים תמנע ניצול לרעה או שימוש לרעה. לדוגמה, אסור להשתמש בקבוצות של דומיינים של צד ראשון כדי להחליף מידע על משתמשים בין אתרים לא קשורים, או כדי לקבץ אתרים שלא בבעלות של אותו ישות. הרעיון הוא לוודא שקבוצה מאינטראקציה ישירה (First-Party) ממופה למשהו שאדם מבין כגורם מאינטראקציה ישירה, ולא משמשת כדרך לשיתוף זהות בין גורמים שונים.
אחת מהדרכים האפשריות שבהן אתר יכול לרשום קבוצה של נתונים מאינטראקציה ראשונית (First-Party) היא לשלוח את הקבוצה המוצעת של הדומיינים למעקב ציבורי (כמו מאגר ייעודי ב-GitHub) יחד עם המידע הנדרש כדי לעמוד בדרישות המדיניות של הדפדפן.
אחרי שההצהרה על קבוצת הצד הראשון מאומתת בהתאם למדיניות, הדפדפנים יכולים לאחזר רשימות של קבוצות באמצעות תהליך עדכון.
לתוכנית הניסוי למקורות יש מדיניות מוגדרת, שעדיין לא סופית, אבל סביר להניח שהעקרונות לא ישתנו:
- הדומיינים בקבוצה של צד ראשון צריכים להיות בבעלות של אותו ארגון, והוא צריך לנהל אותם.
- המשתמשים צריכים לזהות את הדומיינים כקבוצה.
- הדומיינים צריכים לשתף מדיניות פרטיות משותפת.
איך מגדירים קבוצה מאינטראקציה ישירה
אחרי שמזהים את המשתתפים ואת הבעלים של הקבוצה של הנתונים מהצד הראשון של הארגון, השלב החשוב הוא לשלוח את הקבוצה המוצעת לאישור. התהליך המדויק עדיין נמצא בבדיקה.
כדי להצהיר על קבוצת צד ראשון, צריך לארח משאבי JSON סטטיים שמפרטים את החברים והבעלים בכתובת /.well-known/first-party-set ברמה העליונה של כל דומיין שכלול בקבוצה.
בדוגמה של קבוצת הצד ה-1 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`, then thesession`cookie will be included on that request.
If some other site which is not a part of the first-party set, for examplehotel.xyz, sends a request tobrandx.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.
אם יש לכם את רוחב הפס להפעלת ניסויים ולקבלת משוב, תוכלו גם להירשם לגרסת המקור לניסיון של קבוצות צד ראשון ו-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 בוחנות דרכים להפעלת התרחישים לדוגמה האלה.