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
420
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
150
Browser and UI #2 HTML/ARIA
ken7253
2
210
Browser and UI #1 CSS
ken7253
0
89
レビューのやり方を(ちょっと)整理した話
ken7253
1
500
オーバーロード関数の話 @Mita.ts #2
ken7253
0
94
フロントエンドカンファレンス北海道参加レポート
ken7253
0
37
カスタムHooksと単体テストの共通点について
ken7253
0
370
検索エンジン最適化はWebサイトのすべてなのか
ken7253
0
51
使いやすいツールチップを実装する方法
ken7253
0
110
Other Decks in Programming
See All in Programming
Development of an App for Intuitive AI Learning - Blockly Summit 2025
teba_eleven
0
110
WindowInsetsだってテストしたい
ryunen344
1
160
F#で自在につくる静的ブログサイト - 関数型まつり2025
pizzacat83
0
300
つよそうにふるまい、つよい成果を出すのなら、つよいのかもしれない
irof
1
290
try-catchを使わないエラーハンドリング!? PHPでResult型の考え方を取り入れてみよう
kajitack
3
510
The Evolution of Enterprise Java with Jakarta EE 11 and Beyond
ivargrimstad
1
680
ktr0731/go-mcpでMCPサーバー作ってみた
takak2166
0
160
カクヨムAndroidアプリのリブート
numeroanddev
0
420
Go Modules: From Basics to Beyond / Go Modulesの基本とその先へ
kuro_kurorrr
0
120
生成AIコーディングとの向き合い方、AIと共創するという考え方 / How to deal with generative AI coding and the concept of co-creating with AI
seike460
PRO
1
250
Haskell でアルゴリズムを抽象化する / 関数型言語で競技プログラミング
naoya
17
4.5k
技術懸念に立ち向かい 法改正を穏便に乗り切った話
pop_cashew
0
1.4k
Featured
See All Featured
A Tale of Four Properties
chriscoyier
159
23k
Building Applications with DynamoDB
mza
95
6.4k
VelocityConf: Rendering Performance Case Studies
addyosmani
329
24k
Navigating Team Friction
lara
186
15k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3k
Fireside Chat
paigeccino
37
3.5k
Designing Experiences People Love
moore
142
24k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
GraphQLとの向き合い方2022年版
quramy
46
14k
How to Ace a Technical Interview
jacobian
276
23k
Rails Girls Zürich Keynote
gr2m
94
14k
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> 要素のように機能の分割も有り得そう。 今後の動向によってはパーミッションモデルの変化があるかもしれない。
ありがとうございました!