Disappointing: Google Not Yet Requiring Phone Makers To Encrypt By Default

from the get-things-up-to-speed dept

Well, this is disappointing. Back in September, we were happy to see both Apple and Google announced that their mobile platforms would be encrypted by default (for local storage, not for data transmissions), which has kicked off something of a new round of Crypto Wars, as law enforcement types have shoved each other aside to spread as much possible FUD about the "dangers" of mobile encryption (ignoring that they also recommend mobile encryption to keep your data safe).

However, as Ars Technica reported earlier this week, it appears that while Google is encrypting by default on its own Nexus phones that have the latest Android (Lollipop), it slightly eased back the requirements for its OEM partners such as Motorola and Samsung who make their own devices. Default encryption is now "very strongly RECOMMENDED" rather than required. And even with that "very strong RECOMMENDATION," it appears that neither Samsung or Motorola are enabling default encryption on its latest devices.

While some will likely jump to the conclusion that law enforcement pressure is at work here, a much more likely explanation is just the performance drag created by encryption. Last fall, Anandtech did some benchmarking of the Nexus 6 both with encryption on and off, and as the site itself says, the results are "not pretty." Given the competitive market, there's a decent chance that the big phone manufacturers didn't want to get bad benchmark ratings when phones are compared, and those made the decision to go against the "very strong recommendation."

Hopefully this gets sorted out quickly, as phonemakers can optimize new phones for encryption. And, honestly, as the Anandtech report itself notes, these benchmarks are basically meaningless for real world performance:
The real question we have to ask is whether or not any of these storage benchmarks really matter on a mobile device. After all, the number of intensive storage I/O operations being done on smartphones and tablets is still relatively low, and some of the situations where NAND slowdowns are really going to have an effect can be offset by holding things in memory.
But, it appears, while mobile phone makers don't want to take the chance of bad benchmarks hurting their reputation, they're less concerned about leaving consumers' data exposed.

It's disappointing that this is where things are today, after so much focus on default encryption just a few months ago, but hopefully it's just a temporary situation and we'll get to default encryption very, very soon.

Filed Under: android, benchmarks, encryption, mobile encryption, oems, privacy
Companies: google, motorola, samsung


Reader Comments

Subscribe: RSS

View by: Time | Thread


  1. icon
    lfroen (profile), 3 Mar 2015 @ 10:25pm

    Nothing "disappointing" here

    Google do a right thing here - leave a choice in hands of those who care.
    Did you ever saw a door manufacturer that _require_ to use a lock? Did you ever saw such a car?

    So why the hell my phone should be different? Can I please choose by myself whether to use encryption, what kind of encryption and what to actually encrypt?

    People don't expect that car/house/suitcase will somehow lock itself. And people know how to turn protection on a phone too. My 9yo daughter somehow knows.

    So let the Google write software and let those who care make decisions.

Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here



Subscribe to the Techdirt Daily newsletter




Comment Options:

  • Use markdown. Use plain text.
  • Remember name/email/url (set a cookie)

Follow Techdirt
Techdirt Gear
Shop Now: Techdirt Logo Gear
Advertisement
Report this ad  |  Hide Techdirt ads
Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Advertisement
Report this ad  |  Hide Techdirt ads
Recent Stories
Advertisement
Report this ad  |  Hide Techdirt ads

Close

Email This

This feature is only available to registered users. Register or sign in to use it.