Building A Paid App For Firefox OS

At first glance the Firefox Marketplace for Firefox OS may look similar to the Apple Store or Google Play Store but there is a key difference: it does not lock you into Mozilla or lock you into your Firefox OS phone. It enables you to sell a web app that will run on any open web device by way of the receipt protocol. Non-Mozilla marketplaces can participate in selling apps on Firefox OS out of the box by implementing the receipt format and users won’t notice anything different when running a paid app from either store.

When other devices support the receipt protocol then theoretically you could pay for an app once and run it everywhere. There is, of course, a chicken vs. egg problem here so Mozilla hopes to be the egg that helps prove out the decentralized receipt concept and iterate on the protocol. Mozilla invites other vendors to help us work on getting receipts right so that paid apps are as portable and “webby” as possible.

For Developers

It’s the responsibility of each paid app to validate its own receipt. If you’re a developer thinking about selling your app on Firefox OS, this post should give you a head start on implementing the receipt validation bits. This post may also be interesting for those who wish to build a compliant web runtime or a compliant marketplace.

The navigator.mozApps JavaScript API exposes device receipts to your application. The simplest way to validate a receipt is to include a client side library like receiptverifier.js and use the hosted verification service URL found in the receipt. The receiptverifer docs go into detail but it’s as easy as calling this JavaScript code when your app starts up:

  storeURL: "",
  supportHTML: '<a href="">email</a>',
  verify: true

That’s it! This is a high-level shortcut that also displays a prompt on the screen within your app if the receipt is missing or invalid. The docs for the verifier show how to do low-level validation.

For a more complete example, you can check out the code to the Private Yacht app which we’ve been using in testing. This app shows you how to do client side checking with the receiptverifier.js library as well as server side checking via Node.js. We also have a Python library (and one specifically for Django) that you can use on a server to check receipts.

How does it work? Each receipt is a mash up of JSON Web Tokens. One of the properties is a link to a hosted verification service that you can use to check the receipt. You also have the option of verifying receipts offline but this requires periodic key synchronization and some details like refund and reissue handling are not well supported yet for offline validation.

By default, a receipt is only allowed to originate from one of the store URLs in the installs_allowed_from parameter in your app’s manifest. As a developer you’ll create explicit payout relationships with each marketplace and will thus want to limit who can claim to sell your app. This acts as a whitelist for who can provide receipts for your app. Due to the loose nature of client side JavaScript, you can get tighter control over this whitelist by validating receipts server side (that is, on your own app server).

Paid apps for Firefox Marketplace aren’t fully live yet but they’re coming very soon. If you integrate a receipt checker into your app now, you’ll be ready when the submission flow supports payments.

Fraud Protection

Enabling any party on the web to sell apps is crucial to Mozilla’s vision of open web apps. However, making receipts decentralized while fully protecting app assets (without DRM) is challenging. There are currently attacks users can use in their clients, like a DNS proxy, to access paid apps but there is mitigation to this with CSP, CORS, and HSTS, just to name a few. The state of today’s paid iOS / Android apps is actually not much different. There is an open issue right now that will help make marketplace whitelists more effective and Mozilla expects to evolve the system further as more developers and more stores participate. Switching to a signed, packaged app may also offer another layer of asset protection but this was designed more to address permission issues.

As always, if you run into issues please file bugs! If it’s an Apps platform bug select Core (component: DOM: Apps) or select Marketplace (component: Payments/Refunds).

About Robert Nyman [Editor emeritus]

Technical Evangelist & Editor of Mozilla Hacks. Gives talks & blogs about HTML5, JavaScript & the Open Web. Robert is a strong believer in HTML5 and the Open Web and has been working since 1999 with Front End development for the web - in Sweden and in New York City. He regularly also blogs at and loves to travel and meet people.

