はてなブックマーク

Intro W3c が毎年開催する国際会議、TPAc 2025 に参加してきた。 TPAc 2025 今年は何年ぶりかの日本開催であり、会場は神戸コンベンションセンターだった。 TPAc 2025: Overview https://www.w3.org/2025/11/TPAc/ 一週間の日程の中で、様々なミーティングが行われ、今後の Web のあり方が議論される。 TPAc 2025: Detailed schedule https://www.w3.org/2025/11/TPAc/schedule.html W3c は会員制なので、TPAc も会員企業所属などでないと参加できない。 今回はサイボウズ社の W3c 加入を手伝った縁で、サイボウズ社員に帯同して参加した。 印象に残る部分だけ振り返る。 月曜日 初日は、まず Webcomponents cG があった。 WccG - TP

Intro このエントリは、1Password Advent calendar の 10 日目である。 1Password - Qiita Advent calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password このシリーズでは、組織において 1Password Business を運用する上での考慮点を解説していく。 1Password Business 運用ガイド素案 - Google ドキュメント https://docs.google.com/document/d/1cZ5xdOz2IRHXRKVzcUZG-d4wQmlexBet8_Iee_EJlmw SSH の鍵を使って、直接サーバにログインするような運用は減っているかもしれない。 それでも SSH の鍵を使う場面が無くなったわけではない。 今回

Intro このエントリは、1Password Advent calendar の 9 日目である。 1Password - Qiita Advent calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password このシリーズでは、組織において 1Password Business を運用する上での考慮点を解説していく。 1Password Business 運用ガイド素案 - Google ドキュメント https://docs.google.com/document/d/1cZ5xdOz2IRHXRKVzcUZG-d4wQmlexBet8_Iee_EJlmw 入国管理でのリスク 検閲の厳しい国への入国などでは、入国管理で Pc の中を見せるように言われることがある。 このとき、1Password もアンロッ

Intro このエントリは、1Password Advent calendar の 3 日目である。 1Password - Qiita Advent calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password このシリーズでは、組織において 1Password Business を運用する上での考慮点を解説していく。 1Password Business 運用ガイド素案 - Google ドキュメント https://docs.google.com/document/d/1cZ5xdOz2IRHXRKVzcUZG-d4wQmlexBet8_Iee_EJlmw 前回は「1Password の Master Password はマルチアカウントで共通して使って良い」という解説をした。 1Password の M

Intro このエントリは、1Password Advent calendar の 1 日目である。 1Password - Qiita Advent calendar 2025 - Qiita https://qiita.com/advent-calendar/2025/1password 1Password を個人で使うだけでなく、組織全体で利用することで、開発に必要なアカウントを共有したり、cLI を使って自動化するといった、様々なメリットがある。 組織で 1Password を展開する際は、1Password を Business プランで契約し、ドメインに所属するメンバーにアカウントを発行することになるだろう。 その際、組織でどのようなルールを設け、どのような方法で管理し、どのように組織に合わせた設計を行うかは、多くの人が同じような検証を実施することになると思われる。 今回は筆者

Intro このエントリは、2023 年の 3rd Party cookie Advent calendar の 32 日目である。 3rd Party cookie のカレンダー | Advent calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 宙に浮いていた Privacy Sandbox プロジェクトの「後始末」が公開された。 Privacy Sandbox の軌跡 Privacy Sandbox の開始は、以下のエントリの公開と捉えることにする。 2019/08/22: Building a more private web https://blog.google/products/chrome/building-a-more-private-web/ そして、2025/4

Intro 前回は、Nx の事例をベースに「パッケージを公開する側」の対策について解説した。 今回は、「パッケージを使う側」、もっと言えば「OSS を使う上で開発者が考えるべきこと」について考察する。 OSS の危険性 npm 起因のサプライチェーン攻撃が確認されたことで「npm は危険だ」という話になると、「npm を禁止すべき」といった極端な話になったりする。 前回のブログで紹介したような対策を行うなら、多少は良くなるかもしれない。しかし、それらは全てパッケージ公開者に委ねられる。自分が公開者として実施するなら、自分が原因で攻撃が発生することは防げるだろう。 一方、攻撃に必要な突破口は 1 つあれば良い。npm にある全てのパッケージが対策されない限り、npm を主語とした安全が担保される日は来ない。 この広大な依存関係の中には、闇落ちした開発者が、それまでの善良なコードを、自分の意志

