TidBITS: Apple News for the Rest of Us  TidBITS#1131/25-Jun-2012

今週はいろいろな話題が集まった。セキュリティ編集者 Rich Mogull による特集記事は、サンドボックス、Mac App Store、Gatekeeper についての広範囲にわたる質疑応答だ。タイムリーな記事は他にもあって、Adam Engst が SOHO Organizer を使って iCloud にある連絡先情報を Lion 以前の Mac に同期する方法を説明するとともに、問題のあった Thunderbolt Software Update 1.2 を Apple が修正したことを続報し、Agen Schmitz が MacBook Pro の Retina ディスプレイモデルに関するさまざまなレビュー記事を総まとめする。Michael Cohen はタイムリーさを風の流れに乗せて、1982 年の New York Times 記事を振り返る。当時 NSF に委託されて書かれ、コミュニケーションとコンピューティングの未来について驚くほど的確な予知能力を示した、ある報告書を要約した記事だ。今週注目すべきソフトウェアリリースは、TextExpander 4.0、Skype 5.8.0.865、それに Bento 4.1.1 だ。

記事:

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

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


Thunderbolt Software Update 1.2.1 リリース、Apple が謝罪

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

Apple が、リリースノートに何の変更をすることもなく、Thunderbolt Software Update 1.2.1 をリリースして Thunderbolt to Gigabit Ethernet Adapter のサポートを追加した。このアップデートのバージョン 1.2 は起動の障害を起こすことが問題になっていた。(2012 年 6 月 12 日の記事“Thunderbolt Software Update 1.2 が起動障害を起こす”参照。)Apple はこの問題に対処したと思われるが、ユーザーたちの声が届き始めるまで確かなことは言えない。嬉しいことに(そして珍しいことに)Apple はこのアップデートのバージョン 1.2 が引き起こした問題を認め、混乱を招いたことを謝罪し、復元方法の情報を提供した。

フレッシュにインストールしたものに比べてサンプルしたサイズは小さくなるものの、私たちとしてはあなたが Thunderbolt to Gigabit Ethernet Adapter を持っていてそれをあなたの MacBook Air または Retina ディスプレイ搭載 MacBook Pro で使う必要がある場合を除いて、インストールをお勧めすることはできない。(このアダプタは Thunderbolt 搭載のどんな Mac でも働くけれど、上記以外の機種はすべて専用の Ethernet ジャックを持っているはずだ。)少なくとも Apple がリリースノートで述べている限りでは、このアップデートは他に何の役にも立たない。

Apple が問題の存在を公に認め、混乱を招いたことを謝罪した点についてそれを悪く言うつもりは全くないし、これは Apple としては非常に喜ばしい変化だと思うが、Apple が Thunderbolt Software Update 1.2 の配布を取り下げるまでに数日かかったという事実は指摘しておかなければならない。その間、何万人もの Mac ユーザーたちが Mac OS X の再インストールをしてそれぞれ何時間も無駄に過ごす羽目になったかもしれない。その数日の間、TidBITS や他の Mac メディアサイト、あるいはソーシャルネットワーキングなどを通じて素早く知らせが広められ、いったいどれほど多くの人々が影響を受けたかを具体的に知ることはできないけれども、きっと相当な数の人々が該当したことだろう。メディアが噂や論争ばかりに力を注いでいるように見えるこの時代、今回のことは独立系のテクノロジー報道が持つ本当の価値を示す、非常に良い実例となった。

コメントリンク13077 この記事について | Tweet リンク13077


MacBook Pro Retina ディスプレイモデル: レビューのレビュー

  文: Agen G. N. Schmitz: agen@tidbits.com
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

「画期的な」から「びっくり仰天の」まで、思い思いの褒め言葉で飾りながら、初期のレビュー(批評)記事の執筆者たちは最近リリースされた MacBook Pro の Retina ディスプレイモデル(2012 年 6 月 11 日の記事“新型 MacBook Pro、Retina ディスプレイ、フラッシュメモリを搭載”参照)を語りつつ、見た目に派手な Apple の紹介イベントの会場で多くの人たちが感じた期待外れの気持ちをあえて無視しているかのように見える。さまざまのレビュー記事は一様に、Apple の古典的機種に対する今回のアップデートには相当惚れ込んでいるらしい。これほどに称賛が前面に出ているけれども、事実だけを見ればこの新型 MacBook Pro の多くの様相は、高解像度の Retina ディスプレイから全体的なユーザー体験をキビキビとさせるフラッシュメモリのストレージの採用まで、どちらかと言えば革新的 (revolutionary) というよりむしろ漸進的 (evolutionary) というべきものであった。(Apple のハードウェアアップグレードの多くが比較的控え目であると論じた Glenn Fleishman の記事“漸進的改善が Apple に大きな進歩をもたらす”(2012 年 3 月 29 日) を参照。)

私たち TidBITS スタッフの中でレビュー用のユニットを手にしたのは Jeff Carlson ただ一人だった。残念なことに、彼は別の仕事(Seattle Times とかいう名前の安っぽい新聞)で実地体験のレビュー記事を書くのに忙しかった。そこで、今回はインターネットを見回して、彼を含めたレビュー執筆者たちがどんなことを言っているのか調べてみたいと思う。

新型 MacBook Pro のメインとなる機能、つまり 2880 × 1800 ピクセルの解像度を持つ 15.4 インチの Retina ディスプレイについては、Macworld の Roman Loyola が MacBook Pro の解像度設定を Best (Retina) とすれば写真の細部もテキストも驚くほど鮮明になると書いている。ただ、彼は自分がシステムの警告文を読み過ぎて目眩がするような気持ちになったとも言う:「この Retina MacBook Pro のお陰で Mac OS X の細かな部分に対する理解が再び呼び覚まされたが、まあ時が経てばそれもまた当たり前になるのだろう。」

これほど多くのピクセル数を持つ (正確に言えばインチあたり 220 ピクセルなので合計で 518 万 4 千ピクセルとなる) ことの一つの難点は、Retina ディスプレイ用に最適化されていないソフトウェア(レビュー記事に挙げられた例は二つ、Adobe InDesign と Twitter だった)による画像やテキストのレンダリングが美しくないことだ。けれどもTechCrunch の MG Siegler にとっての Retina ディスプレイの最大の問題は、ウェブブラウザにおけるテキストや画像のレンダリングが精彩を欠くことだ。それは、このディスプレイ用にまだアップデートされていないもの (例えば Google Chrome は現在 Retina 対応を開発中だ) のみならず、既に Retina 用に最適化ができている Safari にも言える。彼はこう言う:

「Retina ディスプレイで素晴らしい見栄えになるアプリの実例が見たいなら、Apple のアプリ (iPhoto、iMovie など) を試すか、または Safari で apple.com を訪れるとよい。それ以外は、現時点ではまだお寒い状態だ。そのアプリやサイトがどれほどグラフィック中心かどうかにもよるが、アップグレードを実現することは開発者にとって大仕事となるというのが現実なのだ。」

ピクセルがぎっしり詰まったこのディスプレイに表示するために最適化された Retina 設定を選ぶことに話を戻すと、 Engadget の Tim Stevens は具体的な数字によって解像度を選ぶ選択肢がないことに不満を述べている。その代わりに、Display 環境設定パネルには5ポジションのスライダーがあって、Larger Text から More Space までの5段階から1つを選ぶようになっている。真ん中の選択肢が Best (Retina) だ。彼はこう言う:「たぶん初心者にはこの方が分かりやすいのだろう。ただ、忘れないで欲しい。これは 'Pro' という名前の付いたラップトップ機なのだ。」('Pro' の意味を実感でできないという人には、このマシンが 一度に4台のディスプレイを それぞれのネイティブな解像度で走らせることができるという事実をよく考えてもらいたい。)

Jeff Carlson は、 Seattle Times のレビュー記事 で、このスクリーンの解像度には確かに感銘を受けたけれどもやはり「まだ光沢がある、ただし標準的な MacBook Pro のスクリーンに比べれば反射が少ないので、その点は良くなったと言える」と述べている。

