TidBITS: Apple News for the Rest of Us  TidBITS#938/28-Jul-08

今週のトップニュースは、既に巷に野放しになっている DNS の危機的な欠陥に対して(多数の告示がなされていたにもかかわらず)Apple がこれを修正できなかったことだ。Rich Mogull と Glenn Fleishman が問題点を説明し、DNS サーバを運営している人たちのために可能な回避方法を紹介する。ただし完全な修正には Apple からのアップデートを待たなければならない。Apple には Glenn がもう一つ苦言を呈する。MobileMe への移行の処理と同社の回答書についてだ。何とも冷たい言葉遣いのステータスページが出されただけだった。Adam もそれに追い打ちをかけて、iTunes 7.7 でアクセント付きのトラック名やアーティスト名が壊れてしまうバグについて検討し、またアップデート後に iPod touch がひっきりなしにビープ音を鳴らすのを止める回避策をいくつか考える。さて、良いニュースの方に目を向けると、まず Apple の輝かしい決算報告についてお伝えし、Neale Monks がウォーターマークと画像前処理ツールの iWatermark をレビューする。また Adam はフォントに関する傑作ビデオへのリンクを紹介する。(本当に傑作だ - ぜひご覧あれ!)TidBITS 監視リストでは、Firefox、Default Folder X、Typinator、PDFpen (と PDFpen Pro)、Keyboard Maestro、Skype、iLife '08、それに AirPort Extreme のアップデートについて触れる。

記事:

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

---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----


CollegeHumor ビデオがフォントを擬人化

  文: Adam C. Engst <ace@tidbits.com>
  訳: 湯本 敬<ymo@big.or.jp>

我々 Mac ユーザは、自分達のフォントとして、数多くのフォントを貯め込む傾向がある。そして、今、CollegeHumor からのちょっと陽気なスケッチコメディのおかげで、私たちは、もしもいろいろの異なったフォントが人間だったら、それぞれどんな感じになるだろうかと想像出来る。どんちゃん騒ぎのお祭りは大好きだ。もうこれ以上何も言うまい。-是非 ビデオを見にいく!べきだ!


iPod touch の持続的に繰り返されるビープ音を止める

  文: Adam C. Engst <ace@tidbits.com>
  訳: 湯本 敬<ymo@big.or.jp>

月曜日に休暇から家に戻ったあと、私は時間を浪費することはしなかった。真っ先に私は、私の iPod touch のため、2.0 software upgrade を購入し、ダウンロードし、インストールした。私は国外にいる間に出来なかった遅れを取り戻し、新しいアプリケーションの操作をスタートさせ、Apple の改善をテストしたかったのだ。インストール後、ほぼすぐに、iPod は不規則な間隔で鳴り始めた。私は、NetNewsWire、NYTimes、AIM、そして WeatherBug などのいくつかのアプリケーションをダウンロードしたが、ビープ音の原因となったアプリケーションがどれなのか、その目安となるものはなかった。

急いで Twitter で助けを呼んだところ、その元凶が明らかになった。それは Mail だった。どうやら、新しいバージョンの Mail は、新しいメッセージが入る時はいつも、ビープ音を鳴らす設定になっており、そして、電子メールのための MobileMe の「プッシュ」オプションによって、新しいメッセージを絶えず受信していることになってしまい、それが問題となっていたのだ。頭に来た! ( Twitter 上の多くの人々が、自分と同じ問題を経験していたことを確認した。)

確かに、電子メールを通知するビープ音が好きな人もいるでしょう。が、私の MobileMe アカウントは多くのスパム(ざっと1日あたり30通)を受信し、それ以外にはあまり受信していない。私はそのアカウントを本当の仕事には使用していない。そして Mac の上では、Apple Mail がかなり効果的にスパムをフィルターにかけているので、これまで一度も問題にあったことがない。しかし、私は Mac 上で、1週間におよそ1度だけメールを起動するため、その間に iPod touch を通して、何百ものスパムメッセージを受信することがよくある。今まで、私は iPod touch の Mail は自分自身を技術に精通させるために主に使っていたので、これが一日中ひっきりなしにビープ音を鳴らすとなれば何らかの行動を起こすことが必要だった。

2つの解決策があるが、しかし、どちらも完全には満足出来るものではない。ひとつは、メニューから Settings >General > Sound Effects に入り、音響効果をオフにすることだ。これに関する唯一の問題は、音響効果がカレンダーのアラートにも使用されているということだ。私はこの点について音響効果は使っていないが、カレンダーのアラートは利用したいけれどメールの受信音は鳴らさないようにしたい、という人がいることは容易に想像出来る。幸い、音響効果がオフでも、Clock に設定された時刻アラームは、まだ鳴るし、Clock のタイマーも鳴る。独立したアプリケーションが音響効果に依存しているかどうかは分からないが、でももしそうだとすれば、そうしたソフトも鳴らないと考えられる。それは良いことなのか悪いことなのか。

(iPhone のユーザーは、細かい設定が可能なのでこの問題が起こらない。iPhoneでは、メニューから Settings > General > Sounds と入り、新しいボイスメール、新しいメール、メール送信、カレンダーアラート等について、別々のオン/オフのスイッチを提供している。)

もうひとつは、メールを常時受信する(プッシュ設定)または定期的に受信する(Fetch)のではなく、メールの受信は手動で行い、新しいメッセージを受信するときに Mail を起動させるというものだ。それは Settings > Fetch New Data > Advanced > yourAccountName で変更する。これでメールが静かになるわけではないが、メッセージを取り込んだ後だけ鳴るようになる。これで、少なくともあなたは驚かされたり(起こされたり)しなくなる。

iPod touch で設定項目を最小限に抑えたいという Apple の願望は理解出来るが、この場合は処理単位で設定変更できる iPhone が大きな改善となっていることも事実だ。


Apple、2008年第3四半期で 10 億ドルの利益を計上

  文: TidBITS Staff <editors@tidbits.com>
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

