TidBITS: Apple News for the Rest of Us  TidBITS#818/27-Feb-06

最近の Mac OS X セキュリティ脆弱性のゴタゴタは、天才的クラッカーの業なのか、それとも単に Mac OS X がアプリケーションと書類ファイルを対応付けする方法に欠陥があるだけと考える方がよいのか? Geoff Duncan が Safari への最近の攻撃について検討し、Matt Neuburg は我々がなぜこのような状況に陥ってしまったのかについて解説する。また今週号では Adam が iPhoto 6 を詳しくレビューし、その昔 Macintosh 伝道師であった Guy Kawasaki についての最新情報をお伝えし、それから iTunes で販売された曲数が 10億曲を突破したという Apple の発表についても簡単に検討する。

記事:

Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: <[email protected]>


本号の TidBITS のスポンサーは:


MailBITS/27-Feb-06

Apple スペシャルイベントのニュース -- 今週号の発行日は 2006 年 2 月 28 日の Apple メディアイベントの一日前となっている。力を込め過ぎてキーボードが壊れるまで予想を書き綴ることもできるのだが、それは止めにして、代わりに Steve Jobs の発表が行なわれるまでおとなしく待って、その後間もなく ExtraBITS でその内容を報告させて頂くことにしたい。[JLC](永田)

<http://www.tidbits.com/extrabits/>


iTunes Music Store、10 億曲の販売を達成

文: Adam C. Engst <[email protected]>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

今度 Cupertino に行った時には、ハンバーガーの通算販売数を大々的に宣伝したあの McDonald's の看板を真似て Apple も iTunes Music Store での通算販売曲数を宣伝しているのではないかと、私は注意して見てみるつもりだ。もしも今そういう看板が存在していたとしたら、この 2006 年 2 月 23 日をもってそこにもう一桁数字を追加しなければならないところだったろう。この日、iTunes Music Store では記念すべき one-billion 番目の曲が販売されたのだ。(念のため、これはアメリカの billion の単位であってイギリスの billion の単位ではない。まあ、常識的にお分かりだろうとは思うが。つまり、10 億曲目ということになる。)

<http://www.apple.com/pr/library/2006/feb/23itms.html>(日本語)iTunes Music Storeのダウンロード件数10億曲を突破
<http://www.askoxford.com/asktheexperts/faq/aboutwords/billion>

10 億曲目となったのは Coldplay のアルバム X&Y に収録されている“Speed of Sound”で、購入したのは、ミシガン州 West Bloomfield に住む Alex Ostrovsky だった。丁度うまい瞬間に iTunes の Buy ボタンをクリックした見返りに、Alex は 20 インチの iMac を 1 台と、第五世代の iPod を 10 台、それに $10,000 相当の iTunes Music Store ギフトカードを特賞として受け取った。(この人が壇上でベニヤ板サイズの iTunes Music Store ギフトカードを贈呈されている姿がありありと私の脳裏に浮かんでいる。)Apple はさらに、10 億件目の販売を記念して Alex の名で Juilliard School of Music(ジュリアード音楽院)に奨学金制度を設けた。

Apple の記念碑的瞬間を報告したプレスリリースは二重の意味で興味深い。そこには、その時点での iTunes Music Store 売上げの内容に関する情報も書き加えられていることが多いからだ。(Wikipedia にはこの種の情報の多くが集められているようだが、売上げのグラフ表示もあればもっといいのにと思う。)例えば、iTunes Music Store はこれまでに 1,500万本以上のビデオを販売しており、現時点でおよそ以下のようなものを提供している:

<http://en.wikipedia.org/wiki/ITunes_Music_Store> (日本語)ITunes Music Store - Wikipedia


Guy Kawasaki が復帰したぞ!

文: Adam C. Engst <[email protected]>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

年月が経って Macintosh も成熟の度を深めるにつれ、他所の世界に踏み出して行った人たちも多く、そのため Mac の世界は寂しくなったとも言える。でも、ここに一人、その昔にお馴染みだった懐かしい顔が、最近またそこここで見られるようになってきた。彼の名は、元 Apple エヴァンジェリスト(伝道師)の Guy Kawasaki だ。Guy はベンチャー起業基金の Garage Technology Ventures の専務取締役として働いており、San Francisco の Macworld Expo では神出鬼没で FilmLoop を皆に広めて回っていた。私たちのコミュニティーの中でまた彼の顔を見られるようになったのはとても嬉しいことだったし、それに 2005 年の年末になって始まったブログのお陰で、彼はまた公の場に登場してくれたようだ。

<http://blog.guykawasaki.com/>

“Just Another Blog”ぶっている(見出しに「ブロガー[名詞]:何もすることのない人のために物を書く何も言うことのない人」とある - アイタタ!)のも昔からの Guy 流だが、実際は「ただのブログ」どころではなく、ここには“The Macintosh Way”で一世を風靡した時代以来彼が本の中で書き綴ってきた類いの実際的な知恵が満ち満ちている。彼の最近の本でベンチャー起業系統の視点からの考え方が強くなってきている(例えば“The Art of the Start”“Rules for Revolutionaries”“How to Drive Your Competition Crazy”といったタイトルを見るだけでもそれがわかるだろう)のは言うまでもないが、それでも読んで楽しく、洞察力に満ちていて、新しいプロジェクトを始めようという人や、プレゼンテーションをしようという人、あるいは人よりも一歩先んじるにはどうすればよいかと悩んでいる人なら誰でも、得難い知恵を吸収できること請け合いだ。Guy のブログに出ている文章も、これと同じく高い品質に輝いており、ブログのフォーマット自体も、彼のアイデアのいくつかをより効果的にプレゼンテーションできる方法となっているとも言える。なぜなら、このブログは少しずつの文章が定期的に書き加えられていく形式になっているからだ。私は Guy の本が大好きだが、彼の本を読むといつも私は彼のアイデアがどれか気に入ってそれを実現しようと一生懸命になり、結局自分自身いつの間にか何かのプロジェクトに首まで埋まって、最後には私が当初心に描いていたものとは全然違うことをしているという具合になる。きっと、Guy のブログから始終刺激を受け続けているために、私の考えも行動も、知らぬ間に影響を受けているのだろう。

