Abandon et suppression du gestionnaire de paiement de la carte de base
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 la page Repenser la demande de paiement pour iOS.
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Suppression du champ "supportedType" de BasicCardRequest
Si vous spécifiez le paramètre "supportedTypes":[type] pour le mode de paiement "basic-card", seul le type demandé s'affiche, c'est-à-dire "crédit", "debit" ou "prepaid".
Le paramètre de type de carte a été supprimé des spécifications et a été supprimé de Chrome en raison de la difficulté à déterminer avec précision 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 faire confiance au filtre de type de carte dans le navigateur:
- Seules les banques émettrices connaissent le type de carte avec certitude, et les bases de données téléchargeables des types de cartes sont peu précises. Il est donc impossible de connaître avec précision le type de carte stockée localement dans le navigateur.
- Le mode de paiement par carte de base dans Chrome n'affiche plus les cartes Google Pay, qui peuvent être associées à des banques émettrices.
Intention de suppression | É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. Son utilisation ne peut donc pas être utilisée de manière interopérable. Dans la plupart des cas d'utilisation, elle peut être remplacée par une combinaison d'animation de la propriété display et d'un gestionnaire de rappel/d'événements de suppression (JavaScript).
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Supprimer TLS 1.0 et TLS 1.1
Le protocole TLS (Transport Layer Security) sécurise le protocole HTTPS. Il a une longue histoire qui remonte à près de 20 ans, TLS 1.0 et son prédécesseur plus ancien, SSL. TLS 1.0 et 1.1 présentent un certain nombre de points faibles.
- TLS 1.0 et 1.1 utilisent MD5 et SHA-1, tous deux des hachages faibles, dans le hachage de la transcription du message "Finished" (Terminé).
- TLS 1.0 et 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 1.1 ne sont compatibles qu'avec les algorithmes de chiffrement RC4 et CBC. RC4 est cassé et a depuis été supprimé. La construction du mode CBC de TLS est erronée et vulnérable aux attaques.
- De plus, les algorithmes de chiffrement CBC de TLS 1.0 construisent leurs vecteurs d'initialisation de manière incorrecte.
- TLS 1.0 n'est plus conforme à la norme PCI-DSS.
La compatibilité avec TLS 1.2 est une condition préalable pour éviter les problèmes ci-dessus. Le groupe de travail TLS a rendu TLS 1.0 et 1.1 obsolètes. Chrome a également abandonné ces protocoles.
Intention de suppression | Outil de suivi Chromestatus | Bug Chromium
Contournement du renforcement de la rétrogradation TLS 1.3
TLS 1.3 inclut une mesure de renforcement rétrocompatible pour renforcer les protections de niveau inférieur. Toutefois, lorsque nous avons lancé 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 applique actuellement une mesure de renforcement des certificats qui s'associent à des racines connues, mais autorise le contournement des certificats associés à des racines inconnues. Nous prévoyons de l'activer pour toutes les connexions.
La protection contre la rétrogradation atténue l'impact sur la sécurité des différentes anciennes options 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écouvertes, il est plus facile d'y répondre. ce qui se traduit par moins de sites non fonctionnels pour les utilisateurs par la suite. Ceci est également conforme à la norme RFC 8446.
Intention de suppression | État de la plate-forme Chrome | Bug Chromium
Règlement relatif aux abandons
Pour que la plate-forme reste opérationnelle, nous supprimons parfois de la plate-forme Web les API qui ont fait leurs preuves. Nous pouvons supprimer une API pour de nombreuses raisons, par exemple:
- Elles sont remplacées par des API plus récentes.
- Ils sont mis à jour pour refléter les modifications apportées aux spécifications, afin d'assurer leur cohérence et leur alignement avec les autres navigateurs.
- Il s'agit des premiers tests qui n'ont jamais abouti dans d'autres navigateurs et qui peuvent donc alourdir la charge de travail des développeurs Web.
Certaines de ces modifications auront une incidence sur un très petit nombre de sites. Pour limiter ces problèmes à l'avance, nous essayons d'en informer les développeurs au préalable afin qu'ils puissent apporter les modifications nécessaires afin que leurs sites continuent de fonctionner.
Chrome dispose actuellement d'un processus d'abandon et de suppression des API, essentiellement:
- Faites des annonces à la liste de diffusion blink-dev.
- Définissez des avertissements et des échelles de temps dans la console des outils pour les développeurs Chrome lorsque l'utilisation est détectée sur la page.
- Attendez, surveillez la fonctionnalité, puis supprimez-la lorsque son utilisation diminue.
Vous pouvez trouver une liste de toutes les fonctionnalités obsolètes sur chromestatus.com à l'aide du filtre obsolète et des fonctionnalités supprimées en appliquant le filtre supprimé. Nous essaierons également de résumer certains des changements, raisonnements et parcours de migration présentés dans ces posts.