What would you prefer: 99% of user requests to succeed but w/ 5% risk of getting O-day'd, or have 90% of user requests succeed but w/ 0.1% risk of getting 0-day'd.
The first and it isn't even close. Normal operation of the system is more important than preventing attacks, and trading it away at a 2:1 ratio is a bad trade.
The point of the example is that with the first choice you have 5% legitimate customers and 5% malicious "customers" and by letting all of them in aka all 10%, you get maximum customer satisfaction including satisfaction of the malicious customers.
Alternatively you reject the malicious customers and as collateral damage accept that some customers do not get their request approved.
You're also confusing "normal operation" with what a user request is. A user request is a request to change something, so by definition it is not the continuation of the existing system. You're thinking that a user request is a HTTP request which is not what's being discussed.
Personally - for banking - I'd be plenty happy dealing w/ 90% uptime if it gave me an order of magnitude more security against getting robbed. This tradeoff may not have been realistic a decade ago, but it seems to be where things are trending.
It also is de-facto the case today when logging in as per usual sometimes requires a captcha or additional verification.
What would you prefer: 99% of user requests to succeed but w/ 5% risk of getting O-day'd, or have 90% of user requests succeed but w/ 0.1% risk of getting 0-day'd.
The first and it isn't even close. Normal operation of the system is more important than preventing attacks, and trading it away at a 2:1 ratio is a bad trade.
You're trading it away at a 50:1 ratio though.
The point of the example is that with the first choice you have 5% legitimate customers and 5% malicious "customers" and by letting all of them in aka all 10%, you get maximum customer satisfaction including satisfaction of the malicious customers.
Alternatively you reject the malicious customers and as collateral damage accept that some customers do not get their request approved.
You're also confusing "normal operation" with what a user request is. A user request is a request to change something, so by definition it is not the continuation of the existing system. You're thinking that a user request is a HTTP request which is not what's being discussed.
Personally - for banking - I'd be plenty happy dealing w/ 90% uptime if it gave me an order of magnitude more security against getting robbed. This tradeoff may not have been realistic a decade ago, but it seems to be where things are trending.
It also is de-facto the case today when logging in as per usual sometimes requires a captcha or additional verification.
I could imagine it going so far as to have an LLM re-impl core libs every time a request is processed. Lightning never strikes the same place twice.