Apple は 28-Jun-08 を最終日とする第3四半期に $7.46 billion の売上げで $1.07 billion の利益を稼ぎ出した (一株当り $1.19)。これは前年同期比で利益では 31% そして売上げでは 37% 増であるが、前年の利益は $818 million (一株当り $.92) で売上げは $5.41 billion であった。但しこれらの数字は Apple が手にした現金の増加を必ずしも正しく反映してはいない、と言うのも利益の数字には無形資産も含まれており、かつ Apple は iPhone やその他の売上げをある期間にわたって分割計上する方法を取っているからである。Apple は前四半期の終わりに $19.5 billion の現金及び同等物を持っていた。 この決算のウェブキャスト は Apple のサイトで聞ける。

Apple は又 717,000 台の iPhone を販売したが、これは前年同期に較べて 63% の増加であり、一年前の数字には最初の iPhone モデルが売り出されたその最初の週末だけで売上げられた 270,000 台の電話が含まれている。

これらの販売台数と売上げの数字はより興味深いものとなっている、なぜならば Apple は iPhone が売られた時に iPhone に対する売上げを計上しないからである - 利益には計上される - iPhone が売られた時幾つかの四半期に対して収入が分割計上される。Apple は iPhone 2.0 ソフトウェアが発表された 06-Mar-08 から、iPhone 3G の出荷が開始された 11-Jul-08 までの間、新しい iPhone からの収入を計上するのを止めるという選択をした。つまり、28-Jun-08 を最終日とする四半期に計上された $419 million という iPhone の売上げには、$1.5 billion から $2 billion の間の現金収入に分散されている分は含まれていないのである。これは並外れた次の第4四半期に貢献するであろう。

この四半期は又 Macintosh コンピュータの継続するルネッサンスの一部でもあり、何年にもわたり iPod の販売の後塵を拝してきたコンピュータ側の巻き返しといえる。iPod や iPhone の恩恵でユーザーを増やそうと言う Apple の間接的な戦略が功を奏し四半期当りの販売台数としてはこれまで最高を記録した - 2.5 百万台をちょっと下回るが前年同期に較べると 41% の増加である。Apple は今や全米で第3位のコンピュータメーカーで 8% から 9% の市場シェアを有している ("Apple がコンピュータ販売のシェアを拡大" 2008-07-18 参照)。

かといって iPod が低調だったわけではなく、同社は 11 百万台を出荷し、12% の増加であり、これはこの四半期に際立った祝日や iPod 製品の発表も無かったことを考えると、極めて立派な成績と言える。

小売ストアも素晴らしい成長を示した、これは iPhone 購入者が殺到したせいであろうが、前年対比で売上げ 58% 増、第3四半期の顧客数も 32 百万人で、一年前は 22 百万人であった。直近の四半期でのこれらのストア経由の売上げは $1.44 billion で、476,000 台の Mac を売った。Apple の言では、小売販売を調査している NPD Group によれば Apple の割合は一年前と較べると売上げで 15% から 20% になったと言う。

同社は、第4四半期の売上げはやや増加の $7.8 billion と予想しているが、これは 2007年の第4四半期に較べると 25% の増加である。2008年会計年度通年では、Apple は売上げを $32 billion、前年対比で 35% 増を予想している。


iTunes 7.7、アクセント付きのアーティスト名・トラック名を壊す

  文: Adam C. Engst <ace@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Apple の最新リリースである iTunes 7.7 で、以下に述べるような微妙な問題が出現したことを私たちに知らせてくれた Stig Albjerg に感謝したい。[訳者注: その後、新バージョン iTunes 7.7.1 がリリースされ、この記事に書かれたバグが修正されたようです。以下の記事は、あくまでも iTunes 7.7 についてのことです。]アーティストの名前またはトラック名にアクセント付きの文字[訳者注: ヨーロッパの言語などに見られる、アルファベット文字に飾りを追加した文字のこと]が含まれている場合、その曲を再生したり情報を見たりするとそれらの文字が別の文字に勝手に書き換えられ、正しくない名前になったり場合によっては全く読めなくなったりするのだ。英語以外の楽曲をたくさん持っている人たちには(あるいは、ひょっとすると ヘビーメタルのファンにも!)これは言うまでもなく大きなトラブルだ。この問題が起こるのは MP3 ファイルのみであって AAC は影響されず、どうやら問題は ID3v2.2 タグに使われている文字列エンコーディングフォーマットに関係したことらしい。従って、ユニコード文字で名前が付いているトラック、例えば日本語や中国語についても影響があるかもしれない。

すべての iTunes ユーザーがこの問題に見舞われている訳ではないようだが、私も Mac OS X 10.4 Tiger の下で iTunes 7.7 を走らせて問題を再現させることができた。影響を受けたトラックは Get Info ウィンドウの Summary パネルの中で ID3 Tag フィールドに v2.2 かそれ以前の番号が表示されている。問題が起こったのは私が 2007 年中ごろより以前に iTunes の 7.3 より前のバージョンでリッピングした楽曲に限られていた。(iTunes 7.0.2 でリッピングした曲では確かに問題が起こった。どうやら私は 7.0.2 と 7.3 の中間のバージョンでは何もリッピングしなかったようなので、実際に Apple がどの時点でリッピング後のトラックに ID3 タグを含めるのを止めたのかはわからない。)

iTunes-ID3-Tags

残念ながら、いったん再生されたり Get Info ウィンドウで見たりしたトラックについての唯一の解決法は、アーティスト名やトラック名を iTunes の中で手で修正することだ。いったん修正が済めば、その後はそのままに留まる。

予防の方がより重要だ。そのためには、アクセント付きの文字を含むトラックを iTunes の中で選択してから、Advanced > Convert ID3 Tags > ID3 Tag Version > v2.4 を選べばよい。これをするとアルバムアートが消えてしまうという報告を見たことがあるが、少なくとも私のテストではそれは起こらなかった。Convert ID3 Tags ダイアログにあるそれ以外のオプションをいじってはいけない。

iTunes-Convert-ID3-Tags

