[comp.protocols.appletalk] Idea for painless copy protection

roy@alanine.phri.nyu.edu (Roy Smith) (01/27/91)

	Let's say I wanted to market commercially a Mac program and have
some way to discourage pirating.  Copy protection is out, since it doesn't
allow for backups, or lost/damaged distribution media.  But, what if I did
the following?

	When the program starts up, it installs something which listens for
broadcast packets to a specific port (my knowledge of appletalk is sketchy,
but this is easy to do in IP and I'm assuming AT has some similar
mechanism).  The program then sends out a broadcast packet to that port and
listens for any responses.  The responses it would get back would contain
the serial number of other copies of the program installed elsewhere on the
same AT network.  If any S/N matched that of this copy, it would refuse to
run.

	Let's not get into a philosophical debate about the ethics of
pirating and/or selling software, I'm just looking for comments on the
technical issues.  First, would it work?  Obviously, people could use
ResEdit to change the serial number, but I'm assuming that anybody who can
use ResEdit would find a way to get around any license scheme if they tried
hard enough; I'm out to get the casual pirater, the guy who buys one copy of
an application and passes it around the office/department/lab/classroom.  It
also wouldn't stop people from taking a copy home, but assume for the moment
that the application came with an enlightened license (like the one that
comes with Think C) which explicitly allows you to install it on two
machines as long as there is no chance both copies will be in use at the
same time (I interpret that as meaning it's OK to install it on both your
office Mac and your home Mac).

	Second, would it be a Bad Thing for the network?  I could see how it
might result in a flood of synchronized responses clogging the wire
momentarily, but it wouldn't be any different than how Inter*Poll interacts
with Responder, would it?  It would only happen once per launch, so I would
guess that would minimize the damage.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"

jim@nature.berkeley.edu (01/28/91)

In article <1991Jan27.144523.20674@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes:
>
>	Let's say I wanted to market commercially a Mac program and have
>some way to discourage pirating.  Copy protection is out, since it doesn't
>allow for backups, or lost/damaged distribution media.  But, what if I did
>the following?
>
>	When the program starts up, it installs something which listens for
>broadcast packets to a specific port (my knowledge of appletalk is sketchy,
>but this is easy to do in IP and I'm assuming AT has some similar
>mechanism).  The program then sends out a broadcast packet to that port and
>listens for any responses.  The responses it would get back would contain
>the serial number of other copies of the program installed elsewhere on the
>same AT network.  If any S/N matched that of this copy, it would refuse to
>run. ...

Already been done, at least twice.   Check out KeyServer (developed by 
Denis Devlin of Dartmouth, and used on thousands of machines there).
It is now marketed by Sassafras Software.

  Contact: Denis Devlin at Sassafras Software, Inc.,   
  PO Box 150, Hanover, NH, 03755 (603) 643-3351. 
  Internet: denisd@dartmouth.edu
  Bitnet: DDEVLIN@DARTCMS1.BITNET
  AppleLink: D4989

KeyServer handles the details a bit differently from what Roy Smith outlines,
but essentially provides the same functionality.

LaunchBreak, developed at the University of Michigan, also provides the
fuctionality Roy Smith describes.  It is free.

Jim Bradley, CNR Computer Facility, UC Berkeley

starta@tosh.UUCP (John Starta) (01/28/91)

roy@alanine.phri.nyu.edu (Roy Smith) writes:

> [...]
> 	When the program starts up, it installs something which listens for
> broadcast packets to a specific port (my knowledge of appletalk is sketchy,
> but this is easy to do in IP and I'm assuming AT has some similar
> mechanism).  The program then sends out a broadcast packet to that port and
> listens for any responses.  The responses it would get back would contain
> the serial number of other copies of the program installed elsewhere on the
> same AT network.  If any S/N matched that of this copy, it would refuse to
> run.
> [...]

Similar methods are already in use by several companies and it works 
painlessly. I certainly believe that if protection is necessary, this is
the way to do it.

