Date:       Fri, 30 Sep 94 13:32:32 EST
Errors-To:  Comp-privacy Error Handler <owner-comp-privacy@uwm.edu>
From:       Computer Privacy Digest Moderator  <comp-privacy@uwm.edu>
To:         Comp-privacy@uwm.edu
Subject:    Computer Privacy Digest V5#041

Computer Privacy Digest Fri, 30 Sep 94              Volume 5 : Issue: 041

Today's Topics:			       Moderator: Leonard P. Levine

                         Eastwood Door Problem
                       Re: Eastwood Door Problem
                       Re: Eastwood Door Problem
                       Re: Eastwood Door Problem
                       Re: Eastwood Door Problem
                       Re: Eastwood Door Problem
          Info on CPD, Contributions, Subscriptions, FTP, etc.

----------------------------------------------------------------------

From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 28 Sep 1994 20:53:39 -0500 (CDT)
Subject: Eastwood Door Problem
Organization: University of Wisconsin-Milwaukee

A condominium, let's call it Eastwood, is planning to electrify 
the outside locking of its door system.  What will be installed 
is electrical latches controlled by computers which have loaded 
into their memories a list of some 600 numbers assigned to the 
250 owners of units in the complex.  (Most of the owners have 
more than one key.)  The actual key will be a modern item shaped 
much like a watch battery containing a chip which reports its 
number (24 bit, I believe) when it is inserted into a powered 
socket.  It is called a Dallas Chip.  The connection can be 
easily made just by touching the chip to a ring set into the 
doorjamb.  Technically, the key is equivalent to a credit card, 
but is currently more difficult to duplicate and easier for a 
non-dexterous person to use.

If the key number is in the list, the door opens and the key 
number, the time of entry and date are recorded in the computer 
RAM.  Up to 1000 such entries can be stored.  If the key is not 
in the list, the door does not open but the key number and time 
are recorded and alarms can be set.  

The entry data can be copied into a desktop microcomputer from 
time to time allowing it to be held for any period desired.

A good question might be asked.  "How long should the data be 
kept, who should be allowed to see it before it is deleted, and 
under what conditions should the data be made available?"  

Investigation has shown that this question is rarely, if ever, 
asked.  The data points are collected only to help detect the 
perpetrators of theft and vandalism and to secure the structure.  
They are not collected to identify the comings and goings of the 
residents, to aid lawyers in divorce cases, satisfy the curious, 
or collect statistics on wear and tear on the door latches.

I (a college professor) gave this problem to my class in Computer 
Ethics.  What follows are some of the responses by students in my 
class.  I am presenting them here in order to open discussion in 
this privacy forum.  I think the topic should be of interest.

--
Leonard P. Levine               e-mail levine@cs.uwm.edu
Professor, Computer Science        Office 1-414-229-5170
University of Wisconsin-Milwaukee  Fax    1-414-229-6958
Box 784, Milwaukee, WI 53201       


------------------------------

From: "Student #1" <levine@blatz.cs.uwm.edu>
Date: 28 Sep 1994 20:54:41 -0500 (CDT)
Subject: Re: Eastwood Door Problem
Organization: University of Wisconsin-Milwaukee

Arising from the implementation of a new door-lock security system at
the condominiums are key ethical issues that should be discussed, such
as:  should the data from the keys be kept, and if so, for how long,
and should the public have knowledge of this data?

One should consider why to keep the data in the first place.  Clearly,
this is a security system, therefore data will need to be kept for some
amount of time for various security-related issues and possible legal
issues.  It can be seen that for any legal action to occur, or any
action relating to security, data will definitely need to be kept.

Now that it can be seen that data needs to be stored, other questions
arise, such as how long is this data to be stored?  Viable suggestions
are:  one day, one week, one year, several years, or indefinitely
(forever).  Obviously, if data is to be kept for one day, this would
require the least amount of resources, but the drawback would be that
this would be ineffective for those who are away from their homes for
longer periods of time.  Similarly, one week would still be cost
effective in terms of resources, but once again there are limitations
due to lengthy vacations and the like.  Even a month might not be
enough, but perhaps a year might.  While the disadvantage would be an
increased need for storage resources, a year would, however, provide a
decent enough time frame to cover most legal actions involved.  Several
years would take up a far greater amount of storage resources, not too
mention the fact that it would seem that any legal action or
security-related action that had not already occurred after one year
would be pointless.  Forever would once again adhere to these same
reasons, along with the fact that as the amount of storage increases,
so do costs.

