755006 - [Evangelism] Existing paid applications on marketplace are not doing receipt checking

Status: RESOLVED INVALID

(Marketplace Graveyard :: Payments/Refunds, enhancement)

Description

[Ian Bicking (:ianbicking)]

I just checked all the paid apps in the Marketplace (which to be fair is only from a couple developers), and not one of them checks the receipts.  That means that purchasing and refunding the app gives me the app.

It's okay to be a little lax about receipts, but this is too overt.  We need to help these developers do the right thing here.

A pure-client-side Javascript receipt checking library, that pings that Marketplace, would be helpful.  JSONP or CORS access on the marketplace verifier would also be important.

app.replaceReceipt would also be helpful for updating the receipts when a refund is issued, and application uninstallation on refund also seems sensible (though things are not implemented currently to let the store force an uninstallation, but at least it should try).

Comment 1

[Jason Smith [:jsmith]]

Not sure of the right place of where to put this bug, but moved to marketplace --> payments/refunds for now until we figure out the breakdown of this task (this a multi-part task, possibly including marketplace and desktop web runtime changes). Krupa - If there's another place you would suggest putting the bug, then feel free to move it to another location.

Comment 2

[Kumar McMillan [:kumar]]

Andy started a Python lib: https://github.com/andymckay/receipts

I agree. We need to write libs, lots of docs, then evangelize.

Comment 3

[Christopher Van Wiemeersch [:cvan]]

It is up to the developer to do receipt checking. Unfortunately, how to do that is a huge unknown right now.

We link to MDN when you submit a paid app (http://i.imgur.com/oqyrK.png): https://developer.mozilla.org/en/Apps/Validating_a_receipt

I know there are some parties who are working on libraries that will enable easy receipt verification for developers. Anyone want to chime in?

Comment 4

[Andy McKay]

I've been behind on writing my example app and unfortunately other things got in the way. I'd be willing to file so "let's make some libs" bugs and assign those to the marketplace. 

But this is more job for the evangelism team, biv dev team to do. 

Not sure where that goes.

Comment 5

[Ian Bicking (:ianbicking)]

I'm going to give it a go to write a simple Javascript library.  I'm going to leave off crypto and just focus on Marketplace verification.  There's other use cases, but I think this fits our current round of paid apps.  I'll commit the work here: https://github.com/ianb/openwebapps-helpers (but I haven't committed anything yet).

It would be helpful if verification gave some hint for how long the verification was valid.  In particular there is a period early on when frequent reverification makes sense, as the first 30 minutes has an easy refund.  After that the time could be extended.  While I could (and probably will) code that into the library, the actual heuristics depend on store policy.

Comment 6

[Andy McKay]

I'm working on a django library to demonstrate using a proxy. Hopefully James Burke is working on a JS library. There's a lot going on.

There is no hint on how long the verification is valid. That's slightly different but intertwined with the receipt policy.

A receipt will expire when the certificate or the expiration in the receipt runs out (bug 749673). We expect clients to enforce this (for example for an offline app), or then ask the marketplace and we'll tell them its expired.

The ease of a refund occurring does vary and will vary per store and this could effect how long to check for receipts. Anything that involves checking within that 30 minute instant refund period though feels likely to fall subject to general lag / offline issues. I've always a large degree of leeway should exist in receipt checking for this.

Would it be worth writing in some sort of structure that should demonstrates the rate of reciept checking that a client should do? Or just document it and leave it up to the developer? 

My feeling is there's enough to be done by the developer and this is an edge case, as long as the refund policy is clearly documented and we give rough guidelines and recommendation for our marketplace that's enough.

Comment 7

[Ian Bicking (:ianbicking)]

Re: expiration, I'm more concerned that if there's a policy to check once a week, if you do a check in the first 10 minutes that you not defer the next check until a week from then.  Network errors should also probably be handled differently than all other kinds of errors.

Comment 8

[Fred Wenzel [:wenzel]]

Like Andy is hinting, receipt checking will also need to become part of the open webapps template that the Jameses (Burke, Long) are working on. Ideally it'll be a detached JS library that just happens to be used by the template so that other apps can use it too?

Comment 9

[Ian Bicking (:ianbicking)]

I haven't tested it at all, except to ensure it is syntactically valid, but I have code up: https://github.com/ianb/openwebapps-helpers/blob/master/helpers.js

The focus of this code is very much on pure-Javascript apps (which are pretty much all our paid apps currently).  Server-side verification is safer, but client side verification is much better than the current norm of no verification at all.

Comment 10

[Kevin Dangoor]

I'm nominating this for k9o-blocking because while I believe that developers do not expect (or possibly even desire) full DRM, I do think they would expect some easy way (that they've been told about!) to ensure that users who get a refund won't be able to just continue using the app. (FWIW, Kumar's summary in comment 2 seems spot on, and it's great to see the solutions appearing.)

