I will do this next as you recommend. Thx.
Thinking about this further … if an (android) app can start itself without user intervention, and it can start another app (the native browser in this case - probably because it is set as the default browser somewhere), how does it know what app to start - a mime setting or something (i.e. html = web browser)? If so, perhaps it could start up the email app and send emails from my account, etc. Getting paranoid now …
You can also use APKPure through the browser. You don’t need an app for every thing ;-).
Only if Jolla bridged it. You can still limit the ability of Android Apps in their settings.
1 Like
Perhaps the answer can be found in the Android settings for apps? An active option, for example, “Allow notifications for updates blah …” could be the reason. These settings let Android apps run in the background.
You should generally avoid Apkpure. Why?
https://apkpure.com/privacy-policy.html
Apkpure’s aggressive methods and data collection contradict Sailfish’s security philosophy and privacy. I’ve been wondering why Jolla has offered Apkpure for years. F-Droid is the better alternative if you are looking for Android apps. Clean, OSS and ad-free.
A question that everyone should ask themselves: Why do I use the “secure” Sailfish when I install any advertising and tracker-contaminated Android app? Android’s poor group security model helps with this.
If that’s what you want, you can stick with Android.
My 2 cent
4 Likes
And even if you keep your settings clean and watch out that ’ … services to startup on boot’ is not set, you will see often android processes running that you definitely do not want to run and which you definitely did not start at all!
And just taking a look at apkpure download site you are greeted with an advertisement announcement that matches your experience!
BUT nevertheless: I would like to hear from @Jolla why those android processes can startup themselves?
(there were some comments earlier on TJC and maybe more…)
Sadly, I am forced to use some Android apps because there are no native Sailfish apps and almost certainly never will be … and that is presumably why Jolla included Android support in the first place. We are still in our 3rd Lockdown here in the UK - its been over three months now. I use Facebook messenger and Whatsapp to keep in touch with my mother, daughters and friends - none of whom use, or would have the slightest interest in using, Sailfish and Microsoft Teams for work. You could easily take the view that Aliendalvik is an integral and necessary part of SFOS provided by Jolla to make Sailfish usable for the majority of ‘normal’ users like me, so surely any security model should operate across both. At the very least Aliendalvik should be sandboxed with explicit permissions to allow Android apps to communicate outside the sandbox with the Sailfish world (e.g. notifications, copy/paste, access to camera, storage, starting apps, etc). With messaging apps you need notifications (otherwise how do you know you’ve got a message?) and I understand that such apps need to have a background process for this. However … for non-messaging apps I make sure that notifications are turned off and also the Aliendalvik setting ‘Allow background apps to start on bootup’ is disabled - yet APKPure still somehow started itself in the foreground and also loaded a browser window in the native browser. Unless I have somehow enabled this behaviour myself by incorrectly managing a setting somewhere (and if I have I am not aware of it), then this behaviour surely represents a big security flaw?
4 Likes
I suppose you bring this topic to the next community meeting. In my opinion jolla should communicate in cases like this more actively in the forum.
They could at least provide a high level explanation of their security model.
Maybe we can trigger this by raising awareness in the meeting.
As of your concerns regarding what can be triggered by apps in the system, this is done by using a special uri, which triggers the mime handler listening for this url pattern. There is a mime handler for opening the send mail dialog with prefilled data, but i doubt there is one which directly sends the mail. Although theoretically some app could be triggered, where actual harm could be done via mime handlers. I don’t know what the security concept is here, thats something that could be asked at the meeting as well.
Systems always have to find a balance between security and usability, thus I think user input is really valuable here for jolla.
3 Likes
I use F-Droid, Aurora Droid, and Aurora Store. I hate the new version of Aurora Store, however, its network settings feel very lacking…
I’m not able to attend the next community meeting on the 8th. However, if you follow the above link to the old Jolla Together its clear this has been an issue since Sailfish 2 in 2016. There are numerous posts about android apps starting up on their own even though they’ve not been given permission to do so - in other words ignoring the setting that is supposed to prevent this. If its been an ongoing issue for the last 5 years and Jolla has either not thought it important enough to fix it during this period, or can’t fix it for whatever reason, then then I doubt raising now in the community meeting will make any difference. Happy for other to try of course if they want to. Does rather undermine the ‘Security First’ selling strategy though.
1 Like
I have the same problem for a week and I’ve suspected APKPure as well. I also have this issue on my Lineage OS tablet with APKPure installed.
2 Likes
The Android version was changed with SFOS 4.x?
Maybe this is a general security problem in the droid API? I don’t think SFOS can control all methods. Not in the past and not in the future.
Here is an overview for Android 12. Older versions differ considerably. The API_Level used is decisive. User permissions was changed many times since Android 1. The older the API, the more vulnerable it is. A look at the CVE is recommended.
https://developer.android.com/guide/components/services
https://developer.android.com/guide/topics/permissions/overview
I think that’s more of a problem in Android (or AOSP). Someone who likes to profile users likes to use holes. Apkpure isn’t one of the good guys. It is worth taking a look at the apkpure.apk manifest file. If no service is registered there, they could use another hack. Android doesn’t have a bad reputation for nothing.
It must have happened with one of the last APKPure updates.
I think you are right - I had APKPure installed for months before this started to happen, and it did update itself immediately before this behaviour started.
Android 8 (Oreo) to Android 9 (Pie)
Well, if in more recent versions (or at least since the version of Android used in SFOS 2 in 2016) if Sailfish cannot control whether Android apps can start their background processes after Aliendalvik is started or the phone re-booted then the option to disable this in Sailfish settings should be removed rather than leaving it there and leading people to think they are more secure than they actually are in this aspect.
1 Like
I don’t know if Jolla can be blamed directly. Android is already responsible for its own possibilities or bugs. You can only protect yourself if you are not using Android. Personally, it is unclear to me how Android patches are handled by Jolla. Are all patches being applied? Only a few CVE numbers are listed in the SFOS change logs compared to the Android logs. That is lower compared to the dozen of CVE reported by the Google monthly patches.
Whatever, using the Dalvik is at your own risk.
While Android may have its own vulnerabilities, it very much should be in Jolla’s hands if a random Android application can start up in the background and, without seeking explicit permission, open up the Sailfish browser to specific pages. In fact I would expect even Sailfish applications to have to seek permission first and to only open pages if the user has the phone open.
1 Like
Yes sure. What I am saying is, it is not easy to really check all the constellations in which bugs occur.
You misunderstand me. I am not blaming Jolla at all. What I am saying is that if Sailfish cannot control whether an android app is allowed to start up in the background - either after a reboot, or after starting Aliendalvik because this is the way that Android works and this cannot be changed then Jolla should remove the ‘Allow background apps to start on bootup’ option from sailfish settings/android as (a) it doesn’t and can never work (so what’s the point of continuing to have this option?), and (b) it gives a false impression of more control over the security aspects of how android apps can or cannot run under Aliendalvik where such control, in reality, does not exist. If this is not the case then it is a security flaw/bug in Sailfish and Jolla should fix it.
We think the same way, don’t we? I’m just trying to understand technically why there may be a problem with the Dalvik. For a long time, I have been asking why an operating system that stands for security and privacy uses an Android as a subsystem. Yes, you could remove the “Allow background apps …” option, but what would be better then? There are also apps that can be prevented from running in the background, but not all of them. Otherwise it would be a lot worse. The right consequence would be not to use the Dalvik at all or to choose apps more carefully. The same rules apply as for an original Android phone. Tricky programmers will always find a way.
There are also alternatives to the Play Store (via Aurora) or Apkpure. In addition, I would recommend “ClassyShark3xodus” (F-Droid) to check an app for trackers or undesirable dependencies. This can minimize a risk.
Just because Android runs as a subsystem under SFOS, it is not automatically secure. This is my conclusion.
4 Likes