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.
A partir de agosto de 2021, Google៕ Play Console les solicitará a todas las apps nuevas lo siguiente:
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.
Este es el resumen de todos los cambios:
TIPO DE LANZAMIENTO
REEMPLAZO
REQUERIDO A PARTIR DE AGO 2021
Nuevas apps de Google Play
APK
Android App Bundle (AAB)
Nivel de API de destino establecido en 29+
Nivel de API de destino establecido en 30+
Archivos de expansión (OBB)
Play Asset Delivery o Play Feature Delivery
REQUERIDO A PARTIR DE NOV 2021
Actualizaciones de apps existentes de Google Play
Sin requisitos de formato de publicación nuevo
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.
minSdkVersion
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.
Este artículo forma parte de una serie sobre los cambios del atributo de cookies SameSite:
SameSite
Schemeful Same-Site modifica la definición de un sitio (web) de solo el dominio registrable al esquema + dominio registrable. Puedes encontrar más información y ejemplos en Información sobre "same-site" y "same-origin".
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.
SameSite=None; Secure
Puedes habilitar estos cambios para realizar la prueba tanto en Chrome como en Firefox.
chrome://flags/#schemeful-same-site
network.cookie.sameSite.schemeful
true
about:config
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.
SameSite=Lax
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.
SameSite=Strict
SameSite=None;Secure
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.
Secure
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.
SameSite=None
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.
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:
Errores de carga de subrecursos:
Hay más información disponible en Sugerencias de pruebas y depuración para Schemeful Same-Site.
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:
cookie_name
http://site.example/
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.
includeSubDomain
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.
Lax
Strict
None
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.
Las conexiones WebSocket aún se considerarán del mismo sitio si están en la misma seguridad que la página.
Mismo sitio:
wss://
https://
ws://
http://
Entre sitios:
Fotografía de Julissa Capdevilla en Unsplash