Another such question to consider is if the public be informed of
this.  I use the term ``public'' here to mean the residents of the
condominium.  First off, should the data be made available, in any
form, to the public?  Making the data available would most likely be
seen as a breach of privacy and security, one could know who was where
and at what times.  Privacy would be violated, and security would be
too, for one could look for patterns in residents' comings and goings
and pick optimal times to break in to their condo.  On the other hand,
having the data available to the public also could provide some
security benefits by allowing the residents to see who was attempting
to enter their areas, but this most likely would not be seen by the
public as enough to counter the effects of having their privacy
violated.

Secondly, should the public be even told that the data is being kept?
While it may be obvious that the data is being kept, informing the
public if it is to be kept may upset those patrons concerned with
privacy.  Conversely, having this knowledge in advance may support the
improved security.  Since information is being kept about the tenants,
it would be wise to state in the contract that data from the door-locks
is kept, but stated that its purpose is for security of the complex
only, and that eventually the data is erased.

In conclusion, making the public have knowledge about the keeping of
the data is is recommended, while posting the data is not.  Keeping the
data for one year is also recommended, for the reasons stated above.


------------------------------

From: "Student #2" <levine@blatz.cs.uwm.edu>
Date: 28 Sep 1994 20:55:58 -0500 (CDT)
Subject: Re: Eastwood Door Problem
Organization: University of Wisconsin-Milwaukee

With this statement I will outline to you, the board of Eastwood
Condominiums, what our options are for retaining data being collected
with the installation of our new electronic key system.

There are many alternatives regarding the duration of data retention.
The maximum amount of time the records are kept is only limited by the
amount of disk space we have available.  The information could
conceptually be kept for as short as a day, or as long as eternity.
However, each timeframe has a different level of practicality to suit
our purposes.  Keeping the data until the end of the day eliminates any
storage costs but defeats our purpose for installing this system.  We
would have no way of recalling certain dates if the need were to
arise.  Retaining it for a week or even up a month may be adequate, yet
we must keep in mind that some crimes may go undetected for months.
The data must be kept for a long enough period that will allow us to
recall the time during which a suspected crime has occurred.  In my
estimation, six months to a year is a sufficient amount of time to keep
the records for our purposes.  Anything beyond that can also be
implemented, but doing so could be cause for anyone to question our
motives for retaining the data.

When making the decision on the length of data retention, it is
important to keep in mind why we are doing this.  If our reason for
keeping the records of who accesses what areas of the complex is to
deter crime, is it necessary to keep the data for years on end?  I
think not.  I also believe we must state to our tenants what we are
doing with this information, why we are keeping it, and for how long.
Announcing the data is being kept and what the purpose of that action
is will lead to heightened awareness and, ultimately, less crime in our
buildings.  Furthermore, informing residents why we are keeping the
records for a specific timeperiod should eliminate most questions that
may be raised about this data retention violating our tenants' right to
privacy, not to mention preventing various requests for data unrelated
to criminal investigations.  Our goal in installing this system is to
be able to track down those parties responsible for any theft or
property damage in our buildings, as well as deter crime altogether.
It is not our intent that it be used to find out if a husband is
cheating on his wife or if a teenage girl is seeing a boy in another
building against her parents' wishes, for example.  Therefore, the only
time this data should be examined is when a theft or vandalism
complaint has been filed with the police department, or if a resident
has a legitimate reason to believe their key unit isn't working
properly.  All other requests to examine the records should be denied.

In summary, I recommend we retain the data no less than six months but
no more than a year, for that seems the most practical timeframe for
our purposes.  Furthermore, I advocate that we fully inform our tenants
of our intentions and clearly state to them our retention and
disclosure policies.


------------------------------

From: "Student #3" <levine@blatz.cs.uwm.edu>
Date: 28 Sep 1994 20:57:19 -0500 (CDT)
Subject: Re: Eastwood Door Problem
Organization: University of Wisconsin-Milwaukee

                           Ethics in Computing
                               262-657-002
                    Assignment 1a, September 20, 1994
                                    
                            EASTWOOD COMPLEX
                                    
            Policy Regarding the Building and Door Access and
                             Record Keeping 

                Recommendations to the Board of Directors

1.   A 24-hour electronic key door access system will be installed in your 
     complex.  Residents would have to use this device (about the size of a 
     quarter) to enter into their building.  Every electronic key will have 
     a unique identification number.

2.   Except for the Board of Directors and a few people appointed by them, 
     a resident can only enter his/her building or their area.

3.   Data will be collected and stored for every entry into any of the 40 
     doors, 24 hours a day.  A record contains the key identification number, 
     the date, the time and the door number through which the person entered.  
     This data will be collected every day or week depending on the traffic 
     of that particular door.  Each door reader is capable of handling 20 
     entries. After that  it has to be down loaded and saved in our main 
     computer.