ID3 タグを力ずくで直そうとして、iTunes ですべてを選択しておいて変換を実行させたいと思うかもしれない。でもそれは気を付けた方がいい。あなたがどれだけの数のトラックを選択したかにもよるが、すべてのファイルを編集するには相当の時間がかかる。特に、あなたの楽曲がサーバに保管されていてネットワーク経由でそこにアクセスしている場合は注意が必要だ。また、あなたは一つ一つすべてのファイルを編集しようとしているのだから、おそらくそれらすべてのファイルが再度バックアップされることになり、あなたのバックアップの中で膨大な容量が浪費されることにもなりかねない。

もっと集中的な修正をするために、バグの影響を受けるトラックだけを検索して変換するのがよい。残念ながら iTunes はその検索でアクセント付きの文字とそうでない文字を区別することはできないが、一つ回避方法がある。何かテキストエディタ、例えば Bare Bones Software の TextWrangler あるいは BBEdit を使い、あなたの iTunes フォルダにある iTunes Music Library.xml ファイルを開く。それからいろいろなアクセント付き文字を検索する。何を探せばよいのかわからなければ、Apple Discussions のこのスレッドの最後近くを見れば一般的なアクセント付き文字のリストがある。また、その XML ファイルのコピーを作って、BBEdit の Text > Zap Gremlins コマンドを使ってすべてのアクセント付き文字を黒点あるいは何か見つけやすい文字で全置換しておくのもよいだろう。XML ファイルの中で問題あるトラックをすべて見つけたら、iTunes に戻って ID3 タグの変換をすればよい。

当然ながら、もう一つ考えられる選択肢は、影響を受けるトラックはすべて、Apple が将来のバージョンの iTunes でこのバグを修正するまでの間、再生せずにおくことだ。修正版が出るまでにどのくらい時間がかかるか、あるいはそもそも修正版が出るのかどうかも、今はまだわからないが。[訳者注: 最初に書きました通り、このバグを修正したと見られる修正版、iTunes 7.7.1 が既にリリースされています。]


Google Gmail がセキュアなセッションのオプションを追加

  文: Glenn Fleishman <glenn@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Google が、その無料のホスト型メールサービス Gmail(これは、かれこれもう四年もベータ版のままだ)において、これを利用することに関連した最大のセキュリティ上のリスクの一つを塞いだ。あなたのアカウント環境設定で、すべてのセッションが暗号化されたウェブ接続を要するように設定するオプションが選べるようになったのだ。これまで研究者たちが発見してきた Gmail の数々の脆弱性について、私は 2007-08-27 の記事“開いた Gmail、その他サービスを Sidejack 攻撃がこじ開ける”に書いている。

Gmail は、あなたが最初にセキュアな Gmail のサイトアドレス.を使ったかどうかにかかわらず、あなたのログイン詳細情報については常にセキュア接続を要求する。けれども、もしもあなたが最初にセキュアでない Gmail サイトからスタートしたならば、Google はログイン後、あなたを暗号化されていないウェブ接続に戻してしまう。これは最初から Google の側の誤りであった。なぜなら、あなたの電子メールメッセージがすべて暗号化されずに通ってしまうからだ。さきほど触れた記事に書かれているサイドジャッキング攻撃も、誰かがあなたの Google セッションにおけるトークンを傍受することであなたの Gmail アカウントにフルにアクセスできてしまうことを実証している。

Google は Gmail ブログの中で、今回 Gmail サービスに Browser Connection オプションが Settings > General 表示の一番下に追加され、そこで“Always use https”を選択することができるようになったと述べている。https というのは URL で使うプロトコル名で、あなたのブラウザがウェブサーバとの間で暗号化された SSL/TLS 接続を開始するように指定するものだ。

gmail_always_secure

Google のこのブログには、inbox の一番下に 新たにリンクが追加され、アカウントの活動の詳細情報や、他のマシンで開始されたセッションをログアウトできる方法などが提供されるとも書かれている。例えば私の場合、いくつかの最近のセッションが見えている。昨夜自宅からしたブラウザ接続も、最近の電子メールを自動的に回収するための私の iPhone からの IMAP 接続もそこにある。(Google では現在この機能を送り出している最中なので、まだあなたのところでは見えないかもしれない。Adam Engst にもまだ見えなかった。)

gmail_recent_sessions

以上紹介した二つの変更点は、いずれも Gmail のセキュリティを劇的に向上させるものだ。皆さんには、即座に https 設定をオンにしておくことをお勧めしたい。


MobileMe ステータスページは更新を約束、しかし口調は平板

  文: Glenn Fleishman <glenn@tidbits.com>
  訳: 羽鳥公士郎 <http://www.ousaan.com/mail/>

Apple は、ここ2週間の MobileMe の問題に関して情報開示が足りないと批判を受けていたが、より詳細なステータスページを作成し、それを「1日おき程度」で更新すると約束することで、やっとその批判に応えた。2008 年 7 月27 日時点でのメッセージでは、MobileMe の壊れている部品が引き続き修理されている状況が説明されている。

どうやら少数の MobileMe ユーザ(Apple は 1 パーセントだと言い続けている)に関連するらしいが、もっともいらだたしい問題としては、2008 年 7 月18 日以来、me.com または電子メールクライアントを経由して電子メールにアクセスすることができず、電子メールを送信することもできないということだ。

最初のステータスメッセージによると、一時的な解決策が用意されて、影響を受けたユーザもその日以来送られた電子メールを取得したり、新しい電子メールを受け取ったり、電子メールを送信したりできるようになっている。そのメッセージには、7月16日から18日までに受信されたメッセージのおよそ10パーセントが「残念なことに、復旧させることができませんでした」とも書かれている。(Apple は、この問題がまる1日続いた時点で、彼らの電子メールを転送することを申し出たり、Gmail のアカウントを設定するのを手伝ったりしてもよかったのではないかね、まったく。)

7 月 18 日以前に保存されたり受信されたりしたメールに対するアクセスの完全復旧予定日は、執筆時点では 8 月 1 日だ。このメッセージから読み取れることは、この問題は徐々に解決されるということで、8 月 1 日よりも前に、次第に多くの影響を受けたユーザが古いメールへのアクセスを取り戻すようだ。

