sender e-mail address

[FourthWorld]

if I generate it several times, on the same device, the UUID will be always different.

Then don't do that.

Just write it once on first-run, and then read it in all subsequent runs.

[Simon]

Hi franco,
What Richard means is that you should save the UUID to an external file (just a text file) on the device and read that file every time the app is started. Now you will have a unique ID for each device.

Simon

[francof]

ciao Jacqueline, Richard, Simon. thanks for your time.

Android build info is not reliable, some manufacturers use the same info on all the devices of the same model. And of the devices I've looked at, many of the identifying entries are listed as simply "unknown" which will match other models too.

...

at present now I've not got duplicated data from devices on which app runs... yes I know, no certainty in this world.

Hi franco,
What Richard means is that you should save the UUID to an external file (just a text file) on the device and read that file every time the app is started. Now you will have a unique ID for each device.

Simon

Ok but if I copy the txt. file in another device? the app will find it and it will start.
How you may have guessed, I'm looking for a control on commercial licence. to block,in the future, unauthorized copies.
probably something escapes me

best
franco

[jacque]

at present now I've not got duplicated data from devices on which app runs

It is most easily seen with two users who use the same device. For example, if you and I are both using the same brand and model of a particular phone and both are running kitkat, the build info can be identical.

Many Android manufacturers do not provide a device identifier and all the other info may be the same for all copies of that model.

Android users cannot copy the file to another device unless the phone is rooted, which means the file will be inaccessible to most people.

Apple forbids the use of the uuid, which is why it has been removed from the build info in LC. If you will release to the App Store then Apple will manage ownership. If you are distributing the app yourself then I don't see any other way to manage except to write a file.

[FourthWorld]

Apple forbids the use of the uuid, which is why it has been removed from the build info in LC.

I know you know this, but for the benefit of other readers the UUID Apple prohibits is their own, which several versions back LiveCode used to provide a special function for under a different name. The "UUID" function provided in LiveCode is safe to use on all supported platforms.

If you will release to the App Store then Apple will manage ownership. If you are distributing the app yourself then I don't see any other way to manage except to write a file.

If even that. With Apple's management of app distribution among licensees, developers shouldn't need to spend any time on this at all in iOS. The only risk may be with jailbroken devices, but those are few and so exposed to security risks that it was never a popular thing to do and only less so over time.

Even on the desktop, where a sufficiently motivated person can find a crack or keygen for pretty much all commercial software ever made, the risk is barely worth more than a very modest effort to help encourage honest customers to remain so.

Nothing can stop a hacker. Game companies spend millions on software license enforcement, knowing in advance that it will never stop or even significantly reduce piracy, but merely slow down the time-to-crack to at most about 90 days. In the high-stakes game world that's enough to be worth it, but few of us have titles that will produce that kind of money to be worth the effort.

Besides, over time the crackers have tilted things in favor of the developer: most cracks and keygens these days are Trojans for keyloggers and other malware serious enough to make anyone but the most technically sophisticated think twice about attempting to use them; those with more modest skills who download cracks often find their systems compromised at a deep and sometime unrecoverable level within seconds. Anyone who might ever be a paying customer won't bother with such extreme risk, and the sort who will would never be paying customers anyway.

For most of us, ROI for software security beyond a modest level is easily negative. Much higher ROI comes from focusing on features that add value for paying customers.

[jacque]

I know you know this, but for the benefit of other readers the UUID Apple prohibits is their own, which several versions back LiveCode used to provide a special function for under a different name. The "UUID" function provided in LiveCode is safe to use on all supported platforms.

Thanks for clarifying that, I should have been more specific. The UUID that Apple forbids is the actual device ID built into the hardware, not the software-generated one that LC creates.

I spent some time trying to solve this same problem with my Zygodact product, which generates serial keys for software distributions. It can be used on Android devices but it is not very secure so I don't support it for mobile use. Everything I found on the web about securing Android cautioned against using the build info, because it is not always unique to a particular device. And since Apple forbids custom registration schemes, it can't be used for App Store distributions anyway.

