אפשר למפתחים לצרף קובץ cookie לאחסון ש'מחולק למחיצות', באמצעות מאגר נפרד של קובצי cookie לכל אתר ברמה עליונה.
סטטוס הטמעה
- התכונה נתמכת כברירת מחדל ב-Chrome מגרסה 114 ואילך.
- גרסת המקור לניסיון, שהושלמה, הייתה זמינה בגרסאות 100 עד 116 של Chrome.
- קוראים את המאמרים כוונת ניסוי וכוונה לשלוח.
מה זה CHIPS?
קובצי Cookie בעלי מצב של מחיצות עצמאיות (CHIPS) מאפשר למפתחים לצרף קובץ Cookie לאחסון מחולק למחיצות, עם מאגרי Cookie נפרדים לכל אתר ברמה עליונה, לשיפור הפרטיות והאבטחה של המשתמשים.
ללא חלוקה למחיצות, קובצי cookie של צד שלישי יכולים לאפשר לשירותים לעקוב אחר משתמשים ולאחד את המידע שלהם מאתרים רבים ברמה העליונה שאינם קשורים. התהליך הזה נקרא 'מעקב באתרים שונים'.
דפדפנים נמצאים בעיצומו של הוצאה משימוש בהדרגה של קובצי cookie של צד שלישי שאינם מחולקים למחיצות. לכן, CHIPS , Storage Access API וקבוצות של אתרים קשורים יהיו הדרך היחידה לקרוא ולכתוב קובצי cookie מהקשרים בין אתרים, כמו iframe, כאשר קובצי cookie של צד שלישי חסומים.
CHIPS כולל מאפיין חדש של קובצי Cookie, Partitioned
, שתומך בקובצי Cookie מאתרים שונים שמחולקים למחיצות לפי הקשר ברמה עליונה.
כותרת Set-cookie:
Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;
JavaScript:
document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"
קובץ cookie של צד שלישי שחולק למחיצות (Partitions) קשור לאתר ברמה העליונה שבו הוא מוגדר בהתחלה, ולא ניתן לגשת אליו ממקום אחר. כך ניתן לקרוא קובצי cookie שהוגדרו על ידי שירות של צד שלישי רק באותו הקשר מוטמע של האתר ברמה העליונה שבו הם הוגדרו במקור.
כשמשתמשים בקובצי cookie עם חלוקה למחיצות, כשמשתמש מבקר באתר א' ותוכן מוטמע מאתר ג' מגדיר קובץ cookie עם המאפיין 'מחיצות', קובץ ה-cookie נשמר במאגר שמחולק למחיצות (Partitions) שיועד רק לקובצי cookie שהאתר ג' מגדיר כשהוא מוטמע באתר א'. הדפדפן ישלח את קובץ ה-cookie הזה רק כאשר האתר ברמה העליונה הוא A.
כאשר משתמש מבקר באתר חדש, למשל באתר ב', מסגרת C מוטמעת לא תקבל את קובץ ה-cookie שהוגדר כש-ג' הוטמע באתר א'.
אם משתמש מבקר באתר ג' כאתר ברמה העליונה, גם קובץ ה-cookie שחולק למחיצות ש-C הגדיר כשהוא הוטמע ב-A לא יישלח בבקשה הזו.
תרחישים לדוגמה
לדוגמה, ייתכן שהאתר retail.example
ירצה לעבוד עם שירות צד שלישי support.chat.example
כדי להטמיע תיבת צ'אט לתמיכה באתר שלו. הרבה שירותי צ'אט שניתנים להטמעה כיום מסתמכים על קובצי cookie כדי לשמור מצבים.
בלי אפשרות להגדיר קובץ cookie חוצה-אתרים, support.chat.example
יצטרך למצוא שיטות חלופיות לשמירת מצבים, ולרוב מורכבות יותר. לחלופין, צריך להטמיע אותו בדף ברמה העליונה שיש בו סיכונים, כי הוא מאפשר לסקריפט support.chat.example
לקבל הרשאות מורחבות ב-retail.example, כמו היכולת לגשת לקובצי cookie של אימות.
CHIPS מספק אפשרות קלה יותר להמשיך להשתמש בקובצי Cookie מאתרים שונים, ללא הסיכונים המשויכים לקובצי Cookie שאינם מחולקים למחיצות.
תרחישים לדוגמה ל-CHIPS כוללים תרחישים שבהם במשאבי משנה חוצי-אתרים נדרש מושג מסוים של סשן או מצב קבוע שכולל פעילות של משתמש באתר אחד ברמה העליונה, למשל:
- הטמעות צ'אט של צד שלישי
- הטמעות מפות של צד שלישי
- הטמעות תשלומים של צד שלישי
- איזון עומסים של CDN במשאבי משנה
- ספקי מערכות ניהול תוכן ללא GUI
- דומיינים של ארגז חול להצגת תוכן לא מהימן של משתמשים (כמו googleusercontent.com ו-githubusercontent.com)
- דומיינים מסוג CDN של צד שלישי שמשתמשים בקובצי cookie כדי להציג תוכן שהגישה אליו נשלטת על ידי סטטוס האימות באתר של הצד הראשון (לדוגמה, תמונות פרופיל באתרי מדיה חברתית שמתארחים ב-CDN של צד שלישי)
- מסגרות ממשק קצה שמסתמכות על ממשקי API מרוחקים באמצעות קובצי cookie בבקשות שלהם
- מודעות מוטמעות שצריכות להיות ברמת המדינה עבור בעל התוכן הדיגיטלי (לדוגמה, תיעוד ההעדפות של המשתמשים לגבי המודעות באתר הזה)
למה ב-CHIPS משתמשים במודל חלוקה למחיצות (partitioning) להבעת הסכמה
מכיוון שדפדפנים מוציאים משימוש בהדרגה קובצי cookie של צד שלישי שאינם מחולקים למחיצות, ניסיתם כמה גישות נוספות לחלוקה למחיצות.
לפי ההודעה של Firefox, הם מחלקים את כל קובצי ה-cookie של צד שלישי כברירת מחדל במצב ETP Strict ובמצב גלישה פרטית. כך שכל קובצי ה-cookie באתרים שונים יפוצלו לפי האתר ברמה העליונה. עם זאת, חלוקה למחיצות של קובצי cookie ללא בקשת הצטרפות של צד שלישי עלולה לגרום לבאגים בלתי צפויים, מאחר שחלק מהשירותים של צד שלישי בנו שרתים שמצפים לקובץ cookie של צד שלישי ללא מחיצה.
מערכת Safari ניסתה בעבר לפצל קובצי cookie למחיצות על סמך היוריסטיקה, אבל בסופו של דבר בחרה לחסום אותם לחלוטין, והסיבה לכך היא בלבול של המפתח. לאחרונה, Safari הביע עניין במודל מבוסס-הצטרפות.
ההבדל בין CHIPS לבין הטמעות קיימות של קובצי cookie שחולקו למחיצות הוא ההסכמה של צד שלישי. כדי שקובצי cookie של צד שלישי (ללא חלוקה למחיצות) יצאו משימוש, צריך להגדיר לקובצי cookie מאפיין חדש כדי להישלח לבקשות של צדדים שלישיים.
אמנם קיימים קובצי cookie של צד שלישי, אך המאפיין Partitioned
מאפשר הסכמה להתנהגות מגבילה ומאובטחת יותר של קובצי cookie. CHIPS הוא צעד חשוב שעוזר לשירותים לעבור בצורה חלקה לעתיד ללא קובצי cookie של צד שלישי.
תכנון טכני של חלוקה למחיצות של קובצי cookie
כיום, קובצי cookie מוגדרים לפי שם המארח או הדומיין של האתר שהגדיר אותם, כלומר, מפתח המארח שלהם.
לדוגמה, עבור קובצי cookie מ-https://support.chat.example
, מפתח המארח הוא ("support.chat.example")
.
בקטע CHIPS, קובצי cookie שמאפשרים חלוקה למחיצות (partitioning) יוקצו פעמיים במפתח המארח ובמפתח המחיצה שלהם.
מפתח מחיצה של קובץ cookie הוא האתר (סכמה ודומיין שניתן לרשום) של כתובת ה-URL ברמה העליונה שהדפדפן ביקר בו בתחילת הבקשה, לנקודת הקצה שהגדירה את קובץ ה-cookie.
בדוגמה הקודמת, https://support.chat.example
מוטמעת ב-https://retail.example
, כתובת ה-URL ברמה העליונה היא https://retail.example
.
במקרה כזה, מפתח המחיצה הוא ("https", "retail.example")
.
באופן דומה, מפתח מחיצה של בקשה הוא האתר של כתובת האתר ברמה העליונה שהדפדפן מבקר בו בתחילת הבקשה. דפדפנים חייבים לשלוח קובץ cookie עם המאפיין Partitioned
רק בבקשות עם מפתח מחיצה זהה לזה של קובץ ה-cookie.
כך נראה מפתח קובץ ה-cookie בדוגמה קודמת לפני ואחרי CHIPS.
לפני CHIPS
key=("support.chat.example")
אחרי CHIPS
key={("support.chat.example"),("https", "retail.example")}
תכנון אבטחה
כדי לעודד נוהלי אבטחה מוצלחים, כשמשתמשים ב-CHIPS, קובצי cookie מוגדרים רק על ידי פרוטוקולים מאובטחים ונשלחים באמצעותם.
- קובצי cookie שחולקו למחיצות חייבים להיות מוגדרים באמצעות
Secure
. - מומלץ להשתמש בקידומת
__Host
כשמגדירים קובצי cookie מחולקים למחיצות, כדי שהם יהיו מקושרים לשם המארח (ולא לדומיין שניתן לרשום).
דוגמה:
Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
חלופות ל-CHIPS
Storage Access API וקבוצות של אתרים קשורים (RWS) המשויכים אליו הם מנגנונים של פלטפורמת אינטרנט שמאפשרים גישה מוגבלת לקובצי cookie באתרים שונים למטרות ספציפיות וגלויות למשתמשים.
אלה חלופות לחלוקה למחיצות (CHIPS) באמצעות חלוקה למחיצות (CHIPS) שבה נדרשת גישה לקובצי בישול בכמה אתרים, ללא חלוקה למחיצות.
כדאי לשקול את השימוש ב-Storage Access API ואת קבוצות האתרים הקשורים במצבים שבהם אותו קובץ ה-cookie צריך להיות זמין לשירות שמוטמע במספר אתרים קשורים.
CHIPS מספק את היכולת של שירות לפעול כרכיב מבודד במספר אתרים, שבהם אותו קובץ Cookie לא חייב להיות זמין במספר אתרים. אם השירות מגדיר קובץ cookie עם חלוקה למחיצות, מפתח המחיצה שלו יהיה האתר ברמה העליונה, וקובץ ה-cookie לא יהיה זמין לאתרים אחרים שמשתמשים בשירות גם כן.
העיצוב של קבוצות האתרים הקשורים מסתמך על Storage Access API ולא משתלב עם חלוקה למחיצות CHIPS. אם יש לכם תרחיש לדוגמה המסתמך על מחיצת קובצי cookie משותפת באתרים בתוך RWS, תוכלו לספק דוגמאות ומשוב על הבעיה ב-GitHub.
הדגמה (דמו)
בהדגמה הזו מוסבר איך פועלים קובצי cookie עם חלוקה למחיצות, ואיך בודקים אותם בכלי הפיתוח.
אתר א' מטמיע iframe מאתר ב' שמשתמש ב-JavaScript כדי להגדיר שני קובצי cookie: קובץ cookie עם מחיצה וללא מחיצה. אתר ב' מציג את כל קובצי ה-Cookie שניתן לגשת אליהם מאותו מיקום באמצעות document.cookie
.
כשקובצי cookie של צד שלישי חסומים, אתר ב' יוכל להגדיר את קובץ ה-cookie ולגשת אליו רק עם המאפיין Partitioned
בהקשר שבין כמה אתרים.
כאשר קובצי Cookie של צד שלישי מותרים, גם אתר ב' יכול להגדיר את קובץ ה-Cookie ללא מחיצה ולגשת אליו.
דרישות מוקדמות
- Chrome מגרסה 118 ואילך.
- צריך להיכנס אל
chrome://flags/#test-third-party-cookie-phaseout
ולהפעיל את ההגדרה הזו
שימוש בכלי הפיתוח כדי לבדוק קובצי cookie שחולקו למחיצות
- נכנסים לכתובת https://chips-site-a.glitch.me.
- מקישים על
Control+Shift+J
(או עלCommand+Option+J
ב-Mac) כדי לפתוח את כלי הפיתוח. - לוחצים על הכרטיסייה Application (אפליקציה).
- עוברים אל Application (אפליקציה) > 'אחסון' > 'קובצי cookie'.
- לוחצים על
https://chips-site-b.glitch.me
.
כלי הפיתוח יציגו את כל קובצי ה-Cookie מהמקור שנבחר.
אתר ב' יכול להגדיר את קובץ ה-cookie שחולק למחיצות רק בהקשר חוצה-אתרים, קובץ ה-cookie שלא מחולק למחיצות ייחסם:
- אמור להופיע
__Host-partitioned-cookie
עם מפתח המחיצה של האתר ברמה העליונהhttps://chips-site-a.glitch.me
.
- לוחצים על מעבר לאתר ב'.
- בכלי הפיתוח, עוברים אל Application (אפליקציה) > 'אחסון' > 'קובצי cookie'.
- לוחצים על
https://chips-site-b.glitch.me
.
בתרחיש הזה, מאחר שאתם נמצאים באתר ב' בהקשר ברמה העליונה, יש לו אפשרות להגדיר את שני קובצי ה-cookie ולגשת אליהם:
- מפתח המחיצה של
unpartitioned-cookie
ריק. - לקובץ cookie של
__Host-partitioned-cookie
יש את מפתח המחיצהhttps://chips-site-b.glitch.me
.
אם חוזרים לאתר א', האתר unpartitioned-cookie
יאוחסן עכשיו בדפדפן, אבל לא תהיה גישה אליו מאתר א'.
- לוחצים על מעבר לאתר א'.
- לוחצים על הכרטיסייה Network.
- לוחצים על
https://chips-site-b.glitch.me
. - לוחצים על הכרטיסייה Cookies (קובצי Cookie).
באתר A אמור להופיע __Host-partitioned-cookie
עם מפתח המחיצה של האתר ברמה העליונה https://chips-site-a.glitch.me
.
אם מסמנים את האפשרות הצגת בקשות לקובצי cookie שסוננו, כלי הפיתוח יראו שקובץ ה-cookie ללא מחיצות חסום, מודגש בצהוב עם הסבר קצר: "קובץ ה-cookie הזה נחסם עקב העדפות המשתמש".
בקטע Application (אפליקציה) > Storage > Cookie, לחיצה על https://chips-site-b.glitch.me
תציג:
unpartitioned-cookie
עם מפתח המחיצה הריק.- קובץ Cookie מסוג
__Host-partitioned-cookie
עם מפתח המחיצהhttps://chips-site-a.glitch.me
.
מחיקת קובצי Cookie
כדי לאפס את ההדגמה, מנקים את כל קובצי ה-Cookie של האתר:
- מקישים על
Control+Shift+J
(או עלCommand+Option+J
ב-Mac) כדי לפתוח את כלי הפיתוח. - לוחצים על הכרטיסייה Application (אפליקציה).
- עוברים אל Application (אפליקציה) > 'אחסון' > 'קובצי cookie'.
- לוחצים לחיצה ימנית על
https://chips-site-b.glitch.me
. - לוחצים על ניקוי.
משאבים
- GitHub: קוראים את המסביר, מעלים שאלות ועוקבים אחר הדיון.
- תמיכה למפתחים: אפשר לשאול שאלות ולהצטרף לדיונים בנושא מאגר התמיכה למפתחים של ארגז חול לפרטיות.