Post AwmrrEfngmQclsfv1c by esteban@rebel.ar
(DIR) More posts by esteban@rebel.ar
(DIR) Post #AwmrrAOHby2VUORsAK by esteban@rebel.ar
2025-07-28T18:02:16Z
0 likes, 0 repeats
*Los abuelos de las apps*La W3C y todos los desarrolladores de bien ya sabemos que no hace falta más hacer aplicaciones ""nativas"" para celulares. Los estándares web permiten evitar la tiranía de los stores y la cruz de mantener aplicaciones con SDKs específicos para un tipo de dispositivo que cambian de un dia para el otro según la voluntad de sus reyes.Sin embargo existe una generación que quedó rota, rota de recibir tanta publicidad de los roba-datos para instalarse apps. Si algo permiten las apps nativas es robarte más datos ejercer mejor control de tu dispositivo. ¿Quienes son los principales promoteres de las apps? Bancos, fintechs y redes sociales de la corpo. ¿No te genera sospechas que te pidan instalar una app para ver y subir fotos? En 2002 fotolog hacía lo mismo que instagram y no existían las apps.Mientras que toda app web se puede usar en cualquier lado, inspeccionar tráfico y depurar sus rutinas las llamadas "apps nativas" solo corren en dispositivos específicos con una versión, traen impedimentos para evitar ser depuradas y hay que "hackearlas" para poder inspeccionar su tráfico.Sumado al agravio los desarrolladores deben soportar que los reyes del store impongan reglas arbitrarias a sus apps, tarifas de 30% y cada vez que necesitan enviar una actualización cruzar los dedos que se las aprueben.No seas un abuelo de las apps, la web ya soporta todo y lo soporta mejor. Elegí siempre que puedas la versión web.La web es nativa, son los reyes de las apps que la quieren tildar de mestiza.
(DIR) Post #AwmrrBecughtPN6RHM by freetar@freesoftwareextremist.com
2025-08-01T04:11:47.373468Z
0 likes, 0 repeats
@esteban La web solía ser una forma maravillosa de compartir información, pero las «web apps» la convirtieron en la peor tienda de aplicaciones. No tenemos control sobre lo que hace el programa, cuándo se ejecuta y cómo se manejan nuestros datos. Cuando un sitio web tiene tanto control sobre lo que se ejecuta en nuestra computadora, el efecto es equivalente al de usar un programa privativo que incluye funciones de vigilancia y una puerta trasera universal: https://www.gnu.org/philosophy/wwworst-app-store.html
(DIR) Post #AwmrrCiCyrAMglmoV6 by esteban@rebel.ar
2025-08-01T10:31:37Z
0 likes, 0 repeats
@freetar muy erroneo. Las webapps piden permiso para todo lo que las app y más. Se puede configurar y alterar con extensiones. Podés inspeccionar todo con herramientas estandar y elegir que sucede yque no sucede
(DIR) Post #AwmrrDVq0KrhAh0RrE by freetar@freesoftwareextremist.com
2025-08-01T19:18:20.534151Z
0 likes, 0 repeats
@esteban >Las webapps piden permiso para todo lo que las app y más.Tanto las «aplicaciones nativas» como las «webapps» suelen incorporar características maliciosas, pero rara vez solicitan permiso explícito para ello. Un caso claro es la actualización automática: cada vez que se accede a una «webapp», se descarga e instala una nueva versión del programa, sin que el usuario pueda elegir conservar la anterior. No hay opción de rechazo ni control: la decisión recae exclusivamente en el dueño de la tienda. Si esa nueva versión introduce cambios no deseados, el usuario queda sin alternativa viable, salvo mediante mitigaciones complejas como la virtualización o el uso de proxies locales.>Se puede configurar y alterar con extensiones.Existen herramientas como NoScript, uBlock Origin o LibreJS que permiten limitar parcialmente el abuso de JavaScript, pero ninguna asegura el reemplazo efectivo del programa antes de que se inicie. La única defensa fiable es desactivar por completo la ejecución de JavaScript desde las configuraciones del navegador (por ejemplo, `javascript.enabled=false`)>Podés inspeccionar todo con herramientas estandar y elegir que sucede yque no sucedeVisualizar el código fuente nominal no implica tener control sobre él. La mayoría de las «webapps» entregan sus programas en forma minificada u ofuscada, lo cual dificulta la lectura e imposibilita la modificación práctica.Si desactivás JavaScript, la mayoría de las «webapps» dejan de funcionar por completo. No podés elegir que eso no suceda, ya que el dueño de la tienda mantiene el control total: si modifica el programa, interrumpe el servicio o revoca el acceso, el usuario pierde no solo el programa, sino también los datos vinculados a él.https://www.gnu.org/philosophy/javascript-trap.html
(DIR) Post #AwmrrEfngmQclsfv1c by esteban@rebel.ar
2025-08-02T00:56:28Z
0 likes, 0 repeats
@freetar aham... y todas las apps hacen eso que decis, hasta un script en basic o shell puede auto-actualizarse o bajar código y ejecutarlo. Pero en las webapps tenes control, logs y visibilidad. Además acabás de describir... podes hacer lo que quieras con el javascript. Son superiores a los otros tipos de apps modernas. Contame como ves un request, modificas código o limitás funcionalidades en otras apps. En los navegadores todo eso viene incluido y por defecto las webapps no tienen acceso ni a tu sistema de archivos ni a tus datos de otros sitios.
(DIR) Post #AwmrrFVCbfXrLIiy92 by esteban@rebel.ar
2025-08-02T01:02:36Z
0 likes, 0 repeats
@freetar yo te cuento, como experto en seguridad informatica y desarrollo de software moderno con 20 años de carrera profesional que presentás argumentos que solo compiten contra computar con tarjetas perforadas en una ENIAC. En la realidad si tengo que determinar "que hace" una app y proteger mis datos la webapp es lo mejor. Podés correr código en contenedores pero eso es solo en linux y aún asi pueden usar SSL pinning y es un bardo todo para un usuario común. Con una webapp cualquiera puede inspeccionar que sucede.
(DIR) Post #AwmrrGKFXsNVtcbjiC by freetar@freesoftwareextremist.com
2025-08-02T07:52:49.703205Z
0 likes, 0 repeats
@esteban >todas las apps hacen eso que decis, hasta un script en basic o shell puede auto-actualizarse o bajar código y ejecutarloComo bien explica Alexandre Oliva en el artículo que compartí anteriormente, el problema con las «webapps» no radica únicamente en el lenguaje en que están escritas (como JavaScript), ni en si tienen una licencia libre o privativa, sino en la forma en que son distribuidas y ejecutadas. En la web, los programas llega dinámicamente desde servidores controlados por terceros. El usuario no tiene control sobre qué hace el programa, dónde corre, ni cómo gestiona sus propios datos. El único que conserva el control es el dueño del servidor, es decir, de la tienda de aplicaciones.Cada vez que ejecutás una «webapp», el navegador contacta al servidor, y si hay una nueva versión, sin que te lo informen ni te pidan permiso, esta se descarga y ejecuta automáticamente. No existe ningún consentimiento real del usuario. ¿Y por qué lo harían distinto si ya están convencidos de que tu libertad les estorba?En contraste, si tenés un script de GNU Bash o cualquier otro software libre, también puede tener la capacidad técnica de autoactualizarse o descargar y ejecutar software dinámicamente. La diferencia es que, en ese caso, vos decidís cuándo hacerlo, en qué entorno, y si querés permitirlo. Existe algo que en la web actual no: el consentimiento.>en las webapps tenes control, logs y visibilidadSi el usuario no controla el programa, el programa lo controla a él. Tener un emulador de terminal con logs superficiales de red no implica tener control. ¿Podés acceder al código fuente antes de que se ejecute? No. ¿Podés decidir no actualizarlo y seguir usando una versión anterior? Tampoco. ¿Podés correrlo sin conexión a la tienda de aplicaciones? No, porque ni siquiera lo tenés instalado realmente.Los supuestos «logs» que podés ver en el navegador ofrecen visibilidad superficial. Además, si el código está ofuscado, fragmentado o se modifica dinámicamente, auditarlo se vuelve una tarea arbitraria y frágil. Para auditar una «webapp» de forma integral, necesitarías acceso al servidor que la sirve — algo que evidentemente no tenés. Cuando un sitio web tiene control total sobre lo que se ejecuta en tu computadora, el efecto es idéntico al de un programa privativo con funcionalidades maliciosas y una puerta trasera universal. >podes hacer lo que quieras con el javascriptEs peligroso afirmar que podés hacer lo que quieras con algo que no te pertenece. Podés declinar su ejecución, aceptarlo o quizá interceptarlo — pero no lo controlás. No podés modificar el código fuente original de la aplicación y mantener su funcionamiento, auditarlo completamente ni redistribuirlo. No podés siquiera garantizar que el código que viste una vez sea el mismo que verás mañana.Existen soluciones técnicas para mitigar este problema, como el uso de proxies o wrappers que interceptan y transforman el software antes de ejecutarlo. Pero son incómodas, frágiles y humillantes: son parches que solo pueden aplicar usuarios expertos para protegerse de una arquitectura construida sobre la negación sistemática de su libertad.>Son superiores a los otros tipos de apps modernasSi la «superioridad» se mide en términos de cuánta capacidad tiene el programador de abusar del usuario, entonces sí: las «webapps» están a la cabeza. Por supuesto, eso no implica que las «apps» privativas distribuidas mediante, por ejemplo, .apk sean aceptables: también son hostiles a la libertad del usuario. Pero lo que distingue negativamente a las «webapps» es que ni siquiera permiten los niveles mínimos de autonomía que algunos otros formatos aún toleran.>Contame como ves un request, modificas código o limitás funcionalidades en otras appsSi la «app» es software libre, podés compilar tu propia versión, desactivar funciones, agregar funciones, usar cortafuegos, modificar el código fuente, decidir cuándo actualizarla, y ejecutarla en entornos controlados. En ese caso, el control recae en vos.>En los navegadores todo eso viene incluido y por defecto las webapps no tienen acceso ni a tu sistema de archivos ni a tus datos de otros sitiosEso no es una virtud de las «webapps», sino una restricción artificial impuesta por el navegador. Y esa barrera ya está siendo debilitada progresivamente. Las APIs como WebUSB, WebGL, WebBluetooth, WebAssembly, WebRTC, geolocalización, portapapeles, y almacenamiento persistente (IndexedDB, localStorage), abren vectores de exfiltración de datos, fingerprinting persistente y otros riesgos serios de seguridad. >como experto en seguridad informaticaIncluso si un experto logra configurar contenedores o proxies para mitigar parcialmente los abusos de las «webapps», eso no resuelve el problema fundamental. La libertad no debe depender del grado de pericia técnica del usuario. Una arquitectura ética se diseña para que nadie tenga que defenderse de su propia herramienta. Que un experto pueda protegerse no justifica un entorno que por defecto abusa del resto, dado que la libertad no es un privilegio técnico sino un derecho humano.Además, es importante recordar que una «webapp» se ejecuta automáticamente en el navegador del usuario, sin verificación previa, sin sandbox adicional, sin garantía de integridad y sin auditoría alguna. Que un experto en seguridad recomiende ejecutar código dinámico no verificable, cargado de manera automática desde servidores no confiables, resulta irónico. Porque si realmente hablamos de seguridad informática, eso es exactamente lo que no deberíamos hacer jamás.>Podés correr código en contenedores pero eso es solo en linuxLinux es solo un núcleo y no opera por sí solo. Probablemente estés hablando de una distribución del sistema operativo GNU con Linux como núcleo.>Con una webapp cualquiera puede inspeccionar que sucedeMirar no es lo mismo que controlar. El «código fuente» está ofuscado, minificado, distribuido entre múltiples dominios, cargado dinámicamente y sujeto a cambios constantes.
(DIR) Post #AwmrrH9eSlUkT2empc by esteban@rebel.ar
2025-08-02T12:38:40Z
0 likes, 0 repeats
@freetar xD Las webapps son lo más autónomo que hay. Todas las APIS que introduce la web son permisos que podés no dar a las aplicaciones la verdad se nota que no sabés una goma. No existe nada mejor que las webapps a nivel darle control al usuario y protegerlo por defecto. ¿Sino decime que otra cosa? ¿Confiar en que alguien audito un software GPL? Aún si fuera así siquiera tienen builds reproducibles esas larvas. Hay varios navegadores con estándares de privacidad y builds reproducibles. El programador puede abusar más del usuario con cualquier otro tipo de APP, en especial paquetes de GNU. Podemos empezar por la gran GLIBC xD comprometiendo todo lo que toca y de ahí en adelante. O XZ lib. Y de cosas con menos visibildad ni te enterás lo que hace el software ni tiene builds reproducibles, ni tienen auditorias de seguridad, ni tienen forma de limitar sus permisos y alcance sin ser ultra experto...En cambio en la web en los navegadores tenés estándares de privacidad según tus necesidades, todos con interfaz gráfica para cualquier usuario. Todos los permisos segregados y documentados... y podés correr apps de cualquier desarrollador completamente aisladas del resto siempre. El nivel de ridiculez de "Si la «app» es software libre, podés compilar tu propia versión, desactivar funciones, agregar funciones, usar cortafuegos, modificar el código fuente, decidir cuándo actualizarla, y ejecutarla en entornos controlados. En ese caso, el control recae en vos." Nadie hace eso... No existe un cago de risa más grande que "podés ver el código fuente". En todo podés ver el código fuente, la idea es no tener que hacerlo. Con las webapps tenés control de entrada, . Podés pre-configurarlo. Lo que ten´és realmente es un alto nivel de ignorancia de la seguridad real y privacidad real.Lo que es leer pavadas en internet en vez de vivirla.
(DIR) Post #AwmrrHrbpKemfNDtLc by freetar@freesoftwareextremist.com
2025-08-03T07:29:40.658253Z
1 likes, 1 repeats
@esteban >Las webapps son lo más autónomo que hay. No existe nada mejor que las webapps a nivel darle control al usuario y protegerlo por defecto.Las «webapps» dependen de computadoras ajenas. Por ejemplo, si usás Google Docs, todo lo que hacés va y viene de los servidores de Google. Si Google te bloquea, se cae, cambia la «webapp» o decide darte otra cosa, vos no podés hacer nada, porque no tenés una copia del programa: tenés apenas un acceso temporal a un deservicio.No podés usarlas sin conexión, porque están diseñadas para requerir una conexión constante a la tienda de aplicaciones. Y como bien decís, jamás tenés la «webapp» completa en tu máquina, porque no pueden —ni quieren— almacenarla localmente. Es cierto que algunas APIs como IndexedDB permiten almacenamiento sin conexión limitado, pero eso no las vuelve realmente autónomas ni garantiza que todas sus funciones estén disponibles fuera de Internet. La mayoría —si no todas— siguen dependiendo de la tienda de aplicaciones.Tampoco decidís cuándo se actualizan. La aplicación vive en una computadora ajena, que vos no controlás. Su dueño puede cambiar el software cuando quiera, forzar una nueva versión sin avisarte, agregar nuevas restricciones o eliminar funciones. No tenés una copia fija del programa que garantice que lo que usás hoy será lo mismo que mañana. Estás a merced del amo propietario.No ves el código fuente completo. Abrir el inspector del navegador y ver parte del JavaScript no es equivalente a tener el código fuente de un programa: suele estar ofuscado, minificado y fragmentado. Además, no tenés acceso a la parte que corre del lado del servidor — por ejemplo, en PHP, Python, Ruby, et cétera.Incluso si vieras todo el código fuente, no podés estar seguro de que sea el que efectivamente se está ejecutando, ni de que no se descargue más software dinámicamente, ni de que otro usuario esté viendo lo mismo que vos.Tampoco podés compartirlas sin enfrentar consecuencias legales, porque el código que recibís no suele venir con permisos explícitos de uso, modificación o distribución. Muchas «webapps» ni siquiera publican una licencia. Y aunque pudieras copiar lo que llega al navegador, eso no te da una versión funcional ni completa que puedas compilar y autoalojar con facilidad. Para eso necesitarías el frontend, backend, bases de datos, claves de API, configuración del servidor, et cétera.Incluso si obtenés parte del código fuente, suele estar acoplado a computadoras de AWS o computadoras ajenas que no podés replicar. Si la tienda de aplicaciones decide que ya no sos bienvenido, simplemente deja de funcionar, porque la computadora donde tal cosa reside no es tuya. Si te vetan, cambian los términos de uso o cierran el deservicio, te quedás sin nada.Buena suerte recuperando tus datos. Suponiendo que haya un botón para exportar (no siempre lo hay), muchas veces los datos vienen en formatos privativos o inutilizables. Y si removieron tu cuenta o el servicio sin previo aviso, ni siquiera llegás a eso.No controlás lo que la «webapp» hace, porque no es software libre. No controlás cuándo se ejecuta, porque necesita conexión a Internet constante y puede actualizarse sin tu permiso. Y tampoco controlás tus propios datos, porque están en una computadora ajena, bajo reglas ajenas. «Si el usuario no controla el programa, el programa controla al usuario». Y para controlar un programa, este debe ser libre, por ende, permitirte: (0) ejecutar el programa como desee, (1) estudiar y modificar el código fuente de manera que haga lo que usted desee, (2) redistribuir copias exactas, y (3) redistribuir copias de sus versiones modificadas.Las «webapps» fallan en al menos tres de estas cuatro libertades fundamentales —y muchas veces en las cuatro— por requerir conexión a Internet constante, autenticación forzada, gestión digital de restricciones, software privativo y otras formas de esposas digitales.>Todas las APIS que introduce la web son permisos que podés no dar a las aplicaciones la verdad se nota que no sabés una goma.El navegador puede bloquear el acceso a ciertas APIs como la cámara, el micrófono o la geolocalización. Pero eso no es lo mismo que controlar la «webapp». Para tener control real, primero deberías poder controlar tu navegador, y eso solo es posible si es software libre. Aun así, controlar el entorno no significa que tengas control sobre el programa que se ejecuta dentro del navegador.Aunque se nieguen ciertos permisos explícitos, estas aplicaciones pueden seguir enviando datos a servidores externos, rastrearte por otros medios o ejecutar software malicioso sin que te enteres. El navegador no impide todo esto, y de hecho, muchas técnicas de recolección de datos no requieren permisos visibles. Por ejemplo, sin tu consentimiento, el navegador revela automáticamente: el tipo de navegador y su versión, sistema operativo y arquitectura, resolución de pantalla y de la ventana, idioma preferido, zona horaria, plugins instalados, et cétera.Además, existen técnicas de huella digital que dibujan algo en un canvas HTML5 y se analiza cómo lo renderiza tu navegador (usando antialiasing, subpixel rendering, configuración de GPU, et cétera) o hacer prácticamente lo anterior, pero con gráficos 3D, exponiendo el modelo de GPU y sus controladores o analizar como tu sistema procesa el sonido para generar una huella única o analizar cómo te movés, hacés clic, escribís, scrolleás, y si estás activo o inactivo.>¿Sino decime que otra cosa? ¿Confiar en que alguien audito un software GPL?Solo el software libre puede ser auditado, corregido, estudiado y compartido por cualquiera. Cuando alguien lo hace, toda la comunidad se beneficia.El software privativo, en cambio, depende exclusivamente de la buena voluntad de un único actor: el amo propietario. Si ese actor decide incluir una función maliciosa, ni siquiera podés saberlo, mucho menos corregirlo. Durante décadas se han documentado puertas traseras, mecanismos de vigilancia, funciones restrictivas y abusos intencionados en software privativo. La lista de GNU, por ejemplo, recopila algunos de estos casos: https://www.gnu.org/proprietary/proprietary.es.html>Aún si fuera así siquiera tienen builds reproducibles esas larvas.Te presento a GNU Guix, un gestor de paquetes para el sistema operativo GNU diseñado para, entre otras cosas, lograr reproducibilidad. Cada paquete se construye en un entorno declarado, aislado y verificable. Debian GNU/Linux, distribución no avalada por la FSF, tiene más del 96 % de sus paquetes reproducibles.>Hay varios navegadores con estándares de privacidad y builds reproducibles.Todos ellos son software libre, porque solo la libertad permite verificar que el binario corresponda con el código fuente.>El programador puede abusar más del usuario con cualquier otro tipo de APP, en especial paquetes de GNU.De los 402 paquetes del proyecto GNU, solo conozco 2 que son aplicaciones web: uno destinado a la gestión de sistemas HVAC y dispositivos domóticos en edificios, y otro orientado a la administración de instituciones educativas. Ambos son software libre.Todos los sistemas complejos tienen vulnerabilidades, pero hay una diferencia fundamental: en el software libre, esas vulnerabilidades son detectadas, publicadas y corregidas por cualquiera. En cambio, en el software privativo podés ser usado por algo vulnerable durante años sin saberlo, y no existe forma de auditarlo ni verificar qué está haciendo realmente.Lo ocurrido con xz-utils demuestra que la libertad es el único camino viable: un usuario independiente, sin formar parte del equipo de desarrollo, descubrió la trampa porque podía auditar el software. En software privativo, ese descubrimiento no habría sido posible.>podés correr apps de cualquier desarrollador completamente aisladas del resto siempre. Las «webapps» dependen de dominios, redes externas, CDNs como Cloudflare, librerías de terceros como Google Fonts, y con frecuencia incluyen rastreadores invisibles.>Nadie hace eso... No existe un cago de risa más grande que "podés ver el código fuente".Si eso fuera cierto, el software libre no existiría.El movimiento del software libre no exige que todos revisen el código fuente, sino que todos tengan el derecho a hacerlo, y que existan comunidades que lo ejerzan.Yo compilo mis programas en mi computadora, pero incluso si no lo hiciera, el simple hecho de que alguien más pueda hacerlo y compartir su versión es una victoria contra los enemigos de la humanidad y un paso más cerca de la muerte total del software privativo.>En todo podés ver el código fuente, la idea es no tener que hacerlo.Ojalá lo primero fuera cierto, pero desafortunadamente el «software libre» solo puede existir a pesar del software privativo, no gracias a él. Desconozco qué licencia privativa obliga a leer el código fuente, porque casi nunca lo entrega. En el software libre nadie está obligado a auditar el código.>Con las webapps tenés control de entrada, . Repetir una mentira no la hace verdad. A menos que seas el dueño del servidor, ese «control» no lo tenés.>Podés pre-configurarlo.Existen soluciones técnicas para hacer esto, como el uso de proxies o wrappers que interceptan y transforman el software antes de ejecutarlo. Pero son incómodas, frágiles y humillantes: son parches que solo pueden aplicar usuarios expertos para protegerse de una arquitectura construida sobre la negación sistemática de su libertad.>Lo que ten´és realmente es un alto nivel de ignorancia de la seguridad real y privacidad real.Si yo tengo un alto nivel de ignorancia sobre seguridad y privacidad real, que GNU/Dios se apiade de quienes saben menos que yo. Porque lamentablemente al pueblo se le ha vendido la ilusión de que es seguro ejecutar software dinámico, no verificable, cargado automáticamente desde servidores ajenos y no confiables, y, por si fuera poco, lo presentan como una función predeterminada en casi todos los navegadores modernos.