Intro Nx リポジトリが攻撃を受け、広範囲にわたるインシデントが発生した。 今回の事例は、GitHub Actions を中心に複数のステップが組み合わさった攻撃であり、過去に何度も発生してきた攻撃と本質的には変わらない。 しかし、途中で AI が何度か登場するため「AI が書いたコードをマージしたから」などといった表面的な反応もあるが、実態はそこまで単純な話でもない。 また、「自分のプロジェクトは Nx を使っていないから関係ない」とも言えない攻撃であるため、特にフロントエンドエンジニアは全員注意と確認が必要となる。 この攻撃が何だったのか、そこから学べることは何なのか、解説する。 Nx Incident 今回のインシデントについては、既に公式の Advisory が出ている。ニュース系の記事も多々あるが、一次情報は以下となる。 Malicious versions of Nx a

Intro 筆者のように、インターネット上での生活が長く、かつエンジニアとして生きてきた人間には、一般の人には伝わりにくいデジタルの遺品が多く存在する。 仮に自分が死んだ場合に、これらをどのように遺族に処分してもらうかは、なかなか難しい問題だ。筆者はこの「デジタル終活」をどうするかを、長いこと模索してきた。 今回は、「1Password」と法務局が行う「自筆証書遺言保管制度」を用いた方法を思いついたため、検証を試みる。 注意 筆者はエンジニアであり、法律の専門家ではない。 本方式は、法的に有効な遺言の作成については範囲外である。 本方式の目的は、「遺族の負担を減らす」ことである。 ここで「デジタル 遺品」とは以下のようなものを指す。 自分が使ってきたメールアドレスや SNS のアカウント 取得しているドメイン 登録しているサブスク 管理しているコミュニティや OSS etc. 以下のような

Intro 親の年齢に限らず、生きているうちにやってもらった方がいい、たった 1 つのこととして、エンディングノートの作成がある。 終活は、それをどのくらい準備しておくかで、本人以上に遺族の負担が格段に減るからだ。 エンディングノート エンディングノートとは、自分が死ぬ前に残しておきたい情報やメッセージ、思い出をまとめておくノートを指す。 「これを老後の備えとして書いておきましょう」という形で、病院に案内が置いてあったり、書店で販売されていたりする。 弁護士や公証人の立会いなどはないため、いわゆる「遺言」とは違い法的な効力も保証はない、もっとカジュアルなものだ。 何を書くべきかについてのルールがあるわけでもない。 遺族側の視点で見ると、大きな目的は 2 つある。 何かあった時に「こうしてほしい」という意思があるなら、書いておいてもらえればできる範囲で尊重する 何かあった後に、遺族が困りそう

Intro 先日、Passkey 啓蒙の一環で、まだパスワードマネージャを導入してない人に対する「1Password 導入セミナー」を実施した。 その内容を再収録したものを公開する。 ざっくりと、前半が一般ユーザ、後半が開発者向けの内容となっている。 動画及び資料は、啓蒙目的であれば自由に使ってもらって構わない。 なお、筆者は 1Password との利害関係は一切無い。 Slide 1Password 導入セミナー | ドクセル https://www.docswell.com/s/jxck/KE89J6-passkey-via-1password Video Links Passkey への道 #0: Intro Passkey への道 #1: 平成の Password 感 Passkey への道 #2: 2FA/TOTP Passkey への道 #3: 手入力の限界 Passkey

Intro サービスは、ユーザを守るために Passkey をサポートし、ユーザの移行を促す努力をする必要があった。 このプロセスに対して、ユーザはまったくの受動的態度でいることはできない。 では、ユーザはいったい何をリテラシとして身につけ、どう自分の身を守っていくべきなのだろうか? パスワードマネージャという基盤 ユーザに「今すぐ Passkey を理解し、導入移行すべし」と言いたいところだが、それはさすがに飛躍が過ぎるだろう。 仮に、あまねくサービスが Passkey 対応を終わらせ、あとはユーザ次第という状態であれば、その態度もあり得るかもしれないが、現実は非常に中途半端な過渡期で黎明期だ。 今すぐにでもユーザが取り組めて、この先様々なフェーズに柔軟に対応していく現実的な解は、「パスワードマネージャを導入する」ことだろう。 平成においてパスワードマネージャは、セキュリティリテラシの高

