Firebase Crashlytics - Android Proguard mapping file is uploaded without your consent

4,975 views
Skip to first unread message

Radek Kaczmarczyk

unread,
Jan 28, 2019, 2:51:48 PM1/28/19
to Firebase Google Group
Reason why I am raising this here is that proguard mapping file is something like a private key in key pair or a password to your personal bank account or a credit card number together with expiration date and cvv/cvc code. It is a part of security of your app. You do not share it with anyone just like that. If someone wants to access it then your explicit consent is required first. No API/SDK/(you name it) should be able to upload mapping file after default integration if you do not it enable this feature explicilty and intentionally. No room for assumptions that you might want it because so many people do it even if it is for your convenience.

Crashlytics uploads your proguard mapping file by default for both debug and release builds.

Following websites say that you can disable just it by adding "-printmapping mapping.txt" to your proguard file.

https://docs.fabric.io/android/crashlytics/dex-and-proguard.html
https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports

It doesn't work. I have always had that line in my proguard configuration file and now I can see deobfuscated exception stacktraces in Crashlytics web console.

Mapping file is always generated under default name and default location no matter proguard configuration file contains 'printmapping' line or not. Android Studio always overrides its with own line.

Other developers can confirm that issue:
https://stackoverflow.com/questions/35618434/proguard-printmapping-not-working-in-android-studio-2-0-0-and-2-1-0/36194642

The only working solution is to disable all "crashlytics*" tasks in gradle script by adding something like:

I have contacted Firebase support and asked for removal of all copies of my mapping file as it was uploaded without my consent.

Firebase support response :
"After discussing this with the team, it was confirmed that, unfortunately, it is not possible to delete the mapping file."

Marc Richards

unread,
Feb 1, 2019, 3:26:50 PM2/1/19
to Firebase Google Group
Hi Radek, I'm an engineer on the Crashlytics team. Thank you for your post, and for calling our attention to the fact that our documentation wasn't clear as it could be. 

Removal of the "-printmapping mapping.txt" line ensures Crashlytics can find the mapping file when Android Studio overrides the default location, as described in the StackOverflow post you linked to. The documentation is not intended to imply that it is a toggle to control the upload behavior of our Gradle plugin.

Of course, we strive for our documentation to be as clear as possible in describing how Crashlytics accesses your data. I'll make sure it gets updated soon, to clarify the purpose of removing the "-printmapping" line. We'll also update our Getting Started docs to explicitly describe when the Gradle plugin performs uploads. We'll consider adding a configuration option to explicitly disable mappings file uploads, though at present it is not a priority. Deobsfucation of stack traces is a key feature of Crashlytics; removing access to the mappings file negates most of the utility of the service for the vast majority of our customers.

Finally, regarding deletion of your previously-collected mappings files: We cannot delete mappings files for active Firebase projects. However, deleting your project will result in the files being purged from our systems. Should you choose to do this, you can of course continue to use Firebase by creating new project for your app.

Thanks again for your feedback!
-Marc

Radek Kaczmarczyk

unread,
Feb 1, 2019, 7:00:07 PM2/1/19
to Firebase Google Group
First something to help Android app developers. In order to disable automatic upload of the mapping file just add following to all build.gradle files:

tasks.whenTaskAdded {task ->
    if(task.name.toLowerCase().contains("crashlytics")) {
        task.enabled = false
    }
}

Security is top priority. Any feature at cost of security will sooner or later have negative impact.

Whenever you feature accesses developer sensitive data automatically you must emphasize it one million times in bold with large font!

I agree that automatic deobfuscation is a cool feature but only if developer explicitly agrees to it. In Google Play developer console you need to upload the mapping file if you want to have similar feature. They could do it automatically while building a release apk or at least suggest to do it every time you upload next version of the app. But they don't. Why? Because they respect people.

Aggregation of obfuscated exception stack traces is already a cool feature which helps a lot.

You are saying:

"The documentation is not intended to imply that it is a toggle to control the upload behavior of our Gradle plugin."

...but it gives such conclusions.

Let me quote...

"For Fabric to properly de-obfuscate your crash reports, you need to remove this line from your configuration file, or we won’t be able to automatically upload your mapping file:
-printmapping mapping.txt" - in other words "if you have this line we won't be able to automatically upload your mapping file"

"To let Crashlytics automatically upload the ProGuard or DexGuard mapping file, remove this line from the config file, if it's present:
-printmapping mapping.txt" - in other words "if following line is present you will not let Crashlytics automatically upload the mapping file"

According to quotes above I conclude that the mapping file will not be uploaded automatically if 'printmapping' line is present in configuration file.

This is misleading because according to stackoverflow page mentioned in my previous post 'printmapping' option does not work in Android Studio. You have it or not it works like it is not there. Suggesting that this can prevent automatic upload of the mapping file is making me think that I have an option... which I do not.

If you do not agree that keeping the mapping file safe and secure is not important then this is another reason for not using Crashlytics.

"We cannot delete mappings files for active Firebase projects. However, deleting your project will result in the files being purged from our systems."
This is also wrong and misleading. I believe that as a result of lack of knowledge. I have reached Fabrics support and on my request they have removed my Crashlytics project together with mapping files without touching other functions of Firebase.
Reply all
Reply to author
Forward
0 new messages