[ Jolla C2 ] Android banking apps support with Sailfish 5?

Platform Development
#1

Hi devel sailors or savvy community contributors,

Following question :
Several ( in my case german ) Android banking apps ( Deutsche Bank / Commerzbank / norisbank / Postbank /Sparkasse ) refuse to install on Xperias 10II/10III or trusting the platform, throwing security concerns about rooted / untrusted devices.

The jolla C2 is being promoted as a SFOS reference device, implementing “SFOS as it should be".
This reads : SFOS on SoC straight from the manufacturer. No need to unlock any bootloader of an open-policy Android device.

Hence the question : :question: Will unlocked bootloaders / rooted device - issues remain uncatched on Jolla C2 devices ? Any improvements ?

:point_right: Will the upcoming Sailfish OS 5 / AppSupport combo be smarter or more configurable reporting unlocked bootloaders or rooted device states to AppSupport run apps ?

as it also concerns some banking app security designs :

:point_right: Could the native lockscreen deamon communicate its active state to AppSupport driven apps ? ( telling Andoid apps, that an active screenlock has been set for the device in use )

Thanks for any helpful notes or outlooks on this. :slightly_smiling_face::+1::+1:

4 Likes
Jolla C2 Community Phone deliveries
#2

There will be no substantial difference in this area between C2 and other supported devices. Like several times before, Jolla will improve the situation sooner or later - but you also cannot expect these shitty apps that actively look for a reason to not serve you to work flawlessly all the time.

7 Likes
#3

why should it be complaining about rooted device ? i mean i never played around with those app on jolla 1 or intex but cant remember any rooted device message at that time

#4

If you want to diverge further; please consider starting another thread.

5 Likes
Jolla C2 Community Phone deliveries
#5

Being more precise : :question: will the upcoming Sailfish OS 5 ( officially implemented for the Jolla C2 ) report any unlocked bootloader state to Android and native apps ? ( of which the latter probably won’t bother )

Does / can the native lockscreen deamon communicate its active state to the Android app support ? ( telling Andoid apps, that an active screenlock has been set for the device in use )

:point_right: This especially concerns the usability daily relevant push-TAN banking apps. Even SFOS-users want to do some banking - allocating funds to jolla-subscriptions, right ? :wink::ok_hand:

7 Likes
#6

Hi all, forked AppSupport & banking app discussion from the delivery thread here. Let’s continue discussion over here. Thanks.

10 Likes
#7

@rainemak this is important - since C2 phone is an official device it makes sense to ship it with locked bootloader and unrooted status so this information is then propagated to appsupport.

Lately more and more android apps make rooted/bootloader checks for “security reasons” and won’t work.

Some banking apps are already enforcing these checks, but from my experience McDonals loyalty app also refuses to work. We can only expect for this to get worse over time so now should be appropriate time to act and make sure C2 ships with these two checks passing (nonrooted, bootloader locked)

I already wrote about this issue about an year ago which ultimately led me to switch back to android until this is resolved in SFOS.

The other issue is lack of biometrics support in android app support…

I’m really hoping I will be able to switch to C2 and SFOS as daily driver again :slight_smile:

5 Likes
#8

How exactly would the non-rooted work if you run aosp in a container that has 0 knowledge if you clicked an option in settings to enable devel-su? Maybe signing bootloader is an option, but that still would not cause android apps to suddenly consider sfos flashed phone to be googol compliant (and trying to trick aosp into thinking that is probably even worse idea as googol has a lot more money to spend on lawyers)

3 Likes
#9

I’m just posting my observations and experience and letting know community of potential problems.

If this is unsolvable then it would be wise to put a big fat disclaimer of limitations - rooted /bootloader checks AFAIK are performed by android apps themselves regardless of presence of any google service so this is not something strictly related to google per-se.

I’m probably naive thinking that, since android support is run in a container, host OS (sfos) can fake this. This could then be exposed as an additional setting in android app support menu.

Ideally one could set this per-android-app but that might just be way too much work to implement.

1 Like
#10

That would count as actively trying to interfere with googol’s security mechanisms. The best we can count on is pure aosp and same level of support as lineage/graphene/e/etc… which all suffer the same issues if you have an overzealous security requirements. Closest you can get is opengapps on sfos and it still won’t trick safetynet/bootloader checks etc, just let the company behind the app know they are losing customers (just like los/e/graphene etc users do)

1 Like
#11

And they do. But it is an arms-race. And you can’t be winning all the time.
If you haven’t kept up with the news over the years; things have improved several times.

Why?! The only sensible setting is to have all the nonsense-avoiding spoofing enabled. I can’t imagine any app wanting to see this.

2 Likes
#12

This should probably be handled at a regulatory level instead of playing cat & mouse with Google’s security.

Our energy would be better spent by convincing the EU or individual member states to not get locked in by Apple and Google. Banks will always pick the cheapest option and will just go with Google Play Services for “security”.

Since more and more life happens on the phone people should have the option to not use iOS or Android. (My bank is even phasing out its hardware dongles.)

Jolla should invest energy and money in advocacy for this as well.

17 Likes
#13

Good luck with that. More energy has already been spent than an ordinary nuclear power plant on getting the EU or individual states to stop that.

4 Likes
#14

Agreed.

I still think we must not give up on pushing regulation, nor give up on the technology side of this.

6 Likes
#15

Totally agree. Definitely chipping in my like :+1:

Meanwhile I’m sure, jolla devels can & should handle this with A priorities - especially when running a paid subscription model. Users expect and pay for user / workflow ergonomics ( read : productiveness ) especially on a predestined reference device. :tipping_hand_man:

1 Like
#16

It’s pretty much like @throwaway69 put it. Further, what’s there in side the container matters. Whether boot loader is locked or not doesn’t matter as AppSupport has zero knowledge about that.

Some logcat logs could plausible help to identify your case @launchpad . Please do not share logs directly here at forum (or least check them beforehand). You could send me a private message if you’d like to gather logs.

4 Likes
#17

Thanks everyone for clarifications. Since we are on the topic of banking apps - what is the state of biometrics support for android app support?

#18

Same as always. Forget about it.

#19

Glad hearing it officially once again, that SFOS runs completely tight containers. :ok_hand: Thus developmental focus probably is on reliable provision of essential state parameters, which essential AppSupported Android apps might require.

Maybe a SFOS 5 related “Logcat-community-initiatve”, launched, promoted and instructed by the jolla devel team, could be very helpful polishing up the AppSupport as well as its manageability via SFOS settings. Many things come to mind, not at least the severe issue with the still unsolved, persisting “unreachable camera sensor issue” * when switching between AppSupported camera-using apps - from QR-scanners to messengers.:tipping_hand_man:

There also could be a uselful side-effect : the statistical data obtained about relevant, daily important Android apps within the respective markets of jolla. :slightly_smiling_face::ok_hand:

It must be said : Thanks for your indispensable work so far again, jolla crew ! :slightly_smiling_face::pray::pray::pray:

*) a somehow reserved / locked camera-sensor cannot be read out - resulting in black viewfinders and pictures. Switching between camera-modes and apps ( also between native and non-native ) won’t help.
Apps need to be completely re-installed just to lock up the availability of sensors once again :tipping_hand_man: …

7 Likes