The End Of Capitalism And Rise Of Non Profit Companies - CISPA Vote Means Big Private Companies Have Zero Privacy Policies: Companies Including Governments, Google, Facebook, Yahoo, AT&T, Comcast, EMC, IBM, Intel, McAfee, Oracle, Time Warner Cable, and Verizon All Will Die Pretty Soon..

Proposed amendment to CISPA says Internet companies' promises to protect customer privacy were legally enforceable. But then Republicans vote it down.

Rep. Pete Sessions, a Texas Republican shown in this photo from last year, told his colleagues the privacy amendments weren't in "the spirit" of protecting the United States from cyberattacks.

(Credit: Getty Images
 
Google, Facebook, Twitter, and other Internet companies and e-mail providers will be prohibited from making legally binding promises to protect your privacy, thanks to a vote this afternoon in the U.S. House of Representatives.

By a 5-8 vote, the House Rules committee rejected a bipartisan fix to the CISPA data-sharing bill that would have ensured companies' privacy promises -- including their terms of use and privacy policies -- remained valid and legally enforceable in the future.

The vote came after Rep. Pete Sessions, a Texas Republican who's the committee's influential chairman, urged his colleagues to vote against the amendment (PDF). All of the committee's eight GOP members voted against the amendment, and all the Democrats supported it. (See CNET's CISPA FAQ.)
It also came hours after a formal veto threat from the Obama administration, citing privacy and other concerns about CISPA. A House floor debate is scheduled to begin tomorrow, which now will not include a vote on the amendment.

"We're disappointed that such a commonsense reform won't even get a vote," Will Adams, a spokesman for Rep. Justin Amash, a Michigan Republican who co-sponsored the amendment, told CNET this evening. "When Americans sign up for service with their phone company or their Internet provider they should be entitled to the privacy protections that the companies promise them. Giving companies legal cover to break their contracts with consumers is bad policy and a disservice to the American people."

Congress should have been able to debate the amendment this week because it would ensure Americans' privacy rights, said Rep. Jared Polis, a Colorado Democrat and former Internet entrepreneur. That includes, he said, the rights of "users who have given their information to the company under the explicit assurance of the terms of use that it wouldn't be shared."

These IBM officials were lobbying Rep. Sessions, center, on cybersecurity legislation, according to this photo that appeared in his Twitter feed. IBM has lobbied for CISPA, saying "information sharing from industry to government" is "valuable."

(Credit: U.S. House of Representatives)

Otherwise, Polis said, CISPA means Internet and other companies will be "completely exonerated from any risk of liability" if they open their databases with confidential customer information to the feds and even private-sector firms.

The amendment was only six lines long. It would have altered the latest version of CISPA (PDF) by saying the legislation does not authorize a company "to breach a contract with any other party," including a terms of service agreement.

If it had been adopted during the floor debate, it would have allowed e-mail providers, social networks, and other companies to pledge not to share customers' confidential information with the National Security Agency, Homeland Security, or any other organization under CISPA -- and made that pledge legally enforceable in court.

CISPA is controversial because it overrules all existing federal and state laws by saying "notwithstanding any other provision of law," including a privacy policy or terms of service agreement, companies may share certain confidential customer information "with any other entity, including the federal government." It would not, however, require them to do so.

That language has alarmed dozens of advocacy groups, including the American Library Association, the American Civil Liberties Union, the Electronic Frontier Foundation, and Reporters Without Borders, which sent a letter (PDF) to Congress last month opposing CISPA. It says: "CISPA's information sharing regime allows the transfer of vast amounts of data, including sensitive information like Internet records or the content of e-mails, to any agency in the government."

A representative for House Intelligence Chairman Mike Rogers (R-Mich.), CISPA's primary author, did not immediately respond to questions from CNET this afternoon.

Other amendments that were approved for discussion during the floor debate include one (PDF) that restricts when federal agencies may vacuum up library records, firearm-sales records, educational records, and medical records. Another (PDF) says CISPA will not authorize the NSA or any other spy agencies "to target a United States person for surveillance."

A reprise of 2012?
Last year, a similar coalition mounted an attempt to defeat CISPA. It failed: despite a presidential veto threat and opposition from Ron Paul (R-Tex.) and many of the same critics who offered amendments this week, the House of Representatives approved the measure by a largely party line vote of 248-168. The bill did not, however, receive a vote in the Senate because of wrangling over a Democratic-backed bill with different privacy problems, and it never became law.

A House committee approved CISPA last week without four key privacy amendments sought by opponents that would have curbed the National Security Agency's ability to collect confidential data.

CISPA's advocates say it's needed to encourage companies to share more information with the federal government, and to a lesser extent among themselves. A "Myth v. Fact" paper (PDF) prepared by the House Intelligence committee says any claim that "this legislation creates a wide-ranging government surveillance program" is a myth.

Rep. Adam Schiff (D-Calif.), who voted against the bill during last week's House Intelligence meeting, said at the time he was "disappointed" that his proposal was overwhelmingly rejected by his colleagues.
"It is not too much to ask that companies make sure they aren't sending private information about their customers, their clients, and their employees to intelligence agencies," Schiff said.

Unlike last year's Stop Online Piracy Act outcry, in which Internet users and civil liberties groups allied with technology companies against Hollywood, no broad alliance exists this time. Companies including AT&T, Comcast, EMC, IBM, Intel, McAfee, Oracle, Time Warner Cable, and Verizon have instead signed on as supporters.