(Macintosh の世界に来てからまだ日が浅いし、そもそも Guy Kawasaki なんて名前は聞いたこともない、とおっしゃる方は、まあ騙されたと思って“The Macintosh Way”を手に取って読んでみて頂きたい。Amazon の古本市場なら $5 ほどで手に入るし、ブログには彼の著書のすべてへのリンクがある。)

Guy の得意分野の一つは、コミュニティー構築だ。彼はずっと変わらず Apple 社内でユーザグループの支援者だったし、事実私が San Francisco の Macworld Expo の開幕前日に彼とお喋りしたのも User Group University での私たちの講演の合間のことだった。(この講演の聴衆は皆ユーザグループのリーダーたちだった。)その時私は Chris Breen と Bob LeVitus と共に、ユーザグループに再び活気を取り戻し、新しい時代に即して生き残るためにはどうすればよいかという話題で講演を終えたばかりだった。そのこともあって、私はコミュニティー構築についての Guy の最近の文章を興味深く見守っている。彼の論点はとてもよく的を得ているし、ユーザグループに興味のある人、あるいはとにかく人を集めたいと思っている人にも、きっと役に立つものになると思う。

<http://blog.guykawasaki.com/2006/02/the_art_of_crea.html>


Safari に深刻な脆弱性発見される

文: Geoff Duncan <[email protected]>
訳: 羽鳥公士郎 <hatori@ousaan.com>

Apple の Safari ウェブブラウザについて、深刻なセキュリティホールになりかねない脆弱性が発見された。ユーザがただウェブサイトのリンクをたどるだけで、攻撃者が任意の Unix シェルスクリプトをユーザのマシン上で実行できるというものだ。執筆時点では、Apple からのコメントは得られておらず、パッチもリリースされていないが、さしあたって、Safari ユーザに対しては、Safari 環境設定の「一般」パネルで「ダウンロード後、"安全な" ファイルを開く」のチェックをはずすことを強く勧める。(実際、すでに 2005 年5 月、Dashboard ウィジェットに関連した脆弱性が発見されたときに、このチェックをはずすようお勧めしていた。)

[訳注: 日本時間の 2006 年 3 月 2 日に、この脆弱性やそのほかの脆弱性を修正する Security Update 2006-001 がリリースされました。]

<http://db.tidbits.com/getbits.acgi?tbart=08119>(日本語)Apple、Tiger がまだ熱いうちに 10.4.1 をリリース

この脆弱性の根底には、特定のタイプの書類をどのプログラムで開くのかをMac OS X が決定する方法が関わっている。Mac OS 9 では、ファイルのリソースフォークに4文字のクリエータコードが格納されていて、それを使ってアプリケーションとファイルとを関連付けていた。Mac OS X では、アプリケーションとファイルとの関連付けは、より難解な、メタデータとファイルの拡張子を組み合わせたシステムに変わった。そこで、Unix シェルスクリプトのファイル名を変更して「安全な」拡張子(.pdf や .jpg など)にし、ファイルの実行ビットを立て、Zip 圧縮ユーティリティで圧縮しておくと、Safariは喜んでそれをダウンロードし、解凍し、スクリプトが「安全」なファイルであると思い込んで、のんきに Mac OS X の ターミナル アプリケーションに渡してしまうので、スクリプトが実行される。これにより、攻撃者は、ユーザのホームディレクトリをすべて消去するスクリプトや、コンピュータの設定を破壊するスクリプト、あるいは個人情報を手に入れるスクリプトなどを、簡単に実行することができる。(詳しくは、今週号の Matt Neuburg の記事 "ファイルとフォークと不安と" 参照)。

ほかのプログラムも同様の攻撃を受ける可能性はあるが、現在分かっている限り、この攻撃を受けるウェブブラウザは Safari だけだ。Camino と Firefoxの両ウェブブラウザは、この攻撃に対して安全だ。

デンマークのセキュリティ関連会社 Secunia は、この脆弱性を「きわめて深刻」としており、ユーザが、自分のシステムが攻撃を受ける可能性があるかどうか判定するための、無害なサンプル攻撃ファイルを公開している。Heise Online も同様の攻撃デモファイルを公開している。

<http://secunia.com/advisories/18963>
<http://secunia.com/mac_os_x_command_execution_vulnerability_test/>
<http://www.heise.de/security/dienste/browsercheck/demos/safari/Heise.jpg.zip>

この攻撃から身を守る方法としては、ターミナル アプリケーションを、デフォルトの場所である アプリケーション > ユーティリティ から別の場所に移動するというものもある。(ただし、そうすると、将来システムをアップデートするときに混乱が生じるおそれがあるので、新しいソフトウェアをインストールする前に、元の位置に戻しておくことを忘れないようにする必要があるだろう。)

