Hi Mark!

hello, Tad!

how can I help you today?

I am working my way through the long list of getting ready for production, and am reviewing options for securing my app.

So we are talking obfuscation and encryption.

For an "open beta" on Google, I was hoping to get by with ProGuard but I need something that can encrypt strings.xml and other resources.

Know of anything that isn't outrageously expensive?

the only tool that I know of that does what you describe is DexGuard

I've looked at DashO, DexGuard and AppDome, which are all increasingly expensive

Which is fine for production, but I'm trying just to target a few hundred users initially and don't need to spend 1000's until the testers tell me it's a go.

I was hoping you might know of some library or some such that could handle the resource encryption piece...

why do you feel that you need to encrypt resources? anyone who wants them can still get them -- those tools add speed bumps but don't really stop anyone

Really? I would think good 128bit or 256 bit encryption would make quite a bump.

for example, suppose that you are concerned about API keys -- an attacker would just get them by examining the Web service calls

Well - I would assume those would be encrypted also, and unencrypted on the fly... at least, that's what those 3 products claim to do.

And the website calls are https, so presumably they can't listen in over the wire either.

they are encrypted "at rest", in the APK file

and HTTPS traffic can be trivially intercepted if you have access to the phone

Actually, all three talk about support for both static and dynamic protection.

I do it with Charles Proxy all the time as part of app development

Hmmm..ok so you think encryption is basically a waste of time?

I would not worry about resource encryption, personally

so strings.xml or the same thing with all my static string constants in "Globals.java"?

I do have the web end of things somewhat protected in that every call looks for a token prior to doing what it does, and the token is generated on the fly by the app, not stored anywhere, and only good for a certain amount of time.

that helps a bit for your own Web service

But I was just nervous at having the web API completely open.

All my app keys and so forth I use for validation to Facebook, Google, etc are on the webserver, not in the app, but I still was nervous about some of the other strings.

Facebook for example, requires an ID be in strings.xml in order to use their login widget.

isn't that Facebook'

sorry -- isn't that Facebook's problem if somebody sees that ID?

Well, ultimately it is my app's problem even if it is a Facebook generated issue.

how so? what are you expecting to happen? note that I have never integrated Facebook authentication

Well, nobody could use that ID to hack into someone's FB account, but they could use it to wreak havoc on my app's relationship with Facebook.

presumably.

I don't pretend to know all the ways someone could screw with my app's account on FB with just the ID, but I know for sure they can't if they don't know which ID to hit.

in the end, if you want to apply resource encryption, and you are not worried about problems coming from the resource encryption itself, go ahead and apply it

I'm simply saying that, in all likelihood, they will get that ID in 5 minutes anyway

yeah - well back to my original question :)

Curious if you knew of any open source libs just for that aspect, sounds like the answer is "no".

frankly, I have never looked, but I have not heard of any, either

I couldn't find any through various searches. Bunch of options for doing dynamic encryption/decryption of strings in an app, but nothing to hit the APK or AAB file.

I did find some interesting studies that crawled various distribution points (i.e. Google Play Store) and identified how many apps are obfuscated and/or encrypted vs. those that aren't

Here was one interesting one from a couple years ago: https://cpb-us-e2.wpmucdn.com/faculty.sites.uci...

Focuses more on obfuscation than encryption though...

obfuscation is the focus of a never-ending war with de-obfuscators

Hey another question for you - any opinion one way or the other which has more long term momentum for cross platform (Android/iOS) work: Flutter vs. Kotlin multi-platform?

how long is your "long term"? 2 years? 5? 10?

5

5-10

10 is too long. Who the hell knows for 10

call it 2-5

in a 5-year horizon, my biggest concern would be Google electing to de-fund the effort -- while the community is big enough to attempt to pick up the slack, it will be a huge momentum dain

er, drain

And they focus more on the Kotlin side?

there, it's more a JetBrains thing

and Kotlin is a pretty big piece of their puzzle

however, you have to create the iOS UI outside of Kotlin, at least presently

KMP is about handling 80% of your logic in common between platforms, and doing something native for the remaining 20%

with Flutter, it's end-to-end within their environment

the benefit is that you don't have to do a hunk of Swift for an iOS UI

Right, I would wonder if there are any articles/studies done that give a sense if whether you have actually saved any $ doing that.

vs. native on both platforms

possibly, but it's kinda early on the KMP side -- that sort of analysis might be more practical this year than last year

my hope, for the sake of the Flutter folks, is that Google would scale back their involvement gracefully

I guess Google and Oracle are still in the fight over the Java thing, right? I've been wondering for a while if that wasn't a big reason for the Kotlin push by them.

I would not be surprised if that's part of it

OK - well I'm going to sign off, stay healthy and thanks as always for your input!

happy to help!