757225 - Add app.replaceReceipt() to specification

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Ian Bicking (:ianbicking)]

We should implement app.replaceReceipt, but we should also actually get it into the spec.

Proposal: https://groups.google.com/d/msg/mozilla.dev.webapps/_9OjB23au6Q/RDJE0K25-Y8J

Comment 1

[Bill Walker [:bwalker] [@wfwalker]]

we need this API so that we can support the expiring receipts described in Appendix D of this specification:

https://wiki.mozilla.org/Apps/WebApplicationReceipt/GenerationService

This blocks k9o because it is critical to how we cope with compromised signing keys at our marketplace

Comment 2

[[e-mail] [:onecyrenus]]

mozApps.replaceReceipt
  was just thinking I don't really understand the use case where we want to replace a receipt from an installed app....
  Use case: A receipt has expired:  My next question would be why would the receipt expire ?  For anything that is subscription based, shouldn't they be using in app payments. 

  As a user it would be confusing to have both an in app payment model, and an app renewal / expiration model. 
  Example say I buy an app for $5 which expires yearly, and then I make in app payments, both with their own storage / maintenance mechanism, as well as their own separate code bases. 
  It would be easier to say hey if you want to have a monthly subscription to your app, make it free and then sell the user on in app payments. This makes it very clear to the user what needs to be maintained / managed. 
  
It might be easier for the user to have a price for an app, and then have possible upsells in the context / content of the app. The concept of an app "expiring" doesn't have to exist. 

  Use case: Security breach, and someone is signing their own apps. 
     Will this be prevalent ? 
     Can't the app maker just limit use to one IP at a time, per receipt. 
     Installs from tier 1 partners generally include an origin requirement, meaning that the app can only be installed from a certain origin.  
     For the users we are trying to reach, I don't think it makes much sense for them to attempt this to get out of paying for a $2-3 dollar item. The knock off android app stores haven't taken off to mass appeal, because it's just not that convenient to do...

Comment 3

[Ian Bicking (:ianbicking)]

The specific use case that motivated this is the signature on receipts expiring, so that the marketplace has to issue a new receipt (but can do so usually without intervention).  If a certificate is compromised the store may also force users to return to the store and log in before issuing a new receipt, and .replaceReceipt could be used to fix all the store receipts at once.  Also this allows simply invalid receipts to be removed, for instance if a bug in some system causes invalid receipts to be created.

Comment 4

[Lawrence Mandel [:lmandel] (use needinfo)]

Blocked on implementation bug 757226 instead of blocking on spec. Please renom if we should block on standardization of this API for k9o.

Comment 5

[Anant Narayanan [:anant]]

Adding it to the specification is not a basecamp blocker as long as the implementations (both in bug 745319 and bug 757226) are. Adding it to the spec is trivial enough, so I'm confident about finishing this in time anyway.

Comment 6

[Jason Smith [:jsmith]]

Got it. Thanks.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.