I've pondered on this before, but it's another place where the counterintuitive spanning of so many orders of magnitude effectively trashes any effort to do this. Any simple solution fails, and not just by a little, but utterly. "Hey, maybe we should slow down our bandwidth so an attacker can't exfiltrate our entire petabyte database." Yup, sure, that's great, but the attacker only cares about the most valuable few megabytes, like your customer data and accounting. Any attempt to slow down access to those megabytes is useless, because what's the point of petabytes of data with a window of access small enough to make downloading a few megabytes noticeably difficult?<p>"But jerf, we could 'just'..." Yeah, you could, but you're not going to have just one or two "justs", you're going to have <i>thousands upon thousands</i>, and they'll end up interacting with each other. You end up having to build an incredibly complicated scheme of labeling the value of everything, and along with getting the labeling wrong, there isn't even a correct labeling anyhow.<p>A: "We limit access to the users table because only so many users log in per second and we don't want anyone to SELECT * the table and walk off with the whole thing in 2 seconds."<p>B: "OK, great, well, I have a job here than needs to run across the entire table and send an email to anyone who hasn't logged in in a year that we're going to cut off their access soon. How long will that take?"<p>A: "Let's see... with the current friction on our system, it'll take... a week and a half."<p>B: "Oh, well, that's OK then. With the restrictions on how many emails our email systems will send per hour, that system's looking at 3 or 4 months to do the job."<p>You may think I'm exaggerating the time scales for effect, but I'm not. That's those "orders of magnitude" I refer to. Try to put enough friction on systems to meaningfully slow down attackers and you can easily push jobs into days, weeks, months. Especially if, as I'm kind of thinking of in this example, all this poor developer has to work with is the <i>leftover</i> capacity for emails, because the throttled rate is already nearly consumed by the normal functioning of the system.<p>(Bear in mind that if you "just" build a back door to let such processes work, that's a back door the attacker can walk through, thus defeating the entire purpose.)<p>It's a neat idea but it's a non-starter if you sit down and start working with the numbers. At most there's a few places you could add it and get a specific protection, but as a general principle it is not useful.