Comment 11

[Kumar McMillan [:kumar]]

ianb: awesome!

Once we have something proven and working one idea is we could incorporate it into our mozmarket.js library which is a helper for interacting with the marketplace. Currently it supports mozmarket.buy() for in-app payments but receipt validation sounds like a great feature to add.

This is served by our CDN which has great edge coverage.

The script currently resides here: https://github.com/mozilla/zamboni/blob/master/mkt/site/templates/site/mozmarket.js

Comment 12

[Mark Giffin [:markg]]

I am actively adding docs on receipt validation here:
https://developer.mozilla.org/en/Apps/Validating_a_receipt
Additions and comments welcome.

Comment 13

[Ian Bicking (:ianbicking)]

This library is now roughly working: https://github.com/ianb/openwebapps-helpers/

Later it will be added to mozmarket.js: https://github.com/mozilla/zamboni/blob/master/mkt/site/templates/site/mozmarket.js – that's a library we'll be encouraging all app developers to include.

Comment 14

[Ian Bicking (:ianbicking)]

The library previously known as openwebapps-helpers has been moved here: https://github.com/mozilla/receiptverifier

It implements pretty thorough client-side checking, but without any UI, applications still have to handle the error cases themselves (e.g., redirect to the marketplace).

It will be integrated into mozmarket.js soon.

Comment 15

[Myk Melez [:myk] [@mykmelez]]

Updating the Summary and Severity fields, and adding dev-doc-needed, to reflect the work that needs doing here (which comprises both creating/enhancing a JS library to make receipt checking easier and documenting best practices for receipt checking).

Comment 16

[Kumar McMillan [:kumar]]

this bug led to a more concrete one: bug 758733 :) ianb has working code to verify receipts in JS so we're going to provide that to developers in the mozmarket.js shim served by the marketplace CDN. Docs will also land in MDN but there isn't a bug for that yet.

Comment 17

[Jason Smith [:jsmith]]

(In reply to Kumar McMillan [:kumar] from comment #16)
> this bug led to a more concrete one: bug 758733 :) ianb has working code to
> verify receipts in JS so we're going to provide that to developers in the
> mozmarket.js shim served by the marketplace CDN. Docs will also land in MDN
> but there isn't a bug for that yet.

To clarify my understanding - So this bug then is to finish building the library, and the followup bug in bug 758733 is to integrate it into the deployment process, correct?

Comment 18

[Kumar McMillan [:kumar]]

(In reply to Jason Smith [:jsmith] from comment #17)
> To clarify my understanding - So this bug then is to finish building the
> library, and the followup bug in bug 758733 is to integrate it into the
> deployment process, correct?

This bug has morphed a bit. Originally it was just meant to point out that there were real paid apps in production that were not checking receipts. 

The JS library is now in a working state per https://bugzilla.mozilla.org/show_bug.cgi?id=758733#c3

Comment 19

[Jason Smith [:jsmith]]

(In reply to Kumar McMillan [:kumar] from comment #18)
> (In reply to Jason Smith [:jsmith] from comment #17)
> > To clarify my understanding - So this bug then is to finish building the
> > library, and the followup bug in bug 758733 is to integrate it into the
> > deployment process, correct?
> 
> This bug has morphed a bit. Originally it was just meant to point out that
> there were real paid apps in production that were not checking receipts. 
> 
> The JS library is now in a working state per
> https://bugzilla.mozilla.org/show_bug.cgi?id=758733#c3

Ah, so the bug was more identifying an evangelism problem then, but it already looks like the library is done. So probably the way to resolve this bug then is to get the existing paid apps to do receipt checking properly (prove that we know developers can implement this easily), correct? Steps include what's already happening to get the infrastructure in place, then evangelizing this to app developers successfully.

Comment 20

[Jason Smith [:jsmith]]

Stormy - Who on the dev engagement team would drive evangelizing proper receipt checking for marketplace and use of the library Ian has built for easier receipt verification? That should probably be the person owning this bug to ensure that our existing paid apps and followup paid apps that are submitted properly implement receipt verification correctly.

Comment 21

[Kevin Dangoor]

Two things that are currently in play will help with this...

1. documentation "tracks" that take developers from beginning to end of building an app. these tracks can include info about receipt checking.

2. a bootstrap project is being built to help people get going. That project can also incorporate the new library and receipt checking.

Comment 22

[Wil Clouser [:clouserw]]

What are the actionable steps for this bug?  Who is the owner?

Comment 23

[Jason Smith [:jsmith]]

(In reply to Wil Clouser [:clouserw] from comment #22)
> What are the actionable steps for this bug?  Who is the owner?

Probably isn't actionable anymore, as the paid apps aren't valid anymore. Closing as no longer valid.