しかしながら、Jeff にとってこの新型 MacBook Pro の一番の機能は Retina ディスプレイではない。それは、彼がいつも仕事机の上の外付けモニタに向かいっぱなしで仕事をしているのが大きな原因だ。一番は、このマシンの猛烈なほどのスピードだ。レビューに使ったユニットに搭載された 2.3 GHz Intel Core i7 プロセッサとソリッドステートドライブの組み合わせのお陰で、Jeff は Adobe InDesign をたった 3 秒で開くことができた。(彼が 2 年前に買った MacBook Pro では 25 秒かかる。)

モバイルな用途にもっと使えるようにと考えている人たちのために、 Engadget がバッテリ消費のテストを実施して、2.6 GHz Core i7 機種で 7 時間 49 分、2.3 GHz Core i7 機種で 9 時間 22 分という結果を得た。Apple が公表しているバッテリ寿命 7 時間という数字を、良い結果で裏付けた訳だ。しかしながら、 All Things D の Katherine Boehret はこの MacBook Pro を彼女独自の「標準バッテリテスト」にかけてみた。それはどうやらこのラップトップ機を典型的なユーザーの使い方を超えてストレステストにかけるもののようで、まずスクリーンの輝度を最大にし、省電力設定をすべてオフにし、エンドレスで音楽を再生し続け、Wi-Fi と電子メール受信を常時オンにした。Boehret によるこのテスト結果(二度実施した)の平均は、4 時間をほんの少し超える程度のバッテリ寿命となった。ただ、彼女の推測ではもっとストレスの少ない条件下ならばこの MacBook Pro は間違いなく 5 時間を超えるバッテリ寿命があるだろうとのことだ。

Laptop Magazine の Mark Spoonauer は、この Retina ディスプレイモデルの MacBook Pro に新たに搭載された「非等間隔ファン」のお陰でラップトップ機がプロセッサ負荷の大きいタスク(例えば HD ビデオの編集など)を処理している際の騒音レバルがはっきりと下がったことに気付いた。しかしながら、キーボードが発する熱のレベルは「私たちが不快と思い始める程度をはるかに超えた」華氏 105 度 (摂氏 40.5 度) だった。タッチパッドやラップトップ機の底面はもっと温度が低かった。

[訳者注:非等間隔ファンに関しては、詳細な日本語説明サイト"MacBook Pro with Retinaの冷却ファンは常識破りの素晴らしい発想!: 【Digitalian's Tips】"があります]

ゲームをする人の観点に立って、 The Verge の Ross Miller が Diablo 3 を 2.6 GHz Core i7 プロセッサと 8 GB の RAM を持つ新型 MacBook Pro でテストした。最大解像度でこのゲームを走らせ、「ゲームの飾り物を最大に」引き上げた。(シャドウ、特殊効果、といったものだ。)彼の結果はこのゲームが「毎秒 15 から 20 フレームの間を行き来し、たいていの場合かろうじてプレイできる程度だった」けれど、解像度を下げて 1680 × 1050 (つまり標準の MacBook Pro の解像度) にすれば一貫して毎秒 30 フレームが提供されプレイしやすくなったとのことだ。

この Retina ディスプレイモデル MacBook Pro を、The Verge がその定評通りに華麗かつテンポ良くビデオでレビューしている。一見の価値ありだ。要約として Miller が次のように語っているが、これは他の多くのレビュー執筆者たちの気持ちをも代弁していると思う:

「この新型 MacBook Pro の Retina ディスプレイモデルは本当に、Apple が MacBook の分野で学んできたすべてのことの頂点にあると言ってよい。もちろん、これは世にある MacBook Pro の中で最も高価なものであって、世にあるラップトップ機すべての中でも最も高価なものの一つだ。でも、もしも予算が問題でないのなら、これこそ今あなたが買える最高のラップトップ機だ。」

コメントリンク13081 この記事について | Tweet リンク13081


SOHO Organizer、Snow Leopard で iCloud と連絡先を同期

  文: Adam C. Engst: ace@tidbits.com, @adamengst
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

30 June 2012 の MobileMe 終焉の日が本当に間近に迫るにつれ、人々は引き続きMac OS X 10.6 Snow Leopard が走る Mac を iCloud エコシステムに統合する方法を探している。Apple は iCloud を CalDAV や CardDAV と言った標準に準拠させているにも拘らず、このことはこれまで必ずしも自明のことではなかった。カレンダーに関しては、我々はこれまで二つの解について書いてきた:BusyCal ("BusyCal が iCloud カレンダーを Snow Leopard にもたらす" 5 December 2011) そして iCal ("Snow Leopard の iCal も iCloud に参加出来る" 11 December 2011) である。しかし、連絡先を iCloud と同期させる良い解を探すのはより困難であった、と言うのも iCal を iCloud に向けさせるのに成功したやり方はAddress Book には通用しなかったからである。

いまだ Snow Leopard を走らせている完璧に機能的な Mac をお持ちの方には、理由は何であれ、朗報だと思うが、我々は連絡先を iCloud と同期させる方法に出くわした。これは無料ではないが、簡単である - Chronos からの $99 の SOHO Organizer 9 である。この機能は SOHO Organizer にとっては比較的新しいもので、バージョン 9.1.8 で登場したのだが、Chronos はその導入以来改良を加えてきた - 現行バージョンは 9.2.6 である。事実、SOHO Organizer が必要とするのは Mac OS X 10.5.8 かそれ以降のみであり、10.5 Leopard から 10.7 Lion 迄のいずれのバージョンの Mac OS X でも走らせられる (そして、まだテストはしていないが、我々の想定では 10.8 Mountain Lion も) Mac 上で iCloud 連絡先にアクセスしたいという人には誰にでも有用なものとなっている。

SOHO Organizer は、実際には三つのアプリケーションからなるスイートである:SOHO Organizer、連絡先とカレンダーの管理;SOHO Notes、メモとスニペット保存のユーティリティ;そして SOHO Print Essentials、SOHO Organizer から必要なデータをインポートし、ラベル、封筒、レターヘッド等をデザインし印刷する手助けをする。ここでは SOHO Notes や SOHO Print Essentials については扱わない - これらも有用なプログラムの様であるが、この記事の範疇ではない。

また SOHO Organizer のカレンダー機能についても扱わないつもりであるが、これは実際に iCloud カレンダー同期問題に対する第三の解であると言える。と言うのも、これは BusyCal の様に、iCloud と (そして Google Calendar も) 同期出来るからである。私が理解できる範囲で言えば、SOHO Organizer は基本的に BusyCal や iCal と同じ機能を提供している - もし私が SOHO Organizer を最初に買っていたのであれば、BusyCal を買う前に私のニーズには答えられるか検討したと思うが、今では幸せな BusyCal ユーザーの一人としては、SOHO Organizer のカレンダー機能を検証してみる必要性をそれ程感じない。

そして最後の警告としてだが、私はあなたが既に MobileMe アカウントから iCloud への乗り換えは済んでいて、単に Snow Leopard が走る Mac 上であなたの iCloud 連絡先へのアクセスを得ようとしているのだと想定している。もしこの乗り換えをするのに助けが必要だと言うのであれば、その詳細を説明している Joe Kissell の "Take Control of iCloud" のコピーを手にすべく今すぐ走る必要がある、歩いている暇はない。

連絡先のために SOHO Organizer を設定しそして使用する -- SOHO Organizer スイートには他の色々な能力が備わっているが、iCloud との連絡先同期のための設定は極めて簡単である。やらなければならないことは Preferences ウィンドウを開いて、Accounts をクリック、アカウントを追加するため + ボタンをクリック、iCloud Contacts を選択、そしてあなたの iCloud ユーザー名 (全メールアドレス) とパスワードを入力する。SOHO Organizer は、残りの詳細を舞台裏で埋めてくれ、接続をし、そして全てのあなたの連絡先をダウンロードする。

image

