Access to Footprint IDSolved

We don't expose the "hardware fingerprint" data because it's not that useful if you don't have the algorithms used to generate it.

But, the solution to your problem is to use extra data. See: Extra activation data.

Hi,

A simple solution is simply to generate a GUID that you save somewhere (like in the registry) and then always use this GUID when communication with your API.

Best regards,Alexandre Leclerc

I need a reinstall of the software to produce the same GUID.... So I'm guessing I'll have to do something based on the hardware and computer name, etc which isn't always completely reliable. Would it be possible for you to provide a SHA-2 512 bit string of the unique footprint ID or something like that so that you are not exposing your internal footprint identifier. I completely understand not wanting to expose that as its core to your infrastructure...but is there some other secure way of providing a variant on that data that is still unique?

Would it be possible for you to provide a SHA-2 512 bit string of the unique footprint ID or something like that so that you are not exposing your internal footprint identifier.

No because the hash could be different and the computer could be the same (see: fuzzy matching).

We could generate a GUID for the activation, so even if there's a fuzzy change the GUID would remain the same. However there's a downside to this. Namely, the GUID would be different if:

1. A user deactivated and then activated on the same computer.
2. A user activated a separate product of yours that uses TurboActivate. That is, the GUIDs for the activations of the 2 separate products on the same computer wouldn't match.

Tell me your thoughts.

Hi Sam,

I was thinking of the same solution as you describe. Creating a GUID upon activation, managed by and on LimeLM servers.

As for the activate / deactivate problem, it could probably be solved if the activation Key is the same. If the GUID is based on Key + PC, and the GUID is not deleted until the key itself is deleted, well, you can send the same GUID for the same Key + PC activation.

This could potentially generate some garbage (old GUID) but with a nice garbage collector it would not be that bad (i.e. GUID could be deleted if no server check has been made for this Key + PC for a given amount of time, like 6 months or 1 year).

I think problem 2 would not be a problem but more a feature. At least, the developer could decide which GUID to use if he wanted to only use one for both software (like by asking the API if any of the GUID is already in use and if yes, use that one).

Best regards,Alexandre Leclerc

This would work very well for me to have it be on activation and stored on LimeLM's servers and accessible through the TurboActivate API or even the LimeLM Web API. It would also be the perfect scenario for me to have it based on KEY + PC. My likely install scenario is where users are going to install the software on a leased laptop, use it for a single day, possibly two and then return the computer (software deactivated) and then the next month they lease another laptop for a day or two and reactivate using the same KEY, but a different PC so I would want it treated as a new GUID.

Any further thoughts on this?

I am in real need of this GUID (KEY + PC), I have no problem generating the GUID myself, but I have no access to the PC data. This is critical for me as I am looking to get this built into my product in the next week......so I just need to establish a path forward. Thanks for all of your support on these types of items, maybe this could be of use to other LimeLM users too!

Well, you have a couple of options. Have 1 product key per machine / per user. This way the unique GUID represents a single machine/user.

The alternative is to use the activation ID (you can get this using the web API), which functions exactly like what I suggested a couple of posts above (stupid me, I should've noticed it when I was writing it). Namely, the activation ID stays the same even if the user reactivates (even if the computer only "fuzzy matches" itself). However if the user deactivates then activates again a new activation ID is generated (even if the computer is identical).

Regarding the caching of hardware ID's for an indefinite length of time, as Alexandre suggested, is not an easy thing to implement well (we can implement it poorly in an hour).

Plus, we're still not sure why our customers would find this data useful outside of the licensing context. That is, TurboActivate, TurboFloat, and LimeLM already handle the licensing bits an the necessary "fingerprinting" of computers. But why would you need a unique ID of a computer? Is it just a "nice to have feature" or is there something critical that depends on this?

It's necessary for my application, but now that you mention it, I will do a license key per installation (1 activation per key) on a computer. My install scenario is that the software will be used on a borrowed computer for a day and my application publishes data to the cloud so I need to keep track of the last publish event by computer. So I will assign a license key per installation and use that as my unique installation id.

Thanks for all the great suggestions everyone, this is going to work really good for me.