John

--
John A. Starta        Internet: tosh!starta@asuvax.eas.asu.edu
Software Visionary        UUCP: ncar!noao!asuvax!tosh!starta
                           AOL: AFA John; CompuServe: 71520,3556

peirce@outpost.UUCP (Michael Peirce) (01/28/91)

In article <1991Jan27.144523.20674@phri.nyu.edu>, roy@alanine.phri.nyu.edu (Roy Smith) writes:
> 
> 	Second, would it be a Bad Thing for the network?  I could see how it
> might result in a flood of synchronized responses clogging the wire
> momentarily, but it wouldn't be any different than how Inter*Poll interacts
> with Responder, would it?  It would only happen once per launch, so I would
> guess that would minimize the damage.

You need to be very careful how you implement this.  I know there
are programs out there at do this (generally) already and I've heard
complaints about how they adversely affect some networks.

Keep in mind that LocalTalk networks don't really have alots of band
width to spare and can be adversely affected by lots of NBP lookup activity.

Many schemes that work for a small network fall apart for larger nets
- think about doing NBP lookups on a network with 50 different zones
or more (they're are many of these size networks out there) and waiting 
for that on every launch!

Of course if you limit this to only wreak havok at application launch
it's very easy to work around (just turn of the network while you
launch it, then turn it back on).  The more robust you make the copy
protection the more network effect you end up having.

Ther'se also the idea of a "license server" where you have the application
check in with a server that gives out permission to run and keeps
track of how many copies are running.  But then you're tied to having
a network that's up and running or the user can't even launch your
product.  It also don't control total users, just concurrent use -
very different.

There are probably some workable systems out there for this type of
thing, but please consider the consequences that your users will have
to deal with in a variety of environments.  If you make it too hard
on them they might just drop your product and switch to one that doesn't
have the disadvantages your does.

-- michael


--  Michael Peirce         --   outpost!peirce@claris.com
--  Peirce Software        --   Suite 301, 719 Hibiscus Place
--  Macintosh Programming  --   San Jose, California 95117
--           & Consulting  --   (408) 244-6554, AppleLink: PEIRCE

lippin@ragu.berkeley.edu (The Apathist) (01/28/91)

Recently roy@alanine.phri.nyu.edu (Roy Smith) wrote:
>	When the program starts up, it installs something which listens for
>broadcast packets to a specific port (my knowledge of appletalk is sketchy,
>but this is easy to do in IP and I'm assuming AT has some similar
>mechanism).  The program then sends out a broadcast packet to that port and
>listens for any responses.  The responses it would get back would contain
>the serial number of other copies of the program installed elsewhere on the
>same AT network.  If any S/N matched that of this copy, it would refuse to
>run.

First, this can be streamlined to cut down on network traffic: put the
serial number of the just-starting copy in the broadcast packet, and
have the others reply only if their numbers match.

Several current products use a scheme like this.  With most, the copy
protection is innocous during ordinary use, although a few, through
sloppy programming, introduce a noticeable network load.

There are problems, however.  A legitimate user may be unable to start
the program because someone else is running with his serial number.
On a large network, it may be difficult to track down the offender.

Network managers must keep track of where all the serial numbers are
being used -- if one copy is destroyed, they have to reinstall it with
the right serial number.

On some networks, notably those in university labs, people move from
one machine to another often, and it's not practical to buy a copy for
every machine unless the program is very popular.  These people would
prefer that you limit the number of copies in use, but in a way that
doesn't specify which ones must be used.

If the serial number is embedded in the program, rather than entered
by hand, more problems arise.  Backups must be kept of each of the
original disks.  The program can't be distributed through a server --
the right set of floppies must be delivered to each computer.  And
site licenses become awkward, as you must deliver a set of disks for
every copy licensed.

