Hacker News Reader

Comment by Xuzz | Hacker News Reader

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.

View on HN

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.

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?

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.

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.

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

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.

>> 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.

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.

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

Yes, but you cannot load external scripts. Only content or XHR. I thought the OP was talking about loading code over the network.

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.

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

Reply on news.ycombinator.com