• PSA: Google recently replaced SafetyNet with Play Integrity

    From Maria Sophia@[email protected] to comp.mobile.android on Wed May 27 22:00:52 2026
    From Newsgroup: comp.mobile.android

    PSA: Google recently replaced SafetyNet with Play Integrity
    Why it matters to privacy.

    Some tongue-in-cheek sub titles might be:
    A device that cannot say "no" to Google does not belong to you.
    If you aren't seeing Play login prompts, your phone is ratting you out.
    Convenience is the bait; telemetry is the trap.
    Security is the masquerade; your data is what's being collected.
    The absence of an error message is the proof of a surveillance act.
    A green light from Google means your handcuffs are properly locked.
    The app isn't verifying your hardware; it's auditing Google compliance.

    Q: What's going on?
    A: There is a newly added hidden handshake happening every time you
    open a modern app. If you use a standard setup, it happens so fast
    you never notice it. But if you try to use your phone anonymously,
    that handshake fails, the app freezes, and Google demands a login.

    Here is the ugly reality behind why that is happening, as far as I know.
    Please add value and please help to correct anywhere I may err or omit.

    *The fundamental privacy flaw here is the telemetry payload itself.*

    During the background handshake, Google's servers generate an encrypted
    token that permanently binds the unique hardware signature of the physical device directly to a specific, personal Google account identity.

    It is a real-time tracking mechanism masquerading as a security feature.

    When a mainstream user launches an app, their phone silently broadcasts
    this hardware-to-identity link over the network. If a privacy-conscious
    user blocks this tracking by removing the Google account, the telemetry broadcast sends a blank field, the app back end panics because it cannot
    log the user's identity, and the software immediately halts.

    How do I know this?

    Because my phone is set up without a Google account and I've been getting
    these checks. So has everyone whose phone is similarly set up as private.

    Many app developers switched to Google Play Integrity recently.
    Not because app developers wanted it, but because Google forced them to.
    Google deprecated the old SafetyNet APIs.

    Hence, many newly updated or installed apps now immediately perform a
    Google Play Integrity check the moment they're opened.

    Given that, many apps will refuse to run unless Google's servers verify
    that a valid Google Play account is present and logged into the device.

    If the phone has no Google account set up, which is by design for privacy,
    the app immediately halts and demands a Google Play login. This is a prompt that seemingly cannot be satisfied without breaking the privacy model.

    Mainstream users whose phones are not set up for privacy will likely never
    see this prompt. Their devices quietly satisfy Google's account-tethering
    check automatically in the background. It's a proof they have no privacy.

    This app shows a passing status for my phone, but, many apps still fail.
    <https://github.com/1nikolas/play-integrity-checker-app>
    <https://play.google.com/store/apps/details?id=gr.nikolasspyr.integritycheck>

    To understand why an app can fail even when open-source integrity checkers
    show a passing status, we need to delve deeper into how Google separates
    Play Integrity data into two completely distinct lists.
    A. The device-profile list
    B. The macro-enforcement list

    The device-profile list is what open-source GitHub checkers measure.
    the macro-enforcement list is what consumer apps usually evaluate.

    A. The device-profile list
    1. MEETS_BASIC_INTEGRITY: Basic emulator checks.
    2. MEETS_DEVICE_INTEGRITY: Hardware certification
    3. MEETS_STRONG_INTEGRITY: Hardware-backed cryptographic keys.

    B. The macro-enforcement list
    1. Device Integrity:
    The structural profile verified in List A.
    2. App Integrity:
    Verification that the binary matches the official store version.
    3. Account Licensing:
    Verification that a valid Google account is active on the device
    and that valid Google account holds a license for the app.

    During this background handshake, Google's servers generate a token that
    binds the unique hardware signature of the physical device directly to a personal Google account identity.

    If that account link is missing, the software halts.

    The ability to bypass this privacy-destroying API with tricks like "adb
    install -i com.android.vending" boils down to how lazily an individual app developer incorporated these newly required Google security checks.

    Instead of writing complex code to verify the actual server-side token from Google, lazy developers simply ask the local Android operating system who installed the app. The ADB command forces the operating system to report
    that the Google Play Store was the installer. The app accepts this local metadata response and skips the deep account verification check entirely.

    To see if your own phone is silently broadcasting your identity to pass
    these tests, ask yourself this related but fundamental question:

    Q: When was the last time a newly installed app forced you to sign into
    a google play account just for that app to launch successfully?
    A: ?
    --
    A device that cannot say "no" to Google does not belong to you.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Theo@[email protected] to comp.mobile.android on Thu May 28 10:35:28 2026
    From Newsgroup: comp.mobile.android

    Maria Sophia <[email protected]> wrote:
    Q: What's going on?
    A: There is a newly added hidden handshake happening every time you
    open a modern app. If you use a standard setup, it happens so fast
    you never notice it. But if you try to use your phone anonymously,
    that handshake fails, the app freezes, and Google demands a login.

    GrapheneOS warn you if an app is using the Play Integrity API. Most apps continue as normal, but some banking apps refuse to work. I've never had an app demand a Google login (that I can remember, anyway). It's only a
    handful of apps I have that are making Play Integrity checks (WhatsApp,
    Garmin Connect, maybe eBay are the few I have that do it regularly), but obviously if an app just flat doesn't work then I'm not running it. Aside
    from banking, I recall one taxi app wouldn't let me make an account to use
    it - I just used a different taxi company.

    Some apps won't run if they have been installed from a location other than
    the Play Store. The trick there is to install them another way in the
    primary user profile (eg via .apk or Aurora Store) then launch a secondary
    user profile with a Google account and install them via the Play Store,
    which will automatically update the app in the primary profile to having the 'installed by Play Store' flag (only one copy of an app can be installed
    across the system). You can then stop the secondary profile and carry on
    using the app in the primary profile. If you deny the app network access in the secondary profile it can't phone home anything relating to the Google account it was installed with, and if your primary profile doesn't have a Google account then it can't get hold of that ID.

    Theo
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Maria Sophia@[email protected] to comp.mobile.android on Thu May 28 08:06:41 2026
    From Newsgroup: comp.mobile.android

    Theo wrote:
    GrapheneOS warn you if an app is using the Play Integrity API. Most apps continue as normal, but some banking apps refuse to work. I've never had an app demand a Google login (that I can remember, anyway). It's only a
    handful of apps I have that are making Play Integrity checks (WhatsApp, Garmin Connect, maybe eBay are the few I have that do it regularly), but obviously if an app just flat doesn't work then I'm not running it. Aside from banking, I recall one taxi app wouldn't let me make an account to use
    it - I just used a different taxi company.

    Some apps won't run if they have been installed from a location other than the Play Store. The trick there is to install them another way in the primary user profile (eg via .apk or Aurora Store) then launch a secondary user profile with a Google account and install them via the Play Store,
    which will automatically update the app in the primary profile to having the 'installed by Play Store' flag (only one copy of an app can be installed across the system). You can then stop the secondary profile and carry on using the app in the primary profile. If you deny the app network access in the secondary profile it can't phone home anything relating to the Google account it was installed with, and if your primary profile doesn't have a Google account then it can't get hold of that ID.

    Hi Theo,

    That's great information! I accidentally sidestepped this trap for the
    longest time by not updating my apps but recently I was testing Shizuku updates in Aurora, and wham! I got hit by zillions of these new challenges!

    When I looked up what the heck was going on, I found out that it's been happening to others for about a year or so, but I had avoided all of it.

    If others haven't seen these prompts, it just means they already are
    sending their telemetry to Google but you and I don't do that.

    I can't unlock my USA-spec Samsung bootloader so I'm stuck fighting this
    with conventional means, while otherwise, GrapheneOS is the way to go.

    As for apps that won't install unless the play store installed them, I have
    a trick that gets around that so far, but it will only work on lazy apps.

    Note that almost every app from the Google Play repo is a split APK.
    adb.exe install-multiple -i com.android.vending base.apk split_config.arm64_v8a.apk split_config.xhdpi.apk split_config.es.apk

    The "trick" in that command above is to spoof com.android.vending as
    the installer, even though adb was the actual installer, and even
    as I downloaded the APKs off the Google Play repo w/o an account.

    As you noted, GrapheneOS and similar privacy-focused ROMs highlight Play Integrity usages so users can decide whether to trust each app; if an app refuses to run we can either avoid it or run it in a profile with Play services (as you outlined).

    Your added practical advice for users is useful to document here.
    1. If we need an app, run it only in an isolated profile with Play;
    2. We should prefer open-source alternatives when possible;
    3. We should consider whether the service truly requires the app
    or if a web version works (which has its own issues though);
    4. We should not enter personal Google credentials into a profile
    we want to keep separate unless we accept the account linkage.

    Is that improved advice for users who wish to maintain some privacy? .
    --- Synchronet 3.22a-Linux NewsLink 1.2