A solution to some of these problems is to give each copy a file
containing a list of serial numbers it can attempt to register under.
The program could try each in turn, listening for complaints from the
previously running copies.  This file could be the same for everyone
on the network, or some people could have private numbers present only
in their file.

					--Tom Lippincott
					  lippin@math.berkeley.edu

		"Self meets Self at a cocktail party,
		 exchanges business cards with Self,
		 and thus becomes Self Proper."
					--Jim Bolin

aland@chaos.cs.brandeis.edu (Alan D Danziger) (01/28/91)

This is a very good idea, but it's been done.  Some programs which do
this are SuperLaserSpool and Disk Express II, which I am aware of
(having tried to save time & effort by installing a whole network from
one disk.) :-)

Also, it only works on networks...

--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alan D. Danziger,           | 753 South St,Waltham MA 02154 | "What a drag,
aland@chaos.cs.brandeis.edu | MB 3130 / Brandeis University |   it is,
(617) 894-6859 or 647-3720  | PO Box 9110 Waltham MA 02254  |    getting old"
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alan D. Danziger,           | 753 South St,Waltham MA 02154 | "What a drag,
aland@chaos.cs.brandeis.edu | MB 3130 / Brandeis University |   it is,

bdugan@teri.bio.uci.edu (Bill Dugan) (01/28/91)

In article <1991Jan27.214310.3870@agate.berkeley.edu> lippin@math.berkeley.edu writes:
>Recently roy@alanine.phri.nyu.edu (Roy Smith) wrote:
>>	When the program starts up, it installs something which listens for
>>broadcast packets to a specific port (my knowledge of appletalk is sketchy,
>>but this is easy to do in IP and I'm assuming AT has some similar
>>mechanism).  The program then sends out a broadcast packet to that port and
>>listens for any responses.  The responses it would get back would contain
>>the serial number of other copies of the program installed elsewhere on the
>>same AT network.  If any S/N matched that of this copy, it would refuse to
>>run.
>
>[...]
>There are problems, however.  A legitimate user may be unable to start
>the program because someone else is running with his serial number.
>On a large network, it may be difficult to track down the offender.
>
>Network managers must keep track of where all the serial numbers are
>being used -- if one copy is destroyed, they have to reinstall it with
>the right serial number.

Another problem, of course, is that this type of copy protection is
very easy to crack.  All you have to do is write an INIT that patches
the AppleTalk send calls; just kludge it to search for search string n
that is made by the copy-protected application, and change a couple
chars, and suddenly you have a request that nobody will respond to.
As a network manager, if I were confronted with the necessity of keeping
track of 400 copies of a program with all the serial numbers, I would
seriously consider investing time in such a hack.

bill

milton@en.ecn.purdue.edu (Milton D Miller) (01/28/91)

Look at the thread "SCO TCP/IP copy protection" currently running
in comp.procools.tcp-ip.  (Theirs was periodic while running.)

das@Apple.COM (David Shayer) (01/28/91)

I have used several programs that use this form of copy protection.
They are not usually a problem, unless someone on the network has
a pirated copy of your software/serial number.  In a big network
at a corporation or university, this happens often.  My biggest
complaint is that there is no way to track down who is using the
same serial number.  You should absolutely positively tell the user
the zone and machine name of the user who has the same serial number.

Also, as previous posters have pointed out, this is not a good solution
for site licenses.  They should be able to set up a server on the net,
which knows how many copies they are licensed to run.  When a new copy
is launched it checks with the server to see if it is over the licensed
number of copies, and either lets it go or refuses to launch.


Of course, these are just me opinions.

David

bin@primate.wisc.edu (Brain in Neutral) (01/28/91)

From article <2e5Fw1w163w@tosh.UUCP>, by starta@tosh.UUCP (John Starta):
> Similar methods are already in use by several companies and it works 
> painlessly. I certainly believe that if protection is necessary, this is
> the way to do it.

I believe that something like the proposed scheme is used by PC-NFS,
and the customers hate it.  Consider yourself as the person that has
to install the UNIQUE copy on each machine, and having to keep track
of which machine has which serial number.  Think about that for
dozens, or hundreds of machines.
--
Paul DuBois
dubois@primate.wisc.edu

