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
Modern Angular with Signals and Signal Store:New Rules for Your Architecture @enterJS Advanced Angular Day 2025
manfredsteyer
PRO
0
220
PHPでWebSocketサーバーを実装しよう2025
kubotak
0
280
XP, Testing and ninja testing
m_seki
3
240
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
120
10 Costly Database Performance Mistakes (And How To Fix Them)
andyatkinson
0
330
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.1k
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
130
VS Code Update for GitHub Copilot
74th
2
640
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
4k
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
13
3.7k
すべてのコンテキストを、 ユーザー価値に変える
applism118
3
1.3k
MDN Web Docs に日本語翻訳でコントリビュートしたくなる
ohmori_yusuke
1
120
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
What's in a price? How to price your products and services
michaelherold
246
12k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Site-Speed That Sticks
csswizardry
10
690
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
KATA
mclloyd
30
14k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Optimizing for Happiness
mojombo
379
70k
Raft: Consensus for Rubyists
vanstee
140
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> 要素のように機能の分割も有り得そう。 今後の動向によってはパーミッションモデルの変化があるかもしれない。
ありがとうございました!