The advice today is the same as it has ever been, though. Always assume that any networked computer is or may become compromised. Do not do anything critical on a networked computer, because it is or may become compromised. You can still use computers, but assume that a bad actor may take control at any time, and plan for that eventuality.
For example, if you are hooking up a networked computer to your town's water supply system, ask yourself "what would happen if Iran got complete control of this system?" If you're putting your school system's students' mental health data into a networked computer, ask yourself "what would happen if all of this data became public?"
Every target is worth attacking, but there are not enough bears to eat everybody. Sure, the bears are breeding, but exponential growth does not look threatening until it suddenly is.
I don't think the "breeding rate" was the limiting factor.
It reminds me of a bit from the book Lying For Money [0], where the author notes that you can often find multiple layers of scams attached to other scams, just like meta-parasite in biology.
[0] https://www.simonandschuster.com/books/Lying-for-Money/Dan-D...
What would happen if America got complete control of this system?
Oh wait. Oops.
This is completely unrealistic advice that 0% of people follow.
https://www.bbc.com/news/articles/c934dq95zpgo
https://duckduckgo.com/?t=fpas&q=public+schools+ransomware&i...
...with a hint of sarcasm, but the percentage is definitely a non-zero number.
It seems like the only “safe” option is a PC (+storage) that never attaches to a network, but that extremely limits its usefulness.
Perhaps a vulnerability still exists (for one offline NAS, only): I use dedicated NICs (on each end) to direct-link my online NAS (which is otherwise local network, only, on a separate NIC), for routine backup.
Perhaps this leaves a bridge-LAN vulnerability?
But one is entirely offline, as are all its clients (dumb TVs, mostly).
Stuff like your town's water, transportation, and medical infrastructure and employee and student data are critical. Your car's drivetrain and safety features are critical. Your home's HVAC can be critical in certain times of year. These things should not be connected to the Internet.
Nicholas Carlini has a good talk about the risks on his homepage https://nicholas.carlini.com/ (can't link to the talk directly for some reason)
If you've got a lot of roving bandits with fancy lockpicks, you're village needs to harden the walls, reduce the number of entry points, identify and document entrants more universally, check under more carriages and inside more trunks for stowaways, etc. And with all that comes delays, imprivacy, accusations, false positives.
The low trust world that we're headed towards isn't going to be nearly as fun.
What I mean is, look at how much time and effort we spend on making software services beautiful and branded, and so little time spent on security. In the future we'll probably have fewer webpages and more hardened text-based APIs that end users interact with via their AI agents.
For now most of these appear to be related to supply chain attacks which can be avoided with basic discipline and using features that browsers had for years: https://developer.mozilla.org/en-US/docs/Web/Security/Defens...
If it changes and the hash no longer matches perhaps due customer changing config then the site is faced with the challenge of either the browser refusing to load the script (with potential breakage) or reporting the change which then is probably ignored
It's not really a simple fix for the way the web is built today
If a library serves a script and your site manages user funds you should probably avoid using it or use a cdn that does.
I am not quite sure, but there's also other integrity mechanisms that gurantee that a file was signed by the library developer via a served header with the signature of the file.
Integrity reporting can detect when the script changes