Intro パスワード + TOTP は限界を迎え、Passkey へ移行しなければ、サービスがユーザを守りきれなくなった。 逆を言えば、サービスがユーザを守りたいと思うのであれば、Passkey を提供しないわけにはいかない時代に突入している。 では、令和のこの状況において、サービスはどう対応していくべきだろうか? サービスの対応 理想だけを言うなら、Passkey をサポートし、Username-Less のログインを可能にする。その上で、パスワード+TOTP の認証はサポートを止め、保持していてもリスクでしかないパスワードのハッシュを、サーバから消す。鍵の管理とリカバリにだけに注力すれば良い。 というところまで到達できればよいが、現実的にはまだまだ過渡期どころか黎明期だ。サービスをそのように実装できればシンプルで堅牢だが、ユーザはそこまでの準備が整っているとは言えない。 サービスがパ

Intro Apple が突如発表した Passkey。 実態は「WebAuthn の秘密鍵を icloud で共有」するサービスだった。 そして、業界は本格的な Password-Less に向けて進んでいく。 Passkey と FIDO Passkey は Apple のサービスとして始まったが、単なるいちベンダのサービスでは終わらなかった。 もともと生体認証を牽引していた FIDO を中心にこの方式についての議論が行われ、最終的には業界全体が Passkey を用いて Password-Less を目指す方向で概ね合意することになる。 Apple 以外のパスワードマネージャも Passkey に対応(つまり、秘密鍵を登録しそれを共有する)ようになり、様々な場所で Passkey への移行が啓蒙されるようになった。 ちょうどコロナ禍と重なるくらいの時期だ。 ちなみに、ここまで Web

Intro TOTP/WebAuthn は、バックアップコードの適切な保管方法が示されないまま、移行だけが推し進められた。 YubiKey などの物理 Authenticator の扱いとして、「二本登録して、片方は普段使い、もう片方は貸金庫へ」などと、かなり無理のあるベストプラクティスが啓蒙されたりもしていた。 それらをスマホに移行して、登録は便利だが壊したら詰むでは、ユーザは安心して使えない。いや、正確には「よくわからないまま使って、詰んでから Apple のサポートに連絡する」という状態だったのだろう。 ここに解決策が提示されたのが、WWDc 2021 だった。 Passkey の登場 Apple による Passkey の発表は、いつも通り何の前触れもなく行われた。 Move beyond passwords - WWDc21 - Videos - Apple Developer

Intro Infostealer は、ユーザの権限でインストールされ、ユーザがアクセスできるあらゆる情報を盗んで去っていく。 そこから、どんなに暗号化して保存しても、使用時には平文にしないといけない「パスワード」という文字列を守り抜くのは非常に難しい。 であれば、最初から文字列に頼らなければ良い。それが WebAuthn と FIDO だった。 Authenticator 会社で、このようなデバイスを配られた人もいるかもしれない。 このメモリースティックのようなデバイスは、Security Key と呼ばれ、内部に取り出せない秘密鍵を保存している。 TOTP 用のデバイスと同じように秘密鍵を持っているが、乱数を表示するのではなく、この中にある秘密鍵そのもので認証を行うためのものだ。「所有」の要素であるため、社員証につけて首から下げている人もいるかもしれない。 こうしたデバイスで認証するた

Intro パスワードと TOTP の問題は、「人間が入力する必要がある」ことだった。 対策は Autofill であり、そのためにもパスワードマネージャ相当が必要になる。 では、パスワードマネージャを使っていれば、パスワードと TOTP で十分なのだろうか? パスワードマネージャ パスワードマネージャを使っているならば、以下のことが達成されているはずだ。 パスワードをサイトごとに自動生成 それを保存し、暗号化して管理 TOTP もドメインに紐づけて登録する ログイン時にそれらを Autofill しかも、最近はスマホを使っていれば Apple や Google のパスワードマネージャが最初から統合されている。 自分のアカウントに紐づけてパスワードを保存し、端末を移行しても自動で同期される。 ここまでできていれば、解説してきたほとんどの問題に対策できていそうだ。 確かに、記憶に頼ってパスワ

