More On Policing Shareware

RHW22 writes "Washington Post's Rob Pegoraro looks at shareware, focusing on the question of whether or not this industry can survive if people never actually cough up $$ for the product. He mentions Ambrosia Software, 'a developer of Macintosh games and utilities in Rochester, N.Y., could stop guessing after it revised its payment system last year. The new system aims to stop people from using pirated registration codes in two ways.' Read his column here." We mentioned this several weeks ago, with a link to Ambrosia's description of their system and what led to its adoption.

Comments

Most shareware these days isn't really shareware

[Tyler Eaves]

IMHO, most stuff marketed as shareware is really demoware.

If it can't save - It's a demo
If it pops up excessive nag screens - It's a demo
If major functionality is locked - It's a demo

The only effective way

[TheSHAD0W]

You want to make money on shareware? Charge less. Make it very convenient to pay. And don't annoy the end user.

Headlight Software has made lots of money from Getright registrations, despite some people having pirated it. I've registered it myself. (I think it was $20, not $25, when I did, though.)

If a software company wants too much money for a piece of shareware, users will get a patch or key generator rather than pay. If the software nags the hell out of the user when he installs it, he'll get mad. I know I do.

Then you never really own the software!

[zerofoo]

When I purchase software, I own the product. The problem with expiring registration codes is that you only own the software as long as the company is in business.

What happens when Ambrosia goes out of business and the software code expires? Your product that you PAID FOR stops working.

Can you imagine the impact of GM going out of business and then finding your car doesn't start the next morning? You paid for that car, and you expect it to function correctly for the expected life of that car.

Expiring codes, WPA, and all the other software piracy/protection schemes out there remove control of the software from the end user and shift it to the software vendor. It is only a small step to software as a subscription service after that.

I'm really glad my Linux machine is totally free and if Microsoft, or Ambrosia goes out of business it will still keep working.

-ted

Re:Then you never really own the software!

[MajroMax]

When I purchase software, I own the product. The problem with expiring registration codes is that you only own the software as long as the company is in business.

If done right, this isn't strictly true. A registration system only needs to rely on central servers if data used for the authentication process changes, such as a System ID or a timestamp, the latter being used in Ambrosia's system.

A simple authentication system would take the registree's name, address, and perhaps a keycode given at regtime to create a hash for the authentication server. If that hash is valid (meaning the registration actually happened), the authentication server will respond with a countercode that the program uses to unlock itself. If this countercode is not time-limited in any way, there's nothing logisticially preventing it from beging shown to the user, and thus permanently recorded; it will still be valid so long as the user remembers his name/address/etc.

If changing data is used for the hash, however, then there's a trickier situation if the authentication servers go permanently down. Most schemes would have the server respond with a sepereate countercode, and thus an old one would not work to unlock the program.

One solution to this problem is a master-key; a nonchanging constant that could be released if the company goes out of buisness. This creates security flaws, however, if the key is found out before the company goes out of buisness. Also, having a master key for the product out there would significantly reduce the possible value of the software "asset" in bankruptcy proceedings, so the courts might not allow the key to be made public.

A possibly better alternative would be to have the company release a patch that turned off the date-checking code in the program. Although this doesn't create any security holes in the product while the company's still alive, it does require that the company know it's irrevocably going bankrupt, and the programmers must have enough knowledge about the banakrputcy and power to release the patch -- neither of which are particularly likely in large corporations... after all, management can spin off the now-crippled masses as a "customer base" for future revisions to be sold at auction.

What's really needed is some sort of "dead-man's switch" so that if the company suddenly drops off of the face of the earth, the software will still work. To do this, the software should become non-functional if it receives a negative response from the auth server, instead of becoming non-functional if it fails to receive a positive response. The reg-server hostname should be hardcoded into the software somewhere (binary data file or program executable -- NOT a plaintext file), and the software (given use of an expired regcode) will try authenticating with the server on run and every hour or so until it receives a positive or negative response, in which case it will update its datafile and not try again (with that regcode).

"But Wait!" you say, "Isn't that system inherently insecure, as malpeople can crack the software or selectively block access to the auth servers?"

This is true, but, as the Ambrosia article says, the vast majority of people will do very little beyond trying a cracked regcode -- even installing a crack is beyond the vast majority of people who would typicially use the software; configuring special firewall rules is probably out of the question. (This is also why I said "put the server info in a binary file", as instructions to remove the data from a textfile is easy enough for most users.) Software registration is a game of 90%'s, so eliminating 90% of potential copyright infringers is about as good as you can get for reasonable effort. For people who _do_ tell Zonealarm to not allow the program to connect, a nag screen on startup to the effect of "This software has not verified its registration, click OK to continue" will get another fraction or two to register -- admittedly, it would be a pain if the company went out of buisness, but it doesn't have any bearing on the functionality of the software, especially for something noncritical like a game.

Running the software on a computer without internet access at all is another possibility of getting aroud the auth scheme, but that's becoming increasingly less likely as time goes on -- more and more computers are getting connected in some way, shape, or form, and shareware is largely distributed over the Internet now anyway.

