9 ms·

Even with a burner sim, there is the International Mobile Equipment Identity (IMEI) number, which is tied to the phone, and is known to all apps with the androi

by asnelt 15d ago

Even with a burner sim, there is the International Mobile Equipment Identity (IMEI) number, which is tied to the phone, and is known to all apps with the android.permission.READ_PRIVILEGED_PHONE_STATE permission.

exceptione 15d ago
That can't be true? <https://grapheneos.org/faq#hardware-identifiers https://grapheneos.org/faq#hardware-identifiers> As of Android 10, apps cannot obtain permission to access non-resettable hardware identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial numbers and subscriber IDs. Only privileged apps included in the base system with READ_PRIVILEGED_PHONE_STATE whitelisted can access these hardware identifiers. Apps targeting Android 10 will receive a SecurityException and older apps will receive an empty value for compatibility. The currently enabled carrier-based messaging app for SMS/MMS/RCS is a special case that's given access to certain device identifiers including the IMEI. This is normally the GrapheneOS fork of AOSP Messaging but can be changed to another app by the user. Since these restrictions became standard, GrapheneOS only makes a small change to remove a legacy form of access to the serial number by legacy apps, which was still around for compatibility. It used to need more extensive changes such as disallowing access to the serial number but those restrictions are now standard. I don't know however if sandboxed google play is such a privileged app.
- kasabali 15d ago
  Play services isn't an "app", it's a highly privileged system service that has access to everything and some more.
  - exceptione 14d ago
    yes, but not on GOS.
  - grapheneos 14d ago
    The only way to use Play services on GrapheneOS is as a regular sandboxed app. It runs in the standard app sandbox without any of the usual privileged permissions, privileged SELinux policy and many other forms of special access. It also doesn't get used by the OS as a backend for anything. Our sandboxed Google Play compatibility layer implements this by remapping APIs to ones available to sandboxed apps and stubbing out many which aren't needed.
- asnelt 15d ago
  I couldn't immediately find whether GrapheneOS grants READ_PRIVILEGED_PHONE_STATE to Google Play. It might very well be that the GrapheneOS sandbox spoofs a fake IMEI, and I do hope so. In any case, my parent comment was meant for stock Pixels, as mentioned by armadyl further up in this thread.
  - grapheneos 14d ago
    The only way to install Google Mobile Services apps including the Play Store on GrapheneOS is as regular sandboxed apps. They aren't granted any of the large number of usual privileged permissions, don't run with the usual far more privileged SELinux policies, aren't used by the OS as a backend for anything and aren't otherwise allowed to do special things by the OS in the usual many ways that is granted. They're regular sandboxed apps on GrapheneOS.
  - nickspacek 15d ago
    https://grapheneos.org/usage#sandboxed-google-play https://grapheneos.org/usage#sandboxed-google-play > Google Play receives absolutely no special access or privileges on GrapheneOS as opposed to bypassing the app sandbox and receiving a massive amount of highly privileged access. It doesn't mention IMEI here, but hopefully READ_PRIVILEGED_PHONE_STATE is included in "privileged access."
    - exceptione 15d ago
      There is an AppStore app, I am not sure if this is the one we are talking about? <https://github.com/GrapheneOS/AppStore/blob/main/app/src/main/AndroidManifest.xml https://github.com/GrapheneOS/AppStore/blob/main/app/src/mai...> That one lists: ACCESS_NETWORK_STATE ENFORCE_UPDATE_OWNERSHIP FOREGROUND_SERVICE FOREGROUND_SERVICE_SPECIAL_USE INSTALL_PACKAGES INTERNET POST_NOTIFICATIONS QUERY_ALL_PACKAGES RECEIVE_BOOT_COMPLETED REQUEST_DELETE_PACKAGES REQUEST_INSTALL_PACKAGES UPDATE_PACKAGES_WITHOUT_USER_ACTION
      - gruez 15d ago
        That's grapheneos's own app, separate from the play store or play services.
- mindslight 15d ago
  That's the application software side. I would assume the IMEI and IMSI are both going out to the cell network though, and I would presume that it's trivial to tie a phone number to those with how the mobile industry generally sells subscriber data to various data brokers. The only question is how permissive those data brokers are (their major constraint is how much most people become aware of this dynamic), but when dealing with a major APT like Google I'd assume they're tuned into the best ones with songs about bona fide purposes.
  - exceptione 15d ago
    Are you talking about the US here? I am hoping this would be off-limits in Europe.
    - mindslight 15d ago
      Yes I am talking with a US perspective. I would hope the GDPR would prevent such things in (most of) Europe. But I also personally wouldn't assume so given that there are still the same dynamics of keeping the info flows private to avoid scrutiny, and claiming plausible "legitimate purposes" and "consent".

