Publicado por Tom Grinsted, gerente de Producto de Google Play
Hoy, en Google Play Console, lanzamos un conjunto de métricas nuevas y puntos de referencia únicos. Si los usas, puedes evaluar las tendencias de captación y monetización de tus app y juegos comparándolas con un total de hasta 250 elementos homólogos diferentes, lo que te ayudará a tomar decisiones más fundamentadas y efectivas respecto del mapa de ruta y de las oportunidades de tus productos.
No importa si quieres priorizar nuevas funciones para incrementar la participación, experimentar con los precios o mejorar la retención: todos los desarrolladores nos comentan que necesitan datos y estadísticas de calidad que los ayuden a invertir de la mejor manera.
Aunque algunos de los grandes desarrolladores tengan la posibilidad de comparar datos de sus carteras, no siempre es posible hacerlo; al ingresar a un nuevo territorio, una posibilidad sería ingresar sin publicar apps similares o publicar únicamente uno o dos juegos para empezar. En estos casos, ¿cómo sabes si el rendimiento de tu app o de tu juego es bueno y en qué áreas podrías mejorar?
Con este lanzamiento, ayudamos a todos los desarrolladores a contextualizar y comprender mejor su rendimiento. Aquí te comentamos las novedades:
Nuevas métricas de participación y monetización
En colaboración con expertos en apps móviles y en crecimiento de juegos, lanzamos un nuevo conjunto de métricas de captación y monetización basado en las prácticas recomendadas de evaluación de rendimiento de apps y juegos. Se incluye lo siguiente:
Lanzamos un total de 15 nuevas métricas normalizadas con comparativas y también ponemos a disposición los numeradores y denominadores absolutos para que los consultes. Puedes encontrarlos en la nueva pestaña "Compare to peers" (comparar con elementos homólogos) en la página Estadísticas. Para una mayor practicidad, incluimos ahí otras métricas clave normalizadas como, por ejemplo, conversiones de directorios de tienda.
Haz un seguimiento de tu rendimiento a través de una comparación con elementos homólogos
Con el fin de impulsar el proceso de toma decisiones y ayudarte a descubrir áreas que ofrecen nuevas oportunidades, lanzamos todas estas nuevas métricas normalizadas, que incluyen la comparación con elementos homólogos como elemento estándar. Tendrás la posibilidad de hacer el seguimiento de tus métricas en el tiempo y de compararlas con un total de 25 tipos diferentes de apps y juegos como “juegos para combinar 3 elementos”, “audiolibros” o “cómics”.
Compara tu rendimiento con el de elementos homólogos en la página Estadísticas de Google Play Console.
Los filtros por países te permitirán personalizar estas estadísticas para que se adapten a tus necesidades comerciales. Por ejemplo, podrás ver si juegos similares a los tuyos generan más ingresos gracias a los usuarios en Japón, o bien si la función que tu equipo acaba de lanzar supera a otras apps similares en términos de lealtad en India.
Probamos este conjunto de estadísticas nuevas con socios seleccionados durante el proceso de desarrollo. Los comentarios que nos hicieron fueron útiles para darle forma a nuestro enfoque y, además, positivos:
Guy Ulmer, Plarium Global Ltd.
Aprovecha al máximo estas nuevas métricas y estadísticas con el nuevo curso que lanzamos en Play Academy y ponte al día. También puedes echar un vistazo a nuestros seminarios web de clases magistrales sobre cómo impulsar de manera exponencial tu crecimiento.
Sólida protección de la privacidad para usuarios y desarrolladores
Los datos que utilizan estas nuevas métricas provienen de usuarios que aceptaron compartir su actividad con Google y se moldean para que representen mejor a toda la población. Estos simplemente registran si una app está abierta en primer plano. Los usuarios tienen el control de sus datos y pueden optar por no compartirlos, o bien borrar determinados eventos, en myactivity.google.com.
Además, estas nuevas métricas para desarrolladores son las primeras en usar privacidad diferencial, una técnica avanzada que proporciona mayor protección de la privacidad en todos los conjuntos de datos. Puedes obtener más información sobre este enfoque en nuestro blog técnico.
Al igual que lo que sucedió con los lanzamientos anteriores de puntos de referencia, todas las métricas de comparación con elementos homólogos vienen con una función de protección de la privacidad de los desarrolladores. Los datos se generan a partir de una gran cantidad de apps y juegos, y los grupos de elementos homólogos, impulsados por el sistema avanzado de etiquetado de Play Store, no comparten el rendimiento de apps individuales. Por ello, a pesar de que puedes encontrar comparaciones con conjuntos de elementos homólogos de alta calidad, confiables y útiles, trabajamos para ocultar el rendimiento individual de las apps de los competidores de los conjuntos de elementos homólogos que ves, y, a su vez, para ocultar el rendimiento de tu app de los conjuntos de elementos homólogos que verán los demás.
Pronto habrá más novedades
Este es el primer lanzamiento de un proyecto de varios años, que permite mostrar en Google Play Console más estadísticas útiles y recomendaciones activas. Los desarrolladores de las apps móviles más grandes suelen recurrir a consultores de crecimiento para que los asistan en la toma de decisiones estratégicas fundamentadas a largo plazo en relación con los productos. Estamos trabajando para acercar este tipo de ayuda y experiencia a todos los desarrolladores de Play a través de Play Console. ¡Consulta los lanzamientos del próximo año!
¿Cuán útil te resultó esta entrada de blog?
★ ★ ★ ★ ★
El FLoC brinda un mecanismo para mantener la privacidad en relación con la selección de anuncios basados en los intereses de los usuarios.
A medida que un usuario recorre la web, su navegador utilizar el algoritmo de FLoC para determinar a qué “cohorte de interés” pertenece, el cual será igual al de miles de navegadores con historiales de navegación similares. El navegador recalcula su cohorte periódicamente en el dispositivo del usuario, sin compartir los datos de navegación individuales con el proveedor del navegador ni nadie más.
Los anunciantes (sitios web que pagan por anuncios) pueden incluir código en sus sitios web para recopilar y brindar datos de la cohorte a sus plataformas de tecnología publicitaria (empresas que ofrecen software y herramientas para lanzar anuncios). Por ejemplo, la plataforma de tecnología publicitaria puede aprender de una tienda de zapatos en línea que los navegadores de las cohortes 1101 y 1354 parecen estar interesados en el equipamiento de senderismo que ofrece la tienda. En el caso de otros anunciantes, la plataforma de tecnología publicitaria aprende acerca de otros intereses de esas cohortes.
Posteriormente, la plataforma publicitaria utiliza estos datos para seleccionar los anuncios relevantes (como botas para senderismo de la tienda de zapatos) cuando un navegador de una de las cohortes solicita una página de un sitio web que muestra anuncios, como un sitio web de noticias.
Privacy Sandbox es una serie de propuestas que buscan satisfacer los casos de uso de terceros sin cookies de terceros ni otros mecanismos de seguimiento. Echa un vistazo a Digging into the Privacy Sandbox para acceder a una descripción general de todas las propuestas.
¡Necesitamos sugerencias sobre esta propuesta! Si tienes algún comentario, por favor crea un asunto en nuestro repositorio FLoC Explainer. Si tienes sugerencias sobre el experimento de Chrome con esta propuesta, publica una respuesta en Intent to Experiment.
Muchas empresas dependen de los anuncios para impulsar el tráfico hacia sus sitios web y muchos sitios web de publicadores financian su contenido vendiendo inventarios publicitarios. En general, las personas prefieren ver anuncios relevantes y útiles. A su vez, los anuncios relevantes pueden brindarles más oportunidades de negocios a los anunciantes y más ingresos a los sitios web que los alojan. Dicho de otra manera: el espacio publicitario es más valioso cuando muestra anuncios relevantes. Por lo tanto, seleccionar anuncios relevantes aumenta los ingresos de los sitios web que se sustentan a través de la publicidad. Esto también significa que los anuncios relevantes ayudan a financiar la creación de contenido que beneficia a los usuarios.
Sin embargo, a muchos les preocupan las implicancias sobre privacidad de la publicidad personalizada, que actualmente se basa en técnicas como las cookies de seguimiento y la huella digital de dispositivos, que se utilizan para hacer un seguimiento del comportamiento de navegación de los individuos. La propuesta del FLoC busca facilitar una selección de anuncios más efectiva sin comprometer la privacidad.
El ejemplo a continuación describe los diferentes roles en juego a la hora de seleccionar un anuncio usando FLoC.
El anunciante (una empresa que paga por publicidad) en este ejemplo es una tienda en línea de zapatos:tiendadezapatos.example
El publicador (un sitio web que vende espacio publicitario) en este ejemplo es un sitio web de noticias:noticiasdiarias.example
La plataforma de tecnología publicitaria (que ofrece software y herramientas para lanzar anuncios) es:reddepublicidad.example
En este ejemplo, llamaremos a los usuarios Yoshi y Alex. En principio, los navegadores de ambos pertenecen a la cohorte 1354.
Asignamos a los usuarios los nombres Yoshi y Alex únicamente a los fines de este ejemplo. Con FLoC, el nombre y la identidad personal de los usuarios no se revelan al anunciante, al publicador ni a la plataforma de tecnología publicitaria.
No imagines un conjunto de personas cuando piensas en una cohorte. En realidad, se trata del agrupamiento de la actividad de navegación.
Ahora es el turno de Alex.
Las técnicas actuales para la selección de anuncios se basan en métodos como las cookies de seguimiento y las huellas digitales de dispositivos, que son utilizados por terceros como los anunciantes para hacer un seguimiento del comportamiento de navegación de los individuos.
Con FLoC, el navegador no comparte su historial de navegación con el servicio FLoC ni con nadie más. El navegador, en el dispositivo del usuario, descifra a qué cohorte pertenece. El historial de navegación del usuario nunca deja el dispositivo.
El historial de navegación del usuario no se comparte en ninguna instancia del proceso con el servicio de FLoC, ni con terceros. El propio navegador es el encargado de calcular su cohorte en el dispositivo del usuario. El servicio de FLoC no obtiene ni almacena ningún dato del usuario.
¡SÍ! La cohorte de un navegador puede cambiar. Lo más probable es que no visites los mimos sitios web cada semana, y la cohorte de tu navegador reflejará eso.
Una cohorte representa un clúster de actividad de navegación, no un grupo de personas. Las características de la actividad de una cohorte suelen ser similares a medida que pasa el tiempo, y las cohortes son útiles para seleccionar anuncios porque agrupan comportamientos de navegación similares recientes. Los navegadores de los individuos entrarán y saldrán de una cohorte a medida que su comportamiento de navegación cambie. En principio, esperamos que el navegador recalcule su cohorte cada siete días.
En el ejemplo anterior, los navegadores de Yoshi y Alex pertenecen a la cohorte 1354. En el futuro, si sus intereses cambian, puede ocurrir que sus navegadores usen una cohorte diferente. En el ejemplo a continuación, el navegador de Yoshi pasa a usar a la cohorte 1101 y el navegador de Alex la 1378. Los navegadores pasarán de una cohorte a otra a medida que los intereses cambien.
Una cohorte representa un conjunto de actividades de navegación, no un grupo de personas. Los navegadores pasarán de una cohorte a otra a medida que la actividad cambie.
Como se mencionó anteriormente, el navegador del usuario obtiene datos de su servicio de FLoC que describen el modelo matemático de las cohortes: un espacio multidimensional que representa la actividad de navegación de todos los usuarios. El navegador utiliza un algoritmo para descifrar la región de este «espacio de cohortes» (es decir, la cohorte) que coincide mejor con su comportamiento reciente de navegación.
Habrá miles de navegadores en cada cohorte.
Las cohortes más pequeñas serán más útiles para personalizar anuncios, pero tendrán menos posibilidades de detener el seguimiento de usuarios. Y viceversa. Un mecanismo para asignar navegadores a cohortes necesita una solución intermedia entre la privacidad y la utilidad. Privacy Sandbox utiliza el k-anonimato para permitir a los usuarios «esconderse entre la multitud». Una cohorte es «k-anónima» si al menos «k» usuarios la comparten. Cuanto mayor sea el número k, mayor será la capacidad de la cohorte de preservar la privacidad.
El algoritmo de segmentación utilizado para construir el modelo de cohortes del FLoC está diseñado para evaluar si una cohorte puede tener alguna correlación con categorías sensibles, sin aprender por qué la categoría resulta sensible. Se bloquearán las cohortes que puedan revelar categorías sensibles como la raza, la orientación sexual o el historial médico. Es decir que, a la hora de descifrar su cohorte, el navegador solo estará eligiendo entre cohortes que no revelarán información sensible.
Con FLoC, el navegador de un usuario formará parte de una de las miles de cohortes, junto con otros miles de navegadores de otros usuarios. A diferencia de lo que ocurre con las cookies de terceros y otros mecanismos de segmentación, el FLoC solo revela la cohorte en la que se encuentra el navegador del usuario, no su ID individual. No permite que otros distingan individuos dentro de una cohorte. Además, la información sobre la actividad de navegación que el navegador usa para determinar a qué cohorte pertenece se mantiene en el navegador o dispositivo de manera local, y no se sube a ningún otro lado. El navegador, por otra parte, puede aprovechar otros métodos de anonimización, como la privacidad diferencial.
Los sitios web tienen la opción de habilitar o deshabilitar el FLoC, por lo cual en aquellos sobre temas sensibles se podrán excluir las visitas al sitio del cálculo de FLoC. Como protección adicional, el servicio de FLoC llevará adelante un análisis para evaluar si una cohorte puede llegar a revelar información sensible sobre los usuarios sin determinar por qué esa cohorte es sensible. Si una cohorte representa a un número mayor de lo habitual de personas que visitan sitios web en una categoría sensible, esa cohorte se elimina en su totalidad. Este análisis abarca categorías sensibles, como los problemas financiero o de salud mental, entre otras.
Los sitios web pueden deshabilitar FLoC configurando el encabezado de Políticas de permisos interest-cohort=(). Para la prueba de origen de FLoC en Chrome 89, los sitios web que no deshabiliten el servicio se incluirán en el cálculo de FLoC si Chrome detecta que son sitios web que cargan anuncios. (En Ad Tagging in Chromium se explica cómo funciona el mecanismo de detección de anuncios en Chrome). Por supuesto, los sitios web también pueden simplemente no acceder ni registrar el ID de cohorte de sus visitantes.
interest-cohort=()
La API de FLoC es muy sencilla: es un único método que devuelve una promesa, la cual se resuelve en un objeto que brinda una cohorte id y version:
id
version
document.interestCohort()
Así se ve cuando los datos de la cohorte se vuelven disponibles:
{ "id": "1415926", "version": "chrome.1.0"}
El valor version permite que los sitios web que utilizan el FLoC identifiquen el navegador y el modelo de FLoC a los que hace referencia el ID de la cohorte. Como se describe a continuación, la promesa que document.interestCohort() muestra rechazará cualquier marco que no tenga permiso interest-cohort.
interest-cohort
La API de FLoC está disponible en Chrome 89 y versiones posteriores, pero si no forma parte de la prueba de origen deberás configurar las funciones experimentales y ejecutar Chrome desde la línea de comandos. En Run Chromium with flags se explica cómo puedes hacer esto en diferentes sistemas operativos.
Inicia Chrome con las siguientes funciones experimentales:
--enable-blink-features=InterestCohortAPI --enable-features="FederatedLearningOfCohorts:update_interval/10s/minimum_history_domain_size_required/1"
Asegúrate de que las cookies de terceros no esté bloqueadas y que ningún bloqueador de anuncios esté en ejecución.
Echa un vistazo a la demo en floc.glitch.me.
En How to take part in the FLoC origin trial se explica cómo puedes probar FLoC en un contexto propio o de terceros.
Las políticas de permisos interest-cohort permiten a los sitios web declarar que no deben quedar incluidos en la lista de sitios del usuario a los fines del cálculo de la cohorte. La política predeterminada será allow. La promesa que document.interestCohort() muestra rechazará cualquier marco que no tenga permiso interest-cohort. Si el marco principal no tiene interest-cohort permission, la visita a la página no se incluirá en el cálculo de interés de la cohorte.
allow
interest-cohort permission
Por ejemplo, un sitio web puede deshabilitar todos los cálculos de cohortes FLoC enviando el encabezado de respuesta HTTP:
Permissions-Policy: interest-cohort=()
Si tienes algún comentario sobre la API, crea un asunto en nuestro repositorio FLoC Explainer.
Foto de Rhys Kentish en Unsplash.
Tras un primer año muy exitoso, en el que estudiantes universitarios de toda la región tuvieron la oportunidad de involucrarse en proyectos tecnológicos y recibir mentoría de profesionales y expertos de la industria de la computación y la industria digital, Google Developers anuncia que la convocatoria para líderes del programa Google Developer Student Clubs (GDSC) está abierta.
Los GDSC son comunidades de estudiantes universitarios interesados en tecnologías de Google como Android, Flutter o Google Cloud Platform, entre otras. Para pertenecer no es necesario estudiar carreras relacionadas con tecnología o tener conocimientos previos en informática o programación: el único requisito es ser estudiante de pregrado o posgrado y tener inquietud en aprender sobre desarrollo de software y tecnología.
Los o las líderes de los clubes deben ser estudiantes de pregrado o posgrado que estén a un año o más de terminar sus estudios, y deben estar en capacidad de comprometerse con el GDSC por un año. No es obligatorio cursar carreras relacionadas con la computación, pero sí lo es demostrar habilidades de programación o de ingeniería de software, tener conexiones con la comunidad local de desarrolladores y contar con experiencia organizando y liderando eventos. Además, deben tener interés en generar un impacto sirviendo a su comunidad.
Los leads deben comprometerse durante un año a liderar al menos una reunión cada tres meses (preferiblemente una al mes) y a asistir a los demás encuentros y capacitaciones que Google organice. También es importante que conozcan, cumplan y hagan cumplir los Lineamientos de comunidad de Google Developers.
¿Te interesa? Inscríbete aquí antes del domingo 30 de mayo. Ten en cuenta que deberás llenar el formulario en inglés. Te sugerimos verificar en este enlace si en tu escuela hay un GDSC (aunque no es necesario que el grupo ya exista en tu universidad para postular, ya que puedes comenzar uno en tu escuela). Si lo hay, sería genial que te contactaras con la o el líder del grupo para conocer su experiencia y recomendaciones.
Una vez elegidos, los líderes reciben un entrenamiento por parte de Google, en el que se les ofrecen diferentes recursos y herramientas con las que luego deberán ayudar a los miembros de sus clubes a cumplir sus objetivos. Así como retos y otras herramientas que se irán agregando al programa.
Además de su entrenamiento, los líderes de los GDSC formarán parte de una red global y estarán conectados con otros programas de Google Developers, lo que les permitirá ampliar sus redes profesionales y conocer personas que pueden ser importantes para su futuro profesional. Hay más de 1.250 grupos GDSC en más de 106 países de América, Europa, Asia, África y Oceanía; que organizan cientos de eventos cada año. Aquí puedes encontrar algunas historias de éxito del programa.
“La experiencia de manejar un GDSC les ayudará a mejorar sus habilidades de liderazgo y a convertirse en profesionales más integrados a su comunidad”, opina Solsona. “Es un año intenso, pero lleno de oportunidades”.
Tras un arduo proceso de selección, Google for Startups se complace en anunciar las 13 compañías latinoamericanas seleccionadas para la versión de primavera 2021 del Google for Startups Accelerator LATAM. Este programa está dirigido a startups en etapa de crecimiento provenientes de toda Hispanoamérica. El programa inicia el 5 abril, durará dos meses, y —tal como las dos últimas ediciones de Accelerator— será totalmente virtual.
Los fundadores de las compañía seleccionadas contarán con el apoyo de decenas de mentores y speakers expertos en temas de negocio; mercadeo, branding y relaciones públicas; cultura organizacional, inteligencia artificial y machine learning; y Google Ads, Google Cloud y Android Play; entre otras tecnologías y habilidades organizacionales. Con la ayuda de estos mentores y una metodología que incorpora la experiencia de Google impulsando a algunas de las startups más exitosas de la región, Accelerator será una experiencia definitiva para que las empresas de esta cohorte definan sus prioridades y establezcan los cimientos de su crecimiento futuro.
“Hace un año exactamente estaba programado el inicio de nuestro programa de aceleración en la primera semana de abril de 2020. La pandemia nos forzó a posponer el inicio un par de veces, hasta que nos dimos cuenta que era necesario crear una versión en línea. Desde aquella, nuestra primera edición virtual, hemos aprendido mucho. El programa ofrece más y mejores talleres enfocados en apoyar el crecimiento remoto y distribuido de equipos, optimizar estrategias de negocio, y ajustar recursos y mensajes a usuarios o clientes que están pasando momentos difíciles. Además, desarrollamos versiones modernas y compactas de nuestros talleres insignia: AI/ML, PAIR, modernización de infraestructura y cloud, innovación, cultura, growth, storytelling y OKR; entre otros”, dice Francisco Solsona, Lead de Google Developers para Hispanoamérica.
Es así como Accelerator incluyó una sección dedicada a compartir las mejores prácticas de trabajo remoto y distribuido geográficamente, y reforzó los contenidos relacionados con economía, finanzas y relaciones con inversionistas, dada la urgencia de estos temas en medio de la crisis. Además, el programa ofrece espacios virtuales de relacionamiento y mentoría, que puedan ayudarles a los emprendedores seleccionados a construir contactos de manera eficaz.
Accelerator les permitirá a los emprendedores aprender de los mejores, escalar sus productos, superar desafíos en materia tecnológica y establecer conexiones con redes de emprendimiento en la región y en Sillicon Valley, para así convertirse en agentes de cambio e innovación en el ecosistema de nuestra región.
Las 13 startups seleccionadas de tres países (México, Colombia y Chile) se destacan por el talento de sus equipos y su probada capacidad para crear soluciones de talla global a problemas presentes en la región. Siete de ellas tienen mujeres en su equipo de liderazgo.
En esta cohorte, los sectores de fintech y ecommerce estuvieron especialmente representados, con cuatro compañías cada uno. Las demás compañías pertenecen a segmentos de mercado como finca raíz, salud, ciudades inteligentes e IA aplicada a los medios de comunicación. Son:
Beepquest - México: Ofrece una solución a las empresas para asegurar el cumplimiento de estándares, manuales de procedimientos y control de calidad.
Be-Go - México: Ofrece una solución sencilla a transportadores de carga para ofrecer sus servicios a quienes los necesiten.
Flat - México: Una aplicación que simplifica y acorta el proceso de venta de finca raíz.
Glitzi - México: Ofrece servicios de belleza y spa a domicilio a través de una solución online.
GuruHotel - México: Facilita a los hoteles poner en marcha y gestionar una plataforma de comercio electrónico en minutos, disminuyendo las comisiones a intermediarios y los costos de transacción.
Instaleap - Colombia: Ofrece soluciones para ayudarles a los comercios a agilizar y hacer más inteligente su logística de última milla.
Kredi - México: Ofrece a quienes necesitan créditos bancarios una forma de comparar sus opciones y agilizar el proceso de aprobación.
Medicato - México: Brinda acceso 24/7 a doctores y servicios de telemedicina a través de una app móvil.
Minu - México: Les permite a los empleadores ofrecerles a sus trabajadores la opción de devengar el salario ya trabajado, sin necesidad de créditos o adelantos de nómina.
Mozper - México: Les da a los padres la opción de generar y gestionar una tarjeta bancaria para sus hijos, fomentando hábitos de ahorro y educación financiera.
Vestuá - Chile: Marketplace de ropa usada, que les permite a las personas obtener piezas de buena calidad a buen precio y darles un fin de vida útil responsable a las prendas que ya no usen.
Vexi - México: Proveedor de tarjetas de crédito enfocado en los jóvenes que comienzan su vida crediticia, que ofrece soluciones para manejar los gastos y administrar la tarjeta de forma responsable.
Vozy - Colombia: Desarrolla soluciones de inteligencia artificial basadas en voz para empresas, como asistentes digitales o análisis biométricos.
“La pandemia continúa en nuestra región y hoy celebro que estas 13 startups siguen luchando, abriéndose un espacio en sus respectivas verticales, ofreciendo trabajo digno y opciones de crecimiento a decenas de personas. Estas emprendedoras y emprendedores, junto con sus equipos, hacen que todo el esfuerzo valga la pena.”, completa Francisco Solsona
Al finalizar el programa, estas startups formarán parte del prestigioso grupo internacional de alumni de Google Launchpad Accelerator, donde se unirán a otras compañías latinoamericanas de gran escala como Canasta Rosa, Ben & Frank, Platzi, Konfio, Ualá, La Haus, Ripio, ComparaOnline, Tienda Nube, y Miroculus, entre otras.
Acerca de Google for Startups Accelerator LATAM
Google for Startups Accelerator es la evolución de más de seis años de experiencia del equipo Google Developers trabajando con startups en más de 40 países, a través de su programa Launchpad. GFS Accelerator incluye una programación de vanguardia en temas cruciales, acercando emprendedores y startups a distintos expertos de Google, así como a la red de aliados y colaboradores en la región: fondos de inversión, aceleradoras y empresas.
GFS Accelerator LATAM se ejecuta en conjunto con Centraal México, y otros aliados estratégicos en diferentes países, así como decenas de profesionales que conforman nuestra selecta red de mentores y aliados.
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