Admittedly, this isn't a 100% perfect solution to the tradeoff between infringement-possibilities and functionality in the face of bankruptcy, but I'd guess that it's 80% of the way there, and it would require no changes to the keygen routines themselves.

--
The ideas expressed in this writeup are expressly placed into the public domain.

Is troll your middle name?

[WIAKywbfatw]

The way I see it, shareware authors shouldn't expect to turn a profit. They should just see being profitable as a nice perk.

Why shouldn't shareware authors expect to make a profit? Because you say so?

Shareware is a distribution model - you like it so you register it, recommend it to your friends, etc - nothing more, nothing less.

Too many people equate shareware with free, and those that resort to password cracks are the worst kind as they can't even use the "I just wanted to see if it was what I wanted" defence.

Sure, most people will take advantage of the situation and never register software that they decide to use beyond the trial period, but some people are more honest and will happily pony up $20 for a package that does the job they want done.

But saying that the authors, the people who invested their time and effort into code that other people benefit from, shouldn't expect to see a return on their work is downright unbelievable.

Not Shareware

[wandernotlost]

I find it disturbing that so many people continually show such complete ignorance of the history of this industry.

Shareware is fully-functional software for which you are *encouraged* to pay the developer (if you find it useful). You are also encouraged to share it with your friends, hence the name shareware. It is not time limited. It is not missing any functionality necessary for normal operation. It may have annoying messages nagging you to please pay, but if it is hampered in any way in which you must pay to get the fully-functional version, it is a commercial demo.

It's offensive that so many people these days seem to be freeloading off the good will and generosity of the shareware community in order to sell their commercial products!

Why I hate shareware

[IvyMike]

Actually, I'll just quote Linus: " In my opinion, shareware tends to combine the worst of commercial software (no sources) with the worst of free software (no finishing touches). I simply do not believe in the shareware market at all. "

Perhaps I've been spoiled by Linux, but I'm getting into Mac OS X now, and there are tons of little apps that on Linux would be free, but some chump wants $9 for on OS X. Yeah, part of it is me being cheap, but I keep going back to Linus's quote and end up not buying it.

"Shareware + source" might be interesting, even with a non-RMS-compliant license, but I haven't seen it. (And of course, I'd prefer full GPL if possible.)

Re:Some helpful links with reg code generation inf

[jmaslak]

Okay, you want to write your own key generator.

My advice:

1) Use RECOGNIZED encryption & hashing algorithms. Do NOT invent your own!

2) Don't shorten the result from a hash. I recommend at least 128 bits of entropy in the key (if you use Base64 to represent your key, you need 22 characters)

3) Use public key encryption to prevent giving away your secrets.

An example protocol:

User sends his name (case sensitive) and the current timestamp (both of which the client stores to use in future validation) to the "authentication server" which also takes his credit card number. After receiving payment and validating the timestamp, it generates the registration code as follows:

1) Take the username, timestamp, and a secret symetric string (which will be embedded into the client, but, thus, vulnerable to attack). Concatenate them together with some sort of seperator (like a NUL character).

2) Take this new concatenated string and do some bit scrambling if needed. Take the MD5 hash of this new string and use for the next step.

3) Using RSA and a PRIVATE KEY (*NOT* embedded in your application!), encrypt this hash. Send the encrypted hash value in Base64 to the user. Remember he may need the timestamp as well to re-enter this value. The timestamp can be simply a day/month/year string.

To VALIDATE a registration string,

1) Decrypt the encrypted hash string using the PUBLIC KEY (embedded in your application). Because it is a public key, it doesn't matter if anyone knows it.

2) Verify that that hash equals the value of a hash constructed on a client using the user's name, his registration timestamp, and the shared secret embedded in the application.

Really, this isn't a secret science. But every game designer seems to think he is more creative then hundreds of experts on encryption. This is basically no different then a FFI (Friend or Foe Identification) system used on a military aircraft.

Re:What do these folks expect?

[amccall]

This is a good point.

Shareware authors, and everyone on the internet for that matter, need to ask "Why would I spend my money on this"? I'm sick of hearing websites complain that people don't register for what amounts to a few worthless extras. Would you register for that worthless trash? No? Don't complain.

A good example: If I didn't view the slashdot subscription as a tipjar, there is no way I would EVER consider paying for it. As a long time /.'er, I probabably will.

The shareware, software, or service I see being successful is that which has a service behind it.

Codeweaver's Crossover plugin is arguably worth the money. (As an above poster said, this really isn't shareware as much as it is a demo though.) Those that provide extras for registering - such as sending a CD. For the internet age, DigitalBlasphemy is a another excellent example. Providing an excellent freeware sample gallery, and then a relatively low annual fee for access to the full gallary and then discounts to artwork CD's/etc...

When providing something extra to those that pay, the honor system works. When treating your customers DECENTLY, the honor system works. But when you suspect your cutomers to be criminal from the start, and treat them like trash, you deserve what you get. Registration of shareware should be EASY - not something that requires a complete hardware identification of my machine, 3 CDKey's, all my personal information, and a blood sample. - And if they aren't having that many people register - they're probably asking too much or selling trash.

