• Google に入社して 10 年が経った

    Developer Advocate という技術啓蒙の担当者として Google に入社して今日でちょうど 10 年が経った。技術以外のことについてはめったにブログを書くことはないのだけど、良い節目なのでこの機会に記録を残しておきたい。 Google 入社のきっかけ 「インターネットにアイデンティティのレイヤーを作り、インターネット全体をオープンなソーシャルネットワークの基盤にしたい」これが僕が前職で持っていた野望だった。その一歩として、その会社で運営していたポータルサイト全体をソーシャルプラットフォーム化するというアイディアが採用され進める中で、OpenSocial という Google が中心として進めていた技術に取り組んでいた。日本語の情報が少ない分野だったためブログを書いたり、コミュニティ運営や技術講演をしていたら、当時 (今もだけど) 仲良くしてもらっていた田中洋一郎さんに Google API Expert (現 Google Developer Expert) に推薦してもらった。その数年後に、Google の担当者から社員にならないかと誘われた。 入社当初は Chrome DevRel (Chrome Developer Relations) というチームで、Chrome を中心としたウェブ技術の啓蒙を仕事にスタートした。今はチームの方針で「Chrome」ではなく「ウェブ」のアドボケートになってはいるが、組織改変などの紆余曲折も経つつ、10 年間、ほぼ同じチームで同じような仕事を続けている。 最近のお仕事 以前 Developer Advocate がどんな仕事をしてるかの記事を書いた。当時は日本のウェブに貢献する仕事が多かったが、今はグローバルかつ技術的な仕事に比重を置いている。日本にはかなり大きい Chrome のエンジニアリングチームがあるが、たまたま自分の取り組んでいるプロジェクトに関わるエンジニアが誰も日本におらず、基本的には北米かヨーロッパの人と仕事している (最近久しぶりに東京のエンジニアと仕事する機会に恵まれたが、安心感が全然違う)。ちなみに上司が日本にいたことも実は一度もない。 せっかくの機会なので最近で自分がどんな仕事をしているのかまとめておく。 ウェブ標準化のお手伝い HTML5 以降、ブラウザがカバーする技術分野はオーディオ系、グラフィック系、ハードウェア系、通信系など、専門分野に分けないと追いつかないくらい裾野が広がってきた。その中でも認証系と支払い系の技術を担当している。 大分ブランクは空いたが、認証系技術は自分のこれまでの知識が大いに生かされる分野であり、元々興味があるので相性はいい。キーワードで言うと Credential Management API、FIDO /...


  • パスワードの不要な世界はいかにして実現されるのか - FIDO2 と WebAuthn の基本を知る

    不正送金やアカウントの乗っ取りなど、パスワードが原因の事件が後を絶ちません。高齢者など、IT リテラシの低い人でも簡単かつ安全に自分のオンラインアカウントを管理できる世界が理想ですが、まずはパスワードの不要な世界を実現するのが先決であることは、これまでのインターネットの歴史で証明されたと言えるでしょう。そして、ここに来てパスワード不要なログインを実現する技術として注目されているのが FIDO (= Fast IDentity Online, 「ファイド」) です。そしてその FIDO をブラウザから利用できるようにするのが WebAuthn (= Web Authentication、「ウェブオースン」)。報道内容などからこれらは指紋認証を実現するもの、と思っている人もいらっしゃるかもしれませんが、実際にはちょっと違います。 WebAuthn に関しては、すでに数多くの記事が出ていますので、テクニカルな利用方法についてはそれらに譲るとして、この記事では大局的な部分、この技術によって未来のアイデンティティがどう変わっていくかなど、大きなビジョンについて解説します。 認証の基礎 FIDO のコンセプトを理解する上で、認証の基礎を押さえないわけにはいきません。 認証の 3 要素 オンライン、オフラインに限らず、本人性を確認をするために検証すべきものとして大きく 3 つの要素があると言われています。 知識: パスワードや秘密の質問など、本人しか知らないこと。 所有: セキュリティキーなど、本人しか持っていない特定のデバイスなど。 生体: ユーザー自身の指紋や虹彩、静脈や顔など。 例えば銀行のATMでは、カードそのものを持っていること(所有)、そして PIN を知っていること(知識)、という 2 つの要素で本人確認します。セキュティチップの載ったクレジットカードでも同様に、サインする代わりにカードをターミナルに挿入し、正しい PIN を入力することで、所有と知識を満たす二要素認証を行っていると言えます。 ただ、これらはオフラインのケースであり、パソコンやスマートフォンを通じたインターネット上でのオンラインの認証においては、これまで事情が異なりました。すべてがオンラインのシステムでは、何かを持っていることを証明することは困難ですし、生体を読み取るためのインフラも整っていませんでした。そのため、これまで長い間、パスワードを代表とした知識認証のみが使われてきました。 しかし、プログラムを使って機械的に無数のログインが試みられたり、罠を仕掛けて匿名で情報を盗み出されたり、推測されてしまったり、パスワードはオンラインであるがゆえに、常にリスクと向き合わざるを得ない存在でした。ユーザー側もサービス側も、正しい扱い方を知らずに安全に扱うことが難しいものであり続けたと言えます。 OTP とその弱点 そこで最近人気になっているのが、パスワードに OTP (ワンタイムパスワード) を組み合わせた認証方法です。パスワードに続けて、SMS で送信された番号や、アプリやデバイスに表示された番号を入力します。いずれも本人以外に同じ番号が表示されることはないため、安全性が増します。 しかし OTP...


  • 結局 PWA は来るの?来ないの?

    昨日 Twitter でこんな記事を発見しました。 PWAが来るって言っているエンジニアは今すぐ辞めろ 「instagramのPWAが最高〜!ネイティブと見分けつかない!!とかほざいているグー○ルのエバンジェリストだかエンジニアが騒いでいたので触ってみたのだが、オワコンであった。」 もしかしてこれのことかな? Instagram PWA is sooooooo impressive. I probably won't be able to distinguish it with its native app.InstagramのPWAが、デキが良すぎて感動してる。ネイティブアプリと見分けられる自信ない。 pic.twitter.com/DS8TfceBZ6— Eiji Kitamura / えーじ (@agektmr) 2018年1月26日 確かに、この言い方は若干煽り気味のところがあったかもしれません。しかし、Instagram の PWA について、スクロールの快適さ、投稿時にフィルターがかけられる点など、「ネイティブと見分けられる自信がない」のは、初めて使った時の僕の率直な感想ですし、今でも快適に使っています。 ただ、このツイートをした時点ですべての機能を試したわけではなかったし、後から気付いた違いもありました。勘違いしないでもらいたいのは、もちろん、だからネイティブアプリは不要だなんて言うつもりはないということです。むしろせっかくなので、この機会にもう少し PWA について説明しましょう。 PWA とは何か この記事を読むくらいであればすでにご存知の方は多いと思いますが、PWA は Progressive Web Apps の略で、日本語ではプログレッシブウェブアプリと表記します。PWA については、3 年前から話しているので、基本的な理解からスタートしたい方は、ぜひこちらをお読みください。ちょっと長いですが、概要を把握する分には最初の方だけで十分だと思います。 プログレッシブウェブアプリ詳解 - 過去・現在・未来...


  • Payment Request API のよくある誤解を解く

    このポストは Chromium Browser Advent Calendar 2017 の 12/8 分です。先日 Medium に投稿した英語版を翻訳し、日本向けに若干加筆したものになります。 Payment Request API が登場してからというもの、おかげさまで非常に多くの方に興味を持っていただいています。一方、その複雑さから勘違いや、誤った情報を元に盛り上がってしまっているような状況が起きています。この記事では、みなさんの反応を見ている中でよくある誤解を解き、正確な情報を提供しようと思います。 そもそも Payment Request API が何かご存じないという方は、まずここから読んでいただくと良いと思います。 Web Payment API? Chrome Payment API? Google Payment API? すべて間違いです。正しくは “Payment Request API” です。そしてこれは Google や Chrome のものではなく、オープンスタンダードの仕様として作られており、Chrome 以外のブラウザでもサポートされます。2017 年 11 月現在サポートしているブラウザは: Android 版 Chrome iOS 版 Chrome デスクトップ版 Chrome...


  • Web Payments はなぜ避けて通れないものになるのか - ウェブでの新しいお金の払い方

    前回の記事で解説したように、Payment Request API によってウェブでの支払いにおけるユーザーエクスペリエンスは大きく変わる可能性があります。しかし、これが本当にメインストリームになるのか、将来的に自分のサイトを対応させる必要性は出てくるのか?そんな疑問を持つ方は少なくないと思います。 僕はかなり高い確率で、今後ウェブ上でのほとんどの支払いが Web Payments を経由したものに変わっていくと予想しています。この記事では、その理由を説明していきます。 クレジットカードのセキュリティ問題 あなたはクレジットカードを紛失して再発行した経験はありますか? クレジットカードは紛失や盗難で番号が漏れて他人に知られてしまった可能性がある場合、カード番号を変更しなければなりません。番号が変わるということは、設定してある自動引落などが全てやり直しになってしまいます。その手続きの大変さを考えただけでも、クレジットカードを紛失するのは、金銭的な損失に加えて、それに対する処置という意味でも、大きな損失を伴います。 そもそもクレジットカードの仕組みというものは脆弱です。実店舗などの対面での支払いであれば、物理的カードの提示に加え、署名やPIN番号の入力、監視カメラがあるなどの理由から、ある程度の安全性は担保されてきました。しかしオンラインの支払いが中心となってきた現在はどうでしょう? 多くのオンラインサービスでは、カード番号と持ち主の名前、有効期限が正しければ決済可能です。これは相手が誰であろうと、それらの情報が正しければ決済できてしまうということを意味しています。そしてそれらの情報は、カードが手に入れば一発でわかりますし、カード番号を預けているサービスがクラックされ、情報が盗まれるだけでも悪用することができてしまいます。そして実際にそういったケースはあとを絶ちません。 もちろん、カード会社も手をこまねいて見ているわけではありません。クレジットカードのセキュリティ対策としていくつかの方法があります。 まず、カード情報を受け取る側に課される制約として、PCI DSS と呼ばれるクレジットカード情報を守るためのセキュリティ基準が用意されています。米国では PCI DSS 対応は EC ビジネスを行う上で実質的に必須になっています。 日本でも「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」として、2018 年 3 月までにオンラインでの支払いに PCI DSS を導入する要件を含む取り組みが進められています。 CVC 番号の利用もかなり広まってきました。CVC 番号はカードの裏に書いてある 3 桁程度の数字で、これをマーチャントでカード番号と合わせて入力することで、本人確認が行われます。もちろんマーチャントの脆弱性で漏洩されては意味がありませんので、データベースに保存しない前提になっています。とはいえカードに明記されているものですし、ブラウザなどのクライアントからネットワークを介して渡される以上、どこかに脆弱性が存在する可能性はありますし、絶対的に安全なものとは言い切れません。 他には、3D セキュアと呼ばれる決済時にクレジットカード会社のサイトで認証を行う方式もあります。ただ、お金の支払いの度に id とパスワードによる認証が求められるため、ここでユーザーが脱落してしまうことは容易に想像できます。マーチャントがシステムを実装する手間も考えれば、喜んで導入される類のものではありませんし、あまり普及率は高くないようです。3D セキュアの新バージョンではリスクベース認証を取り入れることで、最小限の認証で済ませることになるようですが、実装の手間が減るわけではありません。 いずれにしろ重要なのは、クレジットカードの情報が漏洩する可能性をできるだけ減らすことです。 そこで PCI DSS は、2015 年に発表されたバージョン 3.2 において、明確に生のクレジットカード情報をブラウザ上で扱うことに関して、従来よりも強い制約を設けました。日本の 「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」においても同様です。 今後オンラインマーチャントは、クレジットカード情報を全く扱わない「クレジットカード情報の非保持化」を進めるか、もしくは PCI...