101–110 of 152 posts
Google Playstore is a walled garden, like Apple's. The walls are only growing higher and higher. Once Apple adds a layer of bricks, Google follows and vice versa.
Earlier quoted context omitted.
I seriously doubt 99% of Google Play developers worry enough that they would take the time and money to run a signing server, and that would introduce a lot of complexity for Google.
How is an automated signing server better security anyway? Google can still sign what they want but now every dev has a missive security hole in the form a server that can sign code reachable from the open web?
Earlier quoted context omitted.
The model also shields to a certain extent against conflict of interests (the product is the user, i.e. ads/tracking/hostile maintainership takeover)
> The model also shields to a certain extent against conflict of interests (the product is the user, i.e. ads/tracking/hostile maintainership takeover) What I find difficult to wrap my head around is that the Debian model (I know other distributions do this as well but just have to give it some name) is very difficult to scale. We basically need maintainers at every single Linux distributions who will (I imagine) go…
For example they can simply refuse to release/publish anything if the code looks shit/obfuscated. They can explicitly ask questions about sections of code.
But since probably 99.9+% of "app review" is already automated ... likely there's no point in spending resources on creating a "GitHub clone" for submitting code to the various app stores.
Earlier quoted context omitted.
It's just a little bit weird that Google designed the Play Store and Android with key signing if they then have to ask for those keys. They control the OS and the store, couldn't they just make devices trust Google's app-repackaging-service's key? This would be easier for everyone, and more honest for the consumer user who gets packages signed by whoever actually built it.
This solution is backwards compatible. Changing the installation verification process is not.
Earlier quoted context omitted.
PITA, most likely. More round trips. More complexity. More work for the user. It also means that the bundling process cannot be improved and you can't extend it to support new configurations without the involvement of the user. There are a bazillion locales and device configurations out there, with more created every day.
Why not let the developer generate the tailored binaries in the first place?
Why do I care? Google can already modify the behavior of an app without the developer's permission; they can just push an update to Android that changes the behavior of that app. It's "reflections on trusting trust" all over again.
My android updates do not come directly from Google, but instead my mobile provider. Google has no control over them, but they have direct control over the play store.
App bundles allow smaller apk sizes [0]: > Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the code and resources that are needed for a specific device are downloaded to run your app. You no longer have to build, sign, and manage multiple APKs to optimize support for different devices, and users get smaller, more-optimized downloads. But as all this logic s…
Piling on here, thats super weird . The reason for digital signatures is that they make a claim. "As a representative of organisation A, the binary with shasum XXXX is our work. We stand behind it." Why would I generate a private key, then share my private key with google ? If google wants to claim that a binary they're shipping to users is same the one they received, they don't need my private key to do that. They c…
Most developers will let Google just generate the keys for them.
The article linked from this one is worth a read: https://commonsware.com/blog/2020/09/23/uncomfortable-questi... They claim that because Google strips the developer signature and signs it themselves, they can modify the app and re-sign it. They suggest that an authoritarian regime could coerce Google into serving modified versions of eg. E2E encrypted messaging apps to people of that regime’s choice as a condition o…
They must be doing some re-signing on their side because the binary you upload is huge and it goes through optimisation on Apple's side so the user has a much smaller download.
Earlier quoted context omitted.
sounds like a good feature to me
If you want to update all your F-Droid apps at once on a non-rooted Android, you need to go through all of them one by one. Basically: click upgrade, click "Install", wait for Android to do its stuff, do the same for the next app. It is extremely impractical and most of the apps I installed from F-Droid are severely out of date because of this Android restriction. Fortunately F-Droid has an "Upgrade all" button which…
Earlier quoted context omitted.
The whole point of this feature is to allow Google to modify the APK by stripping out unneeded resources to reduce file size. If you require both a signature from Google and a signature from the developer, the modified versions would not pass validation. The issue is that this inherently requires users and developers to trust Google to only make innocuous changes.
If it's just "sign a thing, but allow some parts to be crossed out later while still being able to verify the signature", that's not that difficult to implement.