Mac OS X 10.4.5 を新規インストールしたとき、デフォルトでは、Safari の「ダウンロード後、"安全な" ファイルを開く」のチェックははずれているから、多くのユーザは、デフォルトのままでも、この攻撃を受けないかもしれない。しかし、Mac OS X 10.4.5 を使っているからといって、必ずしも安全だとは言えない。それ以前のバージョンのシステムから Mac OS X 10.4.5 にアップデートした場合、Safari の「ダウンロード後、"安全な" ファイルを開く」にチェックが入ったままになるという例が確認されている。したがって、安全のためには、どのバージョンの Mac OS X を使っているかにかかわらず、このチェックがはずれていることを確認するとよい。


ファイルとフォークと不安と

文: Matt Neuburg <[email protected]>
訳: 羽鳥公士郎 <hatori@ousaan.com>

TidBITS 読者の皆さんは、冷静で理性的だろうから、この一週間、世間の耳目を集めるべく繰り広げられた、Mac OS X に最近見つかったいくつかのセキュリティホールに関する FUD(fear, uncertainty, and doubt)の波にさらわれることはないだろうと信じるが(詳しくは、今週号の Geoff Duncan の記事 "Safari に深刻な脆弱性発見される" 参照)、マスメディアは、いつものように、歴史的展望と技術的詳細とを「報道する」という使命をかなぐり捨て、言葉にならない叫び声と意味的に何ら変わるところのない「Mac OS X にウイルス!」というようなセンセーショナルな見出しを掲げ、その後には、お決まりのように、私利私欲を追求する企業の、不安を煽動するプレスリリースが続いた。ここは一つ、誇大広告には取り合わず、事実を見つめよう。

ヒラケゴマ -- ここで考えるべき事実のほとんどは、Mac OS X が書類とアプリケーションとを関連付けている方法に関わる。Finder で書類を見ると、アイコンが見えるわけだが、このアイコンは、その書類を開くアプリケーションが提供している。書類をダブルクリックすれば、そのアプリケーションが立ち上がり、書類を開く。この関連付けはどのように管理されているのだろうか。

Mac OS 9 以前にさかのぼると、この関連付けは、ファイルシステムに不可視の形で格納されたメタデータを使い、不可視のデータベースを探索することで実現されていた。Mac OS X の出現とともに、Apple はこのアーキテクチャの置き換えに着手し、ファイル名のピリオドの後に現れる(非表示にすることもできるが)あの目障りなファイル拡張子を導入するとともに、関連付けられるアプリケーションを特定するために、様々な方式を複雑に組み合わせた。

<http://db.tidbits.com/getbits.acgi?tbart=05415>(日本語)Mac OS X それとも Mac OS NeXT?
<http://db.tidbits.com/getbits.acgi?tbart=06584>(日本語)Mac OS X 10.1: 主な機能
<http://arstechnica.com/reviews/os/metadata.ars/8>

こうして Apple は、書類・アプリケーション間の関連付けをエレガントに実現していた、信頼でき(ときには関連付けが壊れて「デスクトップの再構築」が必要になることもあるが)ユーザには隠されていた方法を捨て、ほかのシステムがそのようにしているからというだけの理由で、ファイルタイプをファイル名に含めるという、醜悪で、しばしば予期せぬ挙動をする方式に置き換えた。ただし、以前の方式が完全に置き換えられたというわけではなく、新旧の方式が、ジキル博士とハイド氏とを協調させるがごとく、不恰好に組み合わされている。何しろ、Mac OS X 以前の時代から生き残っているファイルには、ファイル名に拡張子があるとは限らないからだ。そのため、1つのファイルに、タイプ・クリエータのメタデータがあることもあるし、ファイル名の拡張子があることもあるし、その両方があることもある。

ところが、それで話は終わらない。一般的なファイルタイプ、例えば .pdf について考えてみよう。.pdf ファイルは、プレビュー でも Adobe Reader でも開くことができる。では、どの .pdf ファイルをどちらのアプリケーションで開けばよいのだろうか。ユーザは、ファイルを Dock か Finder のアイコンまでドラッグすることで、望みのアプリケーションで開くことができるが、それは一度限りの解決法だ。ファイルを特定のアプリケーションに _割り当て_ て、Finder でダブルクリックしたときに _常に_ そのアプリケーションで開くようにしたいと思ったら、どうすればよいだろうか。

私には理由が全く分からないのだが、Mac OS X は、この状況に対処するのに、タイプ・クリエータのメタデータを使わない。その代わり、Apple は、リソースフォークの中に特別な場所、'usro' リソースを用意して、ユーザが設定したファイルの関連付け情報を格納するようにした。したがって、Finder の「情報を見る」ダイアログで、「このアプリケーションで開く」ポップアップメニューを操作すると、実際には、そのファイルの 'usro' リソースを設定することになる。ということは、あるファイルが、リソースフォークに 'usro' リソース、メタデータにクリエータコード、ファイル名に拡張子と、3つすべてを同時に備えるということもあり得る。

<http://db.tidbits.com/getbits.acgi?tbart=07516>(日本語)Mac も 20 歳: Bruce Horn との対談

攻撃の構造 -- 今回明らかになった問題は、これらの情報を悪用することによって、矛盾を引き起こすことが可能だということだ。その矛盾こそ、最近見つかったセキュリティホールの急所である。Heise が作成したデモファイルをダウンロードして解凍すると、最終的にはシェルスクリプトコマンドを含んだテキストファイルになるのだが、このファイルの拡張子は .jpg で、'usro' リソースに悪意ある仕掛けが施してある。書類のアイコンは拡張子によって決まる(私のマシンでは、プレビュー が提供する JPEG アイコンになる)が、'usro' リソースは、全く別のアプリケーション、ターミナル と関連付けられている。Finder の「情報を見る」ダイアログを見れば、このファイルが確かに ターミナル 書類であることが分かるだろう。

