GoogleがマップとYouTube、そしてアシスタント向けにプライバシー強化機能を追加

Google(グーグル)は米国時間10月2日、消費者向けのいくつかのプライバシー機能を新たに発表した。対象となるのは、Googleマップ、YouTube、Googleアシスタントなどの特に使用頻度の高いアプリだ。これらの機能は、そうしたサービスを利用するユーザーからGoogleが収集するデータを、ユーザー自身がコントロールし、自ら管理して削除もできるようにするためのもの。場合よっては、そもそもGoogleがデータを収集できないように設定することもできる。

Googleマップでは、以前からChromeブラウザーに搭載され、その後YouTubeでも利用可能となったシークレットモードが使えるようになった。

基本的な考え方としては、特定の場所を検索したり、町をぶらついたりするとき、Googleにマップの利用状況を追跡されたくないこともあるだろう、という状況に対応するもの。

マップで追跡されることをオプトアウトしたくなる理由には、いろいろ考えられる。例えば、パーソナライズされたお勧め情報を関係ないデータで乱したくないという場合もあるだろう。あるいは、自分のすべての検索と、正確な位置情報を、1つの会社がずっと追跡しているのは、あまりに不気味で気に入らない、という人もいる。

マップアプリで、プロフィール写真をタップすると表示されるメニューから、シークレットモードを有効にできる。この機能は今月にはAndroidでリリースされ、その後iOSでも利用可能となる。

一方YouTubeアプリには、YouTubeの履歴を自動削除する機能を提供する。これによりユーザーは、YouTubeの履歴を保持しておく期間を、たとえば3カ月、あるいは18カ月のように設定可能となる。その期間を超えた履歴は、自動的に削除される。ユーザーが、特定の履歴を選んで手動で削除することも可能だ。

そしてGoogleは、ついにGoogleアシスタントでのプライバシー問題にも取り組んでいる。

「オーケーグーグル、どうやって私のデータを安全に保存してくれるの?」と言って、詳しいことを尋ねてみてもいいかもしれない。しかしほとんどの消費者が、このようなコマンドを実際に口に出すとは考えにくい。

それよりも、音声コマンドを使ってアシスタントのアクティビティを削除できる新機能の方が役に立つ。今後数週間のうちにも追加されるはず。

たとえば、「オーケーグーグル、今言ったことを削除して」とか「オーケーグーグル、先週言ったことは全部削除して」と言うことができる。

1週間より以前に言ったことを削除したい場合、アシスタントはユーザーをアカウント設定ページに移行させるので、そこで実行できる。これはちょっと面倒だが、少なくとも以前よりは少ないステップで実現できるようになった。

ボイスアシスタント機能が収集したデータの扱いについて、最近ちょっとした騒ぎになっていた。そうしたアシスタント機能は、完全には無人化されていないことを、ニュースメディアが消費者に警告したからだ。実際には、録音された音声ファイルを人間がレビューし、アシスタント機能の反応や応答を調整したり、改善したりするために利用していたのだ。

Googleアシスタント、Alexa(アレクサ)、さらにはApple(アップル)のSiriも、この新しい分野におけるプライバシーの保護に注意を払っていなかったことを非難されるに至った。そして3社とも、それぞれ対策を余儀なくされた。

たとえばAmazonは、Alexaの録音を人間がレビューすることを、ユーザー自身がオプトアウトできるようにした。Appleは、Siriの応答グレーディングプログラムを世界中で停止した。これは、将来のソフトウェアアップデートで、プライバシーコントロールの問題に対処できるようになるまでの措置、としている。

Googleによれば、アシスタントのデータを削除するための新たな音声コマンドは、数週間以内に利用可能になるという。まずは今週、英語について使えるようになり、来月には、他のすべての言語でも有効になるとしている。

また別のセキュリティ関連の機能強化として、GoogleはパスワードマネージャにPassword Checkup(パスワード チェックアップ)と呼ばれる新機能を導入することを発表した。ユーザーのパスワードが弱いものだったり、複数のサイトで使い回していたり、あるいは漏洩してしまったことをGoogleが検出した場合に、通知してくれる。

こうした機能は、ほとんどのサードパーティのパスワード管理アプリでは標準的なものであり、それを今Googleが取り込むことにも意味がある。

Password Checkupは、すでにパスワードマネージャを開けば利用できる。今年後半にはChromeに直接組み込まれる予定となっている。

原文へ

(翻訳:Fumihiko Shibata)

米セキュリティ企業の内部ファイルにアクセスが可能なパスワードがGitHub上で公開されていた

誤ってインターネット上に公開されていた電子メールアドレスとパスワードを使って、とあるハッカーがセキュリティ企業でありSSL証明書の発行も行っているComodo(コモド)社の、内部ファイルとドキュメントへのアクセス権限を手に入れた。

この認証情報は、GitHub上にComodoのソフトウェア開発者が所有していた公開リポジトリ上に置かれていたものだった。電子メールアドレスとパスワードを手に入れたあと、そのハッカーはMicrosoft(マイクロソフト)のクラウドサービス上に構築されたComodoのシステムに侵入することができたのだ。そのアカウントは2要素認証で保護されていなかった。

認証情報を発見したのは、オランダを拠点にするセキュリティ研究者のJelle Ursem(イェレ・ウーセム)氏だ。彼はComodoのRajaswi Das(ラジャスウィ・ダス)副社長にWhatsApp経由で、アカウントを保護するように連絡した。翌日にはパスワードが無効になった。

ウーセム氏はTechCrunchに対して、そのアカウントにアクセスすることでComodoの内部ファイルやドキュメントにアクセスすることができたと語った。アクセスできたものには同社のOneDrive上のセールスドキュメントやスプレッドシートも含まれており、さらにSharePoint上の同社の組織図を通してチームメンバーたちの経歴、電話番号や電子メールアドレスを含む連絡先、写真、顧客のドキュメント、カレンダーその他の情報にもアクセスが可能だった。

comodo calendar

Comodoの社内サイトにあるスタッフカレンダーのスクリーンショット(画像は提供されたもの)

彼はまた、複数の顧客との合意書や契約書を含んだフォルダーの複数のスクリーンショットをTechCrunchに示した。そこでは例えば病院や米国州政府などの顧客名が、各ファイルの名前として示されていた。他には、Comodoの脆弱性レポートのように見えるものもあった。しかし、ウーセム氏によるざっとした調査では、顧客の証明書の秘密鍵は見つからなかった。

「彼らはセキュリティ企業であり、SSL証明書を配布しているのですから、自社の環境のセキュリティが何よりも優先されていると普通は想像するでしょう」とウーセム氏は言う。

しかしウーセム氏によれば、この公開されていた電子メールアドレスとパスワードを見つけたのは彼が初めての人物ではなかったのだと言う・

「すでにこのアカウントは、スパムを送信している他の誰かによってハッキングされていたのです」と彼はTechCrunchに語った。彼は、フランス財務省からの税金の払い戻しを騙る、とあるスパムメールのスクリーンショットを示した。