4.   The records will be kept for one year before being destroyed.  

     An opportunity to report problems should be given to all the residents.  
     As you are aware, some of your residents take the winter off.  
     Three-to-six months is too short.  It is reasonable  to expect your 
     owners to check their apartments at least once a year.  If something goes 
     wrong, the logs can be back tracked.

5.   This system is intended to prevent burglaries and keep unwanted elements 
     out of the Eastwood area.  The data collected will be used for this sole 
     purpose ONLY.  The data may not used for any other purpose.  
     
     Keeping the data for only one year helps in avoiding unnecessary 
     complications, such as law suits, court orders and archiving.  In my 
     opinion,  it should not be forgotten that we are trying to
     secure  your complex (of burglaries, physical assaults or  property 
     damage) and not judge moral and ethical standards of the residents.  

6.   Please report all burglaries, unwanted happenings and the loss or theft 
     of your electronic key immediately to the Eastwood complex management.  
     This has to be encouraged, especially the latter.  

7.   The Board of Directors reserve the right to  change the above rules as 
     warranted. If any incident occurs out of the limits of this policy, the 
     Board of Directors would act at their discretion, maintaining  the 
     integrity and the security of the Eastwood Complex.


------------------------------

From: "Student #4" <levine@blatz.cs.uwm.edu>
Date: 28 Sep 1994 20:58:55 -0500 (CDT)
Subject: Re: Eastwood Door Problem
Organization: University of Wisconsin-Milwaukee

Policy for the New Key Access to Condominiums

The main question in the new electronic key access system, is how long
to keep the data of who unlocks which door(s).  The reason why a new
system is being considered, is because the tenants do not feel safe
with so many keys in circulation since the creation of the
condominiums.  Many occupants go away for a weekend on up to a couple
of months.  It may not be realized until their return that their place
has been broken into, so the data should not be erased daily or
weekly.  Also there is no need to keep the data forever because the
cost of keeping it would be too great for any use it would have.  Even
the law has its statue of limitations.  I would recommend to save the
data for about three years.  This way if the information is needed for
any criminal investigation or the like, it will be there.  Also if the
data may be forecasted to be needed longer than that, there can be a
formal request made to the board of directors which would decide to
save that particular date(s) of data or not.

Another concern of the tenants will be the ethical limits on the saving
of the data.  They do not want everyone to see when and where they are
coming and going.  The daily outputs of key uses should neither be
posted nor accessible to everyone.  But there should be signs posted at
every entrance stating the length of time the records are kept.  There
should also be either one or two people, appointed by the board, to be
in charge of the data.  These people will be required to keep this
information confidential.  The only people that should have a right to
request this information is the tenants and the police department.
There will be another formal request along with approval of the board
to receive it.  Also, if the board of directors would want any of this
information, they would have to get approval from the tenants present
at the next meeting.


------------------------------

From: "Student #5" <levine@blatz.cs.uwm.edu>
Date: 28 Sep 1994 21:05:16 -0500 (CDT)
Subject: Re: Eastwood Door Problem
Organization: University of Wisconsin-Milwaukee

Dear Sirs and Madams,

Please find contained in this letter technical and personal viewpoints
of mine on the pressing problem of computerized security in the
complex.

Let me be brief and specify clearly the dimensions in data storage:

(1) Assuming that every person of the complex would have a master key,
each with its own unique password (128 bits for each), for every usage
of door we would need to store the number, and the time and date of
opening (32 bits in all). This entails a storage of 160 bits for each
door usage; viz 20 bytes.

(2) I estimate about (worst case), roughly 2500 door openings a day.
That would result in a storage need of about 50,000 bytes = 50KB odd.
This is very reasonable, since even the smallest capacity floppy can
hold about 360KB.

(3) I suggest that we keep this data for about 6 months, or even a
year, which would need a storage of about 11MB-15MB at worst. Even with
a backup, it would consume less than 40MB; the size of the smallest
hard drive.

Having stated the technical aspects, let me take this opportunity to
state some ethical considerations I feel pertinent to the situation:

  (1) I am particulary concerned about the period for which data is to
  be kept. The fear is that of someone innocent being incriminated in
  the event of some incident. As an example, someone frequently
  entering the building (for some legitimate reason) at an unearthly
  hour may seem very suspicious because of the huge data set. Thus,
  attempts should be made to minimize the data store.  The best time
  period would of course boil out once the system has been in operation
  for a considerable period of time.

