Publicado por Hoi Lam, ingeniero de relaciones con desarrolladores para la Plataforma de Android
En 2021, seguiremos trabajando en nuestra actualización anual de nivel de API de destino, que les solicitará a las nuevas apps en agosto, y a todas las actualizaciones de apps en noviembre, que se orienten al nivel de API 30 (Android 11). Además, como anunciamos a principios de este año, Google Play les solicitará a las apps nuevas que usen el formato de pubilcación de Android App Bundle. Este trae los beneficios de las apps más pequeñas y los lanzamientos más simples a más usuarios y desarrolladores, y apoya las inversiones continuas en distribución avanzada.
Publicado por Hoi Lam, ingeniero de relaciones con desarrolladores para la Plataforma de Android
En 2021, seguiremos trabajando en nuestra actualización anual de nivel de API de destino, que les solicitará a las nuevas apps en agosto, y a todas las actualizaciones de apps en noviembre, que se orienten al nivel de API 30 (Android 11). Además, como anunciamos a principios de este año, Google Play les solicitará a las apps nuevas que usen el formato de pubilcación de Android App Bundle. Este trae los beneficios de las apps más pequeñas y los lanzamientos más simples a más usuarios y desarrolladores, y apoya las inversiones continuas en distribución avanzada.
Más de 750 000 apps y juegos ya se publican en etapa de producción en Google Play usando paquetes de aplicaciones. Las principales apps que realizaron el cambio ahorraron en promedio un 15% en su tamaño, en comparación con el uso de un APK universal. Los usuarios se beneficiaron con las descargas más pequeñas, y los desarrolladores, como Netflix y Riafy, notaron un aumento en sus tasas de éxito de instalaciones, lo cual tiene un mayor impacto en las regiones con más dispositivos de gama baja y velocidades de datos más lentas. Los desarrolladores que implementaron el cambio pueden usar funciones de distribución avanzada, como Play Asset Delivery y Play Feature Delivery. Valoramos mucho sus comentarios y planeamos incluir más funciones y opciones para Firma de apps de Play y paquetes Android App Bundle antes de implementar el cambio.
Requisitos para las apps nuevas
A partir de agosto de 2021, Google៕ Play Console les solicitará a todas las apps nuevas lo siguiente:
Usar Play Asset Delivery o Play Feature Delivery para publicar elementos o funciones cuyos tamaños de descarga excedan los 150 MB (ya no se admiten los archivos de expansión, OBB, para las apps nuevas)
Orientarse al nivel de API 30 (Android 11) o uno posterior y ajustarse a los cambios de comportamiento
Requisitos para las actualizaciones de apps existentes
A partir de noviembre de 2021, las actualizaciones de apps existentes deberán orientarse al nivel de API 30 o uno posterior y ajustarse a los cambios de comportamiento de Android 11. Las apps existentes que no reciban actualizaciones no se verán afectadas y se podrán seguir descargando desde Play Store.
Requisitos para experiencias instantáneas
El cambio a la publicación con Android App Bundle también impactará en las experiencias instantáneas que usan el formato ZIP para apps instantáneas heredado. A partir de agosto de 2021, las experiencias instantáneas nuevas y las actualizaciones de las existentes deberán publicar paquetes de aplicaciones instantáneas.
Las apps de Wear OS no están sujetas al nuevo requisito de nivel de API de destino.
Las apps todavía podrán usar cualquier minSdkVersion, así que no habrá cambios en tu capacidad de compilar aplicaciones para versiones anteriores de Android.
Para obtener más información sobre la transición a paquetes de apps, mira nuestra nueva serie de video: modern Android development (MAD) skills (habilidades para el desarrollo moderno de Android). Agradecemos sumamente a todos los desarrolladores que ya adoptaron los paquetes de apps y se orientaron al nivel de API 30. Esperamos seguir mejorando la plataforma de Android junto a ustedes.
Término clave: Esto significa que la versión HTTP insegura de un sitio, por ejemplo, http://website.example, y la versión HTTPS segura de ese sitio, https://website.example, ahora se consideran entre sitios.
La buena noticia es que, si tu sitio web ya fue totalmente actualizado a HTTPS, no necesitas preocuparte por nada. Nada cambiará para ti.
Si todavía no has actualizado totalmente tu sitio web, esa debería ser tu prioridad. Sin embargo, si hay casos en los que los visitantes de tu sitio van a elegir entre HTTP y HTTPS, algunos de esos escenarios comunes y el comportamiento de las cookies SameSite asociadas se describen a continuación.
Advertencia: El plan a largo plazo es eliminar gradualmente la asistencia a cookies de terceros por completo y reemplazarlas con alternativas que preserven la privacidad. Configurar SameSite=None; Secure en una cookie para permitir que se envíe entre esquemas solo debería considerarse una solución temporal en la migración hacia el HTTPS completo.
Puedes habilitar estos cambios para realizar la prueba tanto en Chrome como en Firefox.
Desde Chrome 86, habilita chrome://flags/#schemeful-same-site. Realiza un seguimiento del progreso en la página de estado de Chrome.
Desde Firefox 79, configura network.cookie.sameSite.schemeful como true mediante about:config. Realiza un seguimiento del progreso mediante la edición Bugzilla.
Una de las razones principales para cambiar a SameSite=Lax como la configuración predeterminada para cookies fue protegerse contra la falsificación de solicitudes entre sitios (CSRF). Sin embargo, el tráfico HTTP inseguro aún presenta una oportunidad para que los atacantes de la red falsifiquen las cookies que, luego, serán usadas en la versión HTTPS segura del sitio. Crear este límite entre sitios adicional entre esquemas proporciona una mayor defensa ante estos ataques.
Término clave: En los siguientes ejemplos en los que las URL tienen el mismo dominio registrable, p. ej., site.example, pero diferentes esquemas, por ejemplo, http://site.example frente a https://site.example, se utiliza la denominación entre esquemas.
Navegar entre versiones entre esquemas de un sitio web (por ejemplo, establecer vínculos desde http://site.example y https://site.example) antes permitía que se enviaran cookies SameSite=Strict. Ahora, esto se trata como una navegación entre sitios, lo que significa que las cookies SameSite=Strict se bloquearán.
Advertencia: Todos los navegadores populares bloquean el contenido mixto activo como las secuencias de comando y los iframes. Además, los navegadores, incluidos Chrome y Firefox, trabajan para lograr la actualización o el bloqueo del contenido mixto pasivo.
Cualquier cambio que hagas aquí se considerará una solución temporal mientras trabajas para actualizar por completo a HTTPS.
Entre los ejemplos de subrecursos, se incluyen imágenes, iframes y solicitudes de red realizadas con XHR o Fetch.
Antes, cargar un subrecurso entre esquemas en una página habría permitido que las cookies SameSite=Strict o SameSite=Lax se enviaran o configuraran. Ahora, esto se trata de la misma forma que cualquier otro subrecurso de terceros o entre sitios, lo que significa que cualquier cookie SameSite=Strict o SameSite=Lax se bloqueará.
Además, incluso si el navegador permite que se carguen recursos de esquemas inseguros en una página segura, se bloquearán todas las cookies en estas solicitudes, ya que las cookies de terceros o entre sitios requieren Secure.
Una página HTTP que incluye un subrecurso entre esquemas mediante HTTPS.
Antes, publicar entre versiones entre esquemas de un sitio permitía que las cookies configuradas con SameSite=Lax o SameSite=Strict se enviaran. Ahora, esto se trata como una publicación entre sitios: solo pueden enviarse cookies SameSite=None. Tal vez encuentres este escenario en sitios que presentan la versión insegura de manera predeterminada, pero los usuarios se actualizan a la versión segura al enviar el formulario de acceso o salida.
Como ocurre con los subrecursos, si la solicitud va de un contexto seguro, p. ej., HTTPS, a uno inseguro, p. ej., HTTP, se bloquearán todas las cookies en estas solicitudes, ya que las cookies de terceros o entre sitios requieren Secure.
Advertencia: La mejor solución aquí es asegurar que tanto la página de formulario como el destino estén en una conexión segura como HTTPS. Esto es particularmente importante si el usuario está ingresando información confidencial en el formulario.
Envío de formulario entre esquemas de HTTP a HTTPS.
Las herramientas para desarrolladores y la mensajería están disponibles en Chrome y Firefox.
Desde Chrome 86, la pestaña Error en DevTools incluirá errores Schemeful Same-Site. Puedes ver los siguientes errores destacados para tu sitio.
Errores de navegación:
«Migrar por completo a HTTPS para que las cookies se sigan enviando en solicitudes del mismo sitio» es una advertencia de que la cookie se bloqueará en una versión futura de Chrome.
«Migrar por completo a HTTPS para que las cookies se envíen en solicitudes del mismo sitio» es una advertencia de que la cookie se ha bloqueado.
Errores de carga de subrecursos:
«Migrar por completo a HTTPS para que las cookies se sigan enviando en subrecursos del mismo sitio» o «Migrar por completo a HTTPS para seguir permitiendo que las cookies se envíen a subrecursos del mismo sitio» son advertencias de que la cookie se bloqueará en una versión futura de Chrome.
«Migrar por completo a HTTPS para que las cookies se envíen a subrecursos del mismo sitio» o «Migrar por completo a HTTPS para permitir que las cookies se envíen mediante subrecursos del mismo sitio» son advertencias de que la cookie se ha bloqueado. Esta última advertencia también puede aparecer al publicar un formulario.
Desde Firefox 79, con network.cookie.sameSite.schemeful configurado como true mediante about:config, la consola mostrará un mensaje para los errores de Schemeful Same-Site. Tal vez veas lo siguiente en tu sitio:
«La cookie cookie_namepronto se tratará como una cookie entre sitios en oposición a http://site.example/ porque el esquema no coincide».
«La cookie cookie_namese ha tratado como entre sitios en oposición a http://site.example/ porque el esquema no coincide».
Mi sitio ya está disponible por completo en HTTPS; ¿por qué veo errores en DevTools de mi navegador? #
Es posible que algunos de tus vínculos y sus recursos aún apunten a URL inseguras.
Una forma de solucionar este error es usar HTTP con Seguridad de Transporte Estricta (HSTS) y la directiva includeSubDomain. Con HSTS + includeSubDomain, incluso si una de tus páginas incluye un vínculo inseguro por accidente, el navegador usará en su lugar la versión segura automáticamente.
Si bien recomendamos enfáticamente que actualices tu sitio completo a HTTPS para proteger a tus usuarios, si no puedes hacerlo solo, te sugerimos que hables con tu proveedor de hosting para ver si te ofrece esa opción. Si usas tu propio host, entonces Let's Encrypt proporciona herramientas para instalar y configurar un certificado. También puedes investigar la posibilidad de mover tu sitio a CDN o a otro proxy que pueda proporcionar la conexión HTTPS.
Si eso tampoco es posible, intenta disminuir la protección SameSite en las cookies afectadas.
En los casos donde solo las cookies SameSite=Strict se bloquean, puedes disminuir la protección a Lax.
En los casos donde tanto las cookies Strict como Lax se bloquean y tus cookies se envían a una URL segura o se configuran desde una, puedes disminuir las protecciones a None.
Esta solución alternativa fallará si la URL a la que envías las cookies (o desde donde las configuras) es insegura. Esto se debe a que SameSite=None requiere el atributo Secure en las cookies, lo cual significa que esas cookies podrían no enviarse ni configurarse a través de una conexión insegura. En ese caso, no podrás acceder a esa cookie hasta que tu sitio se actualice a HTTPS.
Recuerda que esto es solo temporal, ya que las cookies de terceros se eliminarán por completo.
¿Cómo afecta esto a mis cookies si no especifiqué un atributo SameSite? #
Las cookies sin un atributo SameSite se tratan como si especificaran SameSite=Lax y el mismo comportamiento entre esquemas se aplica a ellas. Ten en cuenta que la excepción temporal para métodos poco seguros aún se aplica. Para obtener más información, consulta la mitigación Lax + POST en las preguntas frecuentes de ChromiumSameSite.