ここに謝罪はあまり書かれていない。「発生した問題の1つ」と言っているように、お詫びは受動的な態度に満ちている。文字通りの受動態で、つまり「1つの問題が私たちによって発生させられた」と書いているわけではないし、過ちを認めるという精神も感じられない。Apple よ、これは前人未踏の島などではなく、あなた方が開発したシステムなのだよ。問題はひとりでに発生したわけではない。それは、あなた方の設計と移行プランの付随現象ではないか。

このメッセージには、チームは「70以上のバグを修正」したとかかれている。これは、ほとんどのユーザが抱いている、MobileMe は非公式のベータ版として開始されたという印象を裏付けるものだ。私たちにはこれらのバグがどれだけ深刻なものかは分からない。Apple はこの手の問題についてはまったく透明性に欠ける。だから、この言葉を完全かつ公正に評価することは難しい。

Macworld で、TidBITS 編集者の Jeff Carlson が、MobileMe サービスとそのiPhone および Mac OS X デスクトップとの同期された統合についてレビューしている。彼はこのサービスを 3.5 マウスと評価し、サービスがうまく動かない人たちや、MobileMe 電子メールが使えない推定 1 パーセントに当てはまる人たちから、矢のような批判のコメントを受けている。

Macworld の編集ディレクター Jason Snell が、このレビューの批判者たちに答えてコメントしている。彼らは、Jason と Jeff、そして Macworld が、「肯定的な」レビューによって Apple から見返りを受け取っていると非難しているが、Jeff のレビューはおよそ肯定的とは言えない。圧倒的多数のユーザにとって完全に機能しているサービスを、ほかの人々が報告している問題を経験していない記者がレビューするというのは、難しいものだ。

(ついでに言っておくと、私は当初 MobileMe に憤慨していたが、今ではMobileMe は私にとって完璧に動いている。ただし、私のアカウントを Family Pack にアップグレードすることはできないが、Apple はその問題を認識している。Apple はサポートの依頼に圧倒されており、私は、サポートウェブサイトでテキストチャットを始めるのに30分待たされ、担当者とのやり取りにさらに15分から20分待たされた。その挙句に言われたことは、この問題は解決されるであろうが、私が報告した問題が解決されたことを私に通知する手段はApple にはないということだった。それは、率直に言って、ばかげている。彼らは依頼と解決を追跡していないのだろうか。)

最初のステータスメッセージは、私を少々いらだたせた。実際に問題の責任を認めるのではなく、認めたふりをしているからだ。お詫びの口調は平坦で調子が外れている。これは、注文を忘れてしまったことなど実際にはどうでもよいが、チップをもらえないと困るので謝っているふりをしている、レストランのウェイターの口調だ。

一番最初の「スティーブ・ジョブズがリクエストし続けている」というのにも、誠意が感じられない。この記事には署名がない。Jobs は _誰に_ リクエストしたのですか、名無しの MobileMe 製品マネージャさん。四の五の言ってないで、白状したらどうですか。2番目の投稿には「デビッドG.」という署名があり、これは少なくとも正しい方向に向かう一歩ではあるが、大きな一歩ではない。この記事に "Zaphod Beeblebrox" と署名があったとしても、情報価値は変わらないだろう(あるいは価値が増すかもしれない。この歌い手は本名を使うつもりがないということを知ることができるのだから)。

新しい製品やサービスに関する Apple の秘密主義は、ますます無分別になっているようだ。この企業は、プライベートベータおよびパブリックベータという価値あるサービスを手放してしまったのだから。私はレビューワーとして、私がテストした完成版 Apple 製品のほとんどすべてについて、数々のバグを見つけており、中には決して看過できないものもある。Time Capsule がその最たる例で、製品版で多くの人が問題を経験した。

社外でのベータテストは、ほとんどの製品開発において重要な工程であり、従業員がテストをさぼったり、極端な事例として放置したりするような、恥ずべき怠慢を防ぐことができる。私は自分自身が極端な事例そのものだから、問題を多く見つけてきた。MobileMe では、多くのユーザが問題を見つけている。

MobileMe は特別な事例といえる。アプリケーションの規模を拡張したときに何が起こるかを予測するのは困難だからだ(ただし、それをテストするためのツールはある)。しかし、もうそろそろApple に、沈黙の壁は同社にもユーザにも利益にならないということを伝えるべきだ。Jobs さん、こんな壁は壊してください。


iWatermark でウェブ画像を用意

  文: Neale Monks <nmonks@mac.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Script Software の iWatermark は、画像に目に見える(デジタルなものではない)ウォーターマーク(透かし)を追加するアプリケーションだ。この作業は伝統的なグラフィックスアプリケーションでもできるが、iWatermark はその作業のスピードを劇的に向上させる。ウォーターマークのデザインもいとも簡単にでき、インターフェイスはドラッグ&ドロップ対応なので多数のファイルでまとめて作業するのも楽だ。

iWatermark-interface

存在理由 -- 目に見えるウォーターマークを入れることによって、その画像がある人物ないしはある組織に属したものであることが明らかに見て取れる。かくしてこれは著作権の主張のための最初のステップとなる。当然ながら、誰かがその画像をダウンロードしてからあなたのウォーターマークを編集によって取り除いてしまうのを防ぐことはできないし、そうした行為自体が著作権法に触れる訳でもない。

けれども、もしもそうした連中がその写真やそれに基づいた作品をあなたの許可なく販売したりすれば、それは彼らがあなたの著作権を侵害したことになり、あなたは法的手段に訴えるための根拠を得ることになる。もしもあなたの著作権宣言文が明らかに述べられていれば、彼らはそれに気付かなかったと主張することはできない。(より詳しい情報については、米国英国の著作権ページを参照されたい。)

そこで iWatermark の出番だ。これを使えば、写真家やアーティストが画像の上にテキストやグラフィクスのウォーターマークを手早く簡単に追加することができ、かくしてその画像の所有者であることを明確に主張することができる。けれども iWatermark がさらに便利さを増すのは、これが汎用の画像前処理ツールとしてもうまく使えることで、写真やアート作品をリサイズしたりサンプルを取り直したり、あるいはフォーマットし直したりすることによって、ウェブページ上でよりふさわしいバージョンへと仕上げることができる。

