[3R1C]

my partner and I are almost ready to ship our first cocoa application. We need help and input into how we should copy protect our product. We see two general methods of protecting our software. We have already decided to cripple our application. But we dont know whether to enable all functionality via a serial number/password or requiring the user to download a full version.

We know that no matter what we do, our app WILL be pirated, bit my partner puts forth a strong argument that distributing pirate serials via surfers serialz and the like is MUCH easier than distributing executables.

what are the benefits/liabilities of each of these distobution models?

Our dmg.gz is about 620 KB if that makes any difference.

what do ya'll think?

[VValdo]

Originally posted by 3R1C:
<STRONG>my partner and I are almost ready to ship our first cocoa application. We need help and input into how we should copy protect our product. We see two general methods of protecting our software. We have already decided to cripple our application. But we dont know whether to enable all functionality via a serial number/password or requiring the user to download a full version.

We know that no matter what we do, our app WILL be pirated, bit my partner puts forth a strong argument that distributing pirate serials via surfers serialz and the like is MUCH easier than distributing executables.

what are the benefits/liabilities of each of these distobution models?

Our dmg.gz is about 620 KB if that makes any difference.

what do ya'll think?</STRONG>

There's a good article about piracy on Ambrosia software's site.

Basically though, whether it's a SN# or a cracked executable, you're probably right that it'll get pirated.

W

[wadesworld]

Allow the application to be downloaded so people can at least get a look at it before having to pay.

And you're correct - if it does anything remotely interesting, it will be hacked.

Wade

[Apocalypse]

Definitely read the above article about copy protection by Ambrosia. You could also apply a sort of guerrilla warfare and flood all the usual piracy channels with copies of "cracked" copies that are really just the normal version or distribute sets of serial numbers that are incorrect.

Of course, you could also make the program go online and renew its serial number from time to time from your site. That would be an interesting way of doing it although it restricts your user base to those who are either always online or those that would let you occasionally go online. It may annoy them too much in the end.

Just some suggestions,
Jeff.

[Scrod]

Look, this is a Cocoa app, right? So it'll only ever run on Mac OS X. Mac OS X will only run on G3 and G4 machines. The only computers with G3 and G4 processors that Apple has ever manufactured have ethernet built into the motherboard.
In order for a user to get a registration number from you, the app will generate a unique number based on their hardware MAC address. The user will send you that number, and you'll send them back a serial number based on that.
Yes, if someone gets a new computer they'll have to re-register it. But the upsides are numerous: It's not necessary to hide invisible files on the users' computer containing their serial number, it's very, very, very difficult to illegally distribute a working serial number*, and the scheme even complies with many software licenses already, which limit the installation of the software to one computer.

*Yes, people could hack your app or the system to alter their MAC address, but it's far more difficult to create a crack (especially if you update your software frequently) than to simply distribute serial numbers.

And email me (scrod-at-mac-dot-com) if you would like to hear about a non-intrusive way of making an app virtually uncrackable on a UNIX operating system.

[3R1C]

This is precisely the system I have proposed to my partner. Sure they could spoof their MAC address but damn if they dig my prog that much, they can have the damn thing.
Do you know of any source available which implements this strategy? I'm pretty happy with this idea.

[iJed]

Originally posted by 3R1C:
<STRONG>This is precisely the system I have proposed to my partner. Sure they could spoof their MAC address but damn if they dig my prog that much, they can have the damn thing.
Do you know of any source available which implements this strategy? I'm pretty happy with this idea.</STRONG>

Does nobody else think that this idea is evil? Imagine if you have ten or twenty software packages like this, all from different companies, and you upgrade your Mac or get a motherboard replacement. This is what I would call an absolute nightmare! I don't think that I would ever buy software with any kind of evil scheme like this. If I was going to buy it the first thing i'd make sure I had was a crack for it!

Sorry if you think that I am a troll but I feel really strongly about this.

[mahrz]

Originally posted by iJed:
<STRONG>

Does nobody else think that this idea is evil? Imagine if you have ten or twenty software packages like this, all from different companies, and you upgrade your Mac or get a motherboard replacement. This is what I would call an absolute nightmare! I don't think that I would ever buy software with any kind of evil scheme like this. If I was going to buy it the first thing i'd make sure I had was a crack for it!

Sorry if you think that I am a troll but I feel really strongly about this.</STRONG>

It depends on the software you want to sell. I don't think anybody would buy a 20$ shareware with hardware based license key, but if you have a 1000$ product I would give this system a try.

