LiveCode Forums.

LOL. Er... wait...

Even the better supported ones like OSX the shell doesn't always connect, for one thing.

bogs - are you finding problems with the shell command?

bogs wrote: Tue Mar 03, 2020 11:09 am @Richard - you seem to be focused on just the MB and MAC of the nic, and in the case of this OP's question that is sufficient

Being sufficient for this thread was indeed why I was focused on it in this thread.

but what Richmond, I, and all the others in the previous posting were looking for was more along the lines of what Mark figured out, how to get real information about (ALL) the real hardware on a system.

Mark's case is for licensing, which I STILL think is probably the predominant way the information is used is reason enough, but there are other test cases such as I brought up previously, like benchmarking, platform ability, compatibility, etc.

For all those and others, you can't take the least accurate view the Os itself provides, you need to know what the Os is running on.

Determining the OS and its version is already in the engine. And if the OS is misreporting other elements, that would be a bug in the OS for the OS vendor to fix, one that may be difficult for any outsider like the LC team to overcome.

I've never needed unique hardware-based identifiers (the subject of this thread), though I have frequently enjoyed having a system profile for my testers and customers (a very different topic that would make a very nice thread of its own).

So far, I've found most of the info relevant to sales and support needs obtainable with built-in features like OS version, LC engine version, screen size, free disk space, and in the old days even QuickTime version. I've considered adding RAM size to the mix, and for that I'd use shell calls, along with anything else I might dream up. There's so much code floating around in our community there's even a function in Michael Doub's Master Library for distinguishing when a laptop is running from battery or is plugged in. Lot's of options available for whatever mix of info you need.

Go ahead and submit a feature request. It takes only a minute.

But any engine request won't arrive in your hands today, while we can come up with a solution for just about any support-oriented information you'd need that aren't already in the engine (as you've demonstrated, there's a lot there already) using shell calls today.

The only thing that prevents you from enjoying the result you're looking for today is that the solution you seek would be in a script, and you've introduced the additional constraint of requiring that it be implemented specifically in the engine. For myself, I find that whenever I can avoid moving work from my desk to someone else's I get what I want exactly how I want it, and often sooner (see McConnell on the impact of communications in team workflows).

That said, from time to time I do submit requests that represent more convenience than utility-not-possible-in-scripting. But those cases are rare, and tend to be for things that most devs use every day. For example, obtaining detailed metadata about a single file has always been possible, but was cumbersome. Most of us have written functions for that so we can obtain it in a one-line call, but since nearly everyone will need that and the method for doing so may not be obvious to a new user, it seemed a useful suggestion or the team's work queue. Worked out well: it's now part of the core language.

System profiling is a different beast, in that the specific mix of info most useful to one business is likely to differ from another. Unlike file metadata, it's useful to only a smaller subset of apps, and mostly those made as part of a professional product deployment where the few minutes' work needed to script it is well worth the effort when it delivers exactly the information that particular org needs in the format that particular org finds most useful. Even if the engine provided a system profile, odds are it would require scripting to tailor its formatting for the unique needs of the organization using it - perhaps about as much time as using existing functionality to derive it would take, so not much of a savings to attempt a one-size-fits-all.

Now, you can say "Well, if you need it it is easy and you should be able to just shell out (in each instance of different Os) and get it", however it isn't that easy even to shell out on every Os. Even the better supported ones like OSX the shell doesn't always connect, for one thing.

See Mark Weider's question in the post above this one.

The other way to put that is, if it is sooooooo easy to get, why is it soooooooo hard to just include it in the language?

See Mark Weider's reply earlier, and AxWald's reply from this morning.

PS: I find myself using "just" less in recent years, because putting it in front of something I want someone else to do for me doesn't actually make it any easier, but does make it appear so. In practice I find this alters priorities in ways that fall out of sync with business needs. In the example of system profile information, it moves work from easy-and-fun scripting to much-more-expensive C++, and comes with in-perpetuity documentation, maintenance, and support encumbrances not incurred when I write a one-off for myself. I've found few cases where omitting "just" from such clauses hasn't actually improved sober evaluation of the proposition. YMMV.