Intro パスワードだけでの認証に限界が訪れ、TOTP を用いた 2FA が普及した。 しかし、これでもまだ、全くもって不完全であることが、フィッシング詐欺の増加によって証明された。 フィッシング詐欺 以下のような SMS を、多くの人が受け取ったことがあるだろう。 [XXXX 証券株式会社] 緊急連絡、重要なお知らせ。https://t.co/1X2Y3Z4 内容は様々だ。かつては雑な和訳で崩れた日本語も多かったが、最近は AI 生成の精巧な文面が送られてくる。「とにかくユーザを焦らせるような SMS とは?」という大喜利の回答が、定期的に送られてくるので楽しみにしている。 といっても、重要なのはリンクの方だ。クリックすれば、普段使っているのと全く同じ見た目の偽装サイトが開かれ、ログインを促される。うっかりログインすればパスワードが盗まれ、その後本物のサイトにリダイレクトされるため、攻

Intro 「パスワード」が認証の最重要要素で、いかにそれを死守するかを「サービス側」「ユーザ側」双方で考え続けてきたのが、平成の認証だった。 ところが、それは早々に破綻し、「パスワードだけでの認証」に限界が来た。 そこで、導入されたのが二要素認証(2FA: 2-Factor Auth)だ。 2FA が必要だった理由 認証には「記憶」「所有」「生体」の 3 種類があり、そのうち 2 つを組み合わせるのが 2FA だと言われるアレだ。 この文脈で言えば、「記憶」に頼るパスワードだけで認証するのはもう限界なので、別の要素に頼る必要がある。それがパスワードと同じ「記憶」に頼るものであれば、追加する意味がないということだ。 記憶要素追加の典型例は「秘密の質問」だ。「パスワード」の後に「飼っていたペットの名前は?」を入れさせたところで、有意な認証強度の向上には繋がらない。どちらも記憶に頼っているため

Intro まず、今使われているパスワード認証について、これがなぜ問題で、なぜ Password-Less が求められているのかを振り返っていこう。 平成のパスワード感 このエントリを読むような読者であれば、平成にわたって「パスワード」というものがどう扱うべきかは、さんざん啓蒙されてきただろう。 使う側 簡単な単語などにしない 英数記号を使って複雑にする 最低 N 文字以上にする サービス間で使い回さない 雑に保管(モニターポストイットなど)しない 定期的に変更する etc etc 預かる側 簡単なパスワードを弾くようにルールを設ける 平文で保存せずハッシュにする 定期変更を強制する ハッシュは自分で実装せず、適切なライブラリを使う ログに残ったりしないようマスクする ディスクごと暗号化する 通信も暗号化する 認証のリトライに制限をかける 異常なアクティビティにはアカウントロックをかける

Intro フィッシング詐欺や Infostealer を用いた金融サイトの乗っ取り詐欺などは、その被害総額が 5000 億円 を突破してもなお拡大し続けている。米国で発生した 2024 年のオンライン詐欺被害は 166 億ドル に達した。 証券や銀行サービスからは「FIDO 認証登録のお願い」のようなメールが絶えず届き、最近では Gmail のような 20 億以上のユーザがいる大手サービス や、警視庁サイバー犯罪対策課まで「Passkey を利用しましょう」と移行を促すアナウンスをするところまできている。 まだ、多くの人が "Passkey" という名前すら知らないか、聞いたことはあるがきちんと移行まではしていないという状況だろう。新しい技術とはいえ、Passkey の普及があと 1 年早かっただけで、防げた被害は計り知れないだろうと痛感する。 一方、Passkey を知っていながら、誤