[iJed]

Originally posted by mahrz:
<STRONG>

It depends on the software you want to sell. I don't think anybody would buy a 20$ shareware with hardware based license key, but if you have a 1000$ product I would give this system a try.</STRONG>

Yeah I totally agree with you here. If its something really massive like Maya then this would probably be fine. In anything less than a few thousand dollars (pounds for me) then this scheme would be simply unacceptable.

[awe]

Did you evaluate the "keyfile" protection method?

Each user who registers receives a keyfile which is several kb in size. Inside the keyfile you store several times the user information, like registration name, email etc. Of course each time encrypted in a different way. Installation of the keyfile can made be simple by dragging it onto the app icon or offering an open keyfile dialog.

Now let's see what we can do with the keyfile:
A. The leaker didn't care about the encrypted data.
- Got him! The next update will block his keyfile and he won't receive a new keyfile. Of course he will be sued.

B. The leaker was clever, debugged your app and removed the user data/cracked the sn scheme:
- Since the distributed version checks only parts of the keyfile, the user data can be stored in several ways inside the file. Maybe the warez kid forgot to remove it. Gottya...
- The kid removed all data that wasn't checked by the app! Grrr!!! But look: The next updated version won't work with this keyfile, since you are going to check other parts of the keyfile. Make sure that you don't check all components of the keyfile with one version, so that the pirate doesn't get the chance to create a fully functional new keyfile.

C. A keyfile can't be spread on forums like a SN.

In my opionion this is the best method to protect the sales of your software and it's more comfortable to the user as with the Ambrosia method, since the user doesn't need to request a new key, if he wants to activate the software in the future.

awe

[Angus_D]

There are lots of serious arguments against MAC-based SN schemes.

[Northform]

If you price it reasonably and offer credit card orders with an automated system of sending the serials you won't get too many pirates. The problem arises when people charge too much (in the consumers eyes) for the product. I've found that copy protection merely banishes your product to obscurity (depending on how harsh). And you know what they say 'If you love it set it free..." (Not in price, but so long as you don't piss of consumers you should believe in their general goodness and that they will register if they use it).

I've found that when you price things higher you don't make more money, less people buy it and that copy protection also makes people squimish about it.

[3R1C]

All of you present valid arguments. However one thing is certain. If I charged 50 cents for my product, (it will cost 10 bucks) and it was protected with a serial #, my market (mp3 hounds) will just snag a serial from surfers serials.

[King Kong]

I would suggest that any scheme that is machine based (ie ethernet scheme) is bound to frustrate users. The only software I have with this kind of scheme is Final Draft and over the years I have changed machines 8 or 9 times. Each time, the one app that causes problems and requires calls to tech support is Final Draft. I can't imagine how horrendous changing machines would be like if all my apps did this.

[Arakageeta256]

I really like how the haxies apps are only $7.00. That's like pocket change-- or at least nice meal at Subway.

I think you would make an impression by pricing the software below $10. Whether or not you think that's valid, well, that's up to you I suppose.

[kamprath]

Originally posted by 3R1C:
<STRONG>All of you present valid arguments. However one thing is certain. If I charged 50 cents for my product, (it will cost 10 bucks) and it was protected with a serial #, my market (mp3 hounds) will just snag a serial from surfers serials.</STRONG>

Ah, so true. There is nothing you can do about this. You can block found hacked serials in future versions (which is the approach I use) and pop up guilt screen if one is used. In my guilt screen, I point out to the user that turn about is fair play and that with 2-3 lines of code I could be erasing their hard drive - which I don't actually do, as I want to get the sale. Essentially, I try to guilt the people into not using the hacked serials. It never ceases to amaze me though, when I find a new hacked serial and block it, I get a significant spike in "my serial number no longer works e-mails" from people who have never purchased a serial number.

