BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.5.8//EN
CALSCALE:GREGORIAN
LAST-MODIFIED:20260317T123419Z
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:a475d392-c679-4db6-95c5-2ff190a98b85
DTSTAMP:20260317T123419Z
SUMMARY:User Research on Permissions
DTSTART;TZID=America/Los_Angeles:20240925T083000
DTEND;TZID=America/Los_Angeles:20240925T093000
DESCRIPTION:https://www.w3.org/events/meetings/a475d392-c679-4db6-95c5-2ff1
 90a98b85/\n\nThis breakout provides an opportunity to share results from u
 ser research on permission prompts\, discuss methods and findings\, and id
 eate on additional research that could help the community.\n\nPermissions 
 are notoriously difficult to study\, given that they happen in very brief 
 moments while users try to accomplish a primary task. Yet\, they are an im
 portant security and privacy mechanism that can have substantial positive 
 or negative impact on users' experiences on the web. The Chrome team condu
 cted two studies to ([1](https://dl.acm.org/doi/pdf/10.1145/3613904.364225
 2)) understand the general experience of permission prompts on the web as 
 well as ([2](https://www.ndss-symposium.org/wp-content/uploads/2024-108-pa
 per.pdf)) how users perceive a mechanism to make prompts less interruptive
 . We will share a brief overview of results from the two studies and discu
 ss implications.\n\nBeyond that\, this forum provides an opportunity to ex
 change ideas and experiences when conducting user research on security and
  privacy mechanisms in browsers as well as to identify new opportunities t
 o better understand users' experiences.\n\nPlease leave comments and sugge
 stions\, for example if you also have user research in the permissions spa
 ce that you would like to share or other ideas that would fit well into th
 e scope of this breakout.\n\n[Slide deck](https://drive.google.com/file/d/
 1vEhjRx1j69fA2zDtDOJbfsMxOEC3qV-C/view)\n[Recording of conference talk for
  paper 1](https://dl.acm.org/doi/full/10.1145/3613904.3642252#supplementar
 y-materials)\n[Recording of conference talk for paper 2](https://www.youtu
 be.com/watch?v=rbsAPw1XL5Q)\n\n#### **Notes from Q\\&A:**\n\n*Q: When acce
 ssing or requesting permission websites should explain why. Any testing an
 d research whether the page has made an attempt to explain to the user why
  it is asking?*   \nA: Permission rationale study. Tricky to draw firm con
 clusions\, data is very noisy. Will follow up with a study replicating the
  main flows we observed.\n\n*Q: why do websites ask for permission on arri
 val? E.g. [google.com](http://google.com) asks like that without context.*
   \nA: It’s tricky to get hold of non-Google website owners that would p
 rovide rationale. Those that wanted to talk about it were likely to have t
 hought about providing rationale anyway. \n\n*Q: if you require user inter
 action to trigger the prompt what would happen? Do we care if we break pag
 es because of that?*  \nA: This is more a business question than a researc
 h question. Browsers would need to answer that for themselves. Developers 
 can actually query the permission state. So there’s a way for developers
  to check before prompting.\n\n*Q: Prompt fatigue: is that influencing beh
 avior when dealing with the prompt?*   \nA: At the median\, individuals on
  Chrome see approx. 1 prompt per 2 weeks. People make fast decisions based
  on habituation. Fatigue comes through qualitatively though and we do try 
 to avoid additional prompts. \n\n*Q: Cookie banners: users don’t differe
 ntiate between actual permission prompts and cookie banners. So they add t
 o fatigue. Any research related to that?*  \nA: No specific research on ou
 r end\, but we see study participants confuse cookie banners for permissio
 n prompts.\n\n*Q: How many prompts users see is influenced by Chrome remem
 bering the permission state\, this is not the same behavior for Safari. So
  it feels like assumed user fatigue is more of a Chrome thing than generic
  across browsers.*  \nA: Agreed. We are rolling out one time permissions w
 hich will change that\, but no concrete data to be shared yet.\n\n*Comment
 : If we think about the people who commission websites\, they want to know
  where the customers are and send them stuff. Not at all surprising that w
 e have so much more notifications and location prompts.*\n\n*Q: Is there a
  way for websites to know they’re getting into the quieting zone of Chro
 me’s intervention?*  \nA: You can look in CrUX to see your rank\, but th
 ere’s not a direct way to know beyond that.\n\n*Q: Safari requires user 
 activation for Notifications. It’s great that Chrome and Firefox also do
  this. We should start doing something about geolocation as well.*   \nA: 
 Next session has more on notification spam and proposes some solutions.\n\
 n*Q: Is there a presentation issue around users being told that the prompt
  is quieted? Can we reframe it to sound more positive\, e.g. this is a new
  way of doing prompting?*  \n*A: That sounds interesting and worth explori
 ng. We did attempt to change the string in the chip to say “Get Notifica
 tions?” and that did not have substantial effects\, though.*\n\n*Q: Did 
 website devs complain about Chrome changing behavior?*   \nA: Some\, but w
 e tend to answer with “If you do the right thing you shouldn’t need to
  worry about it.” But yes\, developers want predictability.\n\n**Goal(s)
 :**\nShare user research findings on permissions\, discuss best practices 
 and ideas\n\n**Track(s):**\n- Permissions\n\nAgenda\n\n**Materials:**\n- [
 slides](https://www.w3.org/2024/Talks/TPAC/breakouts/user-permissions-rese
 arch.pdf)\n- [Session proposal on GitHub](https://github.com/w3c/tpac2024-
 breakouts/issues/8)
STATUS:CONFIRMED
CREATED:20240916T214722Z
LAST-MODIFIED:20260317T123419Z
SEQUENCE:4
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