And your qualifications for making this dismissive assessment are...? Or do you have peer reviewed studies to which you can cite to support your position?

Copy/paste fail. The link to Scot Terban's article at krypt3ia is http://krypt3ia.wordpress.com/2012/10/29/the-threat-is-real-and-must-be-stopped-clarifications-and-rebuttal-by-an-infosec-professional-final-draft/

>The bacteria that enter the drinking supply poisons a good portion of an entire city and thousands (if not tens of thousands) die.

Because no one, not even the people there at the plant, notice that the sewage is going into the water, and no one notices that the water smells funny, etc., etc. NYC is dealing with something like this right now in the wake of hurricane Sandy. See http://www.huffingtonpost.com/2012/10/30/hurricane-sandy-sewage-toxic-_n_2046963.html.

Killing people with computers is a LOT harder than killing them with kinetic weapons because, aside from people being monitored by computers in hospitals, most people aren't directly relying on the computers to keep them alive.

The north eastern US suffered a major, multi-day blackout a few years ago. It did not bring the country to its knees. Similarly, regional weather events may shut down transit/business/etc., but people are moving to backup systems (e.g., walking/biking to work in the case of NYC) and dealing for the time it will take to bring the systems back online.

Any cyber attack that could actually meaningfully harm the US would cross the line into casus belli and likely receive a kinetic response.

It's possible that some kind of cyber attack could be used as a distraction or to syphon off resources while a kinetic attack takes place, but that's still assuming some other nation believes it is in their national interests to get into a shooting match with the US.

Sen. Lieberman had an opinion piece in the NYT (http://www.nytimes.com/roomfordebate/2012/10/17/should-industry-face-more-cybersecurity-mandates/the-cyber-threat-is-real-and-must-be-stopped-by-business-and-government) supporting your position. Numerous real security professionals would disagree, from Bruce Schneier (http://www.schneier.com/blog/archives/2012/10/stoking_cyber_f.html) to people like Scot Terban (http://www.schneier.com/blog/archives/2012/10/stoking_cyber_f.html).

The short requirements:

1) Explain what you're collecting in real-time at the moment when you give me the option whether or not to permit you to collect it. Tell me what you will use it for, when you will delete it and the consequences if I don't give it to you. People don't read privacy disclosures. Give notice and ask permission at the moment of proposed collection. Make it opt-in, not opt-out.

2) Only request the information required to perform the service I've requested. Use the information I provide only to provide the service I've requested. Only share the information I provide with third parties to the limited extent necessary to provide the services I've requested. Obtain contractual commitments from those third parties that cause them to protect my information and delete it as soon as they've done what's required to provide the service I've requested. Keep information only as long as necessary to provide the service I've requested and delete it after you've done what's required to provide the service I've requested.

3) Protect my information. Encrypt in transit and at rest. Delete thoroughly and don't give in to the urge to collect and keep information just because it might be useful some time in the future. You can't lose what you don't have.

You say the collection "... is for purposes of analysis and ultimately functionality, not persistence." That seems inconsistent with the collection of name and email address. I can't think of too many use cases where you're collecting my name and email address and don't plan to keep it (and use it for marketing or otherwise share it in some way). If you need to contact me or I need to create a user-id that is my email address, you don't need my name.

Your privacy policy is your contract with your user. It is an operational document that must be consistent with your practices. The privacy policy should be consistent with your policies and procedures. If the information you collect, or the way you handle it changes, you must change your privacy policy.

This issue has been gaining importance as our online life becomes an increasing portion of our activity and consumption. People used to keep photos in albums - now they're scattered among devices, memory cards and online services. Personal diaries are now protected with a password instead of a physical lock - and might even be stored on Blogger or LiveJournal or another online service rather than on a hard drive. Family financial information or even personal recipes might be stored in Google Docs. Most of the services we use on a regular basis have little-to-no provisions in place for a family member or an executor to transfer account information. Few companies and even fewer users are thinking about end of life issues when it comes to their online lives.

I did an article about this about a year ago available at http://www.virtualworldlaw.com/2011/04/you-cant-take-it-with-you---death-and-the-virtual-world.html

>Because while things may have been well designed originally or planned including all the fancy redundancy, after years of no major
>issues it becomes a target of its own success: cutbacks and people saying "see, we never needed it, and look at how much >money we can save". Such is the way of things.

Part of this is also people who are bad at math. I once had a major disagreement with a business guy trying to explain that there was a significant difference between a server that had been 100% available for a given time period and one that was _architected_ to be 100% available. He couldn't understand that the former scenario involves getting lucky, while the latter is the result of (more expensive) design.

>It would give a mechanism to see how many people agree or disagree with a post, without the flood of useless "lol me
>too!11!!!1!!!!!1" AOLer posts that plague slashdot

In other words, you've just described what Digg used to be.