パスキーの基本とそれにまつわる誤解を解きほぐす
2023 年は文句なく「パスキー元年」になりました。非常にたくさんのサービスがパスキーに対応し、2024 年はいよいよパスキー普及の年になりそうです。 本記事では、パスキーの基本を振り返ったうえで、パスキーでみなさんが勘違いしやすい点について解説します。 2023 年は本当にたくさんのウェブサイトがパスキーに対応しました。例を挙げます: Adobe Amazon Apple eBay GitHub Google KDDI Mercari Mixi MoneyForward Nintendo NTT Docomo PayPal Shopify Toyota Uber Yahoo! JAPAN もちろんこのリストですべてではないですが、これらだけでも、世界人口のかなりをカバーできるはずで、まさに大躍進と言えます。もしまだパスキーを体験していないという方がいたら、ぜひこの機会にお試しください。
SharedArrayBuffer と過渡期な cross-origin isolation の話
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 の脅威とウェブサイトが設定すべきヘッダーについて
長い記事なので先に結論を書きます。 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 なページとのコミュニ
パスワードの不要な世界はいかにして実現されるのか - FIDO2 と WebAuthn の基本を知る
不正送金やアカウントの乗っ取りなど、パスワードが原因の事件が後を絶ちません。高齢者など、IT リテラシの低い人でも簡単かつ安全に自分のオンラインアカウントを管理できる世界が理想ですが、まずはパスワードの不要な世界を実現するのが先決であることは、これまでのインターネットの歴史で証明されたと言えるでしょう。そして、ここに来てパスワード不要なログインを実現する技術として注目されているのが FIDO (= Fast IDentity Online, 「ファイド」) です。そしてその FIDO をブラウザから利用できるようにするのが WebAuthn (= Web Authentication、「ウェブオースン」)。報道内容などからこれらは指紋認証を実現するもの、と思っている人もいらっしゃるかもしれませんが、実際にはちょっと違います。 WebAuthn に関しては、すでに数多くの記事が出ていますので
Custom Elements - Web Components を構成する技術
この記事は webcomponents.org の記事とのクロスポストです。 HTML は言うまでもなく、ウェブページを構成する最も重要な要素です。しかし、提供される機能が低レベルなため、複雑なコンポーネントを作ろうとすると、途端に div だらけの分かりにくい構造になってしまいがちです。例えば、あなたが必要な機能を盛り込んだ独自のコンポーネントを作れるとしたらどうでしょう？例えばそのコンポーネントに、機能を的確に表すタグ名を付けられるとしたら？既存のタグを拡張して、新しい機能を追加できるとしたら？ Custom Elements は、それを可能にします。 Custom Elements とはなにか？ # Custom Elements は開発者が独自に HTML タグを定義し、サイト上で利用できるようにすることで、繰り返し利用されるコンポーネントを単純化し、再利用する手間を大幅に削減しま
なぜ Web Components はウェブ開発に革命を起こすのか
ウェブアプリケーションのフロントエンドに関わる方なら、もう Web Components という 言葉を全く聴いたことがない方は少ないのではないでしょか。 すでに関連記事も数多く出回っており、実際に触り始めている方も多いと思います。しか し、なぜこれが革命的技術なのか、周囲の人に簡潔に説明できる方はどれくらいいるで しょうか？この記事では、それを試みていきたいと思います。 デジタル部品の流通革命 # ソフトウェア部品の流通に今、大きな変化が起きてきています。 数年前のオープンソース環境を覚えているでしょうか？レポジトリは集中管理型の subversion、リリースは zip、テストは手動。Issue の登録もプロジェクトごとにことな るバグ管理システムが使われていたため、とっつきづらかったでしょうし、パッチを送る のも面倒でした。 そんなオープンソースを取り巻く環境が、git や GitH
Google の Developer Advocate とはどんな仕事なのか？
僕の仕事は Google の Chrome Developer Advocate です。 Google Japan では先週 (2013 年 4 月) からこの Chrome の Developer Advocate を募集開始しました。他にも Google+、YouTube、Android など同種の担当者も募集しているのですが、よく聞かれるし、リクエストもありましたので、この機会に Developer Advocate がどんな仕事をしているのか、ご説明したいと思います。 Developer Relations とは # 上記一連のお仕事ですが、すべて Google 内の Developer Relations チーム (以下 DevRel) という部署に属します。おそらく Google の中でも、開発者の皆さんが一番接触する機会の多いチームではないかと思います。DevRel はさらに
HTML5Rocksが日本語に対応 (2013/12更新)
Posted: May 2, 2012 / Last updated: December 19, 2013 ※ この記事は 2012 年 5 月 2 日に公開されたものを一部アップデートしたものです。 HTML5Rocks というサイトをご存知ですか？HTML5Rocks は、世界でも有数の HTML5 関連情報が集まったサイトで、チュートリアルやサンプル、スライド、動画などで構成されています。このサイトは Google の Chrome Developer Relations チームが中心になって作っているのですが、英語のみだったサイトが、2012 年 5 月に i18n ( internationalization = 国際化 ) を果たし 9 ヶ国語に対応、日本語のコンテンツも追加し始めました。 まだまだ量は多くありませんが、これまで英語を読むことに抵抗のあったディベロッパーの皆さん
WebSocket のバイナリメッセージを試したら、ウェブの未来が垣間見えた
長い記事なので、先に結論だけ書いておきます。WebSocketのバイナリメッセージ機能は、これまでのインターネットのあり方をひっくり返します。「そんなの知ってるよ」という方もいるとは思います。僕も理屈では分かってたつもりだけど、実際にアプリを作ってみて、具体的にそれを感じることができたので、ちょっと長いですがどういうことなのか説明してみます。 WebSocketとは # WebSocketは、HTML5関連の中でも特に注目を集めている技術の一つです。通常のHTTP通信であればクライアントからのリクエストなしにサーバーは応答しませんが、WebSocketを使うことでクライアントとサーバーの間で双方向の通信が可能となります。これを利用することで、今後様々なリアルタイム性の高いサービスを構築することが可能になるでしょう。 そんなWebSocketですが、これまで波乱の道を歩んできました。数年前か
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
