4 ms·

Why?

• tptacek 10y ago
  Among other things, because "it's harder to build things than to break them" is a hoary and largely discredit trope. And of course because the "got things right 99,999 times" thing betrays a lack of understanding of how software works.
  • lutusp 10y ago
    > Among other things, because "it's harder to build things than to break them" is a hoary and largely discredit trope. 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.
    • tptacek 10y ago
      That may be true in the abstract, but it is entirely false in the particulars. Everybody can, for instance, design a cipher they can't themselves break; most competent developers could, within a few weeks of self-directed training, add a feature to Chrome. Try breaking Chrome.
      • lutusp 10y ago
        My point was a simple one -- entropy isn't a "hoary and largely discredit trope." It's a very well-established principle, grounded in copious evidence. > 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/ 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-bug-bounty-payouts.html 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."
      • ahartman00 10y ago
        i think its shades of gray on both sides. Some things are easy to create, some hard. Same for breaking.
    • wglb 10y ago
      The reason is entropy 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.
      • lutusp 10y ago
        > 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.