breidenb@Informatik.TU-Muenchen.DE (Oliver Breidenbach) (01/29/91)

hi there,

severeal people mentioned one problem, that is tracking down the offender
when finding that someone already uses my copy.
Actually that is very very easy. Get yourself a traffic watch program
and you can see the peoples names, the nodes number, the serial number of
the programm using that copy protection mode and so on. Then simply look
for the node where your program runs, rememeber the node number and
search for some entry telling you the name or position (whatever name you
give in the chooser). Then all you have to do is to place a lot of flames
on the person who stole your program.

The second thing someone mentioned, was that there will be a fuss about
the serial numbers of the programs...
How about a "site license" and COUNTING the copies of the program running
on the net? Then a message like "Sorry, to many people using this program
right now...". This would cause a lot of traffic on startup, but if you have more than say 20 macs you should use ethernet anyway... and the programs don't have
to cry "I'm here!" all the time, do they?

have fun, anyway

Oliver "Broke" Breidenbach

fortinp@bwdls56.bnr.ca (Pierre Fortin) (01/29/91)

In article <1991Jan27.144523.20674@phri.nyu.edu>, roy@alanine.phri.nyu.edu (Roy Smith) writes:
> 
> 	When the program starts up, it installs something which listens for
> broadcast packets to a specific port (my knowledge of appletalk is sketchy,
> but this is easy to do in IP and I'm assuming AT has some similar
> mechanism).  The program then sends out a broadcast packet to that port and
> listens for any responses.  The responses it would get back would contain
> the serial number of other copies of the program installed elsewhere on the
> same AT network.  If any S/N matched that of this copy, it would refuse to
> run.
> 
This is just the kind of solution which unfortunately will not scale...
Any product which goes out and searches our entire network of 230+ zones and
nearly 3000 Macs for duplicate serial numbers will not be accepted (read:
allowed) on our network.  We have already classed at least one such application 
as "personna non grata"...

If your application is a super-duper whiz-bang program that everyone will want,
then think about site licensing for big networks.

> --
> Roy Smith, Public Health Research Institute


Cheers,                      
Pierre Fortin       fortinp@bnr.ca         (613)763-2598

jjwcmp@isc.rit.edu (Jeff Wasilko) (01/29/91)

In article <48543@apple.Apple.COM> das@Apple.COM (David Shayer) writes:
>I have used several programs that use this form of copy protection.
>They are not usually a problem, unless someone on the network has
>a pirated copy of your software/serial number.  In a big network
>at a corporation or university, this happens often.  My biggest
>complaint is that there is no way to track down who is using the
>same serial number.  You should absolutely positively tell the user
>the zone and machine name of the user who has the same serial number.

There is a rdev that was recently posted to c.b.m or at sumex called
'Who's there' that displays all objects on a network. It displays all of
my XPress users (XPress is copy protected in this method), so it is
possible to see who's using your copy...

FOr what its worth, I have 1 copy of XPress that's liscenced for 15
users. It checks the network for more than 15 copies of itself at
startup. Since I don't have to deal with 15 serial numbers, I really
don't mind this kind of copy protection....

Jeff

-- 
| RIT VAX/VMS Systems: |     Jeff Wasilko     |     RIT Ultrix Systems:     |
|BITNET: jjwcmp@ritvax +----------------------+ INET:jjwcmp@ultb.isc.rit.edu|
|INTERNET: jjwcmp@ritvax.rit.edu              |____UUCP:jjwcmp@ultb.UUCP____|
|'claimer: I speak only for myself. Opinions expressed are NOT those of RIT.|

denbeste@bgsuvax.UUCP (William C. DenBesten) (01/29/91)

