But nothing is unhackable. That’s impossible to achieve in the real world.
I think that this line of thinking of misguided for two main reasons:
-
As others have already pointed out, there’s a big difference between a theoretical vulnerability and a practical exploit. Many things are vulnerable in theory that are infeasible or impossible to exploit in practice. Several conditions must be met in order for a vulnerability to be of practical significance for you:
A. It must be possible to exploit the vulnerability in your actual system.
B. Your adversary must be aware of the vulnerability.
C. Your adversary must know how to exploit the vulnerability.
D. Your adversary must have whatever resources (e.g., time, money, technology, people) are required to exploit the vulnerability.
E. Your adversary must be willing to expend the required resources in an attempt to exploit this vulnerability. (In other words, your adversary must stand more to gain than to lose from the attempt, or at least believe this to be the case.)Even then, success is not guaranteed. Another way of putting this is to say that everyone’s threat model is different, and not every theoretical vulnerability is relevant to yours.
-
Your statement is about reported vulnerabilities, which puts the focus in the wrong place. It’s easy to reduce the number of reported vulnerabilities: Stop reporting them. Of course, the Qubes OS Project can’t stop external security researchers or upstream projects from reporting vulnerabilities, but a significant proportion of reported Qubes vulnerabilities are discovered and reported by the Qubes developers themselves. If you make the project’s goal “reduce the number of reported vulnerabilities,” that gives the project a perverse incentive: Keep self-discovered vulnerabilities secret. To be clear, the Qubes OS Project would never do this, but the dangers of bad incentives should not be underestimated (also see Goodhart’s law).
It’s not that hard to “hack” a paper notebook locked in a safe, though. Any safe can be brute forced given enough time and resources. In fact, the longest attack duration tested for UL safe certifications is only 60 minutes, and the required tools are probably much easier to come by than, e.g., zero-day exploits worth hundreds of thousands or millions.