Ciudad de México, mayo, 2019 – Los operadores web que utilizan la plataforma Google AMP («Páginas Móviles Aceleradas») webs creadas con un lenguaje de programación propio (AMP HTML), optimizado para que se carguen más rápidamente las páginas web en los dispositivos móviles, ahora tienen una solución para mostrar su propia URL en los sitios móviles desarrollados por AMP y en los resultados de búsqueda de Google.
Recientemente, Google anunció la disponibilidad de HTTP SXG (Signed Exchange) en el navegador Chrome, que permite a los editores de AMP utilizar certificados TLS/SSL habilitados para SXG y así mostrar correctamente el dominio del propietario del sitio. DigiCert es actualmente la única CA (autoridad certificadora, por su sigla en español) pública en el mundo que ofrece certificados TLS con SXG habilitado.
SXG es una estructura técnica que permite a los navegadores mostrar las URL de los editores en los resultados de AMP en caché. Actualmente, SXG está disponible para Chrome 73 y versiones más recientes (y se espera que llegue en una actualización de Microsoft Edge).
DigiCert proporciona certificados compatibles con SXG a través de la plataforma TLS de CertCentral Enterprise que permite a los clientes personalizar y automatizar todas las etapas de administración del ciclo de vida. Los certificados SXG están diseñados especialmente para ser confiados en el mismo ecosistema que el contenido HTTPS típico y para trabajar sincrónicamente con los certificados TLS tradicionales.
Un cambio esperado
Las páginas de AMP son comúnmente reconocidas por el pequeño símbolo del rayo junto a la URL en los resultados de búsqueda de Google en un dispositivo móvil. La falta de capacidad de AMP para mostrar la URL del propietario del sitio web, en lugar de una URL que comienza con Google (https://google.com/amp/example.com/amp-content-example) ha sido un problema para los desarrolladores desde el lanzamiento de AMP en 2015. El uso de certificados TLS con SXG habilitado supera este problema y brinda una gran ventaja a los comercializadores digitales, especialmente a aquellos con sitios que dependen de la marca y los ingresos que reciben un gran tráfico móvil.
¿Por qué usar AMP?
AMP se usa ampliamente, ya que permite a los editores web crear versiones especiales reducidas en su contenido web, que se almacenan en caché y se sirven a los usuarios móviles, a menudo directamente desde los resultados de búsqueda. Esto permite a los usuarios móviles obtener la información que están buscando mucho más rápidamente con cargas de páginas bastante rápidas. Si bien puede que no parezca mucho, un milisegundo o dos en el tiempo de carga de la página puede marcar una gran diferencia en la experiencia del usuario y en el tiempo que los visitantes del sitio permanecerán en una página antes de abandonar la página de carga más rápida. Un estudio de Akamai de 2017 reveló que cada retraso de 100 milisegundos en el tiempo de carga del sitio web puede afectar las tasas de conversión en un 7%, eso se suma a la pérdida de ingresos y oportunidades.
AMP fue desarrollado por Google como un proyecto de código abierto, para apoyar a los editores de contenido que necesitan versiones optimizadas de sus sitios de escritorio para usuarios de web móviles. En 2016, Google integró las páginas AMP en los resultados de búsqueda para fomentar aún más el rendimiento de la web móvil y fomentar la navegación web móvil.
Debido a que la mayoría de los sitios principales no estaban optimizados para la web, AMP requería que Google renderizará todo y usará la estructura de URL google.com/amp en caché, esto hizo posible que Google sirviera las páginas móviles más rápidamente a través de la web. El inconveniente fue que la estructura de URL requerida para AMP desgastó la URL de los resultados de búsqueda.
La introducción de SXG también fortalece la seguridad de la web móvil
Anteriormente, AMP no proporcionaba pruebas criptográficas a un usuario final de que el contenido servido por los servidores de Google era, de hecho, un byte a byte idéntico al contenido creado por el editor. En efecto, el origen cambió a la mitad del flujo del editor a AMP.
Usando las tecnologías actuales para que AMP resuelva este problema, probablemente hubiera terminado con una situación común en otros círculos donde el editor de contenido proporciona un certificado TLS en nombre del propietario del dominio. Este es, en sí mismo, un enfoque menos que ideal para el problema, ya que causa una mayor expansión de la clave privada.
En lugar de aprovechar el Statu quo, Google invirtió en la identificación de nuevos enfoques para resolver este problema de entrega de contenido inmutable. El resultado son intercambios HTTP firmados, que utilizan estándares de empaquetamiento web para proporcionar un mecanismo de firma de una secuencia de elementos concreta de información: una URL de solicitud, información de negociación de contenido y una respuesta.
Estos datos se empaquetan juntos, firmados por el editor de contenido y luego se entregan a AMP. Luego, AMP puede servir el contenido y mostrar la firma en el contenido como prueba criptográfica de que no se ha manipulado de ninguna manera. El origen se mantiene como el origen, con AMP actuando solo como un acelerador para servir el contenido.
Los desarrolladores de páginas AMP pueden usar certificados TLS de DigiCert para SXG para resolver sus problemas anteriores. El uso de esta solución garantiza que la memoria caché servida por terceros, como Google, pueda verificarse de manera independiente con su propia URL, y puede obtener pruebas contra cualquier posible manipulación de contenido.
*Para obtener más información sobre el soporte de SXG de CertCentral y DigiCert, visite https://www.digicert.com/google-amp-security-solutions/.
*Si está interesado, regístrese para obtener una cuenta de CertCentral aquí https://www.digicert.com/account/ietf/http-signed-exchange-account.php
*Para obtener más información sobre cómo emitir certificados compatibles con SXG en su cuenta, consulte https://docs.digicert.com/manage-certificates/certificate-profile-options/get-your-signed-http-exchange-certificate/.