From article <1991Jan27.144523.20674@phri.nyu.edu>, by roy@alanine.phri.nyu.edu (Roy Smith):
> 
> 	Let's say I wanted to market commercially a Mac program and have
> some way to discourage pirating.  Copy protection is out, since it doesn't
> allow for backups, or lost/damaged distribution media.  But, what if I did
> the following?
> 
> 	When the program starts up, it installs something which listens for
> broadcast packets to a specific port (my knowledge of appletalk is sketchy,
> but this is easy to do in IP and I'm assuming AT has some similar
> mechanism).  The program then sends out a broadcast packet to that port and
> listens for any responses.  The responses it would get back would contain
> the serial number of other copies of the program installed elsewhere on the
> same AT network.  If any S/N matched that of this copy, it would refuse to
> run.

As a system administrator, I really dislike copy protection, even this
type.  I now distribute software in the following fashion: I modify
the application so that it checks with a really neat program called
launch break (for info, ask launch-break@caen.engin.umich.edu).  I
then copy it to my file server.  Any user that wants to copy the
program to their hard drive may do so.  When they launch the program,
They implicitly ask launch break if there are any copies available.
If there are, they are permitted to run it.

As a system administrator, I am concerned that we are running only
software for which we are licensed, and that we are making the best
use of our available software.  Launch break makes this very easy for
me.  Part of this ease is the fact that I can install just one copy.
I am serious about being legal.  I purchased a computer that spends
its life making sure that we are not running mor than the licensed
number of copies.

Quickmail has (had) your register the serial number 'feature'.  It is
the only thing that I really detest about Quickmail.  I have mail
running on 20 macs.  I dutifully purchased two copies of their program
(which is licensed for up to 10 macs).  I then added quickmail to my
prototypical system folder on my server.  Unfortunately, I had to tell
half of my users to duplicate copy #1 and the other half to duplicate
copy #2.  This was a big headache.

CE Software and I disagree.  I call this a form of copy protection.
They don't.  This is yet another case of the copy protection getting in
the way of legitimate users.

Oh BTW, it is really handy to have a disassembler, resedit and a
understanding of 68000 assembly, but I don't want to talk about that.

-- 
William C. DenBesten   is   denbeste@bgsu.edu  or   denbesten@bgsuopie.bitnet

awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/29/91)

In article <1991Jan28.202316@Informatik.TU-Muenchen.DE> breidenb@Informatik.TU-Muenchen.DE (Oliver Breidenbach) writes:

>Actually that is very very easy. Get yourself a traffic watch program
>and you can see the peoples names, the nodes number, the serial number of
>the programm using that copy protection mode and so on. Then simply look
>for the node where your program runs, rememeber the node number and
>search for some entry telling you the name or position (whatever name you
>give in the chooser). Then all you have to do is to place a lot of flames

Just a small problem with this.  For one thing, most AppleTalk nets aren't 
set up with fixed node numbers.  They get dynamically allocated when the node
registers itself.  For another, we have people changing their chooser names
all the time.  Both of these can be fixed, of course.

starta@tosh.UUCP (John Starta) (01/29/91)

bin@primate.wisc.edu (Brain in Neutral) writes:

> I believe that something like the proposed scheme is used by PC-NFS,
> and the customers hate it.  Consider yourself as the person that has
> to install the UNIQUE copy on each machine, and having to keep track
> of which machine has which serial number.  Think about that for
> dozens, or hundreds of machines.

I don't think your example is suitable for your response. The reason I say 
this is that if you maintain a hundred, or even a dozen machines you should 
have a profile of each machine. Having to note an additional serial number 
is nothing if you maintain reasonable records. And doing so only makes
your job easier in the long run.

John

--
John A. Starta        Internet: tosh!starta@asuvax.eas.asu.edu
Software Visionary        UUCP: ncar!noao!asuvax!tosh!starta
                           AOL: AFA John; CompuServe: 71520,3556

minich@unx2.ucc.okstate.edu (Robert Minich) (01/29/91)