Bottom line, its a battle that you will never be able to win completely. I estimate (through means I won't discuss here) that 40% of the people who download my shareware use a hacked password. Really heartening to know that the Mac community is so supportive of their shareware authors.

Michael

[parallax]

Originally posted by 3R1C:
<STRONG>This is precisely the system I have proposed to my partner. Sure they could spoof their MAC address but damn if they dig my prog that much, they can have the damn thing.
Do you know of any source available which implements this strategy? I'm pretty happy with this idea.</STRONG>

Ooh yuck. I think that Maya does this, but then again Maya's a big program that costs a lot of big bucks (well not that much anymore). Stuff like that just makes me uneasy.

Esp. if this is a small program, I think your best bet is to do a simple registration (taking all the common precautions) that doesn't annoy users. With small programs, people like to transfer them between computers (school/home, work/home) legitimately and be able to use both without noticing the registration scheme after they enter in their SN.

On the other hand, I think eliminating pirated numbers is just fine.

I would be worried about losing users due to their reaction to an elaborate registration scheme!

[iJed]

Originally posted by parallax:
<STRONG>
I would be worried about losing users due to their reaction to an elaborate registration scheme!</STRONG>

I think with a small shareware app you are likely to lose more money through a MAC address based protection scheme than through pirated serial numbers.

[3R1C]

Hmmmm. Well what if the serial number was the users credit card number? not derived from their credit card number, but the users actual credit card number. Then they would have a real need to guard it and not pass it out.

[parallax]

Originally posted by 3R1C:
<STRONG>Hmmmm. Well what if the serial number was the users credit card number? not derived from their credit card number, but the users actual credit card number. Then they would have a real need to guard it and not pass it out.</STRONG>

That violates their privacy somewhat.

[3R1C]

No it doesn't. The only way it could violate their privacy is if they give it out. And furthermore they would then deserve any negative ramifications that may occur.

[ 04-25-2002: Message edited by: 3R1C ]

[mattcunnane]

Originally posted by 3R1C:
<STRONG>Hmmmm. Well what if the serial number was the users credit card number? not derived from their credit card number, but the users actual credit card number. Then they would have a real need to guard it and not pass it out.</STRONG>

Aside from privacy issues, this isn't really possible. One needs to have some way or verifying a serial number is legitimate (I've never dont this, but I'm gessing you would generate a checksum).

If you just use credit card numbers, anyone could download the software and plug in *any* valid credit card number.

I like the keyfile idea. Are there any examples of this in use?

Matt

[3R1C]

not so. the app would contact my server and check its list of paid users. if the number checks out, the app would run. if not the app wouldnt run.

my app NEEDS the internet to function so connecting to the net is a non-issue.

as far as privacy is concerned, th number is known by only myself and the user.

[ 04-25-2002: Message edited by: 3R1C ]

[Person Man]

Originally posted by 3R1C:
<STRONG>not so. the app would contact my server and check its list of paid users. if the number checks out, the app would run. if not the app wouldnt run.

my app NEEDS the internet to function so connecting to the net is a non-issue.

as far as privacy is concerned, th number is known by only myself and the user.

[ 04-25-2002: Message edited by: 3R1C ]</STRONG>

Some companies have tried a "phone-home" approach, and have gotten a HUGE backlash from people... bad move. It's called "spyware." Visit Macintouch for a story on a program with such a registration scheme to see why it's bad:

Macintouch Special Report

Also, you may want to visit ResExcellence for some info from someone who has made his software "pay-what-you-think-it's-worth-to-you-ware" and how that has made people less likely to pirate the software.

ResExcellence April 25, 2002 RealBASIC Article

[3R1C]

Well I guess I'm fighting a losing battle. This thread has convinced me that trying to lessen piracy of our software is not possible. Im not really a proffessional developer, I'm just a user that started mucking around with programming with his best friend. For me, I'll just stick to being a 'user' . As it now stands, I dont think we will release our product anymore,
Soooo, I guess you guys... win?

[Person Man]

Originally posted by 3R1C:
<STRONG>Well I guess I'm fighting a losing battle. This thread has convinced me that trying to lessen piracy of our software is not possible. Im not really a proffessional developer, I'm just a user that started mucking around with programming with his best friend. For me, I'll just stick to being a 'user' . As it now stands, I dont think we will release our product anymore,
Soooo, I guess you guys... win?</STRONG>

Nah... your product may be quite useful and welcome, but the fact is, if you're going to sell a software program, you have to realize that people will pirate it no matter what kind of registration scheme you use.

It seems to me that you're proposing protection schemes that would just get in the way of letting the legitimate users use it simply. Stick with a "simple" registration system that doesn't require the program to contact a central server (way too many privacy issues), and take a proactive approach to protecting your programs.

People will pirate your software no matter how easy or complex your registration scheme is, it's just a fact of life. Complex schemes can cause more headaches for legitimate users than simpler ones do.

For the one part, I think you should take a look at the ResExcellence article I linked to above... I had never heard of a registration scheme where you could "name your own price" for the reg code. It seems like a valid way of doing things, and he seems to have made money in the process.

Don't let the fact that some people will/could pirate your software keep you from releasing it. There is no such thing as a truly "foolproof" method of protecting something.

[Person Man]

Oh, and one more thing...

Don't assume that all us "MP3 Hounds" are pirates.

I have an extensive collection of Greek Music in MP3 form (over 2000 songs), and ALL of it legitimately purchased.

[3R1C]

I never said that ALL mp3 hounds are pirates, but I'll betcha a nickel that their propensity is greater.

[torifile]

Originally posted by 3R1C:
<STRONG>Well I guess I'm fighting a losing battle. This thread has convinced me that trying to lessen piracy of our software is not possible. Im not really a proffessional developer, I'm just a user that started mucking around with programming with his best friend. For me, I'll just stick to being a 'user' . As it now stands, I dont think we will release our product anymore,
Soooo, I guess you guys... win?</STRONG>

Don't do that. So you get some pirated copies out there. If the app is good enough people will pay. You could require some type of protection that requires some hacking to get rid of and that will be enough to prevent someone from just using surfer's serials. But don't give up on it. What's the app, anyway? Is it that good?

[awe]

Originally posted by mattcunnane:
<STRONG>

I like the keyfile idea. Are there any examples of this in use?

Matt</STRONG>

The keyfile method was widely used with shareware on the Commodore Amiga.

A pal of me developed a shareware MIDI tool for the Amiga. I helped him to develop the protection scheme. The protection scheme got really safe and was never cracked.

Another trick to make the key file even more secure:
Pack the whole keyfile with a private compression algorithm. This way the pirate has
A&lt; to develop a decompression tool [possible by disassembling the app].
B&lt; to develop a compression tool to create a keyfile once he has figured how he can manipulate the decompressed keyfile.

The question is if there are any pirates on the mac that are that clever... I believe not.

awe

[tie]

Originally posted by 3R1C:
<STRONG>Hmmmm. Well what if the serial number was the users credit card number? not derived from their credit card number, but the users actual credit card number. Then they would have a real need to guard it and not pass it out.</STRONG>

You seem a little paranoid about people illegally using your product. That's fine, but you should expect users to be equally paranoid in their own ways. I would never use a $7 program that stored my credit card number in its preferences file on my hard disk. I would never use a $7 program that broadcasts my credit card number across the Internet and stores it in an online database. You could implement your own encryption scheme (server sends random number which is added to credit card number, then sent back encrypted with secret key), but can you really trust home-rolled schemes like that? (For example, what is this secret key?) You can use SSH, but that might be expensive for you. Just some thoughts.

[Gametes]

So, if you're still around, did you release your project? What have the results been, and what scheme did you select?

[Rickster]

Didn't notice this thread the first time around. Responding to the original question for posterity...

I'd go for the serial number method. If your registered version is a separate executable, once it gets leaked the cat's out of the bag and you don't know who leaked it. With a serial number, you can find out which numbers have leaked to the pirate community and block them in future releases. (Don't assume, however, that the original owner of a pirate serial deliberately leaked it and penalize them. There are plenty of ways it could get out with the original owner completely innocent.)

