home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / mac / misc / 13707 < prev    next >
Encoding:
Text File  |  1992-07-23  |  2.1 KB  |  45 lines
  1. Newsgroups: comp.sys.mac.misc
  2. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!quads!jcav
  3. From: jcav@quads.uchicago.edu (JohnC)
  4. Subject: Re: a non-techie view of Newton
  5. Message-ID: <1992Jul24.000435.16476@midway.uchicago.edu>
  6. Sender: news@uchinews.uchicago.edu (News System)
  7. Reply-To: jcav@midway.uchicago.edu
  8. Organization: The Royal Society for Putting Things on Top of Other Things
  9. References: <0105011F.978hg5@dragon.enigami.mv.com> <7889@dirac.physics.purdue.edu>
  10. Date: Fri, 24 Jul 1992 00:04:35 GMT
  11. Lines: 32
  12.  
  13. In article <7889@dirac.physics.purdue.edu> sho@gibbs.physics.purdue.edu (Sho Kuwamoto) writes:
  14. >In article <0105011F.978hg5@dragon.enigami.mv.com> cory@enigami.mv.com writes:
  15. >>>                          And what exactly is the
  16. >>>point of having the signatures stored electronically,
  17. >>>anyway?
  18. >>
  19. >>Imagine tracing a package: from the terminal, the operator could pop-up
  20. >>the signature -- the day after it was signed.  The signature may have
  21. >>been made in New Hampshire, with the operator being located in Los
  22. >>Angelos.  
  23. >
  24. >Imagine UPS already has your signature on file.  (You sign
  25. >for something once, your signature is in their computer)
  26. >The operator could pop up the signature, regardless of
  27. >whether you had received your package or not.
  28. >
  29. >Not saying they would, but it raises questions about the
  30. >usefulness of digitized signatures.  
  31.  
  32. How so?  Database design always has to deal with security issues.  Signature
  33. digitization doesn't change that.  Before UPS had the signature, all they
  34. had, most likely, was a flag field called "signed/received" or something
  35. similar.  How is that any more difficult to tamper with?  There will always
  36. be the possibility of dishonest operators.  The system design has to
  37. anticipate this, and combat the possible damage with audit trails, passwords,
  38. authorization levels, etc.  Maybe even digitized signatures? :-)
  39.  
  40. -- 
  41. John Cavallino                  |  EMail: jcav@midway.uchicago.edu
  42. University of Chicago Hospitals |         John_Cavallino@uchfm.bsd.uchicago.edu
  43. Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
  44. B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637
  45.