テキストによるウォーターマーク -- ウォーターマークの作成は Watermark Editor ウィンドウでする。iWatermark は二種類のウォーターマークをどちらでも追加できる。テキスト文字列か、ユーザーが選んだグラフィックスかだ。テキストは直接入力することも、あるいは他のファイルからドラッグしてくることもできる。ただし、テキストのフォーマッティングを持つファイル(例えばワードプロセッサの書類)からコピーされたテキストは元のフォーマッティングを維持する。状況によってこれは良いことであったり悪いことであったりするが、いずれにしてもフォーマッティングなしにペーストできるオプションがあればよいのにと思うのは自然の成り行きだろう。また、Insert Special メニュー項目でテキストを追加することもできる。これは Address Book からのデータ(例えばあなたの名前や電子メールアドレスなど)や、写真からの EXIF や IPTC データが追加できる。

iWatermark-editor

いったんテキストが追加されれば、それをいろいろな方法で変更できる。例えば、画像の上であちこち動かしたり、リサイズしたり、あるいはエンボス加工のようなグラフィカルな効果を施すこともできる。

一つ気になる問題がある。iWatermark がフォントサイズを変更せずにテキストを拡大縮小するのが分かりにくい。もちろんテキストのフォーマットはフォント、スタイル、フォントサイズを設定することによってさまざまに変更でき、その選択はすべて Watermark Editor の Text タブでおこなう。けれども General タブにある Scale ツールがさらにテキストのサイズを変えて、画像全体のうち何パーセントを占めるようにするか指定できる。こちらのツールはテキストに用いられるポイントサイズを変えないので、大きくてちょっとぼやけたテキストができてしまうこともある。テキストがきれいに見えるようにするには、General と Text のタブを行き来していろいろなコントロールを調整して回らなければならない。

これは馬鹿げたことだ。iWatermark は、ぜひともテキストの拡大縮小をもっとシームレスに、つまり必要に応じて自動的にポイントサイズを変更してウォーターマークがいつもくっきりはっきり見えるようにすべきだ。実際、いろいろと試してみたところ、一番簡単なのはフォントを最大ポイント (288 points) のサイズに設定しておいて、テキストウォーターマークのリサイズはすべて Scale ツールに任せるのが良いようだ。

グラフィカルなウォーターマーク -- もしもあなたが会社のロゴやその他のグラフィカルな図案をテキスト見出しの代わりに入れたいならば、iWatermark はそれにも対応している。あなたがロゴとして使いたいグラフィックを Image パネルにドラッグすれば、プレビュー画面が見られる。その後で Scale ツールを使ってグラフィックのリサイズができるが、その他にも画像の白い部分を透明にするという素敵なオプション(背景部分を取り除くのに便利)がある。

同じ写真の上にグラフィカルとテキストのウォーターマークを組み合わせることもできるが、iWatermark はそれらを二つの独立した項目として扱うことはせず、両者を互いに固定して一つのウォーターマークとして扱う。言い替えれば、General タブにある位置、スケール、その他の設定はそれらをグループと見て同時に適用される。

入力フィルター -- 一つのファイルを iWatermark で開くこともできるが、このプログラムの本領はたくさんのファイルを手早く自動的に処理できるところにある。例えば、あるフォルダの中で特定のフォーマットのファイルだけを、あるいは特定の文字列をファイル名に含むファイルだけを、すべて処理するように iWatermark を設定することができる。このようにして、例えば一つの種類のウォーターマークを GIF 線画に施し、また違った種類のウォーターマークを JPEG 写真に施すということが可能になる。あるいは、特定のサイズ以上のファイルにのみウォーターマークを適用するよう設定することで、フルサイズの写真にはウォーターマークを入れる一方でスケールダウンされたサムネイルには触らずにおくということもできる。

また、メタデータの検索もできる。ただしその挙動は時として一貫性がないようにも見える。例えば、特定の Spotlight コメントを持つファイルのみを処理するよう iWatermark を設定することもできるはずなのだが、私のテストでは iWatermark がこの設定を無視したらしく、該当する Spotlight コメントを含んだファイルのみでなく、そのフォルダにあるすべてのファイルを処理してしまった。

出力オプション -- iWatermark を使ってみて意外なボーナス機能に思えたのは、これがウォーターマークの追加以外にもたくさんのことができることだ。画像をリサイズしたりフォーマットしたりもできる。例えば、たくさんの画像をすべて 640 * 480 ピクセルにリサイズしてから 80% 画質の JPEG ファイルとして保存するように iWatermark を設定することができる。また、ファイル名を変えることもできる。例えば、ファイル名の後に“wtmk”のような拡張子を追加すれば、ウォーターマーク付きのグラフィックが元のファイルと区別できるようになる。

ただし、iWatermark は GIF ファイルを書き出すことはできない。処理のために GIF ファイルを受け入れることはできるが、出力する際には iWatermark のサポートするファイルフォーマットのどれかを選ばなければならない。

iWatermark はまたサムネイルを別ファイルとして生成することもできる。これは、画像をオンラインギャラリーに組み上げなければならない人にとって時間の節約となるとても便利な機能だ。生成される一連のメインの画像と同様に、サムネイルについてもサイズやファイル名、その他の設定ができる。

嬉しいことに、これらさまざまの出力オプションを毎回すべて同時に走らせなければならないということはない。ウォーターマーク、ファイルのリサイズと変換、サムネイル作成はそれぞれ必要に応じて作業ごとにオン・オフの切り替えができる。

残念ながら、あなたが必要なだけ多くのウォーターマークを設定して、必要に応じてそれらを適用することはできるものの、iWatermark ではそういうワークフローをまるごと保存しておくということができない。だから、さまざまの異なったプロジェクトで作業しているウェブデザイナーも、さまざまの異なったウォーターマークをそれぞれ異なった画像セットに手軽に適用することはできるのだが、iWatermark のそれ以外の機能は毎回手で設定し直さなければならない。将来のバージョンではぜひともワークフローの保存を実現して、ユーザーが画像前処理の全プロセスを自動化できるようにしてもらいたいと思う。

