> I wish alternative strategies like "stop having the government collect and store information" would be considered in these situation.

I don't think nixing collection for background checks is viable, though limiting the scope (EDIT: both of data collected and the scope of applications for which government background checks are mandated) might be.

Similarly, limiting both the scope of data retained and the duration for which it is retained from such checks after the decision they support is made might be viable, though there are costs (among other things, to the accountability of government decision makers) as well as benefits to that.

This is the only real solution, as it directly addresses the real problem: interdependence. As Dan Geer described[1] the problem:

    ... risk is a consequence of dependence.  Because of shared
    dependence, aggregate societal dependence on the Internet is not
    estimable.  If dependencies are not estimable, they will be
    underestimated.  If they are underestimated, they will not be made
    secure over the long run, only over the short.  As the risks become
    increasingly unlikely to appear, the interval between events will
    grow longer.  As the latency between events grows, the assumption
    that safety has been achieved will also grow, thus fueling increased
    dependence in what is now a positive feedback loop.  Accommodating
    old methods and Internet rejectionists preserves alternate, less
    complex, more durable means and therefore bounds dependence.  Bounding
    dependence is *the* core of rational risk management.

In software we've had to face this problem of expanding complexity and interdependency so often we have numerous names for the problem like "spaghetti code" and "DLL hell". Numerous techniques have been invented to try and mitigate dependency problems (e.g. "information hiding" with functions and classes, UNIX-style problem separation and component reuse). With Rust, we have even designed an entire programming language with complicated and usual memory management features, with the goal of eliminating some types of interdependent pointer semantics. Even with all that effort, the good designer knows to ask the question "Did we really need to depend on $LIBRARY?".

Unfortunately, there are may other areas of our society that are just starting to learn about complexity at this scale, and do not understand why it might be an absolutely terrible idea to replace an old system that worked with a new piece of software that creates a dependency on the internet. There will be a lot of people that end up having to learn the hard way why it might have been a bad idea to change a security problem form "lock it in a thick-walled room behind a lot of people with guns" into something that probably reduces to Halting Problem.

[1] http://geer.tinho.net/geer.blackhat.6viii14.txt

Exactly. For us who worked on the big software projects, it's something we think of all the time, with the extremes:

- blindly making all class members private, most of the code is the burocracy and a little or even wrong job being done.

- allow everybody access to everything, a mess for the other aspects of brittleness.

Actively maintaining the balance is the hard problem which has to be done all the time as the requirements change all the time, but the task worth doing.

reminds me of this vault company who refuses to use computers to keep records or something along those lines.

http://www.losaltosonline.com/news/sections/news/219-busines...