December 16, 2013 By: Will Verduzco
Back in Android 4.3, a new tool was discovered that for the first time gave users first party granular permissions control for their installed apps. This was, of course, App Ops. As time went on, many users quickly took a liking to the hidden feature, not realizing that the feature was only accessible in the OS for internal debugging purposes. Rather, many took it to mean that Google was looking to bring granular permissions control to the masses. But then, Android 4.4.2 came. Along with the update’s various security upgrades, 4.4.2 also made it more difficult to access the (already hidden) utility.
A few days ago, the EFF publicly chastised Google for “removing” App Ops from Android 4.4.2. Now before getting into the meat of this post, I would take a second to say that here at XDA, we are big fans of the EFF. They do great work protecting the public’s online rights and fighting for what’s right. While we don’t disagree that having granular permissions control is fundamentally a good thing, and in fact we have shared various (superior) means of obtaining such control, it’s a bit unfair to say that this internal debugging feature was “removed” from the OS. After all, it was never officially available in the first place.
Looking back at Android 4.3 when the feature was still accessible, one would have to create a custom shortcut to a specific activity within the Settings app (Settings > App Ops) using a third party app in order to launch the App Ops interface. Alternatively, a user could also install an APK that performed the same task of summoning the aforementioned activity.
Then came Android 4.4.2, which disabled the previously discovered method of accessing the activity. But this change was entirely intentional, as Google always meant to keep the program for internal debugging. As stated by Google Framework Engineer Dianne Hackborn:
That UI is (and it should be quite clear) not an end-user UI. It was there for development purposes. It wasn’t intended to be available. The architecture is used for a growing number of things, but it is not intended to be exposed as a big low-level UI of a big bunch of undifferentiated knobs you can twiddle. For example, it is used now for the per-app notification control, for keeping track of when location was accessed in the new location UI, for some aspects of the new current SMS app control, etc.
The current UI is definitely not something that is appropriate for end users; it is mostly for platform engineers (a tool for examining, debugging, and testing the state of that part of the system), maybe some day for third party developers. In what form these features might be available in the regular UI I couldn’t really speculate about.
In other words, App Ops was never intended to be an end user feature, and as such it was never meant to be seen outside of internal testing. Rather, App Ops was intended for internal debugging of various features that have made or will make their way into other parts of the OS, such as what we saw with the per-app notification control and coarse vs fine location access.
The mere fact that users discovered how to access an internal debug tool, one which has the very real potential to break compatibility in a great deal of applications, does not mean that it was ever “released”—no matter how much any of us want such a feature. After all, most end users don’t even understand the Android permissions model, let alone what could happen when disabling unnecessary permissions.
Now, before you get your pitchforks ready, I want to make it clear that granular permissions control is something that can be quite useful if wielded properly. After all, we’ve publicly commented on the unfortunate state of excessive application permissions in the past. We’ve also covered a few tools such as PDroid and XPrivacy that give users granular control over their permissions. And in the case of XPrivacy, this can be done using fake data that does not break application compatibility. But for those insistent on reacquiring that App Ops functionality that we were never intended to have in the first place, there are various third party workarounds through Xposed framework, Smali editing, or a root-only app.
Ultimately, something has to be done about the Android permissions situation. But criticizing Google for removing a feature capable of breaking application compatibility, one which was never intended to be user-facing, is not the answer. Rather, we should encourage users to use open source privacy management tools such as PDroid and XPrivacy, as well as keep a mindful eye on the applications we choose to install.
ACTA, Anti-Counterfeiting Trade Agreement, is another bill which tramples all over your civil liberties. The Internet is having a hard time fighting off bills that threaten creativity, like PIPA and SOPA, but now something far worse has come to play.
In October 2007, the United States, the European Community, Switzerland, and Japan decided to branch together and negotiate a bill to tackle intellectual property and copyright infringement. Yesterday, all 21 states of the EU, including the UK, signed onto ACTA. As of October 1st 2011, 8 out of 11 countries had signed on, including the United States, Australia, Canada, Japan, Morocco, New Zealand, Singapore, and South Korea.
“Although the proposed treaty’s title might suggest that the agreement deals only with counterfeit physical goods (such as medicines) what little information has been made available publicly by negotiating governments about the content of the treaty makes it clear that it will have a far broader scope and in particular will deal with new tools targeting “Internet distribution and information technology” -EFF
No one really knows what’s in the ACTA agreement, so it’s unnerving why so many countries have signed. They know something we don’t, keeping us out of the equation. Witnessing the recent revolt against SOPA and PIPA, they’ve done this for a reason. Methods to prepare this bill have even led Kader Arif, the European Parliament’s rapporteur for ACTA, to resign on Friday, saying he had witnessed “never-before-seen manoeuvres” by officials preparing the treaty.
“I condemn the whole process which led to the signature of this agreement: no consultation of the civil society, lack of transparency since the beginning of negotiations, repeated delays of the signature of the text without any explanation given, reject of Parliament’s recommendations as given in several resolutions of our assembly.” -Kader Arif
The EFF have also commented on the lack of transparency from officials:
“While little information has been made available by the governments negotiating ACTA a document recently leaked to the public entitled “Discussion Paper on a Possible Anti-counterfeiting Trade Agreement” from an unknown source gives an indication of what content industry rightsholder groups appear to be asking for – including new legal regimes to “encourage ISPs to cooperate with right holders in the removal of infringing material” criminal measures and increased border search powers. The Discussion Paper leaves open how Internet Service Providers should be encouraged to identify and remove allegedly infringing material from the Internet.” -EFF
This is a scary concept, far greater in significance than SOPA. If in the US, please contact your senators to demand more information on ACTA and sign this petition to oppose ACTA and keep the Internet free!
January 26, 2012 By: liwen
In 2010, the US Copyright Office added an exemption to the DMCA, which fully legalized rooting, jailbreaking, unlocking and whatever else you do with your smartphone that is not intended by their manufacturers. While that was certainly good for modders and hackers, of which there are plenty in our forums, exemptions only last for three years and therefore must be renewed before they expire. The Electronic Frontier Foundation (EFF) is now petitioning to do exactly that.
Before you get too upset over this, it’s worth pointing out that rooting and jailbreaking will not immediately become illegal should the exemption really expire. Instead, such activities would fall in a gray area, as The Verge notes, since device manufacturers could argue that they circumvent copyright protection measures – something ASUS, for instance, cited as their reason for locking the Transformer Prime bootloader.
Still, xda-developers believes that if you bought a device, it’s yours to do whatever you want to do with it. No matter whether it’s a smartphone, tablet, or heck, even a game console. Fundamentally, it simply doesn’t make sense: Imagine if you bought a table, but find that it is too high. So, you decide to cut off the legs a bit – imagine if that was not allowed. That’s exactly what we’re doing here: We find that the software that ships on our devices is arbitrarily limited, and thus modify it to add features, remove features, and whatnot.
If you believe in this fundamental freedom too, visit the EFF to read up about what to do to prevent the exmption from expiring; you can sign the petition or, before February 10, submit a comment to the US Copyright Office.
The Electronic Frontier Foundation is hard at work on the Carrier IQ issue. EFF volunteer Jered Wierzbicki reverse-engineered the Carrier IQ Profile file format from WBXML to human-readable XML. (A Profile is a set of instructions telling IQ Agent on your phone what information to collect, and when to send it back to Carrier IQ.)
He then created IQIQ–a clever title, providing a watching-the-Watchmen sort of commentary–to allow anyone to decode the Carrier IQ Profile active on their phone. The EFF hopes to create a Carrier IQ Profile database to force transparency when it comes to information collected from mobile devices.
In order to get the Profile from your phone, you need root, and you have to find it first. So open a terminal and type
adb busybox find / -iname “*.pro”
When you find a file named something like IQProfile.pro, CIQProfile.pro, or defaultprofile.pro, type
adb pull /full/path/to/profile.pro .
T-Mobile customers may have to use a second method to get their Profile, typing this in the terminal:
adb pull /data/data/com.carrieriq.tmobile/app_iq_archive/archive.img
Note the warning EFF gave us:
Please be warned that sensitive data could be in this archive.img file such as URLs, IMEI, SMS metadata, etc. EFF will always do its best to keep archive.img files confidential, but please DO NOT send them if there may be any private information on the handset you are working with.
Then, follow the instructions from EFF to submit it for the Profile database.
Please send us 1) a copy of the Profile, 2) which phone and network it was from, and 3) where on the phone’s file system you found it. You can send us this information in an email at firstname.lastname@example.org or in a git remote we can pull from.