私はそもそも Address Book を好きになったことが無かったし、Lion での模造革バージョンは大嫌いである。と言う訳で私には、連絡先情報を表示する SOHO Organizer のやり方が、必要なものは全部すっきりと揃っておりしかも使い易いと思えた。ウィンドウの左上部に位置する一連のボタンでビューが切り替えられる。最初の二つが連絡先、次の五つがカレンダー、そして最後の一つがジャーナルビューである。Contact Card ビューは、グループをそして次に名前を最初の二つのコラムから選ぶと表示される。そこにあるデータには通常想定されるものはすべて揃っている:名前、住所、電話番号、メールアドレス、携帯メールアカウント、誕生日、そして関係が含まれるが、更に添付ブロックがあり、そこにはその人宛ての或いはその人からのメールメッセージのリスト、電話通話、テキストメッセージ、カレンダー行事、メモ、ファイル等々を入れることができる。更に幾つかのブロックを追加することもでき、URL、追加の住所、ノート、等々である。加えて、名前のブロックを拡張バージョンに切り替えることもでき、敬称、サフィックス、ミドル名、ニックネーム、役職、所属、名前の読み方、そして旧姓のフィールドが追加される。

image

このデータの多くは "生きて" いて、例えば、メールアドレスの隣に付いている小さなアイコンをクリックするとそのアドレス宛てのメッセージを作成できたり、配偶者や子供の名前の隣のアイコンをクリックするとその人のカードに切り替えられるといった具合である。他のアクションには、住所を地図表示する、電話番号に電話をかける、SMS メッセージを送るが含まれる。また、添付リストにあるメールメッセージ等々をダブルクリックするとそれらを開ける。

Contact Card ビューの他に Contact List ビューもあり、ある特定のグループの全ての連絡先をスクロールリストに表示でき、しかも数多くのコラムが選択出来る;表示するコラムを選択するには View > Contact List Columns で出来、そしてドラッグによる再配置、リサイズ、そしてソート (二次ソートのためには Shift-クリック、Last Name, 次に First Name という様に) が出来る。リスト項目にあるデータをダブルクリックすることでそれを直接編集でき、そして Open in Contact Card ボタンをクリックすると詳細がある Contact Card ビューに切り替えられる。

image

SOHO Organizer には他にも連絡先に関する幾つかの優れものがある。重複カードやカード内の情報を検索出来る。カードを統合することも、違いが表示されるので簡単である。また、ある人のカードを他の人の上にドラッグすることで、その人達の間に双方向の関係を作り出せる;これを使って、ある人を誰かの配偶者、子供、上司、部下、等々として関係づけられる。Contact Card ビューでより高速に誰かを探すために、SOHO Organizer は Alphabet Bar を提供しており、姓が特定の文字で始まる連絡先へとジャンプさせてくれる。最後に、複数のウィンドウを開くことが可能で、 Contact List と Contact Card ビューの両方を同時に見ることもできるし、複数のカードだけというのも問題ない。

SOHO Organizer 及び連絡先管理に対するその伝統的なアプローチで私には欠点に見える主たるものは、Facebook, Twitter, LinkedIn といったソーシャルネットワーキングサービスにつなげるという概念が全くないことである。最近リリースされた Cobook にはこれがある ("Cobook 1.0" 25 May 2012 参照)。私がテストした Mac の中の一台 (これだけ) では多少の性能問題を経験したが、これはある特定のズームレベル、或いは再スタートすることで解決したデータベースの破損に関係していたのかもしれない;Chronos は私の報告に極めて良く対応してくれており、バージョン 9.2.7 がマイナーな変更とともに間もなく入手可となるはずである。

Address Book へのリンクは無い -- SOHO Organizer は iCloud がホストする連絡先とは完璧に動作するとはいえ、変更を取り込んだり送り出したりするのは問題ないが、Leopard や Snow Leopard の下で走らせている人達には、一見しては明らかではないが、これが使えない原因となり得る一つの大きな限界がある。SOHO Organizer が iCloud から取り込み同期する連絡先はサイドバーにある iCloud コレクションに現れるが、そこにしか現れない。Lion の下で走らせている人には、これだけで十分である。

しかし、Leopard 或いは Snow Leopard バージョンの Address Book にある連絡先にアクセスしたい場合、或いは、Lion 以前のシステムに蓄えられた Address Book のデータを共有する Cobook や Apple Mail の様な他のプログラムではどうなるのであろうか? 残念ながら、あなたの運もここまでである。但し SOHO Organizer にはサイドバーに別のコレクションがあり - Personal (On My Mac) - そこにある連絡先は全て Snow Leopard の Sync Services を使い Address Book 及び他の全ての Address Book を認知するプログラムと同期する。

iCloud コレクションにあるあなたの全ての連絡先を選択しそしてそれらを Personal (On My Mac) にドラッグしてコピーすることも 可能 であり、そうすればこれらは Address Book にも現れる (フィールドラベルに破損があると同期が阻害されることもあるのでご注意を - もしこれが起こったら、同期するのは一度に小さなグループで行い、問題のある連絡先を見つける)。これでこれらの連絡先に対する読み取りアクセスは得られるが、どうしても 出来ない のは、変更を加えそれらを iCloud コレクションに同期戻しすることである。私は、これらを Personal (On My Mac) から iCloud へとドラッグして戻してみるのをやってみたが、結果は iCloud バージョンの連絡先が破損してしまうか削除されてしまう傾向にあった。たとえこの方法がうまくいったとしても、それは満足できる解とは言えないであろう。何故ならば、これはカードを手でコピーすることとデータの確認も自分で行いそして何が新しく何が古いのかを見極めなければならないからである。そもそも我々が同期ツールを使うのはそのためなのである!

理論的には、Chronos が iCloud と Personal (On My Mac) コレクションの間で同期する機能を追加することは可能であろうが、これが必要なのは Snow Leopard 上の Address Book にある iCloud 連絡先にアクセスする必要がある人だけであることを考えると、そのための開発努力を正当化するのは難しいのではないだろうか。

結論としては、SOHO Organizer はそれ自身が機能豊富な連絡先管理プログラムであり (他の能力に言及するまでもなく)、そして Snow Leopard 及び Leopard ユーザーに対する iCloud 問題に対する一つの解でもある。これだけでも $99 という価格に見合うものである。30 日の試行版も 77.6 MB のダウンロードとして出されている。

コメントリンク13049 この記事について | Tweet リンク13049


1982 年の未来を今日の現在と比較する

  文: Michael E. Cohen: mcohen@tidbits.com
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

1982 年の 6 月は、IBM 5150 (初代の IBM 製 PC) が世に出てまだ一年も経たない頃だった。Apple の売れ筋は Apple II+ で、初代の Macintosh が登場するのも あとたった一年半後に控えていた。インターネットはそもそもまだ存在せず、この "internet" という単語は TCP/IP を利用する非商用のネットワークのみ、例えば ARPANET や MILNET といったものをあいまいに一括りにした意味に使われていた。

その同じ月、 New York Times 紙上に、National Science Foundation (NSF, 全米科学財団) の報告書 "Teletext and Videotex in the United States" が近々リリースされるという記事が掲載された。この報告書には、米国において 1998 年に至るまでに電子的通信のテクノロジーがどのような影響を及ぼすだろうかという予測が展開された。New York Times 紙上に掲載された要約を見ても分かることだが、この報告書は、たとえテクノロジー的な詳細は奇妙なほど的外れであり、コンピューティングの分散化(非集中化)という点を見逃していたとしても、電子的通信が社会に及ぼす影響について驚くほど正確な未来予想となっていた。

Teletext と Videotex -- この報告書は National Science Foundation に委託されてカリフォルニア州 Menlo Park にある Institute of the Future の John Tydeman が執筆したものだが、二つのタイプの家庭用システムを想定した。一つは一方向のコミュニケーションシステムで "teletext" と名付けられ、もう一つは双方向のシステムで "videotex" と名付けられた。報告書の大部分は双方向システムの持つ変革的効果の分析に向けられ、New York Times 紙の記事では「コミュニケーションとコンピューティングという二つの旧テクノロジーの融合により生まれつつある videotex 業界」に基づく双方向システムだと説明された。

この videotex のサービスは家庭用「ターミナル」を通じて届けられ、二十世紀の終わりまでに米国の 40 パーセントの家庭で使われるようになるであろう、またその供給力は広告によって推し進められ資金的支援を受けるようになるであろうと予想された。現実に起こったことを見れば、その家庭用ターミナルの役割をパーソナルコンピュータが担い、videotex サービスとは現実にはさまざまのプロバイダを通じてさまざまの手段で行なわれるインターネットとワールド・ワイド・ウェブへの接続のことであった。

では、家庭用インターネットサービスの数字を比較すると? 報告書が予想した 1998 年での家庭普及率は楽観的に過ぎるもので、U.S. Census のデータによればその年の実際の家庭普及率は 26.2 パーセントに過ぎなかったけれども、そのたった二年後には既に米国におけるインターネットに接続した家庭の割合が 40 パーセントを超えていた。(現在では 75 パーセントを超えている。)

コントロールとコンテンツ -- 報告書は人々が videotex システムを使って、利用できる情報のタイプを調整したり組み合わせたりする様についても語っている。いわく、videotex サービスの購読者たちは「自分たちで独自の新聞を作ったり、自分たちに合ったカリキュラムをデザインしたり、自分たち独自の消費者ガイドを作ったりするだろう。」

現実には、大多数の人々は報告書が想像したほどには生産的でも組織的でもなかった。その代わりに、新世紀に入った当時の圧倒的多数のユーザーたちは、ただ一人一人バラバラに、まとまりなくウェブブックマークをやたらと集めて、その代わりますます高機能になる検索エンジンに依存するようになった。当時優勢だった AltaVista や、生まれたばかりの Google といった検索エンジンの力を借りて、それぞれ欲しい情報に向かって「サーフィン」したのだ。おそらくこれは間違いないと思うが、 Flipboard のようなアプリや、Paper.li のようなサービス、そしてもちろん iTunes U や Khan Academy などから入手できる膨大な講義のコレクションなどがある現在では、私たちは報告書の予想にずっと近い位置にいるのだろう。

報告書は videotex システムが広く使われることの負の側面についても触れていて、そのような状況が「新たな種類の市場操作やソーシャルエンジニアリングを、政治的または経済的利得のために生み出してしまう危険がある」と書き添えている。これまでフィッシングで個人情報を盗まれてしまった人たちや、インターネット詐欺にひっかかった人たち、あるいは架空の政治的スキャンダルを扱った虚偽のニュース記事に惑わされたことのある人たちは、報告書のこの部分の先見の明に気付くだろう。さらには、Angry Birds や FarmVille などの 「馬鹿馬鹿しい」ゲームの類いも、経済的利得のための市場操作の一つと言えるかもしれない。

報告書にはまた、そのようなシステムが「家庭の住人たちの嗜好や挙動をその家庭の外へと持ち出す情報の流れを作り出す」ことの危険についても述べている。当然ながら、この予測はインターネット時代が生み出したプライバシー喪失の状況を正確に映し出すことになったけれども、実は 1982 年に危険と思われていたことの多くは、現在では既に Google、Facebook その他の会社のビジネスモデルにおいて社会的に受け入れられた一部となっており、これらの会社はその種の情報に依存してターゲット広告を届けることで(広告主にとっても訪問者にとっても)有効性を上げようとしている。

変革的効果のチェックリスト -- 予測によれば、videotex サービスが利用できることにより、家庭生活にも、ビジネスにも、また政治にも多くの変化が生じるとされた。それらの予測のいくつかを、一つ一つ見て行こう:

知ってさえいたら -- この報告書が出版された 1982 年当時は、National Science Foundation がこのような報告書を出すのは政府資金の無駄遣いだと非難する人たちも多かったに違いない。けれども、たとえそうだったとしても、これは薄気味悪いほど正確なる無駄遣いであったと言える。当時たまたまこの報告書を読んで、それに注目して、その予測を念頭に置いて長期的なビジネス戦略やキャリア選択を練った人たちは、予測された変化が大筋においてその通りに起こったことで、きっとその恩恵を受けられる立場にいたことだろう。

でも悲しいことに、報告書には空飛ぶ自動車のことが何も書いてない。ねえ、二十一世紀には、空飛ぶ自動車ができるはずじゃなかったっけ?

コメントリンク13073 この記事について | Tweet リンク13073


サンドボックス化、Gatekeeper と Mac App Store について質問に答える

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

Apple は、Mac プラットフォームにおける大きな移行のただ中にある。多くのユーザーが Mac に集まるようになるにつれて、犯罪者たちも集まってくるのは自然な流れと言える。市場に占めるシェアが増えるに従って、Mac コミュニティーが犯罪者たちにとって十分金になるターゲットとなるからだ。けれども、Apple は明らかにこのリスクを認識している。現時点でマルウェアが存在しない iOS の世界から教訓を得て、Apple は Mac OS X 10.5 Leopard のリリース以後 Mac OS X のセキュリティを強化し続けてきた。初めのうちはゆっくりとであったが、最近は大きくそのペースを上げつつある。

Apple の戦略は五つの技術的な柱に支えられている。Mac OS X の基礎を成すセキュリティを強化すること、(今日最も頻繁に攻撃の手段に使われているのはウェブブラウザなので) Safari を堅牢にすること、攻撃の手段を制限するためにアプリがサンドボックス化のテクニックを使うよう奨励すること、Mac App Store からできる限り悪意あるアプリケーションを排除すること、それから 10.8 Mountain Lion 以降では、Gatekeeper を用いることによってユーザーがアタッカーに騙され悪意あるアプリケーションをダウンロードし走らせる可能性を減らすこと、以上の五つだ。

でも私たちはこれを単に技術的な戦いがエスカレートし続ける状況とのみ捉えるべきでない。これらの変更における Apple の真の目標は、とりわけ Mac App Store、サンドボックス化、Gatekeeper という組み合わせを巡る目標は、悪者たちがビジネスを続けて行けるような経済状況を破壊することにあるのであって、偶発的な小競り合いがいつまでも延々と戦われることを目指したものではないのだ。

Uncle Ben[訳者注: Spider-Man の登場人物]の言葉にある通り「大いなる力には大いなる責任が伴う」ものだ。Apple が Mac OS X の中に (Apple により) コントロールされた使用体験の比重をより大きくするにつれて、怖れを抱くユーザーもいるだろう。それはまた、多くの開発者たちにとっての問題ともなり得る。Cupertino における最大の課題は、コントロールと自由との最適なバランスを見つけ出し、それを保持することだ。つまり、1984 年以来 Mac をこれほどまで魅力的なものとしてきた革新的な精神を持ち続けたいのならば。

ここでは、特にサンドボックス化と Mac App Store、それに Gatekeeper について特に焦点を絞って検討してみたい。これら三つこそが、攻撃に対する防御として最も有望な手段を提供すると同時に、Macintosh の魂にとって最も大きなリスクを生み出すものでもあるからだ。この記事は一連の質問に対する回答という形でまとめてみた。さらなる質問をお持ちの方は、どうぞコメントとして質問を寄せて頂きたい。

サンドボックス化とは何か? -- 実際的に言えば、サンドボックス化によりアプリケーションがあなたのコンピュータに予想外のことをすることがなくなる。それぞれのアプリケーションを分離し、それらがあなたの Mac 上でできることを最小限に抑えるために、サンドボックス化は一連のテクニックを指定して包み込む。その背後にあるのは、アプリケーションは意図的にも、またはアタッカーに改変された結果としても、あなたのコンピュータに害を及ぼすことがあり得るので、アプリを「サンドボックス」の中に押し込めることによって潜在的な損害に限度を設けようという考え方だ。サンドボックス化されたアプリケーションは、何が実行可能なアクションかを厳しく規定した一連のルールの下でのみ、あなたのコンピュータの残りの部分とやり取りすることが許される。このサンドボックス化は、ずっと以前から存在しており、Mac OS X や Windows、その他のオペレーティングシステムで既に使われている。

その動作の方法をごく単純化して説明しよう。普通の、サンドボックス化されていないアプリケーションは、あなたのコンピュータ上のすべてのものにフルにアクセスできる。ファイルシステム上のどこにあるファイルでも読み書きでき、ネットワークのトラフィックを傍受したり送信したり、あなたがタイプするものを監視したり、あなたのカメラやマイクロフォンをコントロールしたり、その他いろいろのことができる。(技術的に言えば、アプリはそれがどの保護リングの中で走っているか、どのユーザーアカウントがアクティブかによって限定を受けるが、その点はここでの議論の本筋にあまり関係がない。)たとえそのアプリがそうした機能のすべてを利用するようプログラミングされていなかったとしても、アプリにできる範囲をオペレーティングシステムが制限することはない。だから、コンピュータを攻撃するための最も一般的な方法の一つは、脆弱性を持つアプリケーションを見つけ出し、その脆弱性を突いてそのアプリケーションの中に悪意あるコードを注入し、それからそのアプリケーションを用いてその悪意あるコードを走らせ、さらなるアクションを実行する、というものだ。

これとは対照的に、サンドボックス化されたアプリケーションはフルアクセスを持って動作しない。その代わり、そのアプリケーションは限定を受けたコンテナの内部で動き、あなたの Mac の残りの部分とは隔離される。だから、たとえアタッカーがそのアプリの脆弱性を突いて悪意あるコードを注入したとしても、その悪意あるコードもまたそのサンドボックスの中に制限される。

シンプルな独立動作のアプリ、例えば気軽なゲームなどでは、何の問題も起こらないだろう。Angry Birds ゲームなら、簡単にサンドボックス化できる。けれどももっと複雑なプログラムでは、サンドボックス化は直ちに問題を引き起こす。例えばファイルを保存したり、ネットワークにアクセスしたりといったことだ。この問題を回避するため、個々のアプリケーションには Mac の他の部分への限定的なアクセスを許す一連の「entitlement (資格)」が付与される。例えば、フルにサンドボックス化され何の entitlement も与えられないアプリはそれ自身の持つディレクトリ以外の場所にファイルを保存することができないけれども、entitlement が一つ認められることで、そのアプリがあなたのホームフォルダの中のどこにでもファイルを保存できるアクセス権が与えられる。(そのような状態でも、アプリがファイルシステムのどこにでもファイルを保存できるよりはまだ安全だと言える。)

iOS のアプリは厳しくサンドボックス化されている。iOS のアプリがお互いのファイルにアクセスできないのはこれが理由だ。iOS は写真以外の共有ファイルにアクセスする entitlement を一切認めていない。だから、アプリとアプリの間でファイルをコピーするために私たちは Open In コマンドを使わざるを得ない。

率直に言って、iOS におけるこの制約は、セキュリティのために使い勝手を犠牲にしたものだ。けれども iOS における少なくとも大多数のアプリは、書類を作成したり処理したりはしない。(ただし iPad のお陰で状況は変わりつつあるが。)一方 Mac では、はるかに多くのアプリケーションが書類を中心に動作し、ユーザー体験全体が Finder を中心に展開するので、そのようなシステムを導入すればたちまち大惨事を引き起こしプロフェッショナルなユーザーたちは即座に Windows へ移って行ってしまうことだろう。同じ書類に複数のアプリが変更を加えられるためには膨大な数のコピーを作ることが必須となり、どの変更がどのコピーにあるのかを追跡するのは悪夢のような難問となるだろう。そのような事情から、Apple は iOS アプリよりも多くの entitlement の可能性を Mac アプリ用に作り出したが、それでもなお、サンドボックス化されたアプリはサンドボックス化されていない仲間たちに比べてはるかに制約が多いままだ。

全体的な目標は同じだ。つまり、アプリケーションが(そのデザインにより、あるいはアタッカーに改変されて)あなたのシステムに対して過剰なダメージを与えないように守りたいということだ。ただ、Mac ユーザーの必要と iOS ユーザーの必要とは違うので、何を制限し何を entitlement とするかの適正なバランスを見つけ出すのが難しい。

なぜサンドボックス化がそれほど重要なのか? -- サンドボックス化は、控え目に言っても、非常に大きなことだ。オペレーティングシステムへの攻撃が困難なものとなるにつれて(信じない人もいるかもしれないが、今は実際かなり困難となった)アタッカーたちは特定のアプリケーションをターゲットにし始めた。Adobe Acrobat や Flash、Microsoft Office、Java、ウェブブラウザ、QuickTime に対する攻撃が、Mac OS X や Windows 自体に対する攻撃より頻繁に見られるようになってきている。だからこそ、現在既に、例えば Apple は Safari や QuickTime の一部を、Google は Chrome を、Adobe は Reader と Acrobat (ただしこれは Windows のみ) をサンドボックス化しているのだ。

例えば Google Chrome を見てみよう。これはサンドボックス化の多用のお陰で、現在最もセキュアなウェブブラウザだという定評がある。Chrome は、その中に埋め込んだ独自バージョンの Adobe Flash さえもサンドボックス化して、Flash に対する攻撃がコンピュータを乗っ取る可能性を減らすようにしている。(Flash は、セキュリティの観点から問題が多いことで有名だ。)私の知る限り現実世界で Chrome への攻撃が成功した例は極めて少数で、Flash をターゲットとして Chrome のサンドボックスを破った例はさらに少ない。この理由から、私は自分の Mac で Flash をアンインストールして、Flash を使うサイトは Chrome のみで見るようにしている。

サンドボックス化も万能薬ではない。いくつかの entitlement は、アタッカーがサンドボックスの外で悪いことをするのを許すかもしれない。また、サンドボックス自体もソフトウェアなので、それがクラックされることもあり得る。けれども、少なくともサンドボックスがあるお陰で、たとえその中にあるアプリケーションに脆弱性があって攻撃を受けたとしても、アタッカーがあなたの Mac に足掛かりを得る前に超えなければならない新たなレイヤーが付け加えられていることだけは間違いない。

率直に言って、今日のアタックの状況を見れば、将来 すべての コンピューティングプラットフォームにサンドボックス化が取り入れられることは間違いないと思う。

サンドボックス化と Mac App Store の関係は? -- 2012 年 6 月 1 日現在、Mac App Store におけるすべての新規のアプリとメジャーなアップデートは、サンドボックス化されたものでなければならない。

つまり、Mac App Store のアプリはすべてサンドボックス化済みか? -- いや、そうではない。新規のアプリはすべてサンドボックス化されるが、既存のアプリは必ずしもそうではない。Apple によれば、サンドボックス化されていないアプリもバグ修正は認められるが、それ以外のアップグレードは認めないという。ここにも微妙な線引きが行なわれるだろうし、(少なくとも短期的には)例外がいくつか発生するに違いない気がする。

これによりアプリにどんな影響があるのか? -- アプリによっては、サンドボックス化をしようと思えば、既存の entitlement で提供されていない機能性を失う結果となる。どのような entitlement を開発者たちが利用できるのかの感じを掴むには、Apple の出している資料 "Enabling App Sandbox" を読むとよい。Apple はまた、開発者たちが認可を受けて臨時に使える 一連の一時的 entitlement も提供しているが、これらは将来消滅するかもしれない。例えば Movies フォルダへのアクセスは正規の entitlement だが、(アプリ間で AppleScript ベースのコミュニケーションをするための) Apple Event へのアクセスは一時的な entitlement とされている。

ある種の entitlement が存在しないこと、あるいは一時的な entitlement に依存することに対する開発者たちの不安は、Mac App Store にあるいくつかのアプリに既に影響を与えている。現在の entitlement の制約により実行不可能となった機能を削除してしまった開発者たちもいるし、機能を多くしたバージョンを Mac App Store 以外で提供している開発者たちもいる。Smile の人気あるタイピング拡張ユーティリティ TextExpander 4 は、まさにこの理由で Mac App Store では販売されていないが、バージョン 3.4.2 は Mac App Store で引き続き販売中だ。

一方ユーザーたちは、機能が減ったことに悩まされるとともに複数バージョンのアプリに混乱し、そのいずれもが開発者たちに時間と経費を余分に課す結果となる。他方、サンドボックス化の強制により Mac App Store にあるすべての新規およびアップデートされたアプリでセキュリティが強化される。

なぜ Apple は Mac App Store にサンドボックス化を強制するのか? -- Apple は iOS から重要な教訓を得た。現時点で、iOS には一つもマルウェアが存在しておらず、広範囲にわたるアタックも一度も起こらなかった。これを Google Play と、とりわけ Google にサポートされていない Android ストアがマルウェアの Android アプリだらけである現状と比較してみれば対照的だ。Apple の App Store ではすべてのアプリにサンドボックス化が義務付けられ、すべてのアプリが審査を受ける。一方 Google Play (やそれに代わる市場) では開発者にそのような要件が課されていない。App Store においては Apple が厳重な管理をしていて最も安全なユーザー体験が提供されており、あなたがそれを意識するかどうかにかかわらず、App Store ではマルウェアがあなたの iPhone や iPad に悪いことをする心配がないというのが事実だ。

