El origen y lo que cuelga de él
El origen de tu página decide más de lo que parece: el almacenamiento del navegador, las cookies, los permisos del motor y lo que un servidor remoto ve. Qué cambia entre desarrollo y producción, y qué no conviene apoyar ahí.
Qué cuelga del origen
Qué guardar en el navegador
La regla que sale de la tabla, y es sencilla:
El argumento de fondo: el almacenamiento del navegador está atado a un origen que puede cambiar, lo puede vaciar el motor por presión de disco, y en el disco es un fichero que cualquier programa con los permisos del usuario puede leer. Es una caché con buena memoria, no un almacén.
Y hay un argumento adicional que decide la duda: el core ya tiene un sitio mejor. Con el almacén de preferencias o con SQLite —fase VII— tienes persistencia real, en un directorio conocido, con copia de seguridad y con la posibilidad de migrar el esquema. Guardar en el navegador solo tiene sentido para lo que no merece nada de eso.
Contenido remoto: otro origen, otra vida
El caso que el nivel 32 desarrolla y que aquí importa por el origen: una ventana que carga una URL externa tiene el origen de esa URL, no el tuyo.
Eso significa tres cosas de golpe:
- Su almacenamiento es el de ese sitio, no el tuyo. Comparte cookies y datos con lo que el usuario tenga de ese dominio en su navegador… o no, según el motor y el sistema, que es una diferencia entre plataformas más.
- Tu política de contenido no la gobierna. La política que escribiste se aplica a tu origen; el contenido remoto trae la suya o ninguna.
- Y tus capabilities sí la gobiernan, si le concedes alguna — que es lo que el nivel 32 dice que no hay que hacer.
Lo que no conviene apoyar en el origen
Tres cosas que la gente intenta y no funcionan bien:
Distinguir desarrollo de producción mirando el origen. Funciona y es frágil: cambia con la plataforma y con la configuración. Lo correcto es una bandera de compilación, que el core conoce con certeza.
Una sesión basada en cookies. Se pierde con el origen, se comporta distinto en cada motor, y las credenciales acaban en un fichero del perfil de la webview. La sesión va en el core, y el testigo en el llavero. Fase VI.
Compartir datos entre la web y la app instalada por el almacenamiento. Son orígenes distintos: no hay nada compartido. Si tu producto tiene las dos formas —el reparto mixto del nivel 1.5— la sincronización pasa por un servidor o por un fichero, nunca por el navegador.