Question on Banking App behaviour: E*Trade: Invest. Trade. Save.

kvaradhan3

I am following up frommy comment on https://github.com/PrivSec-dev/banking-apps-compat-report/issues/334 for the ETrade app, trying to figure out how to move forward.

Whereas the original report says that everything worked as expected, I find that, with
`version 12.0.3.7811

com.etrade.mobilepro.activity
versionCode 120003

targetSdk 34
minSdk 29

Installed: Dec 29, 2024; 7:34 AM
Updated: Dec 29, 2024; 7:34 AMandGOS: 2024121200`
the app requires you to actively login to GOogle Play Services.

This sorta breaks my assumption of how Sandboxed GOogle Play services should work.

Appreciate any input or advice,

THanks,

Kannan

de0u

kvaradhan3 I find that with version 12.0.3.7811 com.etrade.mobilepro.activity [...] the app requires you to actively login to GOogle Play Services.

This sorta breaks my assumption of how Sandboxed GOogle Play services should work.

If an app chooses to require a Play login, that is the app's choice. Running Play on GrapheneOS, inside the regular app sandbox without elevated system privileges, does not change whether Play believes a user is signed in. Is it possible to indicate what your expectation had been?

kvaradhan3

Hi de0u

To the extent possible, I want to minimize the chatter among the apps. I am assuming here that the apps don't get to peek into any other entity's data, or call back home with in privacy exposing ways. Google Play Services and Google Play Store, I think are oddly special (it is android afterall), and I am concerned/worried/trying to comprehend that if Google play services was authenticated and connected back to Google, what my exposure would be.

Secondly, in reading the banking report, it was not clear that the app required a /Google Play Services/ that was authenticated to Google. Maybe this need to be added to and called out in the reports going forward.

de0u

kvaradhan3 To the extent possible, I want to minimize the chatter among the apps. I am assuming here that the apps don't get to peek into any other entity's data, or call back home with in privacy exposing ways.

I am not clear on what is meant by "apps don't get to call back home with in privacy exposing ways". Also I am not clear on how that relates to Play. If a user enters data into an app, and the app has network access, the app may send the data somewhere unwanted. But that has nothing to do with sandboxing or Play.

kvaradhan3 Google Play Services and Google Play Store, I think are oddly special (it is android afterall) [...]

What "sandboxed Google Play" means is that on GrapheneOS Play Services and the Play Store are not "oddly special"; they are regular apps.

kvaradhan3 I am concerned/worried/trying to comprehend that if Google play services was authenticated and connected back to Google, what my exposure would be.

There may be legitimate cause for concern. If a user enters data into an app, and the app shares the data with Play, and especially if the app asks Play to send the data somewhere, then the data will be sent somewhere.

But, going back to the bank app, if the bank app demands that Play is installed and demands that a Google account is signed into, that is up to the app, and it's not clear what the GrapheneOS developers could do about that. If a user chooses to install and enter data into a privacy-invasive app, then the user's privacy will be invaded.

Meanwhile, if the bank app didn't use Play Services at all, it could still send any data entered into it wherever it wanted to (including to Google).

kvaradhan3

de0u

de0u I am not clear on what is meant by "apps don't get to call back home with in privacy exposing ways". Also I am not clear on how that relates to Play. If a user enters data into an app, and the app has network access, the app may send the data somewhere unwanted. But that has nothing to do with sandboxing or Play.

To illustrate this with an example, I meant that I am ok with Etrade talking back to Etrade for their backend services and data, but cannot peek into schwab or bank of america or other app data.

I guess I am conditioned to think of Play as somehow integral in android, and when an app requires it to even function, my paranoia hackles turn up a few notches.

I think you bring up two points:

That Play in GOS is just another app so it cannot peek into other app's data.
If an app wants to send something to Google, it can do that in many ways, Play being one of them.

I agree.

So, is it possible for GOS to expose (app logcat, maybe?) the Play APIs that an app is using, so that we may know how and for what purposes an app is using Play?

Thanks,

Kannan

de0u

kvaradhan3 To illustrate this with an example, I meant that I am ok with Etrade talking back to Etrade for their backend services and data, but cannot peek into schwab or bank of america or other app data.

Yes. The standard Android sandbox does this (on GrapheneOS, also on Google's Android, also Samsung's, etc.).

kvaradhan3 I guess I am conditioned to think of Play as somehow integral in android, and when an app requires it to even function, my paranoia hackles turn up a few notches.

On most platforms, Play is "integral" in the sense that it has special privileges that other apps do not. On GrapheneOS, Play is not "integral": GrapheneOS is usable without it, for users who don't need apps that depend on it.

kvaradhan3 So, is it possible for GOS to expose (app logcat, maybe?) the Play APIs that an app is using, so that we may know how and for what purposes an app is using Play?

It should be possible to track and log IPC calls. It might be difficult to sort through and format the data, though. I suspect many apps make a large number of API calls -- both lots of repeat invocations of a specific call, but also I suspect many apps make a lot of different calls.