Activation ... continued - (Machine Binding)
Hello again.
As promised I want to pick up this blog from the ‘Activation’ path we’re already going down. In a sense, activation is almost the middle of the software delivery chain in my view of the world. Incidentally my view of the world is shaped by many inputs: Microsoft’s licensing experience, deep interaction with customers that depend on licensing to help them run their business and some of the great accomplishments of all those individuals and companies that are out there doing business today.
Activation first enters the picture somewhere between the distribution of your software solution and the sale. The details of what activation means to your business should be well-defined before this point. From a life-cycle perspective this is where you begin to customize the end-user’s experience. The questions you should be asking are; “What controls do I have at this point?” and “How should I apply them?” At one level, there’s no easy answer. Besides a complete answer must include a good understanding of the business dynamics you are attempting to influence and how you will use an activation model to take your business in the direction you want to go.
Then there’s another level – the technical level that digs deeper into how activation works. That is where I am taking this blog today.
Activation models number in the thousands. But in the end analysis they all have a few things in common. One of the most controversial, but necessary functions of activation is the concept of binding. Binding occupies the base of the activation model at the technical level. Because many other operations in binding and licensing (the business dynamics) depend on the binding method used. It's no accident the method used to bind the license will typically be considered a fundamental business decision as well as a technical implementation. The most common method of binding to use for activation is machine binding. Machine binding has been around for decades. It has evolved to a state where it is today because there’s been no better option in the PC world. (Although it is worth mentioning that there has been no lack of trying: http://www.cdt.org/privacy/issues/pentium3/). Some of the other licensing models include binding to specific users, user pools, credentials, specific hardware devices, and some combinations thereof. By and large, machine binding is the most prevalent form of binding today. It is not uncommon to see some implementation of machine binding in every model of licensing.
Business imperatives have established machine binding as a crucial component of activation. This is because there must be something to activate against that can be readily validated. It wouldn’t be useful from an enforcement point of view to permit activations that bind to nothing. On the-other-hand, privacy considerations are real-world issues that require careful contemplation by each one of us and the industry as a whole. (Binding with personally identifiable information is another topic for another day.)
Machine binding, in the state it is in today, has an entire host of problems that range from the strictly technical to the more practical problems that revolve around user behavior. We’ll be looking in depth at the technical component today.
To bind a license to a machine, there’s an intrinsic need to derive a ‘fingerprint’ of the machine. This fingerprint should be unique – to a degree. This requirement almost always requires selecting machine-level constants that can be added to an algorithm. The goal is for this algorithm and the choice of constants to reliably reproduce the same result over a period of time. The fingerprint that results from this initial calculation, will be stored somewhere and used by some component of the licensing system to determine if a software license is permitted to run on the specified machine.
Almost all machine binding solutions today use some form of this approach to correlate licenses with a particular machine. The good thing is that everyone is doing it. The not-so-good thing is that everyone is doing it just a little differently and having very different experiences. One software publisher told me that this was the worst part of his job.
We’ll see why that is in a moment.
One of the challenges of machine binding is the fact that there is no standard for hardware manufactures to apply when they ‘ID’ their hardware. Even if there was, the hardware supply chains are so complex it is doubtful that the hardware vendors they contract with could apply the standard consistently or in a reasonable time-frame. Then there’s the matter of which hardware components to choose. At some point, you have to feed your algorithm the constants you will use to calculate the fingerprint. If the constants you choose fail to give you anything useful, then the fingerprint will become less unique – but not necessarily useless. So nearly everyone mixes something else into the formula to make the fingerprint a little ‘wider’ so all future comparison can be more reliable.
The initial fingerprint is then used as a constant to evaluate drift. Drift is the natural evolution of a machine’s hardware state. Hard drives fail and get replaced. Hardware upgrades are common these days. Hardware additions are a necessity for many popular applications. Components are replaced more frequently as machines become more reliable. Even if the physical hardware remains the same, it is quite common for a firmware update to change the identifiers for a hardware component. The result is that the fingerprint will change over time. This drift is used in the evaluation process that determines tolerance. Tolerance is the answer to the following questions:
• What will be allowed to change without invalidating the machine_ID (or device ID) binding?
• What can’t change without invalidating the machine_ ID binding?
• How many times can allowable things change without invalidating the machine_ ID binding?
• How many times within a certain interval can things change without invalidating the binding?
And there are at least a half-dozen other rules that are applied generically. In addition, certain publishers have even more constraints and conditions they choose to apply to the tolerance algorithm.
For nearly every rule in the tolerance algorithm you will be able to find real-world scenarios where the rule has adverse consequences. For instance, a rule or set of rules may cause the binding to be declared invalid where such a declaration isn’t warranted. This is certain to result in the wrong customer experience. It is not uncommon for such a rule to have severe consequences that range from angry customers to public outrage. Just as often is the case where the rule is too ‘lax’ and it enables something to be activated that shouldn’t be.
It’s important to recognize that the rule itself may be fundamentally solid, but then the rule must somehow negotiate with all the other rules and this in itself it very difficult to ‘get right.’ It's also a common technique to give more weight to one rule over another.
When you add in the earlier reviewed problem of unreliable constants (hardware IDs), then the combinations become incredibly complex.
If you hear of someone that has solved this problem, you are probably hearing part of the truth. What has happened it they have the right technical solution in place for their situation. However, there’s also another variable in there that isn’t as apparent but perhaps is the most critical. There’s the issue of enforcement tolerance. Enforcement tolerance is the level of pain you are willing to endure yourself or to put your customers through. The pain is somewhat governed by the behaviors of your user base. This is balanced with other business factors such as, how much revenue might be lost if the machine binding is relaxed and too many casual users are not activating within the business scenarios you have defined. Reducing the enforcement tolerance means a tighter machine binding, which is certain to inconvenience legitimate users after a certain threshold. Increasing the enforcement tolerance will result in the proliferation of users that are successfully activating below the threshold of acceptable use cases.
When we go back to what the publisher described to me was the ‘worst’ part of the job, he was speaking about getting everything in perfect harmony. For him and his team, it was a never-ending thankless job. Too harsh, and he was getting flak from support and sales. Too soft, and he was responsible for the company not being able to recover revenue. He said he learned to always err on the softer side. This ensured that support calls were kept to a minimum and he did not drive good intentioned customers away. I often hear the phrase: "Keep the honest customers honest" when the topic of enforcement comes up.
Our plan of record is to innovate in this area based upon the feedback we are hearing. One of our goals will be to ensure that our software publishers don’t have to understand exactly what’s going on under the hood to get the best possible activation experience for their products. This will require some considerable work and a fair amount of risk. We know that this is what you expect of us and we are looking forward to this challenge.
Terrence Nevins – SLPs Program Manager: (For the entire team)