インターフェイスとパフォーマンス -- iWatermark のインターフェイスは全般にうまくデザインされている。例えば、File メニューは自動的にあなたの iPhoto アルバムにリンクされるので、iPhoto 自体を開くことなくそれらで作業することができる。あなたの iPhoto アルバムの一覧がサブメニューとして現われ、そこで選べば、そのアルバムの中にあるすべての写真がインターフェイスウィンドウの入力パネルに追加される。Input パネルを Control-クリックしても同様のメニューが現われる。

このアプリケーションでもう一つ素晴らしい特徴と言えるのが自動バックアップ機能だ。iWatermark が(編集後のコピーを別ファイルにするのでなく)ファイルに上書きするよう設定しても、自動的に元のファイルのコピーが作られてあなたのアカウントの Library フォルダの中にある日付と時刻のスタンプの入ったフォルダに保管される。

ファイルの処理に関して言えば、iWatermark は元気よく働き、間違いなく本物の時間節約ツールとなるだろう。例を挙げれば、私は 50 個の JPEG 写真でそれぞれ 600K ほどのサイズのものが入った iPhoto アルバムに、ウォーターマークを入れ、リサイズし、PNG にフォーマット変換するよう iWatermark を設定した。私の 1.83 GHz MacBook Pro で走らせてみると、所要時間はたったの 25 秒だった。

結び -- 私が細かな点で不満を述べたことをあまり気にしないで頂きたい。たったの二十ドルで買えるのだから、iWatermark を責めることなどできない。これは、画像前処理プログラムがすべきことをすべて、最小限の手間でやってくれる。単なるリサイズとリフォーマットのツールのみとしても、値段に見合っただけの働きができる。その上にウォーターマークまで付けてくれるのだから、既に美味しいものが、さらに二倍、美味しいというものではないか。

iWatermark 3.1.3 の価格は $20、ダウンロードサイズは 8 MB だ。デモ版もあり、Windows 版もある。


Apple、DNS が攻撃される危機的な欠陥をパッチせず

  文: Rich Mogull <rich@tidbits.com>, Glenn Fleishman <glenn@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

2008 年 7 月 8 日、 何十ものベンダーから大量のセキュリティパッチがリリースされ、DNS (Domain Name Service) におけるある際立った脆弱性に対処が施された。この脆弱性はセキュリティ研究者の Dan Kaminsky によって発見されたものだった。DNS はインターネットの最も基本的な土台を成すものの一つで、ドメイン名 (例えば tidbits.com) を IP アドレス (例えば 216.168.61.78) に翻訳する働きをする。DNS はインターネットの機能においてあまりにも中心的な位置を占めているので、この脆弱性はおそらく最近十年間でインターネットが直面したセキュリティ上の問題のうちで最も重大なものと言えるだろう。

[訳者注: この DNS 脆弱性を修正したパッチ、Security Update 2008-005 が、日本時間の 8 月 1 日に Apple から出ました。Tiger でも Leopard でも、 ソフトウェア・アップデートから入手可能です。]

DNS 検索のために Mac OS X ベースのサーバに接続するユーザーはすべて危険に晒されている。なぜなら、Apple がまだパッチを提供していないからだ。他の会社でオペレーティングシステムあるいは DNS サーバソフトウェアを作成あるいは配布しているところは何十社もそろってパッチを出したというのに。

Apple が会社創立以来最多の新商品の一斉打ち上げのため気を散らされていたのは明らかだろう。iPhone 3G、iPhone 2.0 ソフトウェア、.Mac から MobileMe への移行、それに App Store と続いたのだから。それでもなお、顧客たちが現在危険に晒されているのだから、Apple は即座にこれに対処する必要がある。

自社の顧客たちに DNS サービスを提供している会社はすべて、その DNS サーバのアップデートを済ませているべきだ。それなのにまだそうしていない会社がたくさんある。あなたの ISP が危険に晒されているかどうかをチェックするには、Kaminsky のサイトを訪れて、Check My DNS ボタンをクリックすればよい。もしもそのサイトがあなたの DNS が汚染される危険があると言えば、あなたは今すぐあなたの ISP か、あるいは会社の IT 部門に連絡すべきだ。

DNS の泉を汚染する -- Kaminsky はアタッカーが DNS サーバを攻撃するために使える新しいテクニックを偶然に発見した。このテクニックを使えば、悪者たちがサーバを騙して、特定のドメイン名に対しそのドメイン情報として適切に管理すべきところ以外から出た不正な IP アドレスをそのサーバが受け入れるようにさせてしまえる可能性がある。(これがいわゆる _キャッシュ汚染_ だ。)この攻撃は DNS サーバのソフトウェアには影響を与えない。これはそのソフトウェア自体を攻撃するのではなく、ただそのサーバが保存する(キャッシュしている)情報を変更して、ドメイン名についての応答としてそのサーバが別の場所から取ってきた答を返してしまうようにするのだ。

こうして、あなたがウェブブラウザの URL フィールドに www.tidbits.com とタイプした際に、あなたのコンピュータがその内蔵の DNS リゾルバから正しい IP アドレス(この場合は 216.168.61.78)を受け取るべきところを、アタッカーが間接的にそのリゾルバを騙して、そのアドレスが何か他のもの、例えば 172.31.0.16 であるかのように思い込ませる、というわけだ。

するとあなたのブラウザは、アドレスバーには www.tidbits.com と表示しつつ、その思い込んだ IP アドレスを使っていそいそとウェブサーバへの接続を開く。接続したそのサイトはひょっとしたらマルウェアで一杯のものかもしれない。いや、きっとそういうものだろう。これは Windows ユーザーたちにとって特に問題となる。彼らのシステムは、ただ単にサイトを訪れただけで感染する可能性があるからだ。現在はまだウェブページを訪れただけで Mac OS X が攻撃されるという現行の実例がないので、Mac ユーザーたちが被害者になるとすればそれはむしろサイトを訪れた後でのソーシャルエンジニアリングのタイプの攻撃によるもの、つまりパスワードを再入力するよう要求されたり、その他信用あるサイトならば通常求めないような種類の詳細情報を提供するように言ってきたりするタイプのものが考えられるだろう。