[francof]

...
Nothing can stop a hacker. Game companies spend millions on software license enforcement, knowing in advance that it will never stop or even significantly reduce piracy, but merely slow down the time-to-crack to at most about 90 days. In the high-stakes game world that's enough to be worth it, but few of us have titles that will produce that kind of money to be worth the effort.
...

I believe you, I think a little effort to give a minimum of protection must be done.

...
If even that. With Apple's management of app distribution among licensees, developers shouldn't need to spend any time on this at all in iOS.
...

true, but not exactly cheap: apple asks credit card number before to say hello".

...Android users cannot copy the file to another device unless the phone is rooted, which means the file will be inaccessible to most people.
...

at present in the preopencard I'm going to read this file:

Code: Select all

open file specialFolderPath("DOCUMENTS") & "/att.txt" for read
 read from file specialFolderPath("DOCUMENTS") & "/att.txt" until EOF

you said I cannot copy, or read that file with a text editor, from that folder? or must I do something different?

ciao
franco

[FourthWorld]

...
If even that. With Apple's management of app distribution among licensees, developers shouldn't need to spend any time on this at all in iOS.
...

true, but not exactly cheap: apple asks credit card number before to say hello".

I don't understand. One of the distinguishing characteristics of iOS is that Apple controls all app distribution on that platform. If not through Apple, how would your distribute your iOS app?

[jacque]

at present in the preopencard I'm going to read this file:

Code: Select all

open file specialFolderPath("DOCUMENTS") & "/att.txt" for read
 read from file specialFolderPath("DOCUMENTS") & "/att.txt" until EOF

you said I cannot copy, or read that file with a text editor, from that folder? or must I do something different?

That's right. Files in the documents folder are stored in the app sandbox and other apps can't access it. They can only see files stored in public folders on the drive. You don't need to do anything else.

It would be easy to test though. Create the file and then try to find it with an Android file browser.

[francof]

I don't understand. One of the distinguishing characteristics of iOS is that Apple controls all app distribution on that platform. If not through Apple, how would your distribute your iOS app?

I only meant that, with Apple, to do anything you have to pay:
to test on real device must pay minimun 99$ per year,
if they have the kindness to accept my app on the store must pay,
if the app is sold they take a percentage. etc.

or am I wrong?

That's right. Files in the documents folder are stored in the app sandbox and other apps can't access it. They can only see files stored in public folders on the drive. You don't need to do anything else.

It would be easy to test though. Create the file and then try to find it with an Android file browser.

this is good, sure I will make a test.

thanks all, everything seems a bit clearer.

ciao
franco

[FourthWorld]

I don't understand. One of the distinguishing characteristics of iOS is that Apple controls all app distribution on that platform. If not through Apple, how would your distribute your iOS app?

I only meant that, with Apple, to do anything you have to pay:
to test on real device must pay minimun 99$ per year,
if they have the kindness to accept my app on the store must pay,
if the app is sold they take a percentage. etc.

or am I wrong?

Yes, that's my understanding as well, that the only way distribute any app for iOS requires going through Apple's programs to do so.

Part of what developers get for those fees includes license enforcement, so that's not normally something app devs have to reinvent themselves.

[francof]

sorry, I've forgot to ask for this:
is it possible that some utility app, running on smart and iphone, used to delete old and "apparently" no more used files from the device delete the file, containing the uuid, created by the app:

Code: Select all

open file specialFolderPath("DOCUMENTS") & "/code.txt" for write 
      put  field "fldattivazione" into myText 
      write myText to file specialFolderPath("DOCUMENTS") & "/code.txt" 
      close file specialFolderPath("DOCUMENTS") & "/code.txt" 

after created that file no longer being updated (only read)

best
franco

[jacque]

File cleaners only remove temporary and cache files. I don't think they have any access at all to your app's document files.

[francof]

File cleaners only remove temporary and cache files. I don't think they have any access at all to your app's document files.

ok, thank you
ciao
franco