לקובצי cookie של צד שלישי יש שימושים רבים, אך הם גם גורמים מרכזיים של מעקב חוצה-אתרים.
אנחנו ב-Chrome מציעים חוויה חדשה לבחירת המשתמש עם קובצי cookie של צד שלישי. עליכם להכין את האתר למשתמשים שבוחרים לגלוש ללא קובצי Cookie של צד שלישי.
בדף הזה תמצאו מידע על פתרונות לשמירה על הפרטיות לתרחישים מוטמעים שבדרך כלל הסתמכו על קובצי cookie של צד שלישי, ועל אסטרטגיות שיעזרו לכם לבחור את הפתרון שהכי מתאים לצרכים שלכם.
שירותים מוטמעים או הטמעות כוללים תוכן של צד שלישי (כמו סרטונים, מפות), רכיבים אינטראקטיביים (כמו צ'אט, מערכות תגובות או שירותי תשלום), שירותי התחברות ועוד.
את רוב עבודת המעבר מקובצי cookie של צד שלישי צריך לבצע מפתחי הטמעה, ולא אתרים שמארחים הטמעות. במדריך הזה נדון בעיקר בפתרונות למפתחים שיוצרים שירותים מוטמעים.
אם האתר מסתמך על הטמעה המשתמשת בקובצי Cookie של צד שלישי, חשוב לבדוק ולבחון את התהליכים הקשורים להטמעה ולפנות לספקי ההטמעה אם תגלו תקלות.
בדיקה ובדיקה של התהליכים שעוברים המשתמשים שקשורים להטמעות
הדרך הטובה ביותר לבדוק אם ההטמעות שלכם מושפעות מקובצי Cookie של צד שלישי היא לבדוק את הזרימה של המשתמשים המוטמעים של הצד השלישי כשהסימון לבדיקת קובצי Cookie של צד שלישי מופעל.
אחרי שמגבילים קובצי Cookie של צד שלישי, כדאי לבדוק את תרחישי ההטמעה הנפוצים הבאים:
- ווידג'טים של צ'אט: האם אתם יכולים להתחיל שיחת צ'אט? האם אפשר לרענן את הדף בלי לאבד את הסשן? יש לך אפשרות לעבור לדפים אחרים ולשמור על הסשן?
- הטמעות תוכן: האם אתם יכולים להציג תוכן סרטונים או תוכן מוטמע אחר? האם ההעדפות של המשתמשים, כמו השפה או הכתוביות, נשמרות? האם מוצגות לך מודעות כמצופה, למשל, אם הן לא מופיעות כמנויי Premium?
- התחברות: האם פרטי התחברות, כולל פרטי התחברות לכניסה יחידה (SSO) פועלים עבור הטמעות שתומכות בהם? האם הם עקביים במהלך טעינות מחדש של דפים וניווט לדפים שמשתמשים באותם הטמעות?
- ווידג'טים לתגובות: תוכלו להוסיף תגובות, לסמן לייק או לסמן לייק לתגובות?
- פתרונות תשלום מוטמעים: האם אתם יכולים להשלים את ביצוע התשלומים?
בקטעים הבאים תמצאו מידע ספציפי יותר על ההשפעה האפשרית של התהליכים האלה.
תרחישים נפוצים לדוגמה
יש כמה ממשקי API שאפשר להשתמש בהם להטמעות שבדרך כלל מסתמכות על קובצי Cookie של צד שלישי. בטבלה הבאה מפורטים כמה תהליכי עבודה נפוצים וממשקי ה-API המומלצים לשימוש כסיכום כללי. בקטעים הבאים נסביר את הסיבות להמלצות האלה.
| תרחיש לדוגמה | ה-API המומלץ לשימוש בקובצי cookie של צד שלישי |
|---|---|
| הווידג'ט של הצ'אט | צ'יפים |
| הטמעות מפה | צ'יפים |
| דומיינים של ארגז חול (Sandbox) לתוכן לא מהימן של משתמשים (כמו googleusercontent.com ו-githubusercontent.com) שצריך להגדיר בהם הרשאות מדינה לכל בעל תוכן דיגיטלי |
צ'יפים |
| מודעות מוטמעות שצריכות להיות ברמת המדינה (State) לכל בעל אתר | צ'יפים |
| התחברות דרך ספק זהויות | FedCM |
| הטמעה שמתארחת במקורות שונים אך קשורים. | Storage Access API עם קבוצות של אתרים קשורים |
| התוכן מוטמע עם העדפות שמבוססות על התחברות (למשל, תוכן וידאו ללא מודעות או העדפות שפה/כתוביות) |
Storage Access API |
| ווידג'ט של תגובות ברשתות חברתיות שמחייב התחברות | Storage Access API |
בחירת ה-API שישמש לתרחישים לדוגמה של צדדים שלישיים שמוטמעים בו
בקטע הזה נסביר איך לבחור ממשק API חלופי מתאים והסברים על ממשקי ה-API המומלצים.
תרשים הזרימה הבא עוזר לבחור מבין האפשרויות הזמינות:
בתרשים הזרימה יש שלוש שאלות עיקריות, ואנחנו נבחן אותן לעומק ונסביר למה מומלץ להשתמש ב-API מסוים בכל אחד מהמקרים.
1. האם קובצי ה-Cookie ספציפיים לאתר ההטמעה?
הטמעות רבות של צד שלישי משמשות באופן עצמאי באתרים שלא קשורים כלל. לדוגמה, לרוב, ווידג'טים של צ'אט לתמיכת לקוחות נדרשים כדי להפעיל קובצי cookie, אבל אין צורך לשתף את קובצי ה-cookie האלה בין שני ארגונים שונים לחלוטין, ששניהם משתמשים באותו פתרון לווידג'ט של הצ'אט. למעשה, במקרים רבים רצוי לא להתיר אפילו שיתוף של קובצי cookie.
אם אתם מספקים שירות הטמעה של צד שלישי לאתרים אחרים והוא מסתמך על קובצי cookie, חשוב לבדוק אם קובצי ה-cookie האלה ספציפיים לשירות באתר שבו הוא מוטמע. האם יש מקרים שבהם הם משותפים לצד מופעים של ההטמעה באתרים אחרים?
אם לא צריך לשתף את קובצי ה-cookie, האפשרות הקלה ביותר היא חלוקה למחיצות (partitioning) של קובצי Cookie באמצעות CHIPS. ה-API הזה מקשר קובצי Cookie של צד שלישי לאתר ברמה העליונה, במקום לאפשר שיתוף שלהם לכל האתרים שמשתמשים באותה הטמעה של צד שלישי. קל להטמיע את CHIPS, כי כדי להשתמש בו צריך רק להוסיף עוד מאפיין Partitioned לקובצי ה-cookie הקיימים. כך השירותים המוטמעים עדיין יוכלו לשמור את המצב, אבל הם יוסרו מהאחסון המשותף של מספר אתרים שיאפשר להם לעקוב אחרי אתרים שונים.
בנוסף, אתרים צריכים לבדוק אם נעשה שימוש בקובצי Cookie למטרות הנכונות. יש להשתמש בקובצי Cookie רק כשהם מוגדרים או שצריך לשלוח אותם באמצעות בקשות HTTP. אם זה לא המצב, וקובצי cookie משמשים רק כאמצעי אחסון נוח, צריך להשתמש במקום זאת בממשקי ה-API השונים לאחסון. התכונה הזו שומרת את הנתונים באופן מקומי כשאין צורך לשלוח אותם. ממשקי ה-API של האחסון כבר מחולקים למחיצות בכל הדפדפנים העיקריים, באופן דומה ש-CHIPS מחלק למחיצות קובצי cookie.
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 באמצעות חלון קופץ בדפדפן, במיוחד במופע הראשון ומדי פעם לאחר מכן.
- ייתכן שאתר ההטמעה יצטרך להגדיר מאפיינים נוספים של Sandbox.
ההגבלות האלה מבטיחות את הפעולה החזקה של הפעלה מחדש של קובצי cookie של צד שלישי רק כאשר המשתמש והאתר מצפים לכך. עם זאת, בתרחישים מסוימים, יכול להיות שהמערכת תדלג על פעולות המשתמש. לדוגמה, אם המשתמש אישר גישה לאחרונה, יכול להיות שלא יהיה צורך לשלוח לו בקשה מחדש למשך פרק זמן מסוים (כפי שהוגדר על ידי הדפדפן).
תרחיש נוסף שבו סביר להניח שהמשתמש מצפה לכך הוא באתרים קשורים. לדוגמה, ארגונים מסוימים משתמשים בכמה מקורות שונים, שנחשבים בין אתרים שונים בתור דפדפן, ולכן השימוש בקובצי Cookie בהם נחשב כמקורות צד שלישי. לדוגמה: מותגים עם אתרים ספציפיים למדינה (כמו example.com ו-example.co.uk) או אתרים ספציפיים למותג (כמו example.car ו-example.house).
במקרה כזה, כשיש מספר קטן של אתרים קשורים, אפשר להשתמש בקבוצות של אתרים קשורים. אתרים נשלחים אל Chrome כדי ש-Chrome תדע שהם קשורים. כך מתאפשרת גישה ל-Storage Access API בצורה ידידותית יותר למשתמש, עם פחות הנחיות למשתמשים.
באתרים לא קשורים שהם למעשה צדדים שלישיים, ושבהם נדרשת גישה מלאה לקובצי cookie של צד שלישי כי ממשקי ה-API החלופיים לא מספיקים, השימוש ב-Storage Access API יהיה כפוף לכל הדרישות וההנחיות.
השוואה בין ממשקי ה-API השונים
לכל אחד מהפתרונות יש מאפיינים ומגבלות מעט שונים, ולכן הוא מתאים יותר לשימוש בתרחישים מסוימים. בטבלה הבאה מסכמת את ההבדלים העיקריים:
| צ'יפים | אחסון מחולק למחיצות (Partitions) | FedCM | Storage Access API עם קבוצות של אתרים קשורים | Storage Access API | |
|---|---|---|---|---|---|
| המשתמש לא צריך לקבל גישה לפני כן לגורם המוטמע כאתר ברמה עליונה | |||||
| לא נדרשת בקשה מהמשתמש לאישור גישה | |||||
| לא מחייבת את המשתמש לבצע אינטראקציה עם ההטמעה | (המידע הזה יכול להיות רלוונטי גם לאתרים מוטמעים שיש להם גישה ברמה העליונה). |
||||
| מאמץ ההטמעה | נמוכה מאוד | נמוכה | גבוהה | בינונית | בינונית |
| יכול לשמש לשיתוף קובצי cookie במספר אתרים/מקורות ברמה העליונה | (הצעה בפיקוח.) |
||||
| האפשרות זמינה בדפדפנים שאינם Chromium | (חזרה לממשק Storage Access API). |
תמיכה בתרחישים לדוגמה בדפדפנים שונים
תאימות דפדפן היא אחד מהגורמים העיקריים בהחלטה על פתרון, כפי שמתואר בשורה האחרונה של הטבלה. חלק מממשקי ה-API (CHIPS, FedCM, 'קבוצות אתרים קשורים') זמינים רק בדפדפני Chromium. שני הפתרונות היחידים כרגע לדפדפנים שונים הם ממשקי API לאחסון עם חלוקה למחיצות (כשאין צורך בקובצי cookie) או Storage Access API (כשנדרשים קובצי cookie).
עם זאת, כפי שצוין קודם, ל-Storage Access API יש כמה הגבלות שיכולות להשפיע על חוויית המשתמש באתר שלכם. צוות Chrome עבד על הוספה של ממשקי ה-API האחרים, שנועדו להתאים לתרחישים לדוגמה ספציפיים ולספק חוויה דומה לזו שהייתה יכולה להיות באמצעות קובצי cookie של צד שלישי. לכן מומלץ לשקול את האפשרויות הטובות ביותר ולהתייחס אליהן כשיפורים מתקדמים, עם שימוש ב-Storage Access API לדפדפנים שלא תומכים בכך.
יש כמה סיבות אפשריות לחסימת קובצי cookie (למשל, הגדרות הדפדפן או תוספים), ולכן ייתכן שזיהוי התכונות של תמיכה ב-API לא יספיק. במקום זאת, מומלץ לבדוק אם קיימים קובצי ה-cookie הצפויים, ואם לא, לחזור לתהליך העבודה של Storage Access API כדי לבקש גישה לקובצי cookie של צד שלישי.
נקיטת פעולה עכשיו!
אם ההטמעה של הצד השלישי כבר לא פועלת ללא שימוש בקובצי Cookie של צד שלישי, יש כמה פתרונות זמינים לטיפול בהשפעה האפשרית, כפי שמפורט בשיחה הזו. זה הזמן לבדוק את השירות שלך כדי לאתר קובצי cookie של צד שלישי עכשיו!
אם אתם נתקלים בשיבושים בהטמעות בזמן שChrome בודק את ההסרה של קובצי cookie של צד שלישי, יש כמה אפשרויות לטווח קצר לקבלת עזרה במעבר לחלופות שמתוארות בפוסט הזה. מידע נוסף זמין במסמכי התיעוד בנושא שמירה על חוויות משתמש חיוניות.
אם יש לכם שאלות לגבי תרחישים לדוגמה של הטמעות צד שלישי שלא עסקו במדריך הזה, אפשר להעלות בעיה חדשה באמצעות 'ההוצאה משימוש של קובצי cookie של צד שלישי' במאגר התמיכה למפתחים.