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

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

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 sources 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 — [email protected]