5 ms·

I don't understand the intent of this comment, but one sentence stood out: > It changes from "We guarantee we will distribute your app unmodified" to ... well,

I don't understand the intent of this comment, but one sentence stood out: > It changes from "We guarantee we will distribute your app unmodified" to ... well, I don't know what you are promising, but it's not that. The closest analogy would be a universe in which UPS insists you delegate the packaging of your product to them. Your product remains unchanged, but it's packaged with UPS's packaging which (for the sake of this example) may come with better assurance guarantees relative to your own packaging of the product you're shipping. Point being: (edit: assuming no malicious supply chain interference; I'll get to this) the app is unmodified. Even with Google doing the signing. I don't inherently see anything wrong with this, though I also don't think any physical carriers have tried this. Anyone have any examples? Even from other subdomains within logistics? --- Edit: with supply chain interference (compromising build pipelines, etc), who signs the app doesn't really matter; the app is still tampered before it gets to Google's marketplace. The trade with Google compelling their own signing infrastructure is that it reduces the risk of compromised keys for individual development shops enabling malicious actors to sign builds on behalf of the developers. --- Edit 2: Some pretty great answers and counterpoints here, such as FBA and the resulting uptick in counterfeit goods. Unexpected but good food for thought.

MattGaiser 5y ago
Fulfilled by Amazon does that, although it is more than a shipping company there.
- rblatz 5y ago
  And Amazon commingles inventory, so when I buy an item on Amazon from Bob Amazon may actually ship me Alice’s crappy fake item. Which to drive it home, if Bob included a signed photo with each of his items I would know if I got the item from Bob or someone else.
  - GauntletWizard 5y ago
    Amazon's commingling of inventory is actually fraud, and the fact that they've not been charged for it is the slowness of the legal system. It is fraud in two ways: It misrepresents the seller, and it misrepresent the origin. That it misrepresents the seller is simple: You don't know who provided you the inventory that Amazon is shipping you. You will often get inventory provided by company B when you receipt says company C. When and if you get a defective product, you have a legal case for compensation against company C, but when they didn't provide the product in the first place (company B did), the waters get muddied. You still have a legal case against company C (They're the seller of record, and you got a faulty product). Company C has a legal case against Amazon (they sent a faulty product on behalf of Company C), and Amazon has a legal case against Company B (They were provided a product that was misrepresented) There's an alternate line of legal reasoning: Make Amazon the seller of record. This cuts the gordian knot quite nicely, but Amazon has repeatedly rejected it, because: Sending you commingled product is fraud when the product is not represented correctly: When you buy a "Genuine Apple Charger" and you get a cheap piece of junk in similar packaging, you are being defrauded. Whenever Amazon commingles a non-genuine product with a genuine product and sends it on to the consumer, that's fraud. This is a legal monty-hall problem. If you lay it all out and examine all of the branches individually, it is quite clear: At some point down each of the lines, Amazon has committed fraud. Either fraud against the consumer, or fraud against it's partners, but regardless: Harm has been done to the consumer and that harm was introduced by Amazon. The harm was introduced when Amazon bucketed the faulty products with the non-faulty products, and thereby destroyed the chain of custody of where it came from. IFF Amazon took careful notes and marked each item with it's origin, then they could pass the blame on to Company B (Where it really belongs), but they didn't, and as such are liable for Company B's misdeeds that they have laundered.
saurik 5y ago
The signing key is what allows for upgrades that still gives you access to all of the data from the app; if you have an app with a pin code that is protecting a signing key or a password database, this means Google can now help people upgrade the app without it being an official upgrade from the source you chose. You might try to argue that Google can already just change the operating system out from under you in similar situations, but that forgets that Google doesn't actually control Android: the manufacturer of your phone is the only person who can ship updates for your phone (not Google). Even mitigations focused on this behavior for just Google's store are disappointing, as the current signing key approach is designed to better support multiple competing app stores and platforms: your app, as distributed for every device by ever vendor through any store is signed by the same key... that's what makes it "your app". It should be the case that the app is end-to-end encrypted through any store and that any store is then able to securely upgrade the app you for from any other store... this all is eroding that as it is giving Google too much power over authenticity.
falcolas 5y ago
> the app is unmodified Problem: you have no way to prove it. Nobody can prove it. That’s what developer signing proves - that is hasn't been modified.
Aaargh20318 5y ago
> Point being: the app is unmodified. Even with Google doing the signing. The difference is that you used to be able to verify that Google didn’t modify the app. They simply couldn’t make a change while keeping the signature intact. Now they can, they just say they won’t and expect you to trust their word.
- eganist 5y ago
  > Now they can, they just say they won’t and expect you to trust their word. In theory this can be verified by the developer though? Signing an app shouldn't (I haven't checked this in Google's case) change any integrity values for the app code itself, so the developer (though no one else) is still able to ensure Google wouldn't have tampered anything. But your point makes sense.
  - lazide 5y ago
    The reason they are doing this (keeps getting buried) is because they want to change distributed APKs, shims, etc. so they have the right packages and deps per device, and can ensure that what they build is what is accepted on the device and not some other random thing. So it is working as intended if what is installed on some device is not what the Dev built.
    - GauntletWizard 5y ago
      This still represents a foundational change to the android model, and there are better ways of doing so. The simplest (which requires no changes) of Google to asking you to sign a few dozen different versions of your app for different models. That idea is easy to reject because it would be "too cumbersome" and require re-uploading the same app package repeatedly, but it would work. There are other models that Google could adopt to allow this functionality. Google could come up with a new app format whereupon there were a signed manifest of files, and Google could selectively leave some out (Git does something very similar: The commit includes a map of filenames to cryptographically-secure object IDs, which may be in one of many different packfiles). This would allow Google to strip the assets that are unnecessary for your device, while still giving the Developer control over what's shipped. But more importantly: This is about control. Currently there's a nice check-and-balance system. The developer signs the package, and Google inspects and can choose not to distribute it. The new system gives all the control to Google; They sign, they distribute. This may have been effectively where the system was before, because only a sparse minority of users checked the developer keys directly, but there's a big leap between the trust being defacto with Google (because people trust them and don't check), and that trust being completely with Google (because there's no way to check, Google holds all the keys). I do trust Google to distribute my app. I trust them where I can check their work. I trust them because I can check their work. I know there would be outrage if they started distributing things that were not what I signed. This is that outrage.
cglong 5y ago
UPS does literally this with expensive packages :) If I want insurance on the package, they have to be the ones to pack it.
roody15 5y ago
You do know that the US has been caught intercepting Cisco switches and routers… installing comprised versions of ios and then repackaging and resending to the original destination. Think the worry is google (and perhaps certain US agencies) will use this new requirement to do essentially the same approach with certain apps.

MattGaiser 5y ago

Fulfilled by Amazon does that, although it is more than a shipping company there.

rblatz 5y ago
And Amazon commingles inventory, so when I buy an item on Amazon from Bob Amazon may actually ship me Alice’s crappy fake item. Which to drive it home, if Bob included a signed photo with each of his items I would know if I got the item from Bob or someone else.
- GauntletWizard 5y ago
  Amazon's commingling of inventory is actually fraud, and the fact that they've not been charged for it is the slowness of the legal system. It is fraud in two ways: It misrepresents the seller, and it misrepresent the origin. That it misrepresents the seller is simple: You don't know who provided you the inventory that Amazon is shipping you. You will often get inventory provided by company B when you receipt says company C. When and if you get a defective product, you have a legal case for compensation against company C, but when they didn't provide the product in the first place (company B did), the waters get muddied. You still have a legal case against company C (They're the seller of record, and you got a faulty product). Company C has a legal case against Amazon (they sent a faulty product on behalf of Company C), and Amazon has a legal case against Company B (They were provided a product that was misrepresented) There's an alternate line of legal reasoning: Make Amazon the seller of record. This cuts the gordian knot quite nicely, but Amazon has repeatedly rejected it, because: Sending you commingled product is fraud when the product is not represented correctly: When you buy a "Genuine Apple Charger" and you get a cheap piece of junk in similar packaging, you are being defrauded. Whenever Amazon commingles a non-genuine product with a genuine product and sends it on to the consumer, that's fraud. This is a legal monty-hall problem. If you lay it all out and examine all of the branches individually, it is quite clear: At some point down each of the lines, Amazon has committed fraud. Either fraud against the consumer, or fraud against it's partners, but regardless: Harm has been done to the consumer and that harm was introduced by Amazon. The harm was introduced when Amazon bucketed the faulty products with the non-faulty products, and thereby destroyed the chain of custody of where it came from. IFF Amazon took careful notes and marked each item with it's origin, then they could pass the blame on to Company B (Where it really belongs), but they didn't, and as such are liable for Company B's misdeeds that they have laundered.

saurik 5y ago

The signing key is what allows for upgrades that still gives you access to all of the data from the app; if you have an app with a pin code that is protecting a signing key or a password database, this means Google can now help people upgrade the app without it being an official upgrade from the source you chose. You might try to argue that Google can already just change the operating system out from under you in similar situations, but that forgets that Google doesn't actually control Android: the manufacturer of your phone is the only person who can ship updates for your phone (not Google). Even mitigations focused on this behavior for just Google's store are disappointing, as the current signing key approach is designed to better support multiple competing app stores and platforms: your app, as distributed for every device by ever vendor through any store is signed by the same key... that's what makes it "your app". It should be the case that the app is end-to-end encrypted through any store and that any store is then able to securely upgrade the app you for from any other store... this all is eroding that as it is giving Google too much power over authenticity.

falcolas 5y ago

> the app is unmodified Problem: you have no way to prove it. Nobody can prove it. That’s what developer signing proves - that is hasn't been modified.

Aaargh20318 5y ago

> Point being: the app is unmodified. Even with Google doing the signing. The difference is that you used to be able to verify that Google didn’t modify the app. They simply couldn’t make a change while keeping the signature intact. Now they can, they just say they won’t and expect you to trust their word.

eganist 5y ago
> Now they can, they just say they won’t and expect you to trust their word. In theory this can be verified by the developer though? Signing an app shouldn't (I haven't checked this in Google's case) change any integrity values for the app code itself, so the developer (though no one else) is still able to ensure Google wouldn't have tampered anything. But your point makes sense.
- lazide 5y ago
  The reason they are doing this (keeps getting buried) is because they want to change distributed APKs, shims, etc. so they have the right packages and deps per device, and can ensure that what they build is what is accepted on the device and not some other random thing. So it is working as intended if what is installed on some device is not what the Dev built.
  - GauntletWizard 5y ago
    This still represents a foundational change to the android model, and there are better ways of doing so. The simplest (which requires no changes) of Google to asking you to sign a few dozen different versions of your app for different models. That idea is easy to reject because it would be "too cumbersome" and require re-uploading the same app package repeatedly, but it would work. There are other models that Google could adopt to allow this functionality. Google could come up with a new app format whereupon there were a signed manifest of files, and Google could selectively leave some out (Git does something very similar: The commit includes a map of filenames to cryptographically-secure object IDs, which may be in one of many different packfiles). This would allow Google to strip the assets that are unnecessary for your device, while still giving the Developer control over what's shipped. But more importantly: This is about control. Currently there's a nice check-and-balance system. The developer signs the package, and Google inspects and can choose not to distribute it. The new system gives all the control to Google; They sign, they distribute. This may have been effectively where the system was before, because only a sparse minority of users checked the developer keys directly, but there's a big leap between the trust being defacto with Google (because people trust them and don't check), and that trust being completely with Google (because there's no way to check, Google holds all the keys). I do trust Google to distribute my app. I trust them where I can check their work. I trust them because I can check their work. I know there would be outrage if they started distributing things that were not what I signed. This is that outrage.

cglong 5y ago

UPS does literally this with expensive packages :) If I want insurance on the package, they have to be the ones to pack it.

roody15 5y ago

You do know that the US has been caught intercepting Cisco switches and routers… installing comprised versions of ios and then repackaging and resending to the original destination. Think the worry is google (and perhaps certain US agencies) will use this new requirement to do essentially the same approach with certain apps.