TidBITS#714/26-Jan-04
=====================
To commemorate this week's 20th anniversary of the Macintosh, Adam
talks with Bruce Horn, who wrote the Finder, about what he did
at Apple, where he's been since, and what Macintosh projects he's
working on now. Also, Brady Johnson rejoins us with a look at
whether the new U.S. CAN-SPAM Act will have any effect on our
increasing spam volumes. In the news, Dantz ships Retrospect 6,
and OrangeWare provides Mac OS X drivers for wireless cards using
Atheros chipsets, including 802.11a cards.
Topics:
MailBITS/26-Jan-04
Dantz Ships Panther-Compatible Retrospect 6.0
The Mac at 20: An Interview with Bruce Horn
Can CAN-SPAM Can Spam?
Hot Topics in TidBITS Talk/26-Jan-04
<http://www.tidbits.com/tb-issues/TidBITS-714.html>
<ftp://ftp.tidbits.com/issues/2004/TidBITS#714_26-Jan-04.etx>
Copyright 2004 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: <[EMAIL PROTECTED]>
---------------------------------------------------------------
This issue of TidBITS sponsored in part by:
* READERS LIKE YOU! Help keep TidBITS great via our voluntary <------ NEW!
contribution program. Special thanks this week to Peter Morgan
and the ApplesBC Computer Society for their generous support!
<http://www.tidbits.com/about/support/contributors.html>
* SMALL DOG ELECTRONICS: iBooks On Sale! <--------------------------- NEW!
iBook 12-inch G3/800, Only $739! iBook G3/800 640 MB RAM, $739!
iBook G3/900 14-inch 640/60/Combo/56K/AirPort, Only $1,149!
Visit: <http://www.smalldog.com/tb/> 802-496-7171
* FETCH SOFTWORKS: Is maintaining your Web site tedious? Use <------- NEW!
Fetch, the original Macintosh FTP client, and you can record
AppleScripts that automate repetitive uploads and downloads.
Get Fetch now at <http://fetchsoftworks.com/>!
* Discover, Master, and Unleash the Music in You! <------------------ NEW!
The Big Mix from Aladdin Systems delivers nine awesome titles
in one complete audio package. Get the Big Mix for only $69.99.
<http://www.aladdinsys.com/store/tidbits/bigmix.html>
* DR. BOTT, LLC: Explore our vast assortment of iPod accessories!
NaviPod wireless remote; PocketDock for using standard FireWire
cables with your 3G iPod, and other startlingly cool gear for
enhancing your digital lifestyle. Visit <http://www.drbott.com>
* Web Crossing: now with plug-ins for blogs, wikis, RSS, and more.
Web Crossing v5.0 now sports a new plug-in architecture and
easy customization, yet it's still fast and powerful. Try our
free Web & email server! <http://www.webcrossing.com/tb-104>
---------------------------------------------------------------
MailBITS/26-Jan-04
------------------
**Mac Users Join the "A" List** -- When Apple's AirPort Extreme
(IEEE 802.11g) wireless networking system was announced in January
2003, Steve Jobs declared an older, equally fast system dead. He
said 802.11a, which uses a different range of frequency from the
AirPort (802.11b) and AirPort Extreme standards, would join the
dustbin of history, as the lack of backwards compatibility doomed
it. A year later, 802.11a has more legs because of additional
frequencies allotted to its band, and the large number of wireless
cards from non-Apple sources that can handle 802.11a, b, and g.
802.11a doesn't suffer from as much junk radio interference as
b and g. But Mac users have been excluded from this revolution
so far.
OrangeWare is now offering software drivers that they developed
for 3Com to support a set of chips from Atheros, a competitor to
Apple's wireless source Broadcom. Although the OrangeWare driver
lets Mac OS X use Atheros-based wireless cards, Mac users have
been able to use 802.11g cards made by Linksys, Buffalo, Belkin,
and others that share the Broadcom chips used in the AirPort
Extreme line-up ever since the AirPort 3.1 software update was
released. With the $15 trialware OrangeWare driver, you can use
802.11a or a/g PC or PCI cards from NetGear, Fujitsu, D-Link and
others. OrangeWare has a short list of cards they've tested. [GF]
<http://www.orangeware.com/endusers/wirelessformac.htm>
**DealBITS Drawing: Cocoatech Winner** -- Congratulations to
Gloria Harman of yahoo.com and Richard I. Levine of pobox.com,
whose entries were chosen randomly in last week's DealBITS drawing
and who will be receiving a copy of Cocoatech's Path Finder. Don't
despair if we didn't pick your entry, since Cocoatech is offering
a special price on Path Finder for all TidBITS readers, bringing
the price from $34 down to $29.95. The discount is good through
02-Feb-04 via the second link below. Thanks to the 564 people who
entered, and keep an eye out for future DealBITS drawings. [ACE]
<http://www.cocoatech.com/>
<http://www.cocoatech.com/tidbits0104/>
<http://www.tidbits.com/dealbits/cocoatech.html>
<http://db.tidbits.com/getbits.acgi?tbart=07508>
Dantz Ships Panther-Compatible Retrospect 6.0
---------------------------------------------
by Glenn Fleishman <[EMAIL PROTECTED]>
Dantz Development's venerable Retrospect backup software is now
fully Panther-compatible with an electronic download release that
shipped today. Although Retrospect 5.1 would work under Panther,
and Retrospect Client ran fine in Panther, Dantz had released a
laundry list of situations to avoid and problems in launching and
getting the application to run after restarts and system failures.
(We all stuck with Jaguar on our backup servers.)
<http://www.dantz.com/>
<http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28093>
Retrospect 6.0 could be seen as a maintenance release with a hefty
upgrade price tag unless you have one of four special needs:
making backup sets larger than one terabyte; backing up to an
Xserve RAID; using tape libraries over SCSI or Fibre Channel; or
spanning multiple hard drives with a single backup set, something
Adam ran into with his current hard drive-based backup strategy.
The company also notes speed improvements.
<http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28121>
<http://db.tidbits.com/getbits.acgi?tbart=07295>
The software is available for download right now; the boxed
version follows in mid-February. Pricing is complicated, as is
usual with the number of versions Dantz offers for small, medium,
and large networks.
Retrospect Desktop can back up one local Mac and two networked
Windows, Mac OS, or Red Hat Linux systems with the included
Retrospect Client software. However, it cannot back up computers
running Mac OS X Server (either locally or with Retrospect
Client), and it doesn't offer the large tapeset, Xserve RAID,
or terabyte options. List price is $130 with a $60 upgrade from
previous versions.
Retrospect Workgroup and Retrospect Server include client support
for 20 and 100 machines, respectively, and all the large data
options. However, only Retrospect Server can back up Mac OS X
Server systems. Workgroup lists for $500, and an upgrade is $200;
Server is $800 with a $350 upgrade.
All versions include Retrospect 5.1 if you want to run Retrospect
on a Mac OS 9 system; Retrospect 6.0 can back up older Macs
running Retrospect Client software. Also included is a bootable
disaster recovery CD, but only with the boxed version, not as
part of the electronic-only purchase.
The Mac at 20: An Interview with Bruce Horn
-------------------------------------------
by Adam C. Engst <[EMAIL PROTECTED]>
Twenty years of Macintosh. At this year's Macworld Expo, Steve
Jobs played a version of the famous "1984" ad that launched the
Mac, and Alan Oppenheimer, who was responsible in large part for
AppleTalk, gave a fabulous talk about the history of networking on
the Mac. What I found most interesting was that although twenty
years have passed, many of the original people from those days are
not only still around, they're still producing great work. The
history of the Macintosh is not only still being written, some
of the same people are still doing the writing.
<http://www.opendoor.com/nethistory/>
Let me introduce you to another member of the original Macintosh
team, Bruce Horn, who was responsible for a number of the key
aspects of the Mac and who has continued to write innovative code.
At Apple, Bruce was responsible for the design and implementation
of the Finder (oh, that!), the type/creator metadata mechanism for
files and applications, and the Resource Manager (which handled
reading and writing of the resource fork in files; a note in
Apple's technical documentation at one point exclaimed, "The
Resource Manager is not a database!"). The Dialog Manager and the
multi-type aspect of the clipboard also appeared thanks to Bruce's
ingenuity.
So, to commemorate this 20th anniversary of the Macintosh, I
wanted to talk with Bruce about not just what he did at Apple, but
also what he's up to now, since in many ways, his current work is
both a return to his roots and a glimpse at what might be possible
with the Macintosh in the future.
* Adam: Bruce, many of the aspects of the original Mac that you
worked on revolve around accessing structured data. The Finder was
a front end to the filesystem; the Resource Manager, despite that
note in the documentation, was a bit like a flat-file database;
and type/creator codes were metadata that were just screaming to
be used by a database. To what extent was all that planned, or did
you just come to these solutions as you were working?
Bruce: Several different goals drove me to these solutions. Having
had most of my programming experience in Xerox's Smalltalk
environment, where you could change anything you wanted at runtime
(changes made while the program was running), I was looking for
a dynamic way to handle objects in the system so data such as
localizable strings, menus, images, etc. could be modified by
non-programmers without recompiling the source code. At the same
time, I was realizing that the kind of data that I needed to
manage with the Finder - icons for applications and documents,
and bindings to those icons - needed the same sort of mechanism,
and I wanted a unified solution. So the Finder's Desktop Database
was the driver for much of what the Resource Manager ended up
providing.
The file metadata also was driven by Finder needs. Early on I
realized that to provide a double-click-to-open mechanism for
documents, I'd need a simple way to link a document to a default
application that would open it. Similarly, since multiple
applications could open multiple file types, I couldn't just have
a single mapping from a type to an application that would handle
all files of that type. Thus the separation of the type code
(the actual format of the file) and the creator code (the default
application, which could be easily changed). Independent type and
creator codes stored in the filesystem also enabled us to avoid
polluting the filename with type information, which I felt was
a significant advantage of our approach over others.
The Desktop Database was a cache of the bindings between types and
creators and the icons representing them, stored as resources.
Since application bundles - groups of resources tied together
describing document type and icon information - were stored in
application resource forks, installing an application simply
involved copying the appropriate resources from the application
into the Desktop. The redundant information - type and creator
information in the directory, and bundle information in
application resource forks - made it possible to rebuild the
database at any time without losing anything. It turns out
that this was important in the early days.
Resources were, of course, heavily used in factoring out non-
program data (like menus and text strings) that could be localized
to different languages. With ResEdit, this allowed language
experts to quickly create versions of an application without
needing access to the source code.
Once I was able to convince Andy Hertzfeld of the utility of the
Resource Manager, he rewrote most of the Toolbox to take advantage
of it, which saved significant space in the ROM and gave us the
ability to easily localize applications in a general way.
* Adam: So Mac OS X's reliance on Unix-style filename extensions
for mapping documents to applications is something of a step
backward, then?
Bruce: Yes and no. The original rationalization behind this
was that Mac OS X needed to be compatible with Windows filename
conventions, and to do so we'd need to force filename extensions
to be provided. Because there are so many places that a file might
leave the sanctity of the Mac OS and go out into the cruel world
where extensions are required, it was deemed impossible to
translate names from the Mac convention (with types and creators)
to the outside world's convention. As far as compatibility is
concerned, this did the trick.
But over time it has become apparent that it is difficult to do
this right, and the original mechanism of having redundant type
information, and allowing the user to name the files whatever she
wants, was more flexible and less prone to error. It turns out
that Mac OS X still needed a creator mechanism by which individual
documents could be opened by specific applications, so this
information is stored in the resource fork of the file (of all
places, since Apple is discouraging use of the resource fork),
rather than simply in a creator code.
So the filename extension approach has worked, but with a little
less elegance than the original.
* Adam: Why didn't you go all out and create a system-level
database to handle all this data in the original Mac? Was it
a horsepower issue, or were the software problems too tricky
at the time?
Bruce: It would have been nice. I had some ideas in mind, but when
it came down to fitting it in the 64K ROM, the Resource Manager
was all we could fit. It was a real effort on everyone's part to
make code as small as possible. The Resource Manager was 3K, and
the Finder 46K - amazing considering the size of applications
these days!
* Adam: When did you leave Apple, and what caused your departure?
Bruce: I left Apple in the spring of 1984, after doing a "final"
version of the Finder. I guess I was just looking for something
new to do: having spent several years working intensively on the
Mac, I was ready for a break. Being on the Mac team, working with
absolutely tremendous people, was one of the most significant
things I've done, and it still gives me wonderful feelings when
I think about those times.
* Adam: Can you give us a quick rundown of where you worked after
Apple? Were there any common threads among the various projects?
Bruce: After Apple I went to Adobe and worked a bit on a variety
of small projects, including a LaserWriter spooler. When I was
there I met a couple of Carnegie Mellon grad students, and, to
make a long story short, they convinced me that I should go to CMU
for graduate school (Chuck Geschke, one of the founders of Adobe,
was also a CMU Ph.D.) Grad school was a great experience. I spent
some time at the University of Oslo, Norway as a research
assistant, did some consulting at Apple now and then, and had
a chance to work with some intriguing startups while I was a
student. My Ph.D. thesis described the design of a constraint-
based object-oriented programming language called Siri, which
I'd love to re-implement someday.
After graduating I went back to Apple as a consultant in the
Advanced Technology Group and worked on a project called LiveDoc
with Tom Bonura and Jim Miller, among others. LiveDoc was an
experiment in automatically structuring documents so that various
recognizers could determine that, for example, 555-1212 was a
phone number and 124 Main Street was an address, and provide
contextual actions on those items. It was a lot of fun, and I
wish I had LiveDoc today in Mac OS X. Simson Garfinkel's SBook
provides some of these features as a PIM application.
<http://www.sbook5.com/>
But none of these projects really addressed the problem I wanted
to solve, which was: how can I design an information browser that
works with all types of data, from email messages to images to
music files to documents, and provide a unified mechanism for
organizing, searching, and viewing this information?
I began the iFile project in 1997 to do this, and worked on it for
a couple of years before putting it on the back burner to start my
other company, Marketocracy, where I've been since the middle of
1999.
Marketocracy is a mutual fund company that I co-founded with my
business partner Ken Kam. Our team built a Macintosh-based Web
site running WebObjects and a FrontBase database to allow over
50,000 people worldwide to buy and sell stocks in real time (but
with fake money) to create a model stock portfolio. We provide a
wide variety of tools to help our users to become better portfolio
managers, and by watching their performance over time and ranking
them, we can find the best people in the world to run our funds.
Our Masters 100 Fund, based on the top 100 in our community, has
been running for over two years now and has surprised even us with
its impressive performance and low risk. It has returned over 39
percent since inception when the market has been essentially flat,
and with a beta of 0.47 - half as risky as the market!
<http://www.marketocracy.com/>
* Adam: What are you working on now?
Bruce: Recently I've picked up where I left off in 1999 with iFile
(just a codename for now). iFile is a unified desktop information
browser, like the Finder, but with significant architectural
improvements. It is based on an object-oriented database of my own
design that provides a general way for linking together and
organizing objects of all types. The basic unit of organization is
called a "collection," which is distinct from a folder in that an
object may exist in many collections but in only a single folder.
Collections are like iPhoto albums or iTunes playlists, but they
can contain anything: text files, images, email messages, music
files, contacts, notes, appointments, and so on. While this sounds
a bit like BFS (BeOS Filing System) and the BeOS Tracker combined,
it is much more general and can be used on any filesystem with the
appropriate drivers.
The obvious first application for the iFile technology was
in photo organization, an area in which iPhoto does quite well
already. However, iFile provides more capability in organization
by image metadata (it currently keeps track of 46 different
pieces of metadata for each image), and it should scale much
more smoothly for large collections than iPhoto. But iFile is
not simply a photo manager: it is a general purpose information
browser that can be used in a variety of ways, and can easily
integrate different information sources, such as PIM, email, and
music, among other data types. I think the version of iFile that
I will release publicly will provide much more capability in
those domains.
* Adam: Is it fair to describe iFile as the Finder you'd write
today?
Bruce: Possibly. I think it is much more ambitious than I had
originally intended. If I can eventually get it scaled down to
a level where new users can understand it quickly, it might be
a nice alternative to the Finder.
* Adam: Have you shown it to people at Apple? What did they think?
Bruce: Back in 1999 I showed it first to the Finder group, then
to Avie Tevanian, and finally to Steve Jobs. I think that Apple
was strongly focused on solving the problems of getting Mac OS X
out the door as soon as possible, and looking at an alternative
Finder was low on their priority list. I believe they were
intrigued but had already committed to a different direction,
and couldn't turn the ship in time to take advantage of the
iFile technology. Given the history of Mac OS X, I think they
made the right decision.
* Adam: Let's look at iFile more deeply. There are two aspects to
any filing system, getting data in and displaying that data to
the user. How would someone get data into iFile?
Bruce: The current version of iFile requires the user to specify
the folders that the user would like iFile to track; this is done
by dragging the folders into the iFile workspace window. Once this
is done, iFile tracks any changes to the contents of the folders
and automatically updates the database as required. For example,
the user can drag in the Pictures folder and be able to browse all
the images, create collections, etc., without actually copying any
files or moving any data. iFile respects your directory structures
and never modifies anything directly, in contrast to iPhoto, which
copies images into its own directory hierarchy.
The release version of iFile will not require the user to request
that certain folders be scanned. Instead, iFile will initially
provide a view on the user's home directory, and will scan the
files and folders in the background automatically.
* Adam: Good! The less work users must do, the better. In fact,
one of the main problems with any filing system is that few people
put enough effort into categorizing and managing their data to be
able to find things later reliably. Can iFile automatically
categorize files based on metadata and content?
Bruce: Yes, it can. Collections are a way to automatically
categorize files by their properties. Because iFile maintains
file metadata in the object database, it can search and sort
through the metadata very quickly to return the appropriate
files. Collections are also "live": specifically, if files
appear on the disk that match a collection's specification,
they will be automatically added to that collection, regardless
of whether the collection is currently being viewed. One can
imagine all sorts of interesting AppleScript scripts that could
be triggered based on these events.
Collections also collect files based on their content. Rather than
searching for individual words as Google does, collections search
for key phrases: a word or a sentence. Files that contain any of
the key phrases specified in the collection are automatically
gathered into that collection.
So, what collections do is provide a new way to slice-and-dice the
information you already have in a different way, without requiring
you to import your data or commit to a completely new
organization.
* Adam: What do you think about adding a capability along the
lines of a Bayesian classifier that would evaluate the contents
of a file statistically, much the way some spam filters or the
email classifying program POPfile work? That could reduce the
user's effort even further.
Bruce: That is a great idea and has been discussed for quite some
time. In fact, Apple had worked on a project that was based on
this idea. Piles were automatic groupings of files based on their
content:
<http://www.theregister.co.uk/content/archive/30360.html>
One of the challenges here is to determine an appropriate
similarity function: how do you decide what the collections should
be a priori, to avoid the problems of hundreds of collections,
each with one file, or a small number of collections with
thousands of files? That will take some work.
* Adam: What does iFile do on the display side? Can users create
their own "smart folders" (a bit like smart playlists in iTunes)
that automatically show files that match a specific query?
Bruce: Absolutely. A collection is essentially a smart folder,
with a query specification. For example, it is easy to create
a collection that groups together all the images taken by a
particular model camera by specifying "<Model> is '2500' and
<Make> is 'Nikon'", since that data is available in the EXIF
metadata for the image. Similarly, metadata such as ID3 tags for
music; image data such as resolution, width, and height; file data
such as filenames, creation and modification dates, and sizes; and
so on are all stored in the database for object retrieval and
organization.
So collections actually have three mechanisms for grouping:
manually via drag-and-drop; automatically via metadata query
specification; and automatically via key phrase match.
* Adam: iFile's architecture sounds tremendously appealing, but
I suspect the devil is in the details, and thus in the interface.
Does iFile stick with the current file/folder metaphor (despite
the terminology shift to collections), or does it offer a
rethinking of how we interact with our data?
Bruce: You are right that the devil is in the details. I'm
currently working on how to present all this information in an
appropriately intuitive fashion, and I think I'm getting closer,
but there is still clearly work to do.
iFile begins with the traditional, icon-based file and container
organization (containers being either folders or collections),
but goes further with a variety of different views and layouts.
Many of the layouts provide preview views of the contents of
the files, and in the case of text files, iFile automatically
creates hyperlinks to related collections from within the text.
It's difficult to explain, but once you use iFile you'll find
that some of the views do in fact provide you ways to view your
data from different perspectives.
The more you provide iFile with information regarding how you want
to see your data, via defining collections, the more it can help
you by cross-indexing and showing relationships where they were
not clear before.
* Adam: Are some of the things you're attempting in iFile beyond
what many users can understand? Lots of people just want to be
told what to do, and something with iFile's flexibility might
be lost on them unless it was able to watch their actions and
automatically build collections.
Bruce: I agree that iFile can be somewhat intimidating to new
users: there are a lot of different things that iFile can do,
and there needs to be more immediate gratification when using it.
Creating collections automatically is a good approach, and by
creating useful collections based on not only images but documents
and email, I think that the power of the technology will become
more apparent. I'm planning on implementing some of this in the
next few months, so stay tuned! For anyone interested in this
technology who would like to be contacted when there is a public
version available, sign up at the site below, and I'll keep you
up to date. I'd be happy to go into detail about the release
version in a future issue of TidBITS.
<http://www.ingenuitysoftware.com/>
* Adam: Bruce, thanks for taking the time to chat with me, and
we're all looking forward to seeing what you come up with iFile.
Who knows, perhaps now that Apple has stabilized Mac OS X, they'll
be interested in looking at what you've done again.
Can CAN-SPAM Can Spam?
----------------------
by Brady Johnson <[EMAIL PROTECTED]>
Talk about deja vu. I recall having written this introduction
for a TidBITS article about spam before, each time changing the
unhappy statistics about spam volumes in an upward direction.
I always start by looking at Brightmail and other sites that track
spam to see how the efforts have fared so far. Sad to say, the
news has never been good. Even Congress has acknowledged this in
the opening lines of the CAN-SPAM Act, enacting this sorry comment
into law: "Unsolicited commercial electronic mail is currently
estimated to account for over half of all electronic mail traffic,
up from an estimated 7 percent in 2001, and the volume continues
to rise."
<http://db.tidbits.com/getbits.acgi?tbser=1169>
In fact, according to Brightmail, spam is rising faster than
the mercury on a hot summer day. In 2002, spam accounted for 40
percent of all email, meaning that if Congress's 7 percent number
is correct, between 2001 and 2002 there was a nearly 600 percent
increase. By the end of 2003 that number had soared to 58 percent.
If the trend continues, 65 percent of our email will be spam by
the end of 2004.
<http://www.brightmail.com/spamstats.html>
To stem this tide, Congress has enacted the "Controlling the
Assault of Non-Solicited Pornography and Marketing Act," or
CAN-SPAM. On 16-Dec-03 President Bush signed the bill into
law and it became effective on 01-Jan-04.
<http://www.spamlaws.com/federal/108s877.html>
CAN-SPAM has generated much discussion and debate, with much of
the wired community angrily dismissing it as a deal with the devil
and the marketing community hailing it as a significant step
forward in the battle to combat spam.
Reading the various commentaries on CAN-SPAM, it quickly becomes
clear that a key disagreement turns on the definition of "spam."
To many regular Internet users, "spam" includes any unsolicited
bulk email from any source. To these users, CAN-SPAM addresses
only a small subset of spam while legitimizing the rest of it. The
marketing community and others maintain that bulk email that is
not misleading or deceptive is fair exercise of their commercial
free speech rights and is no more objectionable than junk snail
mail. Thus, they claim that it should not be included in the
definition of "spam." To these users, CAN-SPAM represents a
major step forward.
**What Is "Spam" Anyway?** I feel obligated to point out that spam
is actually a pinkish processed meat product made by Hormel.
Hormel has belatedly taken issue with using their product's name
for noxious email and is attempting to block trademarks that
include "spam" such as SpamArrest.
<http://abcnews.go.com/sections/scitech/Business/techtv_spam030801.html>
But to many folks, "spam" simply refers to any unwanted email from
a stranger trying to sell a product, tout a position, advertise a
commercial Web site, or sway the reader's opinion in some way. As
anti-spam legislation has been enacted in the various states, the
definition has morphed and narrowed to "unwanted commercial email"
or "UCE," exempting non-commercial email such as political or
charitable solicitations. CAN-SPAM narrows this definition even
further.
CAN-SPAM uses the term "spam" only in the title acronym and in one
of the initial recitations. (Recitations in a statute have no
legally binding effect and are merely statements of policy reasons
to aid courts in interpreting it.) CAN-SPAM defines "commercial
electronic mail" as email, "the primary purpose of which is the
commercial advertisement or promotion of a commercial product
or service." Political and charitable solicitations are still
excluded from this definition, as are "transactional or
relationship messages," which are email messages from a party
with whom you have an existing connection of some kind.
CAN-SPAM gives the Federal Trade Commission (FTC) the authority
to change the definition of "transactional or relationship
messages... to the extent that such modification is necessary
to accommodate changes in electronic mail technology or
practices and accomplish the purposes of this Act." However,
the FTC does not have authority to alter the definition of
"commercial electronic mail."
**Key CAN-SPAM Provisions** -- CAN-SPAM's most severe prohibitions
focus on certain types of deceptive and fraudulent email. These
can subject the spammer to substantial criminal penalties of
three years in prison for a first offense and five years for a
subsequent offense, or for deceptive commercial email that is
sent in furtherance of another felony. This would include, for
example, the many messages claiming to be from exiled political
leaders seeking help to launder and share their hoards of untold
wealth if only the recipient would provide a valid bank account
number to them first. Those messages - already the subject of
prosecutions under existing criminal statutes - are subject
to further criminalization under CAN-SPAM.
Other criminal acts include using a computer, server, or domain
to send or relay commercial email without the lawful owner's
permission, and using false headers or misleading subject lines.
These activities are also subject to civil actions and penalties
in addition to criminal prosecution.
CAN-SPAM uses an opt-out model, requiring that all commercial
email include a method of opting out of future mailings from the
sender and must include the sender's real email address and snail
mail contact information. The statute specifies that spam must
contain a mailto, Web link, or other online mechanism that the
recipient can use to opt out. All commercial email subject to
CAN-SPAM is required to identify itself as an advertisement.
The statute does not specify how spammers should identify their
email, leaving that to the FTC, which has until April Fools Day
(01-Apr-04) to publish the identifying marks that spammers must
use. Like other provisions of CAN-SPAM, this identification
requirement does not apply to mail sent to anyone who has
affirmatively consented to receiving the messages.
CAN-SPAM considers certain actions to be "aggravated violations"
potentially subject to more severe penalties. These include
the common practice of harvesting email addresses from various
Internet sources and of using "dictionary attacks." Hijacking
someone else's server is also an aggravated violation.
One heavily criticized component of the Act is the provision
preempting all state laws addressing spam with certain very
limited exceptions. The only state laws that survive this
evisceration are those that prohibit falsity or deception in
commercial email such as the Washington state statute and large
parts of the California statute, and those that only incidentally
affect email. Examples of statutes with incidental effects on
email would include general computer trespass laws, consumer
protection statutes, and other laws that apply generally to
conduct that may sometimes include email. That means that much
existing state law has fallen by the wayside and that the
California opt-in statute which was to take effect this year
has been essentially nullified in most material respects.
As far as enforcement goes, CAN-SPAM allows no private right of
action, meaning that individual victims of spammers cannot go to
court and sue for violation of the statute. Authorized enforcers
are the FTC and other federal government agencies, state Attorneys
General, and Internet service providers. It's worth noting that
Internet service providers often have their own acceptable use
policies relating to email and spam. The new federal statute does
not disturb these private rules, meaning that an ISP retains
authority under those policies to cancel or suspend a user and
often to claim damages, etc. for violation. Leaving ISP authority
in place provides an independent, if seldom-used, basis of
liability against spammers.
**Will CAN-SPAM Work?** I don't think so. CAN-SPAM is a decent
enough starting point, but in my opinion it has too many flaws
to make it effective to stop or even slow spam.
CAN-SPAM's good points are that it is a federal statute and thus
applies uniformly throughout the United States. This eliminates
the sometimes confusing patchwork of different laws in the states
that have enacted anti-spam statutes. It also goes a long way
toward resolving jurisdictional issues involving whether a state
has authority to control a business operating outside its
boundaries. These jurisdictional disputes were quite common
under state spam enforcement.
It's also good to see the various "aggravated violations" called
out and codified, since having them more clearly made illegal will
simplify the job of prosecutors.
Also, anything that increases the potential liability for spammers
may sway the economic balance of spam. If sending spam could
result in prison, spammers will have to determine if the rewards
are worth the potential risk. While added liability may not
impact the scofflaws who will ignore any legal mandate or
prohibition unless they are arrested, increasing the risk of
prison or significant monetary penalties will probably scare off
businesses that might been considering skirting the law before.
But despite those good points, CAN-SPAM's flaws abound. Let's
examine them.
**International Problems** -- Unfortunately, CAN-SPAM applies only
in the United States. True, U.S. law and international treaties
do confer jurisdiction on U.S. courts to address issues arising
internationally if they impact the U.S. But while that may sound
nice on paper, it suffers from two major problems.
First, there is the problem of actual enforcement. Spammers
operating outside the U.S. are often not subject to U.S. courts,
and even where they are, any judgment or court order is worthless
unless it can be enforced. This fact means that the only way an
enforcement agency can compel a foreign spammer to comply with the
law is via diplomatic pressure from the U.S. Show of hands: how
many people think that enforcing U.S. spam law is likely to become
a high priority for U.S. diplomatic efforts any time soon? Now,
if we could show that spammers were actually fronts for terrorist
organizations...
Second, CAN-SPAM's opt-out approach is directly at odds with the
approach taken by much - perhaps most of the rest of - the first
world. The European Union has adopted a Directive (a policy
document) that establishes an opt-in approach. Each individual
member nation must then enact specific laws implementing the
Directive. (The first URL below goes to the English language
version of the Directive; the second URL leads to versions in
other languages.)
<http://europa.eu.int/eur-lex/pri/en/oj/dat/2002/l_201/
l_20120020731en00370047.pdf>
<http://europa.eu.int/information_society/topics/ecomm/useful_information/
library/legislation/text_en.htm#dir_2002_58_ec>
Australia has also adopted an opt-in law broadly prohibiting
commercial email being sent to Australians. In short, while it
seems likely that most spam comes from the U.S. or is touting
products and services of U.S.-based companies, opt-in appears to
be the model of choice in most of the technologically developed
world, with the U.S. falling out of step with the rest of the
global community.
These conflicting approaches are likely to cause problems similar
to, and perhaps worse than, those that existed within the U.S.
before the federal law was passed, and when there were various
state statutes with differing mandates and standards. In the U.S.,
at least all of those states were subject to the same federal
government and general rules of legal analysis and interpretation.
On the international scene, the problems caused by such wildly
conflicting anti-spam models are likely to be worse. Since the
U.S. law is less restrictive, it appears to me that the E.U.
nations and Australia may continue to be flooded with spam that
is legal in the U.S., but illegal in their countries.
**Opt-Out Problems** -- The unfortunate choice of an opt-out model
requires that recipients contact the sender to opt out of future
messages. While this may work for legitimate marketers who
actually include a working unsubscribe mailto or Web link in the
message, most spam is not legitimate, and use such links merely
as unscrupulous means of confirming or harvesting email addresses.
By encouraging people to use these opt-out links, CAN-SPAM may
actually increase the amount of illegal spam. It also potentially
increases the risk of identity theft and other crimes targeting
the unsophisticated Internet user.
**Enforcement Problems** -- CAN-SPAM puts the entire burden of
enforcement on the shoulders of already overworked federal and
state enforcement agencies, which show no signs of rushing to
prioritize spam enforcement. It seems likely that ISPs will take
action, but most ISPs lack the resources to mount intensive
investigations to track down spammers in other countries, or
to support the sort of litigation that may be required to bring
them down.
To be fair, prior to CAN-SPAM, most enforcement had to take place
at the individual level, much of it in states without strong
anti-spam statutes. Most individuals can't afford the expense of
a full-fledged spam investigation any more than many ISPs can. But
CAN-SPAM does not permit individual victims to file private suits
for violating its terms. It seems counterproductive not to allow
individual enforcement since it would both aid in the overall
effort to combat spam, and would result in remedies to the actual
spam victims - the end users - in cases where the spammer could
be found and held accountable.
Lastly, even once spammers are dragged into court, CAN-SPAM may
suffer from loopholes. For instance, the "primary purpose" prong
of the spam definition means that spammers can include personal
notes in their messages that incidentally offer something for
sale, then argue that the solicitation was not the "primary
purpose" of the email. I suspect that most people reading this
have received spam along the lines of: "Hi there! How are you
doing? I am having a great time. By the way, I ran across this
item <insert product here> and thought you might be interested."
While this ambiguity may not pass the laugh test in court, it is
the sort of thing that will almost certainly have to be tested in
court before it has any appreciable impact, thus further delaying
any potential benefit until one of the authorized enforcers
chooses to put the question to a judge. This is another reason
that individual enforcement would have been a good thing - it
seems more likely that an individual or consumer group would take
up this issue sooner than I expect one of the authorized enforcers
to do it.
**Summing Up** -- In previous articles, I have concluded that if
spam is outlawed, only outlaws will spam. An increasing amount
of spam is already in violation of our current state laws and
has not been eliminated or even reduced as the result of having
been outlawed. Legitimate companies have attempted to comply,
but the less-than-legitimate scum will freely violate the new
law unless and until they are physically caught.
In the final analysis, CAN-SPAM is a good start, but is far too
flawed to be an effective tool against spam. Like the state laws,
it will successfully prevent legitimate companies from resorting
to spam (not that most legitimate companies were spamming before),
but it will have no impact on spammers outside of U.S.
jurisdiction and thus not subject to the U.S. law, or on
unscrupulous spammers who will ignore the law unless they are
arrested. The inconsistency with anti-spam laws used in other
parts of the world may harm those nations' efforts to control
spam by allowing spam from the U.S. to circumvent their laws.
Put bluntly, CAN-SPAM tells spammers that they can spam, so long
as they are careful to drive their truckloads of spam through
the truck-sized loopholes in the statute. What's perhaps most
disappointing is that we've waited for years for a federal anti-
spam law, and the one we ended up with isn't nearly as good as
it could have been, or even as good as some of the now-preempted
existing state laws are. That's a shame, and it's one we'll
undoubtedly have to live with for some time.
[Brady Johnson is a grouchy attorney in Seattle who really, really
hates spam.]
Hot Topics in TidBITS Talk/26-Jan-04
------------------------------------
by TidBITS Staff <[EMAIL PROTECTED]>
**AppleWorks international versions** -- It wasn't clear when
Apple released the latest AppleWorks update, but an international
version was also updated at the same time (though French is still
not updated) (2 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2145>
**Habeas under attack** -- Habeas is facing its first serious
test in the war against spam. Can they successfully sue spammers
who infringe their copyrighted and trademarked haiku headers?
(5 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2144>
**Apple creating a full audio product line** -- How will Apple's
recent audio applications (including announced, but not released
programs) affect how the company is received by consumers and the
audio community? (2 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2143>
**iPhoto 4 initial impressions** -- If nothing else, readers think
the speed improvements in iPhoto 4 are some of the best things
about iLife '04. (2 messages)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2142>
$$
Non-profit, non-commercial publications may reprint articles if
full credit is given. Others please contact us. We don't guarantee
accuracy of articles. Caveat lector. Publication, product, and
company names may be registered trademarks of their companies.
This file is formatted as setext. For more information send email
to <[EMAIL PROTECTED]>. A file will be returned shortly.
For information: how to subscribe, where to find back issues,
and more, email <[EMAIL PROTECTED]>. TidBITS ISSN 1090-7017.
Send comments and editorial submissions to: <[EMAIL PROTECTED]>
Back issues available at: <http://www.tidbits.com/tb-issues/>
And: <ftp://ftp.tidbits.com/issues/>
Full text searching available at: <http://www.tidbits.com/search/>
-------------------------------------------------------------------
