הוצאה משימוש והסרה של handler של תמיכה בתשלומים מסוג "basic-card"
גרסה זו של Chrome מסירה את ה-Polyfill של הכרטיסים הבסיסיים עבור Payment Request API ב-iOS של Chrome. כתוצאה מכך, Payment Request API מושבת באופן זמני ב-Chrome ל-iOS. פרטים מלאים זמינים במאמר ReThinking Payment Request ל-iOS.
כוונה להסיר | סטטוס הפלטפורמה של Chrome | באג ב-Chromium
הסר את השדה supportedType מ-BasicCardRequest
אם מציינים את הפרמטר "supportedTypes":[type] באמצעי התשלום "basic-card", יוצגו רק כרטיסים מהסוג המבוקש – "credit", "debit" או "prepaid".
הפרמטר של סוג הכרטיס הוסר מהמפרט ועכשיו הוא הוסר מ-Chrome, בגלל הקושי בזיהוי מדויק של סוג הכרטיס. מוכרים כיום צריכים לבדוק את סוג הכרטיס מול ספק שירותי התשלום שלהם כי הם לא יכולים לסמוך על המסנן של סוג הכרטיס בדפדפן:
- רק הבנקים המנפיקים יודעים בוודאות מהו סוג הכרטיס, ומסדי הנתונים של סוגי הכרטיסים הניתנים להורדה הם ברמת דיוק נמוכה, כך שאי אפשר לדעת במדויק מה סוג הכרטיסים שמאוחסנים באופן מקומי בדפדפן.
- באמצעי התשלום "Basic-card" ב-Chrome כבר לא מוצגים כרטיסים מ-Google Pay, שייתכן שיש להם קשרים עם הבנקים המנפיקים.
כוונה להסיר | סטטוס הפלטפורמה של Chrome | באג ב-Chromium
מסירים את הרכיב
Chrome 81 מסיר את הרכיב <discard>. ההטמעה מוטמעת רק ב-Chromium,
ולכן לא ניתן להשתמש בפעולה הדדית. ברוב התרחישים לדוגמה, אפשר להחליף אותה בשילוב של אנימציה של הנכס display וגורם שמטפל באירועים או בקריאה חוזרת (JavaScript).
כוונה להסיר | סטטוס הפלטפורמה של Chrome | באג ב-Chromium
הסרת TLS 1.0 ו-TLS 1.1
TLS (Transport Layer Security) הוא הפרוטוקול שמאבטח את HTTPS. יש לו היסטוריה ארוכה שמתחילה ב-TLS 1.0 בן כמעט 20 שנה ובקודמו, SSL. גם ל-TLS 1.0 וגם ל-TLS 1.1 יש מספר חסרונות.
- בגרסאות 1.0 ו-1.1 של ה-TLS (אבטחת שכבת התעבורה) נעשה שימוש ב-MD5 וב-SHA-1, גיבוב (hash) חלש, בגיבוב (hash) של התמליל של ההודעה Finish (סיום ההודעה).
- 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 גם הוציא משימוש את הפרוטוקולים האלה.
כוונה להסיר | מעקב אחר הסטטוס של Chrome | באג ב-Chromium
מעקף להקשת שדרוג לאחור של TLS 1.3
TLS 1.3 כולל אמצעי הקשחה תואם לאחור כדי לשפר את אמצעי ההגנה לשדרוג לאחור. עם זאת, כששלחנו את TLS 1.3 בשנה שעברה, נאלצנו להשבית באופן חלקי את האמצעי הזה עקב חוסר תאימות עם כמה שרתי proxy לביטול TLS שאינם תואמים. בשלב זה, Chrome מטמיע את אמצעי הקשחה של אישורים שמקשרים לשורשים ידועים, אבל מאפשר לעקוף את האישורים לשורשים לא ידועים. אנחנו מתכוונים להפעיל אותה בכל החיבורים.
ההגנה על שדרוג לאחור מצמצמת את ההשפעה של האבטחה של האפשרויות השונות מדור קודם שאנחנו שומרים לצורך תאימות. כלומר, החיבורים של המשתמשים מאובטחים יותר, וכשמתגלות נקודות חולשה באבטחה, פחות קשה להגיב להם. (המשמעות היא שבסופו של דבר, פחות אתרים לא תקינות למשתמשים בהמשך). גם התנאים האלה תואמים ל-RFC 8446.
כוונה להסיר | סטטוס הפלטפורמה של Chrome | באג ב-Chromium
מדיניות הוצאה משימוש
כדי לשמור על תקינות הפלטפורמה, לפעמים אנחנו מסירים ממשקי API מפלטפורמת האינטרנט שפעילותם הסתיימה. יכולות להיות סיבות רבות לכך שנסיר ממשק API, למשל:
- הם מוחלפים בממשקי API חדשים יותר.
- הם מתעדכנים כדי לשקף שינויים במפרטים כדי לאפשר התאמה ועקביות עם דפדפנים אחרים.
- אלו הם ניסויים מוקדמים שמעולם לא יצאו לפועל בדפדפנים אחרים, ולכן הם עשויים להגדיל את נטל התמיכה על מפתחי אתרים.
חלק מהשינויים האלה ישפיעו על מספר קטן מאוד של אתרים. כדי לצמצם את הבעיות מראש, אנחנו מנסים לשלוח הודעה מראש למפתחים כדי שיוכלו לבצע את השינויים הנדרשים כדי שהאתרים שלהם ימשיכו לפעול.
ב-Chrome יש כרגע תהליך להוצאה משימוש והסרה של ממשקי API, בעיקרו:
- הודעה ברשימת התפוצה של blink-dev.
- כשהמערכת מזהה שימוש בדף, יש להגדיר אזהרות ולציין סולמות זמן במסוף כלי הפיתוח של Chrome.
- להמתין, לעקוב אחרי השימוש בתכונה ואז להסיר אותה כשהשימוש יורד.
ניתן למצוא רשימה של כל התכונות שהוצאו משימוש ב-chromestatus.com באמצעות המסנן שהוצא משימוש ותכונות שהוסרו על ידי החלת המסנן שהוסר. כמו כן, ננסה לסכם חלק מהשינויים, ההיגיון ונתיבי ההעברה בפוסטים האלה.