Android のサイバー犯罪者たちが、Windows ユーザーを攻撃するのに成功したものと同じテクニックを使っているのを、私たちは見てきた。例えば人気あるアプリケーションのさまざまのバージョンの中にトロイの木馬 を隠したり、 セキュリティ用アプリになりすましたり、 自動ダウンロードをさせたりといったテクニックだ。

たとえ誰かが App Store に悪意あるアプリを潜り込ませることに成功したとしても(概念検証実験として成功させた研究者たちもいる)あるいはアプリが後になって改変されアタックに用いられたとしても、Apple はそれを削除して新規の感染を止めることができる。(Apple は iOS デバイスからアプリをアンインストールはしないが、本当に悪い状況の下ではソフトウェアアップデートによってそれをすることは可能だ。)

Apple はこれと同じ体験を Mac のユーザーにも提供し、アプリケーションを購入しインストールするための安全な場所を実現させたいと思っている。はっきりとそれが Mac App Store の利点だと宣伝することはないかもしれないが、実質的にセキュリティがユーザーたちの懸念材料から消え去ることを Apple は望んでいる。

悪者がサンドボックスを破ることはあり得るか? -- おそらく、それはあるだろう。そうなれば Apple はもう一段の強化をするだろう。すると悪者たちはまたそれを破るだろう。それはいつまでも繰り返す。完璧なテクノロジーなどない。けれどもサンドボックス化は間違いなくアタックにかかるコストを引き上げる。実際、アタックにかかるコストが非常に大きくなるので、潜在的な悪者のうちでサンドボックスをターゲットとしクラックできるだけのスキルと資金を持ち合わせていない連中がきれいさっぱりと拭い去られることになる。

サンドボックス化の強制に不都合な面はあるのか? -- もちろんある。すべてのアプリケーションがサンドボックス化のための要件を満たすことができるとは限らない。Mac は汎用目的のコンピュータなので、当然ながら、開発者たちは常に新たな革新的なる応用を思い付いて、Apple が予想もしていなかった、従って entitlement を作りもしなかった事柄ができる(そのような事柄をする必要のある)アプリケーションを作り出すだろう。

今後決して Mac App Store で販売されることのないアプリもいくつかある。これは問題だ。なぜなら、より多くのユーザーたちがアプリを求めて Mac App Store に行くようになるに従い、その種のアプリの開発者たちにとっては十分多くの人々に手を届かせることが経済的に困難となるかもしれないからだ。

長期的にこれがどんな結果を生むのか、私たちには分からない。私としては、全体的な Mac の市場シェアが伸びるにつれて、Mac App Store にも、独立に販売されるアプリケーションにも、双方ともにより多くの機会が生み出されることを願いたい。もしそうなれば、サンドボックス化されていないアプリを Mac App Store で販売できないことにも埋め合わせがつくだろうからだ。もちろんそれは楽観的な見方に違いないし、小規模の開発者がそのアプリがサンドボックス化不可能なために Mac App Store で販売できない結果として売上げが伸びず廃業を余儀なくされるということも十分にあり得る。

Apple は、特に開発者たちから、Mac App Store におけるその他の問題についても批判を受けている。(例えば、気まぐれでろくに説明も伴わない却下や、デモ版を受け入れないこと、ユーザーのレビューへの反応や顧客とのコミュニケーションが許されないことなどがある。)これら他の不満に対処することなくサンドボックス化を強制した結果、開発者たちの間には懸念や不安が高まったし、また Mac App Store のポリシーとサンドボックス化とが結び付けられた結果(私の考え過ぎかもしれないが)この価値あるセキュリティテクニックの認知に悪影響が出ているような気もする。

なぜサンドボックス化をオプションにしないのか? -- 経験に基づいて言えるのは、セキュリティをオプションにすればそれはもはやセキュリティではないということだ。Microsoft はもう何年も前からサンドボックス機能を提供してきたけれど、それを実際に使っている開発者は事実上いない。Microsoft は開発者たちに対して ASLR や EMET のような攻撃対策テクノロジーを採用させるべく苦闘してきた。それらのテクノロジーは開発者ツールに内蔵されているので採用しても基本的に何のコストもかからないにもかかわらず、その努力が実を結ぶことはなかった。第一、Microsoft が Apple を説得して同社製の Windows アプリケーションに ASLR を組み込ませるのにさえ、何年もかかったのだから。

Apple は Mac App Store を可能な限り安全なところにしたいと思っている。それは宣伝のためかもしれないし、利他的精神によるものなのかもしれない。けれどもその結果が私たちの安全を改善するものであるのなら、それがどんな動機によるものであるかは関係ない。過去の歴史に照らして考えれば、もしも Apple がサンドボックス化を強制しなかったならば、それを使う開発者はほとんど誰もいなかっただろう。こんな風に言いたくはないのだが、長年セキュリティの世界で仕事をしてきた私の経験のすべてが、また私以外のセキュリティのプロフェッショナルたちの経験が、鞭をあてなければ鼻先のニンジンを食べる馬はほんの少数だと語っている。

Apple は自分のアプリをサンドボックス化しているか? -- Mac App Store で販売されているものはそうなっていない。それに正直言って、Apple が自分自身のルールにもっと従っていたならば、開発者たちとの間の事態ももっと進展していただろうにと思う。また、Apple はそうすることで開発者たちの懸念をよりよく理解し、自社のチームが同じ制限の下で働かなければならないことで entitlement の改善に繋げることもできるだろう。社内的にはその方向に向かっているのかもしれないが、現在 Mac App Store にある Apple のメジャーなアプリケーション (Aperture、Final Cut Pro、iLife、iWork など) の現行バージョンはサンドボックス化されていない。

それが悪い見本になっているということは別としても、悪者たちが Apple のアプリケーションをもターゲットとして考慮しているということは念頭に置かねばなるまい。何しろ、iTunes はほぼすべての Mac に存在しているのだから、これがサンドボックス化されていなければ、マルウェアの供給路としてなおさら魅力的なものとなる。iPhoto はおそらくターゲットのリストの二番目に来るだろうし、GarageBand、Pages、Keynote、Numbers、その後にプロフェッショナル向けの各種アプリが続くだろう。

Apple が特定のアプリまたは開発者に例外を認めることはあるか? -- それはあるかもしれない。ただ、これまでにそういう例があったとしても、誰もそれを口に出して言ってはいない。私の印象では、Apple でポリシー作成を担当している人たちは、少なくとも社内的には、未だに手探りの状態なのだと思う。(いろいろな開発者たちの報告によれば、既に entitlement によってカバーされているのでない適用除外措置に関して何を問い合わせても、Apple からは完璧な沈黙しか返ってこないとのことだ。)メジャーな開発者たちや、革新的な開発者たちに対して、Apple が適用除外措置を認めることがあるのかどうか、私たちは注目している必要がある。ただ、現在のところルールは頑として動かせない。私に言えることがあるとすれば、私が Apple と議論した範囲内では、サンドボックス化の強制も entitlement のリストも、いずれもまだ、例えばフロッピードライブの廃止ほどには、最終的な段階に達していないという感じを私は受けている。

Gatekeeper はこれにどう関係するのか? -- Gatekeeper は Mountain Lion の新機能で、ダウンロードしたアプリケーションのうちどの種類のものがあなたの Mac 上で動作するかを制限できるようにする。Apple は Mac App Store とサンドボックス化の強制によってアプリを購入するための安全な場所をユーザーに用意したが、Gatekeeper はサイバー犯罪の経済的な核心を狙い打つために作られたものだ。

悪意あるソフトウェアを誰かの Mac に持ち込むために最も一般的に使われる方法の一つは、その人を騙してそれをダウンロードさせインストールさせることだ。犯罪者たちは巧みなテクニックを用いて、経験の少ないユーザーのみならず、知識豊富なユーザーも、さらにはセキュリティのプロさえも騙している。ダウンロードされたソフトウェアが Mac App Store または既知の開発者から来たものでない限り起動できないようにすることで、Gatekeeper はこの種の方法による感染に対してドアを閉ざすことができる。

