Microsoft se une a la fiesta de alternativas cookieless y, como dice Antonio Andújar en este post de LinkedIn, claramente con ironía hacia Google, pues también utiliza un nombre de pájaro para el proyecto: PARAKEET = PERICO.

Esta propuesta de Microsoft no es nueva, ya que se anunció en febrero, pero ahora se ha "popularizado" después de que lo mencionaran para esquivar la pregunta de si habilitarían FLoC en su navegador Edge.

Tienen un repositorio en GitHub explicando con detalle la solución, que al igual que la propuesta FLoC de Google crea cohortes de usuarios, pero en vez de hacerlo en el navegador lo hace en un proxy server.:

¿Qué diferencia a PARAKEET del resto de soluciones del Privacy Sandbox de Google?

TURTLEDOVE

La diferencia más significativa entre PARAKEET y TURTLEDOVE es que TURTLEDOVE separa completamente las señales contextuales y de grupos de interés al realizar dos solicitudes separadas no correlacionadas y el conjunto de propuestas de TURTLEDOVE sigue evolucionando. El equipo de Google Chrome tiene una implementación de prototipo específico que combina ideas de esas propuestas llamado FLEDGE. PARAKEET es similar a FLEDGE en que también propone un servidor fiable para mediar en las solicitudes de anuncios, obtener paquetes de anuncios y proporcionar capacidades de medición. PARAKEET prevé que se confíe en el servicio para manejar contratos más complejos durante el flujo de publicación de anuncios para permitir ambos niveles sólidos de privacidad y, al mismo tiempo, conservar la capacidad de publicar anuncios relevantes al tener interacciones más directas con el SSP.

SPARROW

SPARROW es similar a TURTLEDOVE ya que los anuncios contextuales y basados en grupos de interés todavía se solicitan por separado. Sin embargo, en TURTLEDOVE la subasta se realiza por cuenta del cliente, mientras que en SPARROW se utiliza el servicio de gatekeeper para estimar las pujas y realizar la subasta publicitaria final. La similitud de SPARROW con PARAKEET es que la solicitud de anuncio del grupo de interés se realiza como parte del flujo de publicación de anuncios en lugar de obtenerla con anticipación. La principal diferencia es que PARAKEET permite que las redes publicitarias alberguen la funcionalidad del modelo de recuperación, subasta y licitación dentro del servicio de una red publicitaria, mientras que el modelo gatekeeper requiere que la red publicitaria comparta la funcionalidad de licitación y subasta con el servicio gatekeeper.

Dovekey

Dovekey involucra un servicio de mediador, similar a SPARROW y PARAKEET, para permitir que tanto las señales contextuales como las de los grupos de interés sean consideradas durante una subasta de anuncios y para resolver otros casos de uso críticos como el presupuesto. En Dovekey, el SSP necesita inyectar claves de forma preventiva en el servicio de clave-valor del mediador donde la efectividad se basa en cómo de bien puede predecir la señal contextual y las combinaciones de grupos de interés dentro de un presupuesto de claves. Dado que las señales combinadas utilizadas durante la subasta no van al SSP, no tiene una oportunidad directa de extraer conocimiento sobre los grupos de interés del cliente. Un riesgo potencial en el enfoque de Dovekey es que la búsqueda de anuncios creativos real podría revelar la información combinada a través de un ataque de tiempo (que, a su vez, podría mitigarse potencialmente al tener los paquetes de anuncios de búsqueda previa del servidor KV). Por el contrario, PARAKEET tiene limitaciones únicas que reducen el riesgo; un servidor Dovekey KV más complejo también podría agregar umbrales de privacidad. Tanto en Dovekey como en PARAKEET, es probable que exista cierto nivel de confianza en el servidor KV. Esa propuesta menciona posibles opciones para la computación entre dos partes y la recuperación de información privada

Seguiremos informando sobre cómo avanza esta y otras soluciones Cookieless.