Un WebView se vende como «solo un navegador». Para tu equipo de fraude y riesgo, es una lotería de identidad de dispositivo. La página carga, el usuario toca pagar y, en algún lado, un motor de riesgo puntúa la solicitud. Lo que no ve es que el «dispositivo» que puntúa cambia cada vez que la app abre una vista nueva o un modo privado borra la cookie jar. La misma persona se vuelve un dispositivo distinto — y tu tasa de rechazos falsos es la factura.
Tres particiones, tres formas de perder identidad
El problema no es un bug; son tres decisiones de partición independientes sumándose. En iOS, la Prevención de Rastreo (ITP) de WebKit particiona el LocalStorage e IndexedDB de terceros por primer parte y limita a siete días las cookies de cliente fijadas vía document.cookie. El propio documento de prevención de Apple indica que la política de cookies por defecto prohíbe a un tercero escribir cookies salvo que ya las tenga, y que el almacenamiento particionado se vuelve efímero. Encima, un WKWebView configurado con WKWebsiteDataStore.nonPersistent() — la forma estándar de implementar sesiones «privadas» o desechables — no guarda nada en disco y lo descarta todo al cerrarse la vista. En Android, el problema opuesto: el CookieManager es a nivel de proceso, así que no hay forma honesta de dar a un WebView una sesión aislada sin borrar de forma destructiva las cookies compartidas con todos los demás WebView de la app. La realidad multiplataforma es un parche donde la identidad a veces se particiona, a veces es efímera y a veces se comparte — y nunca bajo tu control.
Lo que ve el motor de riesgo
Las pilas de fraude y KYC dependen de una señal de dispositivo o instalación estable para separar a un buen cliente recurrente de un fraudster que abre contenedores nuevos. Cuando esa señal es un valor de cookie o localStorage que el sistema operativo particiona, expira o borra, el mismo usuario real se presenta como un dispositivo nuevo y anónimo en cada sesión. Ese es justo el patrón que los modelos de riesgo tratan como alto: dispositivo nuevo, sin historial, geo o comportamiento que no cuadra con la última sesión buena conocida. La plataforma no quiere bloquear al cliente; simplemente no lo reconoce. Mientras tanto, un fraudster real con un contenedor limpio es indistinguible de tu mejor cliente abriendo la app tras un borrado por ITP.
El costo es real y no es el fraude
El dinero perdido por rechazos falsos supera al perdido por fraude. La investigación de la industria recopilada por analistas de recuperación de pagos sitúa los ingresos de e-commerce perdidos por rechazos falsos en cerca de 443 mil millones de dólares al año, con cerca del 58% de todos los rechazos siendo falsos positivos y unos 13 dólares perdidos por rechazo falso por cada 1 dólar perdido por fraude. Un informe de Raconteur y Riskified encontró que solo en 2023, 1,57 billones de dólares de ventas de e-commerce de EE. UU. estuvieron expuestas a rechazos falsos, con 81 mil millones estimados como pérdida permanente, y el 47% de los minoristas dijo que los rechazos falsos dañaban severamente la satisfacción del cliente. Un cliente rechazado falsamente rara vez se queja — se va, y cerca de un tercio no vuelve. Cuando el derivamiento de cookies de tu WebView fabrica en silencio esos falsos positivos, el runtime te cuesta más que cualquier fraudster.
La presión por privacidad lo empeora
La partición agresiva de almacenamiento sí reduce el rastreo entre sitios, pero los investigadores de seguridad llevan años advirtiendo que empuja a la web hacia la huella de navegador opaca — señales derivadas del hardware y la configuración que el usuario no ve ni controla. Dentro de un WebView, eso significa que los equipos de fraude, privados de cookies de primera parte fiables, dependen más de la huella, que es justo lo que los regímenes de privacidad (GDPR y la propia postura de Apple) intentan restringir. Acabas eligiendo entre reconocer a tus propios clientes y respetar las reglas de privacidad, con el comportamiento de partición del WebView forzándote a lo peor de ambos.
La solución del runtime
Un runtime propio del host no le pide al navegador que recuerde quién es el usuario. Emite una identidad de dispositivo o instalación estable, firmada y con consentimiento desde la capa del host, e la inyecta de forma determinista en cada vista y cada solicitud — el mismo identificador aunque el WebView sea efímero, particionado o compartido. La conciliación de sesión del lado del servidor vincula esa identidad a la cuenta real, así los clientes recurrentes se reconocen incluso tras un borrado por ITP, y los fraudsters reales que abren contenedores nuevos siguen destacando. La identidad se vuelve una propiedad que el runtime garantiza, no una moneda al aire dentro del almacenamiento particionado.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Almacenamiento iOS | ITP particiona por primer parte; tope de cookies de 7 días | Identidad estable inyectada por el host |
| Vistas efímeras | nonPersistent() descarta toda identidad | Misma ID firmada en vistas efímeras |
| Almacenamiento Android | Cookie jar a nivel de proceso; sin aislamiento por vista | ID por instalación, no depende de CookieManager |
| Puntuación de riesgo | Identidad deriva por sesión → falsos positivos | Señal de dispositivo consistente → menos rechazos falsos |
| Privacidad | Empuja hacia huella opaca | Con consentimiento, primera parte, auditable |
El hilo conductor de esta serie es el control. Un WebView entrega a tu pila de fraude una identidad de dispositivo que no posee y no puede confiar. Un runtime te deja emitir una. Para un catálogo de páginas ajenas que transan dentro de tu app, esa diferencia es la grieta entre un checkout que convierte y uno que aleja en silencio a buenos clientes.
Fuentes
- WebKit Tracking Prevention — el almacenamiento de terceros se particiona por primer parte y las cookies de cliente se limitan a 7 días — documento de política de Apple: la política de cookies por defecto bloquea escrituras de terceros; LocalStorage/IndexedDB particionados se vuelven efímeros.
- Apple Developer —
WKWebsiteDataStore.nonPersistent()no guarda nada en disco — la configuración WebView privada/desechable estándar descarta todas las cookies y el almacenamiento al cerrarse. - Android
CookieManageres a nivel de proceso — sin aislamiento honesto por WebView — el modelo de seguridad señala que las sesiones efímeras fallan en Android porque las cookies se comparten en toda la app. - El Verdadero Costo de los Rechazos Falsos — ~$443B/año; 58% de los rechazos son falsos positivos — investigación: $13 perdidos por rechazo falso por cada $1 perdido por fraude.
- Juniper: fraude de pago en línea $44B (2024) → $107B (2029); rechazos falsos cuestan $443B/año a la industria — proyecciones de pérdida por fraude frente al mayor arrastre de rechazos falsos.
