
Google Removes Vital Privacy Feature From Android, Claims Release Was Accidental - tijs
https://www.eff.org/deeplinks/2013/12/google-removes-vital-privacy-features-android-shortly-after-adding-them
======
wting
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...](https://play.google.com/store/apps/details?id=com.colortiger.appopsinstaller&hl=en)

[1]:
[https://play.google.com/store/apps/details?id=biz.bokhorst.x...](https://play.google.com/store/apps/details?id=biz.bokhorst.xprivacy.installer&hl=en)

[2]: DO NOT INSTALL, FORCES REBOOT LOOP

[https://play.google.com/store/apps/details?id=com.lbe.securi...](https://play.google.com/store/apps/details?id=com.lbe.security.lite)

~~~
TheCraiggers
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.

~~~
auctiontheory
_The pointer has been dereferenced, if you will._

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

~~~
TheCraiggers
Holy shit, I feel like an idiot. Still, thanks for pointing it out.. keeps me
humble.

Kids, if you're curious what we're talking about, look up dangling pointers in
C, which is what I should have 'referenced' in the first place.

~~~
richbradshaw
It's OK – I hadn't realised that's what dereferenced meant either! Has been 10
years since I wrote any C though.

------
CalRobert
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.

~~~
Tyrannosaurs
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...](http://psychology.wichita.edu/surl/usabilitynews/122/ipadtyping.asp)

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...](http://thinkertry.com/2012/10/30/typing-speed-test-iphone-vs-ipad-vs-
keyboard/)

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.

~~~
DerpDerpDerp
> 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.

~~~
Tyrannosaurs
It's an offhand line but the point stands - people who have the resources to
overcome the barrier have tried and the phones don't sell in great numbers.

Once they get used to a good soft key board like you get on the iPhone or most
Android phones people either don't want (or don't feel they need I suspect)
physical keyboards.

~~~
DerpDerpDerp
That a large company can make enough money by focusing on one type of phone,
thus not splitting their engineering efforts doesn't mean that there wouldn't
be a viable niche market, if not for barrier to entry.

I often hear people lament the design of their phone, caused by the
preferences of the majority.

~~~
tomkarlo
It's hard enough to make a profit on popular phones, as evidenced by the woes
of HTC, Blackberry and others... making a phone for a niche group, especially
if you can't charge materially more (and I mean $1,000 or more, unlocked) just
doesn't make any sense. Particularly when you consider that carrier and OEM
marketing (large national campaigns, in-store placement, etc) doesn't scale
down to small volume products.

Making niche products doesn't work well for consumer electronics in general,
unless you can sell that product at a much higher margin. Having a keyboard on
a phone just doesn't seem to result in being able to sell it for twice as
much.

Another issue with keyboards is they don't internationalize well. So rather
than having 1 hardware design worldwide, you now either need a TON of SKUs -
one for each country (and you can't move inventory from one market to another)
or you need to further limit your target market to just a few regions.

------
Nursie
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?

~~~
ben1040
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
Have you considered listing the reasoning behind your permissions in your app
description?

------
jackgavigan
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.

~~~
outworlder
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.

~~~
barrkel
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.

~~~
jackgavigan
> ..the implementation shouldn't be refusing permissions, it should simply be
> mocking them. Ask for a location? Mock it to an arbitrary location.

Like 38° 53' 50.55", -77° 2' 14.51"

------
cognivore
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.

~~~
morpher
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.

~~~
Groxx
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).

------
616c
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](https://github.com/mateor/auto-
patcher)

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

~~~
Kequc
> 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.

~~~
nekopa
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.

~~~
guyzero
I don't know if you read the article properly but this was never an actual
feature. They were debug screens that required a third-party app to access.
There's no way to access these settings at all from the system UI.

------
ChrisAntaki
> 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.

~~~
raverbashing
Yeah, because checking return codes and error values is overrated

Thanks Google, for making my phone _less secure_.

~~~
josteink
_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.

~~~
The_Double
Google is one of the worse offenders when it comes to not following android
guidelines. Their apps consistently break back button behavior, don't follow
UI guidelines, etc.

------
SmileyKeith
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.

~~~
jxf
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.

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

~~~
jxf
I don't think developers _should_ do it, but there's no question that they're
doing it.

For example, Facebook requests almost every permission under the sun. But if
you look at the average user's permission profile for their Facebook app,
they'll only show a tiny fraction of the overall permissions that Facebook
originally requested.

~~~
SmileyKeith
And that's the really scary part. Is that so many applications do this for
just unreasonable permissions. Then you get one of the bad applications that's
actually using that data for something nefarious and it destroys trust in the
process. For me at least.

------
ansible
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.

~~~
DanBC
> 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](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](http://thomas.loc.gov/cgi-
bin/query/z?c112:S.3186.IS):

