Google Removes Vital Privacy Feature From Android, Claims Release Was Accidental
eff.org
eff.org
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...
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.
I do not think dereferenced means what you think it means.
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.
...'dereference' means 'access the pointed-to data'
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.
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
And while I'm complaining, phones (devices for communication, remember?) need proper keyboards.
OK. I'll crawl back into my cave now.
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.
This is incredibly disingenuous because of the high barrier to entry on cellphone manufacturing.
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.
I often hear people lament the design of their phone, caused by the preferences of the majority.
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.
There were Android phones with keyboards. I had the chance to play with a prototype in 2009 (yes, this was after the iPhone)
Not good. Not good at all.
That form factor is fine, although not popular with consumers. I had a Droid 2 for a while, and found myself using the soft-keyboard more and more, particularly while not using connectbot.
But the keys are too small for the fingers (IMHO). And it's a fragile item in the hardware.
1) Depends on the keyboard - the research I've posted showed that against a netbook keyboard, an iPad in landscape mode had greater accuracy.
2) Agree on the autocorrect features and it's something I've noticed this with touchscreen typing.
It's taken me a while to get used to the auto-correct features. It used to be that they were basically a prompt that something was wrong that I'd retype mannually, now my instincts work with them.
They also act as autocomplete when you're used to them - either fully or with edits (it'll often prompt with the right root word but with a different ending - say regretfully instead of regretful - in some cases it's quicker to accept it's suggestion and then delete than to continue typing, once you're used to it).
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.
After all I can get a physical keyboard on the $5 electronic address book. Even understanding that that's a very cheap keyboard (though that also includes margins for retailer, manufacturer and all the other costs), you're telling me that that the cost of a physical keyboard is going to be a deal breaker on a $300+ smartphone?
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.
Samsung has been immensely profitable with their strategy of 'following the fruity status quo' and have a huge design department and produce dozens of phones and if they thought there was a huge market for a flagship keyboard phone they'd presumably be all over it.
If people want a physical keyboard for their phone there are plenty of case options, e.g.: http://typokeyboards.com/
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 :)
Previously you had a bit of boilerplate code that did much the same. Either way it doesn't actually solve the issue, because you still need the dts file, there's no hardware discovery.
(ok that's a bit of a stretch, some of the busses and things like I2C are discoverable, but you need a map of GPIOs, UARTs etc etc)
The Linaro kernels ("Linaro Stable Kernel" is the keyphrase) boot from devicetrees (aka FDTs). Not sure how much of that is upstreamed, but devicetrees are pretty standard in the ARM world as far as I can tell. (Also, in general if you're doing Linux stuff on ARM, Linaro is the place to look for everything).
Edit: actually, that link isn't very relevant - I just lazily googled "linaro devicetree". But you should be able to find more info!
I'll investigate Linaro at some point, if that's more of a hotbed of ARM development.
https://lwn.net/Articles/560523/ https://lwn.net/Articles/561462/
But you do still need the dts, so while it makes device support easier, it doesn't solve the problem of discoverable hardware and you still need board specs etc, either from the original manufacturer or reverse engineered.
Either way, I was talking about what we have now, and even if we have device tree now it doesn't solve this problem without other pieces to the puzzle. And that's without even getting on to the mess of closed source graphics drivers that exist in the arm world.
Please don't think I'm trying to say we can't have a situation like the OP wants, I'm just trying to explain why we don't.
All the more reason for me to get up to speed with Linaro then, thanks for the heads up :)
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.
Only in the US.
Just read the problems Replicant, the true FOSS android, has had getting all components to work correctly.
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?
One can go back in the lit to Bell Labs research in the 60s for all the pricing strategies. Jean Tirole fleshed most of it out with help by Jean Rochet.
Source: Economist, network industries are my object of research
First rule of phone company: why market when you can monopoly?
uh, those are still around you know. You can even carry them in a backpack.
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?
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.
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.
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.
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.
Like 38° 53' 50.55", -77° 2' 14.51"
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.
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
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.
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.
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).
Stupidity is negligence. Negligence is selfish. That makes it malicious. Its willful which ever way one chose to spin it.
IMHO, such phrases are not much different to ones like "what do you have to hide?". They are designed to look like one thing, confuse and win a point, while hiding the fact that something appalling is going on. Its the language of confusion to control.
Its too easy to be allowed to hide behind a false concept of stupidity. Too convenient.
False, in general. If you want to assert someone is using stupidity as a cover, you need evidence. I don't believe that should be the default hypothesis.
Check it out: "Don't call me stupid; I'll punch you for that!"
I'm not taking sides here, but you have to call a spade a spade.
Even by that definition Google never released it. You needed a 3rd party app to access the feature, Google's software alone was not enough. Google didn't fail here, they flat out never released it.
Or perhaps you could argue that they failed by not releasing it (or something similar), but that's different story.
If it's there and it works, then great for you, but you can't expect a whole lot more. It sucks that they didn't actually make it a published feature with an actual means of accessing it, and take on the responsibility of maintaining it, because it seems like something I'd like to use.
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
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.
So what? The user can just re-enable the app's access to whatever it was trying to fetch.
I don't buy the "millions of apps simply stop working" line. If the apps stops working because it was blocked trying to access my address book, then the app developer should have done better to expect the unexpected when fetching anything from outside the application that isn't essential to its core function and purpose.
Even the simplest of javascript functions will handle a null value or failed fetch. There's even an "onerror" handler for HTML img tags! And you're telling me that millions of apps will fail because they don't receive what they're trying to fetch? Sounds like an exaggeration, or bad programming, or a bad OS.
The implementation on the part of the developer may be tiny, but you still have to have give those companies time to make and test the changes. Look what happens when companies move the Send button or whatever on their UI-- I tidal wave of internet bile comes rolling in. An app developer might appreciate a heads up before deluging their inbox/tracker with complaints and 1 star reviews.
It sounds like you are more familiar with web frontend programming. I'd caution you that Android app development has differences that are important to this discussion.
While I'm no expert in native app dev, it's interesting to see so many people are so confident the apps will break under those circumstances, without actually any first hand experience.
I would likewise caution anyone putting forward this idea, that unless you've seen the effect revoking permissions has had on your app, or another app, then anything you put forward in this discussion is hearsay.
I'm not jumping on the meme train about millions of apps crashing due to permission revoking. Google should just include the feature, and have it default to off, with appropriate warnings about tripping some apps when switched on. It doesn't need to be a complicated thing.
[citation needed]
Oh, it would definitely break some apps. Considering it would introduce new uncertainty. It's still an amazing feature.
Thanks Google, for making my phone less secure.
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.
Then, later, when you actually do want to use it, your app update won't say that you need any new permissions.
Nova Launcher has had the "Set Wallpaper" permission from the start, most launchers have it and use it, but Nova didn't actually needed it initially as the set wallpaper functionality was just calling other apps that held the permission themselves. But I knew Nova would at some point require it (and indeed it does now) and users completely expect the launcher to be able to set the wallpaper, but users still get confused or annoyed by the new permission screen.
"Google Play License Check" is another permission I've requested but not used. It's a reasonable permission for a paid app to have and not one that users email me asking about, but when I first added it to WidgetLocker I did get users asking about new permissions (The "Android Market" at that time didn't specifically point out which permissions were new, so people would just ask about any permission they didn't realize the app had all along). In a future update I ended up disabling license checking because it was proving to be more trouble than it was worth, but I didn't remove the permission because if I ever wanted to turn it back on I didn't want users to be prompted about the permission again.
Requesting something like Read Contacts without actually using it would probably upset users, as some will ask about those kinds of permissions and expect a reasonable answer. Saying it's just for future use would seem a bit suspicious.
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.
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.
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
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:
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.
>> 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.
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?
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.
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.
I think they want to know you are where you say you are. You'll find if you travel out of the area -- particularly out of the entire country -- you won't have access to entertainment you had while at home due to these regional restrictions. Just think of the times when you've gone to the BBC website to view a video only to be told you can't have it outside of the UK (the BBC license area). (Note that I'm assuming you're in the US although your use of "postal code" likely means you aren't.)
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.
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?
Perhaps you could ask one of around 6 billion people in the world how they survive without this essential utility.
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.
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.
(The self-centered prick's response of "then they're not real friends"--which I am addressing because it frequently comes next--willfully ignores that said self-centered prick is making it harder on everyone else to include them. They get excluded because they're being annoying. You have to give to get, and part of your giving is not making everyone else's life difficult because you're frothy about a web company.)
In the U.S. at least, if you have a basic appreciation of people you have formed friendships with over the years, if you value interacting with them over that self-centered Facebook froth, it's not feasible to ditch it. But you can still express a desire for it to improve.
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!
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.
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.
It is all 100% anti-users and pro-monetization; which is probably google's intention all along.
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.
Apps, on the other hand, would have an extra error case to deal with, but 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.
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)).
If not, not.
Seriously EFF, get your act together please. I do want to support you, but not like this.
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.
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.
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?
It isn't a burden to handle security exceptions.
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.
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.
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.
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).
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.
I thought if feature's meant to be solely experimental it'd just sit in a separate feature branch.