כדאי להתכונן להוצאה משימוש של קובצי Cookie של צדדים שלישיים

המדריך הזה יעזור לכם להבין את ההשפעה של הפסקת התמיכה של Chrome בקובצי Cookie של צד שלישי על התוסף שלכם, ואת השינויים שצריך לבצע בו.

סקירה כללית

ב-4 בינואר 2024, השקנו ב-Chrome את התכונה חסימת מעקב, שמגבילה את הגישה של אתרים לקובצי Cookie של צד שלישי (3P) כברירת מחדל, אצל 1% מהמשתמשים. בתחילת 2025, ב-Chrome צפויים להפסיק את השימוש בקובצי Cookie של צד שלישי באופן מלא.

לפחות שני תהליכים שעוברים משתמשים מושפעים בתוספים ל-Classroom:

1. תהליך הכניסה היחידה (SSO) של Google
2. פתיחת משתמשים בכרטיסיות חדשות

כניסה יחידה (SSO) של Google

במהלך תהליך הכניסה באמצעות SSO של Google, המשתמשים מועברים לתיבת דו-שיח כדי להיכנס לחשבון Google שלהם ולתת הסכמה לשיתוף נתונים.

איור 1. הדמיה של שלושה הקשרים שונים של קובצי Cookie במהלך כניסה יחידה (SSO) מתוך iframe: ‏(1) אפליקציית Classroom ברמה העליונה, ‏(2) iframe מוטמע של צד שלישי (DavidPuzzle ב-localhost במקרה הזה) ו-‏(3) תיבת הדו-שיח של OAuth ברמה העליונה.

בהטמעה רגילה של תוסף, קובץ Cookie זמני מוגדר בסיום תהליך הכניסה הזה. ה-iframe של התוסף, שנמצא בהקשר מוטמע, נטען מחדש, ועכשיו הוא כולל את קובץ ה-Cookie הזמני, כך שהמשתמש יכול לגשת לסשן המאומת שלו. עם זאת, כשקובצי Cookie של צד שלישי מושבתים, אתרים בהקשר מוטמע כמו iframe של תוסף לא יכולים לגשת לקובצי Cookie מההקשרים ברמה העליונה שלהם. בתוספים ל-Classroom, המשתמש לא יכול לגשת לסשן המאומת שלו, והוא נתקע בלולאת כניסה.

ביישומים שמגדירים את קובץ ה-Cookie של הסשן בהקשר של iframe מוטמע, אפשר לצמצם את הבעיה באמצעות CHIPS API, שמאפשר לאתרים מוטמעים להגדיר קובצי Cookie מחולקים ולגשת אליהם (קובצי Cookie שמקבלים מפתח גם מהדומיין המטמיע וגם מהדומיין המוטמע). עם זאת, הטמעות שמגדירות את קובץ Cookie זמני בהקשר ברמה העליונה של תיבת הדו-שיח לכניסה לא יכולות לגשת לקובץ ה-Cookie שלא חולק במאפיין iframe, ולכן הכניסה נמנעת.

כרטיסיות חדשות

מסיבות דומות, אם למשתמש יש סשן מאומת שמבוסס על קובצי Cookie ב-iframe של תוסף, וה-iframe מפעיל את המשתמש בכרטיסייה חדשה ברמה העליונה לפעילות, הכרטיסייה ברמה העליונה לא יכולה לגשת לקובץ ה-Cookie הזמני של הסשן שחולק מה-iframe. ההגדרה הזו מונעת את השמירה של מצב הסשן של iframe בפעילות של הכרטיסייה החדשה, ועשויה לחייב את המשתמש להיכנס שוב לכרטיסייה החדשה, למשל. CHIPS API לא יכול לפתור את הבעיה הזו, כי קובצי Cookie של iframe מחולקים לא נגישים בהקשר של רמה עליונה.

פעולות של מפתחים

יש כמה פעולות שכדאי לבצע כדי לוודא שהתוסף ימשיך לפעול כמו שצריך כש-Chrome יפסיק לתמוך בקובצי Cookie של צד שלישי.

1. בודקים את השימוש בקובצי Cookie של צד שלישי בתהליכים החשובים שהמשתמשים עוברים בתוסף. באופן ספציפי, מומלץ לבצע בדיקה עם השבתה של קובצי Cookie של צד שלישי כדי להעריך את ההשפעה על ההטמעה הספציפית שלכם.

2. מידע נוסף על Storage Access API לכל ההטמעות של תוספים, מומלץ להשתמש ב-API‏ Storage Access‏ (SAA). SAA מאפשרת ל-iframes לגשת לקובצי ה-Cookie שלהם מחוץ להקשר של ה-iframe. התכונה SAA זמינה היום ב-Chrome, והיא נתמכת באפליקציית Classroom.

3. הפעלת FedCM. בנוסף, אם אתם משתמשים ב-GIS, בספריית הכניסה באמצעות חשבון Google, ההמלצה הרשמית של צוות הזהויות היא להפעיל את FedCM. הפתרון הזה לא מחליף את היכולות של קובצי Cookie של צד שלישי, אבל בסופו של דבר הוא יידרש ב-GIS כחלק מהוצאה משימוש של קובצי Cookie של צד שלישי. התכונה FedCM זמינה היום ב-Chrome ונתמכת ב-Classroom, אבל ההתנהגות והתכונות שלה עדיין בפיתוח ואנחנו פתוחים לקבלת משוב.

4. מעבר ל-GIS. אם אתם משתמשים בספריית GSIv2 שהוצאה משימוש, שנקראת גם ספריית הכניסה לחשבון Google, מומלץ מאוד לעבור ל-GIS, כי לא ברור אם תהיה תמיכה ב-GSIv2 בעתיד.

5. שליחת בקשה להארכת ניסיון בתכונה שהוצאה משימוש ‫Chrome מציע ניסיון לפני הוצאה משימוש כדי לאפשר לתרחישי שימוש שלא קשורים לפרסום לדחות את ההשפעות של ההוצאה משימוש של קובצי Cookie של צד שלישי. אם הבקשה תאושר, תקבלו טוקן שתוכלו להשתמש בו בתוסף כדי להמשיך להפעיל קובצי Cookie של צד ג' עבור המקור שלכם עד שנת 2024, בזמן שאתם עוברים לפתרון לטווח ארוך כמו SAA. אחרי ההפעלה, תתבקשו לספק מזהה באג או קישור לדוח על תקלה. הצוות שלנו כבר הגיש את הבאג הזה לגבי תוספים ל-Classroom, ואפשר לספק את הבאג הזה.