ב-Chrome מציעים חוויית משתמש חדשה לגבי הבחירה של המשתמשים בנוגע לקובצי Cookie של צד שלישי. עליכם להכין את האתר למשתמשים שבוחרים לגלוש בלי קובצי Cookie של צד שלישי.
בדף הזה מפורט מה עשוי להיות מושפע מהשינויים הצפויים.
תהליכים נפוצים שעוברים המשתמשים
תהליכי עבודה רבים של תשלומים וקניות מסתמכים על קובצי cookie של צד שלישי. בטבלה הבאה מפורטים כמה תהליכי שימוש שעשויים להיות מושפעים מהשבתה של קובצי Cookie של צד שלישי, ומוצעות הצעות לממשקי API חלופיים שבהם מפתחים יכולים להשתמש כדי למנוע שיבושים. הרשימה הזו חלקית בלבד, והיא עשויה להתעדכן ככל שיהיו זמינים פתרונות נוספים לארגז החול לפרטיות. אם נתקלתם בתרחישים נוספים שהושפעו מהבעיה, מומלץ לשלוח לנו משוב.
בדיקת התהליכים שעוברים המשתמשים שקשורים לתשלומים
הדרך הטובה ביותר לבדוק אם תהליכי השימוש של המשתמשים מושפעים מהגבלות על קובצי cookie של צד שלישי היא לעבור אותם עם הדגל לבדיקת קובצי cookie של צד שלישי מופעל.
כדי לוודא שהאתר פועל כצפוי, צריך לבדוק את התהליך הבא עם הגבלת קובצי cookie של צד שלישי:
- תשלום בכמה אתרים: בודקים את תהליכי התשלום שמסתמכים על ספק תשלומים של צד שלישי (כמו Pay with <example-provider>). חשוב לוודא:
- ההפניה האוטומטית מתבצעת בהצלחה.
- שער התשלומים נטען בצורה תקינה.
- תהליך התשלום יכול להסתיים ללא שגיאות.
- המשתמש יופנה בחזרה לאתר שלכם כצפוי.
- לוחות בקרה של תשלומים: בודקים אם הווידג'טים של לוח הבקרה של העסקאות פועלים כצפוי כשקובצי ה-Cookie של צד שלישי מוגבלים. מוודאים שהמשתמש יכול:
- נכנסים למרכז הבקרה.
- כל התשלומים מופיעים כצפוי.
- לנווט ללא שגיאות בין קטעים שונים בלוח הבקרה (למשל, היסטוריית עסקאות, פרטי תשלום).
- ניהול אמצעי תשלום: בודקים שהווידג'טים לניהול אמצעי התשלום פועלים כצפוי. כשקובצי cookie של צד שלישי חסומים, בודקים את הדברים הבאים:
- הוספה או מחיקה של אמצעי תשלום פועלים כצפוי.
- תשלומים באמצעי תשלום ששמרתם בעבר לא יושפעו.
- זיהוי הונאות: אפשר להשוות בין אופן הפעולה של פתרון זיהוי ההונאות עם קובצי cookie של צד שלישי לבין אופן הפעולה שלו בלי קובצי cookie של צד שלישי.
- האם חסימת קובצי cookie של צד שלישי מחייבת לבצע שלבים נוספים, וכך גורמת למשיכה נוספת של המשתמשים?
- האם הוא עדיין יכול לזהות דפוסים חשודים כשקובצי cookie של צד שלישי חסומים בדפדפן?
- לחצן תשלום מותאם אישית: בדיקה אם לחצני התשלום מוצגים בצורה תקינה כשקובצי ה-Cookie של צד שלישי מוגבלים.
- האם המשתמש עדיין יכול להשלים רכישות גם אם הלחצן המותאם אישית לא מציג את אמצעי התשלום המועדף עליו?
תשלומים באתרים שונים
ספקי תשלומים מסוימים עשויים להסתמך על קובצי cookie של צד שלישי כדי לאפשר למשתמשים לגשת לחשבון שלהם בכמה אתרי מוכרים בלי צורך לבצע אימות מחדש. תהליך השימוש הזה עשוי להיות מושפע אצל משתמשים שבוחרים לגלוש בלי קובצי cookie של צד שלישי.
טפסים מוטמעים לתשלום
כדאי להביא בחשבון את הדומיינים הבאים:
payment-provider.example
מספקת שירותי תשלום לאתרים של מוכרים, ומאחסנת את נתוני התשלומים והסשנים של המשתמשים.merchant.example
הוא אתר שמוטמע בו טופס תשלום שסופק על ידיpayment-provider.example
.
משתמש נכנס ל-payment-provider.example
(לדוגמה, בזמן שהוא משלים תהליך תשלום באתר אחר). המשתמש מתחיל תהליך תשלום ב-merchant.example
.
אם קובצי ה-Cookie של הצד השלישי יהיו זמינים, לטופס התשלום payment-provider.example
שמוטמע ב-merchant.example
תהיה גישה לקובץ ה-cookie שלו ברמת הסשן ברמה העליונה, שמוגדר ב-payment-provider.example
בהקשר ברמה העליונה.
עם זאת, אם קובצי cookie של צד שלישי חסומים, לקוד המוטמע לא תהיה גישה לקובצי ה-cookie ברמה העליונה שלו.