by breidenb@Informatik.TU-Muenchen.DE (Oliver Breidenbach):
| severeal people mentioned one problem, that is tracking down the offender
| when finding that someone already uses my copy.
| Actually that is very very easy. Get yourself a traffic watch program
| and you can see the peoples names, the nodes number, the serial number of
| the programm using that copy protection mode and so on. Then simply look
| for the node where your program runs, rememeber the node number and
| search for some entry telling you the name or position (whatever name you
| give in the chooser). Then all you have to do is to place a lot of flames
| on the person who stole your program.

Better yet, put in a little routine in the program to answer to copies in
a way that is visible to the legal user. I like the idea of a notification
manager dohickey that would put a nasty sicn in the apple menu so that you
could walk around and look over other's shoulders. Or maybe an audible ping
that goes off at a specified offset. Synchronise your watches and look for
the confused face! Or.... or... Just knowing a machine name or node number
may not tell you much, especially on a medium size net.
-- 
|_    /| | Robert Minich            |
|\'o.O'  | Oklahoma State University| "I'm not discouraging others from using
|=(___)= | minich@d.cs.okstate.edu  |  their power of the pen, but mine will
|   U    | - "Ackphtth"             |  continue to do the crossword."  M. Ho

peirce@outpost.UUCP (Michael Peirce) (01/29/91)

In article <1991Jan28.202316@Informatik.TU-Muenchen.DE>, breidenb@Informatik.TU-Muenchen.DE (Oliver Breidenbach) writes:
> 
> hi there,
> 
> severeal people mentioned one problem, that is tracking down the offender
> when finding that someone already uses my copy.
> Actually that is very very easy. Get yourself a traffic watch program
> and you can see the peoples names, the nodes number, the serial number of
> the programm using that copy protection mode and so on. Then simply look
> for the node where your program runs, rememeber the node number and
> search for some entry telling you the name or position (whatever name you
> give in the chooser). Then all you have to do is to place a lot of flames
> on the person who stole your program.

One problem with this idea is the amazing number of people who don't
use their name in the chooser.  I've looked around a number of nets
and you see people called "beach bunny", "superman", and the ever
popular "Mac II".

-- michael


--  Michael Peirce         --   outpost!peirce@claris.com
--  Peirce Software        --   Suite 301, 719 Hibiscus Place
--  Macintosh Programming  --   San Jose, California 95117
--           & Consulting  --   (408) 244-6554, AppleLink: PEIRCE

bin@primate.wisc.edu (Brain in Neutral) (01/30/91)

From article <0B010004.cuc5yi@outpost.UUCP>, by peirce@outpost.UUCP (Michael Peirce):
> One problem with this idea is the amazing number of people who don't
> use their name in the chooser.  I've looked around a number of nets
> and you see people called "beach bunny", "superman", and the ever
> popular "Mac II".

Nor in some cases do I want to see a *person's* name, e.g., on a public
machine, I want to see the *machine's* name, not who is using it.

But anyway, isn't there some utility that locks the chooser name so it
doesn't matter what the user types in the box?

--
Paul DuBois
dubois@primate.wisc.edu

awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/30/91)

In article <wemiw1w163w@tosh.UUCP> tosh!starta@asuvax.eas.asu.edu (John Starta) writes:

>I don't think your example is suitable for your response. The reason I say 
>this is that if you maintain a hundred, or even a dozen machines you should 
>have a profile of each machine. Having to note an additional serial number 
>is nothing if you maintain reasonable records. And doing so only makes
>your job easier in the long run.

This really isn't very practical unless you have an automated system for doing
the profile building, preferable via a network software package.  The more 
machines you have the more likely people are to dink with the System setup.  If
you start locking out changes, you are likely to have even more trouble.  

bin@primate.wisc.edu (Brain in Neutral) (01/30/91)

