Session now requires Phone ID!

Hi everyone, last month after adding Session’s repository (messaging app) to the F-droid app I noticed that the new version (1.13.1) has a new permission requirement: Read phone status and identity, that includes the phone number.

I have tried to check if there is any announcement on their website or if they said something about the need to add such permission but personally it removes one of the main reasons why I wanted to use this app.

Maybe the Techlore team, or some of you reading could try to reach Session’s team and ask them about it. I am really disappointed with this change since I wanted to use this app.

The newest version of Session Android is tagged as v1.13.5. It’s not a new thing to require this permission. It’s also in the Signal app v5.40.4.

I’m not really sure why this is the case, the version in F-Droid’s main repo doesn’t seem to require this permission :thinking:

Of course Signal does, but not requiring a phone number is pretty much Session’s only selling point :grimacing:

3 Likes

You will have to ask the Session devs in the Oxen Community on their Telegram or Twitter as I don’t think you will get a decent answer as to when this came about or why. But yes, I asked in Secure Messaging Apps matrix for the time being, maybe they can answer.

The permissions required by Session F-Droid don’t involve the phone ID, but they are included in the official one on Google Play that is bundled with Firebase push.

interesting history in the Oxen chat:

“It uses android.permission.READ_PHONE.STATE so with that permission it can determine phone number and serial”

findings

So, I looked at both the permissions required by F-Droid and Google Play versions.
Google Play: version: 1.13.1
requires: Read phone status and identity

Session F-Droid on Play Store: version: 1.13.4 (unofficial build)
blocked by Play Protect, install anyway
requires: missing Read phone status and identity

GitHub: version: 1.13.5 (stable)
requires: Read phone status and identity

2 Likes

Thank you for your research. I am indeed confused with your findings.
Since the newest version you found on github (1.13.5) also requires to read the phone identity.

I hope it is only a temporary permission used for debugging and will not be present in the final builds.

Also as I mentioned in the post I downloaded the app via their official repository https://fdroid.getsession.org/

Here is a screenshot I took right now:

1 Like

I think that’s related to the voice and video call feature: Add one on one calls over clearnet (#864) · oxen-io/session-android@e1b6bb7 · GitHub

Correct. Upon further investigation and clarification by the Molly developer, the READ_PHONE_STATE permission you can see “… current cellular network information, the status of any ongoing calls, and a list of any PhoneAccounts registered on the device …” - in layman’s terms this means simply that the phone state is information regarding the network and status of any calls in the call lists the app has permission to read, and is necessary to make calls and video calls for Session. It’s listed as a permission carrying larger dangers but it’s not as bad as it sounds.

Here is the list of Android Permissions required for Session to do what it does:

    <uses-permission android:name="android.permission.BLUETOOTH" />
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
    <uses-permission android:name="android.permission.USE_FINGERPRINT" />
    <uses-permission android:name="network.loki.messenger.ACCESS_SESSION_SECRETS" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.CAMERA" />
    <uses-permission android:name="android.permission.RECORD_AUDIO" />
    <uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
    <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
    <uses-permission android:name="android.permission.VIBRATE" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="com.google.android.c2dm.permission.RECEIVE" />
    <uses-permission android:name="android.permission.WAKE_LOCK" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.READ_SYNC_SETTINGS" />
    <uses-permission android:name="android.permission.WRITE_SYNC_SETTINGS" />
    <uses-permission android:name="android.permission.INSTALL_SHORTCUT" />
    <uses-permission android:name="com.android.launcher.permission.INSTALL_SHORTCUT" />
    <uses-permission android:name="android.permission.BROADCAST_STICKY" />
    <uses-permission android:name="android.permission.DISABLE_KEYGUARD" />
    <uses-permission android:name="android.permission.RAISED_THREAD_PRIORITY" />
    <uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />
    <uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" tools:node="remove"/>
    <uses-permission android:name="android.permission.READ_PHONE_STATE"/>
    <uses-permission android:name="android.permission.USE_FULL_SCREEN_INTENT"/>
3 Likes

Hey everyone, Alex from Session here.

The speculation in the thread is absolutely correct — this permission stems from the calls feature. This particular permissions is there to understand if the user is currently having a phone call (non-Session). The reasoning for that is because, well, trying to start a VoIP call while you’re already in a voice call is a terrible user experience and definitely unexpected behaviour for most users.

I spoke to the devs about it this morning, and although we obviously wouldn’t abuse the permission we don’t want people to have to take us on our word, so they’re looking into whether it’s possible to remove it completely and just tolerate some unexpected behaviour for the (probably small number of) users who try to start a Session call while they’re already in a phone call.

3 Likes

Thanks, Alex! A wonderful answer. We appreciate your time.

PR removing it here Remove declared phone state permission by hjubb · Pull Request #919 · oxen-io/session-android · GitHub, we’re still testing it, but i think we are already handling the ongoing call case without needing this permission, just something we forgot to remove from Signal code when we did our voice call implementation.

4 Likes