פתרון בהתאמה אישית באמצעות FedCM
payment-provider.example
צריך לשקול להטמיע את FedCM כדי לשמש כספק זהויות. הגישה הזו מתאימה במקרים הבאים:
payment-provider.example
מוטמע באתרים של צד שלישי שאינם קשורים.payment-provider.example
מוטמע ביותר מחמישה אתרים קשורים.
היתרון העיקרי של FedCM הוא ש-UI יכול לספק למשתמשים יותר הקשר לגבי הבחירות שלהם. בעזרת הרשאת המשתמש, FedCM מאפשר לשתף נתונים מותאמים אישית בין הצד הנסמך (merchant.example
) לבין ספק הזהויות (payment-provider.example
). הצד הנסמך יכול לבחור לתמוך בספק זהויות אחד או יותר, וממשק המשתמש של FedCM יוצג רק באופן מותנה.
בהתאם לצרכים, המפתחים יכולים לבחור בין מצב פסיבי, שבו ההנחיה של FedCM תופיע באופן אוטומטי כשהמשתמש מחובר באמצעות ספק הזהויות, לבין מצב פעיל, שבו תהליך הכניסה יופעל אחרי פעולה של המשתמש, כמו לחיצה על לחצן התשלום.
FedCM משמש גם כאות אמון ל-Storage Access API (SAA), שמאפשר לקוד המוטמע לגשת לקובצי ה-cookie ברמה העליונה שלו שלא חולקו למחיצות, אחרי שהמשתמש מסכים להיכנס באמצעות הספק של הקוד המוטמע, בלי צורך בהודעה נוספת למשתמש.
פתרון שמתמקד בגישה לאחסון
ממשק API נוסף שאפשר להשתמש בו הוא Storage Access API (SAA).
כשמשתמשים ב-SAA, המשתמש מתבקש לאשר את ההטמעה של payment-provider.example
כדי לגשת לקובצי ה-cookie ברמה העליונה שלו. אם המשתמש יאשר את הגישה, הטופס יוצג כמו שהוא מוצג כשקובצי cookie של צד שלישי זמינים.
בדומה ל-FedCM, המשתמש יצטרך לאשר את הבקשה בכל אתר חדש שבו payment-provider.example
מוטמע. כדאי לצפות בהדגמה של SAA כדי להבין איך ה-API פועל.
אם ההנחיה שמוגדרת כברירת מחדל ב-SAA לא מתאימה לצרכים שלכם, כדאי להטמיע את FedCM כדי ליהנות מחוויה מותאמת אישית יותר.
הפחתת הקשיים בשימוש במספר קטן של אתרים קשורים
אם גם אתר המוכר וגם ספק התשלומים שייכים לאותה חברה, תוכלו להשתמש ב-API של קבוצות אתרים קשורות (RWS) כדי להצהיר על קשרים בין דומיינים. כך אפשר לצמצם את החיכוך של המשתמשים: לדוגמה, אם insurance.example
ו-payment-portal-insurance.example
נמצאים באותו RWS, ל-payment-portal-insurance.example
תהיה גישה אוטומטית לקובצי ה-cookie ברמה העליונה שלו כשמתבצע בקשה לגישה לאחסון בתוך הטמעת payment-portal-insurance.example
.
פתרונות ניסיוניים אחרים
ממשק API ניסיוני נוסף שעשוי להועיל בתרחיש הזה הוא חלוקה של חלונות קופצים. ה-API נמצא כרגע בשלב פיתוח פעיל.
באמצעות חלוקה של חלונות קופצים, אפשר לבקש מהמשתמש להזין את פרטי הכניסה שלו כדי להיכנס ל-payment-provider.example
בחלון קופץ שנפתח על ידי merchant.example
. האחסון יתחלק למחיצות על ידי הפותח merchant.example
. במקרה כזה, להטמעת payment-provider.example
תהיה גישה לערכים של האחסון שהוגדרו בחלון הקופץ. בפתרון הזה, המשתמש יצטרך להיכנס לחשבון אצל ספק התשלומים בכל אתר.
תשלומים דרך קישור לתשלום
ספקי תשלומים מסוימים מציעים שירות שבו נוצר קישור לתשלום, שמציג דף תשלום מותאם אישית באתר של המוכר. לעיתים קרובות, שירות קישור התשלום ופורטל המשתמש של ספק התשלומים מיושמים בדומיינים שונים, למשל payment-provider.example
ו-payment-link.example
.
payment-link.example
מטמיע טופס תשלום שסופק על ידי payment-provider.example
. זוהי וריאציה של התבנית של טופס התשלום המוטמע.
FedCM, SAA ו-RWS הן גם אפשרויות טובות במקרה הזה.
מרכזי בקרה של תשלומים
באפליקציות מסוימות מוצגים למשתמשים מרכזי בקרה של עסקאות בכמה אתרים, שמספקים תצוגה מרוכזת של הפעילויות הפיננסיות שלהם. לשם כך, לוח הבקרה צריך גישה לנתונים ספציפיים למשתמש בכמה דומיינים.
כדאי להביא בחשבון את הדומיינים הבאים:
earnings.example
מספקת לוח בקרה של תשלומים שאפשר להטמיע באפליקציות אינטרנט שונות. השירות הזה מאחסן נתוני רווחים של משתמשים ומידע על סשנים.catsitting.example
ו-dogsitting.example
הם אתרים נפרדים, שבהם מוטמע מרכז הבקרהearnings.example
.
משתמש מתחבר לחשבון earnings.example
שלו. כשהם נכנסים לאתר catsitting.example
או לאתר dogsitting.example
, הם יכולים לראות את הרווחים שלהם. מרכז הבקרה המוטמע earnings.example
מסתמך על קובצי cookie ברמה העליונה ומציג את פרטי הרווחים המותאמים אישית של המשתמש.
בדומה לדוגמאות אחרות, אם קובצי ה-cookie של הצד השלישי מושבתים, לקוד ההטמעה של earnings.example
לא תהיה גישה לקובצי ה-cookie ברמה העליונה שלו.