<http://www.heise.de/security/dienste/browsercheck/demos/safari/Heise.jpg.zip>

このような不一致が可能だということは、おそらくはシステムのバグと言うべきだろう。理論的には、システムは 'usro' リソースが不正であることを検出できるはずだ。私が試したところでは、ユーザがクリエータを割り当てたとき、ファイルには、'usro' リソースのほかに、'icns' リソースが加えられ、そのラベルが "Binding Override" となっていることが分かった。これはおそらく、新しく割り当てられたクリエータから提供される書類アイコンであることが意図されているのだろう。例えば、GraphicConverter の JPEG アイコンは、プレビュー の JPEG アイコンとは異なっている。しかし、ターミナルは JPEG ファイルを開けないのだから、ターミナルに JPEG アイコンは存在しない。加えて、攻撃者はターミナルに、このファイルを JPEG ではなくテキストとして処理させる必要がある。そこで、Heise のファイルには、'icns' リソースが存在しない。システムはこれを検知して、何かがおかしいと警告するべきだ。

空騒ぎ -- この脆弱性に .zip ファイルが関わっており、.zip ファイルをコンピュータ上で解凍することによって不正な書類が生成されるというのは事実だが、それは問題ではない。確かに、この書類は StuffIt Expander か Apple 自身のアプリケーション BOMArchiveHelper で解凍されるが、これらのアプリケーションは、この物語では大した役を果たしていない。ただ単に、ファイルを最初に手渡され、それを正しく処理し、結果として解凍されたファイルが不正だったというに過ぎない。.zip ファイルが、本質的に特殊な形式であるというのも事実だが、それはリソースフォークを備えたすべてのファイルに等しくあてはまることだ。

この話で Safari が果たしている役割も、過度に強調されるべきではない。Safari の「ダウンロード後、"安全な"ファイルを開く」設定がオンになっていれば(そうするべきでない理由は数多くあるが)、Safari がダウンロードされたファイルを実際に2度開いてしまうというのも事実だ。1度は解凍するために、そしてそれが全く安全な .jpg ファイルだと誤認してもう1度。しかし、実際のところ、これは、_あなた_ が Finder でするであろうこと、つまり .zip ファイルをダブルクリックして、さらに .jpg ファイルをダブルクリックすることと、何ら変わりがない。

Apple の Mail も、Finder と同じ問題を抱えていることが分かっている。つまり、このファイルが電子メールの添付書類として送られてきたとすると、Mail は JPEG アイコン(.jpg 拡張子に加え)を表示するが、それがダブルクリックされると、ファイルを ターミナル で開いてしまう。しかし、これは Finder の挙動と全く同じで、ただ表示の文脈が異なるだけだろうと思われる。

最後に、問題のファイルが実行可能ファイルであるという事実に関連して、誤解を招くようなことが語られている。このファイルはシェルスクリプトであって、実行パーミッションが設定されているので、ターミナル で開けばスクリプトが実行される。そのような、ダブルクリックすることで実行できるシェルスクリプトが存在するということは、何ら目新しいことではない。どんなテキストファイルでも、.command という拡張子を付け、実行パーミッションを設定すれば、ダブルクリックしたときに ターミナル で実行される。今までもずっとそうだった。(そうなっているべきではないと議論するのは理にかなっているし、この事実があまり知られていないというのも問題だが、それは別の話なので、後で触れる。)また、実行可能ファイルを圧縮してやりとりできるという事実も、目新しくはない。そうでないとしたら、アプリケーションを圧縮して送信するということができなくなってしまう。このファイルに「シバン行」がないという事実を強調する人もいるが、それは筋違いだ。この攻撃は、シバン行があろうとなかろうと、同じように成功する。

結論 -- 私の結論は2つだ。どちらもつきつめれば、Iago [訳注: シェイクスピア『オセロー』の登場人物] が人間について語ったように、コンピュータファイルは「見かけ通りのものであるべきだ。そうでないものなど、いなくなってしまえ」ということに尽きる。

第1に、Mac OS X の複雑な書類・アプリケーション間の関連付け方式は、決して正当化することができないし、今や、この方式にバグがあることが明らかになった。Apple は直ちにこの問題を解決し、それによって、ファイルが常に見かけ通りのものであるようにする必要がある。

第2に、実行可能ファイルは、Cocoa アプリケーションバンドルから、低レベルの実行可能シェルスクリプトにいたるまで、どんな種類のものであろうと、極めて特殊な種類のファイルなのであるから、そのように表示される必要がある。読むべきデータと、実行するべきコードは、どちらもファイルだとはいえ、根本的に異なった種類のファイルであって、実行可能ファイルの表示と挙動は、特別であるべきだ。どんなファイルでも、ただ開くだけでコードとして実行されるものには、それと分かるように、目立つ「バッジ」をつけるべきだ。すべての実行可能ファイルについて、初めて実行されるときに警告するというのも有効だろう。Apple は、URL スキームの大失敗の後、まさにそれと同じようなものを導入した。あるアプリケーションを、書類をダブルクリックすることで初めて開くとき、警告が発せられる。しかし、それ以上には進まなかった。実行可能ファイル自体を最初に開くときには、警告はでない。しかし、今回明らかになったことは、ファイルが実行可能で ある ということに、ユーザが気がつかないことがあり得るということで、そこにすべての問題があるのだ。Apple の修正によって、実行可能ファイルを JPEG と取り違えてしまうというようなことがなくなるならば、この世界はさらに安全な場所になるだろう。


iPhoto 6: 素晴らしいが、革新的というほどではない

文: Adam C. Engst <[email protected]>
訳: 羽鳥公士郎 <hatori@ousaan.com>
訳: 亀岡孝仁 <takkameoka@bellsouth.net>

