Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

BlackBerry® World™ Development

Reply
Contributor
Posts: 13
Registered: ‎02-20-2010
My Device: Bold 9700
My Carrier: Rogers

Licensing: Negative Confirmation ala Podtrapper

Hey Guys,

  Does anyone have any experience with the "negative confirmation" approach to app licensing that Marcus the Podtrapper developer refers to in this article:

 

ORIGINAL ARTICLE

 

I'm intrigued by the idea, but I'm left to my own imagination as to how something like this would work.

 

Some thoughts of the top of my head:

 

- The way it works is the App is compiled in such a way that it will normally be fully functional.

- When someone buys the app from app world, the message from App World to the license server contains the email address of the purchaser, which the license server logs.

- On some periodic basis the App will send a message on the network back to the license server to say "Hey, MyCoolApp is running on a phone connected with this email address <insert email>, and it happens to be running on a device with PIN X.... oh and by the way, while we're at it here's some other useful information (e.g., OS version)."

- The license server logs this info, and looks up the email address to see if it is associated with a paid subscriber.  If it is, and responds "Hey, cool.  Keep on truckin' MyCoolApp."  If its NOT a paid subscriber the server says "Alert, you are not a paid version of the App, disable any of the cool functionality and warn the user they are in Trial mode"... some some variation of that.

 

As usual, the devil is in the details.  I'm wondering what some of those details are?

 

-If my app is not a network dependent app, then all someone woudl need to do to run my app would be to not give it permission to use the network, in which case it can't successfully contact home base, and ultimately be deactivated.  Is there any way around this?  NOTE: I am awre that if I'm selling a little 2.99 app its not worth actively defending my IP any more than this.

-Maybe I could allow for N connection attempts to fail, at which point the App would say "Hi, sorry to bother you, I just need a brief moment on the network to contact the license server, and I promise I won't use much data", and otherwise de-activate.  Woudl this be acceptable?

-Any other finer points I should consider?  Anyone else trying this model out?  If we can get some good discussion going I'd be open to sharing some sort of licensing library as an open source effort.

Contributor
Posts: 13
Registered: ‎02-20-2010
My Device: Bold 9700
My Carrier: Rogers

Re: Licensing: Negative Confirmation ala Podtrapper

So, initially I thought the benefit of "negative confirmation" was in the case of switching devices, but I just realized I can have my license hash on email address, so when a user switches devices their license will still work?  Is my thinking somehow flawed?

 

Stu

Developer
Posts: 76
Registered: ‎03-15-2010
My Device: 9800, 9630
My Carrier: Rogers

Re: Licensing: Negative Confirmation ala Podtrapper

 


sadohert wrote:

So, initially I thought the benefit of "negative confirmation" was in the case of switching devices, but I just realized I can have my license hash on email address, so when a user switches devices their license will still work?  Is my thinking somehow flawed?

 

Stu


 

A potential issue I see here is that the EMail address of the phone does not necessarily have anything to do with the user's paypal email which they have registered in App World. Also, it seems quite a few users do not have a default email addresses configured on their phone and a request for the email address returns "NONE".

 

I don't really see how keying on the email address could be better than using the PIN? App World has built in functionality to handle if someone changes devices. Sometimes, it even works Smiley Wink

New Developer
Posts: 11
Registered: ‎11-13-2008
My Device: Not Specified

Re: Licensing: Negative Confirmation ala Podtrapper

So here are my thoughts, just from what I've been doing with PodTrapper (and kind of a brain dump, sorry)

 

- A design goal for mine: the app can never stop working because my server is down (don't want people who paid for my app to lose access if I decided to stop writing apps or get hit by a bus). This means that if a user successfully blocks the network on their end, my check is out of luck. This makes it less appealing for non-network centric apps which would be easily blockable at the beginning.

- Using an email for the code is problematic, for reasons outlined in the post above, but also for the sharing/guessing factor. (Unless you're detecting it on the phone, which isn't reliable and can change)

- For my keys I take a random set of hex digits of arbitrary length, then MD5 hash it with a known secret string. I interweve the original hex digits with portions of the resultant MD5 as the final 'key'. This way the app can check it without needing a list or similar, but there's no way to reverse it without decompiling and finding my secret string (and there are ways to hide it there as well).

- My mechanism is really only protecting me against casual copying, there are seriously hardcore people out there who crack stuff for fun. I'll never block everyone, or if I could, I'd be hurting more paying customers than pirates with it. (See: Ubisoft)

 

Those are the only thoughts I have at the moment, but if you have any questions feel free to ask and jog my memory Smiley Happy

 

-Marcus

Contributor
Posts: 13
Registered: ‎02-20-2010
My Device: Bold 9700
My Carrier: Rogers

Re: Licensing: Negative Confirmation ala Podtrapper

 

Thanks for the thoughts guys.

lcamobile wrote:

 

I don't really see how keying on the email address could be better than using the PIN? App World has built in functionality to handle if someone changes devices. Sometimes, it even works Smiley Wink


 

So Marcus, do you remember the main issue that motivated you to move towards negative confirmation?  Was it that App Worlds device change handling didn't always work,and  other App stores had no way of helping your customers switch devices at all?

 

As for the random set of Hex digits+ hash.  Am I correct that this is something you do on your license *server*.  App World sends your server a license request, you do the hashing/string/etc. thing and return that number to them, which gets put into the decice.

 

 Now that I think about it some more, it seems like other benefits of that approach are:

-No code that actually does the hashing exists in the App.  Maybe crackers can find these sections of code and reverse engineer easier, as opposed to negative-confirmation licensing where they either

a) need to find a particular users license code and steal it, in which case the server isn't going to start letting 1000s of devices run using the same key when that cracker goes to distribute your app, or

b) figure out your hash scheme themselves, although their still not going to be able to pass this informaiton around to 1000s of would-be theifs, becuase your server is still the gateway to a valid license (i.e. they can figure out your license algorithm, but there's no way for them to cram a license into a server *you* control.

 

Bottom line I'm making a $3-5 piece of software, so I know I don't need to go to crazy lengths, just curious about the ins and outs of this approach.

 

Highlighted
New Developer
Posts: 11
Registered: ‎11-13-2008
My Device: Not Specified

Re: Licensing: Negative Confirmation ala Podtrapper

 

do you remember the main issue that motivated you to move towards negative confirmation?  Was it that App Worlds device change handling didn't always work,and  other App stores had no way of helping your customers switch devices at all?

Well, the app world does have a lot of issues, but even without them, and assuming every store's app switcher works properly, people still don't know about them. They load up the app on their new phone, and if it's tied to the PIN it'll tell them it's invalid. At that point they need to know to go to the app store and switch it, but many don't. I found I was spending > 50% of my support email time dealing with registration code switching issues.

As for the random set of Hex digits+ hash.  Am I correct that this is something you do on your license *server*.  App World sends your server a license request, you do the hashing/string/etc. thing and return that number to them, which gets put into the decice.

Yes, but in my case both the app and the device check it. I could add a third layer to the hash that only the server knows, so the device side could never be reverse engineered, which would be a good step, but not something I've thought about. In my case the device is the first line of defense, and the negative confirmation step is not necessarily to catch keys I've never issued (which in my case is hard because from the get-go I wasn't properly tracking them), rather to prevent putting the same key on multiple devices.

 

-Marcus