-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cloud Audit Logs #2
Comments
@christianrowlands did you find any hints? The non-root version has the same tracker included, by the way. |
Sorry, I missed this one somehow. I think you are right, last time it came in with the protobuf library. I will take a look and see if enabling minification fixes it. |
Ah, that one again – now that you mention it I remember. Especially in the context of minification. Thanks for taking care! I happily check a "test compile" for you if you want me to (can be a naked/unsigned one, I'd just run my scanner over it). How typically Google. Same number they played when forcing people to switch from GCM to FCM (one had to explicitly disable analytics). But then, Flutter folks are no better, requiring you to explicitly specify |
This was the first thing I've noticed while trying out Flutter. I'm guessing they've kept this switch to discourage any attempts to build a tracker-free alternative (other than the legal issues that might cost them a few bucks). |
They might sell it using different phrasing – but essentially what counts is the result: it's not "privacy-first". Though for me, that's not the only issue I have with Flutter apps. There's another one that's literally big: try a "Hello World" app in Flutter. If you'd manage keeping the resulting APK below 1 MB while still being cross-platform, I'd be very surprised. If you don't manage getting it below 5 MB, I'd be not surprised at all… But we're getting off-topic (or rather, I do 🙈) |
I was able to exclude the audit_log.proto file using This first one I enable minify. This one I used the exclude for the audit_log.proto |
And if either of those options work, I will update both Network Survey and Network Survey Rooted |
So use |
PS: What other differences are there? Scanner output looks quite much different. Maybe
Checking the output generated by PPS: Funny. Found Cloud Audit in the first APK as well, just not in Smali:
If you check what
Those are used by Network Survey, and should be detected in the first APK, right? |
It seems that everything in the Here is a version with minify enabled but obfuscation off: I am curious if it finds the google audit tracker in there since it has minify enabled but the code is not obfuscated. |
Ah, that makes sense somehow. I wasn't sure how to understand the phrasing in that documentation ("folders that are not part of the standard AOSP build procedure" or "folders that are not part of the standard AOSP build procedure") – if it's only "supporting files", the latter emphasis must be how to read it. So just to clarify: those "additional" 3 libraries are used by Network Survey or not? My guess is
Dependencies of dependencies of your dependencies and all that, yes. What basically means that even the developers themselves cannot tell what code they use – which is somehow worrying.
Output including the
So no Cloud Audit detected (even So if you agree, I'd say that would be the setup to use: Thanks a lot! Your analysis really helped me to 1) some deeper understanding of the structures Apktool creates, 2) ensuring/confirming I use the proper ones for my library scanner and 3) getting some insights to the tricks Proguard plays and how to optimize them for privacy and transparency! That's what I'll recommend developers from now on: use minify and disable obfuscation 😃 |
Yes, those three libraries are used by Network Survey. The messaging library contains the cellular, wifi, gnss, and bluetooth record definitions. The eclipse paho library is used for the MQTT connection, and the ormlite library is a transitive dependency needed for logging the wireless protocol records to the SQL lite database file. As for this comment:
You are 100% correct. And even worse that is how easy it is to do things without a user knowing. Once you give an app camera permissions, they can take photos at random times and ship that off over an Internet connection all without the user ever knowing. This includes both the rear facing and forward facing camera 😨 . And the amount of data that can be pulled even with just a basic app... yikes. Developing Android apps has made me remove all the unnecessary apps on my phone, it is just too easy for app developers to pull all sorts of information. Yep, I agree, minify on, obfuscation off. I don't plan on doing a release anytime soon, so it might be a couple weeks, but I will reach out when I do. I will leave this issue open until I post the release and you can check it. I agree, it was an interesting exercise to run through! |
Funny then they only get reported if I also scan
And actually even without requiring the
I remember several years ago there were a few apps showing what details could be pulled with or without certain permissions – simply accessing all details and displaying them on-screen. I made a test then, explicitly blocking all permissions to make sure it didn't fool me. Yikes, indeed… Unfortunately, those apps are no longer available. Might be a good idea for a new project in the privacy sector. To give you an idea, one of those apps was permission.READ_PHONE_STATE (link goes to Aptoide), a second one permission.READ_SMS (ApkTom; not sure how safe those downloads would be), both from the same author. He seems to have had several of those apps: I just ducked the latter and found mentionings of DispWifiInfo and others. Should you go for it, I happily take the app(s) into my repo!
One of my core advices: do not install apps you find interesting, but only those you cannot do without. More often than not you won't need them. I never understand folks having hundreds of "extra apps" (i.e. not pre-installed ones) on their devices.
Yes please 😃
Oh yeah! And I'm very thankful you did that with me! Couldn't have done it without you. |
So I did some more testing and it appears turning on minify broke some of the logging logic I am using. I tried to add |
Ouch. Good you caught that before letting it free. Yes, of course: it's ready when it's ready, not before. Thanks for your efforts! PS: would we build this at F-Droid, we'd simply remove it before the build starts. We've got special commands for that in our build recipes. Simplified: "do a checkout, remove unwanted stuff, build". Might also be a viable approach here, if all else fails… |
Did this tracker sneak in without intention?
I didn't find it referenced directly from your
build.gradle
, so I thought some dependency might have drawn it in and you missed it (IIRC Google's ProtoBuf recently started that, and you are using that – and again IIRC enabling minification, which you've explicitly disabled, would kick it out). An app with root powers having proprietary tracking inside is a bit scary 😉The text was updated successfully, but these errors were encountered: