----- Original Message -----
From: Stephen Best <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 30, 1999 8:10 PM
Subject: Re: User name registration
> > I'd recommend that you use the "RegCode" format if you want to sell your
> > program online through PGHQ or PalmCentral. See:
>
> > http://www.palmcreations.com/regcode
>
> > There is src and example code there.
>
> Jason,
>
> As a shareware developer, I'm keen to find something that takes me out of
> the sales loop ... but I think RegCode is the wrong solution for the
> following reasons:
>
> 1. Each user already has an id, why complicate matters by inventing a
> second?
(see below)
> 2. The HotSync id is common to all applications (and can be stored in the
> seller's database) whereas, if I choose it, a RegCode may be unique.
Allowing each developer to choose the composition of their own RegCode is a
requirement in the definition of our RegCode syntax because in some cases,
developers need to encode unique information (such as a barcode scanner
serial number). So yes, a user may have to enter a different RegCode when
purchasing different applications, which is not as convenient as always
typing their HotSync Id, but the HotSyncId introduces several problems for
realtime fulfillment as I will mention below.
> 3. It's unreasonable to ask a user to type in a string of (up to) 22 hex
> digits plus colons.
I think a PUN can be up to 40 characters, whereas a RegCode can be up to 30
(including the colons)
> 4. The hex string doesn't "scan" well whereas the HotSync id (likely based
> on the user's name) does.
The RegCode is not designed to be scanned or read by humans, it is designed
to be used in an automatic unlock key generation process that does not
require a human to read or retype it. Furthermore, the use of hex digits in
the RegCode provides a means for autmatic correction of certain typos (such
as "O" to a "0", etc which couldn't be done if you allowed the complete set
of ASCII characters)
> 5. The resultant unlock code of 5 digits is too short and can easily be
> cracked by some automated routine.
Remember the "automated routine" has to actually type the number into your
application's registration screen up to 65535 times to see if it works --
this test can't be tried outside of your program. It is arguably easier for
a hacker to patch your app to avoid the RegCode test altogether, than it
would be to him to reverse-engineer an unlock code.
> 6. I want to store more info in the unlock code, e.g. registration date,
> product code.
The RegCode can encode any data you choose -- see the paper for details.
Most of your points above deal with the inconvenience of the RegCode syntax
compared to the HotSyncId Pilot User Name), so I'll address them
collectively here...
In addition to the lack of flexibility required for a standardized code that
I mentioned in point #2, above, the PUN has several other drawbacks that
prohibit us from using it in realtime fulfillment. These drawbacks were
explained in the link above, but I'll reiterate them here:
1) Pilot User Name can be interpreted ambiguously by the user. In many
cases, we see the user types their actual real name in the Pilot User Name
field of our CSV files
2) Pilot User Names can contain foreign ASCII characters that may get lost
somewhere in the communcation between the user and seller.
3) There is no way to reject illegal PUN's whereas the RegCode has a
checksum byte.
While RegCode looks messier than a PUN, it serves the purpose of providing
an unambiguous means of communicating a small piece of information between
the user and seller. Since this communication only happens once, I don't
think it's too much to ask the user to type a series of up to 10 hex numbers
in order to provide realtime fulfillment.
Thanks for your comments. We are always looking for ways to improve RegCode
under the existing framework.
-Jason
