サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
CES 2025
blog.agektmr.com
「パスキーのすべて」という本を書きました。1 月 28 日に発売する本書の内容について軽く紹介します。 パスキーのすべて 「パスキーのすべて」は米国 OpenID Foundation 理事、OpenID ファウンデーション・ジャパン KYC WG リーダの小岩井さんと、OpenID ファウンデーション・ジャパン 理事・エバンジェリストのくらと一緒に書きました。小岩井さんとは昨年開催したパスキーハッカソンでもご協力頂きましたし、同じイベントで登壇する機会も多く、最近 FIDO 関連に限らず色々とお世話になっています。くらとはもう 10 年以上、ID 界隈のコミュニティで仲良くしてもらっています。二人共気の置けない愉快な仲間たちです。大まかに分担はしましたが、全員が全体に責任を持つという体制で執筆を行い、終盤は何度かみんなで技術評論社の会議室に篭って執筆・レビューするなど、作業そのものを楽し
最近、パスキーが使いづらい、という声を目にします。作ったはずのパスキーが見つからないために、使いたいサービスにログインできず困った、という人の投稿も何度か観測しました。 そこでこのブログ記事では、どうしてそういうことが起こってしまうのか、どうすればそういう状況を回避できるのか、ユーザーが取れる対策にはどういうものがあるのか、サービス側はどうすればそのように感じるユーザーを減らせるのか、について考えていきたいと思います。 もちろん大前提として、ユーザーが頭を捻らないと使えないような機能は、普及どころか迷惑をかけてしまうため、望ましくありません。ただパスキーは、各社のプロダクトとしては成熟しつつあるものの、トータルのエコシステムとしてはまだ発展途上な部分が残っており、使いづらい部分があることも否定できません。そこで、よりパスキーが使いやすい世界になるまでの間、工夫する方法を知ってもらうことで、
2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。 本記事では、パスキーの基本を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。 2023 年は本当にたくさんのウェブサイトがパスキーに対応しました。例を挙げます: Adobe Amazon Apple eBay GitHub Google KDDI Mercari Mixi MoneyForward Nintendo NTT Docomo PayPal Shopify Toyota Uber Yahoo! JAPAN もちろんこのリストですべてではないですが、これらだけでも、世界人口のかなりをカバーできるはずで、まさに大躍進と言えます。もしまだパスキーを体験していないという方がいたら、ぜひこの機会にお試しください。
パスキーはフィッシングに強く、テクノロジーに詳しくないユーザーでも使いやすい新しい認証方式で、いずれパスワードを置き換えると言われています。この記事では、パスキーの基本と、これからのウェブにとってパスキーがどういう意味を持つのかについてまとめてみます。 パスキーとは何か # 2022 年 12 月 9 日に Google が Android 版 Chrome でパスキーがサポートされたとのアナウンスが出ました。Apple もすでに最新版の macOS Ventura、iOS / iPadOS 16 で Safari がパスキーに対応しています。 パスキーは Apple、Google、Microsoft が協調して使う FIDO クレデンシャルの名前です。エンドユーザーのみなさんがパスワードの代わりとして認識し、直感的にログインできるよう「パスキー」というブランドとアイコンが決まりました。ウ
2021/12/26: Safari も 15.2 から COOP/COEP を使って SharedArrayBuffer が利用できるようになったので、該当箇所の表記を変更しました。 長い記事なので先に結論を書きます。 Chrome、Firefox および Safari で SharedArrayBuffer や高精細タイマーが使えるようになりました。そのためには cross-origin isolation という状態を有効にするのですが、親となる HTML ドキュメントに下記 2 つのヘッダーを送ります。 Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin ただ、これを有効にするには様々な条件と制約が存在し、現段階では多くのサイトは苦戦するでしょう。とりあえず従来通り C
長い記事なので先に結論を書きます。 Spectre の登場で、ウェブサイトに必要とされるセキュリティ要件は増えました。具体的に必要な対策は下記の通りです。 すべてのリソースは Cross-Origin-Resource-Policy ヘッダーを使って cross-origin なドキュメントへの読み込みを制御する。 HTML ドキュメントには X-Frame-Options ヘッダーもしくは Content-Security-Policy (CSP) ヘッダーの frame-ancestors ディレクティブを追加して、cross-origin なページへの iframe による埋め込みを制御する。 HTML ドキュメントには Cross-Origin-Opener-Policy ヘッダーを追加して popup ウィンドウとして開かれた場合の cross-origin なページとのコミュニ
Developer Advocate という技術啓蒙の担当者として Google に入社して今日でちょうど 10 年が経った。技術以外のことについてはめったにブログを書くことはないのだけど、良い節目なのでこの機会に記録を残しておきたい。 Google 入社のきっかけ # 「インターネットにアイデンティティのレイヤーを作り、インターネット全体をオープンなソーシャルネットワークの基盤にしたい」これが僕が前職で持っていた野望だった。その一歩として、その会社で運営していたポータルサイト全体をソーシャルプラットフォーム化するというアイディアが採用され進める中で、OpenSocial という Google が中心として進めていた技術に取り組んでいた。日本語の情報が少ない分野だったためブログを書いたり、コミュニティ運営や技術講演をしていたら、当時 (今もだけど) 仲良くしてもらっていた田中洋一郎さんに
不正送金やアカウントの乗っ取りなど、パスワードが原因の事件が後を絶ちません。高齢者など、IT リテラシの低い人でも簡単かつ安全に自分のオンラインアカウントを管理できる世界が理想ですが、まずはパスワードの不要な世界を実現するのが先決であることは、これまでのインターネットの歴史で証明されたと言えるでしょう。そして、ここに来てパスワード不要なログインを実現する技術として注目されているのが FIDO (= Fast IDentity Online, 「ファイド」) です。そしてその FIDO をブラウザから利用できるようにするのが WebAuthn (= Web Authentication、「ウェブオースン」)。報道内容などからこれらは指紋認証を実現するもの、と思っている人もいらっしゃるかもしれませんが、実際にはちょっと違います。 WebAuthn に関しては、すでに数多くの記事が出ていますので
昨日 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日 確かに、この言い方は若干煽り気味のと
このポストは Chromium Browser Advent Calendar 2017 の 12/8 分です。先日 Medium に投稿した英語版を翻訳し、日本向けに若干加筆したものになります。 Payment Request API が登場してからというもの、おかげさまで非常に多くの方に興味を持っていただいています。一方、その複雑さから勘違いや、誤った情報を元に盛り上がってしまっているような状況が起きています。この記事では、みなさんの反応を見ている中でよくある誤解を解き、正確な情報を提供しようと思います。 そもそも Payment Request API が何かご存じないという方は、まずここから読んでいただくと良いと思います。 Web Payment API? Chrome Payment API? Google Payment API? # すべて間違いです。正しくは "Paymen
前回の記事で解説したように、Payment Request API によってウェブでの支払いにおけるユーザーエクスペリエンスは大きく変わる可能性があります。しかし、これが本当にメインストリームになるのか、将来的に自分のサイトを対応させる必要性は出てくるのか？そんな疑問を持つ方は少なくないと思います。 僕はかなり高い確率で、今後ウェブ上でのほとんどの支払いが Web Payments を経由したものに変わっていくと予想しています。この記事では、その理由を説明していきます。 クレジットカードのセキュリティ問題 # あなたはクレジットカードを紛失して再発行した経験はありますか？ クレジットカードは紛失や盗難で番号が漏れて他人に知られてしまった可能性がある場合、カード番号を変更しなければなりません。番号が変わるということは、設定してある自動引落などが全てやり直しになってしまいます。その手続きの大変
前回の記事では、フォームを最適化することでウェブの決済フローを改善するアイディアについて書きましたが、今回は新しい標準 API を使ったアプローチについて書きます。 見た目にも違いが分かりやすいものですので、まずはこちらをご覧ください。 デモはこちらからお試し頂けます (実際に商品を購入することはできません。また、クレジットカードなどの情報がサーバーに渡されることはありません)。 これまで使われていたフォームの代わりに、支払い専用のユーザーインターフェースが使われていることにお気付きと思います。実はこの UI はウェブサイトが用意したものではなく、ブラウザが提供するもので、サイト管理者はこれを呼び出すことにより、従来のフォームよりも手軽に、正確な支払情報をユーザーから提供してもらうことが可能になります。今回ご紹介するのはこれを実現する Payment Request API についてです。
インターネットが登場して 20 年以上が経過し、時代はデスクトップからモバイルへと移り変わりました。モバイルでは、単に小さな画面に対応しているだけでなく、よりスピード感のある体験が求められています。それは E コマースビジネスも例外ではありません。 モバイルでの決済において、66% がネイティブアプリではなくウェブ上で行われているというデータがあります。検索結果からアプリをインストールしてまで商品を購入するのは手間がかかりすぎるため、そのままウェブ上で決済しようとする人が多いことが原因と考えられます。 ただ逆にモバイルウェブサイトは、デスクトップのウェブサイトと比較として、コンバージョンレートが 66% 低いというデータも存在します。これは逆に言えば、モバイルウェブでのコンバージョンレートにはまだ伸びしろがある、ということも意味しています。 そこで今回は、フォームを改善することでモバイルウ
3 月 13 日、Chrome Beta のブログポストが出ました。Android 版 Chrome でプッシュ通知が使えるようになったのが個人的なハイライトです。 「確かにプッシュ通知は便利かもね〜」と思ったあなた、驚きが足りません。のけぞるべきです。小躍りするべきです。 理由を説明します。 ユーザーエンゲージメントが変わる # あなたのウェブサイトのビジネスモデルが広告モデルにしろ課金モデルにしろ、ユーザーが繰り返し訪れてくれることは大前提です。通常のウェブサイトやサービスは、そのための策を練ります。そのきっかけをサービス側から能動的に与えることで、ユーザーが戻ってきて、ビジネスは回ります。しかし、そのきっかけを与える方法は、非常に限定されていると言わざるを得ません。 インターネットが普及し始めた当初から伝統的に利用されているのがメール、数年前から利用されているのがソーシャルメディア、
この記事は webcomponents.org の記事とのクロスポストです。 Template や Shadow DOM、Custom Elements を使うことで、機能ごとの UI コンポーネントが実現できるようになることはこれまでに説明してきました。しかし、それらを使ったコンポーネントの HTML、CSS、JavaScript を別々に呼び出すのは、非効率です。 依存関係の解決も容易ではありません。jQuery UI や Bootstrap を思い出して下さい。JavaScript、CSS、Web Font といった各種リソースを、必要に応じて別々のタグに記述しなければなりませんでした。特にタグごとにコンポーネントとして扱うことが想定されている Web Components の場合、状況が複雑化することは簡単に想像できます。 これらのリソースを、ひとつの HTML ファイルにまとめて
この記事は webcomponents.org の記事とのクロスポストです。 HTML は言うまでもなく、ウェブページを構成する最も重要な要素です。しかし、提供される機能が低レベルなため、複雑なコンポーネントを作ろうとすると、途端に div だらけの分かりにくい構造になってしまいがちです。例えば、あなたが必要な機能を盛り込んだ独自のコンポーネントを作れるとしたらどうでしょう？例えばそのコンポーネントに、機能を的確に表すタグ名を付けられるとしたら？既存のタグを拡張して、新しい機能を追加できるとしたら？ Custom Elements は、それを可能にします。 Custom Elements とはなにか？ # Custom Elements は開発者が独自に HTML タグを定義し、サイト上で利用できるようにすることで、繰り返し利用されるコンポーネントを単純化し、再利用する手間を大幅に削減しま
この記事は webcomponents.org の記 事とのクロスポス トです。 Shadow DOM を利用すると、DOM 要素に、ウェブページの他の部分とは切り離された、 ノード内だけで有効なスタイルやマークアップを含んだ DOM ツリーを追加することがで きます。この記事と動画では、この Shadow DOM について解説します。 Shadow DOM とはなにか？ # こちらは HTML5 の video タグで表示された動画です。ご覧頂けるとお分かりのように、 コードは video タグのみという単純さでありながら、動画そのものだけでなく、制御用 の UI も表示することができています。 <video src="http://craftymind.com/factory/html5video/BigBuckBunny_640x360.mp4" controls></video>
Posted: October 14, 2014 / Last updated: October 16, 2014 この記事は webcomponents.org の記事とのクロスポストです。 先日 Web Components を構成する技術のひとつである Templates に関するビデオを公開 しましたので、解説したいと思います。 なぜ今 Templates なのか # 我々開発者にとってテンプレートを使うメリットは、デザイナーとの分業を容易にでき る、という点にあります。 ウェブサイトを構築する際に利用されるテンプレートというと、以前は PHP や Python の Django, Ruby on Rails をはじめとするサーバー側での実装が主流でした。それがこ こ数年、ブラウザ側で処理するテンプレート技術が登場し、人気となってきています。 これは HTML5 などオープンウェブ
このイベントは元々、ウェブプラットフォーム上で「音楽」と呼べるレベルのことができ るようになることを目標にしていたので、良い刺激をもらいました。現段階では「音」レ ベルの原始的なところに留まっていると言わざるをえませんが、さらにプラットフォーム を積み上げて、より音楽的なことができるようにしていくのが醍醐味とも言えます。 ハッキング # 会場には参加者 40 名超に加え、W3C、ヤマハ、ローランド、コルグ、クリムゾンテクノロ ジーの各楽器メーカー、JSPA (日本シンセサイザープログラマー協 会) 、AMEI (音楽電子事業協 会) 関連の方など、多数ご来場頂きました。ウェブ業界より も楽器業界からの注目度の高さの方が目立つくらいです。 今回も各楽器メーカーから楽器を貸し出して頂いたのですが、自前の楽器を持参された方 がかなり多かったのが印象的です。その他ハッキング中の熱気は写真でご覧頂き
OpenSocial 周りの調査をしていると、Caja という言葉に遭遇します。セキュアな JavaScript を実現するもの、ということだけ分かっていたのですが、詳細を調べてみました。 クロスサイトスクリプティングとブログパーツ # goo や livedoor、fc2 などのホスティングを含めたブログサービスを使ったことのある方はご存知と思いますが、サービスによってブログパーツが貼れるもの、貼れないもの、一部だけ許可しているものがあります。なぜでしょうか？ Cookie には同一ドメインから実行されたスクリプトしか参照できないという特徴があります。これを利用して、Cookie をセッション情報や閲覧履歴の保存場所として活用しているサービスは少なくありません。上記ブログサービスがブログパーツを許可しないのは、これらの情報を悪意のある JavaScript から守るためです。逆に言うと、
ウェブアプリケーションのフロントエンドに関わる方なら、もう Web Components という 言葉を全く聴いたことがない方は少ないのではないでしょか。 すでに関連記事も数多く出回っており、実際に触り始めている方も多いと思います。しか し、なぜこれが革命的技術なのか、周囲の人に簡潔に説明できる方はどれくらいいるで しょうか？この記事では、それを試みていきたいと思います。 デジタル部品の流通革命 # ソフトウェア部品の流通に今、大きな変化が起きてきています。 数年前のオープンソース環境を覚えているでしょうか？レポジトリは集中管理型の subversion、リリースは zip、テストは手動。Issue の登録もプロジェクトごとにことな るバグ管理システムが使われていたため、とっつきづらかったでしょうし、パッチを送る のも面倒でした。 そんなオープンソースを取り巻く環境が、git や GitH
Test を書く練習ついでにバージョンアップしたのでご紹介。クリップボードにコピーしたリッチテキストを Markdown としてペーストできる Chrome Extension: MarkdownPastr の新バージョンを公開しました。 開発者の方ならご存知とは思いますが、Markdown は最近人気のある Wiki 的記法です。GitHub での採用で、爆発的に人気が出ました。プレインテキストとして見てもそれなりに把握しやすいということも、普及の理由のひとつと思われます。最近では Jekyll などを使ってブログを Markdown で書く人も出てきました。 そんな Markdown ですが、個人的に Google Docs で書いたテーブルを含む文章を Markdown 化したいケースが結構あり、そんな時に不便な思いをしていました。そこで作ったのが MarkdownPastr です。
Posted: February 12, 2014 / Last updated: February 12, 2014 検索してもあまり日本語の情報が出てこなかったのでメモを残しておきます。 JSDoc # JSDoc は言うまでもないですが、JavaScript のソースコードに残したコメントから自動的にリファレンスドキュメントを生成してくれるコマンドラインツール。例えばこんな感じでソースにコメントを書いておくと /** * Resolve url from `srcset` syntax http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/ * @param {string} src Default URL * @param {string} srcset `srcset` argument * @param {number|undef
Posted: January 19, 2014 / Last updated: January 19, 2014 2014 年 1 月 18 日（土）、Web Music Developers JP と Google の共催で Web Music ハッカソン #2 を開催しました。 近年のウェブ技術の発展の中で生まれたブラウザ上で利用できる各種 API: Web Audio API:オーディオをシンセサイズできる API Web MIDI API: MIDI を扱うことができる API WebRTC: P2P でオーディオ、ビデオ、データをやりとりできる API Web Speech API: 音声認識できる API などを使って、丸一日で何か作り上げよう、という趣旨です。 前回は初回にも関わらず、素晴らしい作品がたくさん生まれました。その時の様子はこちらのブログポストからご覧頂くことが
去る 2013 年 10 月 19 日、Web Music ハッカソンというイベントを Google Japan オ フィスで開催しました。これは @ryoyakawai こと ヤマハの河合さん (ややこしい) を中心とした Web Music Developers JP という開発者コミュニティ主催のイベントで、 初の試みです。 ブラウザは近年目覚ましい発展を遂げています。HTML5 というバズワードが非常に分かり やすくはありますが、現在は Chrome、Safari、Firefox といったブラウザで、オーディ オを波形レベルから弄れる Web Audio API が利用可能になっています。 こちらは藍圭介さん (@aike1000) が作られたデモですが、各ツマミは実際 に動かすことができ、本格的なアナログシンセサイザーとして音を鳴らすことができま す。公開されてから 2 年以上経
canvas の DOM エレメント (コンテキストではない) から toBlob() を使う、というのが一番簡潔な回答です。が、これは Firefox には実装されているので すが、残念ながら Chrome にはまだ実装されていませ ん。そこで下記の方法 を使って png や jpeg など、任意の画像形式で Blob を作ることができます。 /*** canvas に絵を書くコード ***/ var type = 'image/jpeg'; // canvas から DataURL で画像を出力 var dataurl = canvas.toDataURL(type); // DataURL のデータ部分を抜き出し、Base64からバイナリに変換 var bin = atob(dataurl.split(',')[1]); // 空の Uint8Array ビューを作る var buf
Posted: August 2, 2013 / Last updated: August 2, 2013 知っている人は知っている方法だと思いますが、実際にやってみたのでメモ。 ※ デモの画像はこちらからお借りしました。特にライセンスが記述されていなかったのですが、問題があれば差し替えます。 ライブラリは jsgif というのを使わせて頂きました。 手順はライブラリを読み込み、画像をひとコマ分ずつ canvas にロード、ライブラリに追加。終わったらバイナリから gif ファイルを生成、という感じ。 もう少し詳しい解説は以下。 LZWEncoder.js NeuQuant.js GIFEncoder.js を読み込む 適切なサイズの canvas を用意 GIFEncoder からエンコーダを作るvar encoder = new GIFEncoder(); アニメーションの時間間隔など
昨年夏に公開した Project Tab Manager という Chrome Extension のバージョン 2.0 を リリースしました。2.0 での変更点は下記の通り： 新しい UI。より直感的で使いやすくなりました。 タブの状態を追跡するようになりました。プロジェクトとして保存さえしていれば、気 軽にウィンドウを閉じて構いません。いつでも閉じた時の状態に復元可能です。 Chrome 再起動時にウィンドウとプロジェクトが自動的に関連付けられるようになりま した。以前はマニュアルで関連付けなければなりませんでした。 キーボードナビゲーションが可能になりました。 オプションがクラウドに保存されるようになりました。自宅や会社で共通の設定が利用 できます (要 Chrome サインイン)。 サマリー機能が拡張されました。自分がどのプロジェクトにどれくらい時間を費やした のか、2 ヶ月まで遡
僕の仕事は Google の Chrome Developer Advocate です。 Google Japan では先週 (2013 年 4 月) からこの Chrome の Developer Advocate を募集開始しました。他にも Google+、YouTube、Android など同種の担当者も募集しているのですが、よく聞かれるし、リクエストもありましたので、この機会に Developer Advocate がどんな仕事をしているのか、ご説明したいと思います。 Developer Relations とは # 上記一連のお仕事ですが、すべて Google 内の Developer Relations チーム (以下 DevRel) という部署に属します。おそらく Google の中でも、開発者の皆さんが一番接触する機会の多いチームではないかと思います。DevRel はさらに
次のページ
このページを最初にブックマークしてみませんか？
『Tender Surrender』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