(2) Lastly, I would re-emphaszie a strict overview of the algorithms
used in the system, and also to whom this data is accessible, and
when?. Attempts should ideally be toward the privacy of all concerned,
without compromising security of the complex.

Board of Directors,
Eastwood Apartments.

Dear Sirs and Madams, 

In response to my letter to the board, dated Sept 8, you had expressed
interest in further details about the range of acceptable values, and
the reasons behind them; as regards the Lock Problem.  Please find the
same in this letter.

In my first letter, I had expressed concern about protecting privacy
without compromising security. With that in mind, following are 3
different suggestions about the period of data-storage, and spanning a
range:

(1) 2 Months: can be termed as an absolute minimum requirement.  Upon
an incident, data would be available upto 2 months back. This would
bring to light any suspicious activity going on over a considerable
time period. It would also enable us to get fairly decent statistics
about door usages. Finally, being a short time-period, privacy of data
is maximized (as far as possible) and probability of an erroneous
suspect reduced.

(2) 6 Months: The suggestion above seems to work pretty well on paper;
but has its disadvantages. It could be argued that the best strategy
for our security system would be to learn from it. As an example: a
particular door may be the most-used door in the complex.  Hence,
attention/weightage has to be given to it. This fact boils out best out
of a half-yearly/per-season basis; something which the first scheme
fails to deliver. The best part of keeping all the data is that various
kinds of statistics could be obtained.As an example, "the usage of the
garage door by 5th floor residents". Further on, 6 months and control
of data would ensure sufficient privacy. Aside that, data storage over
the period is very feasible. It works out at worst to about 20MB (half
the size of the smallest hard-drive in the market).

(3) 1 Year: Extending the case, a year would be a nice period.  Nice,
in the sense that we can collect data and prepare yearly statistics.
We may even be able to contrast this with state-wide/nation-wide
statistics about door-usages in apartments, as well as any breakages
that occur.  In comparison with the second scheme, this would also
provide us with intra-seasonal statistics. Of course, we have to be
more careful about privacy issues here; as well as about arriving at
wrong inferences.

In conclusion, I should probably re-state the need for being judicious
about the type of statistics we produce. Privacy should be conserved as
far as possible. Also, the best time period for data would emerge, once
the system has been operational for a considerable time. It is my hope
that I have clarified the issues further.


------------------------------

From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 26 Sep 1994 12:45:51 -0500 (CDT)
Subject: Info on CPD, Contributions, Subscriptions, FTP, etc.
Organization: University of Wisconsin-Milwaukee

The Computer Privacy Digest is a forum for discussion on the effect of
technology on privacy or vice versa.  The digest is moderated and
gatewayed into the USENET newsgroup comp.society.privacy (Moderated).
Submissions should be sent to comp-privacy@uwm.edu and administrative
requests to comp-privacy-request@uwm.edu.

If you read this from the comp.society.privacy newsgroup and wish to
contribute a message, you should simply post your contribution.  As a
moderated newsgroup, attempts to post to the group are normally turned
into eMail to the submission address below.

On the other hand, if you read the digest eMailed to you, you generally
need only use the Reply feature of your mailer to contribute.  If you
do so, it is best to modify the "Subject:" line of your mailing.

Contributions generally are acknowledged within 24 hours of
submission.  An article is printed if it is relevant to the charter of
the digest.  If selected, it is printed within two or three days.  The
moderator reserves the right to delete extraneous quoted material.  He
may change the subject line of an article in order to make it easier
for the reader to follow a discussion.  He will not, however, alter or
edit or append to the text except for purely technical reasons.

A library of back issues is available on ftp.cs.uwm.edu [129.89.9.18].
Login as "ftp" with password identifying yourid@yoursite.  The archives
are in the directory "pub/comp-privacy".

People with gopher capability can most easily access the library at
gopher.cs.uwm.edu.

Mosaic users will find it at gopher://gopher.cs.uwm.edu.

Older archives are also held at ftp.pica.army.mil [129.139.160.133].

 ---------------------------------+-----------------------------------------
Leonard P. Levine                 | Moderator of:     Computer Privacy Digest
Professor of Computer Science     |                  and comp.society.privacy
University of Wisconsin-Milwaukee | Post:                comp-privacy@uwm.edu
Box 784, Milwaukee WI 53201       | Information: comp-privacy-request@uwm.edu
                                  | Gopher:                 gopher.cs.uwm.edu 
levine@cs.uwm.edu                 | Mosaic:        gopher://gopher.cs.uwm.edu
 ---------------------------------+-----------------------------------------


------------------------------

End of Computer Privacy Digest V5 #041
******************************
.