From article <wemiw1w163w@tosh.UUCP>, by starta@tosh.UUCP (John Starta):
| bin@primate.wisc.edu (Brain in Neutral) writes:
| 
|> I believe that something like the proposed scheme is used by PC-NFS,
|> and the customers hate it.  Consider yourself as the person that has
|> to install the UNIQUE copy on each machine, and having to keep track
|> of which machine has which serial number.  Think about that for
|> dozens, or hundreds of machines.
| 
| I don't think your example is suitable for your response. The reason I say 
| this is that if you maintain a hundred, or even a dozen machines you should 
| have a profile of each machine. Having to note an additional serial number 
| is nothing if you maintain reasonable records. And doing so only makes
| your job easier in the long run.

I agree that good records are essential.  But when one maintains a number
of machines, any single piece of information that must be kept track of
adds to administrative headaches.  Plus, it's not just a number on a piece
of paper that you must maintain.  For the scheme proposed, you have to have
an original disk for every single copy.  This is far less attractive than a
single copy and a site license, or right-to-copy, or license packs.

If somebody trashes their copy, would you rather pull out a disk to replace
it, or have to dig through a whole box of 'em?

I'm not saying it can't be done.  Sure, it can be done.  I'm saying I'd
rather not have to.
--
Paul DuBois
dubois@primate.wisc.edu

rob@uokmax.ecn.uoknor.edu (Robert K Shull) (01/30/91)

In article <1991Jan27.144523.20674@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes:
>
>	When the program starts up, it installs something which listens for
>broadcast packets to a specific port (my knowledge of appletalk is sketchy,
>but this is easy to do in IP and I'm assuming AT has some similar
>mechanism).  The program then sends out a broadcast packet to that port and
>listens for any responses.  The responses it would get back would contain
>the serial number of other copies of the program installed elsewhere on the
>same AT network.  If any S/N matched that of this copy, it would refuse to
>run.
>
>	Let's not get into a philosophical debate about the ethics of
>pirating and/or selling software, I'm just looking for comments on the
>technical issues.  First, would it work?  Obviously, people could use

This would undoubtedly work (there are already some commercial packages
that use this scheme). It does, however, have a major drawback for some
settings. We have about 25 machines running software from a central server.
We run a software package called LaunchBreak which limits the number of
copies of a program in use to a fixed number (set by us). We set this number
to be equal to the number of copies which we legally own.
If a scheme such as you propose is used, we then have a problem. We can
(1) scatter a number of copies of software onto different machines,
and put up signs telling which machines can be used for which applications
(ugly), (2) put multiple copies of the software onto the server, along with
some kind of front end to pick one that's not currenltly in use (more code
to maintain), or (3) hope that the software company makes a "network version"
which will work from our server (so much for the Mac and "integrated
networking") and without deciding we should pay a fortune for it.


Also, LaunchBreak alters the application so that copies which are removed
from the system won't function, so we get automatic copy protection for
the software we use.
If we put the software on the individual machines, everyone can immediately
make copies of it to take home.
So, in our case, this kind of copy protection actually means that more people
will illegally copy the software, since there would be no way to prevent it.

Our policy so far has been to avoid software which uses this method of copy
protection, unless it is requested as a "must have" package (which hasn't
happened yet).

By the way, there are few things as irritating as discovering that you've
got the wrong one of a set of 10 identical, unnumbered disks (thanks, TOPS).
Doesn't exactly make one enjoy using the product.

>with Responder, would it?  It would only happen once per launch, so I would
>guess that would minimize the damage.

If you don't check continuously, there is a trivial way to defeat the
protection. Pull the plug on the AppleTalk line until the program starts up,
then plug it right back in. If you check continuously while the program is
running, then you might end up loading the network (especially on slow
LocalTalk networks).
	Robert
>Roy Smith, Public Health Research Institute

-- 
Robert K. Shull
rob@uokmax.ecn.uoknor.edu				chinet!uokmax!rob

peted@microsoft.UUCP (Peter DUNIHO) (02/02/91)

In article <1991Jan27.144523.20674@phri.nyu.edu> roy@alanine.phri.nyu.edu (Roy Smith) writes:
>
>	Let's say I wanted to market commercially a Mac program and have
>some way to discourage pirating.  Copy protection is out, since it doesn't
>allow for backups, or lost/damaged distribution media.  But, what if I did
>the following?
>
> [question about network based copy protection deleted]
>
>Roy Smith, Public Health Research Institute
>455 First Avenue, New York, NY 10016
>roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy

Well, I don't know about how bad it would be for the network (although,
I think if you only do it when we begin execution or something like that,
the extra load would be minimal), but I know that I've used software
with this kind of protection and it seemed to work pretty well.  It was
CommUnity Mac, which is a software package that lets your Mac look like
a DECNet node on Ethernet.  If I remember correctly, there was some sort
of serialization in combination with a password thing.  I think that the
deal was that we were shipped one product, which would accept several
different passwords to run.  I'm pretty sure the passwords were a enter-once
thing...once you've installed it, you don't have to mess with it unless
you want to change.  As long as you didn't have more than one running
at the same time with the same password, you're cool.  So, if there were
ten possible passwords, you could install the software on everyone's 
machine, and then to change which machines you ran on, you'd just change
the passwords and run them where you want.

