TidBITS#1248/10-Nov-2014 TidBITS#1248/10-Nov-2014もしもあなたの電子メールアドレスを管理しているのが Apple、AOL、または Yahoo なら、この号はあなたが久しぶりに受け取った TidBITS 号であったかもしれない。そのことについて、大変申し訳なく思います！ それらのサービスが私たちを誤って迷惑メールだと判断していたのが原因で、Adam Engst が現状に対処するためどのようなことをしたかを説明する。Microsoft が今回 Office を iPhone にももたらし、iPad と iPhone のユーザーのためにより多くの無料機能を開放した。Julio Ojeda-Zapata がモバイル Office アプリの新機能を概観するとともに、今後何がやって来るかも語る。セキュリティ関係の記事が二つあって、Josh Centers が二要素認証アプリ Authy をレビューし、Rich Mogull はなぜ Apple にとって最大のセキュリティの難問が... あなたなのかを説明する。最後にもう一つ、Michael Cohen が、iCloud Drive は Dropbox の代わりに使えるのかという読者からよく寄せられる質問に答える。今週注目すべきソフトウェアリリースは BBEdit 11.0.1、CrashPlan 3.6.4、Quicken 2015 for Mac 2.2、Pixelmator 3.3、それに ReadKit 2.4.2 だ。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Adam C. Engst: [email protected], @adamengst 訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
あなたは AOL、Yahoo、または iCloud (mac.com、me.com、または icloud.com) の電子メールアドレスを使っていますか？ もしそうなら、そしてもしもあなたが TidBITS の電子メール版を購読したことがあって、その後それが届かなくなっていたなら、大変申し訳ないことです。最近になって、comcast.net アドレスへの電子メールが届かないという大きな問題が起こっていたのを調べていた際に（2014 年 11 月 3 日の記事“Comcast の TidBITS 購読者に対するメール配信再開”参照）私は AOL、iCloud、Yahoo で購読をしている何千人もの人たちへの配送も、それらの電子メールプロバイダの側での不正確なスパム（迷惑メール）フィルタリングのせいでやはりバウンスしていたことに気付いた。iCloud でのバウンスが起こったのはここ数週間以内のことだが、AOL と Yahoo でのバウンスはもっと早くから起こっていた。
現在、それらのドメインにいる人すべてに電子メール配送が復活している。だから、もしこれがあなたが久しぶりに受け取った TidBITS の号であったなら、またお目にかかれて嬉しいし、このような配送の問題が起こったことについては大変に申し訳なく思っている！ もしもお望みなら、ご自分宛てに過去の号を手動で再送信することもでき、実際それはあなたの電子メールプロバイダが何らかの理由で TidBITS をブロックしていたかどうかをチェックできる素敵な手段となる。再送信の方法について詳しくは記事“TidBITS の号を自分自身に再送信”(2013 年 3 月 8 日) をお読み頂きたい。
また、もしもバウンスした場合、 ご自分のアカウントにログインして購読状況のチェックと手動での配送再開をして頂くこともできる。そのページで、あなたの名前、電子メールアドレス、パスワード、その他の変更もできる。
もちろん、既に他の電子メールアドレスから TidBITS を購読し直して下さっている場合や、あるいはもはや Apple 関係のニュースや製品に興味がないとおっしゃる場合は、簡単に購読中止ができる。メッセージの一番下までスクロールして、そこにある Unsubscribe リンクをクリックするだけでよい。
なぜこんなことが起こったのか？ -- 私たちは 1990 年以来ずっと TidBITS を電子メールで配送してきたが、メーリングリストの基盤となるテクノロジーはその間何度も変わった。現在、私たちは Take Control ブックを購入した人たちをも追跡する包括的なアカウントデータベースと結び付いた自家製のシステムを使っている。なので、TidBITS にしても Take Control にしても、私たちが電子メールを送信する際にはいつもデータベースのクエリーからその場で宛先リストを構築して送信している。
私たちはあまりにも長い間これをしてきたので、そしてそれは大体においてうまく行っていたので、私は電子メール配送の世界の最新情報に遅れず付いて行くことを怠けてきた。いやむしろ、私が本気になって取り組んで SPF や DKIM などのテクノロジーを実装したり、またフィードバックループにサインアップすることでメジャーな電子メールプロバイダを購読している誰かが TidBITS を購読中止にせず私たちからのメールの一つをスパム（迷惑メール）とマークした際に警告が受けられるようにしたりしたのは、やっと今年に入ってからのことであった。
（たとえそれが望まないものであったとしても、正当な電子メールメッセージをスパムとマークするのは、残念ながらよくあることだが、どうかお願いだからそれはしないで欲しい。なぜならそれは送信者の風評を理由もなくおとしめるからだ。さらにその結果として、あなたと同じドメインにいる他のユーザーたちへの電子メールが届かなくなることにもなり得るからだ。あなたが購読中のメーリングリストを去るには、必ず unsubscribe リンクを使うべきだ。たいていの場合、リンクはメッセージの一番下あたりにあるはずだ。）
振り返って考えてみれば、私たちのシステムにも最善とは言えない側面があった。それは、システムが提供するレポートが毎週主として送信したアクティブなユーザー数のみを報告していたことだ。これまで、私は何週間も何ヵ月間もこのレポートを見ずに過ごすこともあった。なぜなら、たいていの場合その数字は特別に興味深いものではなかったからだ。でも、750 人の Comcast 購読者を一挙に失ったことにはすぐ気付いたし、2014 年 10 月 27 日に数千人の iCloud 購読者を失ったことも私の注意を引いた。残念ながら、バウンスしたメッセージの中にあった URL は問題を説明するものであったはずなのに、開いてみるとそこには何も問題ないと書かれていたし、[email protected] に電子メールを送ってもバウンスするだけだった。
今後は、購読者数にも、またバウンスのログにも、もっと気を付けるつもりだ。もしも皆さんが何か問題に気付かれたら、どうか私に知らせるとともに、お使いの ISP または電子メールプロバイダにも苦情を述べて頂きたい。
コメントリンク15226 この記事について | Tweet リンク15226
文： Julio Ojeda-Zapata: [email protected]
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
Microsoft は今年初めに、最も重要な Office 生産性スイートを、自社の Windows プラットフォーム用には相応のタッチ対応のソフトウェアを提供することなく、完全な iPad バージョンとしてリリースし物議を醸した ("iPad 用 Office： 詳しく見てみよう" 3 April 2014 参照)。
急速にクロスプラットフォームの時代になりつつあることが明らかになる中で、かっては Windows 中心のソフトウェア会社でもこの傾向は続いている。先週、Microsoft は一連の Office 関連の発表を iPhone, iPad, そして Android に関して行ったが、Windows は後回しにしたままであった (少なくとも、公には)。
最も驚かされるのは、多くの Office 機能が無料で提供されていることである。これはもはや Steve Ballmer の Microsoft ではない。
Office for iPhone -- 恐らく Apple 愛好者にとっての最大の Office ニュースは、iPhone に関するものであろう。Microsoft は、新しいそしてユニバーサルなバージョンの Word, Excel, そして PowerPoint をリリースしたが、これらは iPad 或いは iPhone 上で働き、後者は iPhone のより小さな画面に合わせて微調整されている。
例えば、Word は iPhone の限られた地所を最大限に使うため、タップすると現れるフォーマットペーンを採用している。それは下から上へとスライドし、もう一度タップすると元に戻る。
このフォーマットペーンは、場所を節約すべく良く練られている。伝統の Insert, Layout, Review, そして View メニューは、iPad 上ではトップのツールバーの中にあるが、iPhone 上では小ぎれいなポップオーバーの中に隠れている。このフォーマットペーンの中には多くの制御子があるが、さっとスクロールするだけで簡単に見ることが出来る。
Word ユーザーには二つのビュー選択肢が与えられている：デフォルトビューと Microsoft が "読みやすいレイアウト" 或いは "リフロービュー" と呼ぶものである。
これらの iPhone 用の新しい個別バージョンの Word, Excel, そして PowerPoint は、これ迄 iPhone ユーザーが Office ファイルを開いたり或いは編集したりすることに使えた一つの Office Mobile アプリを置き換える。Office Mobile には限られた機能セットしか与えられておらず、多くの支持者もいなかったし、残念に思う人も少ないであろう。
比較的マイナーな機能アップグレードが iPhone と iPad の両方に適用される。Office アプリには、例えば (しかし、有料のプレミアムユーザー限定)、より多くのカスタマイズ可能なチャートが含まれる。PowerPoint では、アニメーション、ズーム、そして背景フォーマットが微修正されている。
Microsoft は、iPhone と iPad 用の OneNote アプリに対するアップデートは発表していないが、先月遅くに同社は、iOS 8 対応と、iPhone 6 及び iPhone 6 Plus 上のビューの最適化を含んだアップデートを出した。これらの OneNote アップデートには、iCloud Drive サポートと、Touch ID 対応を含んだセキュリティ改善が追加されている。
編集も無料 -- iOS 用の Microsoft の Office アプリはこれ迄 Office 365 に加入していない人に対してはあまり役に立たなかった、何故ならば、これらは Office ファイルを開いて表示することしか出来なかったからである - 編集し保存することは選択肢になかった。
それが今では出来る... 限度はあるが。Microsoft は Word, Excel, そして PowerPoint での核となる編集機能を全ユーザーに対して無料とする一方、高度の、ビジネス中心の機能は、Office 365 ユーザーに対するプレミアムとして残した。
この新しい Office アプリは、技術的には無料で遊べるが全体験を楽しみたい人のためのアプリ内購入のアドオンを含んでいるある種の iOS ゲームに似ている。上に行きたければ、お金を払って！
もっとも、通常の Office ユーザーならアップグレードする圧力はあまり感じないと思われる、と言うのも Microsoft は、無料レベルで出来る事に関して気前良くしているからである。私はこの記事を私の iPhone 6 Plus 上の Word で一銭も払わずに書いている (しかし、私の記事を Mac 用の Word と無料で同期する事は出来ない)。
無料アプリの中で何が出来るのかを見極めるのは結構大変だし、その違いの中には馬鹿馬鹿しいものもある。プレミアムユーザーだけが、既存の Word 書類で向きを変えたり、或いは縦位置で書類を作成出来る。本当に？ Macworld に、無料と有料の機能比較のリストが載せてある 。一つか二つの欲しい機能のためだけに Office 365 へ加入せねばならなくするのではなく、望みの機能を個別に買えるようにしてくれた方が嬉しいのに。
Office アプリを基本的には無料にするという Microsoft の動きは、同社がもう既に堅固なブラウザベースのバージョンの Word, Excel, そして PowerPoint を OneNote と共に無料にしている事からすれば、それ程無理をしていることにはならない。
Dropbox -- Microsoft は、保存オプションも広げた - Dropbox へのサポートが加わった。これは、新しい Dropbox-Microsoft 提携の好意によるものである ("Dropbox が Office にやって来る" 4 November 2014 参照)。結果として、iPhone 上で Office アプリを立ち上げ、そして Microsoft アカウントにログインすると、私の Dropbox アカウントにも接続するよう促される。当然ながら、引き続き書類を Microsoft OneDrive にも保存出来る。
Dropbox と Microsoft は、彼らの提供するものの互換性を上げる努力をしている。 他の発表された機能 には、Office ファイルを Dropbox アプリ内から編集するオプションが含まれる。Office Web アプリと Dropbox の統合、そして Dropbox リンクの Office からの共有もあるが、これらはこの記事を書いている時点では、完全に動作している様には見えない。
今日は、Android -- Microsoft は Android バージョンの Office も約束していたが、ようやく現実のものとなった。条件付きではあるが。
同社は、Android 用の Word, Excel, そして PowerPoint のベータバージョンで試したいという早期導入者のための試行プログラムを立ち上げた。登録が必要だが、アプリを使うことで費用は発生しない。この記事を書いている時点では、この試行は招待者限定である。
これらの Android アプリは、その iPad バージョンと極めて似ているように見えるが、色々なモバイル機器を使い、そしてマルチプラットフォームを通して Office の統一性を求める個人や企業にとってはとても大事なことである。これ迄 Android ユーザーには、サードパーティからの限定的な Office 似のアプリしかなかった。これらの中には良いものもあるが、多くの企業にとっては、Microsoft の公式の Office スイートしか役に立たない。
かわいそうな Windows ユーザー -- iOS と Android が最新の Office のおいしい所を味わっている一方で、Windows PC 上のものの苦難は続いている。私もそのグループの一人である、と言うのも、私は定常的に Microsoft Surface タブレットに依存しており、タッチスクリーン上で通常バージョンの Office アプリを使うのは嫌いだからである。
Microsoft は Windows 用のタッチ最適化された Office アプリを、Windows 10 オペレーティングシステムと共にリリースすると言っているが、これらが予定されているのは、来年後半である。その他の詳細は明らかにされていないが、来たるべき PowerPoint のスクリーンショットは公表されている。
コメントリンク15217 この記事について | Tweet リンク15217
文： Josh Centers: [email protected], @jcenters
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
デジタルセキュリティは今年の熱い話題の一つであった。有名人の私的な写真の盗難と ("著名人の写真盗難は iCloud の欠陥が原因ではない" 2 September 2014 参照)、度重なるクレジットカードの漏洩の間で、少々被害妄想にならない方がおかしいとも言える。
あなたのオンラインセキュリティの戦いを改善する最善の方法は、2 要素認証である。簡単に言うと、2 要素認証は、あなたのパスワード (あなたが知っているもの) に対して更なる層のセキュリティを、専用の機器或いはモバイルアプリによって (あなたが持っているもの) 数秒毎に再生成される数字の形で付け加える。
2 要素認証では、無料の Google Authenticator がデファクト業界標準になっている。これは、あなたの Google アカウントで使えるが、Dropbox, Evernote, Facebook, Tumblr, そしてその他の多くのオンラインサービスとも互換性がある。
Google Authenticator は役目をきちんとこなすが、幾つかの重度な限界もある。それは、バックアップも同期も提供していないので、それがインストールされている機器を失ったり、或いは機器からそのデータを消してしまったりしたら、痛い目に遭うことになる (一例として "２ステップを踊る： 認証の第二要素喪失に対処" 28 August 2013 参照)。一つの Google Authenticator アップデートで、全員の 2 要素トークンが間違って消されてしまい、全員が自分のアカウントにログイン出来なくなってしまったのである。
幸いにも、代替策がある：Authy で、これは App Store で iPhone と iPad に対して無料で入手出来る。
Authy には Google Authenticator にはない数多くの機能がある。Authy はあなたの 2 要素トークンをクラウドにバックアップ出来るので、自分の電話を消し去っても、或いは新しいものを入手しても、これらのトークンを復元でき、自分のアカウントから閉め出されることを防げる。Authy はまた、クラウドを使ってあなたの他の機器も同期出来、しかもこのアプリはユニバーサルなので、iPhone でも iPad でも同じ様に良く働く。そして、もしあなたがより新しい Mac で Bluetooth 4.0 LE 付きのものをお持ちなら (悲しいかな、私は持っていない)、無料の Authy Bluetooth アプリを活用して、あなたの 2 要素トークンを Mac 上に自動的に挿入できる。そのために何かをタイプする必要は全くない。
Authy の得失 -- Authy は 2 要素トークンをクラウドにアップロードすると聞くと、あなたは心配になるかもしれない。しかし、二つのことを覚えておいて欲しい。第一に、 クラウドベースのバックアップは全くの自己選択であり、デフォルトではオフになっている。第二に、Authy はあなたのバックアップをアップロードする前に、あなたの機器上で暗号化する。
いずれにしろ、全てのセキュリティ判断の場合と同じで、Authy のクラウド機能にも得失がある。機密情報を誰か他人のサーバー上に保存すれば、それが盗まれるリスクは、その割合は微少であるにしても、増大する。しかしまた、その利点も考慮しなければならない。Google Authenticator を使う場合、もしあなたの iPhone をなくせば、一時的にしろ、自分のアカウントへのアクセスを失う。どちらの場合がより起きやすいか、或いは/そして、より恐ろしいか：一つのアカウントがハックされる、或いは、ソフトウェアの不具合や壊れた電話のせいで、全てのアカウントへのアクセスを失う？
Authy はまた、Google Authenticator には無い大事なセキュリティ機能を付け加えている：このアプリを PIN 又は Touch ID でロックするオプションで、万が一泥棒がその機器の全体のパスコードをかいくぐることが出来たとしても、あなたのトークンを見ることは出来ない。
たとえ Authy に脆弱性があると分かった場合でも、2 要素認証で守られたオンラインアカウントの方が、一つのパスワードに全面的に依存するものよりもより安全であろう。アカウントパスワードを破ることに加え、攻撃者はあなたの Authy パスワードも破らなければならない。反対に、攻撃者があなたの Authy アカウントに侵入できたとしても、トークンはアカウントパスワード無しでは役立たずである。その様なアカウントは、一つのパスワードしか持たないものよりも、ハックするのは二倍難しい。
私にとって、Authy を使う判断は容易である。それは私のアカウントを 2 要素認証で守ってくれ、そして Google Authenticator が有する問題の可能性を減じてくれる。
Authy を使う -- Authy は、2 要素認証の観点からすれば、使うのは極めて簡単である。最初に、アカウントトークンを設定する必要がある。画面下部にある Add Account をタップし、次にオンラインサービスから提供された QR コードをスキャンするか、或いは提供されたコードを入力する。これらどちらかの入手方法はサービスによって異なる。
一つかそれ以上のアカウントを付け加えると、それらは画面の下部に現れる。もし四つ以上あれば、画面下部のボタンの列は追加のアカウントを見るために展開できる引き出しと Add Account ボタンに変化する。2 要素保護のかかったサイトにログインするために入力する必要がある時限トークンを表示するには、単にアカウントをタップすれば良い。タイマーを意識すること - 通常一つのトークンは期限切れとなるまでたった 30 秒しか無い。もしトークンの残り時間が数秒しか残っていない場合、次のを待つ方がやりやすい。もし iOS 機器自体からログインしようとしているのであれば、トークンの隣にある青いコピーボタンをタップすればクリップボードにコピーすることも出来る。
もしアカウントを管理したり、或いは追加のセキュリティ保護を設定したければ、右上の Settings をタップする。Settings 画面では、My Account で自分の Authy アカウントに紐付けされるのはどの電話番号とメールアドレスかを設定出来る。これらは重要である：あなたが新しい iPhone に移る時、Authy はあなたの ID を証明するためこれらの連絡方法の一つを使うよう求めてくる。Protection PIN 及び/或いは Fingerprint Protection もここで設定出来るので、私はその使用を是非お薦めする。もしあなたの機器が Touch ID 対応なのであれば、Fingerprint Protection を有効にしないのは馬鹿げていると思う、何故ならば、殆ど手間をかけず一層のセキュリティを付け加えられるからである。
Accounts ペーンでは、あなたのトークンを管理し、より良い名前を設定出来るが、新しいユーザーにとってもっと大事だと思われるのは、クラウドバックアップを設定し、そしてバックアップパスワードを変更する場所でもあることである。
Bluetooth ペーンは、ただ単に Authy に Bluetooth を使って Authy Bluetooth アプリと会話をさせてくれる。このオプションが使えればの話ではあるが。
最後に、Devices ペーンでは、複数機器サポートを設定し、管理できる。他の機器を有効にするには、Authy が Inherited Trust と呼んでいるものを使う。言い換えれば、同じ Authy アカウントを別の機器で使おうとする場合、その機器を既に認定されている機器から承認する必要がある。実際問題として、これはセキュリティと便利さの間の良いバランスである様に見える。
窓を板で覆い尽くす -- 今日では、デジタルセキュリティはゾンビ大襲撃映画の様なものである。買い溜めをし、窓に板を打ち付けて籠もることは出来るが、遅かれ早かれ、恐らく単純な人間エラーのせいでゾンビは侵入を果たす。
しかし、あなたの努力が結果的には無益であるかもしれないからと言って、窓を板で塞ぐのを止めるのはおかしい。同時に、食料が必要になった時に出られない程、塞いでしまうのもこれまたおかしい。
それが私にとっての Authy の見方である。この開発者も認めていることだが、クラウド機能はセキュリティを弱める可能性も秘めているが、同時に、自分自身が自分のデジタルハウスから出られなくなる可能性も下げられる。
また Authy は一つのことしかしないことも認識すべきである - これはオンラインセキュリティに対する特効薬では無い。これであなたのクレジットカード番号が店舗から盗まれるのを防げるわけでもないし、Apple の奇妙な 2 要素認証の導入のせいで起こった Jennifer Lawrence の写真が盗まれた事件が防げたわけでも無い。
Authy はあなたのセキュリティキットの中の一つのツールに過ぎないが、2 要素認証の威圧感を減らしてくれる有用なものである。
コメントリンク15214 この記事について | Tweet リンク15214
文： Michael E. Cohen: [email protected], @lymond
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
記事“iCloud Drive への移行”(2014 年 10 月 15 日) を書いて以後、私は iCloud Drive をどう使えば Dropbox の代わりになるかという質問のメッセージをいくつか受けた。その返事にも何度か書いた通り、私は「iCloud Drive は Dropbox の代わりにはならない」と言いたい。ただし、質問した人たちが混乱してしまった理由も分かる。Apple は、iCloud Drive についてまともな説明を提供していないし、それを言うならば iCloud 全般についてもきちんとした説明はない。
問題は、iCloud が一つだけのものでなくさまざまのものを揃えたサービスだというところにもある。ここにはカレンダーや連絡先の保存と同期、電子メール、位置情報サービス、メディアやアプリの共有、バックアップ、データのストレージ、書類のストレージ、その他たくさんのサービスがある。時折 Apple はこれらのサービスのどれかを（特にそのサービスが初めて導入されたりあるいはサービスの内容が拡張されたりした折などに）マーケティングの中で取り上げて呼び物にすることもあるが、巨大なる怪物のようなこの集合体を同社が包括的に扱った手引書を提供したことは、私の知る限り一度もない。そしてこれもまた、Joe Kissell の "Take Control of iCloud" があれほど人気を得た理由の一つだ。（もちろん彼は現在その本の改訂に向けて一生懸命に作業中で、近日中にアップデートが出せる予定だ。）結果として、まさに群盲象を評すの寓話のように、私たちは iCloud というものを自分がたまたま手を触れている巨象の体の部分のことだと思い込んでしまうわけだ。
iCloud Drive は、この iCloud という巨象の体の一部分だ。ただ、Apple はこれが巨象の体のどの部分なのかをきちんと説明する努力をしていない。なので、私たちは iCloud Drive が新しい、生まれたばかりの獣なのだろうと思ってしまいがちだ。けれども実は、これは全く新しいものでもなければ、独立の獣でもない。これは単に、既存の iCloud 機能である Documents & Data を、より成熟させた形にしたものに過ぎない。
Documents & Data 機能 -- Apple が iCloud Drive を導入するより以前には、個々の iCloud 互換アプリが独自にプライベートなストレージスペースをユーザーの iCloud アカウントの中に持つことができた。そのようなアプリのみがそのスペースにアクセスでき、そこに保存されたファイルを扱うことができた。Apple はユーザーに説明したりインターフェイスの中に書いたりする際、その機能に "Documents & Data" という一般的な名前を無造作に付けた。この機能は、次のように動作した。
もしも iCloud 互換な iOS アプリ（例えば Pages や PDFpen など）が対応する Mac アプリを持っていて、そちらのアプリも iCloud を使っていれば、その Mac と iOS アプリはいずれも同一のプライベートなストレージスペースにアクセスでき、同じファイルを使うことができた。つまり、iPhone 上でファイルを作ってそれを iCloud に保存し、それを Mac 上で開いたり、あるいは iPad 上で関連したアプリを使って開いたりできた。
しかしながら、Mac 上でさえファイルの作成・削除・変更はアプリを使ってそのアプリのプライベートな iCloud ストレージスペースの中でしなければならず、Finder が直接にそのファイルにアクセスすることはできなかった。（技術的に言えば Finder で Home フォルダの Library の中の奥深くに踏み込んでそこにキャッシュされた iCloud ファイルを見つけることは できた けれども、Mac の Library の中にキャッシュされたファイルは単に ローカルな コピーに過ぎず、必ずしもその時点での「本物」つまり iCloud 自体に保存されたマスターファイルを反映しているとは限らなかった。）
OS X 10.10 Yosemite と iOS 8 が揃ったことで、Apple は iCloud Drive を導入した。けれどもそれは Documents & Data の代替品ではなかった。それは、Documents & Data のうち Documents 部分に対するユーザーインターフェイスを提供するものであった。
iCloud Drive -- Mac 上では、iCloud Drive はアプリが iCloud に保存したファイルを一覧したり追加したり削除したりするため Finder からアクセスできる方法を提供する。それに加えて、ユーザーが iCloud の中に自分でフォルダを作ったり、そのフォルダの中に何でも好きな書類を入れたりする方法も提供する。iCloud Drive は、Finder ウィンドウのサイドバーに Favorites 選択肢の一つとして現われ、クリックすれば普通のフォルダのリストとよく似て見えるものを表示する。ただし、見た目は人を欺くものだ。
iCloud Drive の中に表示されるフォルダの多くは、実際もしあなたが独自にフォルダを追加していないならばすべてのフォルダが、Finder 流のフォルダでなく「アプリライブラリ」だ。このアプリライブラリこそ、従来アプリがプライベートに持っていた書類ストレージスペースが iCloud Drive の中に存在していた形だ。これらは従来通りそのオーナーたるアプリが管理し保持しており、あなたがそこですることは依然として基本的にその個々のアプリによって決定される。例えば、いくつかのアプリはあなたがそのアプリライブラリに置くことのできる書類の種類を制限するかもしれない。Finder の中で Get Info によりアプリライブラリ「フォルダ」の情報を見ることすらできない。File メニューの Get Info 項目は無効になっているので選択できない。Command-I のショートカットを試しても Finder がビープ音を鳴らすだけだ。
iOS 8 には Finder がないので、iCloud Drive へは iCloud 対応アプリの中からアクセスする。ただしもちろん、アプリの開発者がその機能を提供すればの話だ。たいていの場合、iOS 8 の iCloud 対応アプリは管理する iCloud 書類を従来のバージョンの iOS でしていたのと大体同じやり方で表示する。
しかしながら、書類の表示は従来と同じ古いやり方でしていたとしても、アプリは iCloud Drive をブラウズしたり、互換な書類で他のアプリライブラリやユーザーフォルダに保存されているものを開いたりする方法を提供することもできる。例えば、iOS 版の Pages では、書類マネージャツールバーの + アイコンをタップすると iCloud Drive の "document picker" に導かれ、そこからユーザーフォルダや他のアプリのライブラリ（ただし、そのアプリがそれを許していなければならず、アプリによってはライブラリを無効にしたり、また picker に登場しないようにしたりしているものもある）を開くことができ、そのライブラリやフォルダの中で書類を選んで開くこともできる。
他のアプリのアプリライブラリや iCloud Drive フォルダから書類を開いた際にそのアプリが何をするかを予測するのは難しい。その書類のコピーを作って自分のアプリライブラリに保存するアプリもあれば、エイリアスを作ってそれをアプリライブラリに保存するアプリもある。
大体において、iCloud Drive は単に従来からある Documents & Data サービスの Documents 部分を管理するため、従来のバージョンの iOS や OS X が提供したよりも便利で、よりコントロール可能な方法を提供するだけのものだ。けれども、iCloud Drive 上で、しかも一部のアプリライブラリの中でさえも、あなたが自分でフォルダを作成できるようになり、どのような書類でも好きなようにそのフォルダの中に保存できるようになったのを見て、あなたはこう思うかもしれない。「これはきっと、Dropbox の代わりに使えるようになったのに違いない」と。でも、あなたのその考えは十中八九間違っている。
iCloud Drive は Dropbox の代わりにならない -- そもそも Dropbox の価格は iCloud よりはるかに安い。Dropbox で 1 TB のストレージが $99 であるのに比べて、iCloud で同じ容量のストレージならば 月額 $19.99 (つまり年額 $239.88) だ。
でも、理由はコストのみではない。これら二つのサービスは、動作のしかたが違う。例えば、共有について見てみよう。iCloud は一般的に共有のためのものだが、それは主として あなた のものを あなたのデバイス と共有するため、つまり同じもの（カレンダー、音楽、メール、Numbers の中の予算案、Pages の中の書きかけの小説、など）をあなたが持っているすべてのデバイスの間で共有するためのものだ。他の人との間での共有は、たとえその相手が iCloud ユーザーであっても簡単ではないし、できたとしてもその選択肢には制約があり（例えば特定のフォトストリームや、あるいは Pages や Numbers で明示的に共有した書類など）焦点がしっかりと絞られている。
他方、Dropbox では、フォルダとその中にあるすべての書類を他の Dropbox ユーザーたちと共有できる。Take Control 本の原稿も、Dropbox を使って著者たちや編集者たちに渡され、執筆・編集・出版の作業がされている。同じことを iCloud Drive でしようと思ってもそれは不可能だ。
その上、Dropbox と違って iCloud はファイルの過去のバージョンを保存しないし（ただし個別のアプリがそれをすることはあり得るが）また削除したファイルを復活させることもできない。
けれども最も重要な点は、iCloud Drive が 単なる ファイル共有サービスではないことだ。Mac でも iOS でも、アプリが口を出して、そのアプリライブラリの中であなたに何ができるかに制約を課していることを思い出そう。それはつまり、Finder が iCloud Drive を扱う際に、それが普通のドライブと同様にたくさんのフォルダを持つものという幻想を作り出そうとしつつ、それでいて個々のアプリに対してそれぞれ独自の持ち物に関する権利や要求を尊重しようとするため、Finder の挙動が私たちの予期せぬものになり得るということだ。例えば、どのアプリライブラリがどのファイルを受け入れるのかは、試してみないと、見ただけでは分からない。
また、少なくとも Yosemite の最初のリリースにおいては、アプリライブラリの領域の中で一見普通のファイル処理の操作をしようとしても、Finder が混乱してしまうことがある。例えば iOS アプリが作成したエイリアスの名前を変更しようとしてもうまく行かない。私の経験では、それをすると Finder が回転するビーチボールをいつまでも出し続けてそのまま復帰できなかったこともあるし、また別の時には変更したはずのファイル名が文字と数字の長い羅列に変わってしまったこともある。この種の挙動は、ファイル共有サービスではあってはならないことだ。
だから、ありのままの現在の姿においては、つまり、iCloud に保存されているあなたの書類に対する管理・アクセス・同期のためのより良い方法としては、iCloud Drive は歓迎すべき拡張だ。
でも、これは決して Dropbox ではない。
コメントリンク15216 この記事について | Tweet リンク15216
文： Rich Mogull: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
オペレーティングシステムのセキュリティに対する Apple の取り組みは、従来は最低限のものでしかなかった。幸いにも、従来はそれで実害はなかった。
セキュリティの世界で長く時間を過ごせば、テクノロジーではなく経済状況と人の挙動がセキュリティを規定するのだということが分かってくる。Apple についての文章を私が初めて書くようになったのは 2006 年だが、その当時この会社は優れたセキュリティチームを持っていたけれども、そこにあまり多くの資金を割り当てなかった。セキュリティの実害に苦しんでいないときに大きな予算をセキュリティに割り当てることを正当化するのは難しい。
そのことは Microsoft を見ればよく分かる。Windows がコンピュータ業界を支配するようになって以後も、長年にわたり同社はセキュリティにあまり投資をしてこなかった。そして悪人たちが動き出すようになり、2001 年に至ってもはや Windows ベースの PC を攻撃から保護するのが不可能に近い状況になってしまった。Microsoft の最大の顧客、例えば大手の銀行や米国政府などは、セキュリティの防御をインストールしセキュリティ漏洩に対処するためのコストが急伸するにつれて、どこか他へ（Microsoft でなければ何にでも！）移行するぞと迫った。その結果生まれたのが、2002 年の Trustworthy Computing Initiative だ。そして、Microsoft は現在、業界で最も強力なセキュリティプログラムを持っている。
ほとんど予知能力があるとも思えるような一連の動きによって、Apple はその弾丸をかわしつつ、それでいてハンドヘルドデバイス市場で優位に立ち、パーソナルコンピュータ市場でシェアを増すという芸当をやってのけた。Apple は Microsoft の初期の失敗から正しい教訓を学び、その結果として iOS の深刻なマルウェアを私たちは一つも目にしていない（存在しているものの大多数は jailbreak 済みのデバイスを標的にしている）し、大規模な Mac マルウェアの蔓延も起こっていない。要するに、とりわけ iOS については、Apple は初期のうちに、つまり犯罪者たちが攻撃のエコシステムを築くことができるようになるより前に、セキュリティをきちんと整備したのだった。
けれども未来はクラウドの中にある。そして Apple の未来は iCloud にある。これはデバイスと、ソフトウェアと、サービスとのエコシステム全体を一つに結び付ける、オンラインの接着剤だ。私は自分の仕事の時間のほとんどをクラウドのセキュリティのために費やしてきたが、これは本当に言葉に言い表わせないほど難しい問題であって、私たちがこれらのサービスを利用する度合が増えるにつれて問題は悪化する一方だ。Apple は、他のすべての大手のクラウドプロバイダと同様に、今では銀行が直面するのと同じレベルのセキュリティの問題に直面している。（Willie Sutton [訳者注： 有名なアメリカの銀行強盗] の言葉「そこに金があるから」を思い出して頂きたい。）
どんな銀行にでもセキュリティについて尋ねてみるとよい。彼らは間違いなく、顧客のアカウント（口座）が問題だと答えるだろう。
水にまき餌する -- 「有名人のヌード写真」という言葉ほど、人の注目を集める見出しは他にないだろう。その結果起こったメディアの狂乱のような騒ぎは「水にまき餌する」などという言い回しでは到底表現できないようなものであった。その上、そこに世界で最も人気あるテクノロジーブランドが関係しているとなれば、そして、問題が発生したのがその会社のここ数年で最大の新製品発表が行なわれるほんの数週間前だったとなれば、そしてその新製品の中にメジャーな新しい金融サービスが含まれていたとなれば、もうこれは例外中の例外とも言うべき悪夢の報道発表となるのは避けられない。
今ではその騒ぎを皆さんご存じだろう。Labor Day [訳者注： 9 月の最初の月曜日] の週末にかけて、百人ほどの著名人たちのヌード写真がインターネットに出回った。漏洩源は iCloud バックアップか iCloud 写真だろうという臆測がたちまち広がったが、それはほんの数日前に iCloud を直接力づくの方法で攻撃する新しいツールがリリースされたからであった。大多数のクラウドサービスはこの力づくのやり方に制限をかけている。（そして Apple もすぐにブロックをかけた。）
その後明らかになった真実はそれよりほんの少し劇的の度が低いものであったが、憂慮すべき度合は決して低くなかった。48 時間経たないうちに Apple は iCloud 自体がハックされたのではなく、力づく攻撃のツールが介在していたのでもなかったと発表した。そうではなくて、個々の有名人が意図的に標的とされ、その人たちの写真が、おそらく iCloud への iOS バックアップから盗まれたのだと判明した。この犯罪はおそらく長期間にわたって行なわれたもので、必ずしもすべての写真が iCloud から来たものではなかった。
40 時間を超える調査の結果、インターネットで最近非常に多くなっている、ユーザ名、パスワード、セキュリティーのための質問を対象とした非常に的を絞った攻撃により、特定の著名人のアカウントが乗っ取られてしまったことが明らかになりました。私たちが調査したケースのどれもが、iCloud(R) や Find my iPhone を含む Apple のシステムに欠陥があったことから発生したものではありませんでした。Appleは、本件に関わった犯罪者の特定に向け、捜査当局と協力を続けています。
このような攻撃から守るため、ユーザの皆さまには常に強力なパスワードを用い、2 段階の認証を有効にしておくことを推奨いたします。
iCloud がハックされた訳ではなかったと言うが、iCloud はハックされた。サービスの核心的な脆弱性を攻撃したものではなかったが、犯罪者たちは有名なユーザーたちを標的として、一連のアカウント乗っ取り攻撃をかけたのだった。彼らはパスワードや、パスワード回復のための質問を見つけ出した。私の推測では、彼らはおそらくそうやって手に入れた当初の情報をもとにフィッシングのテクニックを使って犠牲者の友だちや同僚たちを釣り上げたのだろう。そのようにして彼らは iCloud 認証情報を手に入れ、それからハッキングツールを使って iCloud バックアップのコピーを取り込み、Apple の通常の新規デバイス通知（主として Messages と FaceTime が使われる）も二要素認証さえ回避した。二要素認証は、新規購入や核心的な Apple ID 変更しか保護していなかった。
Apple は苦境に陥った。これは iCloud に特有の問題ではなかったし、同社としては基本的に顧客が自分のアカウントを十分に保護していなかったと非難するしかなかった。そして Apple は解決策として二要素認証を推奨した。それは問題が起こった当時には攻撃を阻止することができなかったのだが。（当時は iCloud ログインやバックアップに二要素認証は適用されていなかった。）あ痛っ。
公正のために言えば、アカウントの乗っ取りがインターネットで非常に多くなっていると述べた点で Apple は正しかった。けれども Apple の決断のいくつか、例えば二要素認証で保護されるサービスの範囲を限定したことや、パスワード回復のための質問（これはパスワード破りに使われやすいことで悪名高く、とりわけ有名人なら深刻だ）に依存したこと、またサーバ上での異常な活動を探知しなかったことなどは、すべて攻撃者たちの仕事を容易にする結果となった。
iCloud が一般的な意味で破られたのではなかったが、だからと言って Apple がすべきことを全部したことにはならない。そして、たとえ同社がもっと多くの手を尽くしたとしても、このような持続的な攻撃を防止できる保証はどこにもない。アカウントの乗っ取りは途方もなく深刻な問題であり、撲滅するのは不可能で、私たちがクラウドコンピューティングにますます依存するようになるにつれて唯一最大の難問になるのは間違いないと思われる。
パスワードはどこで「ゴルディアスの結び目」になるか -- 身元を明らかにするというのは複雑な問題だ。とりわけ、身元という概念自体が一時的なものなのだからなおさらだ。よくある名前を持つ友人に聞いてみるとよい。例えば私たちスタッフの一員 Michael Cohen (彼は著名な Michael Cohen リストにあるどの人とも別人だ) も同意してくれるだろう。デジタル世界において、私たちは 身元 の証明についてはあまり気にせず、むしろ 認証 について気にする。つまり、コンピュータに対して、特定のアカウントに対応した人物が自分であることを証明することが問題なのだ。
私たちはそれを、自分が知っているもの (パスワード)、自分が持っているもの (スマートカードや iPhone アプリ生成のコードなどのデジタルトークン)、あるいは自分自身 (指紋) を使ってする。これらのもののうち多くをチェックすればするほど、認証は強力になる。
パスワードはほとんど常に認証の要素の一つとして使われている。トークンにはコストがかかり、またなくしやすい。指紋、あるいはどんな生体要素も、深刻なプライバシーの問題を引き起こすと同時に信頼性をもって運用するのが難しい。トークンも指紋も、遠隔サービスにログインする目的には適していない。なぜなら、すべての人が自分用のリーダーを必要とするからだ。どんなウェブサイトにログインするにもクレジットカードをスワイプしなければならなかったと想像してみよう。そのようなシステムの複雑さは、規模が大きくなれば、現行のテクノロジーやソーシャルな制約から見てほぼ到達不可能だろう。いったい誰がカードを提供するのか？ いったい誰があなたの指紋のテンプレートを管理するのか？ いったいどうやってすべての情報伝達をするのか？ 多くの場合トークンや指紋は パスワードよりセキュア度が低い ので、私たちはそれらを主要な要素としてでなく、二次的な要素として使う傾向にある。
パスワードへの依存を軽減することは、解決不可能な問題ではないかもしれないが、解決までにはまだまだ長い道のりが控えている。
事態を悪化させているのが、アカウントのオーナー権と復旧の問題だ。私たちはパスワードを忘れるし、私たちはスマートカードをなくす。私たちの指紋も変わることがある。そうした事実があっても私たちは自分のアカウントへのアクセスを制限されたくはないので、私たちは復旧のメカニズムを加える。そのためにはもう一つ別の、もっと強いパスワードが必要になって、ユーザーたちはそれを書き留めて安全なところにしまっておくよう勧められるが、でも書き留めたものというのは、当然ながら、安全ではない。あるいは、私たちはユーザーにセキュリティ質問を要求してそのアカウントのオーナーだけがそれに答えられることを願うかもしれないが、覚えられる質問ならば、それはすなわち解明できる質問であり、そのことは今回ハックを受けた著名人たちが身をもって体験した通りだ。
Apple の難問 -- Apple、Google、その他クラウドプロバイダ各社は、今では私たちの生活の中の最もプライベートで重要な側面を管理している。私たちは彼らを信用して、驚くべき範囲の情報を、時には直接の金銭的価値を持つような情報さえ、彼らに託している。彼らは実質的に銀行と化している。
銀行をセキュアにするのは簡単なことではない。アカウントの乗っ取りは今も日常的に起こっているけれども、私の経験から言えば、たいていのオンラインサービスに比べれば乗っ取りの頻度はずっと低い。銀行は幅広い種類のセキュリティツールを配置している。ツールの名前は「リスクベース認証」「ユーザー挙動分析」「不正行為対策分析」などさまざまだ。これらのツールは数多くのアカウント乗っ取りの試みをキャッチするが、全部をキャッチできる訳ではない。金融機関は他のどの垂直市場に比べてもはるかに多くの努力をセキュリティのために費やしている。
著名人たちの写真盗難の後で私が目にした Apple に対する批判のいくつかは正当なものだった。力づくのツールの有効性に基づいて判断すれば（たとえそれが今回の攻撃に使われなかったとしても）Apple ほどの規模と重要性を持つクラウドプロバイダに期待される探知と分析のテクニックを Apple が用いていたようには見えなかった。二要素認証（パスワードと、スマートフォンに送られるコードとを用いる認証）は iCloud サービスの多くに適用されておらず、しかもセットアップの手間が驚くほど複雑だった。しかも Apple は不審な活動を通知することもしなかった。それがあれば顧客たちに対して誰かがアカウントにアクセスしデータを引き出しているという警告になっただろうに。
力づくの攻撃のやり方を見過ごしていたことを除けば、Apple のセキュリティチームがこれらの決断に対して非難されるべきとは言えないだろう。彼らはこの業界でもトップクラスのチームであるが、明らかに彼らは容易く退けられぬ他の事柄も考慮せざるを得ないという制約を受けていた。ユーザー通知をあまりに多く送り過ぎれば、あっという間に通知が意味を失ってしまう。あまりにも頻繁に二要素認証を要求すれば、ユーザーたちが背を向けてしまう。それでも、今回の事件よりも以前から私はそうした懸念を持っていた。私はいつも、パスワードがいくら強いものであってもアカウントの乗っ取りによって自分のデータが危険に晒されることがあり得るのが心配だった。私は、自分のデバイスのいくつかでは iCloud バックアップさえ使っていない。
批判の多くや、提起された解決策の多くは、考えの甘いものであった。二要素認証を義務化せよと書いたライターたちは非常に多かった。私の場合、複数の iPhone や iPad を持っている上に、信用できる妻もいるので、そうなっても不満はない。でも、もしもあなたがたった一台の iPhone しか持っておらず、アカウントの復旧を任せられる信用できる人もいなければどうだろうか？ 電子メールでパスワードをリセットするのも別の方法としてあるけれども、その電子メールアカウントも乗っ取られたり、またはなくしたデバイスを使ってしか電子メールにアクセスできなければどうするのか？ Apple ストアへ ID を携えて行けばよい？ それは都会に住む人には良いだろうが、猛烈に不便だと思う人たちはとてつもなく多くいる。
何億人もの顧客たちが Apple 製品を使っている。iCloud 利用者の数がどれくらいなのか私は知らないが、とにかくここで考えているのは 週末のうちに 1 千万台もの iPhone を売り上げた会社だ。付随的な状況が数百万ものユーザーたちを取り囲めば、セキュリティの複雑さは飛躍的に増す。Apple がそれほどのスケールで動いているのなら、ルールそのものが変わってくる。
行動分析（ビッグデータや自動分析を通じて通常挙動からの逸脱を識別するもの）でさえ、どこかの時点で失敗に陥る。例えばわが著名人たちを考えてみよう。彼女たちは映画の発表イベントで 10 日間に 10 ヵ国を回りつつデバイスを使うかもしれない。そんな際に、攻撃を探知するために設けられているアカウントのルールも、彼女たちには特別扱いで除外される可能性が高いだろう。
こうして、Apple は社会の中で最も複雑なセキュリティの難問に直面することになる。そして、直面する問題のスケールは、ほんの少数の会社しか考慮する必要のないほど大きなものだ。
全部ひっくるめると -- Apple はそのデザインと技術的リソースを駆使して困難なセキュリティの問題に取り組める能力を持っている。Touch ID は指紋テクノロジーの優れた実装だ。Apple は他の誰とも違う方法で問題に取り組み、プライバシーを暴露することなく使い勝手とセキュリティの双方を増すために複雑な問題を単純化した。Messages、FaceTime、iCloud Keychain といったものもすべて、平均的なユーザーにはほとんど分からないところで暗号化を巧みに活用しつつ、さらに大きなセキュリティの懸念を持つ人々のためにより複雑なオプションにも対応できるようにしている。Gatekeeper は蔓延する Mac マルウェア市場の可能性ををそれが成長するよりも前に実質的に摘み取った。また、Apple Pay はかつて実装されたことのある決済システムの中で最もセキュアかつシンプルなもののようだ。
これらすべてと、Apple による二要素認証の実装とを比べてみよう。それは、他の誰のものに比べても決して良いとは言えず、ごく最近になるまで実際かなり悪いものであった。これもまた、途方もなく難しい問題がエレガントな解決策を求めて悲鳴を上げている事例の一つだ。認証とアカウント所有権に対する同社の答は問題を Touch ID 風に考え直すことを要した。そして明確化のために言い添えると、そこに取り組んだのは決して Apple が初めてではなかった。
著名人たちの写真盗難に対する Apple の当初の反応により、まず最も重大なギャップが閉じられた。今では、二要素認証を有効にしておけば、iCloud に関係するすべてが保護される。二要素認証はユーザ名とパスワードのみに依存するサードパーティのソフトウェアを動作できなくするので、Apple はアカウント全体を明かさないアプリケーション個別のセキュアなパスワードを作れる機能も追加した。アプリ個別のパスワードとはちょっとしたハックに過ぎず、大多数の他のコンシューマ向けクラウドプロバイダはその代わりに OAuth と呼ばれる標準を使っているが、直接 OAuth へ移行してしまえば開発者たちが追い付くまでの間多くのものが動かなくなってしまうだろう。ただ、Apple が結局はそれを必要としているのは間違いない。
Apple はまた、ログインやアカウントへの変更について以前より多くの通知を出すようになった。それは良いことだが、とりわけ iOS 8 になってデバイスレベルの新たな通知が多数増えたことを考えれば、Windows Vista 級の通知に向かって方針転換しつつあるかのようにも見える。
Apple がサーバ側で何をしているのかは私たちには分からないし、今後も分かることはないだろう。同社は、銀行が使っているものに似た幅広いテクノロジーを使っているのかもしれない。ただ同社がリスクベース認証を使っていないことは分かる。このテクノロジーにより、信頼できるコンピュータからログインしたかどうかを銀行が時折あなたに尋ねるようになる。それ以外の違いはたぶんないのではないかと思う。
私は Apple に対して何をすべきか命令する気もなければ、いろいろな会社にクラウドのセキュリティに関する助言をすることで生計を立てている者として語るつもりもない。けれども、Apple の将来のクラウドセキュリティに向けた動きとして、次の二つの基本的なことは事実となると思う：
Apple はこれからも認証の問題に取り組み、複数通りの角度からそれを攻めるだろう。それらはすべて、複雑な状況を単純化することに重点を置いたものとなるだろう。Apple が運営しているほどのスケールにおいてはどんなやり方もそれ単独で働けるものではないので、取り組むべき難問は異なるユーザー層に向けた幅広いオプションを単純化するものとなる。今日の Apple は、ひいき目に見てもそういうことには並みの結果しか残せていない。iCloud が Apple エコシステムの中心となるに従い、同社には新たな分野を開拓する必要があるだろう。銀行でさえ、国際化、膨大なユーザー数、多種多様な顧客のスキルという組み合わせに Apple と同じレベルで直面しているところはほとんどない。
Apple はクラウドセキュリティのありとあらゆる選択肢を使い、積極的な姿勢で新たなアプローチやテクノロジーを継続的に採用して行くだろう。犯罪者たちがユーザーアカウントを攻撃するための新たな方法を模索し続ける終わりのないいたちごっこの中で、それこそが論理的な発展であるからだ。Apple には優秀な サーバのセキュリティ があるが、アカウントのセキュリティ にはまた違った考え方と違ったツールが必要となる。
少なくとも私は、それこそ Apple がして行くことだと思っている。私にとって最も大きな恐れの一つは、Apple がシステムのエンジニアリングを改善するよりも、むしろユーザーの挙動を変えさせようと試みるのではないかという点だ。 Wall Street Journal とのインタビュー の中で Tim Cook はこう語った。「起こってしまったこの恐ろしい状況から一歩下がって、私たちにもっと何かができたのではないかと考えると、私の考えは使う人の意識の面に向かう。私が思うに、それを次第に高めて行くべき責任が私たちにはある。これは、本当はエンジニアリングとは別のものだ。」
セキュリティのプロフェッショナルとして私が従っている原則は「人の挙動が変わることを期待してはいけない。何があろうとも」というものだ。誰も、たとえ Apple でさえも、パスワードの必要を取り除いたり、あるいはアカウントを保護するためのたった一つで完璧に近いやり方を思い付いたりすることはできない。何億人というユーザーが関係していれば、教育に依存したり、より良いセキュリティ習慣に頼ったりすることもできない。絶対間違いなく Apple は、これら攻撃の可能性を減らせるためのエンジニアリングの選択肢を持っていたし、それらを実際に使ってきたはずだ。
Apple はたった三年間を投資しただけで Apple Watch の最初のバージョンをデザインすることができた。ならば、本気で問題に取り組みさえすれば、パスワードやアカウント乗っ取りについて Apple にどんなことができるのか、私は心から楽しみにしている。ただ、これは Apple がそれをすると決断すればの話だが。
コメントリンク15101 この記事について | Tweet リンク15101
文： TidBITS Staff: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
BBEdit 11.0.1 -- Bare Bones Software が BBEdit 11.0.1 をリリースした。広範囲にわたるメンテナンス・アップデートで、最近リリースされたバージョン 11.0 (2014 年 10 月 26 日の記事“BBEdit 11、既存の顧客のため機能をオーバーホール”参照) の後にユーザーから報告のあった問題点に対する一連の改良や修正を加えている。50 件近くもリストされた変更点から主なものを挙げれば、この古参のテキストエディタは起動時にスリープ状態を復帰させるために必要な時間を短縮し、旧来のフォーマットからカラースキームを適用することに関係したクラッシュ一件を修正し、起動時に HTML マークアップパレットの位置を正しく復帰させられなかったバグを解消し、書き出し環境設定に特定のフォントでテキストスムージングを無効にする設定を追加し、SGML/HTML 構文解析ツールが必要とする一時的メモリ量を削減し (サイズの大きな書類で良い効果があるはず)、また「世界が燃えるのを見たい人もいる」という理由で Preferences と Setup のメニューのコマンドに省略記号文字を追加した。（最後の変更は特に Michael Cohen のお気に入りだ。）BBEdit 11 の価格は新規ライセンスが $49.99 で、BBEdit 10 のユーザーは $29.99、BBEdit 9 かそれ以前の場合は $39.99 でそれぞれアップグレードできる。2014 年 5 月 1 日かそれ以降に BBEdit 10 を購入した人は無料でアップグレードできる。($49.99、バージョン 11 のライセンスがあれば無料アップデート、11.2 MB、リリースノート、10.8.5+)
CrashPlan 3.6.4 -- Code42 Software が CrashPlan 3.6.4 をリリースし、OS X 10.10 Yosemite に対応するとともに、詳細不明ながらセキュリティアップデートも施した。このインターネットバックアップソフトウェアは今回から、Code42 公開クラウドへのバックアップからもデフォルトのファイル選択からも Time Machine バックアップファイルを除外するようになった。今回のアップデートではまた、CrashPlan が一時停止している際に実行されたバックアップやリストアさえもログに含めるようになり、Mac OS Extended (Journaled, Case-Sensitive) ファイルシステムにおける大文字小文字の区別の問題を修正している。手動で CrashPlan 3.6.4 をダウンロードする必要はない。アプリが自動的に自らをアップグレードするはずで、まだそれが起こっていなくても数日中に起こるはずだ。バージョン番号はアプリ起動時のスプラッシュ画面にも、また Settings > Account 画面にもはっきりと表示される。(30 日間試用できる CrashPlan オンラインバックアップサービス付きで無料、51.3 MB、リリースノート、10.5+)
Quicken 2015 for Mac 2.2 -- Intuit が Mac 用の財務管理ソフトウェア Quicken 2015 のバージョン 2.2 をリリースした。（最近 Glenn Fleishman がレビューしている。2014 年 10 月 2 日の記事“Quicken 2015： あともう少し、でもまだ許容範囲にない”参照。）多数の改善や修正が含まれている。今回のアップデートでは、Quicken Windows または Quicken for Mac 2007 から既存のアカウントのために自動ダウンロードをセットアップする際に役に立つ新機能が加わった。また、手で入力した取引や同じアカウントから読み込んだ取引のための Download Matching 機能を改善し、Security List で有価証券を統合する機能を追加し、過去の Quicken リリースの複数の既存のアカウントを一つの Quicken 2015 for Mac ファイルに読み込む機能に対応し、新規ウィンドウの中に記録簿またはレポートを開くためのキーボードショートカット Control-O を追加している。今回のリリースではまた、過去のバージョンの Quicken からアカウントを読み込むことに関係したいくつかの問題点を修正するとともに、Bill Reminder の中で残高が正しく算出されなかったバグを解消し、モバイル同期にいくつか修正や改良を加えている。この記事の執筆時点で Mac App Store ではまだ Quicken 2015 for Mac のバージョン 2.1.1 のままだが、Intuit はもうすぐ最新リリースが入手できるようになると約束している。(新規購入 $74.99、無料アップデート、リリースノート、10.7+)
Quicken 2015 for Mac 2.2 へのコメントリンク:
Pixelmator 3.3 -- The Pixelmator Team が、同名の 画像編集アプリ Pixelmator のバージョン 3.3 (ニックネームは Limestone) をリリースし、OS X 10.10 Yosemite にうまく調和するようにインターフェイスのデザインを更新した。さらに、Pixelmator 3.3 では iCloud Drive や Continuity などの Yosemite 機能にも対応し、Handoff 機能を使って Mac 上の Pixelmator と iPad 上の Pixelmator for iOS との間で切り替えて使えるようにした。今回のアップデートではまた、Repair Tool 拡張を提供することにより Apple Mail や TextEdit の中にある画像を Pixelmator アプリを開かず編集できるようにしている。(Mac App Store から新規購入 $29.99、無料アップデート、42.8 MB、リリースノート、10.9.5+)
ReadKit 2.4.2 -- Webin が ReadKit 2.4.1 をリリースし、OS X 10.10 Yosemite との間や、Feed Wrangler との同期パフォーマンスおよびスマートストリーム処理との間の互換性のための改善を加えた。この RSS クライアントおよび「あとで読む」アプリはまた、スマートフォルダのバッジ環境設定で項目数か未読数のどちらかのみを表示するオプションを追加し、内蔵 RSS でフィードタイトル改名に関係したいくつかの問題点を修正し、フィード・フォルダ・スマートフォルダの削除の際に確認を追加し、「あとで読む」サービスのフォルダで未読バッジに影響を与えていたバグを解消し、記事から記事へナビゲーションする際の選択を修正している。バージョン 2.4.1 をリリースした後間もなく、Webin は移行の際の問題点に関係したバグをいくつか修正する ReadKit 2.4.2 をリリースした。(Mac App Store から新規購入 $9.99、無料アップデート、4.1 MB)
文： TidBITS Staff: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
今週の ExtraBITS では、EFF が主流のメッセージングにおけるセキュリティで Apple が先頭を行っていると発表し、Apple Watch 用アプリとしてどんなものが期待できるかを一人の開発者が語り、Apple が中国産の変種のマルウェアを素早く阻止し、Rob Griffiths が Mac OS X Hints に別れを告げ、間もなく Microsoft Office と Dropbox がフルに統合される。
EFF いわく： Apple が最高の主流メッセージングセキュリティを提供 -- Electronic Frontier Foundation が、オンラインのメッセージングシステムのセキュリティを測定したスコアカードを発表した。プレスリリースにおいて EFF は「Apple の iMessage および FaceTime 製品が大衆市場における選択肢の中で傑出した結果を示した。ただし、現在そのいずれも、標的を絞った高度な監視活動に対する完璧な保護は提供できていない」と述べた。iMessage と FaceTime が減点された二つの分野は、ユーザーが相手の人物確認を検証する役に立つ点と、コードをオープンにして独立の第三者に点検させる点だ。
Apple Watch のアプリに何が期待できるか -- 開発者 David Smith は Apple が Apple Watch に関して公にした情報を調べて、どのようなアプリが期待できるかを考えた。彼は、開発者がアプリを書くために必要な WatchKit API が二段階に分けて出されることに気付いた。第一段階には、アプリが作成できるアクション可能な通知や Glance (iOS 8 での通知やウィジェットと同様に動作するもの) の範囲に制約がある。今年のうちに開発者たちは第一段階のアプリを作り始められるようになるが、フルにネイティブなアプリが約束されている第二段階が始まるのは来年の後半、おそらく 2015 年 6 月の WWDC の後と思われる。
Apple、中国の WireLurker マルウェアを阻止 -- Apple が WireLurker マルウェアを素早く阻止した。このマルウェアは感染した Mac を経由して中国の iOS デバイスに広がりつつあった。（Mac と iOS デバイスの有線接続が必要だった。）中国に限って広がったこの WireLurker は、Palo Alto Networks によって発見された。Apple は素早くそのコード署名を無効にし、jailbreak されていない iOS デバイスが感染しないよう予防措置を講じた。しかしながら、研究者たちは将来コードが書き換えられて再び攻撃が始まる可能性もあると警告している。
Mac OS X Hints への非公式な別れ -- これは決して公式に閉鎖された訳ではないが、創設者 Rob Griffiths が Mac OS X Hints に別れの言葉を述べた。このサイトは最近 45 日間以上にわたり更新されていない。彼は 14 年前にこのサイトを始め、その後 2006 年に Macworld に売却したが、彼は 2010 年までこのサイトの管理を続けた。Griffiths はこのサイトの終了の原因として管理の失敗を述べてはおらず、むしろ OS X が成熟したことを理由に挙げている。
Dropbox が Office にやって来る -- もしもあなたが Microsoft Office を使っていて、Dropbox に対応していないことに不満を感じていたなら、あなたの悩みはもうすぐ解消される。間もなく、Dropbox ファイルを Office の中から開いたり、Dropbox アプリの中で Office ファイルを編集したりできるようになる。また、Dropbox は同社のウェブサイトを来年には Office Online と統合させることを計画している。
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。
告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。
TidBITS ISSN 1090-7017©Copyright 2014 TidBITS: 再使用はCreative Commons ライセンスによります。
, 
日本語版最終更新：2014年 11月 14日 金曜日, S. HOSOKAWA