What the internet needs a little bit of old-style business sense. Something I see almost none of.

Re:Blatant theft?

[American AC in Paris]

I fail to see how this amounts to theft. It is a violation of a modern law, but theft is almost so obvious one has to think about it to even define it. Theft is the act of depriving someone of some 'thing' that they have exclusive rights to, either by earning it, or having been given it by someone who themselves earned it.

...so you're suggesting that a software developer hasn't 'earned' the right to distribute her own creation as she sees fit?

If a developer spends 1200 hours of her life making a game, is it your right to disregard her terms?

The DEVELOPER is the OWNER of her own product. She does indeed have exclusive rights to her own creation; if she kept the only copy of the software encrypted on a CD and locked in a filing cabinet, you have absolutely no right to tell her that she must give it to you. If she gives it to you on the condition that you don't give it to anybody else, you have absolutely no right to give it to other people. She can choose to develop and distribute it however she sees fit, and she gets FINAL SAY in this matter. It doesn't matter if you don't want to cough up ten dollars; it doesn't matter if she wants to set up a registration scheme that forces you to call a 900 number every time you want to use the program. The terms are completely up to the DEVELOPER, not the consumer.

If you don't like the terms a developer has set forth, then don't use that developer's product. It's that simple. Cracking a developer's product for the express purpose of using it on your own terms is incredibly disrespectful to the developer. She worked hard to produce that software, she deserves respect, and she has the right to set out her own terms. You the end user, on the other hand, did exactly jack shit to create said software. Where do you get off telling us that it's morally okay to tell the developer to go piss up a rope?

If you disagree with a developer's terms, them do not use the software. Period.

Software development takes time. Software development takes energy. Software development takes thought. Software development is always, at some point, a royal pain in the ass. Software development is a labor of love. That you have the gall to even suggest that the end-user has the right to dictate their own terms to the developer tells me that you have never, ever developed software of any real magnitude.

There are precious few ways to keep people from pirating software, but damned if I'm going to let you claim that it's the right thing to do.

I *TRIED* to buy shareware.. this is the problem..

[takochan]

This is an interesting debate.

I think shareware authors should be paid for their work. Shareware is cheap, shareware is great..

But...

In fact, I tried on 3 instances to buy/register shareware.. and this is what happened.. I think this is part of the problem...

1)Trumpet (a TCP IP stack from several years ago).
Buy the program, registration never shows up in m ail.. wait.. email back and forth..wait some more.. in meantime, trial expires, re-install wait somemore. Client I am billing hours for is getting unhappy.. Calling to Australia to get it sorted out was not fun either.

2)DFX (an sound effects addin for winamp)
Liked it, and tried to buy a copy with their VISA card purchase screen... then.. nothing happens.. no registration comes.. nothing..wait days... nothing happens, no reply, no program... nothing.. I write email to them.. nothing happens..no reply..

Finally I *CALLED* the company, to ask them what is going on. They said that my visa transaction was rejected (but they never bothered to inform me of this, even though they collected my email address (just to send me spam I guess?). When I asked the sales rep at DFX what is wrong, they told me that my destination address and billing address were different, (I am an expat overseas) so.. transaction just gets automatically rejected, bin'ed.. period. No mail, no reply, no followup, nothing.. rejects just goes to /dev/null..

They didn't email me when the Visa was rejected (or ask where I live.. or anything), nor did they even bother to reply my original emails.
The answer the DFX rep gave me on the phone to all this was... "well, it is just a $15 program, so we can't spend too much effort (ie any!) to deal with things that might come up".

3)NJstar
It is a great program. But they wanted me to send checks to Australia or something in AUS dollars.. gee.. how to I do that.. the bank will charge me $50 in processing fees (after waiting in 3 lines at 20 minutes a pop because no one would know how to draw up a foreign denominated check), for a $25 program..

Those are my stories..

..and people wonder why they don't register their shareware...?!. ..

...because it is too complicated
to pay for it, thats why.. fix that, and then
I am ready to buy lots of great stuff.. but
right now it is just too much hassle I discovered,
so I just stay away from it..

Re:Some helpful links with reg code generation inf

[captaineo]

There is a variant of this system that would be virtually impossible to crack... Intel & AMD would have to embed a private key in the CPU core. When buying software, you would present the public key that corresponds to your CPU. The software vendor would check this against a list of valid keys published by Intel (to prevent people from making their own key pairs), encrypt the software using your public key, and then send it to you. Your CPU would decrypt the code as it executes using the private key embedded in it. The binary would not work on any other CPU.

A hardware-based system like this is many orders of magnitude more secure than a software-based system, because the software remains encrypted all the way up to the CPU. The only way to break it would be to find one of the embedded private keys ($$$ equipment)... Or to convince a software vendor to encrypt with a made-up key that you know both public & private parts of...

BTW, this is also the basic framework for audio/video copy-prevention systems. (CSS works like this, except there are only a handful of private keys, and the CSS encryption algorithm is flawed)