From privacy@cv.vortex.com Wed Sep 9 18:01:10 1992
Return-Path: <privacy@cv.vortex.com>
Received: from cv.vortex.com by csrc.ncsl.nist.gov (4.1/NIST)
id AA05336; Wed, 9 Sep 92 18:00:43 EDT
Posted-Date: Wed, 9 Sep 92 14:04 PDT
Received-Date: Wed, 9 Sep 92 18:00:43 EDT
Received: by cv.vortex.com (Smail3.1.26.7 #2)
id m0mSZCx-00022UC; Wed, 9 Sep 92 14:04 PDT
Message-Id: <m0mSZCx-00022UC@cv.vortex.com>
Date: Wed, 9 Sep 92 14:04 PDT
From: privacy@cv.vortex.com (PRIVACY Forum)
Subject: PRIVACY Forum Digest V01 #16
To: PRIVACY-Forum-List@cv.vortex.com
Status: R
PRIVACY Forum Digest Wednesday, 9 September 1992 Volume 01 : Issue 16
Moderated by Lauren Weinstein (lauren@cv.vortex.com)
Vortex Technology, Topanga, CA, U.S.A.
===== PRIVACY FORUM =====
The PRIVACY Forum digest is supported in part by the
ACM Committee on Computers and Public Policy.
CONTENTS
Re: Wells Fargo Bank changes customer security system (Bob Leone)
Re: Wells Fargo Bank changes customer security system (Randy Gellens)
Re: Vernam Cipher (Bob Leone)
Re: Vernam Cipher & Privacy (Willis H. Ware)
Re: Vernam Cipher (Tom Ohlendorf)
Transferring ownership of private data (Larry Seiler)
Usenet privacy? (Jim H.)
Re: Usenet privacy? (Brian Reid)
*** Please include a RELEVANT "Subject:" line on all submissions! ***
*** Submissions without them may be ignored! ***
-----------------------------------------------------------------------------
The PRIVACY Forum is a moderated digest for the discussion and analysis of
issues relating to the general topic of privacy (both personal and
collective) in the "information age" of the 1990's and beyond. The
moderator will choose submissions for inclusion based on their relevance and
content. Submissions will not be routinely acknowledged.
ALL submissions should be addressed to "privacy@cv.vortex.com" and must have
RELEVANT "Subject:" lines. Submissions without appropriate and relevant
"Subject:" lines may be ignored. Subscriptions are by an automatic
"listserv" system; for subscription information, please send a message
consisting of the word "help" (quotes not included) in the BODY of a message
to: "privacy-request@cv.vortex.com". Mailing list problems should be
reported to "list-maint@cv.vortex.com". All submissions included in this
digest represent the views of the individual authors and all submissions
will be considered to be distributable without limitations.
The PRIVACY Forum archive, including all issues of the digest and all
related materials, is available via anonymous FTP from site "cv.vortex.com",
in the "/privacy" directory. Use the FTP login "ftp" or "anonymous", and
enter your e-mail address as the password. The typical "README" and "INDEX"
files are available to guide you through the files available for FTP
access. PRIVACY Forum materials may also be obtained automatically via
e-mail through the listserv system. Please follow the instructions above
for getting the listserv "help" information, which includes details
regarding the "index" and "get" listserv commands, which are used to access
the PRIVACY Forum archive.
For information regarding the availability of this digest via FAX, please
send an inquiry to privacy-fax@cv.vortex.com, call (310) 455-9300, or FAX
to (310) 455-2364.
-----------------------------------------------------------------------------
VOLUME 01, ISSUE 16
Quote for the day:
"I don't want a pickle--just want to ride on my motor-sicle."
-- "The Motorcycle Song"
Arlo Guthrie
----------------------------------------------------------------------
Date: Sun, 6 Sep 1992 23:51:17 -0400
From: Bob Leone <leone@gandalf.ssw.com>
Subject: Re: Wells Fargo Bank changes customer security system
> [ Yes, I know that such automated systems are now becoming widely
> available. However, the question for this Forum is, *should* such
> information be freely accessible, without any controls by the
> customer, no recording of who is requesting the information, and no
> notification to the customer that their account information is
> being queried? Also, does the widespread move from "manual" to
> "automated" systems for dispensing this information possibly
> encourage abuse through easier repetitive access? -- MODERATOR ]
There is a potential technological "fix" for this: the caller-id feature
that phone companies are starting to offer. This feature becomes especially
easy to work with under ISDN. (Caller-id supplies the phone number of the
caller to the callee).
All a bank would have to do is:
1) Record the caller-id of all incoming account-balance-request calls
in an audit-trail log.
2) If this incoming caller
A) has queried the same account more than once on this current day, or
B) is using caller-id-blocking (something that a legitimate merchant
would not do), or
C) is calling from a pay-phone (which can be determined from the
first three digits of the incoming phone number),
then reject the call and log a message in the "security violation" log.
Of course, for banks to go through the extra effort, they have to have a
reason. A few lawsuits and newspaper articles resulting from criminals
misusing the bank's system should do nicely.
Bob Leone
[ Any kind of serious reliance on caller-id would probably be
impractical for this purpose. For a variety of well-founded
reasons (well discussed in previous issues of this digest) a range
of restrictions on caller-id are being imposed in many areas; some
areas may not be supporting it at all. Also, tracking of merchant
calling numbers for this application may do little good, since you
might find calls from any number of lines randomly selected by the
normal trunking functions of most PBX systems.
More importantly, such a procedure does not give the bank customer
any say over who has access to the information regarding their
account status, and on what basis. Ideally, the customer would be
able to specify that a particular query from a particular entity
would be permitted when they were writing a large check or
applying for credit, but perhaps "random" queries would be
rejected since they would not be so authorized.
The key, of course, as noted by Bob above, is that if the
institutions involved don't think it worth their while to
provide such controls they won't bother doing so. -- MODERATOR ]
------------------------------
Date: 08 SEP 92 06:12
From: <MPA15AB!RANDY@TRENGA.tredydev.unisys.com>
Subject: Re: Wells Fargo Bank changes customer security system
>[ Yes, I know that such automated systems are now becoming widely
> available. However, the question for this Forum is, *should* such
> information be freely accessible, without any controls by the
> customer, no recording of who is requesting the information, and no
> notification to the customer that their account information is
> being queried? Also, does the widespread move from "manual" to
> "automated" systems for dispensing this information possibly
> encourage abuse through easier repetitive access? -- MODERATOR ]
This comment from our moderator got me thinking about how I've come to accept
automated privacy risks as just another aspect of our society which I prefer
were different, but don't have any control over.
What would it take to change our institutions so that technological advances
were used to help people retain more privacy, instead of causing us to have
less? I know TRW offers (for a fee) to notify me when they give out my credit
report. I like the idea of being told this, but dislike the concept that I
must pay for the privilege, as it reinforces that TRW, not I, own the
information.
Several nearby supermarkets offer to let me pay for purchases through a debit
card. Of these, Lucky uses a common system to ring up items and process the
debit, producing one receipt and of course linking my choices with my identity.
Another store, Alpha Beta (owned by the same company), has two different
systems, producing two receipts, and the hope that the databases aren't linked.
A third, Vons, does not perform an electronic debit, but rather an electronic
check (which takes several days to clear, unlike the debits). None of the
stores make any mention of the privacy aspects. If one of them were to tout
their system as offering both convenience and privacy, would they do more
business? Is the profit motive enough to get change? Or are laws needed, and
if so, are they likely to be passed? I see increasing evidence that given a
choice, people prefer the promise of safety or convienence over privacy.
=====================================================================
= sua cuique voluptas (everyone has his own pleasures) =
= Randy Gellens randy%mpa15ab@trenga.tredydev.unisys.com =
------------------------------
Date: Sun, 6 Sep 1992 23:58:28 -0400
From: Bob Leone <leone@gandalf.ssw.com>
Subject: Re: Vernam Cipher
>If an inexpensive and quite secure method of encryption were
>available to all, would not use of end-to-end encryption go some
>distance toward solving the privacy problem ?
>
>This would not be a popular idea with law enforcement agencies,
>the NSA, and other spooks. Aside from obvious objections from
>this quarter, are there any good arguments against general
>availability of such an encryption method ?
The immediate rationale for govt opposing this is "But drug dealers
will use it to prevent police monitoring of their conversations.
Therefore, in the name of the War on Drugs (all salute, now), this
must be prohibited"
My response would be "If the War on Drugs (alias 'Prohibition, the Sequel')
requires regular people to give up their privacy and civil rights, then
maybe we should just cancel the War, as we did with Prohibition in 1933."
Bob Leone
------------------------------
Date: Tue, 08 Sep 92 10:37:25 PDT
From: "Willis H. Ware" <willis@iris.rand.org>
Subject: Re: PRIVACY Forum Digest V01 #15: Vernam Cipher & Privacy
Art Zimmerman -- GlasNet <glasnost@igc.apc.org> -- asks:
>> ..............would not use of end-to-end encryption go some distance
>> toward solving the privacy problem ?
The answer depends on what you mean by "some distance." E2E encryption
would handle any problems which are related to intercept of traffic while
in transit over communications systems. In a precise sense, such an event
is not a privacy issue but a communications security one resulting in a
breach of confidentiality -- which the in-transit message presumably
enjoys. For example, intercept of the Royal Family's cellular telephone
conversations is not a privacy infraction, but rather an intrusion on the
confidentiality of the connection. Usage is careless, however, and
privacy is often loosely used as an inappropriate synonym for either
security or confidentiality.
Aside from that, interception of communications is of unknown magnitude.
There is anecdotal evidence of such things, and the presence of scanners
and much other contemporary consumer electronics leads to speculation that
comms interception is widespread. The US of course did pass a law
protecting specifically the bands used by cellular phones; it is illegal
to listen in on such connections since it is considered an extension of
the Wiretap Act. Surprisingly, cordless connections have no protection.
Put a cordless fone in your car and connect the car by cellular; part of
the circuit is legally protected; part, not. I have never seen hard data
on the amount of such intercepts. Thus, one doesn't know whether E2EE
addresses a big problem or a small one. People engaged in illegal actions
of course go to some lengths even now to avoid interception by law
enforcement agencies.
The <<big>> issue in privacy is the collateral or unauthorized use of
information about people. It's the old story: collect information for
one purpose and usually legitimately; then use it for anything else the
recordkeeper can think of -- combine it with other data, sell it,
target mail with it.
Typically exploitation of personal information is by 3rd parties who have
either acquired it legitimately from public records, from list sellers,
from database sellers, or as a result of being in business; e.g., video
rental records, the sale of driver license records by the California DMV.
E2EE does nothing of course for this major component of [true] privacy.
Infractions of privacy such as the ACLU or CPSR worry about is of growing
magnitude and almost certainly dwarfs any other use of information about
people that one can imagine.
Privacy is a long and involved topic. We'll save the tutorial for another
time.
Willis H. Ware
Santa Monica, CA
[ While there are no federal laws regarding cordless
phone interception, there are apparently some state
laws that apply, including a recent one here in
California, I believe. -- MODERATOR ]
------------------------------
Date: Wed, 9 Sep 1992 09:19 EDT
From: "Tom Ohlendorf - TSU Admin. DP, (410) 830-3642"
<D7AP002@TOA.TOWSON.ED
Subject: Re: Vernam Cipher
> Date: Sun, 30 Aug 92 17:00:47 PDT
> From: GlasNet <glasnost@igc.apc.org>
> Subject: Vernam Cipher
>
> There is a well-known cryptographic technique - the Vernam
> Cipher, also known as the one-time pad - which is secure against
> any known form of decryption attack. The problem with this
> technique has always been in key distribution; an amount of key
> equal to that of the plaintext is required.
>
[additional quoted text removed by moderator]
I would be very interested in applying this variant of the Vernam Cipher.
There are many instances where I can find it to be useful. For example, I am
involved with an organization in my area that runs several client based service
programs. I and others have set up a network which includes an infrared data
link to a building nextdoor and a dedicated landline data link to another
building several miles away. Most of the data travelling along these links
reference clients of the respective programs (client privacy). If I could
encrypt this data using the metjod described above, it would be quite useful.
Many thanks,
Tom
-----
Tom Ohlendorf, Programmer/Analyst
INTERNET: D7AP002@TOA.TOWSON.EDU
------------------------------
Date: Mon, 7 Sep 92 18:37:54 EDT
From: "LARRY SEILER, DTN225-4077, HL2-1/J12 07-Sep-1992 1815"
<seiler@rgb.enet.dec.com>
Subject: Transferring ownership of private data
In digest V01 #15, Larry Hunter says that selling a defunct video store's
customer/rental list is within the law because the "ordinary course of
business" is defined to include "transfer of ownership". Certainly if a
video business is sold, the customer records should go with it.
However, the case here is a defunct business whose assets were being
sold off. Can "transfer of ownership" really be defined to mean parts
of a defunct business? If so, I suppose any video business, defunct or
not, could sell its rental records and call it "transfer of ownership".
To me, the thing wrong with this picture is permitting businesses to
treat records of private information (whatever one puts in that category)
as a marketable asset. I've heard defenses of the practice as being
necessary for effective business. However, the phone companies do not
(I hope!) market their billing records of the numbers we call, and neither
do I think that any other sales data (whether video rentals, groceries, or
loans) should be marketed without explicit permission from the consumer.
Larry Seiler
------------------------------
Date: Wed, 09 Sep 92 11:49:40 -0700
From: horning@src.dec.com
Subject: Usenet privacy?
One of the newsgroups I subscribe to is news.lists, on which a variety
of sources periodically post a number of interesting analyses of
usenet traffic, such as USENET FLOW ANALYSIS REPORT, Top 25 News Submitters
by User by Kbytes, Changes to List of Periodic Informational Postings,
etc.
None of the current postings seems to be an objectionable invasion
of privacy. However, it seems that the analysis techniques used
for some of them could easily be refined to collect (and presumably
sell) detailed information about individual usenet users of a kind
that readers of this forum would probably consider abusive if it
were done by a telephone company, video store, or department of motor
vehicles.
I'd be interested to know what safeguards (other than the restraint
of those doing the analysis) and/or guidelines there are for such
activity. Is it assumed that usenet users realize there is no right
to e-privacy?
Jim H.
------------------------------
Date: Wed, 09 Sep 92 12:00:08 PDT
From: Brian Reid <reid@pa.dec.com>
Subject: Re: Usenet privacy?
I do the USENET flow analysis and USENET readership analysis. Both of
them have the potential for harming the privacy of individuals if
mis-used.
My safeguards are as follows:
* The raw data-gathering software strips the identity of
individuals; I ensure that before the data ever reaches me all
specific identifying information has been removed. I have no
control over the system administrators who produce this data, but
I don't want there to be stored on my system, even for one second,
information that would let me learn about the reading habits of
individuals.
* All data are kept private. I do not release raw data to anyone.
It would be possible to write programs that analyzed flow data and
readership data that could impute a lot about the identity of
individuals.
* All reports that I produce are aggregated over a geographically-
defined population. I will not produce custom reports for anyone,
and I will not perform an analysis of any subset that is defined
by any factor other than geography.
I rely on my own judgment for deciding which reports could potentially
violate privacy. There is an interesting duality here: there is privacy
to be had from summaries, but there is also a threat from aggregation.
If I tell you that the summary of data from 100,000 people shows
certain trends, that is potentially interesting. However, the knowledge
that I have data about 100,000 people is potentially dangerous. This is
the reason why I ensure that I do not have the opportunity to store
data about individuals: if I kept it and relied on the security of my
own computer system, then somebody with a search warrant could force me
to divulge it. By making sure that it never gets here I can make sure
that it cannot be released to law enforcement.
------------------------------
End of PRIVACY Forum Digest 01.16
************************
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
