swillden writes: There's been a lot of discussion of what, exactly, is meant by the Apple announcement about iOS8 device encryption, and the subsequent announcement by Google that Android L will enable encryption by default. Two security researchers tackled these questions in blog posts:
Matthew Green tackled iOS encryption, concluding that at bottom the change really boils down to applying the existing iOS encryption methods to more data. He also reviews the iOS approach, which uses Apple's "Secure Enclave" chip as the basis for the encryption and guesses at how it is that Apple can say it's unable to decrypt the devices. He concludes, with some clarification from a commenter, that Apple really can't (unless you use a weak password which can be brute-forced, and even then it's hard).
Nikolay Elenkov looks into the preview release of Android "L". He finds that not only has Google turned encryption on by default, but appears to have incorporated hardware-based security as well, to make it impossible (or at least much more difficult) to perform brute force password searches off-device.
swillden writes: "Google posted on Wednesday: 'we’re releasing a new, cloud-based version of the Google Wallet app that supports all credit and debit cards from Visa, MasterCard, American Express, and Discover. Now, you can use any card when you shop in-store or online with Google Wallet. With the new version, you can also remotely disable your mobile wallet app from your Google Wallet account on the web.'"
swillden writes: Finally addressing a problem with the new Google+ social network that has generated a great number of complaints from long-time Google users, Google has announced the availability of Google+ for users with Google Apps accounts. The feature isn't enabled automatically for all Google Apps domains, though, it's necessary for the domain administrator to turn it on.
swillden writes: "I recently got the opportunity to play with some fairly high-end hardware and I was very surprised at the poor I/O performance. The machine was a 4-way Xeon with a high-end RAID controller and five 300GB SCSI Ultra-320 15,000 RPM drives, to be configured as a very high-performance database server. I didn't care so much about the real database workload, though, I just wanted to see what kind of data rate I could get, for fun.
Given that each of these drives individually can sustain over 100 MB/s, and given that I'd expect RAID0 to scale roughly linearly with the number of drives, I was expecting in the neighborhood of 500 MB/s. What I got (according to bonnie++) was about 200 MB/s, less than half the expected data rate. Disappointed, I decided to give Linux MD RAID a try, which got me up to about 240 MB/s, 20% faster than the hardware RAID, but still disappointing.
My question for the slashdot geeks that play with this kind of stuff all the time is: What kind of performance should I expect out of a system like this? Does RAID0 always scale so poorly? And, just for good nerdish fun, what's the fasted storage I/O you've ever seen?"
swillden writes: "Everyone who pays any attention at all to security, both computer security and "meatspace" security, has heard the phrase Security Theater. For years I've paid close attention to security setups that I come in contact with, and tried to evaluate their real effectiveness vs their theatrical aspects. In the process I've found many examples of pure theater, but even more cases where the security was really a cover for another motive.
Recently, a neighbor uncovered a good example. He and his wife attended a local semi-pro baseball game where security guards were checking all bags for weapons. Since his wife carries a small pistol in her purse, they were concerned that there would be a problem. They decided to try anyway, and see if her concealed weapon permit satisfied the policy. The guard looked at her gun, said nothing and passed them in, then stopped the man behind them because he had beer and snacks in his bag. Park rules prohibit outside food. It's clear what the "security" check was really about: improving park food vending revenues.
So, what examples of pure security theater have slashdotters noticed? Even more interesting, what examples of security-as-excuse have you seen?."
swillden writes: "I've come across an increasing number of GPL programs lately that display an EULA-style click-wrap agreement during installation. While not exactly wrong, this seems like a bad idea to me, since it perpetuates the idea that you must agree to some arbitrary set of conditions in order to install and use a piece of software. In this case the conditions are very liberal (there are none, really), but still it reinforces the notion that you can't install a package unless you agree.
The FSF says that such click-wrapping is neither required nor forbidden but it seems like a bad idea to promote the click-wrap meme, even if the license is user-friendly. What do slashdotters think?"