私たちはこの記事を公開する前に、Comodoにコメントを求めた。彼らの広報担当者は、このアカウントは「マーケティングおよび取引の目的で使用される自動アカウントです」と述べ、「アクセスされたデータはいかなる意味でも改ざんされておらず、研究者から通知を受けて数時間以内にロックされました」と付け加えた。

これは、開発者がコードをオンラインで保存する公開GitHubリポジトリの中で、企業のパスワードが公開されていることが発見された最新の事例である。多くの場合開発者たちは、不注意のうちに、内部のみのテストに使用されるべき秘密の認証情報を含むファイルをアップロードしてしまう。ウーセム氏のような研究者は、定期的にリポジトリの中のパスワードをスキャンして企業に報告している。多くの場合それはバグ発見の報奨金と引き換えに行われている。

今年の初めにも、ウーサム氏は、GitHubの公開レポジトリ上で、Asus(エイスース)の従業員による内部パスワードの公開が行われていることを発見した。2016年には、Uber(ウーバー)もハッカーがGitHub上で内部認証情報を見つけたために情報漏洩が起きている。

関連記事:Asus was warned of hacking risks months ago, thanks to leaky passwords

画像クレジット: Getty Images

[原文へ]

(翻訳:sako)

株取引アプリのロビンフッドがパスワードを平文で保存していた

米国時間7月24日、株取引アプリのRobinhood(ロビンフッド)が、一部のユーザーのパスワードを含む資格情報を社内システムに平文で保存していたことを明らかにした。これはきわめて深刻なセキュリティ上の誤りだが、同社はデータに不適切にアクセスされたことを示す証拠はないとしている。とはいえ、ユーザーが危険にさらされた恐れがある。念のため、今すぐパスワードを変更しよう。

パスワードや個人情報といった扱いに注意を要するデータは、通常、常に暗号化して保存される。最悪、侵入されてデータベースが流出したとしても、攻撃者にはわけのわからないデータだ。しかし残念ながら、このルールが守られていなかったようだ。

多くのユーザーがRobinhoodから次のようなメールを受け取った。CNETJustin Cauchon氏もそのひとりだ

お客様がRobinhoodのアカウントのパスワードを設定する際、弊社では業界標準のプロセスに従って、社内で誰もパスワードを閲覧できないようにしてきました。7月22日の夜、弊社は一部のお客様の資格情報が読める状態で社内システムに保存されていることを発見しました。その中にはお客様のパスワードも含まれていたことをお知らせします。

弊社はこの問題を解決しました。また徹底的に調査した結果、弊社対応チーム以外からのこの情報へのアクセスは認められませんでした。

本当に「業界標準」だったら、他社もパスワードを平文で保存していることになる。そう考えれば、GoogleFacebookTwitterなどにも最近同様の誤りがあったことの説明がつくかもしれない。

Robinhoodの担当者は、この問題に迅速に対応したことを強調した。しかし、問題が発見された経緯、平文で保存されていた期間、この問題の原因となった業界標準からの逸脱、影響を受けたユーザーの数はコメントしておらず、今後これらの点について回答するかどうかも明らかにしていない。同社は次の声明を出した。

我々は速やかにこの情報の記録の問題を解決した。徹底的に調査した結果、弊社対応チーム以外からのこの情報へのアクセスは認められなかった。念のために、我々は影響を受けた恐れのある顧客に通知し、パスワードをのリセットを促した。我々は顧客に対する責任を真摯に受けとめ、顧客の情報の安全に全力を尽くす。

もしあなたがRobinhoodからのメールを受け取ったらアンラッキーだ。パスワードを変更しよう。もし受け取らなかったら……。それでもパスワードを変更しよう。気をつけるに越したことはない。

[原文へ]

(翻訳:Kaori Koyama)

Windows 10がパスワードの期限切れポリシーを廃止

5月は記念すべき月だった。健全性と実用主義が不合理な妄想に勝利した。もちろん政治の話をしているのではない。Microsoft(マイクロソフト)がようやく(そう、ようやく!それでもやったことを讃えよう)Windows 10のセキュリティー基本計画のパスワード期限切れポリシーを廃止した。

多くの大企業や組織が(TechCrunchの親会社 Verizonも)、ユーザーにパスワードを定期的に変更するよう求めている。これは、著しく非生産的なポリシーだ。マイクロソフトは、以下のようにコメントしている

最近の科学研究が、パスワード期限切れポリシーを始めとする長年続いているセキュリティー方針に疑問を投げかけ、より効果のある方法を提案した。パスワードが盗まれなければ、期限切れにする必要はない。そしてパスワードが盗まれた証拠があるなら、直ちに行動すべきであり期限が来るまで問題解決を待つことはない。

もし組織が禁止パスワードリストや多段階認証を導入し、パスワードを予想する攻撃や無人ログインの試行などを正しく検出していれば、定期的なパスワード変更は必要ないはずだ。そしてもし、最新のセキュリティー対策が施されていないのなら、パスワードの有効期限にどれほどの効果があるだろうか? 定期的なパスワード変更は過去の遺物であり、非常に効果の薄い対策だ。

そういう組織でパスワードを使っている人は、システム管理者にこのブログ記事を送ることをお勧めする。もちろんはじめは無視されるだろうが、それは大企業のシステム管理者とはそういうものだからであり、情報セキュリティーというものは規則を増やすだけの不合理な「一方向ラチェット」だからであり、我々の恐怖のカルチャーが実際のセキュリティーよりもセキュリティー劇場の方を重んじるからだ。しかし、いずれは世界が動いていることをしぶしぶ認め始めるだろう。

代わりにすべきことは、LastPassや1Passwordのようなパスワードマネージャーを使おう(無料バージョンでも十分有効なので使わない言い訳はできない)。これを使えばパスワードの使い回しを排除あるいは少なくとも最少にできる。2段階認証が用意されている場合は必ず使うこと。Number PortingやとSS7 attackなどの問題を指摘されているSMSの2段階認証でさえ、一段階認証よりずっといい。

そして、コードやデータのリポジトリーを使っている人には、パスワードやAPIキーを保存しないようにお願いする。私はコンサルタント会社のCTOだが、この残念な事象で相談に来るクライアントの数に読者は驚くに違いない。リポジトリーのアクセス管理はあまり厳重ではないので、repoファイルはごく簡単にコピーできるし、置き場所を間違えることもある。そして、ひとたび個人情報を登録してしうと、完全に削除することはおそろしく面倒だ。代わりに、環境変数のように簡単なものを使うだけでもいろいろな意味で大きな前進であり、複数環境にわたって作業するにも便利だ。

完璧なセキュリティーは存在しない。世界水準のセキュリティーは扱いにくい。しかし、適度に強力なセキュリティーは、いくつかの基本ルールを守っていれば十分使いやすい。そのためにはルールを最小限にするのがよいし、意味のないルールは廃止すべきだ。パスワードの有効期限はその1つだ。バイバイ、有効期限。せいせいした。

[原文へ]