私にとって、iPhoto ほど、その機能になじみのあるプログラムは、ほとんどない。それというのも、私の本 "iPhoto for Mac OS X: Visual QuickStart Guide" を執筆するため、毎年のように一つ一つの機能を徹底的に調べているからだ。そのため、Steve Jobs が iPhoto の新しいバージョンを発表するとき、どんなデモをするのか、いつもとても楽しみにしている。直近のMacworld Expo San Francisco の基調講演で、iPhoto 6 が発表されたときも、彼のデモを楽しんだ。しかし、新しい機能を試すのは本当にワクワクするのだけれど、iPhoto に古くからあるイライラを Apple が修正したかどうかを確かめるというのにも、同じように興味津々だ。ここ最近のバージョンアップは、イライラ解消という点ではあまり目立ったことはなかったが、うれしいことに、iPhoto 6 はイライラの4つに取り組んでいる。ただし、残念ながら2つは取り残され、新しい頭痛の種も1つ加わってしまった。それはさておき、まずは、iPhoto 6 のいかした新機能を見てゆこう。それらは、編集と共有の2つのカテゴリーに、大きく分けることができる。

<http://www.apple.com/ilife/iphoto/>(日本語)アップル - iLife - iPhoto

編集機能の改良 -- 従来、iPhoto には、写真を編集するためのモードが3つあった。表示パネル、別ウインドウ、そして Photoshop Elements のような外部エディタだ。Apple はこのコレクションにもう1つ、フルスクリーン編集を追加した。これを使うと、iPhoto のインターフェースはすべて隠れ、編集中の写真が、画面に収まる最大の大きさで表示される。画面上部にはサムネールパネル、画面下部にはツールバーパネルが現れるが、どちらも、Dock で「自動的に隠す」をオンにしているときと同じように、自動的に現れたり隠れたりする。フルスクリーン編集を、画像をダブルクリックしたときのデフォルトの動作として割り当てることもできる。iPhoto のインターフェース要素は、画像のために使った方がよいスペースをとりすぎていていると感じられることもしばしばだったし、編集用の別ウインドウは、サイズと位置を覚えてくれないから、フルスクリーン編集は大変歓迎すべき機能だといえる。

フルスクリーンモードでは、なじみのあるインターフェースに変更が余儀なくされたところがある。例えば、「情報」ボタンをクリックすると、半透明の「情報」パネルが現れる(通常の「情報」パネルを表示する場所がどこにもないからだ)。スクロールバーもないため、画像を拡大したときは、半透明の「ナビゲーション」パネルが現れ、それで画像のスクロールをする(ただし、スクロールホイールで上下にスクロールすることもできるし、Shift を押せば左右にもスクロールできる)。フルスクリーン編集について、私が不満に感じるのは、画像がフルスクリーンで表示されるのに時間がかかるということだ。私の Dual 1 GHz Power Mac G4 で、メインウインドウの表示パネルでは編集を始めるまでに2秒かかるのに対し、フルスクリーンモードでは4秒ほど待たなければならない。さらに、2つのモニタを使っていて、誤ってフルスクリーン表示の外側をクリックしてしまうと、iPhoto は、変更を保存することなく、即座に整理モードに戻ってしまう。

「調整」パネルは iPhoto 5 から変更がないが、新しい「エフェクト」パネルに、3列×3行のボタンが並んでいる。「白黒」ボタンと「セピア」ボタンがここに移動したほか、編集中の写真に適用できる新しいエフェクトが6つ、そして9番目のボタンは、画像を編集前の状態に戻す。「アンティーク」エフェクトは、「セピア」エフェクトによく似ているが、それほど彩度が変わらず、上品な感じだ。「色を弱める」と「色を強める」のボタンは、「調整」パネルの「彩度」スライダを操作するのと似て、色を薄くしたり濃くしたりする。一番下の段に並んでいる3つのボタンはどれも、画像を楕円形にマスクし、画像の中心部がそのまま見えるようにする。「マット」は白いマスク、「ビネット」は黒いマスクを適用し、「エッジをぼかす」では、マスク部分の画像がぼかされる。これら「エフェクト」パネルのボタンは、「白黒」「セピア」「現在」を除けば、何度か繰り返しクリックすることで、適用の度合いを強めることができる。異なるボタンをクリックしてエフェクトを組み合わせることも可能だ。例えば、写真をセピア調にして、色を薄くし、ビネットマスクを適用することもできる。これらの新しいエフェクトを、私が実際に使うようになるかどうかはまだ分からないが、Apple がこれらのエフェクトを Photo Booth に全く含めなかったのは、ちょっとした驚きだ。また、Mac OS X の Core Imageエフェクトを iPhoto で使えるようにする方法を、誰か見つけてくれないかと願っている。BeLight Software のフリーウェア ImageTricks にその機能があるが、これは独立したアプリケーションだ。

<http://www.belightsoft.com/products/imagetricks/overview.php>

これら3つの半透明のパネルが加わったことで、新たな頭痛の種が生まれた。パネルを透かして下の画像が見えるとはいえ、やはりパネルは邪魔になるから、2つ目のモニタがあれば、そちらの方に置いておきたいと考えるだろう。そこで2つ目のモニタに移動すると、iPhoto は起動しているあいだ、その位置を覚えておいてくれるが、いったん終了すると、次に起動したときには、「エフェクト」パネルと「調整」パネルについて、困ったことに位置を忘れてしまう。

