Intros: Sam Weiler

Good time to make progress on permissions.

This session is to scope the issue, see who is interested in working on it

Anssi: invited to comment
... perspective from their working group - device & sensors, exposing powerful features to web platform

Q: how to not compromise privacy?

User-facing prompting doesn't scale

Permissions API allows management about access so we don't need to prompt user

Currently running original trial in Chrome (63) - generic sensors

Permissions API integration, require secure context, have limitations on sensors reading

If, say, window out of focus, it doesn't get sensor readings

Can add technical measures to enforce

UI can be confusing for users (mixed content)

Want to bring consistency to platform

User Agent should be able to innovate in UI experience

Is evolving; what works on desktop might not work for mobile (small screen)

Like to hear from others in this space

Sam: do we need to involve OS as well? (may ask same questions)

Q: which pieces are you struggling with? Are which ones do we need to tackle?

Anssi: the trial was mainly to get feedback from users

UI issues are hard

User experiments are key

User understanding is hard (e.g., what does it mean for sensor to have access)

Q: anything about equivalence classes? Do we bundle these?

Anssi: for us, some sensors are combined for simplification. But your question more about user intent?

npdoty: can be helpful to frame in terms of capabilities and not sensors
... may be able to identify places where APIs have similar capabilities

anssi: agrees for need to clarify language/presentation for users

npdoty: may not be able to explain features

barryl: challenge: granularity. Often ask/grant more than we need.
... can you describe what you intend to do, more than what you need

<npdoty> +1 for data minimization design in APIs

sam: mobile apps ask for file perms, but knowing they really need to save & read own files and not beyond, is clearer

anssi: asking for permission in context is often preferable; not surprise to users

<npdoty> keeping permissions design in-context, rather than app-like bundling, is a goal for the Web

"just in time" prompts

GDPR issues for consent need to be considered

Q: are consent receipts on the agenda?

Are we considering regulatory requirements in this session?

Intention here to try to take advantage of requirements in a positive way

npdoty: accountability approach can lower burden on users (asking a lot); might be easier to assist user and decrease requests/UX load

<oyiptong> err

anssi: sensors with more sensitive data, explicit ask; otherwise may be "ask forgiveness" for less sensitive cases
... have not done a great job in our community in documenting common patterns, good approaches

<anssik> Frecency algorithm

brandon (?): can we provide detail about usage (say, when sensor is in active use)?

anssi: we could do things like highlight first-visit usage

sam: how interested are browser vendors in having consistency?

(speaker?) - Mozilla prefers to improve what we have rather than deploy new model.

anssi: we can give guidance but not force a specific approach; some folks are unsure what to do

Should we have guidance in the specs? Well...not helpful for UX team

(eric?) - Permissions API provides a list of elements but implementation is still left to browser vendors

<oyiptong> npdoty: no, thank you, got my q asked

yochai (?) - want to allow users to allow different browsers and not have to reimplement everything for a site

npdoty: flexibility in UA is helpful but also interop important -- site developers will care if there is a big difference in implementation between browsers
... to get good interop, we may need to provide better guidance to devs

marcos: we had open bug for years on geolocation -- Firefox had inconsistency in UI, caused issues with user feedback
... we change guidelines so often that it's hard to provide UX guidance
... say, differences between mobile & desktop (modal interaction); need more research/data to help us

sam: bring convo back to what to complete in this workshop, highest priority

marcos: we found user perm databases were inconsistent - this is a blocker right now (Permissions API)
... what to do about legacy APIs?
... also how to handle revocation

(should you be able to revoke & re-ask)

how long should permissions live?

<npdoty> do we have clarity on origin-specificity of permissions?

Eric (?): not a lot of guidelines for those writing API spec -- if you need to request permission do you rely on PermAPI or need to handle this yourself?

Are things in, say, Clipboard Spec or Permissions? - want to do the right thing

anssi: Would like to look at existing models: up-front prompt, ask forgiveness; file system dialog modified with permission management in same UI

In other words: a UI abstraction, expanded for permission handling

anssi: also want to stress need for research/data on users/UI
... if we have a workshop, must have UI people involved

marcos: there is also "upgrade model" (#4)

anssi: yes, can make assumptions about previous model

(previous install, that is - what they allowed)

<npdoty> frequency, installability, and other trust heuristics could be a useful topic for discussion

And "frecency"

sam: ways of keeping permission records - there is what was granted but also what was used

hard to deploy these on mobile

users may want easy access to these records - clearly not for broader access

More suggestions: users don't have great ways to proceed when they say "no"

recovery flow is not excellent

<npdoty> a "second chance" api measure :)

<anssik> [to help scribe, FTR what I think would be useful to investigate further:]

If you say no to, say, geo location...there is no good way to recover from this

<anssik> Would think useful would be to survey shipping permission models:

<anssik> - ask forgiveness

<anssik> - up-front modal prompting

<anssik> - non-blocking prompting

<anssik> - <input type=file> dialog, used for filesystem access, also media capture (see capture attribute aka HTML Media Capture)

<anssik> - Progressive Web Apps model, "installed" web app implies increased level of trust

<anssik> - Frecency https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/_algorithm

(?) - existing model - if you get media permission and deny it more than once, UI changes accordingly (for repeat requests after denial)

<npdoty> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Frecency_algorithm

yochai: there may be ways to provide info through other means? (manual or another tool)

sam: there seem to be problems worth tackling

Any dissenters?

Calendar constraints in Feb/Mar to avoid? IETF.

Last thoughts?

Where is workshop? Unknown right now.

NA or EU seems to work for folks in the room.

Offer for Melbourne also thrown into the ring....

Q: this is all focused on user perms, yes? Internet Identity Workshop is in first week with April (Mountain View)

Might have overlap in audiences

wseltzer: rechartering of Device & Sensor WG might be relevant to this work - ideas for new work.

anssi: this is under discussion

<weiler> Meeting: TPAC 2017 breakout on Permissions and User Consent

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: weiler Anssi_Kostiainen npdoty shigeya Keyur Tomoyuki_Shimizu jeffh
No ScribeNick specified.  Guessing ScribeNick: tarawhalen
Inferring Scribes: tarawhalen

WARNING: No "Topic:" lines found.


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)