Comment on Google Play Store listing apps installed from F-Droid that it cannot update

• mundane@feddit.nu ⁨8⁩ ⁨months⁩ ago

  Mismatched signatures have been discouraged since day one of Android. A mismatched signature is a sign that some one other than the original publisher built this package, and the user needs to be aware that it might be malicious.

  That F-Droid went with this setup with mismatched signatures was always going to make their apks look suspicious.

  source

  • NeatNit@discuss.tchncs.de ⁨8⁩ ⁨months⁩ ago

    You misunderstood the whole situation. The signatures are all fine. Google Play Store is trying to override an app installed from F-Droid. If the two stores had the same signature, the play store would be able to do this which would go completely counter to the user’s choice (they installed from F-Droid for a reason). It’s a good thing the signatures don’t match, there’s nothing suspicious about it.

    It used to be that the play store just wouldn’t show updates to apps that it wasn’t actually able to update. They broke this behaviour.

    source

    • Norgur@fedia.io ⁨8⁩ ⁨months⁩ ago

      No, it's not a good thing. The solution would be to use a different package name for the f droid version. That's what's supposed to be done. It's not the signature or Google that's causing the problem. It's that there are two packages with identical names that should not be identical.

      source
    • mundane@feddit.nu ⁨8⁩ ⁨months⁩ ago

      The package name is the unique id. If you want to distribute multiple variants (like two versions with differing signatures) they should not have the same identifier. If they are not the same the id/package name should not be the same.

      Having different package names would also prevent the Google play store from trying to update it.

      source
• Norgur@fedia.io ⁨8⁩ ⁨months⁩ ago

  Even if it's new behavior, there is really no reason to assume that this was done to evoke some dark pattern or other. It just shows that Google will not think about 3rd party stores when they do anything with their services and that is hardly news, is it? Besides: I kinda get it honestly. If they'd take all the stuff out there for android into account before they did anything, nothing would be done at all.

  So the question becomes less why that's there, but more what stores like Samsung do to prevent this issue and if F-Droid can adapt the same behavior.

  source

  • NeatNit@discuss.tchncs.de ⁨8⁩ ⁨months⁩ ago

    Maybe that’s true, but then:

    • They previously had code to prevent this, why did they remove it?
    • Why won’t they fix it now? I’ve reported this twice already and I’m not the only one, this is affecting a huge number of users, why are they ignoring it? I refuse to believe they’re not aware of it. And if they aren’t aware of it that points to an even bigger issue of having absolutely no idea the repercussions of that they do even when thousands/millions of users reach out to tell them.

    source

    • Norgur@fedia.io ⁨8⁩ ⁨months⁩ ago

      I think you massively overestimate the amount of users that are
      a) affected by this
      b) reporting it
      When seeing the overall picture, this might mlbe a rather fringe issue in Google's eyes.

      Furthermore, you might be exaggerating the impact as well. The "impact" is that an app update fails. That's it. That might be annoying, but isn't the grave and evil thing you make it out to be.

      Besides, have you ever thought about that this stems from a rather bad practice on F-Droid/app developer side? They use the same package name for a software with a different signature. That's just not ideal to begin with. All packages with the same name should have the same signature for any given version of the package. That's how security works. If they don't follow that, how is a user/security software supposed to check if the signature is authentic or of the package was tampered with?

      source

      • NeatNit@discuss.tchncs.de ⁨8⁩ ⁨months⁩ ago

        AFAIK F-Droid allows using the same signing key as in PS. The choice is up to the developer. But as I said, if they use the same key then PS will overwrite the app, which is 100% unwanted behaviour.

        What do you suggest about package names? So you think there should be org.wikipedia.playstore, org.wikipedia.fdroid, org.wikipedia.galaxystore to use a different package name per store? Or should just F-Droid get the special name?

        Do you think it’s okay when e.g. play store and galaxy store update apps installed by the other store? This happens with various apps, especially some Samsung and Microsoft apps. (Obviously only when using the same keys)

        And specifically do you think that’s okay when F-Droid is thrown into the mix? I think absolutely not, especially since F-Droid often removes proprietary libraries, ads and tracking that are present in the other sources.

        Honestly I can warm up to the idea that F-Droid builds should have a unique package name (call it a flavour, even if it’s 1:1 with the play store release). But the Play Store and Galaxy Store overwriting each others’ apps already reeks of idiocy to me, and F-Droid has nothing to do with it.

        source
  • joewilliams007@kbin.melroy.org ⁨8⁩ ⁨months⁩ ago

    Samsung just says:

    Can't auto update Installed from Google play store.
    And Can't auto update Installed from Aurora store.

    You can easily see from what store an app has been installed in android.

    source
• wreckedcarzz@lemmy.world ⁨8⁩ ⁨months⁩ ago

  The ps has done this for many years, unfortunately

  source

  • NeatNit@discuss.tchncs.de ⁨8⁩ ⁨months⁩ ago

    I’ve only been seeing it in the past few months, definitely less than one year. Before that this never happened even when I had affected apps installed. Notably the Wikipedia app.

    source

    • wreckedcarzz@lemmy.world ⁨8⁩ ⁨months⁩ ago

      I have experienced it for at least 5y or so, back when I ran CalyxOS. It would try to override the sim tool at every opportunity when calyx used a custom version. With GrapheneOS, I have always (3y) had a stub apk to give me the preview picture in gCam without requiring gPhotos, and it bitches and errors constantly if you don’t turn off auto-updating. Tasks.org joined it recently since I use Obtainium (not f-d); it’s been happening with quite a few apps, just Tasks has been out of sync for the Github release vs play store release.

      Android knows if an apk is installed from the ps or not, this would be a two-line if-statent fix. But there’s no incentive for them to make using alternative stores/methods work better than the bare minimum, so they don’t :(

      source
• SaltySalamander@fedia.io ⁨8⁩ ⁨months⁩ ago

  The, being F-Droid, need to fix this, yes. They really should.

  source