יש הרבה שימושים בקובצי 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 באתרים האלה נחשב כשימוש בקובצי 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).
עם זאת, כפי שצוין קודם, ל-Storage Access API יש כמה הגבלות שעשויות להשפיע על חוויית המשתמש באתר. צוות Chrome עבד על הוספת ממשקי ה-API האחרים, שנועדו לענות על תרחישים לדוגמה ספציפיים ולספק חוויה דומה לזו שהיתה אפשרית באמצעות קובצי Cookie של צד שלישי. לכן מומלץ לבחון את האפשרויות הטובות ביותר ולטפל בהן כהשיפורים הדרגתיים, עם חזרה ל-Storage Access API בדפדפנים שלא תומכים ב-Storage Access API.
מאחר שקובצי cookie יכולים להיחסם מכמה סיבות (לדוגמה, הגדרות דפדפן, תוספים), יכול להיות שזיהוי התכונות של תמיכת ה-API לא יהיה מספיק. במקום זאת, מומלץ לבדוק אם קובצי ה-cookie הצפויים קיימים. אם לא, אפשר להשתמש בתהליך העבודה של Storage Access API לבקשת גישה לקובצי cookie של צד שלישי.
כדאי לפעול עכשיו!
אם הקוד המוטמע של הצד השלישי לא פועל יותר בלי שימוש בקובצי cookie של צד שלישי, יש כמה פתרונות שיכולים לעזור לכם להתמודד עם ההשפעה האפשרית, כפי שמפורט בהרצאה הזו. עכשיו זה הזמן לבדוק את השירות כדי לאתר קובצי cookie של צד שלישי.
אם נתקלתם בבעיות בהטמעות שלכם עכשיו, בזמן שChrome בודק את ההסרה של קובצי cookie של צד שלישי, יש כמה אפשרויות לטווח קצר שיעזרו לכם בזמן המעבר לחלופות המתוארות בפוסט הזה. מידע נוסף זמין במסמכי העזרה בנושא שימור חוויות משתמש קריטיות.
אם יש לכם שאלות לגבי תרחישי שימוש בהטמעות של צד שלישי שלא מופיעים במדריך הזה, אתם יכולים לדווח על בעיה חדשה באמצעות התג 'הוצאה משימוש של קובצי Cookie של צד שלישי' במאגר התמיכה למפתחים.