5 ms·

Counterpoint: as a developer, this looks awful. For iOS: write an app, set a price, release it. For at least 90+% of potential customers, they have to pay for

by Xuzz 14y ago

Counterpoint: as a developer, this looks awful. 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.

pnathan 14y ago
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.
- dubcanada 14y ago
  That's an interesting solution. I wonder how delivering an entire application on launch will affect load times, speed, bandwidth usage, etc.
  - pnathan 14y ago
    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.
    - callahad 14y ago
      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/ https://login.persona.org/
- st3fan 14y ago
  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.
  - kumar303 14y ago
    You can use CORS in a packaged app to talk to your own web service http://en.wikipedia.org/wiki/Cross-origin_resource_sharing 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_permissions https://developer.mozilla.org/en-US/docs/Apps/App_permission... Some info
    - st3fan 14y ago
      Yes, but you cannot load external scripts. Only content or XHR. I thought the OP was talking about loading code over the network.
    - briansmith 14y ago
      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.
  - pnathan 14y ago
    It'll be a web app loaded from the web.
kumar303 14y ago
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.
- st3fan 14y ago
  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.
  - rajivm 14y ago
    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.html 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).
- dubcanada 14y ago
  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.
chrismorgan 14y ago
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.
- jmathai 14y ago
  >> 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.
coob 14y ago
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 :)

by Xuzz 14y ago

pnathan 14y ago

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.

dubcanada 14y ago
That's an interesting solution. I wonder how delivering an entire application on launch will affect load times, speed, bandwidth usage, etc.
- pnathan 14y ago
  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.
  - callahad 14y ago
    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/ https://login.persona.org/
st3fan 14y ago
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.
- kumar303 14y ago
  You can use CORS in a packaged app to talk to your own web service http://en.wikipedia.org/wiki/Cross-origin_resource_sharing 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_permissions https://developer.mozilla.org/en-US/docs/Apps/App_permission... Some info
  - st3fan 14y ago
    Yes, but you cannot load external scripts. Only content or XHR. I thought the OP was talking about loading code over the network.
  - briansmith 14y ago
    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.
- pnathan 14y ago
  It'll be a web app loaded from the web.

kumar303 14y ago

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.

st3fan 14y ago
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.
- rajivm 14y ago
  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.html 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).
dubcanada 14y ago
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.

chrismorgan 14y ago

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.

jmathai 14y ago
>> 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.

coob 14y ago

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