フルスクリーンモードには、もう1つ、大変歓迎すべき重要な機能がある。最大8枚までの写真を、1度に表示して比較できるのだ。フルスクリーンモードで「比較」ボタンをクリックすると、現在表示している写真の隣に、次の写真が、それぞれ最大の大きさで表示される。整理モードで、最大8枚までの写真を選択してから、フルスクリーンボタンをクリックすると、iPhoto はフルスクリーンモードに切り替わって、すべての写真を最大の大きさで表示する。その1つをクリックして、矢印キーを使って、現在表示されていない次の画像や前の画像を表示することもできるし、さらに興味深いことに、それぞれの画像に対してすべての編集ツールを使用でき、Delete キーを押せば現在の画像を消去することもできる。このように画像を比較するのは、写真を取り込んだ後、それを見渡して、どれを残すべきか判断するのに、とても役に立つ。カメラの連写モードで速い動きを撮影したときなどに使うと、特に効果的だ。

共有するのはよいことだから -- もう1つ、Apple が iPhoto を大幅に改良したのは、写真を共有するための様々な方法についてだ。当初から iPhoto の看板機能だったフォトブックも改善され、新しいテーマが加わり、印刷の品質も向上し、価格は低下した。ブックを作成しているときに「再生」ボタンをクリックすれば、スライドショーとして表示することができる。しかし、本当に素晴らしいことは、ブックから派生して、2つの新しい印刷形式、カードとカレンダーが誕生したことだ。どちらも、レイアウトの方法は、ブックとほとんど同じだ。

カードには、2つ折りのグリーティングカードとポストカードと、2つの形式がある。グリーティングカードでは、表紙に画像を1つ配置し、内側のパネルのいずれか1つに文章を書く。ポストカードは片面に画像が1つ、もう片面には、通常のテキストブロックか、住所と切手のための標準的な枠のいずれかを置くことができる。これらを作成するのは、ご想像の通り簡単だ。どの画像を使うのか選び、テキストを入力し、フォントを選ぶ(デフォルトを変更したければ)ことしかできない。どちらにも、様々なデザインや背景が用意されている。価格は、カードの種類や注文する枚数により、1枚あたり 1 ドルから 2ドルのあいだだ。

カレンダーはもっと自由が利く。もちろんたくさんのテーマがあり、それぞれのテーマにたくさんのページデザインがあるし、それぞれが表示する写真の枚数によって変化する。それぞれの日付の上に写真をドラッグすることもできるから、例えば家族の誕生日にその人の顔写真を貼るということも、簡単にできる。写真のタイトルをキャプションとして加えることもできるが、キャプションの位置は写真に隣接するテキストボックスから選ばなければならず、写真の上に重ねることはできない。特定の日付に、何でも好きなテキストを加えることもできる。iPhoto では、12 か月から 24 か月までのカレンダーを作成でき、30 か国以上の祝日を表示できる(残念ながら、1度に1か国だけだから、米国とオーストラリアの祝日を両方表示することはできない)し、iCalのカレンダーを読み込むこともできる(これを使えば、2か国以上の祝日を表示できるだろう)。また、アドレスブック から誕生日を読み込んで表示できる。どのカレンダーも見栄えがする。価格は 12 か月で 20 ドルで、1月分追加する毎に 1.50 ドルかかる。

Steve Jobs は、Macworld Expo の基調講演で、iPhoto の新しい Photocast機能を大々的に取り上げた。確かにこれは興味深い機能だ。基本的な目的は、iPhoto ユーザが、ほかの iPhoto 6 ユーザや、画像に対応した RSS リーダ(例えば Safari)のユーザと、.Mac アカウントを経由して、写真を共有できるようにするというものだ。Photocast を始めるには、スマートアルバムではなく、通常のアルバムが必要だが、そのアルバムに変更を加えたとき、それを自動的に反映させることができる。Photocast を誰にでもアクセス可能にすることもできるし、ユーザネームとパスワードを必須にして、それを知らせた人にだけアクセス可能にすることもできる。しかし、Apple が、公開されているPhotocast の一覧を作成するというようなことは、どうやらなさそうなので、現実的には、誰かが直接 URL を知らせないかぎり、Photocast の URL が知られることはないだろう。

人気のある写真共有サイト Flickr について言えば、私は特に入れ込んでいるというわけではないが(どうして皆は、ありとあらゆる様々なネチズンたちが投稿した写真を見るなどという時間を捻出することができるのだろう?)、Flickr の RSS フィードが iPhoto に現れるように(つまり、「ファイル」>「Photocast を登録」を選択して、URL 欄にペーストできるように)努力している人たちもいる。正直に言って、この2つのあいだに深いつながりがあるとは思えないのだけれど、下記にリンクしたサイトで提供されているプロキシサービスを試してみるのもよいだろう。これらを使うと、Flickr の写真を、ユーザネームやセット、タグに基づき、1度に 10 枚かそれ以上、最大サイズで、iPhoto に送ることができる(私が試したところでは、Photocastr が最もうまくいった)。

<http://photocastr.com/>
<http://snosrap.com/photocast/>
<http://phlikr.3xi.org/>

Photocast アルバムは、とにかく風変わりだ。写真を検索したり編集したりはできないし、さらに奇妙なことに、写真を Photocast アルバムから自分のライブラリに移動することもできない。ところが、写真を通常のアルバムに移動したり、カレンダーやブックに使うことはでき、そうした後では、編集ができる。しかし、それでもやはり、写真はライブラリに現れない。Photocast の写真をライブラリに取り込む唯一の方法は、Photocast アルバムを削除することだ。すると、iPhoto は、ユーザが「使用した」写真を保存し、同時に、それ以外のものについて、ライブラリに読み込んで保存するかどうかを尋ねる(ところが、Photocast アルバムを削除すると、私の場合2回に1回は iPhoto 6.0.1 がクラッシュする)。iPhoto 6 を使った Photocast が人気を獲得するかどうかは、現状ではまだ未知数だ。

