3 ms·

Aside from the horrendous privacy implications, is there a possible argument that this is anti-competitive?

realusername 5mo ago
That's the whole goal of the concept. Safetynet (the predecessor of Play Integrity) was developed to block CyanogenMod and then later used to block Huawei.
- jeroenhd 5mo ago
  App developers need to put effort into enabling these APIs so it's not like Google is actively blocking your favorite apps. Their makers are. Like with reCAPTCHA, there are other services and libraries out there to detect root access and other things companies want to detect in their apps.
  - realusername 5mo ago
    Sure, Google was betting that bureaucratic companies would enroll voluntarily and it worked. > Like with reCAPTCHA, there are other services and libraries out there to detect root access and other things companies want to detect in their apps. My opinion on this is that any method to check integrity, root access or if developer mode is enabled is a security vulnerability by itself, no such app should be able to know that.
    - jeroenhd 5mo ago
      > My opinion on this is that any method to check integrity, root access or if developer mode is enabled is a security vulnerability by itself, no such app should be able to know that. I think knowledge of such information should be available to all apps, but I think apps should not be so annoyingly restrictive. There's absolutely no reason why games or generic apps need to act on any of this information.
      - realusername 5mo ago
        Realistically, in which scenario this information can be useful? I can't think of anything, it should be removed. It's been misused by banking app and games, I've never seen a legitimate use case.
        jeroenhd 5mo ago
        To verify that the user or someone who had physical access to the device (border checks, etc.) hasn't messed with the firmware. If I were a bank I wouldn't want to be on the hook for someone getting their bank account drained by the custom ROM someone downloaded from XDA. Then there's the DRM thing, where copyright owners make companies like Netflix sign a document like "if you don't enforce strong DRM, you cannot serve our media". Their choice is either use DRM (which in turn uses integrity checking) or not serve you at all. As a user, you once again have the choice of "buy the box set" or "use a smartphone with a trusted OS". There's also the corporate use case, companies have remote wipe capabilities for data integrity purposes and don't want their employees rooting phones. Pokemon Go used it to check whether people were spoofing their location and ruining the game for others. They were especially assholish about it, but that should hardly be a surprise when Nintendo is involved at any part of the chain. Any game with in-app purchases wants to verify that nobody messed with the APK to get paid content for free. It's almost a basic business requirement. Combining limited-lifetime remote attestation tokens with data fetch URLs means superweatherapp-patched-luckypatcher.apk on LineageOS will not be able to pretend to be the real app (GPlay on stock Android already offers app verification APIs). In Google's case, "this is a physical device and not an emulator" is a strong signal that the user is not a bot pretending to be a human. In an age where CAPTCHAs are easier to solve for AI than they are for humans, that kind of verification is worth a lot. I'm sure I'm missing a lot of use cases here, but the technology is useful. It's often used in apps and games I would never want to run on my phone anyway, except for banking apps perhaps.
        realusername 5mo ago
        Then it's a matter of personal opinion, I would not count any of the ones you listed as valid. Integrity doesn't prevent customers to download a fake banking app, DRMs should be legally banned to be honest (sorry/not sorry media companies) and passports are best in physical form. For company usage, locking the bootloader accomplishes the same thing. As for bots, it doesn't prevent bots as you have unmodified device farms on racks. It's actually how ad fraud is done at the moment, they don't bother modifying the devices. Pushing integrity even more will just funnel even more money to this ad fraud mafia as they will have a new source of revenue.
jeroenhd 5mo ago
the only anticompetitive element I can think of is the way they pushed their scanning app to Android phones with Play Services. On IOS they're not in control but still able to launch an app (app snippets the feature is called, I think?) but on Android they themselves killed off Instant Apps because nobody used it. If one of Google's competitors like hCAPTCHA tries to do the same, they'll have more friction on Android than Google does. When it comes to GrapheneOS, it's the website owners that decided to block those devices by using this service. There are other services that don't block those phones they can use instead.