More articles by Robert Nyman [Editor emeritus]…


  1. Steve

    I’ve interested in the receipt format you’ve mentioned but I have a Python based application that’s more server based, not for Firefox OS. Could my app utilize the receipt protocol and hook into your services so I can distribute my paid app that way?

    February 27th, 2013 at 09:24
    1. Kumar McMillan

      Yes, of course. We have a Python library you can use on your server to validate receipts (but anyone could do something similar in another language):
      This one is for Django:

      February 27th, 2013 at 13:02
  2. erlehmann

    Could this finally be a use case for HTTP 402 Payment Required? ;)

    February 27th, 2013 at 10:09
    1. Robert Nyman [Editor]

      Maybe. :-)

      February 27th, 2013 at 12:52
    2. Kumar McMillan

      Hah. Yes. Well, a 304 might be more useful because a browser would actual display new page to explain how to pay for it :)

      February 27th, 2013 at 13:03
    3. Andy McKay

      We do now use 402 :)

      April 4th, 2013 at 10:22
  3. Nikhil Somaru


    What sort of skillset would one require to begin developing for this platform. What are the tools?

    February 27th, 2013 at 11:12
    1. Robert Nyman [Editor]

      I good place to start is by reading Getting started with Open Web Apps – why and how.

      February 27th, 2013 at 12:53
  4. Jeffrey

    It sounds like “Asset Protection” is just another word for “Copy Protection” and “Digital Rights Management”. Is this correct?

    February 27th, 2013 at 13:06
    1. Kumar McMillan

      Sure, you could think of it that way. What we’re saying is that Mozilla does not offer complete Digital Rights Management. You can protect against people using your paid app without paying for it but it will never be 100% effective. We’re not encrypting assets on the web with true DRM.

      While this may be disappointing to some businesses our plan is to make *paying* for apps very easy, easier than stealing them ;)

      February 28th, 2013 at 08:42
      1. ZenCODE

        Thanks, that clarifies a lot ;-)

        March 17th, 2013 at 02:02
  5. pnathan

    I’ve looked around but I havn’t seen anything about in-app purchases. That’s something I’m very interested in exploring.

    Am I just missing it, or is it not there yet?


    February 27th, 2013 at 14:16
    1. Robert Nyman [Editor]

      In-app payments will be supported, but there are a number of details around that to work out (and we hope to have a follow-up article on that here).

      But in general, it will look something like this:

      var pay = navigator.mozPay(paymentToken);
      pay.onsuccess = function (event) {
      // Payment succeeded

      February 27th, 2013 at 17:25
  6. Kostadinov

    will it be possible to connect the phone to the computer and directly modify the source code of any application on the phone?
    For instance, if I want to change the background color of the main page or if I want to add a custom div somewhere, will it be easy enough?

    February 28th, 2013 at 12:42
    1. Robert Nyman [Editor]

      Great question! If you are interested in that, I recommend reading the Hacking Gaia for Firefox OS, part 1 article.

      March 1st, 2013 at 07:56
      1. Kostadinov

        Thank you, Robert! I’ve already had a look at this and many other links. I feel comfortable with the system and I am pretty sure that I will be able to write some apps for my own needs.
        My question was a bit more in another direction – the security (in terms of code protection) of the applications. For example, if everything is easily visible and accessible, it is possible to have a situation where I pay for an app, and the connect my phone, copy the app to my computer and then deploy it on another phone.
        I know it is a hard task to find a good balance between open and protected content (code) and that’s why I am curious about the FFOS approach. It will be much much better than iOS but we need to find out what the trade-offs are.

        March 1st, 2013 at 13:25
        1. Kumar McMillan

          Good question. You can copy around your own receipt and it will be valid on all devices. So, if your valid receipt leaked out then anyone else could use it too (receipts are not tied to users). To protect against this abuse, the app can do server side receipt checking and block usage if, say, more than 5 IPs were accessing the same receipt at once. It is not possible for an attacker to retrieve receipts from your phone without physically rooting it first.

          March 1st, 2013 at 13:29
          1. Korni

            I just installed a free app from the official marketplace, connected the mobile phone to my computer and was able to browse through the app’s code. Took just minimal digging and i found “/data/local/webapps/webapps.json” where all the important information is stored, i.e., the origin of the app. Then you simply can open your favorite browser and visit the website and look at the entire source code… That is what I actually fear with Firefox OS. You implement some awesome app, sell it over the marketplace and then someone just copies it for half the price. It is not about hacking your app, it is all about stealing code which might keep off some developers. Unless there is any solution to protect the code. With iOS and Android we have native apps, hence no code protection necessary. Here something else is needed…

            March 12th, 2013 at 07:47
          2. Kumar McMillan

            Hi Korni. What you say is true: you can view the source of any app since it is the web and that’s the nature of the web. Even with a packaged app you can root the device and retrieve the package. However, you mention that you cannot do this with iOS and Android but that’s not true. Try searching Google for the apk file of your favorite paid Android app and you’ll probably find it. De-compiling Java code is not hard (try searching) and the result would not be much different from de-compiling obfuscated JavaScript. On the other hand, iOS strips symbols so it’s not always possible to get the source.

            Anyway, I don’t think paid apps on the web are going to be that much less accessible than iOS/Android apps. In *both* cases you need to put a strong server component in your paid app for it to be something truly unique that cannot be pirated. Even then, someone will always try to copy your app if it’s successful. Just look at the first Groupon clones in China, for example, the styles *and* the server logic had been copied in a short time period.

            March 13th, 2013 at 07:28
  7. WebResourcer

    Interesting approach with receipt protocol. I do like the idea that you could pay for an app once and run it everywhere. Hope others embrace this approach this would unify a lot of things.

    March 2nd, 2013 at 09:50
  8. Rogger Shaw

    It is like a Asset Protection. The other word for Copy Protection and Digital Rights Management.

    Am I right?

    March 4th, 2013 at 03:14
  9. Fred Lin

    Does receipt protocol support multiple web market in webapp side?

    As a webapp developer I may want to put my webapp in both carrier’s market and mozilla marketplace.

    March 5th, 2013 at 07:32
    1. Kumar McMillan

      Yep, that’s exactly what it’s intended for. As a developer you can sell your app through any marketplace that supports the receipt protocol.

      March 5th, 2013 at 08:54

Comments are closed for this article.