A receipt for an app contains your product domain. That way when you verify the receipt, you can check that the product url matches your hosted app. This will stop people copying valid receipts around for your app.
However a packaged app has no domain. To get packaged apps working we just set it to the marketplace for want of a better idea in bug 784447. That's not such a great idea, since I can take a receipt for packaged app X and copy it over to packaged app Y and it will work great there.
Best idea so far, make a fake domain app-slug.packagedapp.marketplace.firefox.com thats obvious to the end developer. We'd need to surface this in the dev tools so its clear.
Of course, problem is that slugs can change.
Rob suggested using the app guid, so the domain could be:
Those can't change.
app://app-guid is what nick suggested and makes sense, we'll just need to change specs and trunion to allow that.
I don't quite understand the attack here.
Is the problem that the user purchases an application and receives a valid receipt for that app. He then copies the application files as well as the receipt to another device, thereby being able to use the application on that app as well?
If so, how does giving an application a domain help here? Wouldn't the application running on the other device also have the same domain?
I think that is correct: an attacker buys one app legitimately then copies the receipt to use for another app illegitimately.
Andy, is the problem that the developer needs some unique value in the receipt to whitelist? If so, could we use an ID in product.storedata?
The could use product.storedata, but they wouldn't know the data before hand and its specific to the store. So we'd have to expose that information.
Plus the assumption has been that information is something store specific and something a developer should never worry about.
If an origin is given in the manifest as is suggested in the bug 852720, I would much, much rather use that than any made up value.
This means that packaged apps will require an origin if they would like to be paid.
Let's use the origin from the manifest to populate the receipt. This means the developer will know the value before it goes to the marketplace and testing should be possible.
This is blocked on bug 878105 - figuring out if app origins are unique or not.
For the record, I reverted in: https://github.com/mozilla/zamboni/commit/10187d85
Can you please add some STRs to this bug in order to test it?
1) create a paid packaged app. ensure that the app manifest has an origin.
2) buy the paid packaged app, examine the receipt contents, ensure that the receipt product url field, matches the origin.