Abandon et suppression de la prise en charge du gestionnaire de paiement "basic-card"
Cette version de Chrome supprime le polyfill de carte de base pour l'API Payment Request dans Chrome pour iOS. Par conséquent, l'API Payment Request est temporairement désactivée dans Chrome pour iOS. Pour en savoir plus, consultez Réfléchir à la demande de paiement pour iOS.
Intent to Remove | État de la plate-forme Chrome | Bug Chromium
Suppression du champ "supportedType" de BasicCardRequest
Spécifier le paramètre "supportedTypes":[type] pour le mode de paiement "basic-card" n'affiche que les cartes du type demandé, qui peut être "credit", "debit" ou "prepaid".
Le paramètre de type de carte a été supprimé de la spécification et est maintenant supprimé de Chrome, car il est difficile de déterminer précisément le type de carte. Aujourd'hui, les marchands doivent vérifier le type de carte auprès de leur PSP, car ils ne peuvent pas se fier au filtre de type de carte dans le navigateur:
- Seules les banques émettrices connaissent avec certitude le type de carte, et les bases de données de types de cartes téléchargeables sont peu précises. Il est donc impossible de connaître avec précision le type de carte stocké localement dans le navigateur.
- Le mode de paiement "basic-card" dans Chrome n'affiche plus les cartes Google Pay, qui peuvent être associées à des banques émettrices.
Intent to Remove | État de la plate-forme Chrome | Bug Chromium
Supprimez l' élément .
Chrome 81 supprime l'élément <discard>. Il n'est implémenté que dans Chromium et n'est donc pas possible de l'utiliser de manière interopérable. Dans la plupart des cas d'utilisation, il peut être remplacé par une combinaison d'animation de la propriété display et d'un rappel/gestionnaire d'événements de suppression (JavaScript).
Intent to Remove | État de la plate-forme Chrome | Bug Chromium
Suppression de TLS 1.0 et TLS 1.1
TLS (Transport Layer Security) est le protocole qui sécurise HTTPS. Il a une longue histoire qui remonte à TLS 1.0, qui a près de vingt ans, et à son prédécesseur encore plus ancien, SSL. TLS 1.0 et TLS 1.1 présentent un certain nombre de failles.
- TLS 1.0 et 1.1 utilisent MD5 et SHA-1, deux hachages faibles, dans le hachage de la transcription pour le message Finished.
- TLS 1.0 et TLS 1.1 utilisent MD5 et SHA-1 dans la signature du serveur. (Remarque: il ne s'agit pas de la signature du certificat.)
- TLS 1.0 et TLS 1.1 ne prennent en charge que les algorithmes de chiffrement RC4 et CBC. RC4 est cassé et a été supprimé depuis. La construction du mode CBC de TLS est défectueuse et vulnérable aux attaques.
- De plus, les algorithmes de chiffrement CBC de TLS 1.0 ne construisent pas correctement leurs vecteurs d'initialisation.
- TLS 1.0 n'est plus conforme à la norme PCI DSS.
La prise en charge de TLS 1.2 est indispensable pour éviter les problèmes ci-dessus. Le groupe de travail TLS a abandonné TLS 1.0 et TLS 1.1. Chrome a également abandonné ces protocoles.
Intent to Remove | Chromestatus Tracker | Bug Chromium
Contournement du renforcement de la compatibilité avec TLS 1.3
TLS 1.3 inclut une mesure de renforcement rétrocompatible pour renforcer la protection contre le déclassement. Toutefois, lorsque nous avons déployé TLS 1.3 l'année dernière, nous avons dû désactiver partiellement cette mesure en raison d'incompatibilités avec certains proxys de terminaison TLS non conformes. Chrome implémente actuellement la mesure de renforcement pour les certificats qui se rattachent à des racines connues, mais permet de contourner cette mesure pour les certificats qui se rattachent à des racines inconnues. Nous prévoyons de l'activer pour toutes les connexions.
La protection contre la rétrogradation atténue l'impact de la sécurité des différentes options obsolètes que nous conservons pour la compatibilité. Cela signifie que les connexions des utilisateurs sont plus sécurisées et que, lorsque des failles de sécurité sont détectées, il est plus facile d'y répondre. (ce qui signifie moins de sites défectueux pour les utilisateurs à l'avenir). Cela est également conforme à la RFC 8446.
Intent to Remove | État de la plate-forme Chrome | Bug Chromium
Règlement d'obsolescence
Pour maintenir la plateforme en bon état, nous supprimons parfois des API de la plate-forme Web qui ont fait leur temps. Plusieurs raisons peuvent expliquer la suppression d'une API, par exemple:
- Elles sont remplacées par des API plus récentes.
- Elles sont mises à jour pour refléter les modifications apportées aux spécifications afin d'assurer l'alignement et la cohérence avec les autres navigateurs.
- Il s'agit de tests préliminaires qui n'ont jamais abouti dans d'autres navigateurs et qui peuvent donc alourdir la charge d'assistance pour les développeurs Web.
Certaines de ces modifications n'auront qu'un impact très limité sur un nombre très faible de sites. Pour atténuer les problèmes à l'avance, nous essayons de prévenir les développeurs à l'avance afin qu'ils puissent apporter les modifications nécessaires pour que leurs sites continuent de fonctionner.
Chrome dispose actuellement d'un processus d'abandon et de suppression des API, qui se résume comme suit:
- Annoncez-le sur la liste de diffusion blink-dev.
- Définissez des avertissements et indiquez des échelles de temps dans la console d'outils pour les développeurs Chrome lorsque l'utilisation est détectée sur la page.
- Attendez, surveillez, puis supprimez la fonctionnalité lorsque l'utilisation diminue.
Vous trouverez la liste de toutes les fonctionnalités obsolètes sur chromestatus.com à l'aide du filtre obsolète et des fonctionnalités supprimées à l'aide du filtre supprimé. Nous essaierons également de résumer certains des changements, des raisonnements et des chemins de migration dans ces articles.