Date: Mon, 07 Nov 94 22:38:30 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#059
Computer Privacy Digest Mon, 07 Nov 94 Volume 5 : Issue: 059
Today's Topics: Moderator: Leonard P. Levine
Re: Mother's Maiden Name
Re: Digital Signature Alternatives
Re: Digitized Signatures
Re: Discover Card Code?
Re: Discover Card Code?
Re: Discover Card Code?
Re: E-mail Privacy Alert
Re: E-mail Privacy Alert
Re: E-mail Privacy Alert
Re: Info on European Computer Privacy Laws
Re: Info on European Computer Privacy Laws
Must I Always Carry I.D?
Intrusive Supermarket Card
Identity vs. Digital Signatures
Re: Planting "Mistakes" to Guard Copyright
Other People's E-mail (long)
Minnesota Driver License
Re: Sears Captures Signatures
Info on CPD, Contributions, Subscriptions, FTP, etc.
----------------------------------------------------------------------
From: fd@wwa.com (Glen L. Roberts)
Date: 06 Nov 1994 10:07:32 -0600
Subject: Re: Mother's Maiden Name
Organization: WorldWide Access - Chicago Area Internet Services 312-282-8605 708-367-1871
Barry Margolin (barmar@nic.near.net) wrote: If someone steals your
wallet they'll get your Social Security card and credit cards, so
they'll know all the important numbers. It's unlikely that your
mother's maiden name is written down anywhere that a thief would
find it, so it's a common identity check.
And, if the thief, is a little high-tech and rather than risking
exposure by stealing your wallet, simply, steals some data from your
cordless phone calls... he'll have all your good little numbers and
secret codes like your mother maiden name...
It also seems to me that things like one's mother's maiden name is
easily found for many people by a trip to the county clerk, and a check
of the marriage records...
These little "secrets" to protect us... are only as effective as we
believe that they are secret... Even more than protecting us, they make
it EASY for a knowledgeable person to commit fraud, unhindered.
--
Glen L. Roberts, Editor, Full Disclosure
Host Full Disclosure Live (WWCR 5,065 khz - Sundays 7pm central)
email fd@sashimi.wwa.com for catalog on privacy & surveillance.
Does 10555-1-708-356-9646 give you an "ANI" readback?
------------------------------
From: rerodd@unity.ncsu.edu (Richard Roda)
Date: 06 Nov 1994 17:44:04 GMT
Subject: Re: Digital Signature Alternatives
Organization: North Carolina State University
Bob Bales <74774.1326@CompuServe.COM> wrote: Hospitals, banks,
insurance companies and other organizations are looking to replace
paper with electronic documents, but they need a way to "sign"
those documents for legal and control purposes.
A new paper written by noted author, attorney and electronic
commerce expert Benjamin Wright considers the practical features of
two alternative signing methods: smart-card based public-key
cryptography and PenOp, a pen computer technology that captures
handwritten autographs. Wright argues that PenOp holds certain
advantages over public key cryptography.
IDEA: place the handwritten autograph within a public key signed
document and have people who deal with you agree that a document from
you is not valid unless it has been signed with your public key *and*
containes your electronic signaure. This would give the best of both
worlds.
------------------------------
From: ruthann@mitre.org (Ruth Ann Brasie Valentine)
Date: 07 Nov 1994 13:31:14 GMT
Subject: Re: Digitized Signatures
Organization: MITRE
stark@rtsg.mot.com (George Stark) wrote: Gee, that's all we need
now, a digitized version of out signatures that can be hammered
onto documents we've never seen before. What sort of privacy
protection is going on those signatures?
I had this experience, and not wanting to hassle the clerk, asked for
the manager's name an dnumber and called the next business day.
Apparently, retailers are required to keep recordss ofall transactions
for three years. I still said I didn't see why I had to sign and what
were thye doing with the signatures. She gave me the name of the
company doing the computer work for them. It is Nabanco. She also
gave me the customer service number, so I called. They were not happy
to hear from me.
This is what thye said: We keep records for merchants. We void the
sale if a signarute is not recorded within x seconds of the register
transaction. Our service prevents credit card fraud..... etc, etc.
I asked what assurance do I have that my signature will not show up in
some strange place. She said Nabanco would be out of business pretty
soon if that began to happen, so I amsitll not convinced.
There are two ways around this. One, make a mark, any mark in the box,
and then sign the paper in another spot. this circumvents the
cancellation software, because somethinggot captured.
The second (and this has been over the course of a year, only two
instances of this) time I just refused to sign on the electronic
thinggy and she said ok, but asked for my driver's license to see if it
was me.
If enough people just refuse to play the game, merchants will get the
message that *this approach* is not the way to combat fraud!
------------------------------
From: olcay@libtech.com (olcay cirit)
Date: 06 Nov 94 11:10:14 PST
Subject: Re: Discover Card Code?
steve@owlnet.rice.edu (Steven Minor McClure) wrote: Did you notice
the patch of seemingly random dots on the front of the
form?---probably your account number encoded somehow.
Xerox (Or was it IBM?) developed a way of converting ascii into
something that looked like a really complex maze, and it was so robust,
you could scribble all over it and it could translate 100%. I'm not
sure if this is what you are talking about, though.
------------------------------
From: kadokev@rci.ripco.com (Kevin Kadow)
Date: 06 Nov 1994 21:56:48 -0600 (CST)
Subject: Re: Discover Card Code?
Did you notice the patch of seemingly random dots on the front of
the form?---probably your account number encoded somehow. Except
it looks like there's enough detail there to store way more than
the 16 or so digits of the account number. Anybody know what
algorithm they might be using (or what else might be stored there?)
?
I haven't seen the Discover application you mention, but you could be
describing a 2-D barcode, they basically look like a patch of random
square dots.
--
kadokev@ripco.com Kevin Kadow
FREE Usenet/Mail, inexpensive Internet - Ripco... Wearing white hats since 1983
Dialup:(312) 665-0065|Gopher:gopher.ripco.com|Telnet:foley.ripco.com ('info')
------------------------------
From: Jon Green <jonsg@hyphen.com>
Date: 07 Nov 1994 09:36:30 -0500 (EST)
Subject: Re: Discover Card Code?
Steven Minor McClure writes: Did you notice the patch of seemingly
random dots on the front of the form?---probably your account
number encoded somehow. Except it looks like there's enough detail
there to store way more than the 16 or so digits of the account
number. Anybody know what algorithm they might be using (or what
else might be stored there?) ?
Being a Limey, I haven't seen the form in question, but I _have_ worked
extensively in the murky world of barcodes, and I think I can probably
answer the question. The dot-pattern Steven saw was probably a "Dot
Code". This is a square grid of dots, containing multiple
error-correction codes and orientation information, and also a
considerably higher info density than your standard barcode; not
surprising, since the humble barcode encodes one-dimensionally
(usually) whereas a dotcode is 2-D and can occupy a _much_ smaller
acreage for the same or better capacity. You need a digitising camera
to read it, rather than a simple wand, so it's taking a fair time to
come to market. I believe Phillips in the UK (for one) has been
working on it.
--
jonsg@hyphen.com
------------------------------
From: wbe@psr.com (Winston Edmond)
Date: 06 Nov 1994 20:27:03 GMT
Subject: Re: E-mail Privacy Alert
Organization: Panther Software and Research
<rossk@ucsu.colorado.edu> writes: In our experimentation with a
freely available Internet software program, we have discovered that
we can use someone else's e-mail address to mail messages and post
to newsgroups.
Yup. If you're new to the Internet, that probably comes as a
surprise. Another way to say it is that it's pretty easy to forge
anyone's name to anything that goes over the net. That's why:
(1) there's research into digital signatures, and authentication (e.g.,
PGP), particularly ones that can't be spoofed by capturing IP packets
and playing them back later (e.g., Kerberos); and
(2) it's next to impossible to take legal action on the basis of email,
because you either have to get the person you're suing to admit sending
the message(s), or you have to prove they weren't faked (in the face of
common knowledge that forgery is not that hard).
That's also why incremental improvements in tracing (e.g., the
Received-by: lines in email) were implemented. It's why people use
the Path: header in newsgroup message when they're trying to figure out
where a forged message really originated (and there are lots of such
messages around April 1 each year).
Fortunately, most of the time the message either really did come from
who it says it came from, or it doesn't matter who sent it. When you
can't tell and it does matter, you have to figure out a method of
verification that will satisfy your needs (e.g., send email to someone
else who might know the truth or use the phone).
One aspect deals with interactive publishing, and the importance of
allowing readers to interact with a publication via e-mail. What
are your concerns and comments about this issue?
If it's a good question, it may not matter who asked it. When it does
matter, the publication or news service must verify the source.
------------------------------
From: wbe@psr.com (Winston Edmond)
Date: 06 Nov 1994 20:50:22 GMT
Subject: Re: E-mail Privacy Alert
Organization: Panther Software and Research
Richard Threadgill <richardt@remarque.berkeley.edu> writes: It is
presently believed to be technologically difficult to falsify this
[telephone caller-ID] information, ...
Not all that difficult if what I've been told is true. Apparently, the
Caller Number Delivery information is sent at 1200 bps using the same
1200 bps protocol modems use. Although the real CND information is
delivered by the phone company after ring 1, a "forger" can send
another ID string after the phone is answered. Many CND (Caller ID)
boxes will accept the new string and store it just as they did the
first string. Now the forged number is last in the caller-ID box's
list of callers and the real number is bumped back to last-1. Anyone
who doesn't realize that's been done may not think to look back beyond
the "current" number and may be fooled.
------------------------------
From: Do not remove this tag under penalty of law <nobody@hottest.hell.int>
Date: 07 Nov 1994 14:02:08 -0500 (EST)
Subject: Re: E-mail Privacy Alert
Organization: Down Under
rossk@ucsu.colorado.edu, allegedly writes: Recent news accounts
have emphasized the importance of password safety for e-mail
accounts.
I think the issue is to protect the mail they are receiving.
Crackers have broken into mail accounts and messaged objectionable
material all over the Internet.
Forging mail headers is trivial (witness the name and headers of this
message.) You cannot reply to this message (this is intentional to
make it clear that this is a forgery, but creating a header that would
accept return replies would have been trivial.)
If you read this message, it means that the e-mail safety debate
might enter another level. This very message, and several like it,
is being sent via someone else's e-mail address --- without use of
a password.
This is what has caused people to turn to using PGP-signed messages on
their outgoing mail, even when the message is not a "secure" message.
In our experimentation with a freely available Internet software
program,
Yeah, 'sendmail', probably with the IDA patches. Comes with every Unix
system and is available free with source from probably a hundred ftp
sites. And news is usually INN or C-News.
we have discovered that we can use someone else's e-mail address to
mail messages and post to newsgroups. Readers of those messages
can reply directly to the e-mail address.
Further, if I had written a program to create IP traffic, I could have
hidden the incoming IP address of this message to someplace else,
rather than the actual location (I wasn't trying to hide my identity,
since it appears at the bottom of the message, just to show that
forging message headers is trivial; I do it every day since the TDR.COM
domain can only receive incoming mail; to generate mail with that name
requires that I generate an SMTP header indicating mail came from
there.). With a slip account, it is possible to generate traffic that
looks like it came from the originating party, since the slip server
generates the IP address, it is possible to have it forge some other
address on an outgoing message; as a result, the 'Received: ... from '
header on the message could point to where it purports to come from.
David Lawrence <tale@uunet.uu.net> once posted an article in control
that told how to forge a news message that would look like it came from
the originating site without your own site's name appearing in it.
The consequences seem rather broad. It is a little like Pandora's
box. Anyone can use this software and send objectionable messages
without the e-mail account owner's consent or knowledge.
Sounds like they are talking about one of the PC-based slip programs or
POPmail programs such as Eudora since the PC program cannot verify the
domain name or id you claim to be, it has to take you at your word. If
you claim to be someone else, you *are* as far as that program is
concerned.
Did they just wake up from a long snooze or something? This capability
has been possible for as long as E-Mail has existed. And has been
trivially easy for probably the last five years or more.
We are not mentioning the software program that allows this posting
at this point because: 1. We are still testing how easy it is to
send messages without passwords. 2. If it is easy, we will contact
software developers for comment.
If you are on the same system as the party to be spoofed, and can
either telnet to port 25 of any other computer that will relay mail
(pucc.princeton.edu is a good one) or can access sendmail with the -bb
option, you can send out mail as if you were the other party and unless
there is a lot of heavy checking of logs, such actions are
undetectable.
Forging and spoofing mail are trivially easy to do. The only issue is
if you have to believe that the message as sent is a valid transmission
from that party; then it's an issue.
The problem will remain as long as we don't have cryptographic
verification of news and mail postings, and we won't see that for the
rest of this century - the standards don't exist and the software to
ensure things are verified isn't there - if not longer. There are
still places that run the long-obsolete "B" news software, and there
are places who are running software that generate bad news headers (as
witness the huge list of bad mailers generated in the list of errors
posted each week on one of the news newsgroups.
Expecting cryptographic news verification - when news isn't even
considered very important at most sites - is a long stretch.
--
Paul Robinson - Paul@TDR.COM
Reports on Security Problems: To Subscribe write PROBLEMS-REQUEST@TDR.COM
Voted "Largest Polluter of the (IETF) list" by Randy Bush <randy@psg.com>
------------------------------
From: Grace L Morello <gmorello@mason1.gmu.edu>
Date: 06 Nov 1994 18:16:15 -0500 (EST)
Subject: Re: Info on European Computer Privacy Laws
This is in response to a request for examples of government or employer
invasions of privacy for Dutch television. I once worked for All
America Auto Transport, in Washington, D.C. After two years on the
job, my employer, Stephen J. Walter, purchased a second switchboard
which he kept in his private office for the purpose of monitoring
employee sales and customer service calls. As long as he notified
employees that their calls would be monitored and claimed it was for
training purposes, the FCC would not step in. He kept that switchboard
in his office for at least another year before I left, and monitored
everyone, including managers and long term employees throughout that
time. As constructive criticism and advice were not offered during
that time, I can only assume it was kept for spying purposes.
His wife, Steina, would routinely rummage through the desks of
employees out sick or on vacation in plain view of the other
employees. She thought nothing of confiscating personal property, such
as magazines or playing cards and throwing them out without a word.
Her justification was that she was "cleaning up" the office.
If you would like verification, please send me an e-mail message and I
would be happy to give you the phone numbers of several former
employees who will corroborate these events, and may add other horror
stories.
Best of luck with your project. It's nice to know someone is fighting
big brother.
------------------------------
From: pgfelker@aol.com (PGFelker)
Date: 06 Nov 1994 23:16:08 -0500
Subject: Re: Info on European Computer Privacy Laws
Organization: America Online, Inc. (1-800-827-6364)
MIKE@HTI.dnet.hac.com writes: The issue of Information Security and
privacy in the European Communities is current in a state of
definition and change. The Commision of the European Communities
have created a Senior Official Group on Information Security
(SOG-IS) to draft a set of standards to be adopted by all of the
member nations. This is known as the "Green Book on the Security
of Information Systems" and is currently only in draft form. I
have attempted to get more information through legal channels as
well as personal contacts, all without much success.
What little bit I have been able to piece together indicates that some
of the existing laws, such as Germany and France, will undoubtedly be
modified to say the least. In all probability, what ever is adopted by
the European Communities will take precedence over existing laws.
This isn't much help and I don't have any addresses to offer, but
thought I could share my knowledge regarding your posting.
------------------------------
From: coreynelso@aol.com (CoreyNelso)
Date: 07 Nov 1994 01:21:00 -0500
Subject: Must I Always Carry I.D?
Organization: America Online, Inc. (1-800-827-6364)
I friend recently told me that he thought you HAVE to carry I.D. of
some kind with you at all times. I don't think you need "your papers
please" just to walk around the block. Does any one have any ideas
about this?
\ Sent By:
\ /\
( ) Mrs. Corey L. Nelson <CoreyNelso@aol.com>
.( o ). Fri, Nov 4, 1994 at 10:36 PM PST
------------------------------
From: Winn Bill <WinnB@rnd1.indy.tce.com>
Date: 07 Nov 94 11:46:00 PST
Subject: Intrusive Supermarket Card
There is a supermarket chain in Indiana, Marsh Supermarkets, that has a
discount card program called "Fresh IDEA" (Instant Discounts
Electronically Applied). The idea behind the program is one completes
an application and gets a discount card in return. When making
purchases at Marsh, holders of this card are given unpublished
discounts. The application has some very interesting, and intrusive,
questions. Many of the questions, sans the multiple choice answers,
follow. Remember, this is a discount card program for a supermarket
(analogous to using coupons), not a security clearance application.
Type of Residence (rent, own, etc.)
Education (Highest level completed)
Annual Household Income
Martial Status
Number of persons in household.
Do both you and your spouse/partner work outside the home?
List the names, birth dates, and sex of children under 21 who live in your
home.
Does anyone in your household smoke?
(various questions about name and sex of the smoker, brand smoked,
and a line for the signature of the smoker follows this
question).
How much does your household spend on food each week?
Does anyone in your household have insomnia? Is that person you?
Is the sufferer under a doctor's care? What medication is being taken?
Would you like the name of a physician to educate and treat you for
insomnia?
Does anybody in your household have psoriasis? (various questions regarding
this follows)
Various questions about skin-pigmentation problems.
Various questions about diabetes.
Various questions about bladder control.
What method of payment do you use for your prescriptions?
Questions regarding military rank/federal service rank of persons living in
your household.
Which of the following computer products do you own?
Which of the following hobbies interest people in your household?
How many six-packs of beer are purchased in your home each month?
What kinds of beer?
The questionnaire closes with a place for a validation signature,
social security number, driver's licence number, and home address and
phone number.
The owner/CEO of the chain has been sent a letter inquiring as to why
all of this information is needed for a coupon card, but thus far there
has been no reply.
------------------------------
From: Alan W Grover <awgrover@garnet.msen.com>
Date: 07 Nov 1994 21:25:44 -0500 (EST)
Subject: Identity vs. Digital Signatures
We realize that digital signatures are meant to be a means of
authentication. We are not as conscious that in fact digital signatures
are really tokens which we treat as representing a person. I have not
heard this discussed, but if it has been discussed please forgive my
ignorance, or better, direct me to such discussions.
Society has been comfortable with treating a signature,the ink and
paper sort, with legal force as witness of the signer. The presumption
has been of distinctiveness and uniqueness. The digital domain has
presented a difficulty. There is nothing about a document that is not
described by the data of the document itself. Therefore a copy of the
document is the same as the original and uniqueness cannot apply. Most
importantly, the signature can be perfectly copied.
We dispense with uniqueness, therefore, and resort to attribution--"Is
this attributable?" Cryptology has provided a means of reliable
attribution--the digital signature. Which presumption is that the
document was witnessed by the signer.
Thus I arrive at my question--"What are the social consequences of
treating the token (i.e., the digital signature) as the person?"
If I were to suggest that we recognize the identity of a person by
their hat and only by their hat, it having acquired a characteristic
shape and state, a personality, from years of wear and habit, it might
seem ridiculous. For we know how easy it is to exchange hats, borrow,
lose, or even steal hats. Continue imagining that the banker looks only
at the persons hat before dispersing funds, that colleagues greet you
after recognizing your hat, that the court bailiff dutifully recognizes
your hat as the legal proof of who you are. This is exactly the
situation with digital signatures. We define the person as the token.
Wear the wrong hat and no-one, not the law, not your bank, not your
colleagues, will recognize you nor believe that you are the same
person. The person is treated as the shadow cast by the token.
I make this point because the token, the digital signature, is separate
and separable from the person. The pen and paper signature is not
seperable as it is produced by the physical person, a biometric
condensation. And yes, as the body/mind is changed/damaged, the
signature can change, but we treat the signature as a representation of
the person, and not as proof of the person.
The social context of the digital signature is very different, it seems
to me. We take the digital signature to be proof of the person, not his
representation. The difference is because the signature is rooted in
the physical domain, and the digital signature in the digital where
presence is not relevant. Consider these newsgroups as you judge that
statement.
May I close with my caution--do not allow a token to be taken as
primal, for then the person is derivative. Our society is well along
this path, i.e. identity cards and identity numbers. There is a lesson
of giving up the definition of our identity to those with power, but I
shall not take the space here to expand on it. Your gentle attempts to
correct my mistakes, and other comments, would be welcome.
--
Alan Grover Private Citizen awgrover@msen.com
------------------------------
From: MVanAuken@UH.edu (Michael Van Auken)
Date: 07 Nov 1994 12:08:40 -0600
Subject: Re: Planting "Mistakes" to Guard Copyright
Organization: University of Houston, Information Services
dwn@dwn.ccd.bnl.gov (Dave Niebuhr) wrote: One local map printer
lists important features in places where they shouldn't be. An
example is the high school which is shown mixed up with an
elementary school. Another is the nearest Coast Guard Station
closer to a main road than the bay it sits beside. A third is an
historical site is listed where a Native American Reservation is
located yet neither is tied to the other in any way.
Another example is the Key Map Company. It includes nonexistant
streets in its maps. If the nonexistant street they put in their map
shows up in someone elses map they know that the map was likely copied
from theirs.
I have noticed only one example of this in my copy of the Houston Key
Map. I used the map while sketching a map on an invitation I was
creating. In an effort to include all relavent cross streets (to help
guests if they got lost) I noticed a street I had never seen before.
Thinking I might have missed it, I went looking for it. It was not
there.
The nonexistant street on the map was essentially and alley between a
major street and a freeway access road that crossed a few dozen yards
from where the street was shown to be.
Unless you were looking for something on the street (which you wouldn't
since it didn't exist (unless of course you have some really malicious
friends)) or copying the map (which I was) its presence would not be a
problem.
This is the only example I have noticed and verified.
--
Michael Van Auken | Einstein has overcome time and space. Harvey
MVanAuken@UH.edu | has overcome not only time and space--but any
713/743-1502 | objections.
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 07 Nov 1994 21:42:34 -0600 (CST)
Subject: Other People's E-mail (long)
Organization: University of Wisconsin-Milwaukee
Taken from Computer underground Digest Sun Nov 5, 1996 Volume 6 :
Issue 96 ISSN 1004-042X
Date: 03 Nov 1994 18:54:51 -0600 (CST)
From: pkennedy <pkennedy@IO.COM>
Subject: File *&*--Other People's E-mail: TO Read or not to Read?
OTHER PEOPLE'S E-MAIL: TO READ OR NOT TO READ?
There still seems to be a lot of confusion remaining about if and when
you can properly and legally read another person's electronic mail. As
the number of people going on-line increases, and the situations where
e-mail is used proliferate, the landscape gets more complicated. Yet,
the same basic rule we've always had for Postal Service mail applies to
electronic mail: if the message isn't addressed to you, don't read it
unless you have permission. If in doubt, don't read other people's
mail. Simple enough.
Predictably, the exceptions complicate this simple rule. All e-mail
users should learn the important ones, and systems administrators
should commit them to heart.
THE ECPA. The principal law protecting the privacy of e-mail is the
Electronic Communications Privacy Act of 1986 (the "ECPA" for short).
ECPA is a 1986 federal law that expanded to e-mail the protections long
afforded telephones conversations. The ECPA makes it a serious crime
to read, use or disclose another person's electronic communications
without justification. The ECPA sets the basic "don't read without
permission" rule, along with some exceptions.
Not only does the ECPA criminalize reading mail without permission, it
also provides a civil remedy for those whose mail has been read or
disclosed. So, even if you can't get law enforcement interested in
prosecuting the person who snooped through your e-mail, you can sue the
snooper in court. If you win, the snooper pays you damages and pays
your attorney's fees. (It was this civil provision that allowed Steve
Jackson Games and its BBSs users to sue the Secret Service for reading
and deleting their e-mail, and allowed them to collect money from the
Service and force the Service to pay their legal expenses.)
THE ECPA EXCEPTIONS -- DISCLOSURE TO LAW ENFORCEMENT. The ECPA's
restrictions have some exceptions. First, systems administrators may
disclose that mail to law enforcement officials in response to a
subpoena, search warrant or court order without penalty, *if* the
administrator has a good faith belief that the legal papers are valid.
A proper subpoena or search warrant should particularly identify the
electronic files to be seized, and should identify at least the
recipient or sender of the messages sought. It should not be a broad
request for "all electronic mail messages" on a particular computer, or
simply "all computers," especially when the system to be searched or
seized runs a BBS.
THE ECPA EXCEPTIONS -- BUSINESSES. The ECPA does *not* protect the
privacy of a business' internal e-mail. A common misunderstanding
among employees is that law protects the privacy of internal e-mail.
The ECPA does not prevent an employer from monitoring its employees'
electronic mail, just as it does not prevent an employer from listening
in on telephone conversations to check up on the employee's work.
On the other hand, each state has laws that protect a person's privacy
from unwarranted snooping. Generally, a person's "private" sphere at
work is fairly limited, but an employer who for years provides private,
secure electronic communications among its employees may have allowed a
sphere of privacy to develop. A sudden, unannounced change to a policy
of reading employee e-mail might then violate state law. The safer
practice for an employer would be to have a clear, written policy
stating that company electronic mail is not private, and that the
company retains (or is reclaiming) the right to review employee mail.
Companies with gateways to outside mail services should be especially
clear on their policy, because, rightly or wrongly, employees will have
a greater expectation of privacy for personal mail they receive from
outside the company, similar to personal letters sent to a work
address.
THE ECPA EXCEPTIONS -- SYSTEM ADMINISTRATORS. The final important set
of exceptions to the ECPA's "don't read without permission" rule is for
the system administrators. System administrators may "intercept,
disclose or use" an electronic communication when engaged in any
activity which is a "necessary incident" (1) "to the rendition of his
service" or (2) "to the protection of the rights or property of the
provider of that service."
There is some debate on the breadth of these exceptions. No court case
has discussed how they apply to BBSs. I read these exceptions
narrowly, and believe the prudent systems administrator should too.
The ECPA says that these exceptions are *not* a license to read users'
mail at will, or even to spot-check to see if users are up to no good.
The law says that the systems administrator "shall not utilize service
observing or random monitoring except for mechanical or service quality
control checks." Any spot-checking must be to monitor the system's
*functioning,* not the users' *activities.*
What if a system administrator has specific information that a certain
user might be using e-mail to discuss or even facilitate a crime? Does
that justify nosing through the user's e-mail? Again, I believe only
very narrow circumstances could justify it. The systems administrator
is no more responsible for criminal plots in e-mail than Ma Bell is for
telephone conspiracies. For that reason, the law need not give the
administrator a private-cop badge to rifle through e-mail and monitor
for any signs of crime. While the ECPA does permit a system
administrator to disclose to the police the contents of an e-mail
message that was *inadvertently* obtained and which appears to pertain
to the commission of a crime, this strongly implies that *intentional*
sleuthing by systems administrators is forbidden.
*If* a systems administrator has specific information that a user is
about to damage the system or crash the service, say with a virus, the
system administrator could justify reviewing that user's e-mail as a
protection to the system. The harder case is if the administrator
suspects that a user's actions might be criminal, but the only threat
to the system is that it might get seized by law enforcement on account
of the user. (Most BBS crime poses no other threat to the system, as
it usually depends on the systems' continued functioning). Here, the
administrator might argue that the threat of a seizure of the system
(and the resulting loss of property) justifies reading the suspected
user's e-mail. At minimum, however, the ECPA's specific prohibition of
random monitoring would require the system administrator to have good,
solid evidence against the user, not just a vague suspicion or
anonymous claims that something bad is going on.
A good point of reference: Remember that the same law applies to BBSs
and telephone companies. Most people want to limit Ma Bell's right to
monitor phone calls as much as possible. The same goes for e-mail.
TRYING TO AVOID THESE RULES? The ECPA severely restricts a systems
administrator's access to electronic messages flowing through his or
her system. Some systems administrators try to avoid this limitation
on their nosiness by posting disclaimers saying "NOTICE: This system
does not provide private electronic communications" or "WARNING: We
read your mail. It is not private." With these warnings, some systems
administrators think they can freely read everyone's e-mail. These
warnings are a bad idea.
First, they probably won't do the job. While the facts of the
particular case will matter, such disclaimers probably will not stand
up in court. Judges and juries don't like these "take it or leave it"
ultimatums when it comes to privacy. The disclaimer also probably
isn't true: the system *does* provide mail that is private from all
prying eyes except the systems administrator, and on any busy system,
the administrator *can't* read all the mail, which may re-create in
practice the very expectation of privacy the administrator is trying to
deny.
Second, the disclaimers may make things worse. While trying to
decrease the chance of a user suing the administrator under the ECPA,
the disclaimer will increase the systems administrator's risks in other
areas. An administrator who actually reads his or her user's e-mail
can be charged with knowing its content, and this increases the
potential for successful civil suits for libel, as well as the danger
of criminal prosecution for aiding criminal activity on the BBS. The
administrator can always claim "I didn't read *that* message," but the
system's own words say the opposite.
Worse, if the system is seized by law enforcement, the systems
administrator may lose very helpful allies: the users. When innocent
users try to sue the police for violating *their* rights under the
ECPA, the police will be sure to defend their acts based on what the
system itself told them: no private e-mail here! The ECPA should be a
great deterrent against the wholesale seizure of BBSs; systems
administrators diminish that deterrent by using these disclaimers.
Finally, what possible reason, other than plain rude nosiness,
justifies reading other people's mail? The law not only imposes no
responsibility to read or monitor mail flowing through a system, it
prohibits it. System administrators who fear criminal responsibility
for what their users are discussing in e-mail are as wrong as if
Southwestern Bell was worried about being held responsible for crimes
committed over their phone system.
A tough question: What about users' personal file directories on
BBS's? Many BBSs, Internet providers, and other computer systems
provide their users file storage areas. Some systems call and treat
these areas as "private." Would it violate the ECPA if the system
administrator nosed through the files in a user's area? It's common
for users to write e-mail to a file and store it, making them "stored
electronic communications" covered by the ECPA. If the ECPA protects
the privacy of these files from snooping by system administrators,
doesn't the ECPA clash with the developing strict liability for system
administrators for copyright infringement -- who are now being held
liable for infringing files whether or not they knew they were on the
system? (See Legal Bytes, Vol. 2, No. 1, "BBS System Operators'
Liability for Copyright Infringement: Let the Sysop Beware"). How
does a system administrator avoid unknowingly harboring infringing
computer files? The solution *probably* lies in the system
administrator gaining proper consent from the user, before the fact, to
monitor these files, but the authors honestly haven't worked through
this difficult question yet.
LEGAL BYTES is a (usually) quarterly publication of
George, Donaldson & Ford, L.L.P., Austin, Texas.
George, Donaldson & Ford, L.L.P.
114 W. Seventh Street, Suite 1000
Austin, Texas 78701
(512) 495-1400
gdf@well.sf.ca.us
David H. Donaldson, Jr., Editor
6017080@mcimail.com
Peter D. Kennedy, Associate Editor
pkennedy@io.com
To subscribe:
Send mail to legal-bytes-Request@io.com with the words
"subscribe legal-bytes" in the message _body_.
Online at:
ftp.eff.org, /pub/Publications/E-Journals/Legal_Bytes/
gopher.eff.org, 1/Publications/E-Journals/Legal_Bytes
gopher://gopher.eff.org/11/Publications/E-Journals/Legal_Bytes
http://www.eff.org/pub/Publications/E-Journals/Legal_Bytes/
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 07 Nov 1994 22:04:02 -0600 (CST)
Subject: Minnesota Driver License
Organization: University of Wisconsin-Milwaukee
Taken from RISKS-LIST: RISKS-FORUM Digest Sunday 6 November 1994
Volume 16 : Issue 53 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND
RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G.
Neumann, moderator
Minnesota driver license (Daniel Frankowski)
Date: 04 Nov 1994 15:55:56 -0600 (CST)
From: dfrankow@winternet.com (Daniel Frankowski)
Subject: Minnesota driver license
*City Pages*, a great free news weekly here in the Twin Cities
(Minnesota USA), recently had an article [1] chock full of privacy
issues and implications of the new Minnesota driver license (not
"driver's" but "driver" on our license). I approached the article with
deep suspicions about a new card, and came away only slightly less
suspicious.
The old license has been the same for 25 years. It has a picture, a
license number and some personal information (address, height, weight,
signature, birthdate, etc.).
.. [O]fficials were tired of the ease with which the old card could
be forged and altered. In early 1990, local police officials
uncovered a forgery ring in the Twin Cities that used fake Minnesota
licenses to open bank accounts and pass close to $1 million worth of
bad checks.
To make it harder to forge, the new card is printed in several fonts
and the location of your (digitized and stored) picture depends on your
age. For the information age, there is a barcode with your driver
license number, and a magnetic stripe that can contain three lines of
about 80 characters each, currently slated to contain a person's full
name, date of birth, and driver license number.
The article raises a plethora of issues, some of which follow. I have
hastily tried to put them into categories, which unfortunately
overlap.
INFORMATION HANDLING RISKS
- The state government assumes that the public should trust government
agencies with these technologies. This resulted in a lack of public
discussion or input because the government did not publicize the new
card proposal. The article gave an example I had not heard why we
should not trust government: upon dishonorable discharge from the US
military, it assigned a code which potential employers and others could
get. 257 meant "unfitness, homosexual acts," 261 was "psychiatric or
psychoneurotic disorder," 287 was "unclean habits including venereal
disease," and 289 "unsuitability, alcoholism."
- Currently, the Driver Vehicle Services (DVS) department makes all
their information public except social security number and medical
information. That is, registration and title info, driving records,
and the personal information from your license. The state sells it
("provides it for a fee"), and currently has 600 online accounts
(presumably customers buying the information). They can sort by age,
area, or size of person, for example.
- The card is a universal identifier, a notion often reviled in RISKS.
- The article mentions a national database of 7 million commercial
drivers (only truckers?) called (and operated by) AAMVANET which went
online January 1989. It contains each person's name, date of birth,
social security number, and physical descriptors. "It was mandated by
the federal government because truckers were getting licensed in
multiple states to avoid suspensions." Barry Goleman is the president
of AAMVANET, Inc., a subsidiary of the American Association of Motor
Vehicle Administrators. "Goleman says that in the future, the system
will include all drivers-- currently a total of 160 million,
nationwide."
- The license may be linked to issues unrelated to driving. In
Wisconsin, your license may be suspended for failing to pay public
fines. The article's example is a late book fine at the public
library.
RISKS OF SUDDENLY SWITCHING TECHNOLOGIES
- The company producing them (Deluxe Check Corporation, big in
Minnesota) promised quicker turnaround for new licenses, but their
digitizing cameras overheated, and their incompatible transmission
protocols lost about 4000 new pictures which have to be retaken.
RISKS OF MAGNETIC STRIPES
Goleman (see above) said "upward of" 22 states have magnetic
stripe-reading technology for driver licenses already.
- You, the card holder, cannot easily read the magnetic stripe to
ensure that there are no mistakes because a special machine is
required.
- Businesses could modify credit card readers to read the license
stripe "ostensibly to verify ID" and build databases of shopping habits
and personal information.
- Minnesota businesses are trying to get extra information put on the
magnetic stripe.
- A state group proposed distributing AFDC (welfare) money. The
article hypothesized the card could be used (say) to track your
location.
Comments:
At first, I was impressed with the fact that all information in the
barcode and magnetic stripe would also be visible on the card. In
other words, no hidden information. However, other points listed above
drained away my relief.
I noted a fatalism about the article: it catalogued frightening
consequences without proposing solutions or interviewing privacy
experts. This seems typical of even good journalism these days.
So are there simple guiding principles about the use of information for
a driver license?
Would it be a good idea to pass a law requiring cash machines to be
able to display (for free) any information on a magnetic stripe given
the appropriate PIN #?
How else can we solve the problems above?
1. Card Blanche, Jennifer Vogel, City Pages, Vol 16, No 725, October
26, 1994, pages 15-20.
Dan Frankowski dfrankow@winternet.com
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 07 Nov 1994 22:05:27 -0600 (CST)
Subject: Re: Sears Captures Signatures
Organization: University of Wisconsin-Milwaukee
Taken from RISKS-LIST: RISKS-FORUM Digest Sunday 6 November 1994
Volume 16 : Issue 53 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND
RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G.
Neumann, moderator
Followup on Sears captures signatures (Steve Holzworth)
Date: 31 Oct 1994 18:44:44 -0500 (EST)
From: Steve Holzworth <sch@unx.sas.com>
Subject: followup on Sears captures signatures
Since my original post concerning Sears now digitizing signatures when
you sign a credit card slip, bunches of people :-) have sent me Email,
either asking for elaboration on the risks involved, or adding
anecdotes of their own. I'll attempt to describe the potential risks as
I see them.
Summary of previous post:
Sears in my area has recently started asking for people to sign their
credit card receipts while the receipts are on what is obviously a
small digitizing pad. Sears doesn't make it obvious that this is the
function of the device.
You can refuse to sign on the tablet. They'll probably have to call
someone first to OK it.
Potential Risks of digitized signatures:
Capturing the act of signing gives the store more information than
simply scanning a copy of a signed receipt would. In addition to the
basic image of the signature, the tablet can also effectively record
stroke information (direction of strokes, and possibly, pressure of
strokes). This is important, because given stroke information, it is
almost trivial to write a program to fake a signature with a pen
plotter. Simply use the stroke points as control points for spline
curves. Said control points can then be perturbed slightly to yield
what appears to be the same signature STYLE, without being a direct
copy of an existing signature.
Of course, Sears wouldn't do anything so stupid. However, once the data
is available, a disgruntled or entrepeneurial employee could sell the
data to other parties. Let's see. Bill Gates goes to Sears and buys a
screwdriver on his credit card. How much is his signature potentially
worth on the market? Or, (for the really paranoid :-) ), some
government agency, say, DEA, known to be overzealous at times, decides
to "apply" your signature to some incriminating evidence...
I don't believe Sears (and others mentioned) can perform dynamic
signature verification on the fly. They can't possibly have that
horsepower at the terminal (at present). Even simple credit card number
verification takes 30 seconds or more. Imagine the complexities of
looking up one of N million signatures, correlating it to the new
sample, then issuing a go/no-go response in a reasonable time frame.
The closest approximation to this so far is the Apple Newton
handwriting recognition. It looks in a small (10k words) dictionary,
has to be trained to your writing style over time, and still screws up
often enough to cause some headaches. How tolerant is your customer
base to having their charges denied when they KNOW they wrote a valid
signature?
More importantly, what REASON can Sears have for wanting this
information? I proposed that they can't do anything useful with it
yet, so why should we let them have it? Further, to the best of my
knowledge, no credit card provider requires card owners to supply
digitized signature information when initiating a transaction. My
understanding is that, per the card issuer agreement with the merchant,
the merchant CANNOT require ANY other identifying information, assuming
they get an approval code from the card issuer. Keep in mind, you
don't even SIGN a receipt for a mail-order purchase... Why should we
let Sears et al digitize our signatures?
One limited use of a digitized signature could be to display a specimen
of your signature on POS terminal so the clerk can compare with your
receipt. Of course, that is supposedly what the signature on the back
of the card is for (among other things)...
One responder mentioned that if the customer was signing paper on top
of a tablet, it was unlikely that much information could be captured
beyond stylus pressure. This is incorrect. I developed high-end CAD
software for civil engineering and land planning for many years. All of
the digitizers we used were capable of capturing positional information
through quite a number of layers of vellum, mylar, and/or paper. This
was necessary because much of engineering work involves tracing
existing maps or drawings.
Several responders stated that they had run into similar digitizers at
Sears, Service Merchandise, and others. A few stated that my example of
refusing to sign had encouraged them enough to "just say no" :-) next
time.
I'm not trying to be paranoid, but I attempt to see all of the angles
when confronted with a situation as described above. I operate under
the rule that unless you can give me an extremely good reason why I
should give you some class of information about me, you don't get it.
Numerous posts to RISKS have documented how quickly and easily
information about someone is disseminated, and how difficult it is to
correct misinformation, once it gets spread. I attempt to minimize
acquisition of the information as a preemptive measure.
--
Steve Holzworth SAS Institute x6872 SAS/Macintosh Development Team
Cary, N.C. sch@unx.sas.com
------------------------------
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 #059
******************************
.