Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue

TidBITS Logo


RealNetworks may be poking a hornet's nest with its Harmony software, which enables customers to play music from the RealPlayer Music Store on iPods. Needless to say, Apple is not amused. Also in this issue, Joe Kissell shares advice on making attachments stick when using Apple's Mail software (and announces his new "Take Control of Email with Apple Mail" ebook), TidBITS rolls into the blogosphere with a new weblog, and we wish Steve Jobs a thorough and speedy recovery following cancer surgery this past weekend.


Copyright 2004 TidBITS: Reuse governed by Creative Commons license
<> Contact: <>

This issue of TidBITS sponsored in part by:


Steve Jobs Undergoes Cancer Surgery -- In an email message to Apple employees 01-Aug-04, Apple CEO Steve Jobs disclosed he had successful surgery to remove a cancerous tumor from his pancreas, and will be taking the month of August off to recuperate. In the meantime, Tim Cook - Apple's current head of worldwide sales and operations - will run Apple. Jobs identified his cancer as an islet cell neuroendocrine tumor, a rare condition which can be treated by surgical removal. He said his tumor was diagnosed early, and that he would require no radiation treatment or chemotherapy. Jobs did not have adenocarcinoma, the far more common (and more serious) form of pancreatic cancer. We wish him a speedy and complete recovery. [GD]


Apple Refuses to Sing with Real's Harmony

by Geoff Duncan <>

