Bajas y eliminaciones en Chrome 81

Joe Medley
Jo Medley

.

Baja y eliminación del controlador de pagos de compatibilidad con tarjetas básicas

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 se inhabilitó temporalmente en Chrome para iOS. Para obtener todos los detalles, consulta Reconsideración de la solicitud de pago para iOS.

Intención de quitar | Estado de la plataforma Chrome | Error de Chromium

Se quitó el campo supportedType de BasicCardRequest.

Cuando especificas el parámetro "supportedTypes":[type] para la forma de pago "basic-card", se muestran tarjetas solo del tipo solicitado, que es "crédito", "debit" o "prepaid".

El parámetro de tipo de tarjeta se quitó de la especificación y ahora se quita de Chrome debido a la dificultad para 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 una precisión baja, por lo que es imposible conocer con exactitud el tipo de tarjetas almacenadas de forma local en el navegador.
  • En Chrome, la forma de pago "tarjeta básica" ya no muestra las tarjetas de Google Pay, que podrían tener conexiones con bancos emisores.

Intención de quitar | Estado de la plataforma Chrome | Error de Chromium

Quitar el elemento

En Chrome 81, se quita el elemento <discard>. Solo se implementa en Chromium y, por lo tanto, no es posible usarla de manera interoperabilidad. En la mayoría de los casos de uso, se puede reemplazar con una combinación de animación de la propiedad display y un controlador de eventos/devolución de llamada de eliminación (JavaScript).

Intención de quitar | Estado de la plataforma Chrome | Error de Chromium

Quitar 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 a TLS 1.0 de casi veinte años y su predecesor aún más antiguo, SSL. TLS 1.0 y 1.1 tienen algunas debilidades.

  • TLS 1.0 y 1.1 usan MD5 y SHA-1, ambos valores hash poco seguros, en el hash de transcripción para el mensaje Finalizado.
  • 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 algoritmos de cifrado RC4 y CBC. RC4 está roto y desde entonces se quitó. La construcción del modo CBC de TLS es defectuoso y es vulnerable a los ataques.
  • Además, los algoritmos de cifrado de CBC de TLS 1.0 construyen sus vectores de inicialización de forma incorrecta.
  • TLS 1.0 ya no es compatible con PCI-DSS.

Admitir TLS 1.2 es un requisito previo para evitar los problemas anteriores. El grupo de trabajo TLS dejó de estar disponible TLS 1.0 y 1.1. Chrome también ha dejado de usar estos protocolos.

Intent de quitar | Seguimiento de Chromestatus | Error de Chromium

Omisión del endurecimiento a una versión inferior de TLS 1.3

TLS 1.3 incluye una medida de endurecimiento compatible con versiones anteriores para fortalecer las protecciones a versiones anteriores. 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 de TLS que no cumplían con las políticas. Actualmente, Chrome implementa la medida de endurecimiento para los certificados que se encadenan con raíces conocidas, pero permite omitir los certificados encadenados hasta raíces desconocidas. Tenemos la intención de habilitarlo para todas las conexiones.

La protección por cambios a una versión inferior mitiga el impacto en la 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, responderlas es menos complicado. (Esto, a su vez, implica menos sitios dañados para los usuarios en el futuro). Esto también se alinea con RFC 8446.

Intención de quitar | Estado de la plataforma Chrome | Error de Chromium

Política de baja

Para mantener la plataforma en buen estado, a veces quitamos las APIs de la plataforma web que ejecutaron su curso. Puede haber muchos motivos por los que quitaremos una API, como los siguientes:

  • Se reemplazaron por API más nuevas.
  • Se actualizan para reflejar los cambios en las especificaciones a fin de alinear y mantener la coherencia con otros navegadores.
  • Se trata de experimentos iniciales que nunca tuvieron éxito en otros navegadores y, por lo tanto, pueden aumentar la carga de la asistencia para desarrolladores web.

Algunos de estos cambios afectarán a unos pocos sitios. A fin de mitigar los problemas con anticipación, tratamos de avisarles a los desarrolladores con un aviso anticipado para que puedan realizar los cambios necesarios y mantener sus sitios en ejecución.

Actualmente, Chrome cuenta con un proceso para la baja y la eliminación de las API, que es básicamente el siguiente:

  • Anunciarlo en la lista de distribución blink-dev.
  • Establece advertencias y asigna escalas en la consola de Herramientas para desarrolladores de Chrome cuando se detecte uso en la página.
  • Espera, supervisa y quita la función a medida que disminuye el uso.

Puedes encontrar una lista de todas las funciones obsoletas en chromestatus.com con el filtro obsoleto y las funciones quitadas aplicando el filtro quitado. También intentaremos resumir algunos de los cambios, el razonamiento y las rutas de migración de estas publicaciones.