Google Removes Vital Privacy Feature From Android, Claims Release Was Accidental

https://www.eff.org/deeplinks/2013/12/google-removes-vital-privacy-features-android-shortly-after-adding-them

by tijs • 13 years ago

406 203 13 years ago

oceanstone• 13 years ago

When asked for comment, Google told us that the feature had only ever been released by accident — that it was experimental, and that it could break some of the apps policed by it.

Oh, it would definitely break some apps. Considering it would introduce new uncertainty. It's still an amazing feature.

raverbashing4• 13 years ago

Yeah, because checking return codes and error values is overrated

Thanks Google, for making my phone less secure.

signalnow3• 13 years ago

It was never official, it was never announced nor documented.

josteink• 13 years ago

Yeah, because checking return codes and error values is overrated

Even Google's own non-AOSP camera is guilty of this too.

The API docs says an app should check for camera capabilities before using them. Still the PhotoSphere feature in Google's non-AOSP camera attempts to set Flash-settings on devices with no flash-capability.

To overcome the issue you have to rewrite the camera-interface code to ignore API calls to SetFlash, SetLightmode etc when not supported, instead of throwing as you should be doing according to the docs.

So yeah. Even Google is guilty of this one.

hahainternet• 13 years ago

By allowing you to install software they make your phone less secure. Better buy a feature phone ASAP!

jevinskie• 13 years ago

I can't believe they question Google's authenticity when they say it was accidentally released too soon and then go on to criticize the feature for being unpolished and incomplete!

davedx• 13 years ago

I think it's a great feature. There have definitely been some apps where I would have liked to use them but they've had permissions requirements that I did not believe the app's core functionality needed.

rtpg2• 13 years ago

every time I open facebook messanger with gps enabled, I see it querying my location. I hate it so much. Would love to be able to turn that off

arsemouflon• 13 years ago

Well ...

kiallmacinnes3• 13 years ago

Have you tried not opening it?

Seriously, if you use any of facebooks stuff, you clearly value something they offer more than your privacy. Everybody, and I'm not just talking about the HN crowd, knows how bad Facebook is when it comes to privacy.

Nursie9• 13 years ago

I tend to keep GPS switched off in the phone settings because of this sort of thing.

FB is not allowed on my device in the first place because I don't trust it, but it's not the only offender. It really annoys me when I'm in-app or in-browser and I see the GPS icon pop up and start trying to get a lock. Sometimes even before the browser has asked if a page is allowed to have the location.

The answer is no!

lclarkmichalek• 13 years ago

Open the Facebook app -> App Settings -> Messenger location services -> Uncheck Location is on

zimbatm• 13 years ago

If you really want it, the CyanogenMod firware has something similar packaged with it.

tomrod4• 13 years ago

For me, it's things like Facebook, Dropbox, Google search, Twitter, Skype, and a plethora of others that one would expect to seamlessly allow for permissions adjustments.

rtpg2• 13 years ago

I'm surprised this feature wasn't in place from day 1. It probably involves almost no implementation overhead on the OS side of things.

Apps, on the other hand, would have an extra error case to deal with, but they should be dealing with other error cases anyways.

gorhill2• 13 years ago

"they should be dealing with other error cases anyways"

Especially when "Access to all your contacts" (or whatever) is really not needed for the application to work correctly.

kmfrk3• 13 years ago

It's been a pretty shitty week for privacy, hasn't it? First the Disqus hack, then the changed Block feature on Twitter, and now this?

djm_• 13 years ago

Twitter has gone back on that after listening to user feedback. I honestly think this 'App Ops' feature will also return, it was only found by sniffing about in the APKs and could only be activated (easily) by installing an app which surfaced the settings pane; that's not the same as it being a default menu option that was removed - it wasn't meant for public release yet. I appreciate the EFF and their stance on this but I'm giving Google the benefit of doubt on this one, hopefully we'll see it soon in its full glory.

SamReidHughes2• 13 years ago

The changed block feature on Twitter didn't do anything negative for privacy.

kmfrk3• 13 years ago

It took away users' ability to block other users from viewing their tweets? How is that not privacy?

signalnow3• 13 years ago

This was not officially released, nor was it user facing.

salient• 13 years ago

I hope it wasn't just an "accident" and Google really was working on a way to make it work for both developers and users, and perhaps it was there much like the ART runtime is in there, even though it's not ready for primetime.

I think Google can make it work, but they need to be committed to it. Surely there's a way for the apps to gracefully transition to not needing certain permissions. Google just needs to introduce the proper rules for developers to make this work.

hrjet• 13 years ago