Last week a public shouting match erupted between Apple Computer and RealNetworks over what material can be played using Apple's iPod portable music players. RealNetworks develops the RealPlayer digital media player software, which competes with both QuickTime and Microsoft's Windows Media technologies. RealNetworks also operates the RealPlayer Music Store (a competitor to Apple's iTunes Music Store) and the Rhapsody subscription music service.


Duelling Divas -- The current brouhaha has some history. On 09-Apr-04, RealNetworks CEO Rob Glaser proposed a "tactical alliance" between RealNetworks and Apple, in which Apple would license the FairPlay digital rights management (DRM) technology used by the iTunes Music Store to RealNetworks. This would allow content purchased from Rhapsody and the RealPlayer Music Store to play on the iPod, which - then as now - commands the lion's share of the market for portable digital music players. In return, RealNetworks would make the iPod its "primary device" for its music services and player software. Glaser also waved a stick, hinting RealNetworks might convert over to Microsoft's Windows Media or approach other hardware vendors if a deal couldn't be reached with Apple.


Apple quickly declined RealNetworks' proposal. Apple already had the most popular portable player and the most popular online music service, and apparently felt staying on its current track was more beneficial than diverting effort into striking deals with smaller partners. Apple may also have felt RealNetworks' adoption of Windows Media was unlikely, given the rancorous legal history between RealNetworks and Microsoft.

Shouting Match -- On 26-Jul-04, the public silence between RealNetworks and Apple was broken when RealNetworks announced a new technology initiative dubbed Harmony. Among other things, Harmony purports to make material protected using non-Apple DRM technologies playable on the iPod. Harmony could be an important market advantage for RealNetworks. Currently, iPods can play back either unprotected files (e.g., ordinary MP3s) or content protected using Apple's FairPlay DRM system (like songs purchased from the iTunes Music Store). RealPlayer Music Store and the Rhapsody music service would have a competitive edge if they could claim their material works with Apple's iPod as well as a multitude of other devices from Sony, Rio, PalmOne, Gateway, Dell, and others. RealNetworks' DRM-enabled content would work on more than 70 portable devices, whereas protected material from iTunes Music Store would work on just one. RealNetworks' reasoning for Harmony is appealing: when people buy music online, they should be able to listen to that music on the portable player of their choice without worrying about file formats or copy protection. It should just work.


I'm not fully versed in the technical details of Harmony, but it's apparent RealNetworks did not create Harmony in conjunction with Apple. Instead, RealNetworks proceeded on its own, taking authorized material protected using non-Apple DRM schemes and wrapping it with Apple's FairPlay DRM for use on the iPod. Thus, when the iPod sees content a user purchased from RealNetworks, it plays transparently. This method works for material available via Rhapsody and RealPlayer Music Store because those services use the same AAC audio format as content from the iTunes Music Store (albeit at a higher bitrate: 192 Kbps rather than 128 Kbps). iPods have built-in support for AAC; Harmony does not alter the iPod software or give it the capability to handle new media formats.

Apple fired back sharply at RealNetworks on 28-Jul-04, saying it was "stunned that RealNetworks has adopted the tactics and ethics of a hacker" to enable its content on Apple's iPod, and warning that Harmony was unlikely to work with current and future iPods once Apple released new iPod software. In other words, Apple was angry, and would attempt to hamstring Harmony on the iPod as soon as possible. Apple also indicated it was investigating legal action, including possible violations of the Digital Millennium Copyright Act (DMCA). RealNetworks responded 29-Jul-04, re-affirming its commitment to Harmony and asserting the technology was both fully legal and developed independently.


Loud and Off-Key -- This dispute between Apple and RealNetworks touches on many nerves in the worlds of online music and digital rights management. Some people resent that Apple's iPod currently supports only a closed, proprietary DRM system, and many people would welcome the idea of playing music purchased from any source they like on the iPod, regardless of whether it comes from the iTunes Music Store or another service. Support for additional DRM systems might make the iPod even more popular, and - given the iPod's high margins - that would mean even more money for Apple. After all, Apple isn't yet earning much (if any) money from selling music via the iTunes Music Store: why would Apple care if people bought songs from another service, so long as they're played back on a profitable iPod?

On the other hand, part of the reason for the iPod's success is its tight integration with iTunes and the iTunes Music Store. By controlling the user's online music experience from browsing and purchase to synchronization and playback, Apple has created a best-of-breed solution. Supporting other DRM systems on the iPod - or licensing FairPlay to other online music services - means Apple would surrender both iTunes and the iTunes Music Store, two key components in Apple's digital music strategy. If another online music service (like Rhapsody) or another jukebox application (like RealPlayer) didn't support the iPod very well, that would diminish the market's perception of the iPod.

However, if Apple remains set against Harmony, it's not yet clear whether Apple has any practical recourse but to try pulling the rug out from under it via software updates, since Apple's claim that RealNetworks potentially violated the DMCA seems tenuous. First, RealNetworks has been in enough tooth-and-nail fights with Microsoft over the years to be able to afford quality legal advice - it's a safe bet a reasonable amount of homework was done before RealNetworks made a public statement. Second, RealNetworks' Harmony does not appear to be violating copyright of protected content, since it is not disabling DRM - protected content is still protected once it's transferred to the iPod. Third, Apple may have difficulty claiming its own copyrights were violated, since Harmony does not alter iTunes or the iPod's built-in software, and the DMCA contains specific exemptions for reverse engineering solutions for the purpose of interoperability.


No Fat Ladies Singing Yet -- Harmony may simply represent an escalation in RealNetworks' efforts to get its content onto the iPod and expand the utility of its Windows-only Rhapsody music service. The dispute also highlights the fact that Apple's current market-leading position in digital music distribution means the company will be forced to protect its business from competitors and dilution; in doing so, will undoubtedly take on tones and behaviors long-time Apple aficionados will find jarring. In fact, those tones and behaviors might be more reminiscent of a company which has long-dominated the operating system market: Microsoft.

Extra! Extra! Blog All About It!

by Adam C. Engst <>

Blogging is all the rage these days, with bloggers even receiving press credentials from the Democratic and Republican National Conventions. But until recently, I'd never quite seen the point in having a weblog, given that I have a full-fledged publication in TidBITS, and a moderated mailing list in TidBITS Talk. What could I want to say that I couldn't say in one of those two places? Quite a lot, it turns out.

A brief aside. Last week, those of you who receive the HTML edition of TidBITS know that our server initially sent you a blank email message instead of the issue, and later you received the text edition instead of the HTML edition. Geoff discovered the blank message problem around 10:30 PM for me (7:30 PM for him), and we spent the next two-and-a-half hours on the phone trying to figure out what had gone wrong and rectify it. Around midnight my time, after a few attempts at reconfiguration and resending the HTML edition failed, we tried sending the text edition (with an explanatory note to help defuse all the well-intentioned mail from readers telling us of the problem we already knew about), and that approach succeeded. Unfortunately, our efforts this week to determine why the trouble occurred and to fix it were unsuccessful; we couldn't see any reason the problem should have reared its ugly head. The entire process is highly automated, the automation has worked perfectly for years, and short of the particular words used in last week's issue (which shouldn't be a concern - the message format itself was structurally sound), nothing has changed in those systems. In short, we have to watch the sending process in person again this week to make sure the problem doesn't crop up again.

How is this related to blogging? Although we're not shy about documenting our systems here in TidBITS, we usually draw the line about telling you all about troubles we have with the servers or other things that go on unless there's a larger context (like this article!) into which to weave the report. We intentionally limit the length of TidBITS issues (to avoid overloading readers), and there's only so much room for infrastructure stories about how we valiantly protected our list server from a nefarious dictionary attack by a spammer, particularly when no readers were affected and when few people use the same aged hardware and software as we do (making it hard to draw broad technical lessons). At the same time, when a problem does occur, as with the delivery of the HTML edition last week, we don't have a good way of providing what is essentially a status report. And with the number of readers we have, answering email from everyone who writes in to alert us to a known problem (even with Eudora's boilerplate text feature) is time-consuming.

But status report-type postings aren't the primary reason we've become more interested in starting a weblog. Over the years, the TidBITS formula has gradually evolved into a couple of short bits about events of the week or particularly interesting product releases, anchored by two or three longer and more detailed articles. These articles generally require some time to write, and every one of them is edited by at least two of us before publication. That's great for ensuring accuracy and eliminating the last few typos, but it makes the entire process top-heavy, the end result being that we shy away from shorter, more informal bits that would feel awkward without additional context in an issue (brief opinion pieces in particular), that are amusingly unimportant, or that we simply lack the time or enthusiasm to flesh out sufficiently for an article. Ironically, given that blogging is considered to be a relatively recent development, that sort of writing is exactly what TidBITS started with fourteen years ago.

It is for these reasons that we've started ExtraBITS, in which TidBITS editors will wax blogosophic about the kinds of subjects you enjoy reading in TidBITS. The pieces will be shorter, breezier, and yes, less complete and exhaustively researched. They should be, in their own size and context, no less useful or enjoyable than our regular weekly content, just different. I anticipate them being more like the letters sent home (for publication in the local paper) from foreign climes by the correspondent of yesteryear. It's possible that a few of these ExtraBITS postings will grow into full-fledged articles that will later appear in TidBITS, but I suspect that will apply only to a small minority. I more see ExtraBITS as occupying a currently empty space between the formal publication approach of TidBITS and the discussion-driven TidBITS Talk.

Of course, there are other reasons I'm setting up ExtraBITS now as well. From the technical standpoint, although I'm sure there are many blogging packages to choose from, I'm using the Weblog plug-in for Web Crossing, which took me about five minutes to set up and integrates with everything else I'm doing in Web Crossing. It provides all sorts of niceties, such as support for RSS readers (even to the category level), the option to subscribe so you receive postings in email, and spell checking when posting. More important, it's the next step for me in becoming familiar with Web Crossing's low-level capabilities in preparation for the design of our content management system. Who knows, perhaps we'll even appropriate some of the now-commonly understood weblog interface elements in our final design.

For instance, one thing I want to look into for our content management system is the integration of article-specific comments with a mailing list, thus enabling people to post comments about an article and automatically have those comments both end up in mailing list threads and remain attached to the root article. That's roughly what we have working now with articles in our database and threads in the TidBITS Talk archive, but making the link between a thread and article requires the manual inclusion of an appropriate URL (usually by me, during moderation), making it an error-prone process.

Another potential benefit of ExtraBITS from my perspective, once it gets going, is increased traffic to our Web site overall, and particularly throughout the week (most of our Web traffic comes on Tuesday and Wednesday, decreasing throughout the week). Most of our current readers consider TidBITS an email publication, and while that won't be changing, it's difficult in these spam-ridden days to increase the readership of an email publication. By making our Web site more of a frequent destination, particularly in the weblog medium that has become so popular and heavily used, we hope to introduce more people to TidBITS as well.

Adding up all the benefits - a place for pieces that would otherwise go unwritten, a chance to learn more with Web Crossing's capabilities, experience with a slightly different publishing medium, and increased traffic to a more regularly updated Web site - I think ExtraBITS will be a winning combination. Check it out, complete with posts from the last week, at:


Working with Outgoing Attachments in Apple Mail

by Joe Kissell <>

I once worked for a company where a lot of the senior management (and, more importantly, their secretaries) still thought that internal communication revolved around printed memos. I often received email messages whose entire content was: "See enclosed memo." So I dutifully opened the attached documents in Word, where I invariably found a paragraph or two of text in the company's standard memo template that could just as easily have been typed (or pasted) directly into the email message. This backward approach to communication annoyed me mightily, because the senders' failure to use email properly forced everyone else to jump through hoops to read a simple message.

Enlightened email users (such as, I'm sure, most TidBITS readers) use attachments only when they add something one can't convey in the body of a message. But even our best efforts to use attachments wisely can be undone by uncooperative email programs. Apple Mail, despite its general ease of use, sometimes handles outgoing attachments in unexpected ways. You can make sure the vast majority of your attachments arrive intact for the vast majority of your recipients by following some simple guidelines, which I've excerpted from my latest ebook, "Take Control of Email with Apple Mail."

Always Include File Extensions -- Filename extensions never hurt, and they often help (even when your recipient is a Mac user). To make sure an individual file has an extension, select it in the Finder, choose File > Get Info, and look in the Name & Extension section. As far as Mail is concerned, it doesn't matter if a particular file has the Hide Extension option checked; as long as the extension exists, it comes through on the recipient's end. To save yourself the bother of checking each file (at the expense of slightly less beautiful file names), choose Finder > Preferences, click the Advanced button in the toolbar, and select the Show All File Extensions checkbox. That way you'll always know at a glance whether a file has an extension.

Always Use Windows-Friendly Attachments -- Sending attachments in "Windows friendly" format usually makes them friendlier for Macs too. The Windows Friendly Attachments feature has nothing to do with extensions and does not add them for you. So, what does it do?

By default, Mail assumes your recipient is also a Mac user and therefore includes the resource forks (if any) of attached files. Normally a Mac user sees such attachments as a single file, whereas a Windows user sees two individual files - one containing the data fork of the file and the other containing the resource fork.

When you choose "Windows Friendly" attachments, Mail strips the resource fork so that Windows users receive just one file, not two (one of which would be unusable anyway). In most cases - at least for files created with modern applications - all the crucial parts of files are in the data fork; as long as the filename has the correct extension and they have an appropriate application, Windows users can open the file.

The term "Windows Friendly" seems to imply that using this option makes your attachments "Mac Unfriendly." Mail's documentation reinforces this worry by stating that Mac users may be unable to open files correctly if the Windows Friendly option is used. But in practice, just the opposite is frequently true. The Mac version of Eudora, for example, sometimes cannot decode perfectly ordinary Mac files, such as Word documents, if they were sent without using the Windows Friendly setting. In other words, a wiser design might have been to make "Windows Friendly" the default behavior, with an option to make attachments "Mac Friendly" on those rare occasions when you truly must.

To tell Mail to use Windows Friendly encoding for all new messages, choose Edit > Attachments > Always Send Windows Friendly Attachments. (Although this command appears on a menu, it's actually saved as a preference.) Oddly, this command is disabled when composing a new message.

You can also toggle Windows friendliness for individual messages: When you attach a file using the Attach button on the toolbar or by choosing File > Attach File (Command-Shift-A), notice the checkbox at the bottom, Use Windows Friendly Attachments. If it's selected, all the attachments for this particular message are sent in Windows Friendly format. Unfortunately, Mail offers no convenient way to toggle Windows friendliness for attachments added to your message by drag & drop or copy & paste.

When a Problem Comes Along, You Must Zip It -- If file extensions and Windows friendliness still result in attachments the recipient can't read, try compressing them (the files, not the recipients). Zipping covers a multitude of sins by wrapping up one or more files - including resource forks, if any - in a compact, cross-platform-compatible package. Under Panther, you can compress a file or folder in the Finder (in Windows-friendly Zip format) by selecting it and choosing File > Create Archive of <filename>. Of course, StuffIt Deluxe and StuffIt Standard Edition can also create the protective Zip or StuffIt archives as well.


Sending Graphical Attachments -- When you attach a graphical image to your message, the recipient of your message sees the image inline (that is, in the body of the message) if her email client supports inline display. ("Take Control of Email with Apple Mail" contains a table listing the capabilities of popular Mac and PC email clients.) If a client does not support inline display (or the recipient has turned off the inline display option), the file appears as an attachment that must be opened in a separate program.

On the one hand, an inline image is easier for the recipient to see - all she has to do is look at it. On the other hand, inline images can be frustrating to scroll through. If you do not wish to send a graphical image inline, you must compress the file before attaching it - Mail, sadly, lacks a built-in compression option, though fortunately for Panther users, the Finder offers Zip compression without requiring a separate application.

Note that when you compose a new message, Mail always shows attachments in the body of your message. You can manually drag them somewhere else, but many email clients display all attachments in a separate list, regardless of where you place them in the message body.

If you paste an image into a message or drag & drop an image from another window (say, a Web browser), Mail converts the raw image data to an attachment in TIFF format. On the other hand, if you drag & drop the icon of an image file (or use the Attach button to locate the file using the file browser), Mail leaves the attached image in its original format. This difference is significant, because although most email clients can display JPEG images just fine, support for TIFF - especially in non-Mac email clients - is less common. If possible, I suggest attaching image files as opposed to pasting or dragging in raw image data.

Take Control of Email with Apple Mail -- As much as I like Mail, it has quite a few other quirks and frustrations - ranging from misleading error messages to seemingly missing features. After experiencing many of these problems myself and reading literally thousands of reports of others struggling with the same things, I set out to determine what's really going on behind the scenes. In my 89-page "Take Control of Email with Apple Mail" ebook, I explain why Mail works (or doesn't work) the way it does and how you can solve many of the most common Mail problems. Even if Mail is working perfectly well for you, you'll learn how to use it more effectively. "Take Control of Email with Apple Mail" costs $10, or you can purchase it along with "Take Control of Spam with Apple Mail" (ordinarily $5) for a total of $12.50. As with all Take Control ebooks, purchasers are entitled to receive all minor updates for free.


[Joe Kissell is a San Francisco-based writer, consultant, and Mac developer who kicked off the Take Control series with the best-selling "Take Control of Upgrading to Panther." When not solving Mac problems, he gives guided tours of the rest of the world on his Interesting Thing of the Day Web site.]


Take Control Pricing Thoughts

by Adam C. Engst <>

With Joe Kissell's "Take Control of Email with Apple Mail," you'll notice that we set the price at $10 - as we had done for Glenn Fleishman's "Take Control of Sharing Files in Panther" - instead of the introductory $5 price point we have used for most of our other ebooks. We had a number of reasons for the change, including:

As I noted when I first wrote about the Take Control project, we intended $5 as an introductory price, and one that we would reevaluate once we had learned more about the business side of the venture. It's still too early to make any categorical statements about pricing, but $10 seems appropriate for books that are closing in on the 100-page mark and that we anticipate growing even more with free updates.


Note that we've made it trivially easy for anyone concerned with price to save 10 percent on their next order, simply by clicking the Help a Friend button on the cover of the current version of any ebook and recommending that ebook to a friend (who also saves 10 percent). Oddly, even though thousands of people have presumably seen that button, only 11 have taken advantage of the discount. (If there's a problem with the Web pages that handle the referral, let me know, since it was the first programming I ever did in Web Crossing.) Also, all user group members are entitled to 10 percent off any Take Control order; nearly 150 user groups currently receive the discount and free review copies of our ebooks.

We're in this for the long run, and we have a number of new ebooks and other projects in the works that we think you're going to like a lot. But as with all businesses, we have to make sure that we can earn sufficient income to afford to carry out those plans. Thanks for all the support you've given us so far, and we certainly plan to continue producing ebooks worthy of your support.


Non-profit, non-commercial publications and Web sites may reprint or link to articles if full credit is given. Others please contact us. We do not guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. TidBITS ISSN 1090-7017.

Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue