TidBITS#40/04-Feb-91
====================
 
 Copyright 1990-1992 Adam & Tonya Engst. Non-profit, non-commercial
   publications may reprint articles if full credit is given. Other
   publications please contact us. We do not guarantee the accuracy
   of articles. Publication, product, and company names may be
   registered trademarks of their companies. Disk subscriptions and
   back issues are available.
 
 For more information send electronic mail to info@tidbits.uucp or
 Internet: ace@tidbits.uucp -- CIS: 72511,306 -- AOL: Adam Engst
 TidBITS -- 9301 Avondale Rd. NE Q1096 -- Redmond, WA 98052 USA
 -----------------------------------------------------------------
 
Topics:
    Clones from the Woodwork
    Private Parts
    Backup Bits
    Reviews/04-Feb-91
 
 
Clones from the Woodwork
------------------------
  The termites in the wainscotting of the Macintosh market are on
  the march again. The original and most persistent termite is David
  Small, wizard at large, and producer of a line of increasingly
  sophisticated Macintosh emulators for the Atari ST line. Then came
  the AMAX, the Macintosh emulator for the Amiga that prompted
  Usenet flame comparisons between the A3000 with AMAX and the IIfx.
  ARDI was the next termite (maybe I should allude to the marching
  ants of a selection marquee instead) with a Unix library that
  simulates Macintosh ROMs. ARDI designed its product, ROMlib, to be
  burned into ROMs and then used in Macintosh clones, and although
  it was announced in September, little has surfaced from ARDI
  since.
 
  That was it for a while. Then in November, up popped RDI and its
  Brite Lite SPARC-based laptop, which included PC and Mac
  compatibility, though we never heard how RDI achieved Mac
  compatibility. Two weeks later came the first relatively real
  clone, the Cork System 30, which features IIci performance and a
  bunch of extras, such as a DSP chip. In time for the Christmas
  press release deadline was Hydra Systems, which announced that it
  had created a PC board that runs Macintosh software. Like the Cork
  computer, the AMAX, and David Small's Spectre GCR (and of course
  the Outbound laptop), the Hydra requires that you use 128K ROMs
  from old Macs (though Hydra plans to release its own Mac-
  compatible ROMs later on in the year). Since Apple has some
  control over these ROMs, it's unclear how common such emulators
  will be, although Cork claims that plenty of Mac 512KE's and
  Pluses are out there waiting to be turned into IIci's (much as the
  ugly duckling wanted to be a swan).
 
  Just this week came perhaps the most determined termite of all.
  NuTek Computers announced that it has completely reverse
  engineered the Macintosh ROMs (no indication which ones) in a
  clean-room environment. NuTek aims to ship a three-chip set late
  in 1991 that will allow third parties to manufacture Macintosh
  clones six months later. NuTek's clones require the 68020 or
  68030, which will remove them from the bottom of the market. NuTek
  has based its interface on Motif, from OSF, which will prevent
  interface trouble with Apple's legal department, though a lawsuit
  is likely nonetheless. Like ARDI, NuTek's emulated chipset will
  not require use of Apple's system software. In addition, Hydra has
  licensed the Xerox Star interface (you remember the Star, the
  machine which Star-ted all this graphical nonsense) in deference
  to Xerox and more practically, as a defence against Apple Legal.
 
  In some ways, I'm not interested in buying a Macintosh clone. I
  once owned a Franklin ACE 1000 Apple II clone, and while it worked
  well, it never ran ProDos or AppleWorks, which would have been
  nice. Clones will never be 100% compatible because Apple reserves
  the right to change things whenever it pleases. Even in the PC
  world, you can never guarantee that every PC clone will run every
  piece of PC software and work with every piece of PC hardware.
  Complete compatibility is a myth. Even Apple's new machines take a
  while before most everything works correctly (I'm still impressed
  that programs from 1984 like FEdit and Missile Command work on
  every Mac I've tried them on).
 
  More interesting will be Apple's reaction. There's been talk of
  licensing ROMs recently in certain circles (and no, I can't tell
  you which ones), and in my opinion Apple should go ahead and do
  it. While complete compatibility is a myth, Apple stands a much
  better chance of achieving it than a company that reverse-
  engineered the ROMs. And besides, if Apple doesn't do something
  about these termites, they'll munch right into profits.
 
    Abacus Research and Development, Inc. -- 505/766-9115
    Hydra Systems -- 408/996-3880
    Cork Computer Corp. -- 512/343-1301
    NuTek Computers -- 408/973-8857
 
  Related articles:
    MacWEEK -- 29-Jan-91, Vol. 5, #4, pg. 1
    MacWEEK -- 08-Jan-91, Vol. 5, #1, pg. 173
    MacWEEK -- 18-Dec-90, Vol. 4, #42, pg. 1
    InfoWorld -- 28-Jan-91, Vol. 13, #4, pg. 1, 93
    InfoWorld -- 14-Jan-91, Vol. 13, #2, pg. 8
    PC WEEK -- 28-Jan-91, Vol. 8, #4, pg. 5
 
 
Private Parts
-------------
  United States mail, known as snail mail in electronic circles, is
  private. Among the federal crimes that you don't want to be found
  guilty of are opening other people's mail and tampering with their
  mailboxes. It's even more serious if a mail carrier reads
  someone's mail or interferes with its delivery. The US Postal
  Service doesn't advertise these facts much, but most people sense
  that the love letter sent in the mail is guaranteed to be private,
  at least until your paramour leaves it lying around after reading
  it. This sense contributes to the impression that electronic mail
  systems are equally as private, whereas in fact, no laws require
  them to be private, on the one hand, and on the other, email is
  easy for system administrators to surreptitiously read if they
  wish.
 
  This misconception of privacy has surfaced twice in the ugly
  battlefield of jurisprudence. The first case, brought by ex-Epson
  email administrator Alana Shoars, accused Epson management of
  ordering middle management to systematically read private email
  messages. Epson denies everything, but refuses to guarantee
  privacy. Shoars was not so much upset by the concept of non-
  private email, but by the secretive and harmful way in which Epson
  used the resulting knowledge.** **A California judge dismissed
  part of that case, saying that electronic mail does not fall under
  a California law protecting against telephone and telegraph
  wiretapping. Though the federal Electronic Communications Privacy
  Act (ECPA) of 1986 protects electronic communications, the ECPA
  only covers outside intervention. In other words, what you do in
  your own house or company is your business. Sleazy, perhaps, but
  your business.
 
  The second surfacing of the privacy issue developed as a case
  against Nissan Motors, brought by two information systems
  specialists, Rhonda Hall and Bonita Bourke. Their manager
  reprimanded them for using company software for personal use. He
  used copies of electronic mail messages as supporting evidence.
  Again, the crux of the issue seemed not to be the non-private
  nature of the mail, but the deception foisted on the two that the
  mail wasn't monitored. Noel Shipman, Alana Shoars' attorney, is
  handling this case as well. Mr. Shipman has no prior experience in
  electronic privacy issues, but I suspect he'll be pretty good at
  it before the issue disappears.
 
  I haven't made up my mind about this issue. On the one hand, I
  detest snoops and electronic peeping Toms. On the other hand, I
  don't think the government should regulate internal company
  policies. Our government has much to do that's more important and
  shouldn't meddle in private affairs past basic protection (and no,
  I'm not sure if electronic privacy at the company level qualifies
  as a "basic" protection). I can think of a relatively simple
  method that would eliminate the entire issue, though. What if
  every electronic mail system, and I do mean every, encrypted each
  mailfile, using the username as the encryption key? The only way
  to read the mail would be from the account to which the mail was
  sent, because no other account could decrypt the message, no
  matter what privileges the account had. If the encryption was
  built into the base system, it would make no difference to users,
  who would never notice, and if it was implemented well, it
  wouldn't drag down the system too much.
 
  Lest I sound too clever, let me add that something approaching
  this system exists in an email package called cc:Mail. cc:Mail
  runs on Macs and PCs (and just added the ability to administrate
  the system from Macs, to its credit) and performs this automatic
  encryption on all messages. The network administrator can change
  users' passwords, but cannot read their mail or perform any other
  sort of electronic snoopery.
 
  In light of this, I have several suggestions for anyone
  potentially affected by these issues. First, make sure your
  organization guarantees either that mail will or will not be
  private and publicizes the decision. That will solve many
  problems. Second, suggest repeatedly to the makers of your email
  package (if it's not cc:Mail) that they implement automatic
  encryption as soon as is feasible. Third, if you see no sign of
  compliance from your email supplier or plan to set up a new
  system, consider using cc:Mail. Note that I know little about
  cc:Mail other than what the reviews have said - use the command
  --find whole "cc:Mail"-- (in the message box in HyperCard and
  don't include the dashes, of course) to search your TidBITS
  Archive to find the three relatively recent reviews of cc:Mail.
 
  Universal automatic encryption would remove almost all problems
  related to private email and would satisfy everyone except those
  who steal useful information from others' mailfiles. Another
  advantage would be the removal of responsibility from the network
  administrator. To use an example from a networking conference at
  which I spoke last summer, what if a network administrator
  "happens" to see a mailfile organizing the takeover of a campus
  building by a radical group? Common sense and duty require that
  person to report the incident to the authorities, but if the
  university guarantees private email without encrypting mail, the
  administrator could be guilty of breaking university policy. So
  the administrator sits between the proverbial rock and a hard
  place. It could become more complicated yet, if the takeover could
  have been prevented (by breaking campus policy) and someone is
  accidently hurt or killed in the process. It's all too complicated
  to decide hypothetically, but would be completely moot if that
  email was encrypted. Ideally, such encryption would force policy
  makers to admit that they have no say over mail which may contain
  undesirable content (sex, drugs, and rock 'n roll) and merely
  passes through their sites on its way elsewhere.
 
  Technology needn't make life more difficult, particularly in this
  case, where it can remove such issues from everyday life and from
  the legal battlefield. Lawyers simply don't need our business and
  it would be great if we didn't need them.
 
  Related articles:
    Current Events (CE newsletter) -- Winter-90, pg. 3
    InfoWorld -- 21-Jan-91, Vol. 13, #3, pg. 33
    InfoWorld -- 21-Jan-91, Vol. 13, #3, pg. 85
    InfoWorld -- 14-Jan-91, Vol. 13, #2, pg. 5
    InfoWorld -- 22-Oct-90, Vol. 12, #43, pg. 58
 
 
Backup Bits
-----------
  In the never-ending effort to implement a disk backup method that
  offers users both transparency and complete control, SuperMac
  technology and Dantz Development each recently shipped upgrades to
  their backup programs, DiskFit 2.0 and Retrospect 1.2.
 
  DiskFit 2.0 is a major upgrade from the previous version and
  includes a host of new features that promise to make DiskFit
  competitive with Retrospect as one of the premier backup programs,
  though DiskFit retains its "feature" of keeping files in Finder-
  readable format. DiskFit now offers better control over file
  selection with a tree-like interface for selecting and excluding
  specific folders (the propaganda doesn't mention whether or not
  specific files can be included or excluded in this fashion). Files
  can be excluded by type or creator, which is helpful. Like
  Retrospect, DiskFit can perform unattended backups, starting up
  and shutting down automatically. Having this capability internal
  to the program is important, because workarounds with macro
  programs like QuicKeys2 work, but they are more subject to error.
  Again like Retrospect, DiskFit allows the user to define a folder
  on a hard disk as a subvolume, which can be a useful way to define
  the data to backup and restore. I guess there was a lower limit
  before, but DiskFit can now backup and restore files up to 2
  gigabytes in size. If your files are larger than that, forget it
  and buy another backup system. Think of it this way. It would take
  over 2.5 million 800K floppies and over 17 hours (at 1 meg per
  minute) to back up that single file. I've got better things to do
  with my time. The final new feature of DiskFit is an interesting
  one, considering a new product at Macworld Expo. It is compatible
  with a number of automatic floppy disk loaders, presumably
  including the one just released by Fifth Generation Systems, the
  Jukebox 5. More on that later. Oh, upgrades are $24.95 for DiskFit
  and $54.95 for Network DiskFit (the same thing but it works over
  networks and preserves network privileges), but if you bought
  either one after October 1st, 1990, you get the upgrade for free.
  Owners of SuperMac hard drives can download the upgrade for free,
  or pay $14.95 to have SuperMac send you a copy personally (but I
  don't think it's autographed).
 
  Retrospect 1.2 isn't as major as an upgrade as DiskFit 2.0, but
  that's mostly because most of the power was already there.
  Retrospect now offers a simplified way of backing up and
  restoring. Two buttons have been added to the main screen, Backup
  and Restore, which do little different from their Archive and
  Retrieve counterparts, but which offer fewer options and less
  complexity. There are a few interesting functional changes as
  well, including the ability to back up multiple source**s** to
  single or multiple archives in a single step. In this way, you can
  save two hard drives onto a single tape in a single step, for
  instance. Most interesting though, is a companion product,
  Retrospect Remote, which uses Retrospect 1.2. With Retrospect
  Remote, you can back up any volume (or part of one) over any
  AppleTalk network (that's LocalTalk, EtherTalk, and TokenTalk, and
  perhaps GoTalk soon) to any other storage device. The upgrade
  price for Retrospect 1.2 is $30 if you purchased it before
  September 1st, 1990 and free otherwise. The price of Retrospect
  sits still at $249 and Retrospect Remote (for 10 users) runs $449.
  Another Remote 10-Pack costs $249. Apply all normal discounts to
  those prices - Retrospect itself is usually a little more than
  $150 mail order. For more details on Retrospect 1.2/Remote, wait
  for our full review issue, coming sometime to a network near you.
 
  Backup programs, particularly ones that do unattended backups, are
  awfully nice, but most of us probably don't have backup media that
  we can trust to insert itself into the disk drive at the proper
  time. A butler would help ("Jeeves, the backup please."), but few
  of us are blessed with such help. Fifth Generation Systems may
  have the answer with its Jukebox 5, the closest thing to a butler
  I'm ever likely to have. For a mere $99, you get a cute little box
  that feeds up to 15 disks into your Mac's disk drive. And unless
  your drive is different from mine, there's only room for one disk
  at a time, so the Jukebox 5 will accept the ejected disk and store
  it in a hopper. That's the best option for those of us without
  larger backup volumes. Of course there are limits; you have to
  limit the incremental backups to 15 disks, which shouldn't be too
  hard if you do them relatively often, and your backup program must
  work with the Jukebox 5. I don't know if Retrospect does, but
  DiskFit claims it should, and I'd be very surprised if Fifth
  Generation's own Fastback didn't. Jukebox 5 is good for automated
  copying, if you need to crank out 15 copies of something for a
  user group or whatnot. There may be other floppy flippers (I
  should probably trademark that name) but I haven't heard of them,
  so the Jukebox 5 could be the one to break open the market.
 
    SuperMac Technology -- 408/773-4489
    Dantz Development -- 415/849-0293
    Fifth Generation Systems -- 800/873-4384 -- 504/291-7221
 
  Information from:
    SuperMac propaganda
    Dantz propaganda
    Fifth Generation propaganda
    Ken Hancock -- kenh@hscfsas1.harvard.edu
 
 
Reviews/04-Feb-91
-----------------
 
* MacWEEK
    Shapes, pg. 33
    Page Director, pg. 33
    Essential Tools & Objects CD-ROM, pg. 34
 
* MacUser
    FileMaker Pro, pg. 44
    Norton Utilities for Macintosh, pg. 46
    Nisus 3.01, pg. 47
    Typist, pg. 58
    Navigator and CIM, pg. 62
    Interchange Programs, pg. 68
      Software Bridge for the Macintosh
      Word for Word/Mac
    MacroMind Director, pg. 72
    Claris CAD, pg. 75
    ClickChange, pg. 88
    Personality!, pg. 88
    DiskLock, pg. 88
    The String Quartet, pg. 88
    MacRAM Portable, pg. 90
    Screenshot, pg. 90
    HP 48SX Calculator (hooks to a Mac), pg. 92
    Editorial Advisor, pg. 92
    Personal PostScript Lasers, pg. 116
      (too many to list)
    32-Bit Color Paint Programs, pg. 134
      Studio/32 1.0
      PixelPaint Professional 1.0
      DeskPaint 3.03
      Color MacCheese
    Geographic Analysis Programs, pg. 158
      ATLAS*MapMaker
      Descartes
      GeoQuery
      MacInfo
      Tactician
 
* BYTE
    Fax-O-Matic, pg. 127
    FaxConnection, pg. 127
    FileMaker Pro, pg. 130
    Excel 3.0, pg. 136
    Illustrator 3.0, pg. 178
 
References:
    MacWEEK -- 29-Jan-91, Vol. 5, #4
    MacUser -- Mar-91
    BYTE -- Feb-91
 
 
..
 
 This text is encoded in the setext format. Please send email to
 <info@tidbits.uucp> or contact us at one of the above addresses
 to learn how to get more information on the setext format.
