11-06-2009 12:19 PM
I'm a new BlackBerry Developer and have some questions regarding the various licensing models outlined in DB-00761 and DB-00757. Is there an API associated with creating these models? From What is written, it is unclear to me how the anything but the Static License model would work.
With the Static license model, there isn't a license key, so I ASSUME that APP World simply controls access to the model by ensuring that the fee is paid before allowing download and installation. With this model, a user could potentially copy the application from one device to another and not pay a second fee. I know this is possible, my question here is if this is realistic and worth my time defending?
For the models that require a key it is unclear to me how the keys are used. Do I need to provide the code in the application that will unlock the application?, . . .which requires that the key is stored on the device and checked each time that it is the correct code? If that is the case, does App World place the key on the device and all I need to do is check that it exists?
Or do I need to provide an entry field in my app for the user to enter the key? Which presents the problem of being able to independently validate the key with BlackBerry before unlocking the device? I have not been able to find a API that I can look at that might answer these questions.
Using a key without some sort of validation either by the app against BlackBerry servers or by AppWorld against a list of legitimate devices presents the same problem as the static model. The once installed and given the key, the user can copy the application to another device and use the same key.
It is possible that AppWworld/BlackBerry can enforce licensing of all devices/application combinations
remotely without the inclusion of coding in my app, . . . other than to tell them what the key/keys are.
Is that the case?
If the strategy is that we give AppWorld a key, and it's up to the app developer to roll their own protection strategy, I'd like to know what those strategies might be.
Thanks for your time.
11-06-2009 03:29 PM
Piracy - if someone really wants your app, they will get it no matter what. The question is, is it worth their time trying to pirate a $2.99 - $9.99 app.. Maybe.
I don't see how a developer would know if someone is copying their applciations illegally unless it connects to their web server for functionality.
If you do the dynamic licensing model (which I recommend because you get information about the customer, email address and the blackberry), you have to host a website to generate the license key. Usually this is generated from the customer's Blackberry PIN. Since you write the code to generate the key on the web server, you have to write the code to reverse the key in your application. This means you do not have to store the key in your application--just the code to reverse it.
Do you need a screen to allow the user to input the key? It's up to you but I would say Yes. AppWorld does inject the key you generated on your web server in the JAD file and you can look this up via code in your application. If it is there and it validates, you do not have to show a screen to the user because validation is done! On the other hand, if the key is not in the JAD file for any reason (like they downloaded from a different website than AppWorld) or if the key in the.JAD file is not correct, you will have to show the screen to the user. So basically the screen will show if there's any exception with automatically trying to validate the key.
There is another solution that you can implement which would solve all of your piracy issues. You can set up your application with the dynamic licensing model only so you can get the customer's email and PIN which you will log in a database table in your web server. You generate a bogus key, maybe say, "NO KEY REQUIRED" or whatever and your application doesn't check for the key at all. Instead, it makes an HTTP request to your server with the device's PIN as a parameter and checks that table in your database to see if they made a valid purchase though AppWorld. All you have to do is send an indicator back saying YES, and you validate. Pretty simple.
This should work for all AppWorld customers because all of them have some sort of a data connection or else they couldn't download the game from AppWorld in the first place. The only time this would be an issue if you distribute your game on other web sites that offer a desktop download for people who don't have a data plan or if the customers purchases your application from AppWorld with a valid connection to the Internet but runs your application for the first time with no Internet coverage. This would prevent them from activating their new purchase. But again, most people who have Blackberries and buy from AppWorld have to have an Internet connection and will most likely be in coverage.
I hope this helps.
02-26-2010 01:38 PM
"Since you write the code to generate the key on the web server, you have to write the code to reverse the key in your application. This means you do not have to store the key in your application--just the code to reverse it."
What is the difference? To reverse, you need a key right? I'm not aware of any encryption/decryption scheme that does not use a key. Which means you are storing a key or using a key that can be accessed on the device, unless you are using keyagreement which requires a connection, and then you are back to the web service scenario. If you are using a hash algorithm, then the code for duplicating the hash is stored in the application and hence crackable.
Am I missing something?
Been wracking my brains about this, and I don't see a viable solution other than the web service. I'm thinking of using a web service but allowing the user x number of free accesses for the situations when they do not have coverage (not uncommon for me). When they do connect and verify the PIN, the free access count resets.
02-26-2010 02:00 PM
Forgive me for dribbling this out, but bottom line is that once they have the class files on their device, they can decompile and remove or replace license checking code and start sharing or selling their own copy, right? Seems like a fundamental flaw of releasing Java code into the wild.
And yes, I read your very first sentence about the juiciness of the target, but we are in this game because of the scaling potential of the internet market which means a $2.99 price tag adds up pretty quick. I am picturing cadres of developing-world programmers where their expertise, time and numbers are relatively inexpensive in comparison to the potential to capture a market for a popular application.
So I guess you just have to say, what the heck, and make your play with a reasonable, but understandably weak, license scheme. Am I out to lunch? Thanks for your patience.