by asnelt 15d ago

exceptione 15d ago

That can't be true? <https://grapheneos.org/faq#hardware-identifiers https://grapheneos.org/faq#hardware-identifiers> As of Android 10, apps cannot obtain permission to access non-resettable hardware identifiers such as the serial number, MAC addresses, IMEIs/MEIDs, SIM card serial numbers and subscriber IDs. Only privileged apps included in the base system with READ_PRIVILEGED_PHONE_STATE whitelisted can access these hardware identifiers. Apps targeting Android 10 will receive a SecurityException and older apps will receive an empty value for compatibility. The currently enabled carrier-based messaging app for SMS/MMS/RCS is a special case that's given access to certain device identifiers including the IMEI. This is normally the GrapheneOS fork of AOSP Messaging but can be changed to another app by the user. Since these restrictions became standard, GrapheneOS only makes a small change to remove a legacy form of access to the serial number by legacy apps, which was still around for compatibility. It used to need more extensive changes such as disallowing access to the serial number but those restrictions are now standard. I don't know however if sandboxed google play is such a privileged app.

kasabali 15d ago
Play services isn't an "app", it's a highly privileged system service that has access to everything and some more.
- exceptione 14d ago
  yes, but not on GOS.
- grapheneos 14d ago
  The only way to use Play services on GrapheneOS is as a regular sandboxed app. It runs in the standard app sandbox without any of the usual privileged permissions, privileged SELinux policy and many other forms of special access. It also doesn't get used by the OS as a backend for anything. Our sandboxed Google Play compatibility layer implements this by remapping APIs to ones available to sandboxed apps and stubbing out many which aren't needed.
asnelt 15d ago
I couldn't immediately find whether GrapheneOS grants READ_PRIVILEGED_PHONE_STATE to Google Play. It might very well be that the GrapheneOS sandbox spoofs a fake IMEI, and I do hope so. In any case, my parent comment was meant for stock Pixels, as mentioned by armadyl further up in this thread.
- grapheneos 14d ago
  The only way to install Google Mobile Services apps including the Play Store on GrapheneOS is as regular sandboxed apps. They aren't granted any of the large number of usual privileged permissions, don't run with the usual far more privileged SELinux policies, aren't used by the OS as a backend for anything and aren't otherwise allowed to do special things by the OS in the usual many ways that is granted. They're regular sandboxed apps on GrapheneOS.
- nickspacek 15d ago
  https://grapheneos.org/usage#sandboxed-google-play https://grapheneos.org/usage#sandboxed-google-play > Google Play receives absolutely no special access or privileges on GrapheneOS as opposed to bypassing the app sandbox and receiving a massive amount of highly privileged access. It doesn't mention IMEI here, but hopefully READ_PRIVILEGED_PHONE_STATE is included in "privileged access."
  - exceptione 15d ago
    There is an AppStore app, I am not sure if this is the one we are talking about? <https://github.com/GrapheneOS/AppStore/blob/main/app/src/main/AndroidManifest.xml https://github.com/GrapheneOS/AppStore/blob/main/app/src/mai...> That one lists: ACCESS_NETWORK_STATE ENFORCE_UPDATE_OWNERSHIP FOREGROUND_SERVICE FOREGROUND_SERVICE_SPECIAL_USE INSTALL_PACKAGES INTERNET POST_NOTIFICATIONS QUERY_ALL_PACKAGES RECEIVE_BOOT_COMPLETED REQUEST_DELETE_PACKAGES REQUEST_INSTALL_PACKAGES UPDATE_PACKAGES_WITHOUT_USER_ACTION
    - gruez 15d ago
      That's grapheneos's own app, separate from the play store or play services.
mindslight 15d ago
That's the application software side. I would assume the IMEI and IMSI are both going out to the cell network though, and I would presume that it's trivial to tie a phone number to those with how the mobile industry generally sells subscriber data to various data brokers. The only question is how permissive those data brokers are (their major constraint is how much most people become aware of this dynamic), but when dealing with a major APT like Google I'd assume they're tuned into the best ones with songs about bona fide purposes.
- exceptione 15d ago
  Are you talking about the US here? I am hoping this would be off-limits in Europe.
  - mindslight 15d ago
    Yes I am talking with a US perspective. I would hope the GDPR would prevent such things in (most of) Europe. But I also personally wouldn't assume so given that there are still the same dynamics of keeping the info flows private to avoid scrutiny, and claiming plausible "legitimate purposes" and "consent".