לקובצי cookie של צד שלישי יש שימושים רבים, אבל הם גם כלי מפתח למעקב בכמה אתרים.
הצוות של Chrome מציע חוויה חדשה של בחירה למשתמש עם קובצי Cookie של צד שלישי. עליכם להכין את האתר למשתמשים שבוחרים לגלוש בלי קובצי Cookie של צד שלישי.
בדף הזה מפורט מידע על פתרונות לשמירה על הפרטיות בתרחישים מוטמעים שבעבר הסתמכו על קובצי cookie של צד שלישי, וכן אסטרטגיות שיעזרו לכם לבחור את הפתרון שמתאים ביותר לצרכים שלכם.
שירותים מוטמעים, או מוטמעים, כוללים תוכן של צד שלישי (כמו סרטונים ומפות), רכיבים אינטראקטיביים (כמו צ'אט, מערכות תגובות או שירותי תשלום), שירותי כניסה ועוד.
רוב העבודה להעברה מקובצי cookie של צד שלישי צריכה להתבצע על ידי מפתחי התוספים, ולא על ידי אתרים שמארחים תוספים. המדריך הזה יעסוק בעיקר בפתרונות למפתחים שיוצרים שירותים מוטמעים.
אם האתר שלכם מסתמך על הטמעה שמשתמשת בקובצי cookie של צד שלישי, חשוב לבדוק ולבחון את התהליכים הקשורים להטמעה, ופנו לספקים של ההטמעה אם תגלו בעיות.
בדיקה ובדיקה של תהליכי השימוש של המשתמשים שקשורים להטמעה
הדרך הטובה ביותר לקבוע אם התגים המוטמעים מושפעים מקובצי cookie של צד שלישי היא לבדוק את תהליכי השימוש בתגים המוטמעים של הצד השלישי כשהדגל לבדיקת קובצי cookie של צד שלישי מופעל.
אחרי שתגבילו את קובצי ה-Cookie של צד שלישי, כדאי לבדוק את התרחישים הנפוצים הבאים של הטמעה:
- ווידג'טים של צ'אט: האם אתם יכולים להתחיל שיחת צ'אט? יש לך אפשרות לרענן את הדף בלי לאבד את הסשן? האם יש לך אפשרות לנווט לדפים אחרים ולשמור על הסשן?
- תוכן מוטמע: האם אתם יכולים לצפות בתוכן וידאו או בתוכן מוטמע אחר? האם העדפות המשתמש, כמו שפה או כתוביות, נשמרות? האם המודעות מוצגות כצפוי, למשל, לא מוצגות מודעות למנויי פרימיום?
- התחברות: האם אפשר להתחבר – כולל התחברות באמצעות כניסה יחידה (SSO) – להטמעות שתומכות בכך? האם הם נשמרים במהלך טעינת מחדש של דפים וניוווט לדפים שמשתמשים באותם הטמעות?
- ווידג'טים של תגובות: האם אתם יכולים לפרסם תגובות, לסמן אותן ב'לייק' ולהצביע עליהן למעלה?
- פתרונות תשלום מוטמעים: האם אתם מצליחים להשלים תשלומים?
בקטעים הבאים מפורט מידע ספציפי יותר על ההשפעה האפשרית על תהליכים אלה.
תרחישים נפוצים לדוגמה
יש כמה ממשקי API שאפשר להשתמש בהם לרכיבים מוטמעים שבעבר היו תלויים בקובצי cookie של צד שלישי. בטבלה הבאה מפורטים תהליכי עבודה נפוצים וממשקי ה-API המומלצים לשימוש, כסיכום ברמה גבוהה. בקטעים הבאים נסביר את הנימוקים להמלצות האלה.
| תרחיש לדוגמה | ממשק API מומלץ לשימוש בקובצי cookie של צד שלישי |
|---|---|
| ווידג'ט של Chat | CHIPS |
| הטמעת מפות | CHIPS |
| דומיינים של סביבות חול לתוכן משתמש לא מהימן (כמו googleusercontent.com ו-githubusercontent.com) שצריך להגדיר ברמת המדינה לכל בעל תוכן דיגיטלי |
CHIPS |
| מודעות מוטמעות שצריך להגדיר ברמת המדינה לכל בעל תוכן דיגיטלי | CHIPS |
| כניסה באמצעות ספק זהויות | FedCM |
| הטמעה שמתארחת במקור שונה אבל קשור. | Storage Access API עם קבוצות של אתרים קשורים |
| תוכן מוטמע עם העדפות שמבוססות על התחברות (כמו תוכן וידאו ללא מודעות או העדפות לגבי שפה או כתוביות) |
Storage Access API |
| ווידג'ט של תגובות ברשתות חברתיות שדורש התחברות | Storage Access API |
בחירת ה-API לשימוש בתרחישי שימוש של צד שלישי מוטמע
בקטע הזה נסביר איך לבחור ממשק API חלופי מתאים, ונספק הסבר על ממשקי ה-API המומלצים.
תרשים הזרימה הבא יעזור לכם לבחור מבין האפשרויות הזמינות:
בתרשים התהליך מופיעות שלוש שאלות עיקריות, ונבחן אותן בפירוט ונראה למה מומלץ להשתמש ב-API מסוים בכל מקרה.
1. האם קובצי ה-cookie ספציפיים לאתר ההטמעה?
הרבה פריטים מוטמעים של צד שלישי משמשים באופן עצמאי באתרים שאינם קשורים כלל. לדוגמה, לפעמים צריך קובצי cookie כדי שווידג'טים של צ'אט לתמיכת לקוחות יפעלו, אבל אין צורך לשתף את קובצי ה-cookie האלה בין שתי ארגונים שונים לחלוטין, שבמקרה משתמשים באותו פתרון של ווידג'ט צ'אט. למעשה, בחלק גדול מהמקרים עדיף לא לאפשר כלל שיתוף של קובצי Cookie.
אם אתם מספקים שירות הטמעה של צד שלישי לאתרים אחרים והוא מסתמך על קובצי cookie, כדאי לבדוק אם קובצי ה-cookie האלה ספציפיים לשירות באתר שבו הם מוטמעים. האם הם משותפים על ידי מופעים של ההטמעה שלכם באתרים אחרים?
אם אין צורך לשתף את קובצי ה-cookie, האפשרות הקלה ביותר היא חלוקת קובצי ה-cookie באמצעות CHIPS. ה-API הזה מקשר קובצי cookie של צד שלישי לאתר ברמה העליונה, במקום לאפשר להם להיות משותפים בין כל האתרים שמשתמשים באותו הטמעה של צד שלישי. קל להטמיע את CHIPS כי צריך רק להוסיף מאפיין Partitioned נוסף לקובצי ה-cookie הקיימים. כך השירותים המוטמעים עדיין יכולים לשמור את המצב, אבל נפח האחסון המשותף בין אתרים שמאפשר מעקב בין אתרים יוסר.
בנוסף, בעלי אתרים צריכים לבדוק אם הם משתמשים בקובצי cookie מהסיבות הנכונות. צריך להשתמש בקובצי cookie רק כשהם מוגדרים או כשצריך לשלוח אותם עם בקשות HTTP. אם זה לא המצב, והשימוש בקובצי cookie הוא רק כאפשרות אחסון נוחה, כדאי לשקול להשתמש במקום זאת בממשקי ה-API השונים לאחסון. כך הנתונים נשארים מקומיים כשאין צורך לשלוח אותם. ממשקי ה-API לאחסון כבר מחולקים למחיצות בכל הדפדפנים העיקריים, באופן דומה לחלוקה של קובצי cookie ב-CHIPS.
2. האם קובצי ה-Cookie הם של ספק זהויות של צד שלישי?
שימוש נפוץ בקובצי cookie של צד שלישי בתוכן מוטמע הוא כדי לספק יכולות כניסה שמנוהלות על ידי ספק כניסה של צד שלישי, כמו כניסה באמצעות חשבון Google. במקרה כזה, אי אפשר להשתמש בקובצי cookie עם חלוקה למחיצות.
Federated Credential Management (FedCM) הוא ממשק API ייעודי לתרחיש לדוגמה הזה, והוא פועל בלי קובצי Cookie של צד שלישי. אם ספק הזהויות תומך ב-FedCM, יכול להיות שלא תצטרכו להשתמש בקובצי cookie של צד שלישי.
מידע נוסף על טיפול בהשפעות של קובצי cookie של צד שלישי על תהליכי העבודה של כניסה לחשבון זמין במדריך הזהות.
3. האם קובצי ה-cookie משמשים במספר קטן של אתרים קשורים?
אם אף אחת מהאפשרויות הקודמות לא מתאימה כתחליף לקובצי cookie, תצטרכו לבדוק אם כדאי להפעיל מחדש את הגישה של קובצי cookie של צד שלישי להטמעה. אפשר להפעיל את האפשרות הזו בתרחישי שימוש ספציפיים ומבוקרים באמצעות Storage Access API. ה-API הזה מפעיל מחדש גישה מלאה לקובצי cookie של צד שלישי (בכפוף לאמצעי בקרה), ולכן זו האפשרות החזקה ביותר. לכן מומלץ להימנע מכך אם אפשר להשתמש בחלופה מגבילה יותר.
כדי להשתמש ב-Storage Access API, צריך לעמוד בכמה דרישות:
- המשתמש צריך לבקר באתר של התוכן המוטמע ברמה העליונה בעבר. לדוגמה, אם מטמיעים מערכת תגובות, המשתמש צריך גם לבקר באתר של מערכת התגובות הזו.
- כדי שניתן יהיה לשתף קובצי cookie, המשתמש צריך לבצע פעולה בתוכן המוטמע. המשמעות היא שייתכן שלא תהיה אפשרות לטעון את התוכן המוטמע המלא לפני אינטראקציה של משתמש.
- יכול להיות שהמשתמש יצטרך לאשר את שיתוף קובצי ה-cookie באמצעות חלון קופץ בדפדפן, במיוחד בפעם הראשונה ומדי פעם לאחר מכן.
- יכול להיות שיהיה צורך גם להגדיר באתר ההטמעה מאפיינים נוספים של ארגז חול.
ההגבלות האלה מבטיחות שהפעולה המשמעותית של הפעלה מחדש של קובצי Cookie של צד שלישי תתבצע רק כשהמשתמש והאתר מצפים לכך. עם זאת, בתרחישים מסוימים, יכול להיות שהפעולות של המשתמש יועברו על פניהן. לדוגמה, אם המשתמש אישר גישה לאחרונה, יכול להיות שלא יהיה צורך לבקש ממנו אישור מחדש למשך פרק זמן מסוים (כפי שמוגדר בדפדפן).
תרחיש נוסף שבו סביר להניח שהמשתמש מצפה לכך הוא באתרים קשורים. לדוגמה, ארגונים מסוימים משתמשים במספר מקורות שונים, שנחשבים כמקור חוצה-אתרים בדפדפן. לכן, השימוש בקובצי cookie בכל המקורות האלה נחשב כשימוש של צד שלישי. דוגמאות לכך הן מותגים עם אתרים ספציפיים למדינה (למשל example.com ו-example.co.uk) או אתרים ספציפיים למותג (למשל example.car ו-example.house).
במקרה כזה, כשיש מספר קטן של אתרים קשורים, אפשר להשתמש בקבוצות של אתרים קשורים. אתרים נשלחים ל-Chrome כדי שמערכת Chrome תדע שהם קשורים. כך אפשר לגשת ל-Storage Access API בצורה ידידותית יותר למשתמש, עם פחות הנחיות למשתמש.
באתרים לא קשורים שהם למעשה צדדים שלישיים, שבהם נדרשת גישה מלאה לקובצי cookie של צד שלישי כי ממשקי ה-API החלופיים לא מספיקים, השימוש ב-Storage Access API יהיה כפוף לדרישות ולהנחיות המלאות.
השוואה בין ממשקי ה-API השונים
לכל אחד מהפתרונות יש מאפיינים ומגבלות שונים במקצת, שמאפשרים לכם לבחור את הפתרון המתאים ביותר לתרחישי שימוש מסוימים. בטבלה הבאה מסכמים את ההבדלים העיקריים:
| CHIPS | Partitioned Storage | FedCM | Storage Access API עם קבוצות של אתרים קשורים | Storage Access API | |
|---|---|---|---|---|---|
| המשתמש לא צריך לגשת בעבר לצד המוטמע כאתר ברמה העליונה | |||||
| לא נדרש מהמשתמשים לאשר את הגישה | |||||
| לא נדרש מהמשתמש לבצע פעולה כלשהי במודול המוטמע | (יכול להיות נכון גם לגבי אתרים מוטמעים עם גישה ברמה העליונה). |
||||
| מאמצי ההטמעה | נמוכה מאוד | נמוכה | גבוהה | בינונית | בינונית |
| אפשר להשתמש בהם כדי לשתף קובצי cookie בין כמה אתרים/מקורות ברמה העליונה | (הצעה שנמצאת בבדיקה.) |
||||
| זמינה בדפדפנים שאינם מבוססי Chromium | (המערכת תעבור ל-Storage Access API.) |
תמיכה בתרחישי שימוש שונים בדפדפנים
תאימות הדפדפן היא אחד הגורמים העיקריים בבחירת פתרון, כפי שצוין בשורה האחרונה בטבלה. חלק מ-API (CHIPS, FedCM, Related WebSite Sets) זמינים רק בדפדפני Chromium. בשלב זה, שני הפתרונות היחידים לדפדפנים שונים הם ממשקי API לאחסון מפולח (כשלא נדרשים קובצי cookie) או Storage Access API (כשנדרשים קובצי cookie).
עם זאת, כפי שצוין קודם, לממשק API של גישה לאחסון יש כמה הגבלות שעשויות להשפיע על חוויית המשתמש באתר. צוות Chrome עבד על הוספת ממשקי ה-API האחרים, שנועדו לענות על תרחישים לדוגמה ספציפיים ולספק חוויה דומה לזו שהיתה אפשרית באמצעות קובצי Cookie של צד שלישי. לכן מומלץ לבחון את האפשרויות הטובות ביותר ולטפל בהן כהשיפורים הדרגתיים, עם חזרה ל-Storage Access API בדפדפנים שלא תומכים ב-Storage Access API.
מאחר שקובצי cookie יכולים להיחסם מכמה סיבות (למשל, הגדרות דפדפן, תוספים), יכול להיות שזיהוי התכונות של תמיכת ה-API לא יהיה מספיק. במקום זאת, מומלץ לבדוק אם קובצי ה-cookie הצפויים קיימים. אם לא, צריך לחזור לתהליך העבודה של Storage Access API כדי לבקש גישה לקובצי cookie של צד שלישי.
כדאי לפעול עכשיו!
אם הקוד המוטמע של הצד השלישי לא פועל יותר בלי להשתמש בקובצי cookie של צד שלישי, יש כמה פתרונות שיכולים לעזור לכם להתמודד עם ההשפעה האפשרית, כפי שמפורט בהרצאה הזו. עכשיו זה הזמן לבדוק את השירות ולראות אם יש בו קובצי Cookie של צד שלישי.
אם נתקלתם בבעיות בהטמעות שלכם עכשיו, בזמן שאנחנו בודקים את ההסרה של קובצי cookie של צד שלישי ב-Chrome, יש כמה אפשרויות לטווח קצר שיעזרו לכם בזמן המעבר לחלופות שמתוארות בפוסט הזה. מידע נוסף זמין במסמכי העזרה בנושא שימור חוויות משתמש קריטיות.
אם יש לכם שאלות לגבי תרחישי שימוש בהטמעות של צד שלישי שלא מופיעים במדריך הזה, תוכלו לדווח על בעיה חדשה באמצעות התג 'הוצאה משימוש של קובצי Cookie של צד שלישי' במאגר התמיכה למפתחים.