Baja y eliminación del controlador de pagos compatible con "basic-card"
Esta versión de Chrome quita el polyfill de tarjeta básica para la API de Payment Request en Chrome para iOS. Como resultado, la API de Payment Request está inhabilitada temporalmente en Chrome para iOS. Para obtener más información, consulta Repensar la solicitud de pago para iOS.
Intento de eliminación | Estado de la plataforma de Chrome | Error de Chromium
Se quitó el campo supportedType de BasicCardRequest.
Si especificas el parámetro "supportedTypes":[type] para la forma de pago "basic-card", se muestran las tarjetas solo del tipo solicitado, que es "credit", "debit" o "prepaid".
El parámetro de tipo de tarjeta se quitó de las especificaciones y ahora se quita de Chrome debido a la dificultad de determinar con precisión el tipo de tarjeta. Actualmente, los comercios deben verificar el tipo de tarjeta con su PSP, ya que no pueden confiar en el filtro de tipo de tarjeta del navegador:
- Solo los bancos emisores conocen el tipo de tarjeta con certeza, y las bases de datos de tipos de tarjetas descargables tienen baja precisión, por lo que es imposible conocer con exactitud el tipo de tarjetas almacenadas de forma local en el navegador.
- La forma de pago "tarjeta básica" en Chrome ya no muestra tarjetas de Google Pay, que pueden tener conexiones con bancos emisores.
Intento de eliminación | Estado de la plataforma de Chrome | Error de Chromium
Quita el elemento .
En Chrome 81, se quita el elemento <discard>. Solo se implementa en Chromium, por lo que no es posible usarlo de forma interoperable. En la mayoría de los casos de uso, se puede reemplazar por una combinación de animación de la propiedad display y un controlador de eventos o devolución de llamada de eliminación (JavaScript).
Intento de eliminación | Estado de la plataforma de Chrome | Error de Chromium
Se quitaron TLS 1.0 y TLS 1.1
TLS (seguridad de la capa de transporte) es el protocolo que protege HTTPS. Tiene una larga historia que se remonta al TLS 1.0 de hace casi veinte años y a su predecesor aún más antiguo, SSL. Tanto TLS 1.0 como 1.1 tienen varias debilidades.
- TLS 1.0 y 1.1 usan MD5 y SHA-1, ambos hashes débiles, en el hash de transcripción del mensaje de fin.
- TLS 1.0 y 1.1 usan MD5 y SHA-1 en la firma del servidor. (Nota: Esta no es la firma del certificado).
- TLS 1.0 y 1.1 solo admiten los algoritmos de cifrado RC4 y CBC. RC4 está dañado y, desde entonces, se quitó. La construcción del modo CBC de TLS es defectuosa y es vulnerable a ataques.
- Además, los algoritmos de cifrado CBC de TLS 1.0 construyen sus vectores de inicialización incorrectamente.
- TLS 1.0 ya no cumple con los estándares PCI-DSS.
La compatibilidad con TLS 1.2 es un requisito previo para evitar los problemas anteriores. El grupo de trabajo de TLS dejó de admitir TLS 1.0 y 1.1. Chrome también dio de baja estos protocolos.
Intento de eliminación | Chromestatus Tracker | Error de Chromium
Omisión del endurecimiento del regreso a una versión anterior de TLS 1.3
TLS 1.3 incluye una medida de endurecimiento retrocompatible para fortalecer las protecciones contra el cambio a una versión inferior. Sin embargo, cuando enviamos TLS 1.3 el año pasado, tuvimos que inhabilitar parcialmente esta medida debido a incompatibilidades con algunos proxies de terminación TLS no conformes. Actualmente, Chrome implementa la medida de endurecimiento para los certificados que se encadenan a raíces conocidas, pero permite un bypass para los certificados que se encadenan a raíces desconocidas. Tenemos la intención de habilitarlo para todas las conexiones.
La protección contra el cambio a una versión inferior mitiga el impacto de seguridad de las diversas opciones heredadas que conservamos para la compatibilidad. Esto significa que las conexiones de los usuarios son más seguras y, cuando se descubren vulnerabilidades de seguridad, es más fácil responder a ellas. (Esto, a su vez, significa que habrá menos sitios dañados para los usuarios en el futuro). Esto también se alinea con la RFC 8446.
Intento de eliminación | Estado de la plataforma de Chrome | Error de Chromium
Política de baja
Para mantener la plataforma en buen estado, a veces quitamos de la plataforma web las APIs que ya cumplieron su ciclo. Existen muchos motivos por los que quitamos una API, como los siguientes:
- Se reemplazan por APIs más recientes.
- Se actualizan para reflejar los cambios en las especificaciones y lograr la alineación y coherencia con otros navegadores.
- Son experimentos iniciales que nunca se materializaron en otros navegadores y, por lo tanto, pueden aumentar la carga de asistencia para los desarrolladores web.
Algunos de estos cambios afectarán a una cantidad muy pequeña de sitios. Para mitigar los problemas con anticipación, intentamos avisar a los desarrolladores con anticipación para que puedan realizar los cambios necesarios y mantener sus sitios en funcionamiento.
Actualmente, Chrome tiene un proceso para la baja y eliminación de APIs, que consiste en lo siguiente:
- Anunciar en la lista de distribución blink-dev
- Establece advertencias y proporciona escalas de tiempo en la consola de Herramientas para desarrolladores de Chrome cuando se detecta el uso en la página.
- Espera, supervisa y, luego, quita la función a medida que disminuya el uso.
Puedes encontrar una lista de todas las funciones obsoletas en chromestatus.com con el filtro obsoleto y las funciones quitadas con el filtro quitado. También intentaremos resumir algunos de los cambios, razonamientos y rutas de migración en estas publicaciones.