home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / phreak / sysinfo / risks_cn.txt < prev    next >
Encoding:
INI File  |  2003-06-11  |  12.2 KB  |  261 lines

  1. [From RISKS DIGEST 16.50]
  2.  
  3.  
  4. Date: Tue, 25 Oct 94 18:01:25 PDT
  5.  
  6. RISKS-LIST: RISKS-FORUM Digest  Tuesday 25 October 1994  Volume 16 : Issue 50
  7.  
  8. ----------------------------------------------------------------------
  9.  
  10. Date: Fri, 21 Oct 94 20:46 PDT
  11. From: lauren@vortex.com (Lauren Weinstein)
  12. Subject: CNID (numbers vs. names)
  13.  
  14. The assertion has been made that perhaps calling number ID would be more
  15. acceptable if something other than numbers were sent.  In fact, that is
  16. already part of the CNID spec (calling name delivery), though it is not
  17. implemented in all CNID systems.  In most implementations I've seen *both*
  18. name and number are delivered--which rather kills the idea of delivering "who
  19. is calling" info rather than "where are they calling from" info.
  20.  
  21. There isn't much enthusiasm among the commercial end-users for name-only
  22. delivery.  The reason is obvious--you can't collect phone numbers for return
  23. sales calls when you're just handed a name.  While the telcos have touted CNID
  24. as being for individuals, the real focus has always been on commercial use as
  25. the real money maker.
  26.  
  27. At this point, the CNID controversy boils down to the seemingly simple
  28. question, "Since it is mandated that everyone must have per-call blocking
  29. available, why can't per-line blocking be made available?"  Once again, I
  30. think the reason is obvious.  Most people aren't on PBX systems that are
  31. easily programmed to dial the three digit blocking code on each call, nor will
  32. most people want to spend money for add-on gadgets to do this.  So the hope of
  33. the telcos is that most people will forget or won't bother to use the per-call
  34. code most of the time.  If per-line blocking were available (and surveys show
  35. most subscribers would want it--people want to know who's calling, but don't
  36. want other people to always know *their* number!) then CNID's commercial value
  37. would be significantly lowered.
  38.  
  39. --Lauren--
  40.  
  41. ------------------------------
  42.  
  43. Date: 22 Oct 1994 02:44:36 -0400
  44. From: mds@access.digex.net (Michael D. Sullivan)
  45. Subject: Re: CNID (Preece, RISKS-16.47, Klossner, RISKS-16.48)
  46.  
  47. Andrew Klossner objects to the proposal to assign each phone a second unique
  48. number solely for CNID; This would be accessible only through an 800 number.
  49. Klossner claims this would be impractical because "Almost all area codes in
  50. North America are more than half populated. In order to double the number of
  51. phone numbers, most area codes would have to be split."  This does not present
  52. a major obstacle, however.  The pseudo-number would not have to be a valid
  53. phone number.  [This was also pointed out in a subsequent message by Scott
  54. Preece himself.  PGN]  Such a number could fit within the existing CNID
  55. transmission system if it utilized the same number of digits as a valid US
  56. number (10 digits), but there are no valid 10-digit numbers beginning with 0
  57. or 1 (20% of the numberspace), no valid 10-digit numbers with 0 or 1 as the
  58. fourth digit (20% of the numberspace, overlooking overlap with the foregoing),
  59. no valid 10-digit numbers with 11 as the second and third digits (reserved for
  60. 911, 411, and other service codes) (1% of the numberspace), no valid numbers
  61. with 11 as the fifth and sixth digits (same reason) (1% of the numberspace),
  62. no valid numbers with 00 as the fifth and sixth digits (to avoid confusion
  63. with 800, 900, etc.) (1%), no valid numbers with 200, 300, 400, or 600 as the
  64. leading digits, etc.  Over 40% of the numberspace is reserved, and the
  65. remaining 60% is far from fully occupied -- only recently have a handful of
  66. area codes with 0 or 1 in the middle been assigned (20% of the numberspace
  67. remains relatively vacant), and likewise phone numbers with a 1 or 0 as the
  68. fifth digit (i.e., in the middle of the NXX "exchange" group) have been
  69. assigned only in major urban areas.  It is very unlikely that anywhere near
  70. 50% of the numberspace is actually assigned -- keep in mind that there are 10
  71. billion unique numbers available in a ten digit numberspace.
  72.  
  73. Clearly, then, it would be technically possible for the foreseeable future to
  74. assign each telephone number in the North American Numbering Plan a unique
  75. second number.  This number would not be usable as a telephone number, but it
  76. would only work through an "800" number, which would decode it.
  77.  
  78. Moreover, there is no reason why such a non-dialable number should be uniquely
  79. assigned to each number.  The telephone companies could use the non-dialable
  80. subset of 10-digit numbers as a pool of codes for one-time use in each area
  81. code.  The real dialable number is actually transmitted between central
  82. offices, but is not transmitted to the end user.  If the "privacy" bit is
  83. toggled on, the central office could store the real number and transmit a
  84. non-dialable number from a one-time pad, and it would only be mapped to the
  85. real number for a limited time, such as 48 hours, if keyed into the "800"
  86. number associated with the same telephone company and dialed from the number
  87. that was called (i.e., from the phone that received the non-dialable number).
  88. There is no reason for a permanent association between the non-dialable number
  89. and the real number; in fact, that would defeat the purpose of CNID and
  90. unpublished numbers.  Calling the pseudonumber, through the 800 gateway, would
  91. be a one-time deal.  There's no major technical obstacle to that.
  92.  
  93. Michael D. Sullivan | INTERNET E-MAIL TO:  |also: avogadro@well.sf.ca.us | 
  94. Washington, D.C.    | mds@access.digex.net |   74160.1134@compuserve.com |
  95.  
  96.    [Various astute messages from 
  97.       keener@upenn5.hep.upenn.edu (Paul T. Keener),
  98.       "john (j.m.) clarke" <jclarke@bnr.ca>, 
  99.       George Swan <gswan@io.org>, 
  100.    and others tend to make similar observations, and are omitted.  Please
  101.    forgive me if I have oversimplified the points made by the omitted plethora
  102.    of messages.  I think you would all be overwhelmed if I included
  103.    everything.  PGN]
  104.  
  105. ------------------------------
  106.  
  107. Date: Sun, 23 Oct 1994 13:18:42 +0000 (GMT)
  108. From: Tim Duncan <timd@edinburgh.ac.uk>
  109. Subject: Re: CNID and Don Norman -- CNID can be private (Wells, RISKS-16.48)
  110.  
  111. |> [Don Norman] suggests that other information should be sent instead of a
  112. |> telephone number. ...
  113.  
  114. This is currently being tested by British Telecom in Edinburgh.  Subscribers
  115. have been given the option of submitting their own identifying string (16
  116. characters) instead of the default which is their name as it appears in the
  117. phone book.
  118.  
  119. Tim Duncan, AI Applications Institute, Univ. of Edinburgh, 80 South Bridge, 
  120. Edinburgh EH1 1HN, Scotland, UK  Tel: +44 31 650 2747  Email: timd@ed.ac.uk
  121.  
  122. ------------------------------
  123.  
  124. Date: Tue, 25 Oct 1994 09:26:24 +0000 (GMT)
  125. From: "B.M. Cook"  <barry@cs.keele.ac.uk>
  126. Subject: Calling Number ID - in the UK
  127.  
  128. We're about to get calling number ID in the UK, too - from British
  129. Telecommunication (BT) at least.  It is being promoted on the benefits to the
  130. subscriber, e.g. "This service has already been available in North America for
  131. some time, where it has had a major impact on malicious and fraudulent
  132. calls.".
  133.  
  134. The fact that lines for which information has been previously withheld
  135. (ex-directory numbers) will send information is hard to spot in the
  136. literature!
  137.  
  138. The features listed in DIGEST 16.46 appear to have implemented, but not well
  139. publicised - I get the distinct feeling that the service will be of most
  140. benefit to companies who want to create lists of 'phone numbers!
  141.  
  142. We will be getting -
  143. 1. Per-line blocking - FOC, just call and ask for it.
  144. 2. Per-line unblocking - the default unless you change it.
  145. 3. Per-call blocking - dial 141 before the number you want.
  146. 4. Per-call unblocking - dial 1470 before the number you want.
  147.  
  148. 1. and 2. need a phone call but it costs nothing.
  149. 3. is advertised in the literature.
  150.  
  151. BUT 4. took some discovering!  I want to block outgoing ID by default and
  152. allow it only on certain calls (e.g. friends, certainly not businesses who
  153. will record it, sell the lists etc.) so per-line blocking with per-call
  154. unblocking is the answer.
  155.  
  156. This option is not mentioned in the literature, I phoned the further
  157. information freefone number to be told that what I wanted is not possible.
  158. Rather than give up here, as I guess most people would, I asked them to record
  159. my requirement so that if enough other people also wanted it they might think
  160. about providing it.  They said they'd get someone to call me back which they
  161. did the next day.  A very pleasant call from Edinburgh from someone who knew
  162. rather more about the system (it had been on trial in Scotland before being
  163. introduced elsewhere).  No problem, he said, we already have what you require,
  164. just have the line blocked and put 1470 in front of calls you want to unblock -
  165. I'll put the line block on for you. The next day we had confirmation, by mail,
  166. that it had been done.
  167.  
  168. So, it looks as though we will be getting a decent service (it goes live on
  169. November 5th) - but only if you know what you want and work a little to get
  170. the information!
  171.  
  172. ------------------------------
  173.  
  174. Date: 24 Oct 1994 05:05:25 GMT
  175. From: jet@abulafia.genmagic.com (J. Eric Townsend)
  176. Subject: Bypassing CNID in an emergency
  177.  
  178. I see a big RISK in "ignore all phone numbers I don't recognize".  At least
  179. once every 6 - 12 months, I get an emergency call at my house from a friend or
  180. family member.  The call usually comes from a pay phone, but has originated at
  181. a business or a residential line as well.
  182.  
  183. By blocking "unknown numbers", I would have missed calls with the following
  184. content in the past year.
  185.  
  186. - "best friend severly injured in a vehicle accident, come immediately"
  187.  
  188. - "we broke down coming back from a late nite concert, it's 0230 and
  189.    we're stuck in the middle of a really bad section of town with no
  190.    transportation.  can you come get us?"
  191.  
  192. - "my flight was canceled, so I caught one that arrives 3 hours earlier
  193.    and at a different airport.  come get me before I'm bored to death!"
  194.  
  195. And, most importantly to *me*:
  196.  
  197. - "Hi, I just got your resume from a friend of yours, and we'd like
  198. you to come in for an interview."
  199.  
  200. I ended up getting a great job from that one...
  201.  
  202. I don't see what is signifcantly gained by CNID that isn't gained by
  203. using an answering machine to screen calls.  I do see what can be lost
  204. by ignoring calls from numbers one does not recognize, however.
  205.  
  206. J. Eric Townsend jet@genmagic.com  USA 415.335.7463 aka jet@well.sf.ca.us 
  207. work: jet@genmagic.com      AT&T PersonaLink: A5803643645@attpls.net
  208.  
  209. ------------------------------
  210.  
  211. Date: Mon, 24 Oct 94 10:45 GMT
  212. From: jampel@cs.city.ac.uk (Michael Jampel)
  213. Subject: Caller Number Identification in the UK
  214.  
  215. British Telecom is starting a CNID (Caller Number Identification) in the UK.
  216. If you do nothing, your number will be sent out every time you make a call.
  217. But if you dial 1471 (I think -- anyway, some 4 digit code) before dialling
  218. the number you want to call, then your number will not be sent out.
  219.  
  220. Or you can ask for your number _never_ to be sent out. But in this case it is
  221. _not_ possible to dial, say, 1472 to have your number sent out occasionally.
  222.  
  223. So if you don't particularly want to tell life insurance companies your phone
  224. number, and if you don't trust yourself not to forget to dial 1741
  225. double-bucky, you are put in the situation where you can never send out your
  226. number, which will usually not matter, until the day that it does matter.
  227.  
  228. I feel that BT are not serving the needs of their domestic customers here:
  229. CNID is great if someone you know is getting dirty phone calls, but otherwise
  230. its main function is to benefit commercial customers. But there is nothing we
  231. can do about it.
  232.  
  233. Michael Jampel
  234.  
  235. ------------------------------
  236.  
  237. Date: Mon, 24 Oct 1994 09:03:41 +0800
  238. From: stalzer@macaw.hrl.hac.com
  239. Subject: Re: CNID and Don Norman -- CNID can be private
  240.  
  241. It would not take the database miners of the world long to build a cross
  242. reference between user selected call number ids and the real phone numbers.
  243. To keep off the list, you would have to never let a company associate your
  244. real phone number with your id. This would be hard to do if you use credit
  245. cards, mail order outfits, etc.  Also, given the penchant for phone companies
  246. to charge a few bucks for every trivial service change, like changing an id,
  247. the cross reference would tend to remain up to date.
  248.  
  249. Although, I should add that if people conspire to choose the same id,
  250. like PRIVACY, we can give the marketers a real headache.
  251.  
  252.   -- Mark
  253.  
  254. ------------------------------
  255.  
  256. End of RISKS-FORUM Digest 16.50 
  257. ************************
  258.  
  259. END-----------------cut here------------------
  260.  
  261.