הוצאה משימוש והסרה של 'Basic-card' (כרטיס בסיסי) תמיכה ב-handler של תשלומים
בגרסה הזו של Chrome מסירים את ה-polyfill של הכרטיס הבסיסי ל-Payment Request API ב-iOS Chrome. כתוצאה מכך, Payment Request API מושבת באופן זמני ב: iOS ב-Chrome. לפרטים מלאים ראו חשיבה מחדש על בקשת תשלום ל-iOS.
כוונת הסרה | סטטוס פלטפורמת Chrome | באג ב-Chromium
הסרת השדה SupportType מ-BasicCardRequest
מציין פרמטר "supportedTypes":[type] לאמצעי תשלום אחד ("basic-card")
מציג כרטיסים מהסוג המבוקש בלבד, שהוא אחד מהערכים 'אשראי', "debit" או
"prepaid"
הפרמטר של סוג הכרטיס הוסר מהמפרט ועכשיו הוא מוסר מהמקומות הבאים Chrome, עקב הקושי בקביעת סוג הכרטיס המדויק. מוכרים היום צריך לבדוק את סוג הכרטיס ב-PSP, כי הוא לא יכול לסמוך על הכרטיס מסנן סוגי הפריטים בדפדפן:
- רק הבנקים המנפיקים יודעים מהו סוג הכרטיס ברמת ודאות והכרטיס שניתן להורדה יש מסדי נתונים ברמת דיוק נמוכה, כך שאי אפשר לדעת במדויק סוג הכרטיסים שמאוחסנים באופן מקומי בדפדפן.
- הכרטיס הבסיסי אמצעי התשלום ב-Chrome לא מציג יותר כרטיסים מ-Google Google Pay, שעשוי להיות קשרים עם בנקים מנפיקים.
כוונת הסרה | סטטוס פלטפורמת Chrome | באג ב-Chromium
צריך להסיר את הרכיב
Chrome 81 מסיר את הרכיב <discard>. היא מוטמעת רק ב-Chromium,
ולכן לא ניתן להשתמש בו באופן הדדי. ברוב תרחישי השימוש, זה יכול להיות
הוחלף בשילוב של אנימציה של הנכס display והסרה
(JavaScript) קריאה חוזרת (callback)/טיפול באירועים.
כוונת הסרה | סטטוס פלטפורמת Chrome | באג ב-Chromium
הסרה של TLS 1.0 ו-TLS 1.1
TLS (Transport Layer Security) הוא הפרוטוקול שמאבטח את HTTPS. יש בו היסטוריה ארוכה שמתחילה עם TLS 1.0 בן 20 שנה כמעט, גרסה קודמת ישנה יותר, SSL. גם ל-TLS 1.0 וגם ל-1.1 יש כמה נקודות חולשה.
- בגרסאות TLS 1.0 ו-1.1 נעשה שימוש ב-MD5 וב-SHA-1, שני גיבובים חלשים, בגיבוב של התמליל להודעה 'הסתיימה'.
- TLS 1.0 ו-1.1 משתמשים ב-MD5 וב-SHA-1 בחתימת השרת. (הערה: לא מדובר החתימה באישור).
- TLS (אבטחת שכבת התעבורה) בגרסאות 1.0 ו-1.1 תומכים רק בצפנים RC4 ו-CBC. ל-RC4 לא תקין הוסר. מבנה מצב CBC של TLS פגום וחשוף מתקפות.
- הצפנות CBC של TLS 1.0 בונים את וקטורי האתחול שלהם בטעות.
- TLS 1.0 כבר לא תואם ל-PCI-DSS.
תמיכה ב-TLS 1.2 היא דרישה מוקדמת כדי למנוע את הבעיות שצוינו למעלה. TLS (אבטחת שכבת התעבורה) קבוצת העבודה הוצאה משימוש את גרסאות TLS 1.0 ו-1.1. גם Chrome הוצא משימוש של הפרוטוקולים האלה.
כוונת הסרה | Chromestatus tracker | באג ב-Chromium
מעקף הקשחה של TLS 1.3 לאחור
TLS 1.3 כולל אמצעי הקשחה תואם לאחור לחיזוק ההגנות לאחור. עם זאת, כששלחנו את TLS 1.3 בשנה שעברה, נאלצנו להשבית את זה באופן חלקי נמדד עקב חוסר תאימות עם כמה הגדרות TLS שלא עומדות בדרישות. שרתי proxy. ב-Chrome מיושמת כרגע מידת הקשחה לאישורים שמשרשרת לשורשים מוכרים, אבל מאפשרת לעקוף את שרשרת האישורים לשורשים לא ידועים. אנחנו מתכוונים להפעיל אותה בכל החיבורים.
שדרוג לאחור של ההגנה מצמצם את ההשפעה של האבטחה של האפשרויות השונות מהדור הקודם כדי לשמור על תאימות. כלומר, החיבורים של המשתמשים מאובטחים יותר, כשמתגלה נקודות חולשה באבטחה, לא צריך להתערבל מגיבים להם. (כתוצאה מכך, המשמעות היא פחות אתרים לא תקינים למשתמשים road.) הכלל הזה תואם גם ל-RFC 8446.
כוונת הסרה | סטטוס פלטפורמת Chrome | באג ב-Chromium
מדיניות הוצאה משימוש
כדי לשמור על תקינות הפלטפורמה, לפעמים אנחנו מסירים מ-פלטפורמת האינטרנט ממשקי API שההרצה שלהם הסתיימה. יכולות להיות סיבות רבות לכך שנסיר API, כמו:
- הם מוחלפים על ידי ממשקי API חדשים יותר.
- הם מתעדכנים בהתאם לשינויים במפרטים כדי ליישר קו עם דפדפנים אחרים.
- אלה ניסויים מוקדמים שמעולם לא יצאו לפועל בדפדפנים אחרים, ולכן הם יכולים להגביר את נטל התמיכה על מפתחי אתרים.
חלק מהשינויים האלה ישפיעו על מספר קטן מאוד של אתרים. כדי לטפל בבעיות מראש, אנחנו מנסים לשלוח הודעה מראש למפתחים כדי שיוכלו לבצע את השינויים הנדרשים כדי שהאתרים שלהם ימשיכו לפעול.
ב-Chrome יש כרגע תהליך להוצאה משימוש והסרה של ממשקי API, בעיקרון:
- הודעה ברשימת התפוצה blink-dev.
- מגדירים אזהרות וקובעים מגבלות זמן במסוף כלי הפיתוח ל-Chrome כשהמערכת מזהה שימוש בדף.
- מומלץ להמתין, לעקוב ולהסיר את התכונה עם ירידות בשימוש.
ב-chromestatus.com ניתן למצוא רשימה של כל התכונות שהוצאו משימוש באמצעות המסנן שהוצא משימוש . בנוסף, התכונות שהוסרו זמינות באמצעות המסנן שהוסר. ננסה גם לסכם חלק מהשינויים, ההיגיון ונתיבי ההעברה בפוסטים האלה.