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
220
Browser and UI #1 CSS
ken7253
0
96
レビューのやり方を(ちょっと)整理した話
ken7253
1
500
オーバーロード関数の話 @Mita.ts #2
ken7253
0
98
フロントエンドカンファレンス北海道参加レポート
ken7253
0
41
カスタムHooksと単体テストの共通点について
ken7253
0
380
検索エンジン最適化はWebサイトのすべてなのか
ken7253
0
55
使いやすいツールチップを実装する方法
ken7253
0
110
Other Decks in Programming
See All in Programming
The Modern View Layer Rails Deserves: A Vision For 2025 And Beyond @ RailsConf 2025, Philadelphia, PA
marcoroth
2
730
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
620
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
230
バイブコーディング超えてバイブデプロイ〜CloudflareMCPで実現する、未来のアプリケーションデリバリー〜
azukiazusa1
0
350
猫と暮らす Google Nest Cam生活🐈 / WebRTC with Google Nest Cam
yutailang0119
0
170
テスターからテストエンジニアへ ~新米テストエンジニアが歩んだ9ヶ月振り返り~
non0113
2
220
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
250
Claude Code + Container Use と Cursor で作る ローカル並列開発環境のススメ / ccc local dev
kaelaela
12
7.1k
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
260
ソフトウェア設計とAI技術の活用
masuda220
PRO
17
3.8k
おやつのお供はお決まりですか?@WWDC25 Recap -Japan-\(region).swift
shingangan
0
140
レベル1の開発生産性向上に取り組む − 日々の作業の効率化・自動化を通じた改善活動
kesoji
0
300
Featured
See All Featured
Done Done
chrislema
184
16k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
520
The World Runs on Bad Software
bkeepers
PRO
70
11k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Balancing Empowerment & Direction
lara
1
450
What's in a price? How to price your products and services
michaelherold
246
12k
Building Adaptive Systems
keathley
43
2.7k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
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> 要素のように機能の分割も有り得そう。 今後の動向によってはパーミッションモデルの変化があるかもしれない。
ありがとうございました!