Mozilla

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:

mozmarket.receipts.Prompter({
  storeURL: "https://marketplace.firefox.com/app/your-app",
  supportHTML: '<a href="mailto:you@yourapp.com">email you@yourapp.com</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).

23 comments

Comments are now closed.

  1. Steve wrote on February 27th, 2013 at 09:24:

    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?

    1. Kumar McMillan wrote on February 27th, 2013 at 13:02:

      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):
      https://github.com/andymckay/receipts/
      This one is for Django: https://github.com/andymckay/django-receipts/

  2. erlehmann wrote on February 27th, 2013 at 10:09:

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

    1. Robert Nyman [Editor] wrote on February 27th, 2013 at 12:52:

      Maybe. :-)

    2. Kumar McMillan wrote on February 27th, 2013 at 13:03:

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

    3. Andy McKay wrote on April 4th, 2013 at 10:22:

      We do now use 402 :)

      http://zamboni.readthedocs.org/en/latest/topics/api/payment.html#installing

  3. Nikhil Somaru wrote on February 27th, 2013 at 11:12:

    Interesting.

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

    1. Robert Nyman [Editor] wrote on February 27th, 2013 at 12:53:

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

  4. Jeffrey wrote on February 27th, 2013 at 13:06:

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

    1. Kumar McMillan wrote on February 28th, 2013 at 08:42:

      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 ;)

      1. ZenCODE wrote on March 17th, 2013 at 02:02:

        Thanks, that clarifies a lot ;-)

  5. pnathan wrote on February 27th, 2013 at 14:16:

    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?

    regards,
    pnathan

    1. Robert Nyman [Editor] wrote on February 27th, 2013 at 17:25:

      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
      }

  6. Kostadinov wrote on February 28th, 2013 at 12:42:

    Robert,
    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?

    1. Robert Nyman [Editor] wrote on March 1st, 2013 at 07:56:

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

      1. Kostadinov wrote on March 1st, 2013 at 13:25:

        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.

        1. Kumar McMillan wrote on March 1st, 2013 at 13:29:

          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.

          1. Korni wrote on March 12th, 2013 at 07:47:

            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…

          2. Kumar McMillan wrote on March 13th, 2013 at 07:28:

            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.

  7. WebResourcer wrote on March 2nd, 2013 at 09:50:

    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.

  8. Rogger Shaw wrote on March 4th, 2013 at 03:14:

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

    Am I right?

  9. Fred Lin wrote on March 5th, 2013 at 07:32:

    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.

    1. Kumar McMillan wrote on March 5th, 2013 at 08:54:

      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.

Comments are closed for this article.