Firstly, its much easier to break something than build it. You build software with 100,000 lines of code and 1 line has a potential exploit? you did a good job 99,999 times
I found this article hard to read after getting to this point.
I found this article hard to read after getting to this point.
The application of that argument in this context might be misguided, but it is certainly true that it is much easier to destroy something than to build it in the first place. The reason is entropy -- highly ordered systems are particularly vulnerable to unraveling in the face of this natural law.
> Try breaking Chrome.
Happens every day. Google must remain constantly vigilant for this possibility and offers substantial monetary rewards to those able to break it:
https://www.google.com/about/appsecurity/chrome-rewards/
If breaking Chrome was a practical impossibility as you suggest, this program wouldn't exist or pay out rewards. But that's false.
Source: http://www.eweek.com/blogs/security-watch/google-increases-b...
Quote "Since that first set of bug bounties was paid in 2010, Google has paid out over $1.25 million and fixed some 700 reported bugs."
Breakages in this context are not related to entropy. They are hidden errors that are not detected until long after the system is deployed. For example, the BEAST attack exploited a flaw that was first identified 10 years earlier. Similarly, errors such as padding oracle attacks on badly written encryption code don't decay--they are broken from the beginning and turns out to require exceptional insight to detect.
This is a misapplication of the idea of entropy or decay to real-world software problems.
For a mathematical equation, or for a computer program that's written and then never touched again, obviously true -- after all, these things aren't part of physics, how could entropy play a role?
But for a computer program or language that's subject to perpetual revision to meet new needs, entropy's role is self-evident. Microsoft Windows is a classic example -- there are parts of Windows that cry out to be removed and replaced, like the presence of drive letters to name just one, except for the requirements of legacy compatibility.
For a sufficiently long-lived program or language, one that's subjected to major revisions over time, something very much like entropy is present and obvious. And the closer to everyday reality the software is, the more subject to user demands and changes, to that same degree the software's history exhibits something like entropy -- until finally the software's maintainers decide to just abandon the effort and start over. Just as with actual physical systems.