Hacker News Reader

Comment by fallingknife | Hacker News Reader

The developer would still be able to post the shasum though, right? If so this would still be detectable.

Nope, because the delivered bundle is going to be different from the APK the developer uploaded. This is the actual goal of this system. And when used for good, it allows much smaller app downloads.

However, it also makes developer signing harder (so google decided to eliminate it) because every app bundle is going to be a different file. As a side effect, this also kills 'reproducible builds', unless the bundling process by google is itself reproducible.

Thing is, Google wants to repackage the apps to lower and optimize download sizes. The developer can't know what SHA hash of an optimized partial bundle is.

Google could publish the code they're going to use to do the transformation step (as e.g. a Docker image), and the developer could audit the result by optionally independently running the same code themselves, at any time after publication. As long as the code Google published was deterministic, the developer should be able to use it to reproduce a binary with the same the SHA as the one offered centrally.

This is the same process that package maintainers (e.g. Debian, Mozilla, Tor) go through to produce reproducible (i.e. verifiable, deterministic) binary packages: they enable arbitrary users to run a copy of the packaging + distribution infrastructure on their own machine, such that they can watch it all go and see that it spits out the same thing the remote server does.

Yup, I'm pretty sure this makes reproducible builds totally impractical for any apps installed through the Play Store.

Apps that currently provide reproducible builds: Signal, Threema, Telegram. (Probably others as well.)

If "optimize[d] download sizes" is the goal, Google could simply release a tool that performed the compression/etc on a bundle (pre-signing) and require[1] that apps must be processed by the tool before submission.

[1] Google could easily verify this by making the tool output a fixed point; running the tool on an already processed bundle shouldn't change anything.

That doesn't work if there's a large and possibly growing matrix of hardware/OS/whatever combinations they're trying to optimize for.

I've only mentioned one example of how such a tool could work. There are many ways this typ0e of system could be designed. For an alternative that doesn't depend on the number of output combinations, see GauntletWizard's example[1] that uses a signed manifest of files.

[1] https://news.ycombinator.com/item?id=27177425

If they have the tool, they could give the tool. It's not like it's very often that a totally new arch + DPI + Android version combination appears.

The point is, if you build a signed app meant to run on any device, you are going to include code/assets for all of them. What Google wants to do is basically "tree-shake" the APK so that when you download it, it only contains what you need for your device.

Still, if they can generate the "shaken-down" version the dev could as well.

That tooling exists for a few years now - I don't think a lot developers opted to use it though.

"optimizing download size" is a lazy distraction when an OS update can be 1 GB. Goggle really wants to modify the apps for selected individuals. To sugar coat the pill, they came up with the size optimizing story (and reducing carbon footprint, probably).

Reply on news.ycombinator.com