It's hard to take the idea seriously, but in the interest of honing my steel-manning skills:
You'd only want to rate-limit writes to existing files, since reads and creates are harmless. You'd have to rate-limit deletes too, because otherwise ransomware could simply read files, create an encrypted copy, and delete the original to bypass the throttle. You might be tempted to exempt certain .exes, but that opens you to process hijacking attempts (as is already done for LPE and UAC bypass.) You might also want to exempt certain folders, but then ransomware could find those, make a symlink inside and use the symlinked paths to bypass. The limit would need to be machine-wide, since ransomware could otherwise run multiple processes, or use ephemeral processes, etc. And you'd have to rate-limit the NT variant of the call, not the Win32 wrapper, since otherwise the malware could abuse WSL to bypass the limit - and speaking of, are you going to rate-limit WSL2 writes to Linux files?
The reduced I/O would ruin user experience (unless the limits were so high as to be ineffective.) It'd be a cat and mouse game, too - ransomware would get smarter about picking valuable files to encrypt first. Encrypting a single database journal is worth way more than a bunch of .lnks, after all. And app developers would be incentivized to consolidate files together to improve their app's perf, which reduces the efficacy of the safeguard.
This sort of proposal is exactly the kind of myopic child-proofing that can rot the foundation of a system.
You'd only want to rate-limit writes to existing files, since reads and creates are harmless. You'd have to rate-limit deletes too, because otherwise ransomware could simply read files, create an encrypted copy, and delete the original to bypass the throttle. You might be tempted to exempt certain .exes, but that opens you to process hijacking attempts (as is already done for LPE and UAC bypass.) You might also want to exempt certain folders, but then ransomware could find those, make a symlink inside and use the symlinked paths to bypass. The limit would need to be machine-wide, since ransomware could otherwise run multiple processes, or use ephemeral processes, etc. And you'd have to rate-limit the NT variant of the call, not the Win32 wrapper, since otherwise the malware could abuse WSL to bypass the limit - and speaking of, are you going to rate-limit WSL2 writes to Linux files?
The reduced I/O would ruin user experience (unless the limits were so high as to be ineffective.) It'd be a cat and mouse game, too - ransomware would get smarter about picking valuable files to encrypt first. Encrypting a single database journal is worth way more than a bunch of .lnks, after all. And app developers would be incentivized to consolidate files together to improve their app's perf, which reduces the efficacy of the safeguard.
This sort of proposal is exactly the kind of myopic child-proofing that can rot the foundation of a system.