One consideration is that mobile OSs do not permit shell calls.

FourthWorld wrote: Tue Mar 03, 2020 9:10 am

mtalluto wrote: Tue Mar 03, 2020 5:25 am Correct. We capture memory, graphics card, hd, motherboard, MAC address and a few other tidbits about the user.

Can you share how you obtained the motherboard ID?

I am sharing this information with the caveat that this code is not productized for other developers. We have a series of utilities that are used only in our products. So, no instructions exist. I am not trying to be elusive, but I underestimated what goes into working with the hardware information we collect. These code snippets are part of a much broader collection of libraries that support our licensing and auto-update framework. I am digging around the code, trying to pull out the most relevant portions. I am not free to provide the full libraries because it would be too much work to clean them of things we can not release.

We have plans to release this framework in completed sections for others to enjoy. To give you an idea of how much work productizing code like this can take, it took us five years to productize the database portion of the framework. I think that was the hardest part as it is the biggest. The auto-update, registration, branding, licensing, and CRM modules need the same treatment. If you follow our work, we already released the hardest parts of dealing with registration.

Going through the code reminds me that this was not a one day project. It took a lot of time to figure out. We have been perfecting this process over the years. I suppose you might conclude that it is more complicated than I previously stated. I take for granted that the APIs handle all the details. The details do exist. That said, if you do not mind putting in the effort, here are the essential parts that get the raw data. The Mac is far cleaner than what we had to do for Windows.

If WMIC fails, we have a backup API that kicks in to get some hardware info. We hired Dar Scott to write a DLL that would get the HD serials. We resorted to the less favorable 'ipconfig' calls via shell for MAC addresses. You can shell("ver") to get the Win OS details with a back of LC's systemVersion(). Resolution details come from LiveCode's screenRects(). We called this collection of hardware details the lite version. Minus Dar's DLL, you could do this lite version on your own.

<business hat/> The following statements should apply to vertical market apps pretty easily. It may be more difficult to enforce them with horizontal apps. For horizontal market apps, I would let the customer install as many copies as they want and manage the running of them with a cloud license model.

There have been comments that shell calls may not work reliably. This statement would be correct. You will find they can fail in environments were IT can install security software. Our answer is open and honest to the support teams our clients hire. These requirements are required. It may seem a bit cavalier, but we have never had an issue with compliance. I am sure that everyone reading this would agree that they spent a lot of time making X software. We intentionally do not make a lot of products. We do labor intentionally over the most minute details for the few that we make. This level of concern for making excellent software comes with a price tag. Thus, protect your work where you can and get paid. </business hat>

@Jacque: Indeed, but this isn't really something you should be doing on mobile at all - its considered a privacy invasion.

Certainly Apple does not allow apps in its AppStore which generate (and visibly utilize!) a unique id that uniquely identifies a device and I suspect Google would not look on it fondly either.

There used to be an iOS API you could use to get an actual unique device-id which was the same across all installed apps - but that was heavily abused by advertising platforms (and indeed Facebook IIRC). It was deprecated and removed around iOS 5 or 6.

The most you are allowed to do is to use a unique id-per-app-install (essentially a persistent UUID which is generated on first-run) - which is what the replacement call provided by iOS now does (but that is identical to doing the 'generate a uuid on first run' trick). Critically, this provides zero information about the user as every app installed on the device will have a different such id.

Generally apps on mobile will identify users by a login of some sort; whether it be to a private/per-app type identity management system, or indirecting through something like Google or Facebook's identity services. This forces informed consent by the user - i.e. they are explicitly authorizing your app to 'know who they are' (and under the GDPR in Europe at least, you have to be clear about what you will use said identity information for).

