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
380
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
Browser and UI #1 CSS
ken7253
0
62
レビューのやり方を(ちょっと)整理した話
ken7253
1
470
オーバーロード関数の話 @Mita.ts #2
ken7253
0
71
フロントエンドカンファレンス北海道参加レポート
ken7253
0
35
カスタムHooksと単体テストの共通点について
ken7253
0
340
検索エンジン最適化はWebサイトのすべてなのか
ken7253
0
46
使いやすいツールチップを実装する方法
ken7253
0
97
Reactにおけるkeyの使い方について
ken7253
1
160
テックブログ文豪への道
ken7253
0
76
Other Decks in Programming
See All in Programming
List とは何か? / PHPerKaigi 2025
meihei3
0
860
PHPバージョンアップから始めるOSSコントリビュート / how2oss-contribute
dmnlk
1
1k
Building a macOS screen saver with Kotlin (Android Makers 2025)
zsmb
1
150
メモリウォールを超えて:キャッシュメモリ技術の進歩
kawayu
0
1.9k
Building Scalable Mobile Projects: Fast Builds, High Reusability and Clear Ownership
cyrilmottier
2
280
リストビュー画面UX改善の振り返り
splcywolf
0
140
AHC045_解説
shun_pi
0
530
Code smarter, not harder - How AI Coding Tools Boost Your Productivity | Webinar 2025
danielsogl
0
130
The Efficiency Paradox and How to Save Yourself and the World
hollycummins
0
110
サービスクラスのありがたみを発見したときの思い出 #phpcon_odawara
77web
4
640
RuboCop: Modularity and AST Insights
koic
2
430
Agentic Applications with Symfony
el_stoffel
2
290
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
7
390
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Unsuck your backbone
ammeep
670
57k
Facilitating Awesome Meetings
lara
54
6.3k
For a Future-Friendly Web
brad_frost
176
9.7k
Into the Great Unknown - MozCon
thekraken
37
1.7k
Speed Design
sergeychernyshev
29
900
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
660
Side Projects
sachag
452
42k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
178
53k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
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> 要素のように機能の分割も有り得そう。 今後の動向によってはパーミッションモデルの変化があるかもしれない。
ありがとうございました!