(翻訳:Nob Takahashi / facebook

Googleが2005年以来G Suiteのパスワードが平文保存されていたことを公表

Googleは、同社のエンタープライズ顧客の一部システムで、誤ってパスワードが平文で保存されていたことを発表した。

検索の巨人は米国時間5月21日にこの問題を公表したが、正確にどれだけの顧客が影響を受けたのかは語らなかった。「当社のG Suite利用者の一部に対して、パスワードの一部が社内の暗号化システムにハッシュされずに保存されていたことを通知した」とGoogleのエンジニアリング担当副社長Suzanne Frey氏はコメントした。

通常パスワードはハッシュアルゴリズムを利用して暗号化され、人間が読めないようになっている。G Suiteの管理者は、社員ユーザーの新パスワードを手動でアップロード、設定、リカバーすることができる。これは新しい社員が加わったときに利用する機能だ。しかしGoogleは今年4月、2005年に実装したパスワード設定、リカバリーの仕組みに誤りがあり、パスワードを平文で保存していたことを発見した。その後Googleは同機能を削除した。

今回のセキュリティー障害によって消費者向けGmailアカウントが影響を受けることはない、とFrey氏はコメントしている。「なお、問題のパスワードは当社の暗号化されたセキュアシステム基盤内に保存されていた」とFreyは言った。「問題は既に修正されており、該当するパスワードが不正利用された形跡はない」。現在Googleには500万人以上のG Suiteユーザーがいる。

Googleはまた、今月G Suiteの新規ユーザー登録でトラブルシューティングを行っていた際、第2のセキュリティー欠陥を見つけたことも発表した。Googleによると、1月以降にG Suiteのハッシュされていないパスワードの「一部」が内部システムに最大2週間保存されていた。このシステムをアクセスできたのは、一部の権限を持つGoogleスタッフのみであったとGoogleは公表した。

「この問題は修正済みであり、ここでも対象となるパスワードの不正アクセス、不正利用の形跡はなかった」とFrey氏は述べている。Googleは、G Suite管理者にパスワード障害について警告済みであり、パスワードを変更していないアカウントのパスワードは近くリセットすると表明している。

広報担当者は、Googleが今回の問題をデータ保護当局に報告したことを正式に認めた。

この一年間に秘密データを平文で保存したことを認めた会社としてはGoogleが最新になる。Facebookは3月に、FacebookおよびInstagramのパスワード「数億件」を平文で保存していたことを公表した。TwitterGitHubも同様のセキュリティー問題があったことを昨年認めている。

関連記事:

[原文へ]

(翻訳:Nob Takahashi / facebook

マイクロソフトはパスワードを期限切れにするポリシーの廃止を検討

Microsoft(マイクロソフト)は、ユーザーに定期的に自分のログインパスワードを変更することを要求するWindowsのポリシーを廃止することを提案した。

公式のブログ記事でMicrosoftは、新たなセキュリティ設定のベースラインの草案では、数週間ごと、あるいは数ヶ月ごとにパスワードを変更することをユーザーに強制することをやめたと明かしている。対象となるのは、ネットワークのグループポリシーによってアカウントが制御されているユーザーだ。

Microsoftのセキュリティベースラインのドキュメントの草案には、企業のネットワークに接続しているすべてのユーザーのグループに効力のある推奨ポリシーが記述されている。その中には、特定の機能やサービスを制限することで誤用や悪用を防ぐためのルールや、マルウェアがシステムやネットワークを攻撃するのに利用する可能性のある機能を隔離する際のルールなどが含まれている。

同社によれば、これまでのパスワード変更ポリシーは「古風で時代遅れになった存在価値の低い対策」であり、もはや「意味があるとは考えられない」としている。

以下は、MicrosoftのAaron Margosis氏の見解だ。

定期的にパスワードを期限切れにすることは、パスワード(またはハッシュ)がその有効期間中に盗まれて、不正に使用されるということを想定した状況にだけ有効な防御策です。もしパスワード盗まれていなければ、それを無効にする必要はありません。逆にもしパスワードが盗まれたという証拠があるなら、むしろ直ちに行動すべきであって、有効期限が切れるのを待ってから問題に対処するという手はないでしょう。

仮にパスワードが盗まれた可能性が高いと考えられる場合、その盗まれたパスワードの使用を許可し続けることが許容される期間は何日間でしょうか? Windowsのデフォルトでは42日です。それは、ばかばかしほど長い期間のように思われるのではないでしょうか?まあ、そのとおりです。私たちの現在のベースラインでは60日としています。以前は90日でした。というのも、頻繁な期限切れを強制すると、また別の問題が起こるからです。そして、もしパスワードが盗まれるということがないのであれば、そうした問題が起こるだけで、ほかには何のメリットもないのです。さらに、もしあなたのユーザーが、無防備にも駐車場でアンケートに答え、飴玉と引き換えに自分のパスワードを渡してしまったら、パスワードを期限切れにするというポリシーには、何の意味もなくなってしまいます。

そうしたポリシーをベースラインから除外する方が、別の日数や、期限切れそのものの廃止を推奨するよりも、組織ごとのニーズに合わせてベストな方法を選択できるはずです。しかもガイダンスに違反することもありません。それと同時に、私たちはまた別の保護方法を強く推奨することを、改めて明らかにしなければなりません。それはベースラインとして表現できる類のものではありませんが。

言い換えれば、Microsoftは、定期的にパスワードを変更することよりも、強力で長くユニークなパスワードの使用を重視することにしたのだ。

数週間、または数カ月ごとにパスワードを変更することは、日常的にWindowsを使っているユーザーをイラつかせるだけではない。利益よりもむしろ害をもたらすことになるという指摘もある。元FTC(米国連邦取引委員会)のチーフテクノロジスト、Lorrie Cranor氏は2016年のブログ記事で、ユーザーに頻繁にパスワードの変更を強制すると、パスワードが弱いものになってしまう可能性があると書いている。

「研究者は、すでにユーザーのパスワードを手に入れた攻撃者は、パスワードの変更によってひるむことは考えにくいと指摘しています」と、彼女は述べている。「いったんパスワードを知った攻撃者は、ユーザーが変更した後のパスワードも容易に推測できることが多いのです」。

その後間もなく、連邦政府にサイバーセキュリティの実践およびポリシーについて助言する立場にあるNIST(米国標準技術局)は、それまでの助言を改訂し、定期的なパスワード変更を義務付けるポリシーを削除した。

すでに退官したNISTの元マネージャ、Bill Burr氏は、パスワードを期限切れにすることを推奨するポリシーを2003年に策定した張本人だが、2017年のインタビューでは、そのことを悔やんでいる。そのルールは、「実際にはユーザビリティに悪影響を及ぼしました」というのだ。

画像クレジット:Getty Images

原文へ

(翻訳:Fumihiko Shibata)

ホットスポット検索アプリが200万件以上のWi-Fiパスワードを流出させた

人気のAndroid用ホットスポット検索アプリが200万箇所以上のWi-Fiネットワークのパスワードを流出させた。

何千人ものユーザーがダウンロードしたそのアプリを使うと、近くのWi-Fiネットワークを見つけることができる。ユーザーがWi-Fiパスワードを端末からアップロードすると、他のユーザーがそれを利用できる。

しかし、200万以上のWi-Fiパスワードが保存されたそのデータベースが保護されずに露出され、誰でも中身をアクセスして一括ダウンロードできる状態になっていた。

セキュリティー研究者でGDI FoundationのメンバーであるSanyam Jai氏がこのデータベースを発見し、TechCrunchに報告した。

本誌は2週間以上をかけて中国に拠点があると思われるデベロッパーに接触を試みたが成功していない。最終的にホスト運営者のDigitalOceanに連絡をとったところ、同社はその日のうちにデータベースを閉鎖した。

「我々はユーザーに告知し、データベースがさらされていたサーバーをオフラインにした」と広報担当者が本誌に伝えた。

各レコードには、Wi-Fiネットワークの名前、正確な位置情報、基本サービス識別子(BSSID)およびネットワークパスワードが平文テキスト形式で保存されていた

アプリの開発者は、公開ホットスポットのパスワードのみを提供していると称していたが、調べたところ大量の家庭用Wi-Fiネットワークのデータが見つかった。流出したデータにネットワーク所有者の連絡先情報は含まれていないが、位置情報を地図に照らし合わせたところ、完全な居住エリアや企業の存在しない地域が見つかった。

同アプリは、ユーザーがネットワークオーナーの了解を得ることを要求しておらず、Wi-Fiネットワークの不正アクセスを可能にしていた。ネットワークにアクセスすることで、攻撃者がルーター設定を変更してDNSサーバーを改変し、無防備なユーザーを悪意のあるウェブサイトに誘導する可能性がある。攻撃者は、ネットワークを流れる暗号化されていなデータを読み取り、パスワードや秘密を盗み出すこともできる。

流出した数万件はのWi-Fiパスワードは、米国拠点のネットワークのものだった。

[原文へ]

(翻訳:Nob Takahashi / facebook

英国の「最悪のパスワード」は想像以上だった

人名、サッカー選手、ミュージシャン、架空の人物。これらがパスワードの年間ワーストランキングの上位を占めた。英国の政府機関である国家サイバーセキュリティーセンター(NCSC)による。

しかし、ひどいパスワードの中でも「123456」を超えるものはない。

ベテランのセキュリティー専門家にとっては驚きではない。この6桁の数字は、その利用範囲の広さから過去何年にもわたり最悪パスワードの名をほしいままにしている。このあとに続くのが、なんと、なんと「123456789」だ。

NCSCは、3000万人の「カモ」がこの2つのパスワードだけを使っていると言った。これはセキュリティー研究者Troy Hunt氏が運営するウェブサイトであるPwned Passwordsのデータに基づく最新の盗難分析による。Hunt氏はHave I Been Pwnedという盗難通知サイトも運営している。

「サイバーセキュリティーは難しそうだと感じる人が多いことは理解しているが、NCSCは人々が被害を大きく減らすのに役立つ身近なアドバイスをたくさん提供している」とNCSCの技術ディレクターであるDr. Ian Levyは言った。「パスワードの使いまわしは、避けることのできる最大のリスクだ。自分の名前や地元のフットボールチーム名やお気に入りのバンド名のような想像できるもので、大切なデータを保護すべきではない」。

弱いパスワードは問題だ。侵入を企てるロボットが簡単に予測できるだけでなく、企業のデータ漏洩で盗まれたときにも侵入されやすい。「モノのインターネット」のデフォルトパスワードがそのまま使われることも多く、スマートデバイスを狙う邪悪な目的のロボットの乗っ取られる恐れがある。

私たちになにができるのか?

TechCrunchは、無料のサイバーセキュリティーガイドをいくつか公開しているので、適切な行動に役立ててほしい。パスワードマネージャーを使うことは大きな一歩だ。パスワードマネージャーは、パスワードを生成して安全に保管するので、人間はいちいち覚える必要がない。もう一つが二要素認証で、パスワードにもう一段階の障壁を加えることで、最強のハッカーであってもあなたのアカウントへに侵入することは難しい。

安全のためにかかる時間は長くない。ある日の1時間を割くことがスタートだ

[原文へ]

(翻訳:Nob Takahashi / facebook

Facebookが数億人のパスワードを平文で保存していたと認める

Facebookでまたセキュリティー上の問題が見つかった。

コンピューターセキュリティを専門とする調査報道ジャーナリストのBrian Krebsは自身のサイトで「長年にわたってFacebookは数億アカウントのパスワードを平文で保存している」とするレポートを発表した。 Facebookは米国時間3月21日、公式ブログで事実だと認めた

FacebookのPedro Canahuati氏によれば、問題が発見されたのはは1月に行われた定例のセキュリティチェックの際で、パスワードを見ることができるのはFacebook社内の担当者だけだという。しかしKrebsは「Facebookでは2000人のエンジニア、デベロッパーがパスワードを含むログにアクセス可能だ」と指摘している。しかもFacebookがこの失態を認めたのは事実が判明してから何カ月もたち、外部のジャーナリストであるKrebs氏に指摘されてからだった。

Krebs氏によれば、バグは2012年にさかのぼるという。FacebookのCanahuati氏はブログでこう述べている。

我々のログインではユーザー以外がパスワードを見ることができないようにマスクするシステムを採用しており、これ(をチェックする際に平文で保存していること)がわれわれの注意を引いた。パスワードは社外からアクセスすることはできないし、社内でも悪用されたり、不適切なアクセスを受けたという証拠はまったく発見されていない。

しかしどのようにしてこの結論に達したのかは説明されていない。Facebookは数億人のユーザーにこの問題を通知するという。またInstagramのユーザーにも通知がいくはずだ。これには途上国など接続スピードが遅く、通信量が高価な地域向けの軽量版であるFacebook Lightのユーザーも含まれる。

Krebs氏は「6億人のユーザーが影響を受ける可能性がある」としている。これは同社の27億人のユーザーの約5分の1だが、この数字はまだFacebookによって確認されていない。

またどのようにしてこのバグがシステムに入り込んだのかもまだ説明されていない。パスワードを誰でも読める平文のまま保存するというのはもちろん適切な方法ではない。Facebookのような大企業はパスワードを保存する際にソルトを付加してハッシュ化するのが普通だ。どちらのテクニックも攻撃を著しく困難にする。この方法を用いればシステム側もパスワードの内容を知る必要がない。

昨年、TwitterGitHubでも似たような(ただしそれぞれ異なる)バグが発見された。両社ともパスワードにスクランブルをかけず平文のまま保存していた。

いずれにせこのバグはFacebookを襲っている一連のセキュリティ問題の最新の例だ。Facebookがユーザーの許可を得ずにサードパーティーに個人情報にアクセスすることを許す契約を結んでいた問題は刑事事件として捜査されることが報じられた。 最近の一連のセキュリティ問題は議会への証人喚問政府の諸機関による調査をもたらしている。

Facebookが事実を確認するのに長時間かかった理由、またデータ漏洩が発生した場合、米国、ヨーロッパにおいてはそれぞれ法で定められた通知義務が発生するがその通知を行ったのかどうか、Facebookにコメントを求めた。今のところ冒頭で紹介したブログ記事以上の回答は得られていない。

なおFacebookのヨーロッパにおける運営を管轄するアイルランド政府のデータ保護局は「Facebookからこの問題に関する通知を受けた。さらに詳しい情報を求めている」としている。

画像:Getty Images

原文へ

(翻訳:滑川海彦@Facebook

長いパスワードはパスワードの悪用や同一パスワードの再利用を大幅に減らす

インディアナ大学の研究者たちが、パスワードに関する厳しい規則は…相当面倒なものを除いては…実際に効果があることを実証した。その研究を行った院生のJacob Abbott, 同大のCIO Daniel Calarco, そしてL. Jean Camp教授らは、彼らの研究成果を“Factors Influencing Password Reuse: A Case Study.”(パスワード再利用の影響要素に関する事例研究)と題するペーパーで発表した。

Abbottはこう述べている: “われわれのペーパーは、文字数15文字以上などの厳しい要件により、インディアナ大学のユーザーの圧倒的多数(99.98%)が、パスワードをほかのサイトで再利用しなくなることを示している。制限文字数が短い他の大学では40%もの高率でパスワードが再利用されている”。

パスワードの再利用に対する規則の影響力を知るために、インディアナ大学を含むアメリカの22の大学のパスワードに関する規則を調べた。そして、オンラインで公開されている二つの大きなデータセットから、メールとパスワードの組み合わせを取り出した。それらのデータセットには、メールアドレスとパスワードの組み合わせが13億件ある。それらのメールアドレスとパスワードの組み合わせを大学のドメインごとに分類し、各大学の公式のパスワード規則と比較した。

結果は明白であった: 厳しいパスワード規則によって、その大学の個人データ漏洩リスクは大幅に低減していた。

要約すると、長いパスワードを求める厳しいパスワード規則により、パスワードの詐欺的利用や本人のパスワード再利用が99%、すなわちほぼ完全に防止できている。また同研究によると、パスワードの中で自分の名前やユーザー名を使わない、という規則も、セキュリティに貢献している。結局のところ、厳しいパスワード規則がある方が、なにもないよりも、はるかにましである。当たり前のことのようだが、覚えておくべき、そして必ず思い出すべき、重要なポイントだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

カリフォルニア州でデバイスのデフォルトパスワードを禁ずる法律が成立

良いニュースだ!

California州が2020年から、すべての新しい消費者電子製品に、“admin”, “123456”, あるいは古くからお馴染みの“password”といった、デフォルトのパスワードを設けることを禁ずる法律を成立させた。

その法律によると、ルーターやスマートホーム製品など、同州で生産されるすべての新しいガジェットは、最初から“リーズナブル”なセキュリティ機能を持っていなければならない。とくにパスワードについては、各デバイスが、あらかじめプログラミングされたユニークな(他機と共通でない)パスワードを持っていなければならない。

また、新しいデバイスはどれも、ユーザーがデバイス固有のユニークなパスワードを入力してそれを最初に使用するとき、新しいユーザー固有のパスワードの設定を求め、その設定を終えたあとにのみ、最初のアクセスを認めるものでなければならない。

何年も前から、ボットネットたちが、セキュリティのいい加減なデバイスを利用して、大量のインターネットトラフィックでサイトを襲撃してきた。その大量のトラフィックによる攻撃は、分散型サービス妨害攻撃(distributed denial-of-service, DDoS)と呼ばれている。ボットネットが目をつける‘いい加減なセキュリティ’の典型が、デバイスに最初から設定されている、そしてユーザーがそれを変えることもない、デフォルトパスワードだ。上に例を挙げたような、よく使われるデフォルトパスワードは、そのリストがどこかに公開されているので、マルウェアはそれらを利用してデバイスに侵入し、そのデバイスをハイジャックする。そして、ユーザーの知らないうちにそのデバイスは、サイバー攻撃の道具にされてしまう。

2年前には、Miraiと呼ばれる悪名高きボットネットが、何千台ものデバイスを悪用してDynを攻撃した。Dynは、多くの大型サイトに、ドメインネームサービス(DNS)を提供している。DDoSでDynが麻痺してしまうと、これに依存しているサービスに誰もアクセスできなくなる。被害サイトの中には、TwitterやSpotify, SoundCloudなどもいた。

Miraiは、比較的単純素朴な、しかし強力なボットネットで、デフォルトパスワードを悪用していた。今度の法律でデフォルトパスワードというものがなくなれば、このタイプのボットネットは防げるが、でもセキュリティの問題はほかにもたくさんある。

もっと高度なボットネットは、パスワードには見向きもせず、個々のIoT(物のインターネット)デバイスの脆弱性につけこむ。その典型的なデバイスは、スマート電球、アラーム、家庭用電子製品などだ。

IT評論誌The Registerの指摘によると、今回のカリフォルニア州法は、バグが見つかったときのソフトウェアのアップデートを、デバイスのメーカーに義務付けていない。大手のデバイスメーカー、Amazon、Apple、Googleなどはソフトウェアを常時アップデートしているが、無名に近いブランドの多くはやっていない。

しかし、そんな現状でも、この法律は、何もないよりましである。今後もっともっと、改定していただきたい。

[下の引用記事(未訳)の関連記事]

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Facebook曰く:アタッカーが連携アプリにアクセスした「形跡はない」

Facebookは、先週発見したデータ流出によってサードパーティーアプリが影響を受けた「形跡はなかった」と発表した。

ハッカーらは、昨年Facebookが不注意から混入させた3つの脆弱性の組み合わせを利用して、少なくとも5000万ユーザーのアクセストークンを盗み出した。その他4000万ユーザーもアタックを受けた可能性がある。Facebookはこれらのトークン(ユーザーのログイン状態を保つために使用される)を無効化し、ユーザーは強制的に同サイトに再ログインさせられた。

しかし、ログインにFacebookを利用しているサードパーティー製のアプリやサイト、サービス(Spotify、Tinder、Instagramなど)も同じく影響を受けた可能性があり、Facebookログインを使用するサービス各社は、ソーシャルネットワークの巨人に回答を求めていた。

「当社は、先週発見したアタック期間中にインストーあるいはログインされた全サードパーティーアプリのログを解析した」とFacebookのプロダクトマネジメント担当VP、Guy Rosenが ブログ記事に書いた。「調査の結果、アタッカーがFacebookログインを使っていずれかのアプリにアクセスした形跡は現時点で見つかっていない」。

「当社が提供している公式Facebook SDKを使用しているデベロッパーすべて——およびユーザーのアクセストークンの有効性を定期的にチェックしているデベロッパー——は、われわれがユーザーのアクセストークンをリセットした際に自動的に保護されている。

Rosenは、全デベロッパーがFacebookの開発ツールを使っているわけではないことを認識しており、そのために「各デベロッパーが自社アプリのユーザーが影響を受けたかどうかを識別し、ログアウトさせるためのツールを開発している」と語った。

Facebookはツールの提供時期については言及しなかった。TechCrunchは同社にコメントを求めており、回答があり次第続報の予定。

今回の不正侵入がヨーロッパで500万ユーザーに影響をあたえたことをFacebookは認めた。当地域のプライバシー保護法は、より厳格で制裁金も高額だ。

新たに制定された一般データ保護規則(GDPR)の下では、仮にFacebookがユーザーデータを保護する努力を怠っていたことがわかれば、欧州の規制機関はFacebookに最大16.3億ドル(前会計年度の全世界売上である407億ドルの4%)の罰金を科すことができる。

画像提供:Getty Images

[原文へ]

(翻訳:Nob Takahashi / facebook

iOS 12のセキュリティー設定、トップ5――バージョンアップを機に今すぐ確認しておこう

AppleはiPhone and iPad向けOSの最新版、iOS 12を一般公開した。新しいパッケージではセキュリティーとプライバシーが大幅に強化されている。

新しい機能を利用してAppleのモバイル・デバイスをさらに安全にする設定をご紹介しよう。

1. USB制限モードを有効にしてハッキングを困難にする

この機能は見つけにくいかもしれないが重要だ。ロックされた状態で1時間以上たつとUSBであれヘッドフォンであれ、あらゆる外部機器の接続をブロックする。これは警察、ハッカーがロックをバイパスしてデータにアクセスすることを不可能にする。

設定 > Touch IDとパスコードを開き、パスコードを入力する。下にスクロールしてUSB アクセサリ のオプションがオフになっていることを確認する。iPhone Xの場合はFace IDの設定をチェックする。

2. iOSのアップデートは自動モードに

iPhoneやiPadのアップデートにはそのつど多数の新しいセキュリティー機能や脆弱性に対するパッチが含まれている。ハッキングやデータ流出の危険性を大きく低下させることができるのでぜひ適用しておくべきだ。残念ながらOSのアップデートを長く怠っているユーザーが多い。大きなバージョンアップでないかぎり、アップデートしていないなどということはないだろうか? iOS 12からはアップデートがバックグラウンドで行われるようになり、作業の邪魔をしなくなった。自動アップデートはオンにしておこう。

設定 > 一般 > ソフトウェアアップデート を開いて自動アップデートを有効にする。

3. デバイスのパスコードを強いものにする

iOS 12のパスコード機能は大きく強化された。従来、デフォールトでは4桁の数字だったが新しいOSでは6桁になった。2桁の数字の追加はブルートフォース(総当たり)法でパスコードを破ろうとすることを100倍困難にする。

ただしパスコードの数字の桁数は自由に増やせる。8桁でもいいし、もっと長くてもいい。ロック画面にキーパッドが大きく表示されるので入力は簡単だ。

設定 > Touch IDとパスコード を開き、現在のパスコードを入力する。続いてパスワードを変更オプションから新しい数字コードを選択する。

4. この機会に2ファクタ認証を有効にしよう

2要素認証(2ファクタ認証)は現在一般に利用できる中で最強のセキュリティー対策の一つだ。ハッカーがどうにかしてユーザーのパスワードを手に入れたとしても、同時に携帯電話も盗まなければアカウントにアクセスすることができない。しかし長年、2要素認証は手間がかかることで嫌われていた。iOS 12ではパスコードが自動的に補完される新機能が追加された。パスコードコードはiCloud.comへのログインにも用いられる。iOS 12でパスコードを取得すると他のデバイスに送信が可能になり、要素認証の手順は大幅に簡単になった。ぜひ有効にしておこう。

アップデートを完了する際の設定で2要素認証を有効にすることができる。あるいは設定 を開き、左サイドバー上部の自分の名前をタップしパスワードとセキュリティー オプションを開く。ここで2ファクタ認証をオンにし、信頼できる電話番号を入力する。

5. この機会に使い回しのパスワードを変更しておこう

iOS 12のパスワード・マネージャーにはパスワードの安全性を検査する機能が追加された。ユーザーが異なるサービスに同じパスワードを使い回していることを発見すると変更するように警告する。これによりあるサイトから得たパスワードでユーザーがパスワードを使いまわしている他のアカウントをすべてハックするcredential stuffingと呼ばれる攻撃を防ぐことができる。

設定 > パスワードとアカウント > WebサイトとAppのパスワード を開き、パスコードを入力する。ここでパスワードを保管しているサイトの一覧が表示される。パスワードを使いまわしているとそれぞのアカウントに警告シンボルが表示されるので、サイト名をタップしてWebサイトのパスワードを変更に進む。

〔日本版〕iOS 12へのアップデートは日本でもすでに公開されている。接続状態にもよるが再起動も含めて20分以上かかる可能性がある。なお訳者のiPadではアップデート後も新しいパスコード入力画面は4桁で表示された。ここでパスコードプションを開くとメニューがポップアップし、6桁の数字コードなどを選ぶことができる。USB制限モードの設定はUSBアクセサリのオプションを無効(グレーアウト)にしたときセキュリティーが高い状態となる。

原文へ

滑川海彦@Facebook Google+

iOS 12のオートフィルはサードパーティーのパスワード・マネージャーもサポート

AppleはiOS 12のパスワード・オートフィルでサードパーティーのパスワード・マネージャー・アプリをサポートすることがわかった。つまりAppleのモバイル・デバイスからパスワードが必要なサイトやサービスにアクセスする際、iCloudキーチェーンにパスワードが保存されていなくても簡単にログインできる。

これはマイナーなアップデートのように見えるかもしれないが、実は重要な意味がある。

現在、多くのユーザーが何十、ことによると何百ものパスワードが必要なアカウントを持っており、パスワード・マネージャー・アプリを使ってアクセスを管理している。

パスワード・マネージャーはログイン情報を安全に保管し、必要に応じてすぐに呼び出せるようにする。パスワードを使用するのがセキュリティー上必要であっても多数のパスワードを覚えているのは非常に困難だ。パスワード・マネージャーはパスワードを記憶するだけでなく、サービスにセキュリティー上の問題が起きた際に警告を発してくれる。たとえば家系調査のMyHeritageのアカウント情報が9200万件もリークしたような場合だ。また同じパスワードの使い回しや弱すぎるパスワードなどの問題も警告してくれる。

多くのユーザーがパスワード管理ソフトを利用しているものの、これまではAppleのモバイル・デバイスから使うのはかなり面倒だった。

まずパスワード・マネージャーのiOSアプリを起動し、所望のサービスを指定してパスワードを呼び出してコピーし、ログインしたいアプリに戻ってパスワード欄にペーストするという手順になる(1Passwordの場合は自動パスワード生成機能があり、何回かタップするだけでiOSのシェアシート機能を使ってコピー&ペーストをせずにアプリをログインできる)。

そういう方法があってもやはり手間を食う。 QuickTypeバーでいくつかキーをタップし後はオートフィルに任せるのに比べるとはるかに面倒だ。

今回Appleが発表した情報によれば、ユーザーはいちいちパスワード・マネージャーを立ち上げてパスワードを呼び出す必要がなく、パスワード・オートフィルl機能を用いてパスワード・マネージャーに記憶させたパスワードを入力することができる。これは単に快適で速いだけでなく、パスワード・マネージャー・アプリの普及にも大きな力となりそうだ。

1PasswordはWWDCでこのニュースを聞いたときに興奮して上のような歓迎のツイートをした。また新しいAPIを利用してApple IDのパスワードをオートフィルする動画を添付した。

上の1Passwordのデモでもわかるとおり、新APIを利用すれば、QuickTypeバーをタップするだけで1Passwordに保存されているログイン情報を入力できる。ログイン情報はバーでダッシュの後に示される。パスワード・マネージャーとiCloudキーチェーンに2種類のログイン情報が保存されている場合、QuickTypeバーに両方が表示されるのでユーザーが適切な方を選択できる。

この機能は昨年パスワード・オートフィルが発表されて以来 1Passwordが強く要望していたものだ。

AgileBitsでMacとiOS向け1Passwordの開発責任者を務めるMichael Feyは「iOS 11でAppleはSafariでブラウズした場合、iCloudキーチェーンにパスワードを保存できるようにした。このパスワードはアプリに関連づけることができ、呼び出して入力できるようになった。そこでわれわれはすぐにAppleに接触し、この機能を1Passwordでも使えるようにしてほしいと要望した」という。さらにAgileBitsではバグ・レポートを提出し、1Passwordに統合するプロトタイプを作った

その結果、「今年のWWDCでわれわれの要望が実現した」わけだ(Appleに対する要望は1Password、Dashlane、LastPassの共同によるもので、3社は同時に同様の要望書提出していたという)。

1Password始め、他のパスワード・マネージャーの開発チームも、この秋AppleがiOS 12を一般向けにリリースするときには、それぞれのプロダクトにオートフィルの能力を付加しているはずだ。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

iOS 12のオートフィルはサードパーティーのパスワード・マネージャーもサポート

AppleはiOS 12のパスワード・オートフィルでサードパーティーのパスワード・マネージャー・アプリをサポートすることがわかった。つまりAppleのモバイル・デバイスからパスワードが必要なサイトやサービスにアクセスする際、iCloudキーチェーンにパスワードが保存されていなくても簡単にログインできる。

これはマイナーなアップデートのように見えるかもしれないが、実は重要な意味がある。

現在、多くのユーザーが何十、ことによると何百ものパスワードが必要なアカウントを持っており、パスワード・マネージャー・アプリを使ってアクセスを管理している。

パスワード・マネージャーはログイン情報を安全に保管し、必要に応じてすぐに呼び出せるようにする。パスワードを使用するのがセキュリティー上必要であっても多数のパスワードを覚えているのは非常に困難だ。パスワード・マネージャーはパスワードを記憶するだけでなく、サービスにセキュリティー上の問題が起きた際に警告を発してくれる。たとえば家系調査のMyHeritageのアカウント情報が9200万件もリークしたような場合だ。また同じパスワードの使い回しや弱すぎるパスワードなどの問題も警告してくれる。

多くのユーザーがパスワード管理ソフトを利用しているものの、これまではAppleのモバイル・デバイスから使うのはかなり面倒だった。

まずパスワード・マネージャーのiOSアプリを起動し、所望のサービスを指定してパスワードを呼び出してコピーし、ログインしたいアプリに戻ってパスワード欄にペーストするという手順になる(1Passwordの場合は自動パスワード生成機能があり、何回かタップするだけでiOSのシェアシート機能を使ってコピー&ペーストをせずにアプリをログインできる)。

そういう方法があってもやはり手間を食う。 QuickTypeバーでいくつかキーをタップし後はオートフィルに任せるのに比べるとはるかに面倒だ。

今回Appleが発表した情報によれば、ユーザーはいちいちパスワード・マネージャーを立ち上げてパスワードを呼び出す必要がなく、パスワード・オートフィルl機能を用いてパスワード・マネージャーに記憶させたパスワードを入力することができる。これは単に快適で速いだけでなく、パスワード・マネージャー・アプリの普及にも大きな力となりそうだ。

1PasswordはWWDCでこのニュースを聞いたときに興奮して上のような歓迎のツイートをした。また新しいAPIを利用してApple IDのパスワードをオートフィルする動画を添付した。

上の1Passwordのデモでもわかるとおり、新APIを利用すれば、QuickTypeバーをタップするだけで1Passwordに保存されているログイン情報を入力できる。ログイン情報はバーでダッシュの後に示される。パスワード・マネージャーとiCloudキーチェーンに2種類のログイン情報が保存されている場合、QuickTypeバーに両方が表示されるのでユーザーが適切な方を選択できる。

この機能は昨年パスワード・オートフィルが発表されて以来 1Passwordが強く要望していたものだ。

AgileBitsでMacとiOS向け1Passwordの開発責任者を務めるMichael Feyは「iOS 11でAppleはSafariでブラウズした場合、iCloudキーチェーンにパスワードを保存できるようにした。このパスワードはアプリに関連づけることができ、呼び出して入力できるようになった。そこでわれわれはすぐにAppleに接触し、この機能を1Passwordでも使えるようにしてほしいと要望した」という。さらにAgileBitsではバグ・レポートを提出し、1Passwordに統合するプロトタイプを作った

その結果、「今年のWWDCでわれわれの要望が実現した」わけだ(Appleに対する要望は1Password、Dashlane、LastPassの共同によるもので、3社は同時に同様の要望書提出していたという)。

1Password始め、他のパスワード・マネージャーの開発チームも、この秋AppleがiOS 12を一般向けにリリースするときには、それぞれのプロダクトにオートフィルの能力を付加しているはずだ。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

VRとARは何処へ向かう?

「2016年はVR(仮想現実)の年だという多くの宣言を目にしたものだが、それ以降仮想現実に対するまともな言葉は聞かされていない」と、The Economist誌が酷評したのは昨夏のことである。なにしろ2016年はVR関連のハードウェアとソフトウェアの合計販売額の予想が、51億ドルから36億ドルに減少し、実際には18億ドルという厳しいものになったのだ。いや、まあホリディシーズンが一度不調だったからと言って、そんなに悲観しなくても。2017年になればきっと ――

{0}{1/}{/0}おっとこんな記事が:“Shock Stat: In 2017, VR Headset Shipments For Most Top Brands Went DOWN Compared To 2016.” (衝撃の数字:2017年には多くのトップブランドのヘッドセット出荷が2016年に比べて減少した)。VRヘッドセットの出荷数は急速に増加するだろうと、多くの予想がずっと出されていたのに。最近では業界の動向と共に、煽り記事も出されるようになっている。でもそれは…Oculus Goが発表される前の話じゃないかって?まあ…Goが一番売れたのは、最初の数週間で25万台を売ったときのようだが、それでも同じ月の初めに出た同価格帯のNintendo Switchに比べれば、その数はわずかなものだったし、私がこれを書いている時点では、Amazonの“Video Games > Accessories”ベストセラーリストのトップ20からも遠ざかってしまっている。

とはいえ、これらはひどい数字ではない。ソニーのプレイステーションVRは、約300万台も売れたのだ!…つまり、これはPlayStationの所有者のほぼ4%に相当していることになる。しかし、VRとARは、次のささやかなニッチ(Next Little Niche)ではなく、次の目玉(Next Big Thing)になる筈だったのではなかっただろうか?そしてそれは、直線的にではなく、指数関数的に普及すると考えられていたのではなかっただろうか?

もちろんARは、AppleのARKit、GoogleのARCore、FacebookのAR Studioなどのおかげで誰の手にも届くようになっている。だがあなたは (a) Pokémon GOではなく、(b)家具も関係しないような、有名で成功したARスマートフォンアプリの名前をすぐに挙げることができるだろうか!?

もし私が誰かに向けて非難の指を向けているとするならば、それは自分自身に向けているものだ。私は現時点で、VR/ARがもっと進んでいることを期待しすぎていた。私たちはVRでしかプレイすることのできないヒットゲームに出会ったと思ったし、23ヶ月前にリリースされたPokémon GOが、全く新しいAR世界の先触れだと考えた。やがてそれらがお互いに関係を始め重なり始めるだろうと思ったのだ。長期的には、そう思っておけば良いのかもしれない。だが、短期的には ――

私は今週サンタクララで開催されたAugmented World Expoに参加したのだが、そこで私が理解したことは、業界が実質的に消費者向けAR/VR分野からは(少なくとも今は)手を引いたということだ。誰もが現在AR/VRを仕事の場所に持ち込もうとしている。しかし、複雑な情報をハンズフリーのやり方でアクセスする必要がある仕事が、いったいどれ位あるというのだろうか?VR会議で解決できて、ビデオ会議では解決できない問題はいくつあるのだろう?確かに、それは既に存在しており、その技術は本当に素晴らしいかもしれない。しかし、少なくとも今は、それは「次のささやかなニッチ」の話なのだ。

私は本当に目の覚めるようなものを見た。そのことで、私はつつましいQRコードが複合現実(MR)の極致を実現することができることを確信できるようになったのだ:

とはいえこれはとても素晴らしい工夫だ:「混合現実バックパック」は要するに着用可能なQRコードである。予測:これまで厳しい批判の対象だった(機械に対して以外は目立たないように隠されていた)QRコードが、現実世界とARを結ぶ架け橋の事実上の標準となるだろう。

…しかし、2つの世界の架け橋が用意されても、もし誰もがどちらか片方の世界にしか関心を持たないとしたら、その架け橋はどんな役割を果たすことができるだろう。

「でもゲームがある!」と叫ぶかもしれない。「没入型のストーリーテリングがある!」と。まあ確かに。私もそれについても非常に期待しているのだ…結局のところ私は空き時間はずっと小説家として過ごしているのだから。そしてそれは、現在業界内の明るい話題だ 「ロケーションベースVR」すなわち「VRアーケード」(VR体験機器が設置された遊戯施設)の数は増えていて、それは最近のPunchdrunkSleep No Moreや、Meow WolfHouse of Eternal Return、そしてThe Latitudeといった没入型の劇場の増加と歩調を合わせているように思える。

…しかし、私がこれまでに見たVR/MR没入型ストーリーテリングは皆、格好いいのは最長でも15分程で、誇大宣伝とバズワードがまとわりつき、そして基本的に荒削りなストーリー以上のものを伝えることはできていない。「ストーリーテリングではなくて、ストーリーリビング(物語の中を生きる)なんですよ」と、数ヶ月前に行ったイベントで、熱心なIndustrial Light&Magicの担当者が語ってくれた。もちろんそれはよい言い方だ ―― しかし私がこれまでに見たVRによる「ストーリーリビング」は皆、私が10代の頃に見たDungeons & Dragonsの宣伝よりも遥かに洗練されていないものばかりだった。

もちろん、現在新しいテクノロジーの黎明期にいることは承知している。それはまだ高価で、まだハードウェア集約型である。今でも私たちは、最高の使い方と、人間の物理的な場所とのやりとり、そしてストーリーテリングのための全く新しい文法を探している最中なのだ。しかし、OculusがKickstarterで立ち上げられたのはおよそ6年前であり、私はそれ以来とても多くのVR/AR/MRのデモを見てきた。そしてそのたびに、「このテクノロジーにはとても大きな可能性が秘められている」と帰り道に思うのだ。

しかし、次の目玉(Next Big Thing)になるためには、どこかの時点でその「可能性」を現実のものにし始めなければならないのだ。おそらくMagic Leapがそれをやってくれるだろう(いや冗談を言っているのではない。少なくとも半分は)。しかし、もしそうでなければ、がっかりするような真実は、いくら安価な新しいスタンドアロンハードウェアが手に入ろうと、そしてすべての努力がソフトウェアとデザインとストーリーテリングに注がれようと、私は2年前にいた場所から少しもその実現に近付いていると思えないだろうということだ。誰か私が間違っていると言って欲しい。

[原文へ]
(翻訳:sako)

OktaのPassProtectはあなたのパスワードがどこにもリークしてないか調べてくれる

セキュリティ企業のOktaが今日、Chromeブラウザー用の無料のエクステンションをローンチした。そのエクステンションPassProtectをインストールすると、ユーザーがタイプするパスワードを、被害に遭ったパスワードのデータベース、Troy HuntのHave I Been Pwnedで調べる。

このエクステンションは、本誌TechCrunchの読者のようなテクノロジーに詳しい人向けではないかもしれない。でも、コンピューターのことを何も知らないお隣(となり)さんには、有益だろう。彼らのGmailのパスワードは、すでに盗まれているかもしれない。

Have I Been Pwnedは、これまでリークしたパスワードを集めている大きなデータベースだ。過去には大規模なセキュリティ破り事件が、Dropboxでもあったし、LinkedInやTumblr、Adobeのサービスでもあった。だから過去にあなたのパスワードも、やられているかもしれない。

だからみんな、パスワードマネージャーを使うべきだし、個々のオンラインサービスごとに違うパスワードを使い、そしてできるかぎり二要素認証を利用すべきだ。今多くの企業がOktaに依頼して、会社のイントラネットの認証を安全にしようとしているのも、そのためだ。

でも、大多数のユーザーは何もしていない。

だから今度親戚の家を訪ねたときは、このエクステンションをインストールして、パスワードのセキュリティチェックができるようにしてあげよう。このエクステンションはk-Anonimityというものを利用して、ユーザーのパスワードを安全にHuntのデータベースで調べる。ユーザーのパスワードがOktaやHave I Been Pwnedに共有されることはない。このエクステンションはしかも、オープンソースだ

〔訳注: 本誌TechCrunch Japanは、この記事で紹介されているエクステンションの絶対安全性を保証できません。試用は、自己責任でお願いいたします。〕

関連記事

[原文へ]
(翻訳:iwatani(a.k.a. hiwa