Slashdot Mirror
Next Android To Enable Local Encryption By Default Too, Says Google
An anonymous reader writes The same day that Apple announced that iOS 8 will encrypt device data with a local code that is not shared with Apple, Google has pointed out that Android already offers the same feature as a user option and that the next version will enable it by default. The announcements by both major cell phone [operating system makers] underscores a new emphasis on privacy in the wake of recent government surveillance revelations in the U.S. At the same time, it leaves unresolved the tension between security and convenience when both companies' devices are configured to upload user content to iCloud and Google+ servers for backup and synchronization across devices, servers and content to which Apple and Google do have access.
You need your head read. Google has shown time and again that it does not care about your security. There is no need to trade off convenience for security in cloud backup. Encrypt locally and send the data encrypted to backup. This would be great but i bet that Google also holds they keys and decrypts on their end. Google says it wouldn't be able to use your data for their massive data mining and information theft machine if it were properly encrypted. This is why the data sits on their servers unprotected by encryption, they are the antithesis of your guardians of security. If you value your data, turn off all Google services and manage your own backups.
All I see from your comment is that you're also not using the Google spellchecker.
That's great that Google is going to enable device encryption by default. But are they going to fix the usability and security problems for Android L?
If you enable device encryption on Android, you can no longer back up and restore your data over USB or through third party tools. You can create encrypted backups over USB, but you can't restore them because of bugs in the ADB tools. The only way to back up and restore is by uploading your data to Google's cloud servers, where your data is much more likely to be purloined than if you had just left your device unencrypted in the first place.
When you enable encryption, you set a password. The encryption password becomes your lock screen PIN and there is no way to change it. So, which are you going to choose? A secure encryption password that you'll spend 15 seconds entering on the tiny keyboard every time you want to unlock your phone? Or a useable PIN that is trivial to crack if an attacker gets your encrypted data?
It's clear someone added device encryption to Android to check it off the list and didn't intend for anyone to use it. I hope their product team realizes this before they bring it to a wider audience.
Because some of us really don't care if some droid somewhere is poking around in the text massages in our droids.
And anyone stupid enough to take nude selfies, maybe they need to learn that selfies are neither an art nor an art form? Take a lesson from Mother Nature - clouds leak (it's called rain).
I don't encrypt my phone data because I don't see any benefit for my own use, just more hassles. Just like I don't encrypt my on-disk or on-usb-key data. If/when I come into a situation where I need to, I will, but really, so far that hasn't happened.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
See also https://code.google.com/p/andr...
Unfortunately, this is a total show stopper for full device encryption.
Why isn't it already the default setting?
(Android Security Team member here... though these are my own perceptions and opinions, not an official statement.)
Two reasons:
First, because it's not completely trivial to make it work correctly, all the time, every time, on hundreds of different devices. Android uses dm_crypt, so the foundation is solid, well-proven code, but that doesn't mean there aren't tricky corner cases. With the huge number and variety of Android devices out there, you can be certain that if there's a way it can go wrong, it will. So, conservatism suggests it's a good idea to make it optional for a while and shake out any issues. It's been optional for three years now, and is in use on many devices (I don't know how many; I'd guess tens of millions, though), so it's time to take the next step.
Second, performance was a problem. Not run-time performance -- AES is really fast -- but the initial encryption required reading and writing many gigabytes so it took a long time just to do that much I/O. Encrypting by default means that either the device has to be encrypted in the factory, which would be a major production bottleneck, or else users would have to wait 20 minutes for their phone/tablet to start up just after they unbox it. That's a bad user experience. For L this was optimized so it only encrypts blocks that are in use. Since on a new device very little of the data partition is in use, very little has to be encrypted. That makes the initial encryption very fast (a few seconds).
There's actually another device encryption-related improvement coming in L. I'd love to describe it in detail since I worked on parts of it, but the article doesn't mention it so I'll hold off.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
iOS, like Android, only encrypts all data if a user opts to put a pin in. iOS8 might be different, but all prior version of iOS only encrypted when a pin was entered.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
In addition to the notes that this is a minimal burden on most modern CPUs, Android L will offer much better battery life - on the same devices - owning to it's new execution environment, which will more than offset the additional cost.
I think it's a sop though - the problem, as demonstrated so well recently to a host of famous women, is not that your local device is terribly vulnerable. After all, we're talking one of the few pieces of data storage that most people will have on their person most of their waking hours.
The real problem is cloud storage. While much has been made of the tactics used to gain access to them, note that any sysadmin on the cloud services responsible likely has the same level of access. You'll only have "private" cloud when your device carrys a private encryption key that the service is not privy to - and this isn't going to happen on the big services (excepting MEGA, allegedly), because the reason they let you store your stuff on their cloud for free is because they can mine it for information. And could you really trust a "private" cloud client anyway? Who says the software doesn't leak your private key back to the author?
If you want private data, Free Software is really the only answer, and having your own private hardware would help too.