לקובצי Cookie של צד שלישי יש שימושים רבים, אבל הם גם מאפשרים מעקב אחרי משתמשים באתרים שונים.
יכול להיות שקובצי Cookie של צד שלישי נחסמים בגלל הגבלות בדפדפן, הגדרות משתמש, דגלים למפתחים או מדיניות ארגונית.
אתם רוצים שהאתר או השירות שלכם יספקו חוויה מעולה לכל המשתמשים, עם או בלי קובצי Cookie של צד שלישי.
בדף הזה תמצאו מידע על פתרונות לשמירה על הפרטיות בתרחישים של תוכן מוטמע, שבעבר הסתמכו על קובצי Cookie של צד שלישי, ועל אסטרטגיות שיעזרו לכם לבחור את הפתרון שהכי מתאים לצרכים שלכם.
שירותים מוטמעים, או הטמעות, כוללים תוכן של צד שלישי (כמו סרטונים, מפות), רכיבים אינטראקטיביים (כמו צ'אט, מערכות תגובות או שירותי תשלום), שירותי כניסה ועוד.
רוב העבודה שנדרשת כדי לעבור מקובצי Cookie של צד שלישי צריכה להתבצע על ידי מפתחי תוכן מוטמע, ולא על ידי אתרים שמארחים תוכן מוטמע. במדריך הזה נדון בעיקר בפתרונות למפתחים שיוצרים שירותים מוטמעים.
אם האתר שלכם מסתמך על תוכן מוטמע שמשתמש בקובצי Cookie של צד שלישי, חשוב לבדוק את מסלולי ההמרות שקשורים לתוכן המוטמע ולפנות לספקי התוכן המוטמע אם אתם מגלים תקלות.
ביקורת ובדיקה של מסלולים להמרת לקוח שקשורים להטמעה
הדרך הכי טובה לבדוק אם קובצי Cookie של צד שלישי משפיעים על ההטמעות היא לבדוק את תהליכי המשתמש בהטמעות של צד שלישי עם הפעלת הדגל לבדיקת קובצי Cookie של צד שלישי.
אחרי שמגבילים את קובצי ה-Cookie של צד שלישי, כדאי לבדוק את תרחישי ההטמעה הנפוצים הבאים:
- ווידג'טים של צ'אט: האם אפשר להתחיל שיחת צ'אט? האם תוכל לרענן את הדף בלי לאבד את הסשן? האם אפשר לעבור לדפים אחרים בלי לאבד את הסשן?
- הטמעות של תוכן: האם אפשר לצפות בתוכן וידאו או בתוכן מוטמע אחר? האם ההעדפות של המשתמשים, כמו שפה או כתוביות, נשמרות? האם אתם רואים מודעות כשאתם מצפים לראות אותן, למשל, אם אתם לא מנויים לגרסת פרימיום?
- התחברות: האם ההתחברויות – כולל התחברויות באמצעות כניסה יחידה (SSO) – פועלות בהטמעות שתומכות בהן? האם הם נשמרים גם אחרי טעינה מחדש של הדף ומעבר לדפים שבהם נעשה שימוש באותם הטמעות?
- ווידג'טים של תגובות: אפשר להוסיף תגובות, לסמן לייק ולתת לייק לתגובות?
- פתרונות תשלום מוטמעים: האם אפשר להשלים תשלומים בהצלחה?
בקטעים הבאים מפורט מידע ספציפי יותר על ההשפעה האפשרית על תהליכי העבודה האלה.
תרחישים נפוצים לדוגמה
יש מספר ממשקי API שאפשר להשתמש בהם להטמעות שהסתמכו באופן מסורתי על קובצי Cookie של צד שלישי. בטבלה הבאה מפורטים כמה תהליכי עבודה נפוצים ומומלצים לשימוש בממשקי API כסיכום ברמה גבוהה. בקטעים הבאים נסביר את הנימוקים להמלצות האלה.
| תרחיש לדוגמה | API מומלץ לשימוש בקובצי Cookie של צד שלישי |
|---|---|
| ווידג'ט צ'אט | CHIPS |
| הטמעות של מפות | CHIPS |
| דומיינים של ארגז חול לתוכן משתמשים לא מהימן (כמו googleusercontent.com ו-githubusercontent.com) שצריך להגדיר בהם את ההיקף של המצב לכל בעל תוכן דיגיטלי |
CHIPS |
| מודעות מוטמעות שצריכות להיות מוגבלות לבעל תוכן דיגיטלי מסוים | CHIPS |
| כניסה לחשבון דרך ספק זהויות | FedCM |
| הטמעה מתארחת במקורות שונים, אבל קשורים. | Storage Access API עם קבוצות אתרים קשורים (RWS) |
| הטמעות של תוכן עם העדפות שמבוססות על התחברות (כמו תוכן וידאו ללא מודעות, או העדפות לגבי שפה או כתוביות) |
Storage Access API |
| ווידג'ט של תגובות ברשתות חברתיות שנדרשת התחברות כדי להשתמש בו | Storage Access API |
בחירת ה-API המתאים לתרחישי שימוש מוטמעים של צד שלישי
בקטע הזה מוסבר איך לבחור API חלופי מתאים, ומוצגים ממשקי ה-API המומלצים.
תרשים הזרימה הבא יעזור לכם לבחור מבין האפשרויות הזמינות:
בתרשים הזרימה מוצגות שלוש שאלות עיקריות, ונבחן אותן בפירוט ונסביר למה מומלץ להשתמש בממשק API מסוים בכל מקרה.
1. האם קובצי ה-Cookie ספציפיים לאתר ההטמעה?
הרבה הטמעות של צד שלישי משמשות באופן עצמאי באתרים שלא קשורים זה לזה. לדוגמה, לווידג'טים של צ'אט לתמיכת לקוחות נדרשים לעיתים קרובות קובצי Cookie כדי לפעול, אבל אין צורך לשתף את קובצי ה-Cookie האלה בין שני ארגונים שונים לחלוטין שמשתמשים באותו פתרון של ווידג'ט צ'אט. למעשה, במקרים רבים עדיף לא לאפשר שיתוף של קובצי Cookie.
אם אתם מספקים שירות הטמעה של צד שלישי לאתרים אחרים והשירות מסתמך על קובצי Cookie, כדאי לבדוק אם קובצי ה-Cookie האלה ספציפיים לשירות באתר שבו הוא מוטמע. האם הם משותפים אי פעם על ידי מופעים של ההטמעה שלכם באתרים אחרים?
אם אין צורך לשתף את קובצי ה-Cookie, האפשרות הכי קלה היא לחלק אותם באמצעות CHIPS. ה-API הזה קושר קובצי Cookie של צד שלישי לאתר ברמה העליונה, במקום לאפשר שיתוף שלהם בין כל האתרים שמשתמשים באותו תוכן מוטמע של צד שלישי. ההטמעה של CHIPS היא פשוטה, כי צריך רק להוסיף מאפיין Partitioned נוסף לקובצי ה-Cookie הקיימים. כך השירותים המוטמעים עדיין יכולים לשמור את המצב, אבל לא יכולים להשתמש באחסון משותף באתרים שונים, שמאפשר מעקב באתרים שונים.
בנוסף, צריך לבדוק באתרים אם נעשה שימוש בקובצי Cookie מהסיבות הנכונות. צריך להשתמש בקובצי Cookie רק כשהם מוגדרים או כשצריך לשלוח אותם עם בקשות HTTP. אם זה לא המצב, וקובצי Cookie משמשים רק כאפשרות אחסון נוחה, כדאי לשקול במקום זאת את השימוש ב-storage APIs השונים. כך הנתונים נשארים מקומיים כשהם לא צריכים להישלח. ממשקי ה-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 עם קבוצות אתרים קשורים (RWS) | Storage Access API | |
|---|---|---|---|---|---|
| המשתמש לא צריך לגשת לפני כן לצד המוטמע כאתר ברמה העליונה | |||||
| לא נדרשת בקשה מהמשתמש לאישור הגישה | |||||
| לא נדרשת אינטראקציה של המשתמש עם ההטמעה | (יכול להיות נכון גם לגבי אתרים מוטמעים עם גישה ברמה העליונה). |
||||
| מאמץ ההטמעה | נמוכה מאוד | נמוכה | גבוהה | בינונית | בינונית |
| אפשר להשתמש בו כדי לשתף קובצי Cookie בכמה אתרים ברמה העליונה או בכמה מקורות | (הצעה בדיון) |
||||
| זמינות בדפדפנים שאינם מבוססי Chromium | (חוזר ל-Storage Access API) |
תרחישי שימוש נתמכים בדפדפנים שונים
תאימות לדפדפן היא אחד הגורמים העיקריים כשבוחרים פתרון, כפי שצוין בשורה האחרונה בטבלה. חלק מממשקי ה-API (CHIPS, FedCM, Related WebSite Sets) זמינים רק בדפדפני 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 של צד שלישי, יש כמה אפשרויות לטווח הקצר שיעזרו לכם בזמן המעבר לחלופות שמתוארות בפוסט הזה. מידע נוסף זמין במאמר בנושא שמירה על חוויות משתמש קריטיות.
אם יש לכם שאלות לגבי תרחישי שימוש בהטמעות של צד שלישי שלא מפורטים במדריך הזה, אתם יכולים לדווח על בעיה חדשה באמצעות התג third-party cookie deprecation במאגר התמיכה למפתחים שלנו.