悪者たちが Gatekeeper を回避する方法を試みていることは疑いない。例えば、正当な開発者の開発者 ID を盗み出して使うなどの方法だ。けれどもここでもやはり、Gatekeeper を追加することによって、広く流布させることのできるマルウェアを作成するのが以前よりずっと困難になり、それによって悪者たちが得られるかもしれない利益が減ることになる。

Gatekeeper はどのように動作するのか? -- 私は記事“Gatekeeper が Mac のマルウェア流行にピシャリとドアを閉める”(2012 年 2 月 16 日) の中で Gatekeeper の機能を詳しく説明したが、その要点を簡単にまとめておこう:

Gatekeeper についてはまだまだたくさん語るべきことがあるが、知っておくべき第一は、いったん Mountain Lion にアップグレードした後は、あなたがいくつか余計な手順を踏まない限り、Mac App Store から入手したものか、開発者 ID による署名の入ったもの以外の、新規にダウンロードしたアプリケーションは走らせられなくなる、ということだ。

既に大多数の開発者たちが開発者 ID を使っているのか? -- 今のところまだそうはなっていないが、私が Apple 社内の情報源から聞いた話では、採用は急激に増えつつある。Adobe など大手の出版元ではそれぞれのアプリケーションのアップデートを出しつつあるし、私が普段使っている小規模なところのアプリも多くが開発者 ID を組み込んでアップデートされた。私たちが TidBITS 監視リストでお知らせしているアップデートをフォローして下さっている方なら、それらのアプリが Gatekeeper に対応するため開発者の署名が組み込まれたことに、私たちが触れていることにお気付きだろう。

私が使うアプリの出所を制限すればセキュリティは向上するのか? -- ほとんどのユーザーは Mac のデフォルトを変更したりしない。ここまで議論してきたように、起動できるアプリケーションを Mac App Store から来たもののみに制限するということは、Apple による検査を受けたアプリのみが手に入ることを意味する。それらの多くはまたサンドボックス化もされている。いずれは、すべてがそうなるだろう。

けれども、この点についても議論してきたが、必ずしもすべてのプログラムが Mac App Store のサンドボックス化要件を満たすことが可能な訳ではない。仮にもしも Gatekeeper が Mac App Store のアプリとそうでないアプリという基準のみで判別していたとすれば、ユーザーの多くが制限なしの設定を選ぶことになっただろう。なぜなら、他の場所からダウンロードしたアプリケーションの扱いが極めて面倒なことになってしまうだろうからだ。開発者 ID による署名の入ったアプリをデフォルトで許すように設定したことの素晴らしさは、これなら私たちも大多数の正当なアプリを面倒なことなしにインストールできる一方で、Apple が アプリケーション レベルの代わりに 開発者 レベルでコントロールを保持できるところにある。

開発者たちはそれぞれに無料で割り当てられた開発者 ID を使って何でも好きなものに署名を入れることができ、署名入りのアプリを Apple が審査することはない。けれども、もしも署名入りのアプリで悪意あると判明したものが出現すれば、Apple はその開発者の証明書をブラックリストに載せるとともに、その開発者からのアプリをすべて Gatekeeper がブロックして他のユーザーがインストールできないようにすることができる。

このテクニックによって、マルウェアの広がりが劇的に少なくなるかもしれない。たとえどこかの犯罪者が開発者 ID を獲得するか盗み出すかしたとしても、それが発見され Apple がその ID をブラックリストに載せるやいなや、そのマルウェアが他の Gatekeeper 搭載 Mac に広がることはなくなる。

Gatekeeper も完璧なセキュリティコントロールではないし、そのように意図して作られたものでもない。広範囲にまん延するアタックに焦点を絞ることで、ユーザーを騙して悪い物をインストールさせる方法で広がる Mac マルウェアの経済的生存能力を Apple は減らそうとしているのだ。攻撃を減らすために Mac 自体の守りをさらに強化したことと組み合わされて、Mac に対する攻撃はますます高くつくようになる。

(それからもちろん、開発者たちは自分の開発者 ID を本気で守らなければならない。もしも開発者 ID が盗まれてマルウェアの中で使われれば、Apple のブラックリストがその開発者 ID による署名の入ったすべての正当なソフトウェアにも適用され、即座に売上げが落ちるとともに深刻な評判の低下が起こるだろうからだ。開発者たちと協力して問題解決にあたることに関して、Apple はろくな実績を残していない。だから、もしもそんな事態が起これば状況が改善されるまでに相当長い時間が過ぎてしまうのも想像に難くない。)

これらセキュリティテクノロジーがユーザーや開発者にとって心配な点は? -- 一言で言えば、iOS の中にこそ、その利点もリスクもともに見て取れる。私たちの汎用の Mac においてこの種の制限が課されることはかつて一度もなかったけれども、iOS ではそれが実際に動くのを私たちは目撃してきた。iOS では、何が可能かについてはっきりとした制限がある(中央化されたファイルシステムが存在しないことがその重要な例だ)し、iOS で Apple はたびたびその門番 (gatekeeper) としての役割を乱用してきた。

サンドボックス化によって課される制限は、開発者たちにとっては自分たちがもはや自由に革新することができなくなり Mac App Store のサンドボックス強制の枠内でのみ生き延びるか、または Mac App Store の外で十分多くの市場を手にすることができず開発経費を正当化することさえできなくなるか、いずれかの道しか残されないのではないかという心配の中に取り残されることになる。開発者たちにはまた、私たちが iOS App Store で目撃してきたように、ルールが勝手に変更されたり Apple が単純にルールに従わなかったりといった事態が起こるのではないかという心配もある。Apple が気まぐれな挙動をした事例は何度もあって、普通ならば正当なはずのアプリを理由もなく却下したこともある。開発のために大きな時間と費用を投入しなければならない開発者たちにとって、市場が公正な方法で公明正大に動いていることは必須の条件だ。一貫性のあるルールがなければ、市場は生き残れない。

私はまた多くの開発者たちやパワーユーザーたちと話をして、私たちが Mac の上で何を走らせるかを Apple がコントロールしたがっているのではないかという懸念の声を聞いた。彼らが心配するのは、Apple が将来のどこかの時点で、すべてのものが Mac App Store 経由でなければならずすべてがサンドボックス化されていなければならないという義務化を実施するのではないか、あるいは、市場のあまりにも多くの部分が Mac App Store に依存するようになってそれ以外の場所でソフトウェアが生き延びる道が閉ざされるのではないか、といったことだ。その結果は平均的ユーザーたちにとってはより安全な環境を意味するかもしれないが、プロフェッショナルのユーザーたちにはその代償として自由が失われ、高度な機能も失われるのではないか、という懸念だ。

私は確かに自分の iPad が大好きだが、それと同じくらいに私の Mac で使うさまざまの素晴らしいツールや微調整も大好きだ。それらの多くは、完全にサンドボックス化された世界においては使えなくなるだろう。

未来を予測することはできないけれど、私の個人的な感覚を信じるならば、現在 Apple で働いているチームは汎用目的のコンピュータと iOS デバイスとの違いを認識していると思う。彼らが Gatekeeper を単純に Mac App Store の使用を強制するものとはせず開発者 ID による方法をも作り出してくれたことは、彼らが自由と安全とのバランスを図っていることを示す兆候だろう。また、Apple はサンドボックスの entitlement の拡張もしてきた。ただし、彼らがその部分を「一時的」と呼んでいる限り、その部分の機能に依存せざるを得ない会社は皆、いつ足元をすくわれるのかとビクビクしていなければならない。

