Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
PEPCは何を変えようとしていたのか
Search
ken7253
February 28, 2025
Programming
3
430
PEPCは何を変えようとしていたのか
[@JSConf.jp おかわり Node学園46時限目](
https://nodejs.connpass.com/event/344588/)にて発表した資料です
。
ken7253
February 28, 2025
Tweet
Share
More Decks by ken7253
See All by ken7253
CSS polyfill とその未来
ken7253
0
160
Browser and UI #2 HTML/ARIA
ken7253
2
210
Browser and UI #1 CSS
ken7253
0
94
レビューのやり方を(ちょっと)整理した話
ken7253
1
500
オーバーロード関数の話 @Mita.ts #2
ken7253
0
97
フロントエンドカンファレンス北海道参加レポート
ken7253
0
41
カスタムHooksと単体テストの共通点について
ken7253
0
370
検索エンジン最適化はWebサイトのすべてなのか
ken7253
0
53
使いやすいツールチップを実装する方法
ken7253
0
110
Other Decks in Programming
See All in Programming
「テストは愚直&&網羅的に書くほどよい」という誤解 / Test Smarter, Not Harder
munetoshi
0
170
RailsGirls IZUMO スポンサーLT
16bitidol
0
180
Python型ヒント完全ガイド 初心者でも分かる、現代的で実践的な使い方
mickey_kubo
1
110
Hypervel - A Coroutine Framework for Laravel Artisans
albertcht
1
120
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
2.1k
#QiitaBash MCPのセキュリティ
ryosukedtomita
1
1.3k
PipeCDのプラグイン化で目指すところ
warashi
1
270
おやつのお供はお決まりですか?@WWDC25 Recap -Japan-\(region).swift
shingangan
0
130
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
11k
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
250
Claude Code + Container Use と Cursor で作る ローカル並列開発環境のススメ / ccc local dev
kaelaela
9
5k
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
250
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
BBQ
matthewcrist
89
9.7k
Rails Girls Zürich Keynote
gr2m
95
14k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Agile that works and the tools we love
rasmusluckow
329
21k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
A designer walks into a library…
pauljervisheath
207
24k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
510
Transcript
PEPCは何を変えようとしていたのか @JSConf.jp おかわり Node学園46時限目
ブラウザの標準化まわりを追うのが趣味 最近はReactを使ったアプリケーションを書いています。 ユーザーインターフェイスやブラウザが好き。 https://github.com/ken7253 https://zenn.dev/ken7253 https://bsky.app/profile/ken7253.bsky.social https://dairoku-studio.com ken7253 Frontend developer
PEPCとはなにか
PEPC = Page Embedded Permission Control
一番大きい変更としては <permission> 要素を追加すること。 クリック時に指定した権限の許可がトリガーされる UIはUAから提供されクリック ジャッキングなどができない 権限の許可と種類がセマンティックとして定義される 一度権限を拒否しても再度クリックすることで許可のリクエストが発行される Chrome 126-137
にてOrigin Trialが行われている。 既存のブラウザのパーミッションモデルを大きく変えようとする提案。 PEPC = Page Embedded Permission Control
現在のブラウザにおける権限管理
現在のブラウザにおける権限管理 Chromeの場合、権限が必要なAPIが呼ばれるとオムニボックスの下にプロンプトが現れユーザーに許可を求める。
権限が必要な機能の実装 アプリケーションの実装としては非同期処理として素直に実装すればいいだけ then...catch とかでエラーハンドリング 実装としてはそれでいいが、本当に使いやすいのか? try { await navigator.getUserMedia({ audio:
true, video: true, }, () => {}, () => {}); } catch (e) { // ... };
現在の権限管理の問題点 どの要素がどの権限のリクエストを行うかがセマンティックとして表現されていない 権限のリクエストを行った要素とプロンプトの位置の乖離 "permanent deny" policy により誤った権限拒否の訂正を行うのが難しい
ユーザーが許可するまでプロンプトを出し続けるというスパムができないように、一度拒 否した権限リクエストはアプリケーション側から再度リクエストができないようになって いる。 https://github.com/WICG/PEPC/blob/main/explainer.md#user-agent-abuse- mitigations "permanent deny" policy Many user
agents implement a "permanent deny" policy, and other user agents offer it as an option in the permission prompt. This means that a site will not be able to ask for permission again after the user has blocked it. “ “ ” ”
権限のリクエスト方式
現在のパーミッションリクエスト Browser Application Browser Application 権限を拒否した場合、同じ権限は再度リクエストできない User ボタン等をクリック Event 権限のリクエスト
プロンプトを表示 権限を許可 アクセスの許可 機能の提供 User
PEPCでのパーミッションリクエスト Browser Application Browser Application ユーザー側から事前に許可を与える User Permission要素をクリック Event 機能の提供
User
何が変わるのか 従来はアクション後にプロンプトが表示され計2回のアクションが必要になる。 PEPCでは許可しつつイベントを処理でき1度のアクションで機能を提供できる。 ユーザー起点の許可なのでスパムの心配がなく拒否からの復帰が楽になる。 要素がどの権限を許可するものなのかがセマンティックとして明確になる(はず)。 https://permission.site/pepc
課題がめちゃくちゃ多いのも事実
Webkit,MozillaともにStandard positionはNegative寄り。 https://github.com/WebKit/standards-positions/issues/270 https://github.com/mozilla/standards-positions/issues/908 最大の懸念であるクリックジャッキングの対策のため非常に複雑な仕様に… PEPCの課題
なぜ複雑な仕様になってしまうのか
素直に実装してしまうと 画面全体に透明なpermission要素を設置できてしまう アプリケーション側からEventをdispatchできてしまう ユーザーが別の要素をクリックする直前に前面にpermission要素を表示する などクリックジャッキングが可能になってしまう。 なぜ複雑な仕様になってしまうのか
クリックジャッキング対策のために 表示されるテキストはUAが管理する CSSの指定をホワイトリスト形式に 要素のレンダリング上限の制限 サブフレームでの使用条件の制限 クリックイベントのdispatchに対する制限 クリックの直前にPEPCが移動していないこと クリックの直前にPEPCが(他の要素に覆われていない)見えていること クリックの直前にPEPCがNodeに挿入されていないこと などの対策を行う必要があることが一番大きな要因
なぜ複雑な仕様になってしまうのか
UAがテキストを管理することとCSSの制限に関連して、CSSで Upper case に指定した 場合にテキストの意味が変わってしまう言語はあるのかなどの懸念も Styling button text-transform (capitalize/uppercase/lowercase) #28
なぜ複雑な仕様になってしまうのか
PEPCの現状
PEPCの現状 Webkit,Mozillaの反対意見は根強い セキュリティ的な懸念や余計な複雑性が発生しているのは事実 大きく問題を2つに分けて代替え案なども検討されている 権限リクエストのプロンプトを改善する方向 権限の許可フローの改善
PEPCの現状 現状のままでは標準化は非常に厳しい状態である。 やりたいことは分かるし、需要もありそうだが理解を得られる実装ではない。 一方で代替え案や <portal> 要素のように機能の分割も有り得そう。 今後の動向によってはパーミッションモデルの変化があるかもしれない。
ありがとうございました!