UserPrivacyPolicy

We prefer to engage in a policy based on full disclosure

Those of you who may have read the issue post can guess that I'm not happy about having to do this. It's not that users should not be guaranteed privacy by using this application via play store. Rather I continue to be disgusted at the way Google chooses to operate their collection of private user data. This app collects no data, personally identifying information, nor does any private data go from this application to a central source with the consent of this developer. There is a plethora of device specific information available through the developer console which I have access to, but I did not put it there. Instead this is a built-in "feature" of the Android API which gets integrated into anything you run by the system. We have now been informed that a unique advertising ID associated with the Android phone and that the analytics devil is unusually sensitive about the possibility of developers employing this essential build item to the point that this notice, and a rebuild, and a painful upgrade of the recently obsolete Gradle config files are required to keep the app from being blacklisted on the Play Store. Make what you will of this.

Any reasonable person who is using this application is probably technically able, code savvy, and intelligent enough to understand an appeal that this nonsense is all Google. A hacker ethic and pride in the open source tinkering I work on as a hobby. I do not put malware nor spyware like the Google FireBase API into my code and it's a little insulting to suggest that I would do this to supportive users of a "hacker punk" app which I am happy to say as a math major that I developed from scratch. This is not to say that I do not have a short list of pentesters who probably use the app that I would like to hack, just that this is not the venue.

Permissions required by the app

Let's give an overview of what limited subset of Android permissions are required for the Chameleon Mini Live Debugger app to provide any functionality that is worth using. In other words, as any casual Android developer is introduced to on coding session one has gotten used to, the Android API plays fast and loose with its choices of groupings of permissions which apps must accept as a whole. The following permissions are about as negligible as you can ask for from any modern Droid...

1. Photos/Media/Files (read the contents of your USB storage) This is necessary for the app to perform XModem uploads. We require a source for the bits which are pushed to your Chameleon device, unless you are exclusively using the stock card images provided in four flavors by the Android RAW resources bundled with the app, this means data must be taken off the phone.

2. Photos/Media/Files (modify or delete the contents of your USB storage) Similarly, when a card image is downloaded via XModem from your Chameleon device, these important bits cannot be directly pushed into the Google cloud ether. We require that your phone is the intermediary which requires storage before Google assumes your files as a part of their archiving process to protect the sanctity of your virtual data. In so much as this permission is also required to run the app:

3. Storage (read the contents of your USB storage) Yes. XModem uploads sourced from the file system do require this functionality.

4. Storage (modify or delete the contents of your USB storage) This assertion is only partially true. Distinct applications have their own work space and permissions (the Droid is a Linux after all). The app could potentially overwrite files on your device. However, this concern is over a logic error which would be promptly addressed by the developer if it were to arise. Sorry Google.

5. Other (full network access) This is the only possibility which should be vaguely concerning. Unfortunatley, Google has chosen to structure their API such that the same "download manager" which is used to slap your XModem card binary off to disk gets bundled in with the same web browser download rights so to use one, one must necessarily open up access to the other. I guess that the use of the download manager could be replaced by something else with less animation value for the user, but it's going to take a persistent user with a really good set of concerns to make me get around to changing that code. So yes, Google, we have internet access put no programmatic means built-in to exploit it.

Recommendations

I would estimate that at least some non-negligible percentage of the populaqtions who keep an NFC sniffer / crasker interface at hand on their phones are concerned about privacy, let's estimate, for practical reasons. Now as long as I'm not the target here, I don't have a problem with people who have developed technical skills. In fact, based on this which has just royally pissed me off and set me over the teetering edge with Google, I will finally just advise any user: DO NOT INSTALL THIS APP WITH THE GOOGLE PLAY STORE! It's not difficult to custom build the app from source, and there's no tampering of the binary which Google modifies when it is uploaded. Those who are not comfortable enough fixing a Java line or two between builds can safely install the signed binary APKs provided on the releases page linked above. These have not been repackaged by a second source and can be considered as good as from my box to yours.

This is BS from the perspective of someone who maintains software where one can just go look at what it does! And I have to say the lines of Java don't really do all that much. The time that really required effort was spent on the GUI and it looks nice. Fu@k you Google, my most sincere regards on this matter back up yours.