BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.5.8//EN
CALSCALE:GREGORIAN
LAST-MODIFIED:20241106T183245Z
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-MICROSOFT-CDO-TZID:13
BEGIN:STANDARD
DTSTART:20231105T090000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
END:STANDARD
BEGIN:STANDARD
DTSTART:20241103T090000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20240310T100000
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:2912dccd-bd4d-4671-b63f-c045c7a1703a
DTSTAMP:20241106T183245Z
SUMMARY:Page Embedded Permission Control (PEPC): Safely embedding permissio
 n entry points in web content
DTSTART;TZID=America/Los_Angeles:20240925T100000
DTEND;TZID=America/Los_Angeles:20240925T110000
DESCRIPTION:https://www.w3.org/events/meetings/2912dccd-bd4d-4671-b63f-c045
 c7a1703a/\n\nThis breakout will continue past discussions of the Page Embe
 dded Permission Control ([PEPC](https://github.com/WICG/PEPC)). We will di
 scuss safe\, consistent mechanisms for web developers to link into browser
  UI surfaces\, starting with permissions. Other examples of browser contro
 ls which could be embedded include content settings\, a PWA install trigge
 r\, an installed app management surface\, federated login\, autofill or ot
 her browser settings. To date discussion has focused on the permissions us
 e case\, and while we would like to continue this discussion we believe th
 e concept could be applicable to other use cases. \n\nAs web apps grow mor
 e sophisticated\, rivaling native apps in capability and complexity\, user
 s can become confused as to how to access important settings that affect t
 heir ability to use apps. For example\, in addition to origin scoped Permi
 ssions\, PWAs can have application settings scoped to the application. \n\
 nWebsites can try to help users by providing guided instructions into brow
 ser UI surfaces but (1) this normalizes a safety anti-pattern and should n
 ot be encouraged even in legitimate sites as malicious websites are excell
 ent at deceiving users into making unsafe changes to their settings\, (2) 
 instructions are inconvenient for the user\, difficult to maintain for dev
 elopers and frequently fail to help and (3) these types of instructions pr
 esent extra challenges for accessibility. \n\nThis session will continue t
 he dialog on providing in page access to permission settings\, including i
 mplications for the underlying browser permission model\, while expanding 
 the discussion to include problem spaces beyond permissions. We will prese
 nt preliminary usage data and developer feedback from the PEPC prototype f
 or permissions as context for conversation.\n\nAgenda: https://www.w3.org/
 2024/Talks/TPAC/breakouts/pepc.pdf\n\nAgenda\n\n**Chairs:**\nPenelope McLa
 chlan\, Andy Paicu\, Serena Chen\, Marian Harbach\, Balazs Engedy\n\n**Des
 cription:**\nThis breakout will continue past discussions of the Page Embe
 dded Permission Control ([PEPC](https://github.com/WICG/PEPC)). We will di
 scuss safe\, consistent mechanisms for web developers to link into browser
  UI surfaces\, starting with permissions. Other examples of browser contro
 ls which could be embedded include content settings\, a PWA install trigge
 r\, an installed app management surface\, federated login\, autofill or ot
 her browser settings. To date discussion has focused on the permissions us
 e case\, and while we would like to continue this discussion we believe th
 e concept could be applicable to other use cases. \n\nAs web apps grow mor
 e sophisticated\, rivaling native apps in capability and complexity\, user
 s can become confused as to how to access important settings that affect t
 heir ability to use apps. For example\, in addition to origin scoped Permi
 ssions\, PWAs can have application settings scoped to the application. \n\
 nWebsites can try to help users by providing guided instructions into brow
 ser UI surfaces but (1) this normalizes a safety anti-pattern and should n
 ot be encouraged even in legitimate sites as malicious websites are excell
 ent at deceiving users into making unsafe changes to their settings\, (2) 
 instructions are inconvenient for the user\, difficult to maintain for dev
 elopers and frequently fail to help and (3) these types of instructions pr
 esent extra challenges for accessibility. \n\nThis session will continue t
 he dialog on providing in page access to permission settings\, including i
 mplications for the underlying browser permission model\, while expanding 
 the discussion to include problem spaces beyond permissions. We will prese
 nt preliminary usage data and developer feedback from the PEPC prototype f
 or permissions as context for conversation.\n\n**Goal(s):**\nGather commun
 ity feedback on the use cases and requirements for a general solution to p
 roviding safe entry points into browser UI surfaces from web content while
  laying out an incremental roadmap. Discuss whether (1) the problem space 
 warrants solutions\, (2) the requirements of a solution\, (3) how the PEPC
  as prototyped stacks up against requirements\, (4) alternative ways the r
 equirements could be addressed.\n\n\n\n**Materials:**\n- [slides](https://
 www.w3.org/2024/Talks/TPAC/breakouts/pepc.pdf)\n- [minutes](https://www.w3
 .org/2024/09/breakouts/minutes-18.html)\n- [minutes (initial google doc)](
 https://docs.google.com/document/d/1LR0OjpNRdZCkt6AcZZgflRJeJbGTyTPS5aTUYk
 7iYk8/edit#heading=h.icqdtkv1satn)\n- [Session proposal on GitHub](https:/
 /github.com/w3c/tpac2024-breakouts/issues/18)\n\n**Track(s):**\n- Permissi
 ons
STATUS:CONFIRMED
CREATED:20240916T214931Z
LAST-MODIFIED:20241106T183245Z
SEQUENCE:3
ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor
 eply@w3.org
LOCATION:4 Concourse Level - Oceanside
CATEGORIES:TPAC 2024,Breakout Sessions
END:VEVENT
END:VCALENDAR