I don't have hopes of Google restoring the AppOps functionality in the future. Most of the apps require these excessive permissions because of third-party ad libraries. Google's AdMob library is the most popular of these libraries, being used in 36% of Android apps [1].

[1] http://www.appbrain.com/stats/libraries/ad

awjr• 13 years ago

I didn't use App Ops. Did it allow a general policy to be set? I can see you can set permission per app from the screen shot.

I'm not sure I buy Google's excuse. Any app worth it's salt should be able to cope with not having the permission set. I'm guessing this was impacting their own core apps.

eropple5• 13 years ago

Any app worth it's salt should be able to cope with not having the permission set.

That doesn't in any way follow. My Android application handles the expected failure cases enumerated in the API. It does not handle the "permissions granted when the user saw your manifest and agreed to grant those permissions disappear because reasons" case because they're is no reasonable expectation that case is necessary. The APIs don't allow for that case, if it throws a catchable exception at all it'll be an undocumented one, I can't differentiate between it any other exception that might roll out of Android. Why would be anything other than unhandled?

Which isn't to say that data permissions should not be mockable; they should. But your "anything I don't understand is easy" post is straight-up bad.

616c• 13 years ago

Whatever, fuck Google.

If you are interest in doing this with Android, the autopatcher[0] does this for you on a whole series of ROMs on all versions of Android from 2.x-4.x, and has been doing so successfully for a while. There is a pretty active user community on XDA for the PDroid patchset as well.[1]

[0] https://github.com/mateor/auto-patcher

[1] http://forum.xda-developers.com/showthread.php?t=1357056

Kequc• 13 years ago

Whatever, fuck Google.

Well this is going to be productive.

I'm pretty sure Google isn't out to put all of its users through a meat grinder. For one thing people have been way off the handle about Google touching anything. At all. This article only mentions an accident that lasted one day. So it's "fuck Google" after everything, still, again I guess.

FeloniousHam2• 13 years ago

Right on, right on. While I like the potential of this app, the millions of devices with billions of applications that would simply stopping working with its introduction mean it will need a carefully orchestrated rollout. HN readers might be comfortable with "ever beta" technologies, but the other 99% of users are not (and it's odd that smart people fail to appreciate this).

nekopa• 13 years ago

I don't know if you read the article properly (or maybe I didn't) but the 'accident' was improved privacy. Then they took the better privacy feature out. So that could qualify for a fuck Google comment.

panzerboy• 13 years ago

There is a way of bringing it back, however the phone has to be rooted. See here: http://www.xda-developers.com/android/xposed-module-brings-b...

wting• 13 years ago

If you have root you can still enable it with market apps.[0][1]

However something like this needs to be integrated tightly like iOS and apps need to be aware they may not receive requested permissions. I still use App Ops in Kit Kat and it silently breaks apps all the time. Apps expect to be able request information (e.g. contact details) and crash or stall when they can't.

In that respect, LBE Privacy Guard[2] was a much better alternative up to ICS. It was a privacy firewall that would pop up notifications when protected permissions were being used for the first time. Instead of blocking apps when denied, Privacy Guard would feed it blank data instead. This lead to a better UX and stopped blocked apps crashing.

There needs to be an open source version of LBE Privacy Guard since the current one hasn't been updated over a year and is closed source from a Chinese company.

[0] https://play.google.com/store/apps/details?id=com.colortiger...

[1] https://play.google.com/store/apps/details?id=biz.bokhorst.x...

[2]: DO NOT INSTALL, FORCES REBOOT LOOP

https://play.google.com/store/apps/details?id=com.lbe.securi...

rjzzleep• 13 years ago

