Building A Paid App For Firefox OS(hacks.mozilla.org)
hacks.mozilla.org
Building A Paid App For Firefox OS
https://hacks.mozilla.org/2013/02/building-a-paid-app-for-firefox-os/
9 comments
It's just as easy on Firefox OS. Writing a web service is not required! Mozilla provides one for you :)
BTW, both iOS and Android require servers to be available for purchase checks unless, as the app developer, you don't care about piracy (which might be legitimate for the "most people will buy it" argument).
As for JavaScript being easy to patch. Is it really easier though? You can literally copy around apk files or search for them on pirate sites to get paid Android apps for free. There are videos on youtube for how to Patch paid iOS apps with fake certs and DNS hacks.
BTW, both iOS and Android require servers to be available for purchase checks unless, as the app developer, you don't care about piracy (which might be legitimate for the "most people will buy it" argument).
As for JavaScript being easy to patch. Is it really easier though? You can literally copy around apk files or search for them on pirate sites to get paid Android apps for free. There are videos on youtube for how to Patch paid iOS apps with fake certs and DNS hacks.
both iOS and Android require servers to be available for purchase checks
This is only correct for in-app purchases where it is part of the purchase flow. For your regular app purchase no checks need to be made.
This is only correct for in-app purchases where it is part of the purchase flow. For your regular app purchase no checks need to be made.
Actually - on Android, if you want to 'verify' that your app was not pirated (i.e. the paid-for APK was not just copied from one device to another), you have to call their licensing service: http://developer.android.com/google/play/licensing/index.htm.... Of course, many paid apps choose not to add this additional layer of verification, but it is functionally similar to the Firefox OS solution (except with a web app, you don't even need to copy an APK - you just visit it on the web).
You can't compare JS patching to someone spending hours and hours finding methods for using fake certs and DNS hacks. Sure the end result may be similar but to get to their requires a A LOT less more. Anyone can open up a JS file, find a line of code that does security checking, and return it false. You can show someone that in a Youtube video. What you can't show someone is how to spend hours and hours looking for ways to trick the OS into believing that the packaged application was previously paid for even though it wasn't.
Obfuscated and minified JavaScript with license checking scattered in diverse places will be much, much harder to figure. And it'll vary from app to app, while with Apple devices if you've stolen one you've stolen them all. (I think that's the effect?)
Not when you can easily just hijack the receipt methods. A lot easier than IAT hooking..lol
I'd disagree with the last part. The majority of Android apps do no certificate checks, so it's pretty much as easy as Googling "<paid android app> apk" and clicking the first result. You can even do it on your phone if that's easier.
I think you are correct about opening up JS files though. Are there any good security measures against that?
I think you are correct about opening up JS files though. Are there any good security measures against that?
Doing what you suggest would take "hours and hours" too, as you have to find a way to make the app run your modified JavaScript instead of the one that it retrieves from the server.
Libraries and services to manage this will appear. Mozilla are running their own, which most will probably use. (Think how Google runs the Play Store, but others can run Android app stores too. It's just that this will be far more open than that.)
Patching out code is something that's easy to do in anything while it's centralised. That's why you get do doing things like adding in a license checking macro in various places in many desktop apps: if you remove this check, that one may well still be there.
Just because it's in an ostensibly human-readable language doesn't mean it's human-readable or easily modifiable.
Patching out code is something that's easy to do in anything while it's centralised. That's why you get do doing things like adding in a license checking macro in various places in many desktop apps: if you remove this check, that one may well still be there.
Just because it's in an ostensibly human-readable language doesn't mean it's human-readable or easily modifiable.
>> Libraries and services to manage this will appear. Mozilla are running their own, which most will probably use. (Think how Google runs the Play Store, but others can run Android app stores too. It's just that this will be far more open than that.)
It's an important point and outlines the differences in Mozilla's approach. The same applies for Mozilla Persona. The cost of openness is building a system that's loosely coupled and then adding the glue afterwards to make it easy for many.
It's quite the opposite of closed systems and you have to see the longer term vision to understand why Mozilla starts out with this type of solution.
@chrismorgan, it might go a long way to include the plans for a "hosted" version of the open model as a convenience layer. Most won't make that leap themselves.
It's an important point and outlines the differences in Mozilla's approach. The same applies for Mozilla Persona. The cost of openness is building a system that's loosely coupled and then adding the glue afterwards to make it easy for many.
It's quite the opposite of closed systems and you have to see the longer term vision to understand why Mozilla starts out with this type of solution.
@chrismorgan, it might go a long way to include the plans for a "hosted" version of the open model as a convenience layer. Most won't make that leap themselves.
My tentative design for the FFOS app I'm working on is to have only the rendering code delivered; the rest is requests out to my web server, which then frontends all the interesting stuff. In other words, it's going to effectively be a web page with some strange Javascript.
That's an interesting solution. I wonder how delivering an entire application on launch will affect load times, speed, bandwidth usage, etc.
Honestly, I don't think it's going to be a problem... the magic is all going to happen on the backend: the frontend is going to be (relatively) simple code. Essentially just enough to call out to the backend and render the results. The entire thingie is going to be simple.
I'm not sure how Mozilla is going to handle users, etc, and how I can get that information transferred into my system so that users can get into their account from a regular web browser as well as the web app from their device. I need to figure that out, but I'm not there yet. The sales & user accounting systems are probably going to be 3-5x more troublesome than the actual program.
I'm not sure how Mozilla is going to handle users, etc, and how I can get that information transferred into my system so that users can get into their account from a regular web browser as well as the web app from their device. I need to figure that out, but I'm not there yet. The sales & user accounting systems are probably going to be 3-5x more troublesome than the actual program.
Mozilla Persona will be baked into FirefoxOS and the FirefoxOS Marketplace, thus it probably makes sense to use it for your regular browser users, too. https://login.persona.org/
I don't think the Content Security Policy for standalone Firefox OS apps allows that. I think it is all or nothing; you are either a packaged and self-contained 'privileged' app, or you are a web app that is loaded from the web.
You can use CORS in a packaged app to talk to your own web service http://en.wikipedia.org/wiki/Cross-origin_resource_sharing or you need XHR permissions such as
"permissions": { "systemXHR": {} }
https://developer.mozilla.org/en-US/docs/Apps/App_permission... Some info
"permissions": { "systemXHR": {} }
https://developer.mozilla.org/en-US/docs/Apps/App_permission... Some info
The way pnathan described his app, systemXHR doesn't seem to make sense for it. You usually only need systemXHR when you are writing an app that talks to a third-party server that you cannot control and that you cannot convince to enable CORS. systemXHR also has different handling of cookies and HTTP authentication credentials.
Yes, but you cannot load external scripts. Only content or XHR. I thought the OP was talking about loading code over the network.
It'll be a web app loaded from the web.
Assuming you're not gong the freemium route on iOS of course.
I've just finished writing a receipt checking web service for iAP receipts – in JS nonetheless :)
I've just finished writing a receipt checking web service for iAP receipts – in JS nonetheless :)
This is pretty exciting. Being able to have an open marketplace without lockdown is... erm... well. It's a refreshing change from the iOS land and I hope to see more in this direction.
At any rate, I am starting up a project that I am hoping to sell on the FF Marketplace. It's going to be a trip (never done app development before!).
At any rate, I am starting up a project that I am hoping to sell on the FF Marketplace. It's going to be a trip (never done app development before!).
I definitely appreciate the portability and open standards that seem to be at the core of this product. My startup also runs an app store like product and we decided to focus mostly on web for these same reasons. Portability and open standards are amazing assets that we are not willing to give up and I'm REALLY interested in the process and approach Mozilla is taking to use the same benefits in the mobile market. Mozilla is on the comeback! Watch out tech giants!
I think the open web-applied to smartphones-will be what the entire smartphone market eventually arrives at. Mozilla is playing the long game and doing a lot of extra work and will go through a lot of issues that they wouldn't if they made another walled garden OS and marketplace. One of the reasons that the web is so popular for developing apps is its openness and prevalence. The more momentum firefox OS builds, the more pressure will be put on other phone OS ecosystems to follow suit, especially if you can use firefox within other ecosystems and it integrates well with their marketplace and apis. When that happens, it will be increasingly hard to justify creating a device specific app when you can cover every device with one webapp.
This will be an exciting project to watch.
This will be an exciting project to watch.
An interesting link buried in the article:
http://www.macworld.com/article/1167677/hacker_exploits_ios_...
Does anyone know if Apple has addressed this yet?
In any case, it will be interesting to see if Mozilla can pull this off. When I download an app, isn't it just Javascript? What's to stop me from just diving into the app's source and putting in `function is_this_a_valid_app() { return "yep"; }` ?
http://www.macworld.com/article/1167677/hacker_exploits_ios_...
Does anyone know if Apple has addressed this yet?
In any case, it will be interesting to see if Mozilla can pull this off. When I download an app, isn't it just Javascript? What's to stop me from just diving into the app's source and putting in `function is_this_a_valid_app() { return "yep"; }` ?
That is an old one.
The one concern for app developers on the FirefoxOS will be protecting their code. If its trivial to reverse an Android app and use that code it will be even easier to do it on FirefoxOS. So because of that most apps will be webapps and not native apps. The downside is you will need an always on network connection.
Validating and enforcing in-app purchases will not be a problem on Firefox OS if its a web app. Of course it can be trivially circumvented in native apps. More reason why I expect only webapps on that OS.
The one concern for app developers on the FirefoxOS will be protecting their code. If its trivial to reverse an Android app and use that code it will be even easier to do it on FirefoxOS. So because of that most apps will be webapps and not native apps. The downside is you will need an always on network connection.
Validating and enforcing in-app purchases will not be a problem on Firefox OS if its a web app. Of course it can be trivially circumvented in native apps. More reason why I expect only webapps on that OS.
You also need an "always on" network to verify paid iOS or Android apps. They use web services for verification.
Apple has fixed "exploits" for iOS free stuff every single version they've released. If Mozilla becomes big the same thing will happen, and more of it. Apple stuff is compiled and at least sort of encrypted. Mozilla stuff is pretty much free game.
Counterpoint (with no particular value): encryption standards are publicly visible; does that make them less secure than proprietary and concealed encryption techniques?
No. Proprietary techniques and algorithms are a bit harder to find out but are then usually just as fragile or secure as their open (source) counterparts. History has proven this over and over again.
I would have to say yes. It's a lot easier to break something that is has the code/methods available then play the hex guessing game.
But having an application which is 100% HTML/JS/CSS/Interest other scripting language here. Without any ability to opcache or byte code it and encrypt it. It's not going to take much to crack it.
If they somehow found a way to compress+encrypt the HTML/JS they may be able to make it at least a little bit more challenging. But that would take a lot of effort.
But having an application which is 100% HTML/JS/CSS/Interest other scripting language here. Without any ability to opcache or byte code it and encrypt it. It's not going to take much to crack it.
If they somehow found a way to compress+encrypt the HTML/JS they may be able to make it at least a little bit more challenging. But that would take a lot of effort.
The likes of Java can be decompiled just as successfully as JavaScript.
Minification and obfuscation are quite common for web apps already. It's done for current phone apps, and it will be done for the new breed of web apps in just the same way.
Minification and obfuscation are quite common for web apps already. It's done for current phone apps, and it will be done for the new breed of web apps in just the same way.
Without any ability to opcache or byte code it and encrypt it. It's not going to take much to crack it.
You think bytecode is difficult to crack? :-)
One thing you can do is compile your JavaScript code to asm.js. That is low level enough to make things pretty difficult to reverse.
Until Hex-Rays Decompiler for asm.js comes out of course :-)
You think bytecode is difficult to crack? :-)
One thing you can do is compile your JavaScript code to asm.js. That is low level enough to make things pretty difficult to reverse.
Until Hex-Rays Decompiler for asm.js comes out of course :-)
I want to like Mozilla, really, but why do they seem unable to put out a press release that doesn't contain gratuitous lies or misinformation? (The last Mozilla PR release I read was also misleading: http://news.ycombinator.com/item?id=5128924 ).
there is a key difference: it does not lock you into Mozilla or lock you into your Firefox OS phone
How is this true in any meaningful way? I look down this list of APIs: https://wiki.mozilla.org/WebAPI and I see many many things that are FirefoxOS only, and are not planned to be made available for other platforms.
If they want to say that FirefoxOS can display 'standards compliant' web pages then yes, great, but so can every other OS to some degree (web 'standards' are a moving target and Chrome and Safari have broadly comparable standards compliance).
If FirefoxOS is to be truly standards compliant that means it will be unable to do a single thing that other platforms can't also do in their respective standards compliant web browsers (and if no other browser implements it then it's not much of a standard). So where is the additional value from FirefoxOS? It's just an OS that is by definition less functional than every other OS.
Before anybody chimes in pointing out all the misleading PR from Apple and Google and Microsoft, yes I'm aware of that, but they are for profit companies and don't claim to be working for the betterment of mankind. If to compete with them you also have to coat everything in a glaze of PR bullshit then how are you any better than them, other than that your bullshit has a slightly different consistency that makes it easier to swallow for some people.
there is a key difference: it does not lock you into Mozilla or lock you into your Firefox OS phone
How is this true in any meaningful way? I look down this list of APIs: https://wiki.mozilla.org/WebAPI and I see many many things that are FirefoxOS only, and are not planned to be made available for other platforms.
If they want to say that FirefoxOS can display 'standards compliant' web pages then yes, great, but so can every other OS to some degree (web 'standards' are a moving target and Chrome and Safari have broadly comparable standards compliance).
If FirefoxOS is to be truly standards compliant that means it will be unable to do a single thing that other platforms can't also do in their respective standards compliant web browsers (and if no other browser implements it then it's not much of a standard). So where is the additional value from FirefoxOS? It's just an OS that is by definition less functional than every other OS.
Before anybody chimes in pointing out all the misleading PR from Apple and Google and Microsoft, yes I'm aware of that, but they are for profit companies and don't claim to be working for the betterment of mankind. If to compete with them you also have to coat everything in a glaze of PR bullshit then how are you any better than them, other than that your bullshit has a slightly different consistency that makes it easier to swallow for some people.
I think it's a fair argument to say that one is locked into Mozilla today with our receipt protocol. However, we've designed it from the ground up to work in a decentralized manner so that other marketplaces can participate. This is the exact opposite of iOS (and to an extend, Android) where the business model relies on some premise that the customer will be locked into the platform at the minute she makes a purchase.
The point of this article was to start getting others to help us make it work for them. There is a chicken/egg problem so someone has to start somewhere.
Compare this to Chrome OS; they have not made an effort at creating a decentralized receipt format. To validate a paid app your only option is to talk to Google's web service. https://developers.google.com/chrome/web-store/docs/check_fo...
The point of this article was to start getting others to help us make it work for them. There is a chicken/egg problem so someone has to start somewhere.
Compare this to Chrome OS; they have not made an effort at creating a decentralized receipt format. To validate a paid app your only option is to talk to Google's web service. https://developers.google.com/chrome/web-store/docs/check_fo...
Easy there killer, not all API's are going to be flushed out full W3C recommendations for v1. These things take time. Be patient. There is nothing on that page that suggests any of the WebAPIs "are not planned to be made available for other platforms." In fact, under process it says "The goal is to standardize all APIs."
Also, Samsung has been contributing patches to WebKit for Tizen such as Battery Status, Network Info, Vibration, and more. So the implementation and standardization process is well on its way.
Finally, more app support for my WebOS devices!
That wasn't sarcasm, I'm legitimately excited.
That wasn't sarcasm, I'm legitimately excited.
I feel like Enyo, and WebOS itself, are really under-appreciated. I've built a few apps with Enyo, and it's an absolute treat to use.
Plus, WebOS is still here -- I almost feel like people are actively ignoring it: trying to sweep it under the rug whenever its mentioned. Truthfully, I'll be sad if Firefox OS gains traction, because WebOS did all of this years ago.
Plus, WebOS is still here -- I almost feel like people are actively ignoring it: trying to sweep it under the rug whenever its mentioned. Truthfully, I'll be sad if Firefox OS gains traction, because WebOS did all of this years ago.
Well, WebOS did it in secret and built their own walled garden of "web" APIs, sadly. That may or may not be why it never got traction. Either way, if you built a WebOS app then it won't run anywhere else today. With Firefox OS, Mozilla at least has used standard HTML5 everywhere that it made sense to. Granted, WebOS began its design a long time ago in web years.
> Either way, if you built a WebOS app then it won't run anywhere else today.
That's not very true. Any HTML5/JS app built for WebOS 3.0+ (when Mojo was depreciated, and Enyo brought in) can run in any browser; if it uses WebOS-specific API calls (most often used for notifications), then it can be wrapped in PhoneGap/Cordova and compiled for nearly any OS.
That's not very true. Any HTML5/JS app built for WebOS 3.0+ (when Mojo was depreciated, and Enyo brought in) can run in any browser; if it uses WebOS-specific API calls (most often used for notifications), then it can be wrapped in PhoneGap/Cordova and compiled for nearly any OS.
Correct. Now you have a PhoneGab app not a WebOS app :)
How hard is it to transition an add on for Firefox to an app for Firefox os?
For iOS: write an app, set a price, release it. For at least 90+% of potential customers, they have to pay for it. Piracy requires modifying the device in a way that Apple blocks.
For Android: write an app, set a price, release it. Anyone can easily pirate it, but it's still easiest to buy it instead.
For Firefox OS: write an app, set a price... then write a web service to do receipt checking? Integrate a library to verify purchases? That's a lot of critical code I now have to maintain, and is easy to get wrong. And my app now depends on having a server available (either mine or, it seems, a third party) to verify. And, of course, it's all JavaScript: patching it out is trivial for piracy.
I guess it's more "open" or something, but it just seems like more work for the same result.