El caso 1 es falta de cultura de seguridad. También añadiría otra variable ahí: Corrupción.

 Es común que "el primo de" el politico al que le toque se encarge de programar software tanto para redes institucionales como en el sistema educativo.
A la vez, se siguen usando dinosaurios como base para plataformas. Cual es la ùltima vez que viste una plataforma educativa en React, por ejemplo?
Uno podría pensar que se debe a falta de presupuesto, pero mas bien, es que introducen sobrecostes en tecnologías anticuadas para repartirse el sobrecoste/presupuesto. Especialmente si no son "sistemas críticos" (si lo son pero al que le toca gestionarlo le da igual).

Yo mismo presencié de primera mano como un "primo de no se quien" estaba al cargo del desarrollo, host y mantenimiento de mas de 30 dominios. Tenía hosteados en el mismo servidor webs institucionales, y webs de business que no tenían absolutamente ninguna relación. Vulnerar cualquiera de esas webs del lado del servidor te daba acceso instantaneo a al resto de webs/servicios. No era un experto de nada, mas bien un "espabilado" que vio negocio.

Sobre el caso 2 no puedo comentar porque no estoy al tanto. Simplemente añadir que la motivación de pedir un rescate pequeño no tiene que ser por reconocimiento, si no porque el modus operandi de la mayoría de empresas es contactar a la policía y nunca pagar rescates. El motivo de pedir poco rescate puede ser para hacer mas atractiva la opción de pagar el rescate.

Coincido con tu reflexión sobre la criprografía. La mayoría de fallos explotados no suelen ser sobre criptografía en sí. Si no en malos diseños e implementaciones.

Hazte cuenta en github y publícalo ahí primero. Publícalo en el foro también y guárda dichas páginas en web machine.

Difícil ayudarte sin poder probar el código dado que no compartes la url y no descibres el comportamiento.

Cual es el punto de pagar por publicar una app que no genera ingresos, no recoje data ni tiene anuncios o trackers, y a la vez no hacerla open source?

Precalcula si va a tocar un borde, y si es el caso fuerzas el meteoro a ir hacia la esquina en vez de hacia la pared y recalculas la velocidad para ir hacia la nueva posición.

El problema a simple vista es que la mira se queda pegada al muro (por ejemplo a la esquina superior izquierda) a pesar de que sigues moviéndote en esa dirección.

Otra forma de explicarlo. Si tienes la plataforma de abajo en la posición exacta que mandará la pelota a la esquina superior izquierda, y sigues moviendo la plataforma hacia la derecha (para pegarle con mas ángulo a la pelota para mandar aún mas hacia la izquierda la pelota) la mira no puede moverse mas allá de la esquina izquierda superior (porque se para en el muro).

Cuando pasa esto, no calcula la posición real de donde golpeará la pelota. (Que en vez de golpear en la esquina superior izquierda (donde está la mira), golpeará por ejemplo en la pared izquierda antes de golpear en el "techo".

Una forma que se me ocurre para que lo puedas solucionar es hacer que la mira se mueva por las paredes hacia abajo al llegar al muro del lado izquierdo (lo mismo para el otro lado).

Esto es necesario ya que tal y como lo tienes ahora mismo, no estás calculando el rebote de la pelota en la pared. Este rebote altera en donde va a golpear la pelota en la parte superior tras el rebote contra la pared horizontal.

Podrías hacer este cálculo invisble para la mira y en su lugar calcular en donde golpeará en la parte superior tras el rebote.

Aquí te hice un ejemplo para que visualices el problema:
https://stringmanolo.github.io/share/js/pong/

La linea verde es teniendo en cuenta el rebote en la pared. La linea roja es lo que tu haces.

Minándolo

Ya antes de la IA costaba. Los clásicos low hanging fruits eran cada vez mas difíciles de encontrar al mejorar las herramientas y al masificarse mas el pentesting. Hay servidores que están 24/7 escaneando toda la clearnet por estos fallos. Yo mismo he desarrollado software que extrae y busca paths comunes oara generar todo tipo de urls válidas de un servicio para luego probar open redirects, reflected xss, etc. Es full auto y como el programa puede sacar cientos de miles de urls de un dominio, se pone a correr en varios VPS 24/7 y ahí se queda.

Dado que esto lo hace mucha gente con herramientas potentes y muchas vulns distintas, cada ves es mas y mas complicado.

Por otra parte la IA también va a facilitar crear webs y todo tipo de software por lo cual mientras no avance bastante mas (empieze a poder desarrollar y manter software de seguridad como librerías para parsear input de forma completamente autónoma). El software generado por IA es propenso a contener vulnerabilidades.

Es difícil saber si la IA realmente afecta a la cantidad de bugs o no. Si bien mejora muchas herramientas y agiliza procesos, también introduce nuevos fallos e infrastructura. Los propios LLM en sí parecen ser MUY vulnerables, y es por diseño, no por error de software. Son puras cajas negras y su complejidad es tal que los wrapper necesarios para garantizar su seguridad se vuelven también complejos. Asique a medida que los servicios basados en IA se vaya masificandi, también lo harán las vulnerabilidades de estos sistemas.

Borra el disco con security-erase. El formateo normal u otro software como shred no funcionan al 100% con ssd por una protección que tienen los ssd para evitar que se desgasten unas celdas mas que otras. (Si te interesa saber mas de esta protección: https://en.wikipedia.org/wiki/Wear_leveling ).

Los "borrados" en realidad no "borran", lo que hacen es llenar todo el disco de ceros o información aleatoria haciendo una escritura normal. Esta protección evita que se escriban ceros en las celdas mas usadas/gastadas, lo que hace que en vez de escribir con ceros tu contraseña, se deje esa contraseña intacta y en su lugar se escriban ceros en otra celda del disco que ha sido usada menos.

Para hacer el borrado entonces lo normal es usar el firmware del fabricante del ssd aunque estos no siempre sin fiables al 100%.

Si quieres garantía al 100% de que no se recuperará al info, lo mejor es cifrar el disco antes de borrarlo. Puedes utilizar por ejemplo Luks con el comando cryptsetup en Linux. Una vez todo cifrado, borras el disco con los comandos:

sudo hdparm --user-master u --security-set-pass p /dev/sdX
sudo hdparm --user-master u --security-erase p /dev/sdX

Donde X en sdX es la letra de la unidad de tu ssd en Linux.

La variable la llamas como idmg en un lugar y idimg en otro. "idmg" es una variable vacia por eso no te encuentra el elemento. (Escribiste mal el nombre de la variable?)