מרכזי בקרה של צד ראשון
במקרים שבהם כל שלושת הדומיינים שייכים לאותו צד, מומלץ להשתמש ב-SAA יחד עם RWS.
בעזרת SAA, earnings.example
יכול לקבל גישה לקובץ ה-Cookie ברמה העליונה שלו עם הרשאת המשתמש. אם הצד הזה משתמש ב-earnings.example
בארבעה דומיינים או פחות, הכרזה על היחסים ביניהם באמצעות RWS יכולה לשפר את חוויית המשתמש.
אם אותו צד מטמיע את הווידג'ט ביותר מחמישה דומיינים, הוא לא יכול להצהיר על קשרים בין כל האתרים שבהם הוא הטמיע את הווידג'ט לבין הדומיין של הווידג'ט, כי מערכת RWS תומכת רק בשישה אתרים בקבוצה – אתר ראשי אחד וחמישה אתרים משויכים.
חלוקת מרכזי בקרה מותאמים לעומס
במקרים הבאים, SAA ו-RWS עשויים שלא להיות הפתרון האופטימלי:
- אתם מפיצים פתרון של מרכז בקרה לאתרים של צד שלישי.
- יש לכם יותר מחמישה אתרים שבהם מוטמע הווידג'ט של לוח הבקרה.
במקרה כזה, כדאי ל-earnings.example
להטמיע את FedCM כדי לשמש כספק זהויות. המשמעות היא שהמשתמש יצטרך להתחבר ל-dogsitting.example
באמצעות חשבון שמנוהל על ידי earnings.example
.
FedCM מציע ממשק משתמש שניתן להתאמה אישית, שיכול לעזור להעביר למשתמש בצורה ברורה איזה מידע משותף. באמצעות FedCM, dogsitting.example
יכול לבקש מ-earnings.example
לשתף הרשאות בהתאמה אישית, למשל, כדי לגשת לנתוני עסקאות.
FedCM משמש גם כאות אמון ל-Storage Access API, והקובץ המוטמע של earnings.example
יקבל גישה לאחסון של קובצי ה-cookie ברמה העליונה שלו, ללא בקשה נוספת מהמשתמש בקריאה ל-SAA API.
הגדרות מרכז הבקרה הספציפיות לאתר
אם אין צורך לשתף את הנתונים בין כמה אתרים, כדאי לחלק את קובצי ה-Cookie באמצעות CHIPS. אפשר להשתמש ב-CHIPS כדי לשמור העדפות ספציפיות לאתר, למשל את הפריסה של מרכז הבקרה או את המסננים.
ניהול אמצעי תשלום
תהליך נפוץ נוסף הוא שהמשתמש יוכל לראות ולערוך את אמצעי התשלום שלו בתוך הטמעה בלי לצאת מהאתר המארח.
נבחן את התהליך הבא:
payments.example
מספקת כלי לניהול תשלומים שאפשר להטמיע באתרים. השירות הזה מאחסן את נתוני התשלומים של המשתמשים ואת פרטי הסשנים שלהם.shop.example
הוא אתר שמוטמע בו הכליpayments.example
כדי לאפשר למשתמשים להציג, לערוך או לבחור את אמצעי התשלום המועדפים שמשויכים לחשבוןshop.example
שלהם.
ספקי תשלומים שמטמיעים ניהול של אמצעי תשלום צריכים גם לשקול להפוך לספק זהויות באמצעות FedCM. באמצעות FedCM, המשתמש יוכל להתחבר לצד הנסמך (shop.example
) באמצעות החשבון שמנוהל על ידי ספק הזהויות (payments.example
).
בעזרת הרשאת המשתמש, FedCM מאפשר שיתוף של נתונים מותאמים אישית בין הצד המשתמש לבין ספק הזהויות. היתרון העיקרי של השימוש ב-FedCM הוא שאפשר להציג למשתמשים הקשר נוסף לגבי הבחירות שלהם בממשק המשתמש. הוא גם משמש כאות אמון ל-Storage Access API, שמאפשר לקוד המוטמע לגשת לקובצי ה-Cookie ברמה העליונה שלו.
כשקובצי cookie של צד שלישי מושבתים, לקוד ההטמעה של payments.example
לא תהיה גישה לקובצי ה-cookie ברמה העליונה שלו. במקרה כזה, SAA יכול לעזור לכם לוודא שהפעולה מתבצעת כראוי על ידי בקשה לגישה לאחסון.
לפעמים אין צורך לשתף את המידע שמוגדר בקוד ההטמעה עם אתרים אחרים שמטמיעים אותו. יכול להיות ש-payments.example
יצטרך לאחסן העדפות משתמש שונות לכל אתר הטמעה ספציפי. במקרה כזה, מומלץ לפצל את קובצי ה-cookie באמצעות CHIPS. כשמשתמשים ב-CHIPS, לא תהיה גישה לקובץ ה-cookie שהוגדר ב-payments.example
שמוטמע ב-shop.example
מ-payments.example
שמוטמע ב-another-shop.example
.
ממשק API ניסיוני נוסף שאפשר להשתמש בו בתהליך המשתמש הזה הוא חלוקה של חלונות קופצים.
כשהמשתמש נכנס ל-payments.example
בתוך חלון קופץ שנפתח על ידי shop.example
, האחסון יחולק על ידי הגורם שפתח אותו, ולקובץ המוטמע של payments.example
תהיה גישה לערכים של האחסון שהוגדרו בחלון הקופץ. עם זאת, בגישה הזו המשתמשים צריכים להזין פרטי כניסה כדי להיכנס לספק התשלומים בכל אתר.
זיהוי הונאות
מערכות לניתוח סיכונים יכולות לנתח את הנתונים שמאוחסנים בקובצי cookie כדי לזהות דפוסים שחורגים מהנורמה. לדוגמה, אם משתמש משנה פתאום את כתובת המשלוח שלו ומבצע כמה רכישות גדולות באמצעות מכשיר חדש, יכול להיות שהניקוד של החשד לתרמית יעלה. קובצי cookie לזיהוי הונאות הם בדרך כלל קובצי cookie של צד שלישי, שמוגדרים באתרים של המוכרים על ידי ספקי תשלומים או ווידג'טים של שירותי מניעת הונאות.
הגבלות על קובצי cookie של צד שלישי לא אמורות לפגוע במערכות לזיהוי הונאות, אבל הן עשויות ליצור חיכוך נוסף אצל המשתמשים. אם המערכת לא יכולה לאמת בביטחון שמשתמש הוא לגיטימי בגלל קובצי cookie חסומים, יכול להיות שתידרש לבצע בדיקות נוספות, כמו השלמת אימות הזהות.
כדי לתמוך בזיהוי הונאות כשקובצי cookie של צד שלישי חסומים, מומלץ לשלב את Private State Tokens (PST) API בפתרונות שלכם לזיהוי הונאות. בעזרת PST, ספק תשלומים יכול להירשם בתור מנפיק אסימונים ולהעניק למשתמשים אסימונים שלא מסתמכים על קובצי cookie של צד שלישי. לאחר מכן אפשר לממש את האסימונים האלה באתרים של מוכרים כדי לבדוק אם המשתמש מהימן. פרטים על ההטמעה מופיעים במסמכי התיעוד למפתחים של PST.
אנחנו עורכים ניסויים עם ממשקי API אחרים למניעת הונאות במסגרת ארגז החול לפרטיות.
כפתור תשלום מותאם אישית
לחצני תשלום (כמו Pay with <preferred payment method>) שמוטמעים באתרים של מוכרים מסתמכים לעיתים קרובות על מידע באתרים שונים שהוגדר על ידי ספק התשלומים. כך אפשר להתאים אישית את התשלום, והמשתמשים יכולים ליהנות מתהליך תשלום חלק באמצעות אמצעי התשלום המועדף עליהם. אם קובצי cookie של צד שלישי חסומים בדפדפן של המשתמש, יכול להיות שהדבר ישפיע על העיבוד של לחצן התשלום המותאם אישית.
SAA יכול לאפשר גישה לאחסון, אבל יכול להיות שההנחיה הנדרשת לא תוביל לחוויית משתמש אידיאלית.
אנחנו בודקים פתרון פוטנציאלי שמתמקד באופן ספציפי בתרחיש לדוגמה הזה: מסגרות מגודר עם גישה לנתונים מקומיים ללא חלוקה למחיצות. ה-API נמצא כרגע בשלב פיתוח פעיל, ואתם יכולים לעצב את העתיד שלו. כדאי לנסות בעצמכם ולשלוח משוב.
עזרה
מדווחים על תקלות ב-goo.gle/report-3pc-broken. אפשר גם לשלוח טופס משוב או לדווח על בעיה ב-GitHub במאגר התמיכה למפתחים של ארגז החול לפרטיות.