> Now your cache/registers/SRAM are maintained. Power up with JTAG or a custom/debugging bootrom/mode that hopefully doesn’t overwrite much/any and dump away.
If you care about security, you'd be disabling these. Every product I've worked on disables JTAG and other debug features on production boards and enables secure boot.
To get 192-bit security with RSA you'd need 7680-bit RSA key and with ECC you need 384-bit key as mentioned in the article. That assumes classical attacks only. For quantum attacks, the smaller key sizes used with ECC do make it weaker.
What the article describes is not particularly difficult to implement. But claiming that storing the firmware in a way that prevents the user from updating it via software somehow makes the device more "free" is absurd.
> That's why so few of them tend to advertise transmit capabilities.
Any SDR that has transmit capability freely advertises it and there are many of them. The makers of one of them (bladeRF) also develops an open source 802.11 PHY that can run on their SDR's FPGA if you want to run an open source WiFi radio. (and you don't mind using $700 hardware to run older generation WiFi) Legality of the transmission may be a concern for users of the SDRs but is not for those selling them.
This polling is not done by the CPU, this is a common misconception. In a typical modern system the only polling that happens with USB is done by the USB host controller and only when there is actual data the host controller generates interrupts for the CPU to process it. Obviously, when you configure the mouse at higher frequency you will get more interrupts and hence higher CPU usage but that has nothing to do with the polling.
If you care about security, you'd be disabling these. Every product I've worked on disables JTAG and other debug features on production boards and enables secure boot.