Intro cSS で custom Ident 値を動的に生成する ident() が提案されている。 策定中の仕様をベースに解説する。 Anchor Name の動的生成 Popover の Anchoring は、anchor-name と position-anchor の組で対応付けられる。 <a id=anchor>this is anchor</a> <div popover>this is popover</div> <style> #anchor { anchor-name: --anchor; } [popover] { position-anchor: --anchor; } </style> 一方、以下のように複数の Anchor に対して、紐づけを変えながら単一の Popover DOM を再利用する場合も、全ての対象に anchor-name を振り、Popov

1 月分の被害が追加されているが、これは全体としては誤差程度だ。後から 4 月の被害が多数発覚したことが大きく影響している。 テスタ氏が被害を公表し話題になったことで、被害に気づいた人もいたかもしれない。非常に有益な公表だったと感じている。 テスタ氏の場合 テスタ氏の過去の発言を振り返っても、非セキュリティエンジニアという意味での一般人としては、非常にセキュリティ意識が高く、なんなら同業者に対する啓蒙も行っていたようだ。 フィッシング対策について意識しており、偽サイトへの対策をしていた。 2 段階認証をきちんと設定し、周囲にも推奨していた。 ウイルス対策ソフトを二重に入れて、毎日スキャンを実施していた。 そんな中、どのように攻撃を受けたか。氏の動画などを元にまとめると以下のような流れのようだ。 株式市場が開く前、朝 8:30 ごろから、楽天マーケットスピード(投資ツール)にログインしていた

Intro このエントリは、2023 年の 3rd Party cookie Advent calendar の 31 日目である。 3rd Party cookie のカレンダー | Advent calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie このエントリもいよいよ終わりに近づいてきたようだ。 振り返り ここまでの chrome の動きを振り返る。 2020/01: 3rd Party cookie を 2022 年には廃止する計画を発表 https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html 2021/06: 2023 年後半に延期 https://blog.google/pro

Intro 4 月末にリリースされる chrome 136 からは、一部のケースで「閲覧履歴があってもリンクの色が変わらない」状態が発生する。 もしこの挙動に依存して閲覧をしているユーザがいれば、多少不便に感じるかもしれない。 しかし、これは長年問題視されてきた、ユーザのプライバシー保護のための更新だ。 ユーザ側でも、「サイトが壊れたのでは?」と思う人もいるだろうため、前半は技術用語を少なめに解説し、エンジニア向けの解説は後半で行う。 従来の挙動 例えば、Wikipedia では、リンクをクリックして閲覧先を確認すると、閲覧済みのリンクの色が変わる。 これは、ブラウザに保存された閲覧履歴に該当するリンクの色を、訪問済みとして変えるブラウザの機能だ。 多くのリンクがある場合、確認済みかどうかがわかるために、便利に使われることもあるだろう。 (最近では、閲覧済みでもリンクの色を変えないように実

Intro 我々は、インターネット上において「信頼」できるサービスを、「安全」に使うことに、「安心」を求める。 プライバシーは守られ、不正な取引には加担せず、詐欺被害も受けたくない。 技術的に言えば、通信は暗号化し、個人は匿名化し、データは秘匿し、それによって Secure で Safety で Trustworthy な Web が手に入る。 それを突き詰めた先に、「自由」で理想的なインターネットがある。 本当だろうか? Eve とは誰か Alice と Bob の通信の間にいる Eve は、暗号化されていない通信を覗くことができる。 スノーデンによって告発された PRISM は、「Eve が一人の攻撃者とは限らず、国家そのものであり得る」ことを明るみにした。広域盗聴による監視活動は、国民の安全を守るためという大義のもと実施された。もしかしたら、それによって未然に防がれたテロなども、あっ

Intro cSS に if() および @function が提案されている。 仕様がこれで確定したとは言い切れないため、背景および現状にフォーカスして解説する。 なお先に言っておくが、関数の再帰は初期仕様から外されているため、「cSS がプログラミング言語になった」という話ではない。 if() まず Dark/Light 2 つのモードをもつコンポーネントを考える。Old School な書き方だとこうなるだろう。 <style> .dark { color: #fff; background-color: #000; } .light { color: #000; background-color: #fff; } </style> <my-div class="dark">dark</my-div> <my-div class="light">light</my-div> この場合