here's a translated version that i've been using this up to 4.3.(haven't updated my nexus phone to kitkat and am not planning to either)

http://forum.xda-developers.com/showthread.php?t=1422479

although i think this might also be working in kitkat. what i can recommend to users though is to use pdroid if they wish to do so. so you could use lbe for all apps. and pdroid for lbe itself. a lot of jelly bean custom roms support openpdroid. i personally use cyankang

http://forum.xda-developers.com/showthread.php?t=2212620

magic_haze• 13 years ago

xprivacy does the same thing, and seems to be actively developed. The only problem is that it has an atrocious UX, but again, that seems to be on par for most android utils.

mike-cardwell• 13 years ago

Patch CyanogenMod with OpenPDroid, and install that. That's what I did.

hnha2• 13 years ago

i really miss lbe security on Android 4. Weird how it was abandoned.

JangoSteve• 13 years ago

You don't need root for that first app! I've been using it just fine without root. The description tells you what extra features you get with root, but you can handle the privacy issue without.

tjoff• 13 years ago

Yes you do need root for that first app if you have android 4.4.2 - which is what the whole discussion is about.

fooqux3• 13 years ago

I think the article is a tad misleading here, and I think your first link is going to add to the confusion.

The ability to revoke permissions was built right into the System Settings app, but the ability to access it was hidden from view. Custom roms would usually add a link to it, and apps like AppOps by ColorTiger (your first link) was simply a pointer that would trigger that view to activate (I'm glossing over the root functionality here).

What Google did in 4.4.2 was remove the hidden view from settings. This means that apps like ColorTiger's AppOps will no longer work at all- there is nothing for it to call. The pointer has been dereferenced, if you will.

Apps like LBE (which I share your desire for a newly updated, open source version which doesn't cause bootloops on newer versions of Android), PDroid, and presumably XPrivacy (which I've never heard of, but am looking into now for the inevitable upgrade to 4.4.2 if OmniRom is unable to provide a new solution) work because they replace the functionality that Google removed, not just call something built into Android, but hidden.

Dylan16807• 13 years ago

The pointer has been dereferenced, if you will.

...'dereference' means 'access the pointed-to data'

auctiontheory• 13 years ago

The pointer has been dereferenced, if you will.

I do not think dereferenced means what you think it means.

zrgiu_• 13 years ago

Color Tiger dev here - actually with our version and root access you can install a recompiled version of AppOps with a few extended features as well - rebranded as AppOps X

drdaeman3• 13 years ago

XPrivacy (FLOSS, uses Xposed framework, mostly fakes data instead of cancelling access, if possible) works for me: http://forum.xda-developers.com/showthread.php?t=2320783

It has some rough edges like asking me to check permissions after every (auto)update, even if app hadn't requested any new permissions, but allows relatively fine-grained (API function-name-level) permission control. Root permissions are only required to install Xposed, after Dalvik's runtime's hooked no root's required.

Oh, and "pro" features are useless (you can just build your own version from GitHub sources to enable export, and sharing is completely awkward without any UI to see what happened), but I still donated. Disclaimer: I have no affiliation to this project other than using it on my phone.

em3rgent0rdr• 13 years ago

There is an opensource privacy guard built into cyanogenmod. I just installed the latest nightly CM 11 on my phone (built off of latest android 4.4.2 kitkat), and was pleased to see textsecure integrated as the default SMS as well. Thankfully the CM community cares about things such as privacy...can't trust the big corporate behemoth google.

jackgavigan2• 13 years ago

This is one area where iOS stands head and shoulders above Android. I used to run Cyanogenmod and I remember deciding to not upgrade the Facebook app because doing so would have required giving it a slew of permissions, including the ability to "directly call phone numbers".

By contrast, in iOS, I can choose which apps have access to my location, contacts, etc.

I know that Apple's track record when it comes to privacy isn't exactly spotless but Google would be well advised to follow their lead in allowing users granular control over 3rd-party apps' permissions.

tomp• 13 years ago

So far, I've been an Android fan (I love the customizability and all), but if anything will make me buy an iPhone, it's this feature.

outworlder• 13 years ago

Do not expect Google to implement it anytime soon, due to the massive app breakage potential.

Android's permission system looks good on the surface. However, there are so many required permissons nowadays that many users do not even check them anymore. And you can revoke specific permissions on an app by app basis.

On iOS, developers are told not to rely on certain permissions being available, such as location. Some apps truly can't function without those, but they are supposed to warn the user, not crash.

e40• 13 years ago

Do not expect Google to implement it anytime soon, due to the massive app breakage potential.

I run AppOps 4.3/4.4 rooted (so I use the "App Ops X" version internally), and I must say, I've restricted most of my non-system apps and I've never seen a single broken app.

I think this potential is vastly overblown.

EDIT: for example, in the official twitter app, I turn off these:

* Location

* Read contacts

* Receieve SMS/MMS

* Post notification

* Wake lock

Never had a single problem with the app.

jre• 13 years ago

As long as the disallowed permissions simply return empty results (or random stuff) for the API calls, I don't see how this can break apps.

barrkel• 13 years ago

There is almost zero app breakage potential. Because the implementation shouldn't be refusing permissions, it should simply be mocking them. Ask for a location? Mock it to an arbitrary location. Asking for contacts? Return an empty list, or a list with joe.smith@example.org. Etc.

rahoulb• 13 years ago

This is somewhere where android fragmentation is truly an issue. iOS didn't have granular switchable permissions a couple of versions ago but as the OS moved forward so did the apps.

shrikant• 13 years ago

CyanogenMod has this killer feature called Privacy Guard which you can enable on a per-app basis. It allows you to use the app and lock it out of unwanted permissions without breaking the app functionality.

corresation2• 13 years ago

By contrast, in iOS, I can choose which apps have access to my location, contacts, etc.

Could you detail the "etc"? To my knowledge historically the only activity that triggered a permission confirmation was a precise location fix. Later, after a debacle with many apps siphoning and scurrilously offloading contact lists, contact access was added as a confirmation.

Android has very granular permissions, and iOS does not. If you don't like the requests of an app, the general option is not to install it. Such is exactly what I've done with a number of small vendor apps -- if you demand anything that you don't need, I don't install.

Of course on the flip side Android, be design, allows for much tighter integration and leveraging between apps and the OS, so there are more interesting opportunities, both for good and bad. But those, too, are covered under permissions.

neilkimmett• 13 years ago

In iOS7 you can granularly allow/disallow apps access to: location services, contacts, calendars, reminders, photos, bluetooth sharing, microphone, motion activity (iPhone 5S and new iPads only)

The first time an app tries to access any of the above you will be asked whether to grant it permission or not. You can then edit this preferences in Settings.app > Privacy

mdorazio• 13 years ago

Looking at the Settings area on my phone, it is possible in iOS 6 to set App-level permissions for: -Push Notifications -Location Services -Contacts -Calendars -Reminders -Photos -Bluetooth -Twitter Account Access -Facebook Account Access. Note that iOS7 may have added more.

endemic• 13 years ago

I think benefit of iOS privacy controls is that you can still install the app, then simply deny it access to data. Android asks you for _all_ permissions up front: allow access or you don't get the app. See: recent flashlight app fiasco.

reginaldjcooper2• 13 years ago

Android's permissions are not granular enough and forcing the user to accept them all or not use the app is a security/privacy fail. I love that Android apps can access the telephony API but the permissions for that need to be more fine grained and the toggles to enable them need to be discreet over individual permissions.

Discreet toggles and the request dialogs are roughly the only thing I prefer iOS to Android on. Too bad the rest of iOS is a prison.

dublinben• 13 years ago

BlackBerry actually gave completely granular permission controls for every app you install, as far back as five years ago. It's a shame that neither iOS or Android have come anywhere close in that regard.

ansible2• 13 years ago

The original intention (as explained by Dianne Hackborn among others) is that if the user sees the app requesting too many capabilities... the user should simply choose not to install the app. Having the user needing to understand all the different capabilities is too much. Having a bunch of pop-ups (cough Vista) is also bad UI design.

The current set of capabilities is too technical for end users to really understand. This all need to be collapsed into a few broad areas like "tracks your location" that have clear, clickable explanations.

For the privacy paranoid, having a configurable way to just inject false data would be great. Have a single fake IMEI number, for example. Then for apps, the API call doesn't fail, it just returns the fake number.

DanBC2• 13 years ago

Have a single fake IMEI number, for example.

How would that work in countries where modifying the IMEI is illegal?

UK law (note prison sentence) http://www.legislation.gov.uk/ukpga/2002/31/section/1

I don't know if this is current US law or not. Here's one example http://thomas.loc.gov/cgi-bin/query/z?c112:S.3186.IS:

dTal• 13 years ago

The suggestion was making a userspace call to retrieve the IMEI return a fake value, not modifying the IMEI itself. Perfectly legal, although I imagine a great legal battle could be fought over the interpretation of "interfere with the operation of".

I am, however, surprised that MAC spoofing is enough to get you a prison sentence if done on a "mobile wireless communications device".

EDIT: apparently as of a 2006 addendum in the "Violent Crime Reduction Act" even offering to do it for someone else will land you in the clink. Gotta keep those violent hackers off the streets I guess.

leoedin• 13 years ago

That law seems particularly draconian. I assume it's an attempt to criminalise the changing of IMEIs on stolen phones? Reading that is slightly alarming, if only because I wouldn't have even considered that it could be illegal before today. I wonder how many other pieces of legislation I've naively violated?

Nursie9• 13 years ago

I don't think android would affect the IMEI that gets sent to the network, and the intent of the law was to allow tracking of phones by IMEI (kinda scary in itself, kinda useful for law enforcement) and to allow stolen phones to be blocked from the network and rendered useless, which AFAICT has had a huge impact on levels of phone theft.

> But a person does not commit an offence under this section if—
> (a)he is the manufacturer of the device, or
> (b)he does the act mentioned in subsection (1) with the written consent of the manufacturer of the device.

Perhaps the manual that comes with your phone could come with a line in the license saying that modifying the IDs for the purposes of stopping apps snaffling data is allowed.

yareally• 13 years ago

It would modify it on the application level (user apps are sandboxed anyways), but not on the system/telephony level. System would still be aware of what the real IMEI is, just not whatever shady app requesting the permission.

reginaldjcooper2• 13 years ago

That is one of the more shortsighted laws I have ever read. Or farsighted, depending on your cynicism about surveillance.

I wonder if I generate a UUID on your phone in my app, if you delete the app data does that run afoul of this law?

dhekir• 13 years ago

I can choose not to install an app, but Google prevents me from doing it intelligently, that is, filtering the crappy apps demanding ridiculous permissions. I have to manually click on dozens of them before finding one that does not require, say, Internet access. APEFS (http://www.bs.informatik.uni-siegen.de/forschung/apefs) allowed such filtering, but since Google Play was updated some months ago, it stopped working and was removed. Now I have to resort to F-Droid for free apps, but there are not nearly as many as in Google Play.

Pxtl• 13 years ago

Exactly. The Play Store does not allow me to sort by permissions and doesn't display them up-front, making concern about permissions a fruitless endeavor.

Give me a fuzzy-sort option where I can just apply weightings to how much I value out of (1) Permissions, (2) Popularity, (3) Price and (4) Relevance

throwwit2• 13 years ago

This is a pretty disturbing trend. Just recently I ran into problems with a TV station's app on iOS that refused to play video without Location Services Enabled. I don't mind a general region being disclosed, but the house-level accuracy of the location data definitely creeps me out. I don't think the general public realizes location can be equivalent to a person's id.

dictum• 13 years ago

I don't mind a general region being disclosed, but the house-level accuracy of the location data definitely creeps me out.

This is exactly what I want most of the time. My ISP's servers are usually in neighboring cities, so geoip isn't precise enough, but GPS is too precise for my needs. I just want to disclose what city I'm in. This is enough info to give me useful results (e.g. I search Google for "italian restaurants", it gives me results for my city first) without violating my privacy by giving Google my location habits. Maybe OSes could give an option to reduce the granularity of the location reported, so you could disclose the town or state, but not the exact street, for instance.

hnha2• 13 years ago

There are apps to "fake" your location so maybe you can find a suitable one. I never used one but my external Bluetooth GNSS device feeds its accurate location into Android the same way. Please share if you do find a good one!

mikecane2• 13 years ago

>>Just recently I ran into problems with a TV station's app on iOS that refused to play video without Location Services Enabled.

When it comes to things such as entertainment, regional rights restrictions probably have more to do with that than the app wanting to spy on you. I'm not saying this is right. Just saying how the lawyers have sliced things into pieces like that.

throwwit2• 13 years ago

They could get that region-level information already from ISP routing info. This ratcheting up of info means: The household owner's name, their affluence, postal code, phone number, a cross match with google street view and all info that shows (new car?). The last thing I want is to watch a home reno show on a tablet and then be deluged with phone calls soliciting for new windows. This is definitly not 'right'. (edit: on top of watching ads that glitch and repeat.)

polskibus• 13 years ago

I'm really disappointed, seems like my next phone won't carry Android! App opps worked great for me and help alleviate some worries about tracking. I could also see which apps actually used their claimed Android features. Many of them claim to use location yet never access it.

CalRobert4• 13 years ago

I'm probably going to turn in to that old guy with tin foil who can't play any games because nobody supports his choice of platform, but I really miss when computers were devices you could buy and then put your choice of OS on. Phones are pretty much just little ARM computers, why the hell don't I just install Ubuntu, Firefox OS, Android, WinPhone, Symbian, whatever? I could format a microSD card to boot from and go from there.

And while I'm complaining, phones (devices for communication, remember?) need proper keyboards.

OK. I'll crawl back into my cave now.

StavrosK3• 13 years ago

Why not? I installed Ubuntu the other day, it was trivial. Plus, there's a multitude of custom ROMs.

CalRobert4• 13 years ago

Yeah, but what you would call trivial might be insurmountable for lots of people. Cyanogenmod already has a lot of the privacy features missing in Android, but dicking around with clockworkmod recovery, etc. is pretty daunting.

thecodeore• 13 years ago

Because while the ARM processor is probably supported, most of the other sensors, camera, cell radios, etc have proprietary binary drivers that are not.

Just read the problems Replicant, the true FOSS android, has had getting all components to work correctly.

CalRobert4• 13 years ago

An excellent point, and a bummer.

ChuckMcM• 13 years ago

It will be interesting if we can get more people to flip their HW over to the 'open' side of things.

Nursie9• 13 years ago

One of the issues with that is that devices on ARM systems are not as discoverable as a lot of other systems. You tend to need a kernel built for a particular processor variant, and it needs a device map of some sort for your specific device or it won't know how to find any of the stuff on the board and may just crash. Without this map you just can't boot.

Graphics are also very non-open at the moment, so it can be very hard to install other operating systems in a useful way for that reason.

In theory though, I agree entirely, that would be nice :)

nileshtrivedi3• 13 years ago

Linux supports Device Tree mechanism which solves this issue. You would download a kernel for the correct processor and a .dts file that describes the phone's hardware.

ouaibe• 13 years ago

Because phones inherit from an old business model where they were subsidized by mobile network operators and thus manufactured and sold according to their needs, not to the users need.

This meant you'd have many restrictions and the user was constrained to a tightly-controlled environment that forbode anything the operator deemed unnecessary (and could even contain malware/spyware-like pre-loaded software).

That model gradually evolved into J2ME platforms (and the like), where developers (and sometime users) could make small customizations, until someone decided there was a huge market selling phones designed not for the operators but for their customers (i.e. Apple/Google).

They still built the product partly following the same mindset/model and provided VM-centric phones that still are not designed to give you ring-0 access from the get go and maximize the operator's & manufacturer control on your device, hoping to gain revenues from gated developer communities, reselling applications that are mostly yet another graphical layer on top of code that already exists natively on regular computers since a long time ago.

That model is gradually evolving (hopefully in the right direction) and operators are slowling realizing that they're not device vendors but merely ISPs, which means that the phones are to be sold to customers, centered around their needs and giving them the maximum control (letting them chose the OS and giving them ring0 access).

You still need to get rid of the protected baseband cpu, the SIM, the TEE, the protected bootloaders etc. and eventually might have the device that you speak about.

contingencies• 13 years ago

phones inherit from an old business model where they were subsidized by mobile network operators

Only in the US.

FigBug2• 13 years ago

I think not tying the OS to their hardware was a mistake by IBM. And while it may have let the PC win, what is the point of your platform winning if you get forced out of the business by the clones? There is no money in hardware, you need to control the OS.

Tyrannosaurs4• 13 years ago

Re. proper keyboards - the market says otherwise. There have been plenty of Android phones with hard keyboards but they've not sold in sufficient quantities to make it attractive.

If there was a market for it, people would be making them, if you disagree with that they what are you doing on here, your fortune awaits...

Also worth seeing kids who've never used a physical keyboard to any great extent. I've seen them doing what must be close to 60 words a minute on a touch screen (tablet rather than phone but still). If you're used to it a touch screen keyboard isn't a massive limiting factor.

EDIT: This is interesting: http://psychology.wichita.edu/surl/usabilitynews/122/ipadtyp...

A study showing netbooks to have a typical typing speed of around 60WPM vs 40WPM for iPad, but interestingly it mentions that none of the participants had used an iPad.

I'm guessing that someone with significant experience on a particular OS / soft keyboard with correction could close that gap pretty sharpish.

EDIT2: http://thinkertry.com/2012/10/30/typing-speed-test-iphone-vs...

Someone testing iPhone, iPad and keyboard two years running:

2011: iPhone: 57 wpm, iPad: 60 wpm, Keyboard: 71 wpm 2012: iPhone: 51 wpm, iPad: 75 wpm, Keyboard: 82 wpm

It seems that practice does indeed close the gap. Given that the total install base for touchscreen devices will exceed that for PCs in the next 12 months (probably next 6), that greater level of familiarity will shortly become standard.

uchi• 13 years ago

There's actually something fairly interesting at play that should be mentioned: Typing with a physical keyboard is much more accurate than a touchscreen, but a touchscreen makes up this deficiency by a much simpler to use word completion feature. Error correction is also a breeze. Most of the words written in this post took advantage of those factors, and it took me about a minute to type everything up.

tomrod4• 13 years ago

User preferences != the market. They are half the market.

What this really says is that virtual keyboards have practically no cost, and so utilizing them instead of physical keyboards saves more in marginal (and perhaps per-unit) cost than the revenue from lost customers that require a physical keyboard.

DerpDerpDerp4• 13 years ago

If there was a market for it, people would be making them, if you disagree with that they what are you doing on here, your fortune awaits...

This is incredibly disingenuous because of the high barrier to entry on cellphone manufacturing.

kunai• 13 years ago

There have been plenty of Android phones with hard keyboards but they've not sold in sufficient quantities to make it attractive.

They haven't sold because they've sucked. They had low-quality displays, crappy software, slow SoCs, and barely enough memory to be usable. The only keyboard phone left is BlackBerry, and that's not selling, well, because it's a BlackBerry.

There is a huge market for regular keyboard cellular devices. It's just that nobody's made a half-decent phone along with the keyboard.

If there is a device with a physical keyboard, a tapered, curved design, high quality components, a top-notch display, excellent build quality, the latest versions of Android, and good marketing, and you have a winner on your hands.

It's just that idiotic OEMs like HTC and Samsung would rather follow the fruity status quo than break from the norm. Only BlackBerry seems to have any balls today. Shame they're practically dead in the consumer sector.

saraid2163• 13 years ago

Market realities are not really the substitute for thinking that you seem to think they are.

pjc502• 13 years ago

The touch keyboard lacks feedback but folds to zero size, which is its great advantage. And people are in practice getting along just fine with them, which is why the hardware keyboards have fallen by the wayside.

The main obstacle to boot-your-own-phone in the US is of course the carriers.

tomrod4• 13 years ago

The main obstacle to boot-your-own-phone in the US is of course the carriers.

Surely if it were profitably one of them would break ranks, right? I mean, we have intelligent businesspeople in telecoms at least occasionally?

10098• 13 years ago

I really miss when computers were devices you could buy and then put your choice of OS on.

uh, those are still around you know. You can even carry them in a backpack.

signalnow3• 13 years ago

I don't understand this from the EFF first they post a piece lauding an unofficial, deeply buried unannounced functionality, then they condemn Google for removing something that they have never officially released or supported in the first place.

It’s their mistake for jumping the gun and discussing something that wasn't officially, the followup is just to save face, but that is really an unfair attack.

freehunter• 13 years ago

How would anyone know it was not official until Google said it wasn't meant to be released?

ben10403• 13 years ago

What sort of official feature is hidden and can't be accessed via any user interface provided by the vendor?

trurl42• 13 years ago

I hope this feature will get added again in a future version.

It was not an official feature in KitKat and somewhat breaks the current API, where developers didn't have to check for permissions at runtime.

Android 5.0 maybe?

Nursie9• 13 years ago

They still need to split the permissions more. READ_PHONE_STATE is nasty.

Apps ask for the permission because they (for instance) need to pause playback on a video because you have an incoming call. But it covers all the phone details (numbers, IMEI etc) and who the call is coming from and a hell of a lot of other stuff.

Who the hell thought that was a good idea?

ben10403• 13 years ago

Yep. I have gotten one-star reviews on an app of mine because they think I want to invade users' privacy, when I really just want to pause media when a call comes in.

READ_PHONE_STATE means I have to decide whether I want a handful of one-star reviews for requesting that permission, or a truckload of one-star reviews for the app playing media over their calls.

chuinard• 13 years ago

Have you considered listing the reasoning behind your permissions in your app description?

uniray• 13 years ago

I'm surprised at the EFF. this post seems intended to save face for them rather than anything else.

They had a post recently lauding App Ops although it was never officially released, announced nor documented. And it certainly was not accessible to the average user.

Also it was obviously not compatible with most apps, as they didn’t fail too gracefully. Again: App Ops Was Never Meant For End Users, Used For Internal Testing And Debugging Only

http://www.androidpolice.com/2013/12/11/googler-app-ops-was-...

I do hope Google is working on something similar on an OS level for future releases, but this hack job by the EFF is disappointing and unnecessary.

biehl• 13 years ago

Because using "beta" features from Google is unthinkable?

I think it makes perfect sense to laud even small steps in the right direction (beta-quality features etc.) and comment negatively on steps in the wrong direction (removing privacy options for users).

pgsandstrom• 13 years ago

I would guess this is because cancelling the internet permission can be used to block ads. Ads that generate money for Google.

lifeisstillgood• 13 years ago

If they put it back with next release, it was accidental.

If not, not.

nimble• 13 years ago

They're claiming the release was accidental. Not the removal.

Zigurd2• 13 years ago

This is very disappointing. I had hoped the release of App Ops as a hidden feature indicated that permissions would be user-revocable in a future release.

It isn't a burden to handle security exceptions.

Zigurd2• 13 years ago

Jolla and/or Myriad could make some hay by adding a similar feature to the Android compatibility runtime used in Sailfish.

SmileyKeith3• 13 years ago

This is a major issue Google needs to deal with in Android IMO. I'm surprised that this feature ever existed in Android because of how coupled permissions are with applications. Since applications request all permissions on install I imagine most developers don't have much conditional code for their failure, unlike iOS where you have to because there's a possibility a user may deny access to a single specific thing, like location data. I'd really prefer to see Android go more towards that. When you look at the permissions an application like Facebook requests on install it's just insane.

jxf2• 13 years ago

That's partially because developers are somewhat incentivized to "front-load" their permissions. If you think there's even a chance you might use a permission, even if your app doesn't currently use it, ask for it on the first install.

Then, later, when you actually do want to use it, your app update won't say that you need any new permissions.

exodust3• 13 years ago

This doesn't sound right to me. I don't think developers are doing this.

SmileyKeith3• 13 years ago

I definitely get that. With automatic updates I bet that a lot of applications sit in that update queue on people's devices since they actually have to confirm the new permissions.

cognivore• 13 years ago

There is another point here, one I think even more important and more disconcerting.

Google released an entire feature of their Android OS BY ACCIDENT. W...T...F?! How do you release a feature "by accident?" By having awful quality control? How does that make me feel about the rest of their Android OS now?

Either this, or they're lying through their teeth in an effort to cover up. In either case, it's evil.

chaz2• 13 years ago

Hanlon's Razor probably applies here. http://en.wikipedia.org/wiki/Hanlon's_razor

mcguire2• 13 years ago

Stupidity and malice are frequently indistinguishable by an outside observer.

mattmcknight• 13 years ago

It's more like they left an undocumented feature accessible.

morpher• 13 years ago

From the comments, it sounds like the preference pane was hidden and had to be enabled by installing 3rd party software. Having experimental features in software that are hidden (but included for testing in limited situations) is not surprising, nor WTF worthy.

Groxx2• 13 years ago

This is exactly the case. Someone noticed it somehow (source / activities dump, I forget) and figured out how to launch it. And last I saw it wasn't actually removed, it just had stronger permissions on what was allowed to launch it, which broke all existing launchers. There may or may not be a new way to launch it.

Meanwhile, the source code keeps moving more and more towards having a real runtime-permissions-manager. Honestly I think they'll have something soon, but probably not before 4.5 or 5.0. In the meantime, I've been loving XPrivacy, it's probably more granular than anything they would release anyway (and I've had exceedingly few crashes, blocked data is faked not broken).

kllrnohj2• 13 years ago

No, EFF is simply wrong. The feature was never released, and instead of posting a "we screwed up" retraction EFF is now trying to shift blame.

annoyedgoogler• 13 years ago

If you put software into the wild - you have released it. Just because the cycle has sped up, you didn't document it properly, and your QA failed, does not mean you didn't release it.

I'm not taking sides here, but you have to call a spade a spade.

gorhill2• 13 years ago

All these abusive permissions are an excellent opportunity for GNU-licensed software (free, no ads, only strict minimum of required permissions -- all honestly explained) to thrive on Android.

zmmmmm• 13 years ago

It seems really dumb of Google not to just go with the flow here and let the AppOps feature exist. Whack a giant disclaimer on it that it will break stuff, disable Play Store comments and ratings, let the users use it, and collect the giant PR dividend for looking like you care about privacy. They can do all that and lose virtually nothing because such a tiny percentage of people will ever use this feature that it will make no difference to them at all.

On the other hand they can go the other way and take a giant PR hit for virtually no benefit. Out of some sense of stubbornness or beligerance Google often seems to desire to shoot itself in the foot like this.

cpleppert• 13 years ago

I don't if it will break a lot of applications; probably some. The real problem is the permissions system that doesn't allow users to selectively choose which permissions they want to give to applications thus application developers don't code their applications to not work if they fail to get permission. Users are just shown a screen with the permissions the application requested. For most users, this is worthless. Do any users decide not to install an application based on asking for too much? Users still don't have any control on stock systems over running services and applications in the background.

It is all 100% anti-users and pro-monetization; which is probably google's intention all along.

GrinningFool• 13 years ago

I'd love it if enabling a feature like just caused the selected data points to be returned, but completely bogus (invalid phone number, empty address list, north pole location, etc). It would work for almost everything except network access, and would ensure that it didn't break apps in a bad way.

The all-or-nothing data privacy model of android makes me a bit crazy now that I'm using it on a regular basis for my tablet. That's one thing BlackBerry got right - you can grant or deny individual permissions to applications, and generally could safely assume that application developers knew this and handled security access exceptions when trying to access protected data.

discardorama• 13 years ago

Users of Android should realize that they are the product. If Google gives too much privacy control, advertisers won't pay as much for ads, and Google's core business is ads.

Given a fight between privacy and ad dollars for Google, privacy will lose almost every time (within reason; Google doesn't want to kill the golden goose (i.e., you)).

kiallmacinnes3• 13 years ago

I have to admit, the EFF has just lost a chunk of support from me over this. Google never released this feature - you needed to install some 3rd party app to expose the settings, this alone is enough for anyone of any intelligence to know they are doing something not intended for the general public.

Seriously EFF, get your act together please. I do want to support you, but not like this.

Google Removes Vital Privacy Feature From Android, Claims Release Was Accidental

Related Stories