DNS は分散型であり再帰的になり得る。つまり、一つのサーバは、一連のリンクされた応答を他の DNS サーバから受け取れば、それぞれに対する処理を続けて、最終的に権威ある答を手にするまで止めることはしない。あなたのコンピュータには「スタブ」リゾルバが備わっており、これが名前から数字への変換のために本格的な DNS サーバに問い合わせる方法を知っている。一般的には、その本格的な DNS サーバはあなたの ISP またはあなたの働く会社が運営している。すると、その DNS サーバはそれを受けて root ネームサーバ(これはさまざまの組織が運営している)に問い合わせ、そこで例えば .com についての詳細情報が見つかるという手順になる。

この root ネームサーバがあなたの ISP や会社の DNS サーバに対し、そのドメインの検索情報を持っているサーバを教える。この作業は一つのドメイン名に対してドットで区分された一つ一つの部分ごとに繰り返されるが、一般的には次のような道順を辿ることになる: root サーバ、トップレベルのドメイン (例えば .com) のサーバ、それから企業のドメインサーバ、という順だ。

SSL/TLS を弱めるが、殺しはしない -- この攻撃はセキュアなウェブ接続を直接に無効にするわけではない。その代わりに、この攻撃によってあなたが信頼して依存している信号が弱められるので、あなたがもっと警戒を強めることが必要となる。セキュアなウェブ接続は SSL/TLS (Secure Sockets Layer/Transport Layer Security) のメカニズムによって接続を暗号化し、またその接続の外部にある第三者機関に依存してその接続の認証を行なう。これらの接続の基盤となるデジタル証明書は、ドメイン名が特定の IP アドレスに合致していることを要求する。けれども、もしもあなたの DNS が汚染されてしまっていれば、偽物の証明書がはるかに深刻な危険として浮かび上がることになる。

しかしながら、そのような場合には第三者機関が救いの手となるはずだ。証明書は第三者による署名を与えられる必要がある。この第三者は認証局として知られ、例えば Thawte や Comodo のようなところだ。これらの機関は、要求に対して署名を与える前に、その証明書の依頼を出した者の本人確認を検証することになっている。これらの機関は、依頼された証明書についてどの程度の背景チェックやコントロールを行なうかに応じて何万ドルという料金を請求する。これらの機関についての詳細情報はいろいろのブラウザやオペレーティングシステムにあらかじめインストールされており、それによって信頼の輪が完成される。つまり、あなたのブラウザは第三者機関の署名を知っており、そのことによってあなたのシステムは、ウェブのサイト証明書をその第三者機関が認定したことを検証できることになるのだ。

もしもアタッカーによる偽物のサイトが、それが www.amazon.com であると騙った証明書を持ち出してくれば、あなたのブラウザはその証明書が署名を受けていないか、あるいは少なくとも既知の認証局による署名を受けていないという警告をあなたに知らせてくる。そのような警告は、あなたが信用できる人の運営するウェブサイトに接続しようとしていて、その人が使おうとしている証明書についての明確な情報があなたにその人から知らされているという状況でない限り、常に接続を拒否すべき理由だと考えるべきだ。

組織的な修正、ただし Apple を除く -- キャッシュ汚染はそもそもの初めから DNS の問題点ではあったが、今回 Kaminsky が発見したテクニックは従来知られていたどの攻撃よりもずっと高速で有効性が高い。Kaminsky の見つけた欠陥は、サーバが既にキャッシュした既存の DNS 項目をアタッカーが上書きすることを可能にする。これは従来可能でなかったことだ。この脆弱性はプロトコル自体に関する欠陥であり、従って現在使われているほとんどすべての DNS 実装方法に影響を及ばすことになる。

この欠陥が正真正銘の問題であって広く行き渡っていることを確認した後で、Kaminsky は即座にメジャーなベンダーたち、つまりオペレーティングシステムのメーカー各社や DNS ソフトウェアの開発者たちに連絡をとるとともに、2008 年 3 月に Microsoft の構内で開催された DNS 専門家たちの秘密ミーティングでそのことを知らせた。その結果、これは史上前例のないことであったが、すべてのベンダーたちが、United States Computer Emergency Response Team (US-CERT) の手助けの下に互いに協調して、それぞれの製品への修正を同時にリリースすることで合意した。

この脆弱性の正体を分かりにくくするため、各社はポートのランダム化という修正を利用することでも合意した。これならば必ずしもこの欠陥の詳細をあらわにすることもなく、その結果悪い連中がこれをリバースエンジニアして各組織がパッチを施す前にサーバを攻撃する可能性を遅らせることができるだろう。それは 13 日間保った。けれども 13 日後、あるセキュリティ研究者が誤ってすべての詳細を記したブログ記事の原稿をそのまま公開してしまった。そして 2008 年 7 月 24 日までには、実際の攻撃モジュールが有名な Metasploit 侵入テストツールに現われ、その結果このツールをダウンロードしてウェブブラウザを使えるアタッカーならば誰でもこれを武器として使えるようになってしまった。

