#566 play integrity api and dynamic features

[ryjen]

integrity api

• move play integrity into flavor build
• some other bug fixes with exception handling
• ignoring apps with no integrity for now, useful for proof or logging

features

• separating the build source into 'app/src/play', the only build that will include integrity checks

• added structure to dynamically load features which can be reused by other features. Should be a different branch, maybe with more time.

• currently features are specified in the manifest with a 'meta-data' property with the key as the class, and a value of 'feature'.

• the buildsrc manifest takes advantage of manifest merging.

• when the dynamic features are found, their koin modules are loaded, and they run 'onLoad' (or 'onUnload') with the main activity.

[ryjen]

It is pretty simple to me:

rooted devices can bypass encryption.

---

however I can appretiate the lack of business priority

As I did not overspend time on it honestly, if you need this branch it's there

If you don't belive me have a look at the top frida script:

https://codeshare.frida.re/browse

[tladesignz]

rooted devices can bypass encryption.

Not phased about that at all.

There are 2 scenarios:

User rooted device

If a user roots their device, that's an intentional choice. It's their device, their data, their choice. I don't see, why we should interfere with that.

Attack rooted device

• The media itself is outside our control anyway.
• Why should an attacker attack the Save app?
• If they, for whatever reason want to do that anyway: The code is open source. It's easy to patch the app to remove the check.

So, in that situation, the only scenario we protect against, is where an attacker installs a gadget which tries to listen in on all network traffic. In that case, we wouldn't create that traffic, and we would be a warning sign to the user.

But if the attack is bad enough, that it would trigger Play protect, there's probably a dozen other apps, which start crying. And we're not really protecting the user, anyway. The device already is compromised.

In case the attacker gadget would try to subvert the users submissions, that's actually the only valid reason to stop operating.

But the server configuration is open to an attacker with root. So, if they would want to create a fake submission, they could do that without the app. (or patch it, again.)

Then there's the encryption aspect:

Transport encryption doesn't defend against on-device attackers, but against network attackers. Nothing gained here.

The gain is so minimal, it's just not worth it.

[ryjen]

The use case I am concerned about is when a user has chosen to root their device, but it is taken by persecutors (or similar evil maid attack).

My understanding would be that if people are sharing information that they may be at physical risk for, we don't want their activity in the app to aid in persecution.

Offering your users a remote kill switch could be a nice option if a device is compromised.

As well, an attacker on a rooted device with the Save app installed would likely be able to obtain information on how to compromise any of the backends, and remove media.

[tladesignz]

Good point. The intention seems good in that case, but the cure is over-boarding.

How could we make the user aware of the problem without limiting them and put them under Google control?

Is there a somewhat simple check for root we could do instead?

And then tell them on first start:

ATTENTION: You're running a rooted device. This might open you up for security and privacy breaches, esp. by persecution. Are you sure you want to continue?

Or a less intrusive warning (like a red bar or something in the main scene), which they don't just click out of the way?

[ryjen]

I am moving this to the private repository to cleanup.