iPhoto を使って写真を共有する方法で、ほかに変更が加えられた点を挙げれば、.Mac HomePage との統合が iWeb との連携に置き換わったことや、通常サイズの印刷またはフチなし印刷で、「ズームとトリミング」(これは、本来は、写真を正しい縦横比に切り抜くために必要なものだ)が使えるようになったことなどがある。

頭痛の種、本物と想像上のもの、直ったものそして残ったもの -- 現時点では、iPhoto に関するどう見たって明らかに問題と思えるものを直せない Apple の姿を見ていると、自分の判断の方がおかしいのかと考え込まされてしまう:これらの頭痛の種は直すべきだと思っているのは自分一人だけなのか?どうもこの叫びは Apple を行動に駆り立てるにまで十分なだけ大きくはなかったようだ、とりわけこれらの問題のどれもが捕まえ難かったり解決が難しいという風には私にはみえていないので。

最も話にならないのは、写真かフィルムロールにタイトルをつけるのには iPhoto 6 になっても Info ペインかパネルの Title フィールドにタイトルを打ち込まなければいけないことである。私は長年にわたって iPhoto チームが Finder から何も学べないように思えるのにあきれてきた。Finder かその他の Macintosh インターフェースの中であったならばどこでも、写真やフィルムロールのタイトルをダブルクリックすることで見ながらその場で名前を変更することが出来るのである。

それから iPhoto を Mac OS X と一緒に出荷されている Image Capture ユーティリティよりも強力にする必要性を感じている人が Apple には見当たらないことにも驚いている。少なくとも、カメラから画像をインポートする時に、全部をまとめてやるのではなく選択したものだけでもすることが出来るようにすべきである。Image Capture には Mac OS X の初期のころから選択インポートの機能が付いているのに、5年たってもこの当然と思える機能を真似できないのは一体全体何故なのであろうか?(Image Capture の話が出たついでなので言っておくと、カメラが接続された時、ある特定のプログラムが起動されるようにしたい時に探し回って Image Capture に変更させるのではなく、iPhoto に "hot plug action" 設定出来る機能をもたせた方が気が利いているとお思いになりませんか?)

明るい面を見れば、本当に馬鹿馬鹿しい頭痛の種のいくつかを Apple は排除してくれた。その中で最も目に付くのは、iPhoto の Preferences ウィンドウの Advanced ペインの中にある設定である。これは自分のハードディスク上のフォルダから iPhoto に写真をインポートする時に iPhoto Library フォルダにこれらの写真のオリジナルをコピーすること無しに出来るようにするものである。iPhoto 1.0 以来、人々は iPhoto がインポートした写真を取り扱うやり方に不満の声を上げてきたのだが、5年たってようやく Apple はこの見方に同調したようだ。察するに、オリジナルの写真を保存するために Finder の中に別のフォルダ階層を作って保持してきた iPhoto ユーザーは数限られた本格派だけであろうし、この機能も気の乗らない妥協でしかないかも知れないが、この機能を熱烈歓迎する人たちはきっといると思う。注記;オリジナルの写真はそのオリジナルのフォルダの中に残るが、変更を加えられた写真は iPhoto Library フォルダの階層下に保存される。

iPhoto がファイルをディスクに保存する方法について言えば、これもまた変更された。iPhoto の前回のバージョンで導入された年月日フォルダにびっくりさせられた人は多く、iPhoto 6 では Apple はこの構造を平坦化した。今や iPhoto Library フォルダには 3つのトップレベルフォルダが存在する:Originals (オリジナルの写真のため), Modified (編集された写真のため), そして Data (サムネールのため) である。それぞれのフォルダの中には各年毎のフォルダがあり、年フォルダの中には各フィルムロール毎のフォルダがあり、そのフィルムロールの名前がつけられる (フィルムロールフォルダの中の写真は元の名前を保持する;iPhoto の中で付けられた名前はiPhoto の内部にしか存在できない)。iPhoto 6 は iPhoto Library を新しい技術にアップグレードした後は昔の階層は消してしまう;しかしながら、私はいろいろなアップグレードを試してみたが、ミスってしまう写真も多く、残りのアップグレードが完了した後それらを "回収" するよう言って来る。その場合その通りやった方が良い。私の場合私の一万枚の画像ライブラリの中で約 50枚の写真が回収を必要とした。そしてそのうち約 35枚は重複したものではなかった (iPhoto の Search フィールドを使ってファイル名をマニュアルで検索)。

他の共通した苦情は、iPhoto は写真のベタ焼きを印刷できるのだが、写真のタイトルを含めるかどうかのオプションがなく、ベタ焼き本来の目的のために使うには殆ど役立たずであった。それもようやく是正された;タイトルをオンオフ切り替えするチェックボックスがついて、そして使うフォントも選択できる。

最後に、そして勿論これで全てというわけではないが、Apple はブックにテキストを入力する事に関する気になる誤りも是正した。iPhoto はその誕生から Cocoa アプリケーションの一つであり、Mac OS X の内蔵のスペルチェッカーを使えるようになっていたのだが、Check Spelling As You Type オプションはいつもオフとなっていた。これをブックにテキストを入力する時にオンにしても、ページを替えたり、或いはブックモードから一旦出たりすると、腹立たしいことにいつもそれをオフにしてしまうのであった。これも直った;Check Spelling As You Type はデフォルトでオンに設定されており、そしてそれが当然なのだが、ブック、カード、そしてカレンダーのどこにテキストを入力しても機能する。