(この欠陥を簡潔に説明すると、アタッカーはリクエストを送りつけることによって DNS サーバに特定のドメインを検索させようとする。そのために、アタッカーは一連のよくありがちなポート番号を利用して膨大な数の偽物の答を DNS サーバに送る。もしもそのうちたった一個でも偽物の答が通り抜けてしまえば、アタッカーの「勝ち」だ。基本的に、これは悪い奴が百万人のマラソンランナーを出場させ、良い者は彼らがみんな一人で公園ジョギングをしていると思い込んでいる状態でのレースのようなものだ。実際これは、Metasploit を使えばほんの二・三分で実現できてしまう。ここで、リクエストに使われる一連のポート番号をランダム化すれば、悪い奴が勝つために必要な手続きの複雑度が格段に増すことになる。よくありがちなポート番号についての一般的な脆弱度の評価は 2001 年に既に解明され、 DNS サーバ djbdns に内蔵されている。けれどもこの問題に対する真の解答は DNSSEC で、これは公開鍵暗号化を DNS に組み合わせることによって、真性のドメインオーナーのみがそのドメインに関する DNS クエリーに答を提供することができるようにするものだ。DNSSEC はもう何年も行き詰まっていたが、2008 年 3 月になって行き詰まりは解消されたので、この基本的な DNS の欠陥が明らかとなった今、これが本当に役に立つ日が来ることは十分考えられると思う。)

Apple はパントしたが、まだパッチしていない -- Apple はまだこの脆弱性にパッチを当てていない。脆弱性はデスクトップ版の Mac OS X にも、Mac OS X Server にも影響がある。DNS の検索をする個々のコンピュータも脆弱ではあるが、サーバの方がはるかに高いリスクを負っていることは、この攻撃の性質と影響の範囲を考えれば明らかだろう。

Apple は有名な Internet Systems Consortium の BIND DNS サーバを利用している。これは最も早くパッチされたツールの一つだったが、Apple はこのプロセスの初期の段階で通知を受け、組織的なパッチのリリース日も知らされていたにもかかわらず、まだこのツールの修正版を Mac OS X Server に含めることをしていない。

Mac OS X Server のユーザーでこれを再帰的 DNS のために使っている人はすべて、今すぐ別の方法に切り替えなければならない。そうしなければ、攻撃を受けてトラフィックのリダイレクトを実行されてしまうリスクを負うことになる。上で述べた BIND をインストールすることは、コマンドラインでソフトウェアをコンパイルできる人ならば誰でも簡単にできるはずだ。Mac コミュニティーとしては、誰かがコンパイル版の BIND 9.0.5-P1 を作ってそれを配布し、簡単にインストールできるようにすることを考えてはどうだろうか。

一般的に知られた攻撃ツールでアクティブな攻撃コードが利用可能となっている現状では、Apple がこの脆弱性を修正することが緊急に必要だ。彼らはプロセスの初期の段階から加わっており、他のベンダーたちはそれぞれの製品をタイムリーに修正することができているのだから、Apple がぐずぐずしていることを正当化する理由があるとは想像しにくい。

もしもあなたがサーバシステムを新しいコードでパッチすることができないのならば、それらのサーバの設定を変えて、DNS リクエストをすべて別のプラットフォームへ転送するようにすればよい。例えば Linux または Unix の BIND、あるいは Microsoft のサーバなどに切り替えて、Apple がパッチを出す日を待つのだ。その方法についてはあなたの ISP やネットワークプロバイダに助けを求めるとよい。

デスクトップ版の Mac OS X も厳密に言えば脆弱だが、現在ある攻撃はサーバに向けられたものなるので、あわてる必要はない。

今回のことは非常に深刻なセキュリティ上の問題であるので、私たちとしては出足の遅れてしまった Apple に、ぜひとも責任ある行動と即座の対処を願いたい。

[Rich Mogull による著者注: 私はこの脆弱性に関する当初のコミュニケーションと組織的なリリースに関して Dan Kaminsky を援助して働いた。最初のエグゼクティブ・サマリーを参照されたい。]


TidBITS 監視リスト: 注目のソフトウェアアップデート、28-Jul-08

  文: Adam C. Engst <ace@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>


TidBITS Talk/28-Jul-08 のホットな話題

  文: Jeff Carlson <jeffc@tidbits.com>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

iPhone 3G カーアクセサリ -- 既存のアクセサリのうちどれが iPhone 3G で使えるのか? 従来の iPhone で使えたものでも、この新機種では正しく働かないものがある。(メッセージ数 8)

MobileMe が動かない -- MobileMe でトラブルに出会った読者たちが体験談を交換する。(メッセージ数 3)

トップレベルのドメイン名にバニティの波が -- 近い将来に .engst ドメインが登場するなどと期待してはいけない。(メッセージ数 3)

TidBITS 監視リスト: 注目のソフトウェアアップデート、28-Jul-08_ -- 最新の iWeb アップデートで、長年来のバグが解消された。(メッセージ数 2)

iPhone 同期の問題 -- コンタクト情報の同期で問題が起こったら、いったん Address Book をバックアップからリストアした後でもう一度同期し直してみるのも一つの方法だ。(メッセージ数 4)

500 ギガドライブ3基の構成方法? -- 合わせて 1.5 TB にもなるストレージを目前にして、ある読者がこれらのハードドライブをセットアップするベストの方法への助言を求めている。(メッセージ数 16)

TCo Your iPhone アップデートへのアイデア募集 -- Ted Landau は彼の電子ブック Take Control of Your iPhone のアップデートを計画中だが、新しい iPhone 3G や iPhone 2.0 ソフトウェアについて、どんな内容を含めるのが最も重要だろうか? (メッセージ数 4)

iTunes 7.7、アクセント付きのアーティスト名・トラック名を壊す_ -- iTunes 7.7 のこの問題に、読者たちが体験談を寄せる。(メッセージ数 5)

携帯電話を Mac と同期 -- iPhone 以外の携帯電話との間で同期をとるには、どんな方法があるのか? (メッセージ数 1)

iPhone/Windows パスワード管理 -- 重要なパスワードをすぐ使えるようにセキュアなコピーにしてとっておくのは理にかなっているが、どのプログラムならばそれが提供できるのか? 特に Windows 下では? (メッセージ数 1)

盗まれたラップトップ -- ある読者のラップトップ機が盗まれた。パスワード保護がオンになっていても自分のデータに盗人がアクセスできてしまうことがあるのだろうか、と彼は思案する。(メッセージ数 4)


tb_badge_trans-jp2 _ Take Control Take Control 電子ブック日本語版好評発売中

TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示:書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

©Copyright 2008 TidBITS: 再使用は Creative Commons ライセンスによります。

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