Date: Thu, 28 May 92 17:25:41 EST
Errors-To: Comp-privacy Error Handler <comp-privacy-request@PICA.ARMY.MIL>
From: Computer Privacy Digest Moderator <comp-privacy@PICA.ARMY.MIL>
To: Comp-privacy@PICA.ARMY.MIL
Subject: Computer Privacy Digest V1#036
Computer Privacy Digest Thu, 28 May 92 Volume 1 : Issue: 036
Today's Topics: Moderator: Dennis G. Rears
Re: Caller ID decision
Re: California Drivers Lic & SSN
Re: California Drivers Lic & SSN
Re: Call waiting and Caller ID
New amendment to Buckley Act of 1974
Driver Licenses
The Computer Privacy Digest is a forum for discussion on the
effect of technology on privacy. The digest is moderated and
gatewayed into the USENET newsgroup comp.society.privacy
(Moderated). Submissions should be sent to
comp-privacy@pica.army.mil and administrative requests to
comp-privacy-request@pica.army.mil.
Back issues are available via anonymous ftp on ftp.pica.army.mil
[129.139.160.200].
----------------------------------------------------------------------
From: "david.g.lewis" <deej@cbnewsf.cb.att.com>
Subject: Re: Caller ID decision
Date: Wed, 27 May 1992 13:42:28 GMT
In article <comp-privacy1.31.7@pica.army.mil> gt3741b@prism.gatech.edu (John Rudd a.k.a. Kzin -- Big Electric Cat) writes:
> Yes,I know that Long Distance tends to block the ID automagically..
>I think that ought to be fixed (and if the LD companies would just support
>it, it could be). If not, then the blocked calls should be local calls only.*
>
> * as an asside, a leading code could be sent that instead of
> saying "no ID available", said "this person is or isn't blocking their
> ID", separate from the availablility of their ID.
The calling line identification is sent between switches by SS7. The reason
it is not provided to the called party on LD calls is that there is
not end-to-end SS7 connectivity between the originating office and the
terminating office, because the connections between LEC and IXC are not yet
SS7-signaled.
The indication that a caller has invoked 'blocking' (presentation
restriction) is carried in the same SS7 parameter as is the calling party
number. Therefore, if the number is not available due to lack of end-to-end
SS7, the presentation restriction indicator is not available for the same
reason. Therefore, on a LD call, there is no way (short of sufficient SS7
deployment) for the terminating office to "know" whether or not the calling
number presentation is restricted or allowed.
The other thing you were looking for - a feature which would allow calls
arriving with "presentation restricted" to not be delivered and instead
routed to a recording - is currently implemented on several switches that
support CLASS services (I know it's on the 1A ESS(TM) switch, and think it's
on the 5ESS(R) switch; don't know about other vendor's products). If the
call arrives at the terminating office with the presentation indicator set
to "presentation restricted", the call is routed to an announcement
independent of the state of the called party's line. If the call arrives
and the calling party number is not available, the call is delevered with
the "out-of-area" indication.
David G Lewis AT&T Bell Laboratories
david.g.lewis@att.com or !att!houxa!deej Switching & ISDN Implementation
------------------------------
From: Cristy <cristy@eplrx7.es.dupont.com>
Subject: Re: California Drivers Lic & SSN
Date: Wed, 27 May 1992 14:16:35 GMT
In article <comp-privacy1.35.6@pica.army.mil> idela!bell@uunet.uu.net (Mark Bell) writes:
>
>California now seems to have a law that one has to submit a Social
>Security number for driver's license renewal. Does anyone have any
>advice on how this can be avoided? What if one is a minister who has
>taken a vow of poverty and doesn't have an SSN?
There is only one thing you can do. Invoke your rights under the 1974
Privacy act and request that they tell you:
1: Whether disclosure of your Social Security Number is required or
optional,
2: What law authorizes them to ask for your Social Security Number,
3: How your Social Security Number will be used if you give it to them, and
4: The consequences of failure to provide an SSN.
The Tax Reform Act of 1976 gave authority to state or local tax,
welfare, driver's license, or motor vehicle registration authorities to
use the number in order to establish identities.
--
cristy@dupont.com
------------------------------
From: hibbert@xanadu.com (Chris Hibbert)
Subject: Re: California Drivers Lic & SSN
Date: Thu, 28 May 92 00:20:44 GMT
Mark Bell writes:
>California now seems to have a law that one has to submit a Social
>Security number for driver's license renewal. Does anyone have any
>advice on how this can be avoided?
>
>Mark Bell
This isn't quite right. The law requires a SSN in order to get a new
license, and it won't be until next year that you have to give an
Social Security Number to get a renewal.
Dodging this requirement isn't going to be easy without a court
challenge. Remember, this is the state; they don't even have to
listen to your story, there's a law that says you have to give them an
SSN. If you don't already have one, the clerk will be quite willing
to tell you to go get one if you want a license.
Is there anyone out there that's willing to challenge the new law in
court? You'd have to be willing to go without a license while the
whole thing meanders through the courts. The only plausible challenge
I've heard is on the basis of the state constitution's provision of a
right to privacy in Article 1. I'm willing to do a fair amount of leg
work in putting the challenge together. (I'm a member of the
Computers and Civil Liberties working group of the Palo Alto Chapter
of CPSR, and SSNs are one of my hot buttons. I'm not a lawyer.) My
license doesn't expire for a while, so I can't usefully refuse to give
them a SSN. It's possible that someone who just wants a State-issued
ID card would do as well for a test case, but it sure seems like the
place to start is with someone who can refuse to give a SSN, and wants
a card anyway.
I'm serious about this. Please contact me if you're interested.
Chris
--
hibbert@xanadu.com AMIX: CHibbert
uunet!xanadu!hibbert MCIMail: CHibbert
------------------------------
Date: Thu, 28 May 92 10:47:40 CDT
From: Alan L Varney <varney@ihlpf.att.com>
Subject: Re: Call waiting and Caller ID
In article <comp-privacy1.35.7@pica.army.mil> dpenner@ee.ualberta.ca (Darren E. Penner (Dokken)) writes:
>Just a note to the uninformed people spreading all sorts of rumers about
>call waiting and caller ID.
>
>You WILL NEVER see the number from a person if you are using the line. This
>is becuase the callers ID is sent between the First and Second Rings. Now
>if you are familar with call waiting, the phone does NOT ring, it just beeps,
>an entirely different notification technique. Also note that it happens
>AFTER the first ring, so you can not tell in advance who is calling.
Well, NEVER just gets closer and closer .... Bellcore and
some vendors have been working for a couple of years on the
Caller-ID delivery on "call waiting" problem. There are several
things happening in the area of data delivery to analog customers,
and this is just one small part of a bigger picture.
Below is a slightly edited version of information I sent off
to comp.dcom.telecom recently. But the requirements from Bellcore
include the ability of exactly the ability to send Calling Party
Number and/or Name during the "call waiting beep" interval.
******** Previously published in comp.dcom.telecom *************
Let me take the opportunity here to let those folks who are
REALLY interested in the Caller-ID interface ("REALLY" means you
might actually be willing to pay a few dollars for some documents,
instead of just demanding free stuff) know what's new and evolving
in this area. ...
The "Caller-ID signaling" revisions alter the requirements for
Caller-ID equipment at the Customer end and the CO end. They also
place requirements on equipment in-the-loop, such as Digital Loop
Carrier, Fiber-In-The-Loop, Remote Concentrators, etc. Other req.
provide some of the usage requirements for the equipment, dealing
with "Calling Identity Delivery" (Calling Party Number and/or Name),
delivery during Call Waiting, delivery of information while on-hook
and not ringing, etc.
What requirements are available? Just look {my comments in braces}:
- TA-NWT-000030, Issue 3, "Voiceband Data Transmission Interface
Generic Requirements", April 1992, RFC 92-29, comments due by
June 30, 1992. This is a proposed revision to a previous TA
(TA-NWT-000030, Iss. 2) and original TR-TSY-000030 requirements.
Bellcore does not have an expected date for release of the TR,
but I would expect 1/93 or so, if industry disagreements can be
resolved.
{The TA has CO requirements for what is currently used for the
calling number/calling name CO-to-CPE interface for an analog
The current TR only covers data delivery while on-hook during
ringing (between first and second ring cycle). The TA proposes
a mechanism for data delivery during on-hook-idle and talking
states. It is compatible with existing "boxes" only during the
on-hook-ringing state. (An example of creeping featurism???)
Appendix A of the TA is a revision of SR-NWT-002024, "CPE
Compatibility Considerations for the SPCS-to-CPE Data Transmission
Interface", Iss. 1, April 1992. The SR is just released, and now
some not-obviously-related TA is proposing revisions! If you are
a vendor interested in SR-NWT-002024, it appears you must comment
on the TA-30 Appendix, unless you want to accept the new version
of SR-2024 without comments!! There are MAJOR changes.
The App. suggests that Call-ID memory be large enough to store
information on an average day's calls (Bellcore doesn't specify
that number...), that the display be multi-line so that all
information on a single call can be displayed at once, that the
display be backlit or illuminated.
The requirements appear to allow information transfer from the
far-end party during a call. During transmission, the CPE-to-
handset/keypad path is muted. The timing is pretty critical,
however. There are also requirements for inhibiting the data
reception/acknowledgement when an extension is off-hook, and
a suggestion that the CPE have an on/off switch that would
allow disabling of the off-hook data detection. So if your
answering machine is hooked up as an extension -- not through
the CPE -- the "hacking" of the CPE would be prevented for calls
while you are away. This would also minimize the interference
during a caller's recording when a second caller "call waits"
your answering machine. But to receive the Caller-ID-on-call-
waiting information, all the extension telephones would have
to be connected through the CPE.}
------
TAs can be ordered from:
Bellcore
Document Registrar
445 South Street - Room 2J-125
P. O. Box 1910
Morristown, NJ 07962-1910
Takes 3-4 weeks(!), and the RFC # is helpful, if known. You can also
register as a vendor and receive future like-topic TAs automatically.
Al Varney - the above represents my opinion, and not AT&T's....
------------------------------
Date: Thu, 28 May 92 15:59:21 EDT
From: "RAVI A. KRISHNAN" <rak0@lehigh.edu>
Subject: New amendment to Buckley Act of 1974
I have just heard that there has been a recent amendment to the
Family Educational Rights and Privacy Act of 1974 (Buckley Act). This
amendment supposedly opens up a students admissions committee work
notes to the student. Does any one know anything about this?
Specifically, what is the name of the Amendment and where can a copy of
the text of this amendment be found? I am very interested in seeing
what else this amendment opens
up and makes public.
Ravi Krishnan
------------------------------
Date: Thu, 28 May 92 17:18:34
From: Computer Privacy Digest Moderator <comp-privacy@pica.army.mil>
Subject: Driver Licenses
Several people wrote to talk about different ways states identify
people under 21 for driver's licenses. Thank God I grew up in Germany
where they do not waste thier time on drinking age madness. Anyway it is
time to close this thread as it really does not have to do with effect of
technology on privacy. As a courtesy to the readers and submitted I have
combined all the posters comments into one article.
Dennis
David Olsen <dko@cs.wisc.edu> wrote:
Some states do. Maryland even does one better than that. If you
are less that 21 years old, your photo is a profile. Your date of
birth is still on the license, but no one has any reason to read
it. Not all government agencies are lazy and ingorant.
Ben Combee <gt0501c@prism.gatech.edu> wrote:
In the state of Georgia, driver's licences of minors have a red
UNDER 21 stamped over the picture for that purpose. The birthdate
is still on there, but for that kind of IDing, all a bartender need
check is for the stamp.
Carl Ellison <cme@ellisun.sw.stratus.com> wrote:
There is at least one state (I forget which) whose drivers' license
has pictures in profile for minors and front-view for adults.
J. Michael <76117.367@compuserve.com> wrote:
A Florida drivers license has different colored backgrounds for
above and below the age of 21.
Angelina Whitford <angelina@casbah.acns.nwu.edu> wrote:
Maryland has had profile shots of under 21 drivers for years. In
just the past few years, they have added the words "Under 21" on
the license. Over 21 licenses have full-face photos and
(obviously) no "Under 21" printed on it.
------------------------------
End of Computer Privacy Digest V1 #036
******************************