home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / privacy / p03_022.txt < prev    next >
Text File  |  1996-09-03  |  36KB  |  707 lines

  1. PRIVACY Forum Digest     Saturday, 12 November 1994     Volume 03 : Issue 22
  2.  
  3.           Moderated by Lauren Weinstein (lauren@vortex.com)
  4.             Vortex Technology, Woodland Hills, CA, U.S.A.
  5.     
  6.                      ===== PRIVACY FORUM =====
  7.  
  8.          The PRIVACY Forum digest is supported in part by the 
  9.           ACM Committee on Computers and Public Policy.
  10.  
  11.  
  12. CONTENTS 
  13.     PRIVACY Brief (Lauren Weinstein; PRIVACY Forum Moderator)
  14.     Local authority housing id scheme in London (Steve Bowbrick)
  15.     Re: HTTP, New Browsers, & Privacy (M. Hedlund)
  16.         The dangers of half-hearted privacy measures (David Dyer-Bennet)
  17.     CMU blocks access to nasty newsgroups (Mich Kabay)
  18.     Followup on Sears captures signatures (Steve Holzworth)
  19.     Minnesota driver license (Daniel Frankowski)
  20.     Discover Card "Fraud" Mailing update (dgh@BIX.com)
  21.     Ohio Supreme Court Upholds Privacy of SSNs (David Banisar)
  22.  
  23.  
  24.  *** Please include a RELEVANT "Subject:" line on all submissions! ***
  25.             *** Submissions without them may be ignored! ***
  26.  
  27. -----------------------------------------------------------------------------
  28. The Internet PRIVACY Forum is a moderated digest for the discussion and
  29. analysis of issues relating to the general topic of privacy (both personal
  30. and collective) in the "information age" of the 1990's and beyond.  The
  31. moderator will choose submissions for inclusion based on their relevance and
  32. content.  Submissions will not be routinely acknowledged.
  33.  
  34. ALL submissions should be addressed to "privacy@vortex.com" and must have
  35. RELEVANT "Subject:" lines; submissions without appropriate and relevant
  36. "Subject:" lines may be ignored.  Excessive "signatures" on submissions are
  37. subject to editing.  Subscriptions are by an automatic "listserv" system; for
  38. subscription information, please send a message consisting of the word
  39. "help" (quotes not included) in the BODY of a message to:
  40. "privacy-request@vortex.com".  Mailing list problems should be reported to
  41. "list-maint@vortex.com".  All submissions included in this digest represent
  42. the views of the individual authors and all submissions will be considered
  43. to be distributable without limitations. 
  44.  
  45. The PRIVACY Forum archive, including all issues of the digest and all
  46. related materials, is available via anonymous FTP from site "ftp.vortex.com",
  47. in the "/privacy" directory.  Use the FTP login "ftp" or "anonymous", and
  48. enter your e-mail address as the password.  The typical "README" and "INDEX"
  49. files are available to guide you through the files available for FTP
  50. access.  PRIVACY Forum materials may also be obtained automatically via
  51. e-mail through the listserv system.  Please follow the instructions above
  52. for getting the listserv "help" information, which includes details
  53. regarding the "index" and "get" listserv commands, which are used to access
  54. the PRIVACY Forum archive.  All PRIVACY Forum materials are available
  55. through the Internet Gopher system via a gopher server on site
  56. "gopher.vortex.com".  Access to PRIVACY Forum materials is also available
  57. through the Internet World Wide Web (WWW) via the Vortex Technology WWW home
  58. page at the URL: "http://www.vortex.com/".
  59.  
  60. For information regarding the availability of this digest via FAX, please
  61. send an inquiry to privacy-fax@vortex.com, call (818) 225-2800, or FAX
  62. to (818) 225-7203.
  63. -----------------------------------------------------------------------------
  64.  
  65. VOLUME 03, ISSUE 22
  66.  
  67.    Quote for the day:
  68.  
  69.     "I'm going to give you the choice I never had."
  70.  
  71.         -- Lestat (Tom Cruise)
  72.            "Interview With The Vampire" (1994)
  73.  
  74. ----------------------------------------------------------------------
  75.  
  76. PRIVACY Brief (from the MODERATOR)
  77.  
  78. ---
  79.  
  80. As expected, California's Proposition 187, which would ban all educational
  81. services and non-emergency medical services for illegal immigrants, and
  82. require widepread reporting of undocumented persons by numerous entities,
  83. passed easily in the November 8 election.  Also as predicted, its
  84. implementation was immediately halted by at least two courts, and nearly 30
  85. lawsuits were filed against it within 24 hours.  These suits seek to overturn
  86. the initiative on numerous grounds, including constitutionality, conflict
  87. with federal privacy and other laws, conflict with existing U.S. Supreme
  88. Court decisions, and a range of others.  It seems likely therefore that
  89. perhaps years of litigation will be the primary result of the proposition
  90. for the foreseeable future.
  91.  
  92. Discussion of these issues as they relate to privacy topics would
  93. be welcome in this forum.
  94.  
  95. ------------------------------
  96.  
  97. Date:    Mon, 7 Nov 1994 01:25:41 +0000
  98. From:    Steve Bowbrick <steve@3w.com>
  99. Subject: local authority housing id scheme in London
  100.  
  101. Here in Britain there is a historic resistance to a universal
  102. identification document. Citizenship of this country has always been
  103. defined negatively. Despite many abridgements to this ancient, if
  104. unwritten, right, mostly motivated by immigration-hysteria, it is still the
  105. case that 'being here is enough'. I am never required to prove descent, my
  106. citizenship is not defined positively or 'by blood' as it is in many other
  107. European countries and I do not have to carry, or even own, id.
  108.  
  109. Identification is, of course, a part of daily life - cashing a cheque or
  110. opening a bank account will always require some form of id - but there is
  111. no single, accepted form of id, no national id card and drivers' licenses
  112. do not carry pictures or barcodes.
  113.  
  114. Our Prime Minister, John Major, is explicit in his desire for a universal
  115. id document, tied to the tax and social security systems and carrying a
  116. picture. Popular resistance will be considerable. I will not carry one.
  117.  
  118. Recently, and as if in response to the government's new acceptance of the
  119. 'need' for universal id, my local authority, the London Borough of Tower
  120. Hamlets, has introduced a semi-formal id scheme. I and all tenants of the
  121. borough are required to attend an office of the borough to prove that we
  122. are the legitimate occupiers of our homes. A list of acceptable forms of id
  123. is provided - none formal or accepted in law. A drivers license is
  124. adequate. Leaving aside the paradox of positive identification in a country
  125. that has no such concept (I have pointed out to the borough that, even if I
  126. proved my identity to their satisfaction, I would have proved nothing in
  127. law).
  128.  
  129. I have refused to tender id and I am now threatened with court proceedings
  130. for posession of my home. I'd be interested in the opinion of the experts
  131. on whether my anti-id position is defensible in English law. US
  132. perspectives would be welcome.
  133.  
  134. Steve
  135. --
  136. Steve Bowbrick, Editor, 3W Magazine                             steve@3W.com
  137. 3W Magazine, the Internet with attitude                     +44 181 980 4207
  138.                                ~~~~~~~~                 fax +44 181 981 2351
  139. http://www.3W.com/3W/                                mobile +44 1860 183 481
  140.  
  141. ------------------------------
  142.  
  143. Date:    Sun, 6 Nov 1994 23:33:55 -0800
  144. From:    march@europa.com (Marc H.)
  145. Subject: Re: HTTP, New Browsers, & Privacy
  146.  
  147. Ed Kubaitis <ejk@uiuc.edu> wrote, in V03 #21, about HTTP_FROM, an
  148. environment variable passed by some web browsers to HTTP servers.  The
  149. variable contains the user's email address as entered in their
  150. "Preferences," and Ed expressed concern over possible logging of email
  151. addresses by marketers or other web sites.  I'm glad to see this issue
  152. raised again; I brought it up some months ago when AT&T opened their
  153. "youwill.com" contest, for which they asked users to submit a web
  154. form-based survey.  (Adam Curry, who was apparantly involved in the project
  155. and who was surprised to hear address-gathering from forms was even
  156. possible, assured several posters that no logging was taking place at
  157. AT&T's site.)
  158.  
  159. First off, a list of the browsers supporting this variable (with version
  160. numbers known to be inclusive; earlier versions may also belong here, and
  161. later versions almost certainly do):
  162.         MacMosaic 2.0.0a6
  163.         Lynx/2.3 BETA
  164.         Emacs-W3/2.1.54
  165.         OmniWeb 0.7.4.1
  166.         AIR_Mosaic(16bit)(demo)/v3.06.05.03
  167.         MidasWWW/2.1
  168.         Mozilla 0.9b (Netscape) [all platforms]
  169. I collected this information during September of this year (with the
  170. exception of Netscape); this list will hopefully prevent some duplication
  171. of work, but it is _not_ intended as a blacklist.  NCSA Mosaic for X and
  172. Windows, MacWeb, Global Wide Help & Information System (GWHIS), Chimera,
  173. and Spry's Enhanced Mosaic all do not send HTTP_FROM.
  174.  
  175. As a CGI (Common Gateway Interface -- a protocol for running scripts on web
  176. servers) programmer, I am very much in favor of browsers supporting
  177. HTTP_FROM.  Good use of the variable can allow automation of repetitive
  178. tasks, which is the whole point.  I've used it several times to offer a
  179. default return-address for mailing scripts, which both alerts the user to
  180. the capability, and allows him or her to alter the address if they choose.
  181. I see HTTP_FROM as similar to ftpd's familiar "Guest login ok, send your
  182. complete e-mail address as password" prompt: any program or server that
  183. asks users for their email addresses is completely open to receiving a
  184. false address, or none at all, from those users.
  185.  
  186. On the other hand, Ed's reaction -- and Adam Curry's, and that of other
  187. people to whom I've mentioned HTTP_FROM -- indicates that plenty of web
  188. users don't know this capability exists.  I found out myself only by
  189. running a script similar to Ed's (http://www.uiuc.edu/cgi-bin/printenv) to
  190. list all environment varibles sent -- after having been assured by several
  191. people that the web was completely anonymous, what I was seeking didn't
  192. exist, etc.  To use my example above, ftpd is quite explicit about its
  193. logging, but more recent ftp clients (such as ncftp) -- and the browsers
  194. listed above -- are not.  I see this as the real problem.
  195.  
  196. Explicit warnings and documentation seem to be the best solutons. I'm not
  197. sure what Lauren meant when he noted, "future versions of the Netscape
  198. browser will probably be distributed with the name/address feature
  199. defaulting to off."  It seems to me that this is already the case -- the
  200. user has to enter his or her email address for the variable to work.  What
  201. I would like to see is a much more explicit preferences dialog, one that
  202. warns the user about possible logging by web sites.  I would disagree with
  203. any assertion that particular browsers should be avoided because of
  204. HTTP_FROM.  At worst, particular preferences dialogs should be avoided.  At
  205. best, all browsers could provide a menu option -- similar to "Auto-load
  206. images" -- that would allow the user to turn "Privacy" on or off.
  207.  
  208. This is not a web-specific issue.  Interested readers are referred to RFC
  209. 1413, "Identification Protocol,"
  210. <URL:http://www.cis.ohio-state.edu/htbin/rfc/rfc1413.html>, which details a
  211. more-reliable, transparent, and generalized implementation of TCP
  212. connection logging.  I think it only prudent to assume that any site you
  213. visit on the net could keep a log of your visit; and that as time passes,
  214. more and more sites -- particularly commercial sites -- will do just that.
  215. Browse carefully; the junk mail "you will" receive may be at stake.
  216.  
  217. I support Lauren's call for regulation of the use of such information.
  218.  
  219. M. Hedlund <march@europa.com>
  220.  
  221.    [ My meaning regarding the presumed future default for "Netscape"
  222.      WWW browsers related to defaulting to *not* sending the 
  223.      address information even when it was available in the configuration.
  224.      Since many (most?) people when configuring software will fill in all
  225.      of the requested fields (including name, email address, etc.) it's
  226.      important that the actual sending of the identification information
  227.      be independently controlled through an explicit user decision.
  228.  
  229.         -- MODERATOR ]
  230.  
  231. ------------------------------
  232.  
  233. Date:    Mon, 7 Nov 94 11:03:11 CST
  234. From:    ddb@anubis.network.com (David Dyer-Bennet)
  235. Subject: The dangers of half-hearted privacy measures
  236.      Counterpoint -- Living in a Fish Bowl
  237.  
  238. I'm in favor of privacy.  I'd rather have real privacy than the alternative
  239. I'm going to talk about here.  However, at least in the on-net
  240. privacy-oriented community, I see little or no recognition of the forces
  241. driving the various risks to privacy today.  So I'm writing this to attempt to
  242. expose some issues and options that aren't often seen in this community.
  243.  
  244. The pressures for various sorts of losses of privacy are tremendously strong.
  245. Recorded video monitoring of public spaces probably really does make them
  246. safer; at least it makes it more likely that anybody commiting a violent crime
  247. in that space will be caught and convicted.  Paying for your groceries by
  248. debit card is convenient, and receiving customized coupons for products that
  249. you might actually buy is nice.  Not having to stop at tollbooths on a highway
  250. improves traffic flow, and paying for roads with usage fees moves the costs
  251. squarely onto those deriving the benefits and should help people's rational
  252. personal choices on transportation be less costly to society as a whole.  And,
  253. of course, customized marketing is profitable.  As a consumer, customized
  254. marketing doesn't bother me too much -- what it means to me is that I receive
  255. less uninteresting junk mail. 
  256.  
  257. Most of these things can be implemented without serious privacy impacts with
  258. proper design; the video tapes can be thrown away after a defined period if no
  259. crime is reported, with strict laws about any improper disclosure, for
  260. example.  The tollbooth can work anonymously in various ways.  (The customized
  261. coupons seem to require keeping past purchase history; I find it hard to
  262. imagine a credible scheme to keep that information and use it *only* for
  263. issuing some customized coupons, so perhaps that idea can't be implemented
  264. without compromising privacy.) But all of these approaches involve throwing
  265. away information deliberately.  This is a sin to many people, an unnatural
  266. act.  The incentives for various uses of this information appear strong enough
  267. that the system is likely to develop lots of loopholes and probably illegal
  268. leaks as well.
  269.  
  270. Having essentially all information about me and everybody else be public,
  271. including details of our daily movements, what we read, what we watch, who we
  272. phone, etc. would lead to a very, very different society from what we have
  273. now.  It would largely end the common hypocrisies of day-to-day life, one way
  274. or the other.  Either the avowed standards would remain, and people would
  275. actually conform to them, or new standards would evolve that we'd be willing
  276. to actually live with.  The transition period would be very difficult, of
  277. course.  The first society would be much more restrictive than current
  278. society, but I don't believe it's a likely outcome.  The second might actually
  279. be freer, and also more honest, than what we have now.  People would be forced
  280. to recognize *and accept* the degree of individual differences that actually
  281. exist.  It might be a tolerable outcome.  (This is not what I'd call an
  282. enthusiastic endorsement!)
  283.  
  284. What would be *in*tolerable is a society where that level of information was
  285. available, but *only* to the government and the very rich.  And where the
  286. information on the rich and prominent could often be suppressed, but the
  287. information on those of us with only ordinary resources could not.  This is
  288. the worst possible outcome, and it's one of the more likely dangers.  This is
  289. where we end up with weak laws, compromises, and sloppy attempts at ensuring
  290. privacy.  This is why it's important that society converge on a
  291. strongly-supported position on privacy and pursue it aggressively.  We need to
  292. be either for it, or against it, uniformly and broadly.  
  293.  
  294. Personally, I'm for privacy; I don't want to try the fish-bowl experiment
  295. myself.  But I think that is better than the half-hearted compromises we're
  296. likely to end up with.
  297. -- 
  298. David Dyer-Bennet             Network Systems Corporation
  299. ddb@network.com               Brooklyn Park, MN  +1-612-391-1353
  300. ddb@terrabit.mn.org           My postings represent at most my own opinions.
  301. Web URL: http://www.mtn.org/~ddb  (SF, photography)
  302.  
  303.     [ We've frequently discussed in this forum the rather "insidious"
  304.       nature of the problems you mention.  The convenience of these
  305.       systems makes them difficult to avoid, even when practical
  306.       alternatives to using them exist.  I would argue that 
  307.       only through legislative rules that apply evenly to all
  308.       entities collecting information can the "strong" privacy
  309.       protections you suggest be implemented.  Leaving the decisions
  310.       regarding the use of such data to the collecting entities
  311.       themselves has proven to result in widespread abuse. 
  312.  
  313.       Unfortunately, it seems unlikely that legislation that would help
  314.       the privacy situation in any significant manners will be
  315.       forthcoming anytime soon, at least at the federal level.
  316.       
  317.         -- MODERATOR ]
  318.       
  319. ------------------------------
  320.  
  321.  
  322. Date: 06 Nov 94 15:46:49 EST
  323. From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
  324. Subject: CMU blocks access to nasty newsgroups
  325.  
  326.    [ From RISKS-FORUM Digest; Volume 16 : Issue 53  -- MODERATOR ]
  327.  
  328. >From the United Press Intl newswire via CompuServe's Executive News Service:
  329.  
  330. UPn 11/04 1054 College blocks computer sex access
  331.  
  332.     PITTSBURGH, Nov. 4 (UPI) -- Carnegie Mellon University
  333.     of Pittsburgh said Friday it will block access on its 
  334.     campus computer system to sexually explicit material 
  335.     available on the worldwide computer network called 
  336.     the Internet.
  337.  
  338.     Carnegie Mellon officials said they are acting out of 
  339.     concern that the university could by subject to 
  340.     prosecution under Pennsylvania's pornography and
  341.     obscenity laws.
  342.  
  343. The article goes to to explain that University spokespersons admit they will
  344. be "be accused of stifling free expression" but feel that the risks are too
  345. high, especially since children can easily access these materials.  The
  346. decision was said to have been difficult and painful for the administrators,
  347. who strongly support the tradition of academic freedom.  The decision was
  348. criticized by a student spokesperson, who compared it to banning books.
  349.  
  350. [Comments by MK:
  351.  
  352. The anonymity of the Internet will continue to cause difficult problems
  353. related to access by children.  Right now, the response of well-meaning
  354. administrators and others is to put blanket restrictions on everyone so as
  355. to prevent unsupervised use of the Internet by minors.
  356.  
  357. Imagine a world where no one had developed the concept of an ignition key
  358. for automobiles.  We can imagine well-meaning highway administrators
  359. concerned with access to the high-speed transportation infrastructure
  360. exclaiming, "Gosh, but with these highways and cars, children could travel
  361. to (gasp) brothels and pigsties!  They could see things that their parents
  362. would never want them involved in."  And so the highway administrators would
  363. shut down roads in an attempt to prevent access to bad places by children.
  364.  
  365. In both the real world and this imaginary world, these difficulties are
  366. caused by the lack of identification and authentication in accessing the
  367. highways.  In the real world, we have ignition keys for automobiles and
  368. severe penalties for stealing automobiles or driving without a permit.  We
  369. have no accepted standards for access to networks.
  370.  
  371. Parents who are concerned about access to a network by their children could
  372. take the responsibility of locking their computers or their modems.
  373. However, that's a pretty crude approach too--all or nothing.  And what about
  374. the children's independence and growth?
  375.  
  376. There are already devices available for controlling access to television;
  377. parents program the times, channels and duration of viewing permitted for
  378. their children, who punch in a PIN to gain personally-tailored access to the
  379. TV.  Maybe as Internet access grows, there will arise sufficient interest
  380. and demand for menu systems for access to the Internet.  Parents could
  381. select the sections of the Internet which they wish to allow for their
  382. children; children and parents could explore the Internet together and add
  383. or remove destinations and newsgroups as they see fit.
  384.  
  385. Right now, CompuServe has access to Internet newsgroups.  The administration
  386. has settled on a middle ground in restricting access to the Internet by
  387. limiting the _listings_ of newsgroups.  In fact, however, if someone already
  388. knows the name of a newsgroup, they are free to subscribe even if it isn't
  389. listed.
  390.  
  391. I think that we have to move beyond a crude TOTAL ACCESS / NO ACCESS
  392. dichotomy in regulating access to the Internet.  We need finer granularity
  393. in our restrictions so that we don't infringe on the rights of adults.
  394.  
  395. A final note.  In a recent thread on the NCSA FORUM on CompuServe, there was
  396. a discussion about whether there were mechanisms for restricting BBS and
  397. Internet access by children.  I answered, "Yes--one is PARENTAL
  398. RESPONSIBILITY."]
  399.  
  400. M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn (Carlisle PA)
  401.  
  402. ------------------------------
  403.  
  404. Date: Mon, 31 Oct 1994 18:44:44 -0500 (EST)
  405. From: Steve Holzworth <sch@unx.sas.com>
  406. Subject: followup on Sears captures signatures
  407.  
  408.    [ From RISKS-FORUM Digest; Volume 16 : Issue 53  -- MODERATOR ]
  409.  
  410. Since my original post concerning Sears now digitizing signatures when
  411. you sign a credit card slip, bunches of people :-) have sent me Email,
  412. either asking for elaboration on the risks involved, or adding anecdotes
  413. of their own. I'll attempt to describe the potential risks as I see them.
  414.  
  415. Summary of previous post:
  416.  
  417. Sears in my area has recently started asking for people to sign their 
  418. credit card receipts while the receipts are on what is obviously a small
  419. digitizing pad. Sears doesn't make it obvious that this is the function of
  420. the device. 
  421.  
  422. You can refuse to sign on the tablet. They'll probably have to 
  423. call someone first to OK it.
  424.  
  425. Potential Risks of digitized signatures:
  426.  
  427. Capturing the act of signing gives the store more information than 
  428. simply scanning a copy of a signed receipt would. In addition to the basic
  429. image of the signature, the tablet can also effectively record stroke 
  430. information (direction of strokes, and possibly, pressure of strokes).
  431. This is important, because given stroke information, it is almost trivial
  432. to write a program to fake a signature with a pen plotter. Simply use
  433. the stroke points as control points for spline curves. Said control
  434. points can then be perturbed slightly to yield what appears to be the 
  435. same signature STYLE, without being a direct copy of an existing signature.
  436.  
  437. Of course, Sears wouldn't do anything so stupid. However, once the data is
  438. available, a disgruntled or entrepeneurial employee could sell the data to
  439. other parties. Let's see. Bill Gates goes to Sears and buys a screwdriver on
  440. his credit card. How much is his signature potentially worth on the market?
  441. Or, (for the really paranoid :-) ), some government agency, say, DEA, known
  442. to be overzealous at times, decides to "apply" your signature to some
  443. incriminating evidence...
  444.  
  445. I don't believe Sears (and others mentioned) can perform dynamic signature
  446. verification on the fly. They can't possibly have that horsepower at
  447. the terminal (at present). Even simple credit card number verification
  448. takes 30 seconds or more. Imagine the complexities of looking up one
  449. of N million signatures, correlating it to the new sample, then issuing
  450. a go/no-go response in a reasonable time frame. The closest approximation
  451. to this so far is the Apple Newton handwriting recognition. It looks in
  452. a small (10k words) dictionary, has to be trained to your writing style
  453. over time, and still screws up often enough to cause some headaches.
  454. How tolerant is your customer base to having their charges denied when
  455. they KNOW they wrote a valid signature?
  456.  
  457. More importantly, what REASON can Sears have for wanting this information?
  458. I proposed that they can't do anything useful with it yet, so why should
  459. we let them have it? Further, to the best of my knowledge, no credit card
  460. provider requires card owners to supply digitized signature information
  461. when initiating a transaction. My understanding is that, per the card issuer
  462. agreement with the merchant, the merchant CANNOT require ANY other identifying
  463. information, assuming they get an approval code from the card issuer.
  464. Keep in mind, you don't even SIGN a receipt for a mail-order purchase...
  465. Why should we let Sears et al digitize our signatures?
  466.  
  467. One limited use of a digitized signature could be to display a specimen of 
  468. your signature on POS terminal so the clerk can compare with your receipt.
  469. Of course, that is supposedly what the signature on the back of the card
  470. is for (among other things)...
  471.  
  472. One responder mentioned that if the customer was signing paper on top of a
  473. tablet, it was unlikely that much information could be captured beyond
  474. stylus pressure. This is incorrect. I developed high-end CAD software for
  475. civil engineering and land planning for many years. All of the digitizers we
  476. used were capable of capturing positional information through quite a number
  477. of layers of vellum, mylar, and/or paper. This was necessary because much of
  478. engineering work involves tracing existing maps or drawings.
  479.  
  480. Several responders stated that they had run into similar digitizers at Sears,
  481. Service Merchandise, and others. A few stated that my example of refusing
  482. to sign had encouraged them enough to "just say no" :-) next time.
  483.  
  484. I'm not trying to be paranoid, but I attempt to see all of the angles when
  485. confronted with a situation as described above. I operate under the rule
  486. that unless you can give me an extremely good reason why I should give you
  487. some class of information about me, you don't get it. Numerous posts to
  488. RISKS have documented how quickly and easily information about someone is
  489. disseminated, and how difficult it is to correct misinformation, once it
  490. gets spread. I attempt to minimize acquisition of the information as a
  491. preemptive measure.
  492.  
  493. Steve Holzworth  SAS Institute   x6872  SAS/Macintosh Development Team
  494. Cary, N.C.  sch@unx.sas.com               
  495.  
  496.  
  497. ------------------------------
  498.  
  499. Date: Fri, 4 Nov 1994 15:55:56 -0600 (CST)
  500. From: dfrankow@winternet.com (Daniel Frankowski)
  501. Subject: Minnesota driver license
  502.  
  503.    [ From RISKS-FORUM Digest; Volume 16 : Issue 53  -- MODERATOR ]
  504.  
  505. *City Pages*, a great free news weekly here in the Twin Cities (Minnesota
  506. USA), recently had an article [1] chock full of privacy issues and
  507. implications of the new Minnesota driver license (not "driver's" but
  508. "driver" on our license).  I approached the article with deep suspicions
  509. about a new card, and came away only slightly less suspicious.
  510.  
  511. The old license has been the same for 25 years.  It has a picture, a license
  512. number and some personal information (address, height, weight, signature,
  513. birthdate, etc.).
  514.  
  515.   .. [O]fficials were tired of the ease with which the old card could
  516.   be forged and altered.  In early 1990, local police officials uncovered 
  517.   a forgery ring in the Twin Cities that used fake Minnesota licenses to 
  518.   open bank accounts and pass close to $1 million worth of bad checks.
  519.  
  520. To make it harder to forge, the new card is printed in several fonts and the
  521. location of your (digitized and stored) picture depends on your age.  For
  522. the information age, there is a barcode with your driver license number, and
  523. a magnetic stripe that can contain three lines of about 80 characters each,
  524. currently slated to contain a person's full name, date of birth, and driver
  525. license number.
  526.  
  527. The article raises a plethora of issues, some of which follow.  I have
  528. hastily tried to put them into categories, which unfortunately overlap.
  529.  
  530. INFORMATION HANDLING RISKS
  531.  
  532. - - The state government assumes that the public should trust government
  533. agencies with these technologies.  This resulted in a lack of public
  534. discussion or input because the government did not publicize the new
  535. card proposal.  The article gave an example I had not heard why we
  536. should not trust government: upon dishonorable discharge from the US
  537. military, it assigned a code which potential employers and others
  538. could get.  257 meant "unfitness, homosexual acts," 261 was
  539. "psychiatric or psychoneurotic disorder," 287 was "unclean habits
  540. including venereal disease," and 289 "unsuitability, alcoholism."
  541.  
  542. - - Currently, the Driver Vehicle Services (DVS) department makes all
  543. their information public except social security number and medical
  544. information.  That is, registration and title info, driving records,
  545. and the personal information from your license.  The state sells it
  546. ("provides it for a fee"), and currently has 600 online accounts
  547. (presumably customers buying the information).  They can sort by age,
  548. area, or size of person, for example.
  549.  
  550. - - The card is a universal identifier, a notion often reviled in RISKS.
  551.  
  552. - - The article mentions a national database of 7 million commercial
  553. drivers (only truckers?) called (and operated by) AAMVANET which went
  554. online January 1989.  It contains each person's name, date of birth,
  555. social security number, and physical descriptors.  "It was mandated by
  556. the federal government because truckers were getting licensed in
  557. multiple states to avoid suspensions."  Barry Goleman is the president
  558. of AAMVANET, Inc., a subsidiary of the American Association of Motor
  559. Vehicle Administrators.  "Goleman says that in the future, the system
  560. will include all drivers-- currently a total of 160 million,
  561. nationwide."
  562.  
  563. - - The license may be linked to issues unrelated to driving.  In
  564. Wisconsin, your license may be suspended for failing to pay public
  565. fines.  The article's example is a late book fine at the public
  566. library.
  567.  
  568. RISKS OF SUDDENLY SWITCHING TECHNOLOGIES
  569.  
  570. - - The company producing them (Deluxe Check Corporation, big in
  571. Minnesota) promised quicker turnaround for new licenses, but their
  572. digitizing cameras overheated, and their incompatible transmission
  573. protocols lost about 4000 new pictures which have to be retaken.
  574.  
  575. RISKS OF MAGNETIC STRIPES
  576.  
  577. Goleman (see above) said "upward of" 22 states have magnetic
  578. stripe-reading technology for driver licenses already.
  579.  
  580. - - You, the card holder, cannot easily read the magnetic stripe to
  581. ensure that there are no mistakes because a special machine is
  582. required.
  583.  
  584. - - Businesses could modify credit card readers to read the license
  585. stripe "ostensibly to verify ID" and build databases of shopping
  586. habits and personal information.
  587.  
  588. - - Minnesota businesses are trying to get extra information put on the
  589. magnetic stripe.
  590.  
  591. - - A state group proposed distributing AFDC (welfare) money.  The
  592. article hypothesized the card could be used (say) to track your
  593. location.
  594.  
  595. Comments:
  596.  
  597. At first, I was impressed with the fact that all information in the
  598. barcode and magnetic stripe would also be visible on the card.  In
  599. other words, no hidden information.  However, other points listed
  600. above drained away my relief.
  601.  
  602. I noted a fatalism about the article: it catalogued frightening
  603. consequences without proposing solutions or interviewing privacy
  604. experts.  This seems typical of even good journalism these days.
  605.  
  606. So are there simple guiding principles about the use of information
  607. for a driver license?
  608.  
  609. Would it be a good idea to pass a law requiring cash machines to be
  610. able to display (for free) any information on a magnetic stripe given
  611. the appropriate PIN #?
  612.  
  613. How else can we solve the problems above?
  614.  
  615. 1. Card Blanche, Jennifer Vogel, City Pages, Vol 16, No 725, October
  616. 26, 1994, pages 15-20.
  617.  
  618. Dan Frankowski  dfrankow@winternet.com
  619.  
  620. ------------------------------
  621.  
  622. Date:    Thu, 10 Nov 1994 04:06:13 -0500 (EST)
  623. From:    dgh@BIX.com
  624. Subject: Discover Card "Fraud" Mailing update
  625.  
  626. Discover card did not do a bulk class mailing of their "Fraud Prevention"
  627. information notices.  They were included with the monthly bill.  I don't
  628. think that anybody in their right mind is going to toss out their monthly
  629. Discover Card bill, unopened...
  630.  
  631.     [ It appears that Discover card customers who were mailed regular
  632.       statements recently had the "fraud prevention" notice/request
  633.       included with their statement.  However, bulk class mailings did
  634.       go out to subscribers who were not due statements, presumably
  635.       including people with a Discover card who did not have any current
  636.       card activity, which could be a very large number of folks.
  637.  
  638.         -- MODERATOR ]
  639.  
  640. ------------------------------
  641.  
  642. Date:    Sat, 12 Nov 1994 13:56:25 -0500
  643. From:    David Banisar <banisar@epic.org>
  644. Subject: Ohio Supreme Court Upholds Privacy of SSNs
  645.  
  646. In a decision handed down on October 26, the Ohio Supreme Court has
  647. ruled that governmental disclosure of Social Security numbers (SSNs)
  648. violates individuals' constitutional right to privacy.  At issue was a
  649. request by the Akron Beacon Journal for release of computer tape
  650. records of the City of Akron's year-end employee master files.  The
  651. payroll files contain various information including employees' names,
  652. addresses, telephone numbers, SSNs, birth dates, education, employment
  653. status and positions, pay rates, service ratings, annual and sick
  654. leave information, overtime hours and pay, and year-to-date employee
  655. earnings.  The City had provided the records to the newspaper, but
  656. deleted the SSNs on privacy grounds.
  657.  
  658. EPIC staff, on behalf of Computer Professionals for Social
  659. Responsibility, joined with the Public Citizen Litigation Group in
  660. filing a "friend of the court" brief in the case.  The CPSR/Public
  661. Citizen brief highlighted the privacy implications of SSN disclosures
  662. and argued in support of the City's decision to withhold the numbers.
  663. The brief urged the Ohio Supreme Court to follow the lead of the U.S.
  664. Court of Appeals for the Fourth Circuit in the case of Greidinger v.
  665. Davis, where Virginia's practice of requiring SSNs for voter
  666. registration purposes was held unconstitutional.  EPIC staff had
  667. similarly participated in the Greidinger litigation as friends of the
  668. court.
  669.  
  670. Significant excerpts from the Ohio Supreme Court decision:
  671.  
  672.           The city's refusal to release its employees' SSNs does
  673.      not significantly interfere with the public's right to
  674.      monitor governmental conduct. The numbers by themselves
  675.      reveal little information about the city's employees. ...
  676.  
  677.           While the release of all city employees' SSNs would
  678.      provide inquirers with little useful information about the
  679.      organization of their government, the release of the numbers
  680.      could allow an inquirer to discover the intimate, personal
  681.      details of each city employee's life, which are completely
  682.      irrelevant to the operations of government. As the Greidinger
  683.      court warned, a person's SSN is a device which can quickly be
  684.      used by the unscrupulous to acquire a tremendous amount of
  685.      information about a person. ...
  686.  
  687.          Thanks to the abundance of data bases in the private
  688.      sector that include the SSNs of persons listed in their
  689.      files, an intruder using an SSN can quietly discover the
  690.      intimate details of a victim's personal life without the
  691.      victim ever knowing of the intrusion.
  692.  
  693. Coming a year after the Greidinger decision, the Akron Beacon Journal
  694. case continues a trend toward judicial recognition of the privacy
  695. implications of SSNs.  EPIC will continue to participate in related
  696. litigation in an attempt to establish a body of caselaw protecting the
  697. confidentiality of SSNs and other personal information.
  698.  
  699. David Sobel (Sobel@epic.org)
  700. Legal Counsel
  701. Electronic Privacy Information Center
  702.  
  703. ------------------------------
  704.  
  705. End of PRIVACY Forum Digest 03.22
  706. ************************
  707.