BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.5.8//EN
CALSCALE:GREGORIAN
LAST-MODIFIED:20230923T163129Z
BEGIN:VTIMEZONE
TZID:Europe/Madrid
BEGIN:STANDARD
DTSTART:20221030T010000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:STANDARD
DTSTART:20231029T010000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20230326T010000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:16be075a-4b62-4712-bff5-5d3b509746f1
DTSTAMP:20230923T163129Z
SUMMARY:Page Embedded Permission Control (Permission Element)
DTSTART;TZID=Europe/Madrid:20230913T110000
DTEND;TZID=Europe/Madrid:20230913T120000
DESCRIPTION:https://www.w3.org/events/meetings/16be075a-4b62-4712-bff5-5d3b
 509746f1/\n\nMost user interactions on permission prompts are negative. Fo
 r notifications (the most requested permission type)\, Google Chrome metri
 cs data shows that the percentage of prompts that are ignored\, dismissed 
 or blocked by the user add up to approx 92% on desktop platforms and 85% o
 n mobile devices. \n\n\n\n\n\n\n\nA permission model designed to be initia
 ted by the user would solve these issues. If the user initiates the permis
 sion request it ensures that:\n\n\n\n\n\n\n\n- The user understands the pu
 rpose of the permission\, or at least has enough context to feel comfortab
 le engaging in an activity that uses this permission.\n\n\n\n- The user’
 s current flow or task is related to granting this permission and as such 
 it’s unlikely that the permission request could be interruptive.\n\n\n\n
 - The user agent can ensure the subsequent UI is placed near the current f
 ocus of attention of the user. This is because the user has just interacte
 d with some piece of UI to request the permission which means their focus 
 is likely in the area. Because of the above\, it is unlikely that such a p
 lacement is interruptive or annoying.\n\n\n\n\n\nThis breakout would discu
 ss a proposal for Permission Embedded Permission Control [[explainer](http
 s://github.com/andypaicu/PEPC/blob/main/explainer.md)] [[deck](https://doc
 s.google.com/presentation/d/1fzMEeyWbdpBS7HN9WumIOSbqB3pl-MG2DTo_5-lvgus/e
 dit#slide=id.g27df7eff9c5_0_226)] and intends to continue the dialog from 
 the [w3c Workshop on Permissions](https://www.w3.org/Privacy/permissions-w
 s-2022/report#beyond-prompts) held December 2022.\n\n\n\nSession [notes](h
 ttps://docs.google.com/document/d/1pJFCADgasiqojESz2VePkVwaDdlfDqpN5JSqo4T
 4mMs/edit#heading=h.ocs3ne1w3v4g)\n\nAgenda\n\n**Chairs:**\nPenelope McLac
 hlan\n\n**Description:**\nMost user interactions on permission prompts are
  negative. For notifications (the most requested permission type)\, Google
  Chrome metrics data shows that the percentage of prompts that are ignored
 \, dismissed or blocked by the user add up to approx 92% on desktop platfo
 rms and 85% on mobile devices. \n\n\n\n\n\n\n\nA permission model designed
  to be initiated by the user would solve these issues. If the user initiat
 es the permission request it ensures that:\n\n\n\n\n\n\n\n- The user under
 stands the purpose of the permission\, or at least has enough context to f
 eel comfortable engaging in an activity that uses this permission.\n\n\n\n
 - The user’s current flow or task is related to granting this permission
  and as such it’s unlikely that the permission request could be interrup
 tive.\n\n\n\n- The user agent can ensure the subsequent UI is placed near 
 the current focus of attention of the user. This is because the user has j
 ust interacted with some piece of UI to request the permission which means
  their focus is likely in the area. Because of the above\, it is unlikely 
 that such a placement is interruptive or annoying.\n\n\n\n\n\nThis breakou
 t would discuss a proposal for Permission Embedded Permission Control [[ex
 plainer](https://github.com/andypaicu/PEPC/blob/main/explainer.md)] [[deck
 ](https://docs.google.com/presentation/d/1fzMEeyWbdpBS7HN9WumIOSbqB3pl-MG2
 DTo_5-lvgus/edit#slide=id.g27df7eff9c5_0_226)] and intends to continue the
  dialog from the [w3c Workshop on Permissions](https://www.w3.org/Privacy/
 permissions-ws-2022/report#beyond-prompts) held December 2022.\n\n\n\nSess
 ion [notes](https://docs.google.com/document/d/1pJFCADgasiqojESz2VePkVwaDd
 lfDqpN5JSqo4T4mMs/edit#heading=h.ocs3ne1w3v4g)\n\n**Goal(s):**\nFeedback o
 n a proposal to create a Page Embedded Permission Control (Permission Elem
 ent)\n\n\n**Materials:**\n- [slides](https://docs.google.com/presentation/
 d/1fzMEeyWbdpBS7HN9WumIOSbqB3pl-MG2DTo_5-lvgus/edit#slide=id.g27df7eff9c5_
 0_226)\n- [minutes](http://www.w3.org/2023/09/tpac-breakouts/35-minutes.pd
 f)\n- [live google doc minutes](https://docs.google.com/document/d/1pJFCAD
 gasiqojESz2VePkVwaDdlfDqpN5JSqo4T4mMs/edit#heading=h.ocs3ne1w3v4g)\n- [Ses
 sion proposal on GitHub](https://github.com/w3c/tpac2023-breakouts/issues/
 35)\n\n**Track(s):**\n- privacy
STATUS:CONFIRMED
CREATED:20230905T053831Z
LAST-MODIFIED:20230923T163129Z
SEQUENCE:1
ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor
 eply@w3.org
LOCATION:Giralda III - Level -2
CATEGORIES:TPAC 2023,Breakout Sessions
END:VEVENT
END:VCALENDAR