That's the whole goal of the concept. Safetynet (the predecessor of Play Integrity) was developed to block CyanogenMod and then later used to block Huawei.

jeroenhd 5mo ago
App developers need to put effort into enabling these APIs so it's not like Google is actively blocking your favorite apps. Their makers are. Like with reCAPTCHA, there are other services and libraries out there to detect root access and other things companies want to detect in their apps.
- realusername 5mo ago
  Sure, Google was betting that bureaucratic companies would enroll voluntarily and it worked. > Like with reCAPTCHA, there are other services and libraries out there to detect root access and other things companies want to detect in their apps. My opinion on this is that any method to check integrity, root access or if developer mode is enabled is a security vulnerability by itself, no such app should be able to know that.
  - jeroenhd 5mo ago
    > My opinion on this is that any method to check integrity, root access or if developer mode is enabled is a security vulnerability by itself, no such app should be able to know that. I think knowledge of such information should be available to all apps, but I think apps should not be so annoyingly restrictive. There's absolutely no reason why games or generic apps need to act on any of this information.
    - realusername 5mo ago
      Realistically, in which scenario this information can be useful? I can't think of anything, it should be removed. It's been misused by banking app and games, I've never seen a legitimate use case.
      - jeroenhd 5mo ago
        To verify that the user or someone who had physical access to the device (border checks, etc.) hasn't messed with the firmware. If I were a bank I wouldn't want to be on the hook for someone getting their bank account drained by the custom ROM someone downloaded from XDA. Then there's the DRM thing, where copyright owners make companies like Netflix sign a document like "if you don't enforce strong DRM, you cannot serve our media". Their choice is either use DRM (which in turn uses integrity checking) or not serve you at all. As a user, you once again have the choice of "buy the box set" or "use a smartphone with a trusted OS". There's also the corporate use case, companies have remote wipe capabilities for data integrity purposes and don't want their employees rooting phones. Pokemon Go used it to check whether people were spoofing their location and ruining the game for others. They were especially assholish about it, but that should hardly be a surprise when Nintendo is involved at any part of the chain. Any game with in-app purchases wants to verify that nobody messed with the APK to get paid content for free. It's almost a basic business requirement. Combining limited-lifetime remote attestation tokens with data fetch URLs means superweatherapp-patched-luckypatcher.apk on LineageOS will not be able to pretend to be the real app (GPlay on stock Android already offers app verification APIs). In Google's case, "this is a physical device and not an emulator" is a strong signal that the user is not a bot pretending to be a human. In an age where CAPTCHAs are easier to solve for AI than they are for humans, that kind of verification is worth a lot. I'm sure I'm missing a lot of use cases here, but the technology is useful. It's often used in apps and games I would never want to run on my phone anyway, except for banking apps perhaps.
        realusername 5mo ago
        Then it's a matter of personal opinion, I would not count any of the ones you listed as valid. Integrity doesn't prevent customers to download a fake banking app, DRMs should be legally banned to be honest (sorry/not sorry media companies) and passports are best in physical form. For company usage, locking the bootloader accomplishes the same thing. As for bots, it doesn't prevent bots as you have unmodified device farms on racks. It's actually how ad fraud is done at the moment, they don't bother modifying the devices. Pushing integrity even more will just funnel even more money to this ad fraud mafia as they will have a new source of revenue.

jeroenhd 5mo ago

the only anticompetitive element I can think of is the way they pushed their scanning app to Android phones with Play Services. On IOS they're not in control but still able to launch an app (app snippets the feature is called, I think?) but on Android they themselves killed off Instant Apps because nobody used it. If one of Google's competitors like hCAPTCHA tries to do the same, they'll have more friction on Android than Google does. When it comes to GrapheneOS, it's the website owners that decided to block those devices by using this service. There are other services that don't block those phones they can use instead.