Apple がこの記事を読んでたった一つだけ心に留めてくれるものがあるとしたら、それは次のことであって欲しいと思う: ユーザーたちも開発者たちも、この戦略による安全を大変ありがたいと思うだろうけれど、それと同時に、もしも Apple がコントロールの力を過度に行使したなら私たちはどこに向かうことになるのかと恐れており、その恐れは非常に筋の通ったものだということだ。サンドボックス化と Mac App Store は極めて緊密に相互接続しているので、もしもサンドボックス化がユーザーを保護するためのものでなく全体的なユーザー体験をコントロールするためのツールだと見なされてしまえば、その認知に対して否定的な影響が引き起こされることになる。Apple はあまりにも大きくパワフルで自らの思い通りにきっと何でもできるだろうが、論理的極端へと走ってしまうならば、かの Guy Kawasaki の処女作 "The Macintosh Way" (今は無料ダウンロードで入手できる) に鮮やかに描き出された Macintosh 流のユーザーたちにとって、それは大きな打撃となることだろう。

私の個人的考えでは、Apple は Mac を iOS デバイスと同じくらいロックダウンされたものにすることは望んでいないのではないかと思う。ただ、それが筋の通った懸念であることは、私たち皆が認める必要がある。iOS のあまりにも多くの部分が Lion の中に入り込み、さらにもっと多くが Mountain Lion に入り込もうとしているのだから。

セキュリティの世界で日々働く者として、私は Apple が正しい方向に進みつつあると思う。ただ、そこには改善の余地がある。セキュリティのためのこれらのテクノロジーは、大局的な問題に対処するものとして効果があると実証されているし、私が思うに Microsoft もまた同様のエコシステムによる取り組みを Windows 8 (これは既に本質的に相当セキュアなものではあるが) への移行に伴って採用して行くべきだろう。けれども私の願いは、Apple がこれほど多くの熟練ユーザーたちや開発者たちが懸念を持っている理由を認識して欲しいということだ。もっと明瞭なコミュニケーションが実現されるようになれば、少なくともその懸念のいくつかは緩和されるだろう。

コメントリンク13071 この記事について | Tweet リンク13071


TidBITS 監視リスト: 注目のアップデート、2012 年 6 月 25 日

  文: TidBITS Staff: editors@tidbits.com
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

TextExpander 4.0 -- Smile が TextExpander 4.0 をリリースした。同社のタイピングショートカットユーティリティへのメジャーなアップデートで、長い文章、例えばフォームレターなどを自動化するための新機能がいくつか加わった。けれども、新機能とは別に、今回の新リリースでもう一つ注目すべきは、この最新バージョンの TextExpander を Smile が Mac App Store にリリースしないという事実だろう。これは Apple によるサンドボックス化の要件が原因だ。(この場合は、サンドボックス化をすると TextExpander が他のアプリの中で働けなくなってしまうが、それをすることこそが TextExpander の存在理由なのだから。)TextExpander 4.0 は Smile のウェブサイトからのみ入手可能で、新規購入は $34.95、旧バージョンからのアップグレードは $15 だ。(ただし 2012 年 1 月 15 日以後に TextExpander を購入した人は無料でアップグレードできる。)さらに、TextExpander 4.0 では Mac OS X 10.7 Lion かそれ以降を要するようになった。(10.6 Snow Leopard のユーザーのために、バージョン 3.4.2 が引き続き Mac App Store で入手できる。)

新機能について言えば、今回のリリースで新しい "fill-in-the-blank" スニペットオプションが追加された。これを使ってテンプレートを作成し、名前や日付、さらにはカスタムのリンクや、変数アトリビュートの付いた HTML タグなどでパーソナライズできる。また、複数行にわたるテキストが入力できる fill-in 機能、複数選択のポップアップメニュー、必要に応じて呼び出せるオプションのテキストブロックなども使えるようになった。TextExpander を使うのが初めてという人たちのためには Snippet Creation Assistant が組み込まれて新規のスニペットを作成するためのステップ・バイ・ステップのガイドを提供し、インターフェイスも改善されてポップアップメニューで fill-in スニペットが作成できるようになった。その他の機能拡張としては、テキストフィールドやポップアップメニューのデフォルト値、テキストフィールドに入力している際のスニペット展開、フランス語とドイツ語の AutoCorrect スニペットグループ追加などがある。(新規購入 $34.95、TidBITS 会員には 20 パーセント割引、アップグレード $15 (2012 年 1 月 15 日以後の購入なら無料)、8.5 MB、リリースノート)

TextExpander 4.0 へのコメントリンク:

Skype 5.8.0.865 -- バージョン 5.8.0.865 にアップデートした Skype for Mac は、いくつかユーザーインターフェイスの改善を追加するとともに、間もなくリリースされる OS X 10.8 Mountain Lion への対応を追加している。今回のアップデートには改善された Contacts Monitor (他のアプリケーションを使っている際に以前よりコンパクトにリサイズできる)、モバイルデバイスが横置きと縦置きの表示切替をした場合にモバイルビデオ通話も自動的に向きが切り替わる機能、音量をコントロールするためのキーボードショートカットの追加、会話入力フィールドの SMS ボタン、などが組み込まれた。Skype Premium の購読者にはビデオ通話とスクリーン共有表示とを同時に見られるようにしてスクリーン共有を改善している。改善点の完全なリストは、リリースノートを掲載した Skype Garage ブログ記事で一覧できる。(無料、23.3 MB)

Skype 5.8.0.865 へのコメントリンク:

Bento 4.1.1 -- FileMaker が、同社の簡略化版 Mac 用データベースソフトウェア Bento のバージョン 4.1.1 をリリースした。簡体字中国語ローカライズ版を追加したこと以外に新機能はないが、今回のリリースの焦点はむしろ、最近アップデートされた iPad アプリとの互換性を確保することにある。この Bento 4 for iPad アプリにはあなたのデータにアクセスするための四つの新しい方法、Form 表示、スプレッドシート風の Table 表示、Table と Form の表示を組み合わせた Split 表示、それから Libraries サイドバーの付いた Full Screen 表示が追加された。また、Retina ディスプレイ対応の 40 の新しいテーマや、タップ一つで Bento Template Exchange にアクセスして数多くの無料ですぐ使えるテンプレートにアクセスできる機能もある。

Bento 4.1.1 for Mac は、既存のオーナーには(FileMaker から購入した場合も Mac App Store から購入した場合も)無料アップデートで、新規ユーザーには 2012 年 7 月 31 日までの期間限定で(定価 $49.99 のところ)$29.99 の価格で販売中だ。同様に、Bento 4 for iPad も 2012 年 7 月 31 日までは(定価 $9.99 のところ)$4.99 となっている。ただし、前回のバージョンの Bento for iPad (バージョン 1.15) のオーナーに対する無料あるいは値引きされたアップグレードの道は(将来のアップデートの道も)用意されていない。(たとえ、あなたがほんの数日前に古い iPad 用バージョンを購入したのだとしても。) TUAW の Megan Lavey-Heaton が、古いバージョン 1.15 を最近に購入した人が返金を希望する場合にどこに連絡すればよいかの示唆を述べている。(Mac 版は新規購入 $49.99、期間限定で $29.99 に値引、無料アップデート、98.6 MB)

Bento 4.1.1 へのコメントリンク:


ExtraBITS、2012 年 6 月 25 日

  文: TidBITS Staff: editors@tidbits.com
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

今週紹介したい記事は一つだけだが、これはたっぷり読み甲斐があるだろう。NPR (National Public Radio) の一人の実習生が彼女の 11,000 曲にものぼる楽曲コレクションのうち彼女が購入したものはほとんどないと明かしたのに対して寄せられた興味深い反応を集めたものだからだ。

NPR の実習生、音楽に金を払うことへの議論を再燃させる -- NPR (National Public Radio) の "All Songs Considered" プログラムに参加した一人の実習生が最近ブログに投稿した記事で、自分は iTunes に 11,000 曲も保存しているけれども自分で購入した CD は全部合わせても 15 枚ほどに過ぎないと書いた。彼女のこの記事に対して、嵐のような反応が寄せられた。興味深いことに、賛否双方の反応があった。そこで NPR の Robin Hilton がこのブログ記事に、多数の反応へのリンクを集めた。最も注目すべきはソングライターであり Georgia 大学の音楽ビジネスプログラムの講師でもある David Lowery による記事 "Letter to Emily White" だが、Hilton が引用した他の多くの反応記事も読む価値がある。

コメントリンク: 13080


tb_badge_trans-jp2

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

TidBITS ISSN 1090-7017©Copyright 2012 TidBITS: 再使用はCreative Commons ライセンスによります。

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