There are some exceptions. As CNET reported last month, Facebook has been one of the few companies to rescind its support. Microsoft has also backed away. Google has not taken a public position.

Source: http://news.cnet.com/8301-13578_3-57579958-38/cispa-vote-means-companies-cant-promise-to-protect-privacy

Mega Winner: The cloud storage market is dominated by players that do not take advantage of cryptography beyond HTTPS and server-side encryption.

A word on cryptography

January 22nd 2013The cloud storage market is dominated by players that do not take advantage of cryptography beyond HTTPS and server-side encryption. Since we set out to improve this rather dissatisfying situation three days ago, some news outlets have made attempts to dismantle our crypto architecture. Frankly, we were not too impressed with the results and would like to address the points that were raised:
ars technica: "Megabad: A quick look at the state of Mega's encryption"

"The key used to encrypt your Mega files and folders is stored on Mega's servers, rather than on your local computer."

This is correct - the only key that MEGA requires to be stored on the user side is the login password, in the user's brain. This password unlocks the master key, which in turn unlocks the file/folder/share/private keys.

"It is telling that there appears to be no password recovery mechanism anywhere in the Mega or log-on screens, nor any method of changing your password in the user control panel." Because the master AES-128 key is encrypted using your password, remembering the password is vital. Losing it means you don't just lose the ability to log on to the service - you lose the ability to decrypt your files, period.

This is correct (and comes as no surprise) - however, this will change in the near future:

• A password change feature will re-encrypt the master key with your new password and update it on our servers
• A password reset mechanism will allow you to log back into your account, with all files being unreadable. Now, if you have any pre-exported file keys, you can import them to regain access to those files. On top of that, you could ask your share peers to send you the share-specific keys, but that's it - the remainder of your data appears as binary garbage until you remember your password.

"Without adding entropy, the "random" primes generated by math.random for use as RSA keys are really only pseudo-random and can be guessed."
This is correct - and quite a strange statement to make after conceding that mouse and keyboard entropy are indeed used to enhance Math.random(). We will, however, add a feature that allows the user to add as much entropy manually as he sees fit before proceeding to the key generation.

[On deduplication] "Whatever the underlying method, the fact that block deduplication exists is a blow against the "see no evil" approach taken by Mega."

Fact #1: Once this feature is activated, chunk MACs will indeed be stored on the server side, but they will of course be encrypted (and we will not use ECB!). Fact #2: MEGA indeed uses deduplication, but it does so based on the entire file post-encryption rather than on blocks pre-encryption. If the same file is uploaded twice, encrypted with the same random 128-bit key, only one copy is stored on the server. Or, if (and this is much more likely!) a file is copied between folders or user accounts through the file manager or the API, all copies point to the same physical file.

Forbes: Researchers Warn: Mega's New Encrypted Cloud Doesn't Keep Its Megasecurity Promises
"So Mega, or anyone else who gains control of the Mega server sending the crypto algorithms, can turn off that encryption or steal the user's private key, which would allow decryption of all past and future uploads."

Correct. Fact #1: Our FAQ states exactly that and warns people that do not trust us to refrain from logging into the site (but they could, in theory, still safely use MEGA through client apps from vendors they trust). Fact #2: Any software maker offering online application updates is able to plant Trojan code into specific targets' computers, with much more far-reaching consequences.

"If you can break SSL, you can break MEGA."

Yes. But if you can break SSL, you can break a lot of things that are even more interesting than MEGA.

"To make matters worse, Mega's SSL server seems to use weak 1024-bit encryption, rather than the 2048-bit encryption considered the minimum standard by many cryptographers for a decade. (This 2004 study, for instance, that declared 1024-bit keys would only be secure until 2006.)"

Fact #1: https://mega.co.nz/ uses 2048-bit encryption. Fact #2: https://*.static.co.nz/ uses 1024-bit encryption. Fact #3: All active content loaded from these "insecure" static servers is integrity-checked by JavaScript code loaded from the "secure" static server, rendering manipulation of the static content or man-in-the-middle attacks ineffective. The only reason why HTTPS is supported/used at all is that most browsers don't like making HTTP connections from HTTPS pages. And, using more than 1024 bit would just waste a lot of extra CPU time on those static servers. Fact #4: This has been covered in our FAQ from the beginning.

John Hopkins cryptographer professor Matthew Green says that Mega's claims of a Javascript verification system "make no sense." ... "If the Javascript is verifying itself, it's like trying to pick yourself up by our bootstraps, which doesn't work," says Green. "You need something trusted on the user's machine to check the Javascript, and they don't have that."

Please do not rely on hearsay, even if you are a cryptographer professor. Instead, go to the actual site and look at the actual code. Fact #1: The JavaScript is not verifying itself. Fact #2: A piece of JavaScript coming from a trusted, 2048-bit HTTPS server is verifying additional pieces of JavaScript coming from untrusted, HTTP/1024-bit HTTPS servers. This basically enables us to host the extremely integrity-sensitive static content on a large number of geographically diverse servers without worrying about security.
MegaCracker An excellent reminder not to use guessable/dictionary passwords, specifically not if your password also serves as the master encryption key to all files that you store on MEGA.

Source: https://mega.co.nz/#blog_3