I'd point out that Get(PersistentID) in FIleMaker doesn't give a unique device-id in FMGo or in the FMApp SDK (which allows you to build a solution into an iOS app a bit like LC standalones) - it is just a unique-id-per-app-install.

Thanks, Mark T and Mark W. Useful insights.

bogs wrote: Tue Mar 03, 2020 11:09 am Mark, I'm actually curious about the rest of the points brought up as to why this type of thing shouldn't be included in Lc, so (I hate to burden you with time consuming questions but...)
1. How many Os'es supported by Lc do you deploy too ?
2. How much time (if you remember and the answer to 1 is > 1) did you spend looking up the information to get the parts you needed from each Os?

1. Between all of the products we make, but not inclusive to all the products, we use everything, but the HTML 5 builds in LiveCode.
2. We do the hardware lookups only for Mac and Win. We do not make Linux desktop apps require complete media support and/or the browser widget. Let me be clear that the Linux engine is my favorite for writing server-side workers. Mobile constraints prevent us from digging as deep as we can do on desktops. Our companion mobile apps are free to install and are only useful to people that have one of our core desktop apps anyways. A proper login system is all we need to track users on mobile.

Going back to the original request (which was for some means of validating a user's right to run an app) and obviously what @mtalluto goes to great lengths to do - maybe I'm being slightly naive here, but how does some sort of hardware based unique id offer any better means of validating a user's licensing then an 'on-first-run-uuid'?

In order for the hardware-unique-id to be useful, it has to be tied to a user's purchase of a license to run your app. This would suggest there has to be some record held on a server which maps a user's license purchase to the id of the hardware they have installed the app on. Furthermore to ensure further compliance with the license purchase, this needs to be periodically checked against what is held upon said server (or there needs to be some server communication at some point should the hardware id change outwith the bounds set on the allowed changes).

Given the apparent need for a server (in order to be able to use the unique id); surely any unique id is sufficient, as abuse of a license can be seen through the pattern of calls made to said server (regardless of how that unique id is generated) as the server holds a mapping from unique-ids to license (as would need to be established upon registration).

LCMark wrote: Tue Mar 03, 2020 7:29 pm Going back to the original request (which was for some means of validating a user's right to run an app) and obviously what @mtalluto goes to great lengths to do - maybe I'm being slightly naive here, but how does some sort of hardware based unique id offer any better means of validating a user's licensing then an 'on-first-run-uuid'?

The main difference that I can see is that fingerprinting is not just an isolated unique value that is stored value on the hard drive or memory. It is a collection of hardware id pieces hashed together.

The solution computes the hash every time the software runs. It checks that value to a stored license file in plain sight. Copying the license to another computer will result in a hash mismatch.

The solution survives OS reinstalls and even minor hardware changes. You are right that fresh installs will need internet access or occasional access to a server to verify the license in the cloud.

Plus, you can do useful things by providing a registration key that works for X amount of users. The key is consumed as they register their software.

The hash is not easily spoofed if you use enough hardware to build the hash in the first place. Is it foolproof? Probably not. For the markets we serve, it has worked quite well. I should note that this is a hardware licensing system. User licensing schemes can be dealt with in other ways.

Thank you for going into such detail Mark T., very informative and quite a lot of work to get too.

bogs wrote: Tue Mar 03, 2020 8:49 pm Thank you for going into such detail Mark T., very informative and quite a lot of work to get too.

My pleasure. Pssst...i have a secret. Most of this stuff was developed when I was in my 20s. When you are that young, you view the whole world and infinite time is in front of you. At my current age, I realize that is no longer true. I would not have the time to build these crazy things and get enough coding done to survive.

mtalluto wrote: Tue Mar 03, 2020 8:52 pmMy pleasure.

I'm glad it wasn't quite the burden I thought it might be

mtalluto wrote: Tue Mar 03, 2020 8:52 pm When you are that young...

I don't think I was ever that young ha ha ha