I've noticed that you can get a bit of extra piracy-deterrent value by basing the registration code on the customer's email address. They have to use a valid email address or else they won't get the code emailed to them by your online store. And if they want to intentionally "leak" their code, they'll have to give away their email address -- something most savvy net users these days are careful about lest they get spammed. (Granted, this is easy for a determined pirate to work around, but it's a nice deterrent that combined with others helps to cut down on casual piracy.)

The most you can ever do with a registration scheme is keep honest people honest -- there will always be piracy. The good news is that shareware piracy isn't a huge problem. For one thing, there's a certain "critical mass" a shareware product has to reach before it'll start making the rounds in pirate circles; it's possible to have a product which is popular enough to be successful without being popular enough to make it into Surfers Serialz. And even if there is some piracy going on, a quality product will always be able to find a sizable base of honest customers.

[asmodeus]

As a sidenote, back when I was heavily into Windows gaming, I used to buy pretty much every game I played, which was quite a few. Meanwhile, most people I knew, especially at the LAN parties I went to, just copied their software off everyone else.

I had a harder time with my bought games than everyone else did with their warez games. Since then I've been somewhat against anything more than serial numbers. It was mainly the ugly 'original CD only' and CD must be in drive when playing hack a lot of game producers use.

Even then.... I'm still annoyed about my lost Diablo II serial number.

[dampeoples]

I always wondered if the 'damned' upgrade thing would work. Release your app, then collect all the codes passed around, via serial surfer or whatnot. Release an upgrade, killing these numbers off. The people would then go back to the old software within an hour, it will be reported, but somehow, have the old version check for these pirated codes as well. This will only work if they tried to update and go back to V1.0, or such, but it might catch a few. Sadly, it seems that no scheme works 100%.
You could stop a few more by having the app automatically check for updates on your server (with a checkbox to turn it off), addign the pirated codes list to the file it checks in the process. Not a problem for honest users, I wouldn't think, it would probably be a small text file of some sort.

[absmiths]

Here is another late comment. I implemented a keyfile scheme where the keyfile contained the user's name and registered address (since payment was only accepted by credit card, the address was very likely to be correct). Once registered, the about box had a registration pane which showed the registered user's name and address. I figured this was good enough protection (someone would have to be willing to give away their name and address to release a keyfile) and I never got any complaints. BTW, the registration process explicitly directed the user to the about box to verify successful registration, so it was immediately brought to their attention that their info was in there without ever having to mention piracy.

I also don't like apps that make threats. Any app which says "Hey, I could erase your hard drive if I wanted" would make me distrustful enough of the author to trash it then and there.

[jBee]

Originally posted by kamprath:
I estimate (through means I won't discuss here) that 40% of the people who download my shareware use a hacked password.

oh, this sounds even worse: spyware i believe is the name, or spying on / invading people's privacy another way of looking at it.

let me imagine - it's an app that makes use of the internet at some point in it's life, and when it does so it does something else aswell: reports home - sending out information about the app's current situation. i've always thought the need for *outbound* firewalls are more important than inbound. this type of thing, to me, represents a true trojan horse (rather than the in my opinion, misnamed trojan horse virusses): it's something you take on board happily and conciously, and behind your back, unbeknowst to you, it does something else (sends out info).

that, to me, what i've just described is far worse than any copy protection scheme you can come up with.

would you be willing to let us know which app you're talking about there please Michael? then i can make sure i avoid it.

[Gametes]

A program isn't bad just because it calls home; it's what it says when it calls that matters.

Checking a license key doesn't seem immoral; sending the user's browsing habits and email address does. Even then, if the user has the opportnity to agree or disagree, then it is always ok.

[davidwb45133]

I'm coming into this discussion from a different angle. I don't mind paying the developer for a good product and a look at my software license database will show I'm a good shareware citizen. What bugs the heck out of me are unreasonable restrictions.

I own a powerbook and a desktop. Traditionally software vendors have recognized that people like me probably aren't using both at once so they allow us to install software on both the notebook and the desktop. Many companies (like Microsoft and Adobe) use network aware schemes that prevent the program from running on both computers at once. That's cool, I can accept that. But recently this attitude has begun to change. Canvas 9 is tied to a single computer and a second full charge license is required to install the software on another computer. This, to me, is unacceptable.

Further, the multi-computer household is becoming the norm. But the software industry is almost completely oblivious. I'm aware of only two products that come with family style licenses - Jaguar and ASM.

[Angus_D]

Originally posted by davidwb45133:
Canvas 9 is tied to a single computer and a second full charge license is required to install the software on another computer. This, to me, is unacceptable.

We do this with BurnoutMenu, since it's only $6.95 and two licenses isn't going to break the bank. We're going to re-assess this though, since some people seem to find it annoying.

[rudynorff]

hello,

i didn't want to start a new post because this might be a stupid question. I've been searching google and looked at different mac-dev-sites, but haven't found an answer.

my question is:
where does one store the serial number if he writes an application. the first thing that came to mind was in the users preference folder. so i looked at my registered apps' preference files, but i couldn't find a key.

i just don't get where i have to store the registration information for my applications.
thanks in advance.

greetings
rudy

[Brass]

Its' entirely up to you. You can store it anywhere you like. If you have very loose registration process (like I do) then your preferences file is probably fine.

For myself, I create a global preferences file (in /Library/Preferences, instead of in ~/Library/Preferes) so that once registered, it is available to all users, not just the user that installed it.

This is suitable in my case, because the rego number can be copies from the application itself easily if the user wants to, so there's no point hiding it on the disk.

However, some tighter schemes may want to make it more difficult for the user to get a copy of the number, and so they might put it in a hidden file in some obscure directory on disk.

You can put it anywhere you want really.

[rudynorff]

Thanks. That's exactly what I wanted to know.

Sincerely,
Rudy