De la lista blanca a las capabilities
Qué había en Tauri 1, por qué se sustituyó entero en vez de ampliarlo, y las tres cosas que el modelo nuevo permite y el viejo no. Útil aunque nunca hayas visto la versión anterior.
Lo que había
// Tauri 1 — la idea general{ "tauri": { "allowlist": { "fs": { "readFile": true, "writeFile": true, "scope": ["$APPDATA/**"] }, "dialog": { "all": true }, "shell": { "open": true } } }}Se leía bien y tenía cuatro límites que en aplicaciones reales aparecían todos:
Las tres cosas que el modelo nuevo permite
Y que son exactamente las tres decisiones que parecen ceremonia hasta que se ve de dónde vienen:
1 · Conceder por ventana. Una capability nombra las ventanas a las que aplica. Es lo que permite que la ventana que muestra contenido ajeno —nivel 32— no tenga nada, mientras la principal trabaja con normalidad. Con una lista global, esa separación era imposible y la única defensa era no tener esa ventana.
2 · Conceder por plataforma. La misma capability puede aplicar solo en escritorio, o solo en móvil. Una aplicación que en el escritorio lanza procesos y en el móvil no, ya no concede en los dos sitios lo que solo usa en uno.
3 · Que tus comandos tengan permiso propio. Con el manifiesto del nivel 29, cada comando tuyo es un permiso que una capability concede o no. La lista blanca no tenía nada equivalente: tus comandos existían o no existían.
Las tres se resumen en una frase: el modelo pasó de decir qué puede hacer la aplicación a decir quién puede pedir qué.
La migración
El subcomando del nivel 9.1 traduce la lista blanca a capabilities, y hace bastante trabajo bien. Lo que hay que saber es cómo traduce:
La conclusión práctica: migrar es el principio, no el final. Un proyecto recién migrado tiene el modelo nuevo con la superficie del viejo, y apretar es el trabajo que de verdad da el beneficio. Los niveles 28 a 30 son ese trabajo.