Does that make any sense?  I was afraid of that...well, I did _try_ to
keep from being confusing.  Anyway, I guess the answer to you question
is yes, and it's probably practical too!  (Note that the package I was
using was Ethernet based, so the lack of net degradation might not
extend to normal LocalTalk stuff).

Pete Duniho

uunet!microsoft!peted

cbm@well.sf.ca.us (Chris Muir) (02/03/91)

> When the program starts up, it installs something which listens for
> broadcast packets to a specific port...

One thing that bugs me about this method is that some programs,
like Disk Express II, turn on AppleTalk to do their search. This 
plays havoc with MIDI programs, both in timing accuracy and in
port access.

-- 
__________________________________________________________________________
Chris Muir                              |   "There is no language in our
cbm@well.sf.ca.us                       |    lungs to tell the world just
{hplabs,pacbell,ucbvax,apple}!well!cbm  |    how we feel"  - A. Partridge

peter@cs.uwa.oz.au (02/04/91)

Some observations, some questions...

Two basic mechanisms exist for netwide copy protection :
1) Serial number exclusion, and
2) Application counts.

Serial number checking suffers from the "endless horizon" problem. "In what
zone does one stop checking for duplicates ?" 

LaunchBreak is an application counting mechanism that has been proposed as a
solution, and it is nice for two reasons: 
1) It gets around the weak copy protection offered by the latest Finder of
files from AppleShare file servers. LaunchBroken applications cannot be used
removed from the network.
2) By having a copy of the software on your local disk rather than the file
server means fast launch times.

Question : 
Does LaunchBreak handle multiple zones ?

Unfortunately both mechanisms suffer from the "endless idleness" syndrome. With
MultFinder it is very easy for people to forget to quit from applications,
leaving them running and excluding usage by others.

AppleShare uses the Finder attribute "Shared" to determine whether an
application is multi launchable. This is restricted in that an application may
either be single launchable or multi launchable but without any control over
quantity. 

Questions :
Could this bit be turned into a byte, representing the maximum
number of concurrently open copies ? 
Could AppleShare could keep a count of currently open copies ? 
When a user asks for a (n+1)th copy, could AppleShare poll the
applications for idle time and shut one down if appropriate ?

Peter Dodd
Computer Science Department
The University of Western Australia
peter@cs.uwa.oz.au

Aron_Fingers_Nelson@cup.portal.com (03/04/91)

I'd like to make a tiny comment on this "painless" copy protection issue.
Some programs which do this sort of thing (checking for multiple copies on 
a network) automatically turn on AppleTalk to do their c.p. work.  The
problem is, for MIDI (music) users this will screw up serial communication
to the MIDI interface -- I think it turns off interrupts now and then.
In any case, this causes *major* headaches for people in the music world.
I just wanted to bring this up because this *not* a painless copy protection
method.

aron_nelson@cup.portal.com