Comment on Google's plan to restrict sideloading on Android has a potential escape hatch for users

Zak@lemmy.world ⁨3⁩ ⁨days⁩ ago

• tauonite@lemmy.world ⁨3⁩ ⁨days⁩ ago

  They couldn’t. Domains and SSL certificates can be obtained very easily anonymously and thus wouldn’t let Google identify the developers of malicious apps, which is the goal of this

  source

  • coolmojo@lemmy.world ⁨2⁩ ⁨days⁩ ago

    The trouble is Google’s definition of malicious apps. Are adblockers malicious? How about alternative apps for YouTube? Based on the recent history, I don’t think you will be able to install those apps on the phone you purchased.

    source

    • tauonite@lemmy.world ⁨2⁩ ⁨days⁩ ago

      Yes, I agree. Google will use this to control the Android app ecosystem beyond the Play Store and I don’t like it either

      source

      • aeternum@lemmy.blahaj.zone ⁨2⁩ ⁨days⁩ ago

        You can sure as shit know that NewPipe and Smart Tube Next won’t be getting a licence. Fuck Google so fucking hard.

        source
  • Zak@lemmy.world ⁨2⁩ ⁨days⁩ ago

    It provides a way to open an investigation into a malicious developer without giving Google the ability to ban anyone it doesn’t like.

    source
  • Squiddork@lemmy.world ⁨2⁩ ⁨days⁩ ago

    Yeah I mean some form of asymmetric encryption/validation would work but it stops the real reason why Google wants to implement this.

    source
• LodeMike@lemmy.today ⁨2⁩ ⁨days⁩ ago

  The problem with that is that certificates expire before someone would want to keep using the app.

  source

  • Zak@lemmy.world ⁨2⁩ ⁨days⁩ ago

    It need only check at install time.

    source

    • LodeMike@lemmy.today ⁨2⁩ ⁨days⁩ ago

      Correction: SSL certificates can expire before someone would want to continue being able to install any given app.

      source

      • Zak@lemmy.world ⁨2⁩ ⁨days⁩ ago

        Sure, the developer needs to keep the certificate up to date and re-sign the APK on occasion.

        source

        • -> View More Comments
      • LodeMike@lemmy.today ⁨2⁩ ⁨days⁩ ago

        These two are identical for software.

        source
  • xthexder@l.sw0.com ⁨2⁩ ⁨days⁩ ago

    Code signing certificates work a little differently than SSL certificates. A timestamp is included in the signature so the certificate only needs to be valid at the time of signing. The executable will remain valid forever, even if the certificate later expires. (This is how it works on Windows)

    source

    • InnerScientist@lemmy.world ⁨2⁩ ⁨days⁩ ago

      Doesn’t work, the reason they can expire is to make certificate rotation possible. If an expired ssl certificate is cracked it doesn’t matter because no browser will accept the expired certificate, with your idea the expired certificate just signs an app with the date of 1984 and it works.

      Certificates in SSL can’t change the date because that date is signed by a certificate higher in the hierarchy.

      source

      • xthexder@l.sw0.com ⁨2⁩ ⁨days⁩ ago

        This isn’t “my idea”, this is how the industry already does code signing. You can’t sign something with a date of 1984 because your certificate has a start and end date, and is usually only valid for 1 year.

        You can read more about how this works here: …digicert.com/…/rfc3161-compliant-time-stamp-auth…

        source

        • -> View More Comments