home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 2 / HACKER2.BIN / 782.CPD358.TXT < prev    next >
Text File  |  1993-10-23  |  12KB  |  290 lines

  1.  
  2. Computer Privacy Digest Mon, 18 Oct 93              Volume 3 : Issue: 058
  3.  
  4. Today's Topics:                Moderator: Dennis G. Rears
  5.  
  6.                        Re: Worse Than Billboards
  7.                      Clinton Health Care Initiative
  8.                             Re: SSN privacy
  9.                             Finding someone
  10.              Personal Privacy vs. the "Digital Detective"?
  11.                             Re: Digital Cash
  12.                             Re: Digital Cash
  13.                       Re: Clinton Health Care Plan
  14.  
  15.    The Computer Privacy Digest is a forum for discussion on the
  16.   effect of technology on privacy.  The digest is moderated and
  17.   gatewayed into the USENET newsgroup comp.society.privacy
  18.   (Moderated).  Submissions should be sent to
  19.   comp-privacy@pica.army.mil and administrative requests to
  20.   comp-privacy-request@pica.army.mil.
  21.    Back issues are available via anonymous ftp on ftp.pica.army.mil
  22.   [129.139.160.133].
  23. ----------------------------------------------------------------------
  24.  
  25. Date: Thu, 14 Oct 1993 15:55:05 +0800
  26. From: Brian Gordon <Brian.Gordon@eng.sun.com>
  27. Subject: Re: Worse Than Billboards
  28.  
  29. I find myself disagreeing with two people with whose opinions I rare do --
  30. John Higdon
  31. >> Subject: Digital Detective At Your Service
  32. >
  33. >I never thought that I would have to see this ad here in addition to
  34. >everywhere else. Are your advertising rates reasonable? I run an IP
  35. >bureau, a long distance aggregation concern, am a telecom and RF
  36. >consultant, and do technical consulting in criminal cases. How much per
  37. >column inch?
  38.  
  39. and the moderator
  40.  
  41. >[Moderator's Note:  I'e received many complaints about this one.  This is
  42. >one where I wasn't paying attention.  I was gone for about 10 days
  43. >and really just looked at the headers as opposed to the body of the
  44. >article. ._dennis ]
  45.  
  46. I too saw the "ad" several places, and thought that it was especially
  47. appropriate for this forum.  It was, deliberately, I am sure, a SCREAM
  48. to wake people up to the amount of information that is cheaply and
  49. readily available about them.  No abstractions about "if I have your
  50. SS# I can gets lots of stuff about you", but a real catalog of WHAT
  51. information ANYONE can get.  I thought it was one one the most useful
  52. articles posted here in a long time ...
  53.  
  54. [Moderator's Note:  I think the problem was it was more of an
  55. advertisement than a statement that it was available. ._dennis ]
  56.  
  57. ------------------------------
  58.  
  59. Acknowledge-To:  WHMurray@DOCKMASTER.NCSC.MIL
  60. Date:  Thu, 14 Oct 93 21:12 EDT
  61. From:  WHMurray@dockmaster.ncsc.mil
  62. Subject:  Clinton Health Care Initiative
  63.  
  64.  
  65. >Dennis D. Steinauer
  66. >National Institute of Standards and Technology
  67. >A-216 Technology
  68. >Gaithersburg, MD 20899 USA
  69. nist.gov
  70. >
  71. >BTW --  The "Card" isn't likely to be a smartcard, massive memory card, or
  72. >other such thing -- at least not for a long time.  Indeed, it probably won't
  73. >even be the SAME card in all ares.  
  74.  
  75. I was afraid of that.
  76.  
  77. Actually, all other things equal, I prefer a very smart card.  While
  78. I do not expect either the bureaucrats or the service providers to 
  79. give it up, the best solution is one in which all of the data is 
  80. recorded only on the card, kept in the custody of the data subject, and
  81. used only with his cooperation and consent.  
  82.  
  83. >The president's plan, in line with the
  84. >approach of encouraging technical innovation, initially calls for a minimal
  85. >machine readability capability (read "mag strip").
  86.  
  87. This is 1993. "Minimum machine readability" does not require a "mag
  88. strip."  In 1993 we do not even need the number, much less a "dumb" card.
  89. (What kind of "technical innovation" is a mag stripe card?)
  90.  
  91. The evil is in the data base, not in the card and not in the number.  It
  92. is in the untintended, unanticipated, and unauthorized secondary uses
  93. that will be conceived by the over zealous (those well intentioned and
  94. professional people who brought you Waco).  It is in the unavoidable
  95. errors in the data and in the accidental, but equally unavoidable.
  96. disclosures.   
  97.  
  98. William Hugh Murray, Executive Consultant, Information System Security
  99. 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840                
  100. 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL
  101.  
  102. ------------------------------
  103.  
  104. From: Adrian Demarais <adrn@access.netaxs.com>
  105. Subject: Re: SSN privacy
  106. Date: 15 Oct 1993 04:03:13 GMT
  107. Organization: Net Access - Philadelphia's Internet Connection
  108.  
  109. Vincent Broerman (0005461808@mcimail.com) wrote:
  110.  
  111.  .. why is SSN privacy such a  big deal...
  112.  
  113.   A name, address, and SS number is all a lot of credit card companies
  114. ask for when issuing a card. People have been sued for non-payment of
  115. bills accrued by someone issued a card in their name, at a different
  116. address.
  117.  
  118. ------------------------------
  119.  
  120. From: Rajiv A Manglani <rajiv@athena.mit.edu>
  121. Newsgroups: alt.privacy,comp.society.privacy,misc.legal
  122. Subject: Finding someone
  123. Date: 15 Oct 1993 05:17:05 GMT
  124. Organization: Massachusetts Institute of Technology
  125. Distribution: world
  126.  
  127. I am trying to find a lost relative. All I have is his name, birth date, and
  128. social security number. How might I get an address or phone number?
  129.  
  130. Rajiv
  131.  
  132. --
  133.  
  134.  -------------------------------------------------------------------------
  135.  
  136. Me:     Rajiv A. Manglani               rajiv@mit.edu
  137.  
  138.         La Maison Francaise             Brilliant Image
  139.         476 Memorial Drive #513         Seven Penn Plaza
  140.         Cambridge, MA 02139-4319        New York, NY 10001
  141.         617. 225. 7690                  800. 727. 3278 x200
  142.  
  143.  -------------------------------------------------------------------------
  144.        Stuyvesant High School Alumni EMail Address List Maintainer
  145.  -------------------------------------------------------------------------
  146.  
  147. ------------------------------
  148.  
  149. From: Craig Wagner <craig.wagner@his.com>
  150. Reply-To: craig.wagner@his.com
  151. Date: Fri, 15 Oct 1993 11:29:59
  152. Subject: Personal Privacy vs. the "Digital Detective"?
  153.  
  154.   "A> From: "Tansin A. Darcos & Company" 
  155.  
  156. Just an observation based upon the following:
  157.  
  158.   "A> I once called one of the local offices of a national credit bureau.  I
  159.   "A> pretended to be an employer, and asked them, if I was just interested
  160.   "A> in getting an occasional listing because I am checking perhaps 5 or 6
  161.   "A> people a year as potential employees, and not doing enough business to
  162.   "A> justify a $15 a month subscription, was it possible for me to obtain
  163.   "A> reports even though I am not a subscriber.  'Certainly'.  I have to
  164.   "A> send in a written statement indicating (1) that I have a legally
  165.   "A> authorized reason to obtain the information, and (2) what that reason
  166.   "A> is, e.g. type of request, employment, credit, etc. 
  167.  
  168.   "A> I think only the credit reports needed proof of a legitimate business
  169.   "A> reason.
  170.  
  171. The two requirements enumerated above do _not_ constitute providing "proof" of
  172. a legitimate business reason, any more than a felon signing a statement
  173. claiming not to be a felon in order to purchase a gun is "proof."  Perhaps
  174. something more is required, but as stated, I could send in a letter with a
  175. fictitious name, using an anonymous mail drop, and get access to anyone's
  176. credit rating.  Was something else left out?  Is a copy of some govt. document
  177. "proving" identity also required?
  178.  
  179. ------------------------------
  180.  
  181. Date: Fri, 15 Oct 93 13:08:34 PDT
  182. From: "Dick Murtagh (8-465-4916)" <dickm@vnet.ibm.com>
  183. Subject: Re: Digital Cash
  184.  
  185. In article <comp-privacy3.55.3@pica.army.mil> Todd M Cocks <tmc141@skorpio.usas.ca> writes:
  186. > Why is privacy so important ...
  187.  
  188. I know this is taken out of context, but it is imporant none the less. Many
  189. use this as an argument against privacy issues.
  190.  
  191. Why is freedom of speech so important ?  It's the same question.  The right
  192. to privacy is protected as a natural right under the 8th amendment.  That it
  193. isn't specifically stated has more to do with the limitations of the writers
  194. than their reverence.
  195.  
  196. If 1789 there were no monolithic computer systems gathering and disseminating
  197. information about our private rights.  So, there was no need to explicitly
  198. state it.
  199.  
  200. "A man who is willing to trade freedom for safety, deserves neither freedom
  201. nor safety".  Are we willing to trade our freedom for mere convenience ?
  202.  
  203. ------------------------------
  204.  
  205. From: Ted Oliverio <olie@netcom.com>
  206. Subject: Re: Digital Cash
  207. Organization: NETCOM On-line Communication Services (408 241-9760 guest)
  208. Date: Fri, 15 Oct 1993 20:14:10 GMT
  209.  
  210. Please forgive my naivette, I'm lost:  How does my digital-cash card
  211. act differently than my ATM (debit) card?
  212.  
  213. If it helps, I understand, deeply, how the debit card works.  I just have
  214. no idea what a digital-cash card is.  I also understand that it may just
  215. be a proposal and, as such, doesn't exist yet.  If this is the case, please
  216. explain how your IDEAL digicash-card would work.  And how this is different
  217. from my debit-card.
  218.  
  219.  
  220. -- 
  221.                             \  Home of "Barrel-Of-Monkey-Enterprises",
  222.     olie@netcom.com          \  Tubing-Central. (If you have to ask...)
  223.                               \
  224.                                \  Tubors Rule!
  225.  
  226.  
  227. ------------------------------
  228.  
  229. From: Steven Minor McClure <steve@owlnet.rice.edu>
  230. Subject: Re: Clinton Health Care Plan
  231. Organization: Rice University
  232. Date: Fri, 15 Oct 1993 20:58:18 GMT
  233.  
  234. >Jerry Whelan  <guru@camelot.bradley.edu> wrote:
  235. >...
  236. >Oops!  Lost the card.  Sorry we didn't know abot your allergy
  237. >to this common anesthetic....
  238. >
  239. "I'm sorry sir, no card, no treatment"
  240. "...you will have to go to your local
  241. health care card office to have a replacement made"
  242. "next please!"
  243. I think there are very legitimate reasons to have medical records stored in
  244. several different places around the country....Hey, accidents happen.
  245.  
  246. There also needs to be some way to keep these out of the hands of snoopers,
  247. etc.  No one wants bored govt. workers looking through medical histories.
  248.  
  249. Perhaps everyone should have a copy on their personal card, encoded with
  250. some very small key (such as a PIN).  This data would be mostly protected
  251. by physical security.
  252.  
  253. A second copy could be kept around the country in some network, in a
  254. distributed fashion, where 2 or 3 binary sequences have to be XOR'd to re-
  255. construct the record (similar to key escrow system proposed for Clipper
  256. , which, by the way, sucks for that purpose, but might be OK here,
  257. assuming that suitable escrow agencies can be found).  These binary
  258. sequences would have to be stored at several agencies each, to prevent
  259. loss in disasters, hard disk crashes, etc.
  260.  
  261. A system could be set up where whenever someone needed to access medical
  262. records they would have to prove they are a doctor or something.
  263. A permanent record would be made of the transfer at each escrow agency,
  264. so it would be impossible for a rogue doctor to get a copy of all three
  265. without leaving a 'paper trail' for the patient to find later.
  266.  
  267. By the way, assumed in this scheme is that a patient has complete rights
  268. to look at their medical history.
  269.  
  270. Normally, none of this would have to be done.  The patient would give the
  271. doc. the card and it would be swiped and the medical history would be
  272. loaded into the hospital's computer.  But, if the card was lost, stolen,
  273. or erased, a second copy would be available with only a slight delay.
  274.  
  275. Another assumption here is that the patient would have the responsibility 
  276. to update the remote files by uploading his card to the escrow agencies 
  277. on a regular basis.
  278.  
  279. Sorry this was so long.  Comments anyone?
  280.  
  281. Steve
  282.  
  283.  
  284.  
  285. ------------------------------
  286.  
  287.  
  288. End of Computer Privacy Digest V3 #058
  289. ******************************
  290.