Date: Mon, 12 Dec 94 11:06:11 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#072
Computer Privacy Digest Mon, 12 Dec 94 Volume 5 : Issue: 072
Today's Topics: Moderator: Leonard P. Levine
Question about Electronic Comm. Privacy Act
AppleLink and SSN's
Re: Caller ID and Blocking
Calling Line ID --- Warning by DP Registrar
Re: Parents' SSNs wanted for Fundraising
Regarding National Cryptography Policy
Good Times; Journalist's Questions?
Re: Dynamic Negotiation in the Privacy Wars
German Telecom - Technical Risks/Crime
Re: Clipper Chip Information Needed
Value of Pretty Good Privacy
Info on CPD, (unchanged since 11/28/94)
----------------------------------------------------------------------
From: fwilson@acs.bu.edu
Date: 09 Dec 1994 16:58:27 GMT
Subject: Question about Electronic Comm. Privacy Act
Organization: Boston University
I am attempting to understand Title 18 U.S.C. as ammended by the
Electronic Communications Privacy Act of 1986. Not having any legal
training, I am rapidly getting out of my depth. I'm trying to figure
out whether this Act would cover:
(a) Interception of a student's email by a university sysadmin.
(b) Interception of an employee's email by a corporate sysadmin.
Correct me if I'm wrong, but it seems that both cases WOULD be covered
if the system involved is considered to "affect interstate or foreign
commerce". But how broadly is that phrase interpreted ? Would the
mere fact that a company has out-of-state customers, or that a
university has out-of-state students, be sufficient, or would a
stronger connection be required ?
--
Frank Wilson | fwilson@acs.bu.edu
------------------------------
From: gmcgath@mv.MV.COM (Gary McGath)
Date: 09 Dec 1994 12:21:16 -0500
Subject: AppleLink and SSN's
When you apply for an AppleLink account, you are asked to give the last
four digits of your Social Security Number. This is used to identify
you if you call in claiming you've forgotten your password. This
suggests that anyone who knows your account name and your Social
Security Number can get your password from Apple without much trouble.
The choice of Social Security Number for this purpose is doubly poor,
even aside from the inappropriateness of using it for non-tax purposes.
First, it's not secure or private; lots of people have your SSN.
Second, requests for Social Security Numbers are often accompanied by
threats of dire legal penalties for giving false information, so people
are less likely to think of giving a fake SSN here than they would of
giving, say, a fake MMN (mother's maiden name).
Nonetheless, there is no legal penalty for giving false information in
this case; Apple doesn't care, as far as I know, whether you give your
real SSN or not. You can either refuse to give a Social Security
Number, in which case Apple will assign you a four-digit code, or you
can make up a number. The former makes more of a statement, while the
latter is easier.
--
Gary McGath
gmcgath@mv.mv.com
------------------------------
From: sean@sdg.dra.com (Sean Donelan)
Date: 09 Dec 94 14:59:24 CDT
Subject: Re: Caller ID and Blocking
Organization: Data Research Associates, St. Louis MO
Lynne Gregg <lynne.gregg@mccaw.com> writes: As it stands today, the
FCC Ruling on Calling Number Services is likely to go into effect
4/95 as originally ordered in 3/94. Although the FCC Ruling does
away with per line blocking (on interstate calls) it does require
carriers to support the feature code *67 for per call blocking.
It makes it very hard for a telephone user to predict what will
happen.
If you have per-line blocking on your telephone line, and you make an
interstate telephone call, what happens? If you dial *67 that reverses
the default condition, but what is the default condition? What happens
if you dial a local phone number that is really a FX line to another
state? Should you dial *67 or not?
Anyone care to predict how many different ways these things will get
programmed into different switches around the country?
--
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Domain: sean@dra.com, Voice: (Work) +1 314-432-1100
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 09 Dec 1994 15:32:13 -0600 (CST)
Subject: Calling Line ID --- Warning by DP Registrar
Organization: University of Wisconsin-Milwaukee
Taken from alt.privacy:
The following press release was issued by the Data Protection
Registrar on November 21.
CALLING LINE IDENTIFICATION RAISES NEW PRIVACY ISSUES
"Be careful" says Data Protection Registrar
The Data Protection Registrar, Elizabeth France today warned people
about the risks of two new calling line identification systems being
introduced by BT on November 22nd. These two new services: Call
Display and Call Return will make it possible to capture and record the
telephone numbers of people calling you. Those receiving calls will in
most cases be able to identify the number from which a call is made
even if it is ex-directory.
When making a call it is possible to withhold your number by prefixing
the number dialled by 141. But BT do offer a free per-line blocking
service for preventing the display and transmission of the individual
telephone number on all calls without dialling 141: you have to ask BT
for this service.
Mrs France is concerned that people do not know enough about these new
developments. "These new systems may breach the first principle of the
Data Protection Act which says that personal information must be fairly
obtained and processed," Mrs France explained. "I am worried that many
people do not know what is going on. I am particularly concerned for
ex-directory customers."
Mrs France has decided that outgoing calls from the Registrar's office
will, in general, have the number blocked. "We do not expect people to
use Call Return to call us back and we do not want people to be
confused by a number which they do not recognise. We are also
concerned about preserving the confidentiality of, for example,
complainants who might not wish to reveal that they had been in touch
with my office".
For further information please contact John Woulds, Senior Assistant
Registrar or Dianne Brown-Wilson, Publicity Manager, tel:0625 535711;
fax: 0625 524510
--------------------------
My phone line had CLI disabled over a month ago. I also registered a
complaint with Oftel. Details on how to do this are included in
British Telecomm's literature. Despite my requests for confirmation in
writing that the feature had been disabled, I have not yet received
confirmation. Perhaps I need to phone Oftel again.
--
Paul Leyland <pcl@sable.ox.ac.uk> | Hanging on in quiet desperation is
Oxford University Computing Services | the English way.
13 Banbury Road, Oxford, OX2 6NN, UK | The time is gone, the song is over.
Tel: +44-865-273200 Fax: +44-865-273275 | Thought I'd something more to say.
Finger pcl@sable.ox.ac.uk for PGP key |
------------------------------
From: mr@world.std.com (Michael J Rollins)
Date: 09 Dec 1994 21:47:17 GMT
Subject: Re: Parents' SSNs wanted for Fundraising
Organization: The World Public Access UNIX, Brookline, MA
Wm. Randolph U Franklin (wrf@ecse.rpi.edu) wrote: This is from
Chronicle of Higher Ed, Nov 30, page A35, an article on getting
students' parents to contribute money even before the student has
graduated.
George Wash U asks parents to fill out and return an info card,
which appears to be from the Registrar, but is in fact from
Development (=fundraising). The card asks for the parent's SSNs.
The article says that Development can use this info to get the
parent's income and property that they own, tho it doesn't outright
say that GWU is doing this.
Several years ago, I telephoned for information about taking classes at
a local, at that time "for profit," trade school named Johnson and
Wales. My address and phone number were turned over to the Alumni
Office, which then began to systematically hound me for donations.
Please note that this was a FOR PROFIT institution. It should be
obvious that I have never taken any classes there!
--
Mike Rollins mjr@ids.net mr@world.std.com
------------------------------
From: vin@shore.net (Vin McLellan)
Date: 09 Dec 1994 13:12:33 -0500
Subject: Regarding National Cryptography Policy
From: crypto@nas.edu (CRYPTO)
Subject: Question #1 to the community regarding National...
Date: 09 Dec 1994 09:45:31 -0600
Organization: UTexas Mail-to-News Gateway
Subject:
Question #1 to the community regarding National Cryptography Policy
As many of you know, the National Research Council is
undertaking a study of national cryptography policy
(description available on request to CRYPTO@NAS.EDU).
This note is the first of a number of questions that will
be posted to the Internet community in our attempt to solicit
input on a broad scale. Please circulate this request to anyone
that you think might be able to contribute.
The question of this posting is the following:
How, if at all, do capabilities enabled by new and emerging
technology in telecommunications (e.g., key-escrow
encryption technologies, digital telephony) and electronic
networking make it _easier_ for those who control that
technology to compromise and/or protect the interests of
individual end users? Please use as the standard of
comparison the ease _today_ of compromising or
protecting these interests. We are interested in
scenarios in which these interests might be compromised
or protected both individually and on a large scale. Please
be sure to tell us the interests you believe are at stake.
Please send your comments on this question
to CRYPTO@NAS.EDU.
------------------------------
From: njgreen@panix.com (Noah Green)
Date: 10 Dec 1994 08:44:34 -0500
Subject: Good Times; Journalist's Questions?
Organization: Panix
I am a reporter for the Village Voice doing a story on the "Good Times"
virus hoax on AOL and what it says about our perceptions of email,
about AOL, and about online life in general. If you have any (quotable)
opinions you'd like to share, or know any additional facts about the
situation (particularly stuff like who may have done the original post,
etc.) please email me at njgreen@panix.com. My deadline is on monday,
so please write before then. Any feedback is much appreciated.
noah green
njgreen@panix.com
------------------------------
From: bernie@fantasyfarm.com (Bernie Cosell)
Date: 11 Dec 1994 02:18:42 GMT
Subject: Re: Dynamic Negotiation in the Privacy Wars
Organization: Fantasy Farm, Pearisburg, VA
Winston Edmond writes:
rem@world.std.com (Ross E Mitchell) wrote: But a call that is
rejected because of its anonymity should entail no charge.
This requires that the call be intercepted by the phone
company's central office switchboard before it reaches the
recipient's line.
Doesn't one of the Baby Bells already offer an extra-cost service
that allows one to automatically reject calls where the ID is
blocked (i.e., "out of area" isn't blocked, but *67 calls would be
rejected)?
Bell Altantic, down where we are in SW Viginia, does that. It is
called "Anonymous Call Rejection" and it "lets you reject calls from
callers who have used Per Call Blocking". Another interesting aspect
of the Caller ID mess down here is "NOTE: ... your number will be shown
on their display ... even if your number is non-published or
non-listed".
--
Bernie Cosell bernie@fantasyfarm.com
Fantasy Farm Fibers, Pearisburg, VA (703) 921-2358
--->>> Too many people; too few sheep <<<---
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 11 Dec 1994 10:18:58 -0600 (CST)
Subject: German Telecom - Technical Risks/Crime
Organization: University of Wisconsin-Milwaukee
German telephone systems, like many European phone systems, long have
used mechanical meters that run at different rates (clicks per minute)
for different connections (faster clicks for long distance) with a bill
at the end of the month based on the number of clicks. This had two
features; first there was not way to trace who you called and second
there was no way to contest a portion of the bill.
The first feature, which probably drove the system, was based on the
fear of improper data collection on who one called, appropriate for a
government owned phone system in a nation that remembered a time of
oppression by its own government.
New electronic systems continue to emulate this old mechanical system
with one result (based on feature 2) being nicely discussed in this
copied posting.
--
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
Taken from RISKS-LIST: RISKS-FORUM Digest Sat 10 December 1994 Volume
16 : Issue 64 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED
SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann,
moderator
Date: 10 Dec 1994 13:33:11 +0100
From: Klaus Brunnstein <brunnstein@rz.informatik.uni-hamburg.d400.de>
Subject: German Telecom: technical risks/crime
German media's awareness about Telecom related crimes was raised
significantly when International Herald Tribune reported on its front
page earlier this week that "several thousands of German Telecom
employees" are suspected to have participated in criminal activities
which damaged German Telecom in the order of 500 million DM. According
to this report, telephone lines were switched to service providers in
areas such as Netherlands Antillas where services such as astrologic
reports (horoscopes) and taped sex conversations are regularly offered
at high prices (up to 12 DM/minute); such services are usually
announced in German boulevard newspapers on specific pages.
Income from such telephone calls is usually divided between German
Telecom which bills it's resp. international tariff, and the related
PTT (e.g. NL-Antillas PTT) which subtracts its tariff from the amount
sent and distributes the rest to the service provider. This trade
between the PTTs is calculated by counting the *total volume of connect
time* between related Telecoms. This implies that Telecom pays more to
another PTT than it can charge to individual customers if some pirates
succeed to generate communication between PTTs even when a real
connection was NOT established, or with other criminal tricks. In cases
reported by Herald Tribune, Telecom employees and service providers
worked together to generate a significant volume of communication. Such
procedures are a modern version of earning real money with "virtual
communication" :-)
As German media (with few exemptions) are not well informed about
details of Telecom procedures and systems, much noise was generated,
where some "experts" (e.g. a misinformed member of the Chaos Computer
Club :-) said that hackers may have hacked Telecom computers (which is
nonsense, both in the sense of telephone hacking=phreaking and computer
hacking). While Telecom admitted that investigations were underway (one
day later, 2 Telecom employees and 1 service provider were jailed,
being accused with having damaged German Telecom in the order of 2
million DM), spokesmen immediately rejected that damage be in the order
of 500 million DM. More cases are evidently underway (both in jailing
and reporting :-).
Since some time, public is growingly concerned about Telecom bills as
steadily growing numbers of Telecom customers complain about
unexpectedly high telephone bills. With estimated 600,000 customers (of
35 mio private customers) complaining this year, and a roughly
estimated mean damage of 1,000 DM (as many customers report too high
figures over months, with single bills adding to over 200,000 DM!), the
*overall damage for private customers* may sum up to about 600 million
DM! Despite of some recent damages to enterprise switching systems,
discussion concerning potential economic damage has not reached the
media so far.
Unfortunately, German telecom customers so far cannot control their
bills amount and so argue whether they really connected to such service
providers. Different from other technically advanced countries, German
customers receive monthly bills with *sums of telephone units and the
total price which they have to pay*. This is a relic from ancient
technologies when units were counted in electromechanical counters
whose actual figures were photographed for documentation purposes; the
photos of a new and the last month were compared to calculate the
difference as the basis of the new bill. Since some time, digital
switching systems (esp. Siemens' EWSD and Alcatel' S12) are installed
in most regional switching offices (Vermittlungsstellen), where a
log-record is stored for each call containing all essential billing
data. While German Telecom only recently offered to list details of
each telephone call if customers apply for this service and pay a
monthly price in the order of 10 DM), a federal parliament's commission
(Petitionsausschuss) recently suggested to the ministry of
Telecommunications that detailed bills should be given and that such
service should be free of a fee (as e.g. in US and Canada).
Presently, a growing number of customers are seeking legal help against
such Telecom bills. In few cases, courts (assisted by technical
expertises about potential faults and points-of-attacks) have sentenced
the bills as irregular. As in many cases of digital technologies,
complexity of Telecom networks has grown so rapidly that new risks have
appeared, e.g. in software and management of complex switching systems.
In several cases, software bugs were not detected in Telecom's very
detailed test process; in one case, billing records were store doubly,
which was only detected "in the field". Management of such systems has
never been analysed for any reasonable "quality" (even an ISO
9000-based analysis which is not very adequate would lead to
improvements).
In cases of growingly complex systems with growing bugs and management
faults, more customer protection is needed. As customers are rarely
able to relate overly high bills to technical problems of any kind, it
should belong to the professional duties of related experts and their
organisations (international as IFIP; national as ACM, BCS, GI/Germany,
IEEE) to provide expertise for the public in cases such as Telecom
criminality (from which side whatsoever). This may also help to produce
better insight of public media about technologies.
Klaus Brunnstein (Dec.10,1994)
------------------------------
From: tc@epic.org (Dave Banisar)
Date: 11 Dec 1994 18:07:22 -0400
Subject: Re: Clipper Chip Information Needed
Organization: Electronic Privacy Information Center
Shannon Dunn <SHDUNN@NMU.EDU> wrote: My name is Shannon Dunn and I
am a junior at Northern Michigan University. My reason for writing
is to request information on the Clipper Chip issue. Any kind of
information reguarding the Clipper will be a great aid to an ethics
paper I am writing concerning this issue. Thank You.
We have an extensive archive of materials on Clipper at cpsr.org
/cpsr/privacy/ encryption/. Also look at the back issues of the EPIC
and CPSR Alert at cpsr/alert/
--
Dave Banisar
Electronic Privacy Information Center
------------------------------
From: Chuck Weckesser <71233.677@compuserve.com>
Date: 12 Dec 94 03:23:25 EST
Subject: Value of Pretty Good Privacy
PGP is a joke. Why people even bother with it is beyond me; there is
little difference in leaving your system unlocked--except for time.
--
Chuck Weckesser
------------------------------
From: "Prof. L. P. Levine" <levine@blatz.cs.uwm.edu>
Date: 28 Nov 1994 08:46:14 -0600 (CST)
Subject: Info on CPD, (unchanged since 11/28/94)
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.
This digest is a forum with information contributed via Internet
eMail. Those who understand the technology also understand the ease of
forgery in this very free medium. Statements, therefore, should be
taken with a grain of salt and it should be clear that the actual
contributor might not be the person whose email address is posted at
the top. Any user who openly wishes to post anonymously should inform
the moderator at the beginning of the posting. He will comply.
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 and is not redundant or insulting. 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 #072
******************************
.