~~~
leoedin
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?

~~~
thaumasiotes
[http://www.amazon.com/Three-Felonies-Day-Target-
Innocent/dp/...](http://www.amazon.com/Three-Felonies-Day-Target-
Innocent/dp/1594035229/)

------
throwwit
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
> 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.

~~~
hnha
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!

------
davedx
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.

~~~
rtpg
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

~~~
kiallmacinnes
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.

~~~
eropple
This is the sort of sad comment that continually amazes me. Facebook is am
important part of the social life of millions (billions?) of people. It isn't
feasible to go away from it. It's completely reasonable to have a requirement
to use Facebook while not wanting it to be an ass about stuff like constant
GPS fixes.

Yeah, sure, don't use Facebook. You're the guy who butts into conversations to
tell everyone how you don't own a TV, aren't'cha?

~~~
kiallmacinnes
> This is the sort of sad comment that continually amazes me.

Frankly, I'm stumped.

There's nothing sad about pointing out that you clearly:

1) Understand the privacy costs associated with Facebook

2) Choose, Yes, Choose to continue using it

What's sad is that you feel it's impossible to continue your social life
without it.

~~~
eropple
Sorry to disappoint you, but the rest of America has basically abandoned email
and Twitter isn't a serious medium for connections (at least, among non-
technical people I know; I have a number of friends who use Twitter on the
regular, but only a small few use it meaningfully). If you have friends--
especially non-technical ones--who aren't in your local area (or, a lot of the
time, aren't in your workplace) Facebook is very frequently the _only_ way to
keep in regular touch with most of them.

 _Network effects matter._ That's not _sad_ , that's simply reality. The lock-
in effect is real and puts you in a position where, yes, you have to use it
unless you wish to move out of contact with people. That doesn't mean you have
to like it and it doesn't mean you can't, as the person you sneered at did,
express a desire for its improvement.

------
zmmmmm
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.

~~~
GrinningFool
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.

------
salient
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
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](http://www.appbrain.com/stats/libraries/ad)

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

------
panzerboy
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...](http://www.xda-developers.com/android/xposed-module-brings-back-
app-ops-to-android-4-4-2-and-gives-your-control-of-your-application-
permissions/)

------
rtpg
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.

~~~
gorhill
> "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.

------
discardorama
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)).

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

If not, not.

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

------
kiallmacinnes
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.

------
awjr
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.

~~~
eropple
_> 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.

------
polskibus
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.

------
gorhill
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.

------
trurl42
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?

------
Zigurd
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.

------
kmfrk
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?

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

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

~~~
nhaehnle
I think the point is that if Alice hopes to hide her tweets from Eve by
blocking Eve, then Eve can always log out of Twitter to see those tweets
again.

Conclusion: Blocking users cannot ever be a privacy feature. You cannot
prevent a specific user from seeing your tweets without preventing every un-
logged-in person from seeing your tweets.

Edit: Though admittedly, that's a bit of a black-and-white perspective. I
suppose blocking a user from seeing your tweets could work in the same way
that hell-banning works: If Eve never logs out to check whether you blocked
her, she won't find out. It's a bit of security through obscurity: far from
ideal, but it might work for some practical problems.

~~~
silencio
After reading lots of discussion about this yesterday, I think the change
being negative hinged on one big thing. Nobody truly believed that the
old(current) block on Twitter was actually blocking anyone from reading your
posts if they were public, but not being able to follow someone had the (imo)
underrated benefit of not letting someone directly interact with your tweets.

That added layer of friction meant it was just a little more difficult for
group harassment (e.g. retweet someone you don't like, laugh at them, have a
group of your followers send harassing tweets even though they're not
individually blocked). The only way to do so would be to open Incognito mode
or log into another account and then manually RT or find another way to harass
someone (like a forum or chat). The suggested new functionality meant that
there was more security through obscurity (well not quite, apparently you
couldn't add people that blocked you to lists) but reduced that friction in
the harasser's favor.

Personally I'm hoping Twitter keeps the old block forever, but then adds
something like the attempted new block functionality under the less-of-a-
misnomer-name "mute" \- both have their strengths and weaknesses and I don't
think one can really replace the other.

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

------
uniray
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-...](http://www.androidpolice.com/2013/12/11/googler-app-ops-was-never-
meant-for-end-users-used-for-internal-testing-and-debugging-only/)

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
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).

------
signalnow
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
How would anyone know it was not official until Google said it wasn't meant to
be released?

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

~~~
drdaeman
What sort of "we never meant to release this" feature would get merged into
stable tree and even get into the production builds that get shipped on the
actual retail hardware?

I thought if feature's meant to be solely experimental it'd just sit in a
separate feature branch.

