01-29-2014 10:18 AM
I don't think very many devs would run into a problem with this... it would only show up if someone wanted to untangle their signing key from their BBID, which I doubt happens very often. This is very likely just a misunderstanding on my part, but since I already had a key when they brought in the BBID thing, and I didn't see any benefit to linking it to my BBID, other than one less password to remember, I just left things the way they were.
Thinking about this logically I don't see how it can be as we would have heard thousands of developers screaming about their updates by now.
However there is still the possibility of a third step that binds that key to the bb id permanently so worth finding out if the bb id can be changed.
01-29-2014 11:01 AM
There are a few questions in this thread, hopefully this answers them all.
01-29-2014 12:01 PM
Thanks for clarifying Mark. It seems to work about the way I thought it did and I think I'll leave my signing key unbound.
Your description brings up another question though, inspired by recent events in the Chrome plugin world. Apparently the ad-injection brigade is buying up the ownership of successful (by install count) but unprofitable Chrome extensions, then modifying them quietly with injection logic and posting upgrades for unsuspecting users. This kind of unscrupulous behaviour notwithstanding, how would one go about selling ownership of an app to a third party?
It seems to me you would need for each app you develop to have its own signing key so you could transfer the key without losing access to all your other apps, but I'm not sure about the Author ID. Would changing the ID break the upgrade path for the application on BB World? Is this even possible? Would you need to use a different Author ID for each app you create so you can transfer that with the app if you sell it?
Of course, the other big issue is if the new owner would be able to move the app to their vendor portal and have it identified as the same app by BB World. I'm sure there is no way to do this from the portal, but perhaps BlackBerry could do this manually?
Just curious at this point, I'm trying to understand how BB World uniquely identifies an application for the purposes of upgrades?
01-29-2014 01:06 PM
Quick note that Package-Id is made from Package-Name and Package-Author-Id (which is tied to your signing account).
BlackBerry World doesn't allow a BAR file with the same Package-Id to be uploaded to multiple vendor accounts. Package-Id is also what the OS uses to determine if the application is new or an upgrade. If the Package-Id matches an application already installed, it's considered an upgrade.
That means they'd have to change Package-Name or Package-Author-Id to add the BAR file to their vendor account. Likely they'd change Package-Author-Id since you likely wouldn't sell your code signing keys with the app. I have seen situations where this gets messy when a customer hires someone to build their app and then uses a different vendor to update it. This article explains the best practice to follow for that scenario that protects both parties: BlackBerry 10 Code Signing Guide for Contractors with Multiple Clients
01-29-2014 04:53 PM
Thanks Mark, that's just the kind of article I wanted to see. Unfortunately it doesn't really provide a way to set this up so an app can be sold later to a third party. Given the limitations imposed by BlackBerry, the only way I can think of to transfer ownership of an app so that old purchasers will switch over to the new version is to publish an update using the old keys and vendor account that does nothing else except open BB World at the new owner's app page so the user can install the new version. Unfortunately any app settings would be lost along the way. Perhaps the old and new apps could transfer this data somehow, but sandboxing would prevent them from doing it automatically. If it was a paid app (up front, not in-app) then installing the new app without paying for it again would be very tricky.
I actually have come to believe that the whole debug token / signing key philosophy wasn't very well thought out before it was implemented. I applaud how difficult it would be for anyone to disperse a fraudulent upgrade without the user's knowledge, but the fact that once you have more than one app signed with a single key they can never be severed to sell off one without the other smacks of lack of foresight by BlackBerry to me.
As a long-time contract developer I also believe all those cases of contractors leaving a company with the signing keys and passwords you mentioned almost inevitable. Companies changes names. They change ownership. They sell products and IP to other companies. The current signing key system on BB World makes all those things either impossible, or at least much more difficult than they should be.
01-30-2014 01:01 PM
You're right in that the current system doesn't easily allow for apps to be sold. That's something for us to think about. The old app opening a link to the new app to download and then transfer settings would work, but is kind of messy for the user.
Company name changes are accommodated though. To change that all you need to do is create a new Developer Certificate (author.p12) with the new company name. That won't affect your upgrade path like changing the signing key does.