Lista blanca de cookies
TL;DR: La lista blanca de cookies de CookieVault es una lista de permitidos por dominio que exime a los sitios de confianza del auto-borrado —así conservas los inicios de sesión de los sitios que usas a diario mientras todo lo demás se limpia al cerrar pestaña. La herencia de subdominios, los wildcards y una lista gris mantienen la lista corta; la lista local es gratis, y la sincronización entre dispositivos es Pro.
La lista blanca de cookies en CookieVault Guardian es una lista de permitidos por dominio que anula el comportamiento de auto-borrado, así que los orígenes en lista blanca conservan sus cookies y datos de sitio entre cierres de pestaña mientras todos los demás dominios se limpian en el momento en que se cierra su última pestaña. Es la reimplementación moderna del clásico modelo de lista de permitidos de Cookie AutoDelete, ampliada con herencia de subdominios, patrones wildcard y una lista gris para sitios de solo una sesión. En la práctica, la lista blanca es el ajuste más importante de todo el producto: es el único mando que decide qué inicios de sesión sobreviven y cuáles desaparecen.
Cómo funciona la lista blanca
En resumen: Añade un dominio haciendo clic en el icono de la barra de herramientas estando en el sitio. La herencia de subdominios está activada por defecto, así que una entrada cubre un servicio entero. Los dominios en lista blanca simplemente se omiten cuando el auto-borrado se ejecuta tras cerrarse la última pestaña.
Las cookies son cómo los sitios te recuerdan entre peticiones; MDN documenta que la cookie de sesión es lo que te mantiene autenticado1. La lista blanca funciona indicándole a Guardian que deje en su sitio las cookies de un dominio —y su cookie de sesión en concreto— cuando la limpieza se dispararía en otro caso. CookieVault lee y conserva esos registros a través de la API oficial de cookies del navegador2, así que un inicio de sesión en lista blanca se comporta exactamente como lo haría sin ninguna extensión instalada.
Seis mecánicas que hacen manejable la lista:
- Añadir en un clic —haz clic en el icono de la barra de herramientas en cualquier sitio y elige “Add to whitelist”
- Herencia de subdominios (activada por defecto) —
example.comtambién exime amail.example.comyapp.example.com - Modo de host exacto —desactiva la herencia para poner en lista blanca solo el apex y limpiar sus subdominios
- Wildcards —
*.googleapis.comcubre todos los subdominios de un host de API o CDN en una sola regla - Lista gris —exención de solo una sesión que limpia o promueve automáticamente en el siguiente cierre
- Ilimitada localmente —sin tope de entradas en la lista local gratuita
Un principio fiable para las listas de permitidos es mantenerlas cortas e intencionadas: una lista pequeña y bien elegida es fácil de razonar, mientras que una desbordada derrota silenciosamente el objetivo de privacidad.
Lista blanca vs lista gris
En resumen: La lista blanca significa “no limpiar nunca, conservar entre sesiones”. La lista gris significa “conservar durante esta sesión y luego limpiar o promover automáticamente en el siguiente cierre”. Usa la lista blanca para inicios de sesión permanentes y la lista gris para visitas puntuales.
| Comportamiento | Lista blanca | Lista gris | Por defecto (ninguna) |
|---|---|---|---|
| Cookies conservadas entre sesiones | Sí | Solo la sesión actual | No |
| Limpiadas al cerrar la última pestaña | Nunca | En el siguiente cierre (o promueve) | Siempre |
| Sesión iniciada tras reabrir | Sí | Hasta que termina la sesión | No |
| Mejor para | Inicios de sesión de uso diario | Visitas puntuales / temporales | Sitios no confiables |
| Herencia de subdominios | Sí (por defecto) | Sí | N/D |
La lista gris existe porque la navegación real no es binaria. A veces quieres continuidad durante la próxima hora en un sitio al que nunca volverás —la lista gris te lo da sin hacer crecer permanentemente tu lista blanca.
Errores comunes con la lista blanca
En resumen: Los dos modos de fallo son poner demasiado en lista blanca (lo que cancela silenciosamente el beneficio de privacidad) y olvidar el dominio de inicio de sesión federado del que depende un sitio (lo que te desconecta igualmente). Una lista corta y deliberada y una consciencia de los dominios de proveedor de identidad arreglan ambos.
Seis errores que hacen tropezar a los usuarios nuevos, y cómo evitar cada uno:
- Poner todo en lista blanca “por si acaso” —una lista inflada significa que casi nada se limpia jamás; pon en lista blanca solo aquello en lo que realmente mantienes la sesión iniciada
- Olvidar el proveedor de identidad —un sitio que autentica a través de
accounts.google.como un host de SSO también necesita ese dominio de proveedor en lista blanca, o el inicio de sesión se rompe igualmente - Poner el apex en lista blanca pero necesitar un subdominio —confirma que la herencia de subdominios está activada, o añade el subdominio concreto
- Wildcards demasiado amplios —
*.comno es una regla; acota los wildcards a un solo servicio como*.googleapis.com - Tratar la lista gris como permanente —los sitios en lista gris siguen limpiándose en el siguiente cierre, así que mueve los inicios de sesión a largo plazo a la lista blanca real
- Poner un sitio en lista blanca para recuperar estado del lado del cliente —la lista blanca evita la limpieza futura; no puede restaurar datos ya borrados
La pregunta de soporte más común con diferencia es “¿por qué este sitio me cerró la sesión aunque lo puse en lista blanca?” —y la respuesta casi siempre es un dominio de inicio de sesión federado o SSO ausente. En la duda, pon en lista blanca tanto el dominio de la aplicación como el host de cuenta por el que redirige el inicio de sesión.
Cómo se compara CookieVault con un enfoque manual
En resumen: Podrías borrar cookies manualmente y volver a iniciar sesión, o usar los ajustes de cookies por sitio del navegador, pero ninguno te da una lista de permitidos de un clic, sincronizable y con capacidad de wildcard ligada a la limpieza automática al cerrar pestaña.
| Enfoque | Añadir en 1 clic | Wildcards | Auto-limpiar el resto | Sincronización entre dispositivos |
|---|---|---|---|---|
| Lista blanca de CookieVault | Sí | Sí | Sí | Sí (Pro) |
| Ajustes de cookies por sitio del navegador | No | No | No (manual) | Ligado a un solo navegador |
| Borrado manual + reinicio de sesión | No | No | No | No |
| Cookie AutoDelete (MV2) | Sí | Sí | Sí | No |
La nota honesta: los propios controles de cookies por sitio del navegador están perfectamente bien si solo te importan un par de sitios y nunca cambias de navegador. La lista blanca se gana su sitio cuando quieres limpieza automática de todo lo que no hayas confiado explícitamente, más las mismas reglas en todos los dispositivos.
Gratis vs Pro
En resumen: La lista blanca local —entradas ilimitadas, lista gris, wildcards— es gratis para siempre. Pro (4 USD/mes o 36 USD/año) añade sincronización entre dispositivos con cifrado para que tu lista de sitios de confianza te siga a todas partes.
| Capacidad | Gratis | Pro (4 USD/mes o 36 USD/año) |
|---|---|---|
| Lista blanca local ilimitada | Sí | Sí |
| Herencia de subdominios | Sí | Sí |
| Wildcards y lista gris | Sí | Sí |
| Sincronización de lista blanca entre dispositivos | No | Sí |
| Sincronización cifrada de conocimiento cero | N/D | Sí |
La sincronización es la única parte de pago, y usa la misma pila de conocimiento cero descrita en la página de sincronización cifrada en la nube —tu lista de sitios de confianza se cifra en el dispositivo y el servidor solo ve texto cifrado. Consulta la página de precios para el desglose completo.
Cómo construir tu lista blanca
- Instala CookieVault Guardian desde la página de descarga y fija su icono en la barra de herramientas
- Visita tu correo principal (Gmail, Outlook, Proton) y haz clic en el icono → “Add to whitelist”
- Visita tu host de código (GitHub, GitLab) y ponlo en lista blanca de la misma forma
- Pon en lista blanca tus herramientas de trabajo —aquellas en las que mantienes la sesión iniciada todo el día
- Pon en lista blanca tu banco y la interfaz web de tu gestor de contraseñas
- Añade wildcards para cualquier host de API o CDN que use muchos subdominios, como
*.googleapis.com - Pon en lista gris los sitios puntuales que quieras solo para la sesión actual
- Revisa la lista en Settings → Whitelist y recorta lo que ya no necesites
Todo lo que no esté en la lista se limpia al cerrar pestaña por defecto. Para una versión guiada con capturas y casos límite, consulta el tutorial de lista blanca de cookies.
Véase también
- CookieVault Guardian —la extensión de auto-borrado que controla la lista blanca
- Borrar cookies automáticamente al cerrar pestaña —qué les pasa a los sitios fuera de la lista blanca
- Tutorial de lista blanca de cookies —configuración paso a paso con casos límite
- Borrar cookies pero mantener la sesión iniciada —el flujo que habilita la lista blanca
- Sincronización cifrada en la nube —cómo la sincronización de la lista blanca se mantiene de conocimiento cero
- Precios —desglose de Gratis / Pro / Team
Footnotes
-
El papel de la cookie de sesión en mantenerte autenticado entre peticiones está documentado por MDN en https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies. ↩
-
CookieVault conserva y lee las cookies en lista blanca a través de la API oficial de cookies del navegador documentada en https://developer.chrome.com/docs/extensions/reference/api/cookies. ↩