לארגונים רבים יש אתרים קשורים עם שמות דומיינים שונים, כגון
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 לצד ראשון. - הקשר בין אתרים עם
SameSite=Noneהופך את קובץ ה-cookie לצד שלישי.
עם זאת, זה לא תמיד כל כך ברור. נניח ש-brandx.site הוא נסיעה
אתר להזמנות, והם משתמשים גם ב-fly-brandx.site וב-drive-brandx.site כדי
טיסות והשכרת רכב נפרדות. במהלך הזמנת מסע אחד, מבקרים
לעבור בין האתרים האלה כדי לבחור את האפשרויות השונות — הם מצפים
'עגלת קניות' של אפשרויות שיישארו בכל האתרים האלה. brandx.site
מנהל את הסשן של המשתמש באמצעות קובץ cookie של SameSite=None כדי לאפשר זאת
בהקשרים בין אתרים. החיסרון הוא עכשיו שלקובץ ה-cookie אין אתרים מצטלבים
בקשת הגנה מפני זיוף (CSRF) אם evil.site כוללת בקשה ל-
brandx.site, הקובץ יכלול את קובץ ה-cookie הזה.
קובץ ה-cookie נמצא בכמה אתרים, אבל כל האתרים האלה נמצאים בבעלות ובהפעלה של אותו אדם של הארגון. המבקרים גם מבינים שמדובר באותו ארגון ורוצים אותו סשן, במילים אחרות – זהות משותפת לכולם.
המדיניות בנושא דומיינים של צד ראשון
קבוצות של צד ראשון מציעות
שיטה להגדיר בצורה מפורשת את הקשר הזה על פני מספר אתרים
נמצאים בבעלות ובהפעלה של אותו גורם. הפעולה הזו תאפשר לאפליקציה brandx.site:
להגדיר את הקשר הישיר שלו עם fly-brandx.site,
drive-brandx.site וכן הלאה.
מודל הפרטיות שמוביל ההצעות השונות של ארגז החול לפרטיות מבוססות על הקונספט של חלוקה למחיצות (partitioning) זהות למניעת מעקב בין אתרים – יצירת גבול בין אתרים מגביל את הגישה לכל מידע שיכול לשמש לזיהוי משתמשים.
אפשרות ברירת המחדל היא חלוקה למחיצות (partitioning) לפי אתר, אבל האפשרות הזו פותרת בעיות רבות של צדדים שלישיים
תרחישים לדוגמה, הדוגמה brandx.site מראה שאינטראקציה ישירה (First-Party) יכולה להיות גדולה יותר
מאשר אתר אחד בלבד.
חלק חשוב בהצעה של הדומיינים של הצד הראשון הוא להבטיח שהמדיניות בדפדפנים שונים כדי למנוע ניצול לרעה או שימוש לרעה. לדוגמה, אסור לשייך לדומיינים של צד ראשון לאפשר חילופי מידע על משתמשים באתרים לא קשורים, או בקבוצות של אתרים שאינם בבעלות של אותה יישות. הרעיון הוא להבטיח 'דומיינים של צד ראשון' ממופים למשהו שאנשים מבינים כאינטראקציה ישירה (First-Party), לא יכול לשמש לשיתוף זהות בין צדדים שונים.
אחת מהדרכים האפשריות לרישום קבוצה של צד ראשון באתר לשלוח את קבוצת הדומיינים שהם מציעים לכלי מעקב ציבורי (כמו במאגר ייעודי של 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 כשההקשר שלו הוא חלק
מוגדר כהקשר ברמה העליונה.
המשמעות היא שאם קובץ ה-cookie הזה מוגדר על ידי brandx.site:
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אם לא.
יש כמה דרישות נוספות:
SamePartyקובצי cookie חייבים לכלולSecure.SamePartyקובצי cookie לא יכולים לכלולSameSite=Strict.
חלה דרישה על Secure כי השינוי הזה עדיין חוצה-אתרים וצריך לצמצם את המקרים האלה
על ידי הקפדה על חיבורים מאובטחים (HTTPS). באופן דומה, מאחר שזאת
קשר בין אתרים, SameSite=Strict לא חוקי כי הוא עדיין מאפשר
הגנת CSRF מבוססת-אתר בתוך קבוצה.
אילו תרחישים לדוגמה מתאימים לדומיינים של צד ראשון?
דומיינים של צד ראשון מתאימים למקרים שבהם ארגון צריך ליצור המשותפת באתרים שונים ברמה עליונה. זהות משותפת במקרה הזה כלומר, מפתרון מלא של כניסה יחידה (SSO) ועד הצורך עדיפות באתרים שונים.
ייתכן שלארגון שלכם יש דומיינים שונים ברמה העליונה של:
- דומיינים של אפליקציות:
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
איך אפשר להיות מעורבים?
אם יש לך קבוצת אתרים שתואמת לקריטריונים שלמעלה, יש מספר אפשרויות להשתתפות. הכי קשה לקרוא ולהצטרף את הדיון על שתי ההצעות:
- דיון בקבוצת קהילה בנושא פרטיות שהוגדרה על ידי צד ראשון
- דיון לגבי מאפיינים של קובצי Cookie מסוג SameParty
במהלך שלב הבדיקה ניתן לנסות את הפונקציונליות באמצעות
דגל שורת הפקודה --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 בתאריך
הנה שתי תבניות שכדאי לשקול.
אפשרות 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
את קובץ ה-cookie cname-fps בבקשה מרובה-אתרים אם האתרים המעורבים נמצאים
מוגדר והדפדפן נמצא בגרסת המקור לניסיון. כדאי להתייחס לגישה הזו כמו
השקה בו-זמנית של תכונה מעודכנת לפני השבתת התכונה הקודמת
.
למה יכול להיות שאין צורך בקבוצה של צד ראשון?
עבור רוב האתרים, גבולות האתר הם מקום מקובל לשרטוט
החלוקה לגבולות של המחיצה או הפרטיות. זה המסלול שהוצע עם
CHIPS (קובצי Cookie עם חלוקה עצמאית למחיצות)
מדינה (State), שתתן לאתרים אפשרות להביע הסכמה
דרך המאפיין Partitioned כדי לשמור את האתרים הקריטיים האלה
הטמעות, משאבים, ממשקי API ושירותים, תוך מניעת דליפה של זיהוי
מידע בכמה אתרים.
נקודות נוספות שכדאי להביא בחשבון כדי להבטיח שהאתר שלכם יהיה תקין בלי שתצטרכו קבוצה:
- האירוח שלכם מתארח במקורות שונים, ולא באתרים שונים. בדוגמה שלמעלה,
אם ל-
brandx.siteהיוfly.brandx.siteו-drive.brandx.site, אז אלה הם תת-דומיינים שונים שפועלים באותו אתר. קובצי ה-Cookie יכולים להשתמשSameSite=Laxואין צורך בהגדרה. - אתם מספקים הטמעות של צד שלישי באתרים אחרים. במבוא, לדוגמה
סרטון מ-
video.siteשמוטמע ב-my-blog.siteהוא סרטון של צד שלישי ברור לחלק. האתרים מופעלים על ידי ארגונים שונים והמשתמשים רואים אותם כישויות נפרדות. שני האתרים האלה לא יכולים להיות יחד. - אתם מספקים שירותי כניסה חברתיים של צד שלישי. ספקי זהויות שמשתמשים דברים כמו OAuth או OpenId Connect מסתמכים לעיתים קרובות על קובצי Cookie של צד שלישי חוויית כניסה חלקה יותר למשתמשים. זה תרחיש לדוגמה נכון, אבל הוא לא מתאים לדומיינים של צד ראשון, כי יש הבדל ברור בין הארגונים. הצעות מוקדמות כמו WebID הן בחינת דרכים להפעלת תרחישים לדוגמה כאלה.