לארגונים רבים יש אתרים קשורים עם שמות דומיינים שונים, כמו brandx.site ו-fly-brandx.site, או דומיינים למדינות שונות כמו example.com, example.rs, example.co.uk וכן הלאה.
דפדפנים עוברים להגדרת קובצי Cookie של צד שלישי כמיושנים כדי לשפר את הפרטיות באינטרנט, אבל אתרים כאלה בדרך כלל מסתמכים על קובצי Cookie לפונקציות שמחייבות שמירה על מצב גישה והרשאות גישה בכל הדומיינים (כמו כניסה יחידה (SSO) וניהול הסכמה).
דומיינים של צד ראשון יכולים לאפשר התייחסות שונה לשמות דומיינים קשורים שנמצאים בבעלות ובהפעלה של אותה ישות, במצבים שבהם יש התייחסות שונה לצד הראשון לצד שלישי. שמות הדומיינים בקבוצה של צד ראשון נחשבים לאותו צד, והם יכולים לסמן אילו קובצי 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 לאינטראקציה ישירה (First-Party). - הקשר באתרים שונים עם
SameSite=Noneהופך את קובץ ה-cookie לצד שלישי.
עם זאת, השיטה הזו לא תמיד ברורה כל כך. נניח ש-brandx.site הוא אתר להזמנת נסיעות, וגם החברה משתמשת ב-fly-brandx.site וב-drive-brandx.site כדי
להפריד בין טיסות לבין השכרת רכב. במהלך ההזמנה של מסע אחד, המבקרים
עוברים בין האתרים האלה כדי לבחור באפשרויות השונות – הם מצפים ש"עגלת הקניות" שבחרתם תישאר זמינה באתרים האלה. brandx.site
מנהל את הסשן של המשתמש באמצעות קובץ cookie מסוג SameSite=None כדי לאפשר אותו בהקשרים שבין כמה אתרים. החיסרון הוא שעכשיו לקובץ ה-cookie אין הגנה מסוג Cross Site Request Forgery (CSRF). אם evil.site כולל בקשה אל brandx.site, הוא יכלול את קובץ ה-cookie הזה!
קובץ ה-cookie הוא חוצה אתרים, אבל כל האתרים האלה נמצאים בבעלות ובהפעלה של אותו ארגון. המבקרים גם מבינים שמדובר באותו ארגון ורוצים את אותו סשן, במילים אחרות – זהות משותפת.
המדיניות בנושא דומיינים של צד ראשון
דומיינים של צד ראשון מציעים שיטה להגדרה מפורשת של הקשר הזה בין כמה אתרים שנמצאים בבעלות אותו צד ומופעלים על ידו. זה יאפשר ל-brandx.site להגדיר את הקשר מאינטראקציה ישירה עם fly-brandx.site, drive-brandx.site וכו'.
מודל הפרטיות שמניע את ההצעות השונות של ארגז החול לפרטיות מבוסס על הרעיון של חלוקה למחיצות (partitioning) של זהות כדי למנוע מעקב בין אתרים. שרטוט הגבול בין אתרים שמגביל את הגישה לכל מידע שיכול לשמש לזיהוי משתמשים.
אפשרות ברירת המחדל היא חלוקה למחיצות לפי אתר, שפותרת הרבה תרחישים לדוגמה של צד ראשון, אבל הדוגמה brandx.site מראה שצד ראשון יכול להיות גדול מאתר אחד בלבד.
חלק חשוב מההצעה של דומיינים של צד ראשון הוא לוודא שהמדיניות בדפדפנים שונים מונעת ניצול לרעה או שימוש לרעה. לדוגמה, דומיינים של צד ראשון לא יכולים לאפשר חילופי פרטי משתמשים בין אתרים לא קשורים, או קיבוץ של אתרים שאינם בבעלות אותה ישות. הרעיון הוא לוודא שקבוצה של צד ראשון ממופה למשהו שהוא מבין כאינטראקציה ישירה, ולא משמשת לשיתוף זהות בין צדדים שונים.
אחת הדרכים האפשריות לרישום קבוצה של צד ראשון באתר היא לאפשר לאתר לשלוח את קבוצת הדומיינים המוצעת שלו למעקב ציבורי (למשל מאגר ייעודי ב-GitHub), יחד עם המידע שנדרש כדי לעמוד במדיניות הדפדפן.
אחרי האימות של טענת הנכוֹנוּת (assertion) של הקבוצה הראשונה לפי המדיניות, דפדפנים יוכלו לאחזר רשימות של קבוצות באמצעות תהליך עדכון.
לניסוי המקור יש מדיניות מוגדרת שאינה סופית, אבל סביר להניח שהעקרונות יישארו ללא שינוי:
- הדומיינים בקבוצה של הצד הראשון חייבים להיות בבעלות אותו ארגון ובהפעלה שלו.
- הדומיינים צריכים להיות ניתנים לזיהוי כקבוצה.
- לדומיינים צריכה להיות מדיניות פרטיות משותפת.
איך מגדירים קבוצה של צד ראשון
אחרי שתזהו את החברים ואת הבעלים של הצד הראשון בארגון, תצטרכו לשלוח את הקבוצה המוצעת לאישור. התהליך המדויק עדיין נמצא בדיון.
כדי להצהיר על קבוצה של צד ראשון, משאבי 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. - קובצי cookie מסוג
SamePartyלא יכולים לכלול אתSameSite=Strict.
יש הוראת 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 - דומיינים של Sandbox שמשתמשים אף פעם לא יוצרים איתם אינטראקציה ישירה, אבל קיימים מטעמי אבטחה:
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 בסביבה פעילה כדי לראות איך קבוצה של נתונים מאינטראקציה ישירה (First-Party) תשפיע על קובצי ה-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
האפשרות השנייה דורשת יותר עבודה, אבל מאפשרת להפריד לגמרי את תקופת המקור מהפונקציונליות הקיימת ומאפשרת לבדוק באופן ספציפי את השילוב של 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 מסתמכים לעיתים קרובות על קובצי cookie של צד שלישי כדי לספק למשתמשים חוויית כניסה חלקה יותר. זה תרחיש תקף לדוגמה, אבל הוא לא מתאים לקבוצות של דומיינים של צד ראשון כי יש הבדל ברור בין הארגונים. הצעות מוקדמות כמו WebID בודקות דרכים להפעיל תרחישים לדוגמה כאלה.