アップグレードすべきか? iPhoto の新しいバージョンがでる度に、私は iLife の最新版にアップグレードするだけの価値がある改良がなされているかという質問に置き換えて考えることにしている。iPhoto 6 は iPhoto を本気で使っている人には、それに見合う改良や新機能を提供しているが、もし iLife '06 の他のアプリケーションにも興味があるというのであれば、これは絶対にやった方がいい。そうは言っても、写真の編集には iPhoto は使わないし、そしてブック、カード、或いはカレンダーもオーダーする気がないというのであれば、iPhoto 6 の新機能もそれだけで $80 の価値はないかもしれない;iPhoto 6 は単純に言ってその基本では iPhoto 5 とそんなに違ってはいないのである。


Take Control ニュース/27-Feb-06

文: Adam C. Engst <[email protected]>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

"Take Control of Podcasting on the Mac"、GarageBand 3 をカバー -- ポッドキャスティングは嵐のように 2005 年を席巻した。でも、多くの人たちはすぐに気付いた。これは、思ったより難しいぞと。だからこそ、私たちは去年“Take Control of Podcasting on the Mac”をリリースしたのだし、Apple が GarageBand 3 にポッドキャスティング関係の機能を山ほど盛り込んでも誰も驚かなかったというのも頷ける。それでも、Apple の iLife アプリケーションを使ったことのある方ならば誰もがわかっているように、Apple の説明書というものはあまり詳しいことは書いてないのが現状だ。そこで、今回 Andy Affleck が“Take Control of Podcasting on the Mac”をアップデートして、GarageBand 2 または 3 を使ってポッドキャストを作る方法を書き加えてくれたのはとりわけ嬉しいニュースと言えるだろう。この電子ブックにはもちろん、以前からと同様に Rogue Amoeba の Audio Hijack Pro についても書いてある(このプログラムが $3 値引きになるクーポン付きだ)し、さらに今回新たに SoundStudio 3 についてもカバーしている。もう一つ今回新たに書き加えられたのが、ポッドキャストに章を追加する方法についての情報だ。このアップデートはバージョン 1.0 を購入して下さった方には無料だ。お持ちの電子ブックの表紙にある Check for Updates ボタンをクリックして頂ければアップデートがダウンロードできるようになる。まだポッドキャスティングなんてものは試していない、とおっしゃる方、この電子ブック“Take Control of Podcasting on the Mac”はたった $10 で、ピカピカの新しい GarageBand 3 のすべてを使いこなすための手助けとなるはずなので、どうぞお試しあれ。

<http://www.takecontrolbooks.com/podcasting-mac.html?14@@!pt=TRK-0029-TB818-TCNEWS>(日本語)Take Control Ebooks: あなたの知りたいことがすぐわかる


TidBITS Talk/27-Feb-06 のホットな話題

文: TidBITS Staff <[email protected]>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

各話題の下の1つ目のリンクは従来型の TidBITS Talk インターフェイスを開く。2つ目のリンクは私たちの Web Crossing サーバ上で同じ討論に繋がる。画面上の見栄えが異なるほか、こちらの方が高速のはずだ。

DVD オーディオを iTunes に? -- オーディオの一部を DVD から直接録音するにはどうすればよいのか? いくつかの異なった方法をご紹介しよう。(メッセージ数 6)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2902>
<http://emperor.tidbits.com/TidBITS/Talk/739/>

SMS テキストメッセージングのコスト -- アメリカ合衆国内では、通常の電話料金よりも高いお金を払って携帯電話からテキストのメッセージを送れるようにしている。世界各国では、この点どうなっているのだろうか? (メッセージ数 8)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2903>
<http://emperor.tidbits.com/TidBITS/Talk/740/>

iPod nano を G3 Mac (OS 9.2.2) で外部記憶機器として使えるか? -- Mac OS X の走っていない2台の Mac の間で、iPod nano を USB ストレージ機器として使うことは可能だろうか? (メッセージ数 2)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2904>
<http://emperor.tidbits.com/TidBITS/Talk/741/>

Mac OS X 10.4.5、つまずく PowerBook を修正 -- 最新の Mac OS X Tiger アップデートの中に、オーディオ入力がフィードバックループに陥ってしまうという鬱陶しい問題への修正が盛り込まれていた。(メッセージ数 2)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2906>
<http://emperor.tidbits.com/TidBITS/Talk/742/>

Input Manager は悪魔の業か? -- Leap-A マルウェアが悪用した仕様について解説した先週号の Matt Neuburg の記事を読んで、この問題がどの程度まで広く影響が及ぶのかという議論が起こる。(メッセージ数 6)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2907>
<http://emperor.tidbits.com/TidBITS/Talk/743/>

シェルスクリプトを使った攻撃 -- セキュリティへのこの最新の脅威について TidBITS 読者たちが検討し、Safari 以外のウェブブラウザでも危険があるのかどうか考える。(メッセージ数 16)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2908>
<http://emperor.tidbits.com/TidBITS/Talk/744/>


tb_badge_trans-jp2 _ Take Control Take Control 電子ブック日本語版好評発売中
Tiger でのファイル共有、TidBITS 翻訳チーム訳
Panther でのユーザとアカウント、TidBITS 翻訳チーム訳
Panther のカスタマイズ、TidBITS 翻訳チーム訳
Panther へのアップグレード、TidBITS 翻訳チーム訳

非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

Valid XHTML 1.0! , Let iCab smile , Another HTML-lint gateway 日本語版最終更新:2006年 3月 3日 金曜日, S. HOSOKAWA