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

  1. PRIVACY Forum Digest      Wednesday, 9 September 1992      Volume 01 : Issue 16
  2.  
  3.          Moderated by Lauren Weinstein (lauren@cv.vortex.com)
  4.                 Vortex Technology, Topanga, 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.     Re: Wells Fargo Bank changes customer security system (Bob Leone)
  14.     Re: Wells Fargo Bank changes customer security system (Randy Gellens)
  15.     Re: Vernam Cipher (Bob Leone)
  16.         Re: Vernam Cipher & Privacy (Willis H. Ware)
  17.     Re: Vernam Cipher (Tom Ohlendorf)
  18.     Transferring ownership of private data (Larry Seiler)
  19.     Usenet privacy? (Jim H.)
  20.     Re: Usenet privacy? (Brian Reid)
  21.  
  22.  
  23.  *** Please include a RELEVANT "Subject:" line on all submissions! ***
  24.             *** Submissions without them may be ignored! ***
  25.  
  26. -----------------------------------------------------------------------------
  27. The PRIVACY Forum is a moderated digest for the discussion and analysis of
  28. issues relating to the general topic of privacy (both personal and
  29. collective) in the "information age" of the 1990's and beyond.  The
  30. moderator will choose submissions for inclusion based on their relevance and
  31. content.  Submissions will not be routinely acknowledged.
  32.  
  33. ALL submissions should be addressed to "privacy@cv.vortex.com" and must have
  34. RELEVANT "Subject:" lines.  Submissions without appropriate and relevant
  35. "Subject:" lines may be ignored.  Subscriptions are by an automatic
  36. "listserv" system; for subscription information, please send a message
  37. consisting of the word "help" (quotes not included) in the BODY of a message
  38. to: "privacy-request@cv.vortex.com".  Mailing list problems should be
  39. reported to "list-maint@cv.vortex.com".  All submissions included in this
  40. digest represent the views of the individual authors and all submissions
  41. will be considered to be distributable without limitations. 
  42.  
  43. The PRIVACY Forum archive, including all issues of the digest and all
  44. related materials, is available via anonymous FTP from site "cv.vortex.com",
  45. in the "/privacy" directory.  Use the FTP login "ftp" or "anonymous", and
  46. enter your e-mail address as the password.  The typical "README" and "INDEX"
  47. files are available to guide you through the files available for FTP
  48. access.  PRIVACY Forum materials may also be obtained automatically via
  49. e-mail through the listserv system.  Please follow the instructions above
  50. for getting the listserv "help" information, which includes details
  51. regarding the "index" and "get" listserv commands, which are used to access
  52. the PRIVACY Forum archive.
  53.  
  54. For information regarding the availability of this digest via FAX, please
  55. send an inquiry to privacy-fax@cv.vortex.com, call (310) 455-9300, or FAX
  56. to (310) 455-2364.
  57. -----------------------------------------------------------------------------
  58.  
  59. VOLUME 01, ISSUE 16
  60.  
  61.     Quote for the day:
  62.  
  63.        "I don't want a pickle--just want to ride on my motor-sicle."
  64.  
  65.                     -- "The Motorcycle Song"
  66.                            Arlo Guthrie
  67.  
  68. ----------------------------------------------------------------------
  69.  
  70. Date:    Sun, 6 Sep 1992 23:51:17 -0400
  71. From:    Bob Leone <leone@gandalf.ssw.com>
  72. Subject: Re: Wells Fargo Bank changes customer security system
  73.  
  74. >    [ Yes, I know that such automated systems are now becoming widely
  75. >      available.  However, the question for this Forum is, *should* such
  76. >      information be freely accessible, without any controls by the
  77. >      customer, no recording of who is requesting the information, and no
  78. >      notification to the customer that their account information is
  79. >      being queried?  Also, does the widespread move from "manual" to
  80. >      "automated" systems for dispensing this information possibly
  81. >      encourage abuse through easier repetitive access? -- MODERATOR ]
  82.  
  83. There is a potential technological "fix" for this: the caller-id feature
  84. that phone companies are starting to offer. This feature becomes especially
  85. easy to work with under ISDN. (Caller-id supplies the phone number of the
  86. caller to the callee).
  87.  
  88. All a bank would have to do is:
  89.    1) Record the caller-id of all incoming account-balance-request calls
  90.       in an audit-trail log.
  91.    2) If this incoming caller
  92.     A) has queried the same account more than once on this current day, or
  93.         B) is using caller-id-blocking (something that a legitimate merchant
  94.        would not do), or
  95.         C) is calling from a pay-phone (which can be determined from the
  96.        first three digits of the incoming phone number),
  97.       then reject the call and log a message in the "security violation" log.
  98.  
  99. Of course, for banks to go through the extra effort, they have to have a 
  100. reason. A few lawsuits and newspaper articles resulting from criminals
  101. misusing the bank's system should do nicely.
  102.  
  103. Bob Leone
  104.  
  105.     [ Any kind of serious reliance on caller-id would probably be
  106.       impractical for this purpose.  For a variety of well-founded
  107.       reasons (well discussed in previous issues of this digest) a range
  108.       of restrictions on caller-id are being imposed in many areas; some
  109.       areas may not be supporting it at all.  Also, tracking of merchant
  110.       calling numbers for this application may do little good, since you
  111.       might find calls from any number of lines randomly selected by the
  112.       normal trunking functions of most PBX systems. 
  113.  
  114.       More importantly, such a procedure does not give the bank customer
  115.       any say over who has access to the information regarding their
  116.       account status, and on what basis.  Ideally, the customer would be
  117.       able to specify that a particular query from a particular entity
  118.       would be permitted when they were writing a large check or
  119.       applying for credit, but perhaps "random" queries would be
  120.       rejected since they would not be so authorized.  
  121.  
  122.       The key, of course, as noted by Bob above, is that if the
  123.       institutions involved don't think it worth their while to
  124.       provide such controls they won't bother doing so. -- MODERATOR ]
  125.  
  126. ------------------------------
  127.  
  128. Date:    08 SEP 92 06:12   
  129. From:    <MPA15AB!RANDY@TRENGA.tredydev.unisys.com>
  130. Subject: Re: Wells Fargo Bank changes customer security system
  131.  
  132. >[ Yes, I know that such automated systems are now becoming widely
  133. >  available.  However, the question for this Forum is, *should* such
  134. >  information be freely accessible, without any controls by the
  135. >  customer, no recording of who is requesting the information, and no
  136. >  notification to the customer that their account information is
  137. >  being queried?  Also, does the widespread move from "manual" to
  138. >  "automated" systems for dispensing this information possibly
  139. >  encourage abuse through easier repetitive access? -- MODERATOR ]
  140.  
  141. This comment from our moderator got me thinking about how I've come to accept
  142. automated privacy risks as just another aspect of our society which I prefer
  143. were different, but don't have any control over.
  144.  
  145. What would it take to change our institutions so that technological advances
  146. were used to help people retain more privacy, instead of causing us to have
  147. less?  I know TRW offers (for a fee) to notify me when they give out my credit
  148. report.  I like the idea of being told this, but dislike the concept that I
  149. must pay for the privilege, as it reinforces that TRW, not I, own the
  150. information.
  151.  
  152. Several nearby supermarkets offer to let me pay for purchases through a debit
  153. card.  Of these, Lucky uses a common system to ring up items and process the
  154. debit, producing one receipt and of course linking my choices with my identity.
  155. Another store, Alpha Beta (owned by the same company), has two different
  156. systems, producing two receipts, and the hope that the databases aren't linked.
  157. A third, Vons, does not perform an electronic debit, but rather an electronic
  158. check (which takes several days to clear, unlike the debits).  None of the
  159. stores make any mention of the privacy aspects.  If one of them were to tout
  160. their system as offering both convenience and privacy, would they do more
  161. business?  Is the profit motive enough to get change?  Or are laws needed, and
  162. if so, are they likely to be passed?  I see increasing evidence that given a
  163. choice, people prefer the promise of safety or convienence over privacy.
  164.  
  165.   =====================================================================
  166.   = sua cuique voluptas              (everyone has his own pleasures) =
  167.   = Randy Gellens            randy%mpa15ab@trenga.tredydev.unisys.com =
  168.  
  169. ------------------------------
  170.  
  171. Date:    Sun, 6 Sep 1992 23:58:28 -0400
  172. From:    Bob Leone <leone@gandalf.ssw.com>
  173. Subject: Re: Vernam Cipher
  174.  
  175. >If an inexpensive and quite secure method of encryption were
  176. >available to all, would not use of end-to-end encryption go some
  177. >distance toward solving the privacy problem ?
  178. >
  179. >This would not be a popular idea with law enforcement agencies,
  180. >the NSA, and other spooks. Aside from obvious objections from
  181. >this quarter, are there any good arguments against general
  182. >availability of such an encryption method ?
  183.  
  184. The immediate rationale for govt opposing this is "But drug dealers
  185. will use it to prevent police monitoring of their conversations.
  186. Therefore, in the name of the War on Drugs (all salute, now), this
  187. must be prohibited"
  188.  
  189. My response would be "If the War on Drugs (alias 'Prohibition, the Sequel')
  190. requires regular people to give up their privacy and civil rights, then
  191. maybe we should just cancel the War, as we did with Prohibition in 1933."
  192.  
  193. Bob Leone
  194.  
  195. ------------------------------
  196.  
  197. Date:    Tue, 08 Sep 92 10:37:25 PDT
  198. From:    "Willis H. Ware" <willis@iris.rand.org>
  199. Subject: Re: PRIVACY Forum Digest V01 #15: Vernam Cipher & Privacy
  200.  
  201. Art Zimmerman --  GlasNet <glasnost@igc.apc.org> -- asks:
  202. >> ..............would not use of end-to-end encryption go some distance
  203. >> toward solving the privacy problem ?
  204.  
  205. The answer depends on what you mean by "some distance." E2E encryption
  206. would handle any problems which are related to intercept of traffic while
  207. in transit over communications systems.  In a precise sense, such an event
  208. is not a privacy issue but a communications security one resulting in a
  209. breach of confidentiality -- which the in-transit message presumably
  210. enjoys.  For example, intercept of the Royal Family's cellular telephone
  211. conversations is not a privacy infraction, but rather an intrusion on the
  212. confidentiality of the connection.  Usage is careless, however, and
  213. privacy is often loosely used as an inappropriate synonym for either
  214. security or confidentiality.
  215.  
  216. Aside from that, interception of communications is of unknown magnitude.
  217. There is anecdotal evidence of such things, and the presence of scanners
  218. and much other contemporary consumer electronics leads to speculation that
  219. comms interception is widespread.  The US of course did pass a law
  220. protecting specifically the bands used by cellular phones; it is illegal
  221. to listen in on such connections since it is considered an extension of
  222. the Wiretap Act.  Surprisingly, cordless connections have no protection.
  223. Put a cordless fone in your car and connect the car by cellular; part of
  224. the circuit is legally protected; part, not.  I have never seen hard data
  225. on the amount of such intercepts.  Thus, one doesn't know whether E2EE
  226. addresses a big problem or a small one.  People engaged in illegal actions
  227. of course go to some lengths even now to avoid interception by law
  228. enforcement agencies.
  229.  
  230. The <<big>> issue in privacy is the collateral or unauthorized use of
  231. information about people.  It's the old story: collect information for
  232. one purpose and usually legitimately; then use it for anything else the
  233. recordkeeper can think of -- combine it with other data, sell it,
  234. target mail with it.
  235.  
  236. Typically exploitation of personal information is by 3rd parties who have
  237. either acquired it legitimately from public records, from list sellers,
  238. from database sellers, or as a result of being in business; e.g., video
  239. rental records, the sale of driver license records by the California DMV.
  240. E2EE does nothing of course for this major component of [true] privacy.
  241. Infractions of privacy such as the ACLU or CPSR worry about is of growing
  242. magnitude and almost certainly dwarfs any other use of information about
  243. people that one can imagine.
  244.  
  245. Privacy is a long and involved topic.  We'll save the tutorial for another
  246. time.
  247.                         Willis H. Ware
  248.                         Santa Monica, CA
  249.  
  250.         [ While there are no federal laws regarding cordless
  251.           phone interception, there are apparently some state
  252.           laws that apply, including a recent one here in 
  253.           California, I believe. -- MODERATOR ]
  254.  
  255. ------------------------------
  256.  
  257. Date:    Wed, 9 Sep 1992 09:19 EDT
  258. From:    "Tom Ohlendorf - TSU Admin. DP, (410) 830-3642"
  259.      <D7AP002@TOA.TOWSON.ED
  260. Subject: Re: Vernam Cipher
  261.  
  262. > Date:    Sun, 30 Aug 92 17:00:47 PDT
  263. > From:    GlasNet <glasnost@igc.apc.org>
  264. > Subject: Vernam Cipher
  265. > There is a well-known cryptographic technique - the Vernam
  266. > Cipher, also known as the one-time pad - which is secure against
  267. > any known form of decryption attack.  The problem with this
  268. > technique has always been in key distribution; an amount of key
  269. > equal to that of the plaintext is required.
  270. >
  271. [additional quoted text removed by moderator]
  272.  
  273. I would be very interested in applying this variant of the Vernam Cipher. 
  274.  
  275. There are many instances where I can find it to be useful. For example, I am
  276. involved with an organization in my area that runs several client based service
  277. programs. I and others have set up a network which includes an infrared data
  278. link to a building nextdoor and a dedicated landline data link to another
  279. building several miles away. Most of the data travelling along these links
  280. reference clients of the respective programs (client privacy). If I could
  281. encrypt this data using the metjod described above, it would be quite useful.
  282.  
  283. Many thanks, 
  284. Tom
  285.  
  286. -----
  287. Tom Ohlendorf, Programmer/Analyst
  288. INTERNET: D7AP002@TOA.TOWSON.EDU
  289.  
  290. ------------------------------
  291.  
  292. Date:    Mon, 7 Sep 92 18:37:54 EDT
  293. From:    "LARRY SEILER, DTN225-4077, HL2-1/J12  07-Sep-1992 1815" 
  294.      <seiler@rgb.enet.dec.com>
  295. Subject: Transferring ownership of private data
  296.  
  297. In digest V01 #15, Larry Hunter says that selling a defunct video store's
  298. customer/rental list is within the law because the "ordinary course of
  299. business" is defined to include "transfer of ownership".  Certainly if a
  300. video business is sold, the customer records should go with it.
  301.  
  302. However, the case here is a defunct business whose assets were being
  303. sold off.  Can "transfer of ownership" really be defined to mean parts
  304. of a defunct business?  If so, I suppose any video business, defunct or
  305. not, could sell its rental records and call it "transfer of ownership".
  306.  
  307. To me, the thing wrong with this picture is permitting businesses to
  308. treat records of private information (whatever one puts in that category) 
  309. as a marketable asset.  I've heard defenses of the practice as being
  310. necessary for effective business.  However, the phone companies do not 
  311. (I hope!) market their billing records of the numbers we call, and neither 
  312. do I think that any other sales data (whether video rentals, groceries, or 
  313. loans) should be marketed without explicit permission from the consumer.
  314.  
  315.     Larry Seiler
  316.  
  317. ------------------------------
  318.  
  319. Date:    Wed, 09 Sep 92 11:49:40 -0700
  320. From:    horning@src.dec.com
  321. Subject: Usenet privacy?
  322.  
  323. One of the newsgroups I subscribe to is news.lists, on which a variety 
  324. of sources periodically post a number of interesting analyses of 
  325. usenet traffic, such as USENET FLOW ANALYSIS REPORT, Top 25 News Submitters 
  326. by User by Kbytes, Changes to List of Periodic Informational Postings, 
  327. etc.
  328.  
  329. None of the current postings seems to be an objectionable invasion 
  330. of privacy.  However, it seems that the analysis techniques used 
  331. for some of them could easily be refined to collect (and presumably 
  332. sell) detailed information about individual usenet users of a kind 
  333. that readers of this forum would probably consider abusive if it 
  334. were done by a telephone company, video store, or department of motor 
  335. vehicles. 
  336.  
  337. I'd be interested to know what safeguards (other than the restraint 
  338. of those doing the analysis) and/or guidelines there are for such 
  339. activity.  Is it assumed that usenet users realize there is no right 
  340. to e-privacy? 
  341.  
  342. Jim H.
  343.  
  344. ------------------------------
  345.  
  346. Date:    Wed, 09 Sep 92 12:00:08 PDT
  347. From:    Brian Reid <reid@pa.dec.com>
  348. Subject: Re: Usenet privacy? 
  349.  
  350. I do the USENET flow analysis and USENET readership analysis. Both of
  351. them have the potential for harming the privacy of individuals if
  352. mis-used.
  353.  
  354. My safeguards are as follows: 
  355.  
  356.     * The raw data-gathering software strips the identity of
  357.       individuals; I ensure that before the data ever reaches me all
  358.       specific identifying information has been removed. I have no
  359.       control over the system administrators who produce this data, but
  360.       I don't want there to be stored on my system, even for one second,
  361.       information that would let me learn about the reading habits of
  362.       individuals.
  363.  
  364.     * All data are kept private. I do not release raw data to anyone.
  365.       It would be possible to write programs that analyzed flow data and
  366.       readership data that could impute a lot about the identity of
  367.       individuals.
  368.  
  369.     * All reports that I produce are aggregated over a geographically-
  370.       defined population. I will not produce custom reports for anyone,
  371.       and I will not perform an analysis of any subset that is defined
  372.       by any factor other than geography.
  373.  
  374. I rely on my own judgment for deciding which reports could potentially
  375. violate privacy. There is an interesting duality here: there is privacy
  376. to be had from summaries, but there is also a threat from aggregation.
  377. If I tell you that the summary of data from 100,000 people shows
  378. certain trends, that is potentially interesting. However, the knowledge
  379. that I have data about 100,000 people is potentially dangerous. This is
  380. the reason why I ensure that I do not have the opportunity to store
  381. data about individuals: if I kept it and relied on the security of my
  382. own computer system, then somebody with a search warrant could force me
  383. to divulge it. By making sure that it never gets here I can make sure
  384. that it cannot be released to law enforcement.
  385.  
  386. ------------------------------
  387.  
  388. End of PRIVACY Forum Digest 01.16
  389. ************************
  390.