בדיקת ההשפעה של השינויים בקובצי cookie של צד שלישי על תהליכי העבודה של התשלומים

ב-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 ברמה העליונה שלו.

בתרשים מוצגת אינטראקציה עם אתר של מוכר (merchant.example) שמשתמש בווידג&#39;ט תשלומים מספק צד שלישי (payment-provider.example). כשקובצי cookie של צד שלישי חסומים, הווידג&#39;ט לא יכול לגשת לקובץ ה-cookie ברמה העליונה שלו, וכתוצאה מכך חוויית המשתמש עלולה להיפגע.
כשקובצי cookie של צד שלישי מושבתים, לווידג'ט payment-provider.example לא תהיה גישה לקובץ ה-cookie של סשן המשתמש שהוגדר בהקשר ברמת העליונה ב-payment-provider.example.

פתרון בהתאמה אישית באמצעות 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 ברמה העליונה שלו.

תרשים שממחיש תרחיש שבו פרטי הרווחים של משתמש, שמתארחים בכתובת earnings.example, מוצגים במרכז בקרה מוטמע בכתובת dogsitting.example.  כשקובצי cookie של צד שלישי חסומים, ללוח הבקרה המוטמע אין גישה לקובץ ה-cookie ברמה העליונה שלו, ולכן לא ניתן להציג את נתוני הרווחים המותאמים אישית של המשתמש.
כשקובצי cookie של צד שלישי מושבתים, לווידג'ט earnings.example שמוטמע ב-dogsitting.example לא תהיה גישה לקובץ ה-cookie שהוגדר בהקשר ברמת העליונה ב-earnings.example.

מרכזי בקרה של צד ראשון

במקרים שבהם כל שלושת הדומיינים שייכים לאותו צד, מומלץ להשתמש ב-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 במאגר התמיכה למפתחים של ארגז החול לפרטיות.