Permissions Spec ad-hoc call -- 08 Jun 2016

<scribe> scribenick: bhill2

<hta2> OK, I'm here.

jyasskin: guess chaals won't be making it... let's start
... there are 3 PRs I've wrote for the Permissions spec, they differ in the ways that I've listed as questions on the agenda
... between doing the 2nd and 3rd, Anne suggested I document how UAs actually behave and future plans
... that is the UA behavior doc linked from the agenda

https://docs.google.com/document/d/1_YTpXijrkKNlmSlpA0fEwc5WMmZvRvdTRwF81g_gndk/edit

jyasskin: FF asks multiple times even in the same frame for multiple requests
... revoking doesn't impact existing streams / sequence of callbacks from already granted sources
... safari lets you call watchLocation multiple times, only shows bubble on first time
... callbacks continue if blocked in another frame
... chrome, edge, show a bubble, if user accepts, can call from other frames with no bubble
... camera is basically the same but Edge switches behavior and acts more like Safari

mt: not really different for other permissions

jyasskin: didn't rigorously test, but don't expect

mt: probably would just be a browser bug if there were differences

jyasskin: in chrome you can manually grant permission to an entire domain (+ subdomains) not just an origin
... can also grant permissions without user having done anything
... and changes in various specs for future UI, e.g. persistent storage requiring a persistent permission (not like Safari/FF default)
... media wants to require consent in context of top-level domain
... chrome planning to experiment with auto-deny and auto-grant
... permission delegation and feature policy proposals which would constrain possible grants to those from parent or headers
... midi and push behave a bit differently from other complex permissions, some imply others (e.g. midi with sysex implies without as well)
... the PRs interact in different ways
... skip to agenda item 3
... starting with first
... there are 3 different ways to describe how permission stores work
... leaning toward 3rd
... specifically we don't describe permission stores at all, but describe a query that algorithms can make
... UA returns what it believes user intent is for those queries

mt: this is consistent with my original understanding

jyasskin: original spec didn't say anything about how query happened or got an answer
... that's what issue #97 goes back to
... other PRs are more concrete but allow same behaviors from the UA

mt: hard to test assertion that these are functionally equivalent as they are difficult to comprehend

jyasskin: look like they require UA to do things but don't in practice

mt: not certain that's true

jyasskin: 96 is halfway between the other two, defines a per-realm store initialized and changed however UA wants
... provides a concrete place to put data but doesn't really constrain anything so I think more straightforward to just take 97's suggestion

hta2: the reason we've gotten into specifying is there are things we don't want the UA to do
... e.g. we don't want permissions to cross origins or have inconsistent answers
... can always find inconsistencies when UA can 'intuit' intent of the user

mt: permissions do cross origins and it varies how that happens
... how do the subtle variations on origin allow this to happen
... in FF www.google.com I believe that permissions for that can extend to a.www.google.com, and port numbers are irrelevant
... that's how permissions work when they first landed in the dawn of time
... point of spec is to make sure that when the application makes a request it understood on what terms it was making the request
... so it can avoid asking awkward questions in inappropriate situations

jyasskin: heard questions from Anne and Harald about forbidding that kind of behavior, if FF is doing it it is hard to forbid it

mt: if we deny a permission we do a lot of cleaning up of the database and things we shouldn't do, but intent is the same
... we look at public suffix list and actually go to public suffix and scrub to that level in case you've given permission for
... www.google.com and google.com separately, both will get denied if you deny either

hta2: if you deny hangouts.google.com you also deny google.com?

mt: think so but not certain; code is a rats nest, may depend on permission too
... getUserMedia is different code from notifications stuff

hta2: good to have a recommended implementation and allow UAs to do elsewise

mt: I think denying permissions is an interesting part here
... means that hangouts may need to go back to the prompt if appRTC gets denial
... but better than surprises on the part of the user if we do things like hide the www in the address bar; user thinks they've denied google

jyasskin: don't think I've said anything about revocation in the 97 proposal

mt: spot on, says "if you learn user wants to deny... deny"

jyasskin: not consistent in restricting to an origin everywhere

raymes: some feel strongly permissions should only be origin scoped, that's the model of the web
... but we are talking about different UX treatments of address bar and hiding various things
... if user thinks of them as same thing, seems like we may end up scoping to something like that, probably not now in Chrome
... too much momentum to keep scoped to origin for now

jyasskin: fine for this difference in behavior and want to allow it in the spec

hta2: would like to have a recommendation and sharply differentiate between what the sites can do and what the user can do
... request vs. revoke
... if a blog on blogspot was able to programmatically manipulate permissions for another blog, very bad
... user denying all of blogspot.com is fine

mt: yes, but I believe blogspot has an entry in the PSL

hta2: at any given time it is dangerous if PSL is not updated

mt: grants need to be narrower than revocations

hta2: if user wants to grant widely, fine, but application should not be able to programmatically have ability to modify state beyond itself

jyasskin: as written shouldn't grant to parallel application

mt: not strictly true, port is scrubbed; cert is good enough

jyasskin: parallel domain should be safe

hta2: consider an attack from a domain that is unfriendly

jyasskin: at most a DoS

hta2: an irritation to the user, kind of a DoS

mt: think it is managable

jyasskin: think people like 97?

mt: on point D there is some work to be done

jyasskin: details will need work but other PRs don't specify an algorithm
... 97 lets the algo call into other specs

mt: not that much to write out

hta2: in getUserMedia it took quite a few rounds
... a joint spec will make it easier to argue for merged implementations

mt: I think 97 as a hook is pretty good
... prompt user to choose I have comments on

jyasskin: I think we can iterate on choice topic offline
... ask users permission is intended to refer to the bubble or whatever UA does

mt: the way I modeled this is "yes | no | I don't know"
... IDK is "get some more info", prompt user to choose is one implementation of that
... could allow browser to do other things

hta2: choose vs. prompt is relevant if e.g. 3 cameras vs 1

rrasgent, make minutes

hta2: problem with prompt to choose is it introduces notion of option which I can't find defined
... should say prompt to select a descriptor

jyasskin: in media capture argument is mediaStreamConstraint

hta2: getUserMedia first looks at list of configurations, resolutions, framerates, camera direction
... filters those before asking user to choose among remaining
... don't want to pass constraints directly to user, but results of applying constraints

mt: think we need to refine the "i don't know" aspect of this
... but think the basics are fine

raymes: what should the choose algorithm return?

jyasskin: returns one of the choices, or denied

raymes: what _is_ it

jyasskin: whatever structure the caller passed in
... options must be both human understandable and something useable by the algorithm later
... in getusermedia may be a list of media source ids

mt: which prompt will have to change into meaningful names

hta2: should be able to treat permission for each camera individually

mt: that's one way to model it

hta2: one complication of getUserMedia is that devices come and go

jyasskin: api can expose list of present devices which is a subset of those granted

mt: subset of all devices ever known, superset of those available as it may return denied devices

jyasskin: in bluetooth we don't return devices not granted

mt: only concern I see is how to present e.g. mic and camera concurrently from POV of spec

hta2: when you want to ask for something, you add it to the list of everything to ask for, and at event loop turn, aggregate the requests to the user

mt: that is one way to implement, but do you need to say anything in the spec

hta2: if anything, implementation guidance, people will ask about this

mt: what if you've got a prompt in front of someone and geolocation is asked for? do you consolidate or show another one?

jyasskin: thoughts on powerful features?

mt: would avoid that term, use something value neutral; maybe talk about resources that require permissions?

hta2: resource works, capability works for me to; vague enough to mean anything

raymes: feature?

hta2: feature doesn't work, if I have 2 cameras, both are not features; camera is the feature

jyasskin: camera is the feature, you grant access to a specific device; same with bluetooth

mt: how would you model file upload with this spec?

jyasskin: file is a resource, picker grants you access to contents once

<hta2> IP addresses need to be modeled as a resource/feature/capability.

<mt_____> hta: access to IP addresses in WebRTC specifically

<mt_____> My point was that #97 allows us to weasel things nicely

<hta2> We want the spec to be able to say "the user's intent to grant access to IP addresses is inferred from his granting permisison to use of cameras", which is gross, but it's what we're going to do.

request & revoke

mt: maybe issue 83 is summary of issue?

https://github.com/w3c/permissions/issues/83

jyasskin comment on Apr 27 (Pro / Con)

mt: for new APIs we can have consistent spelling, but not particularly compelling

raymes: I lean towards not including these; people who want these the most aren't here
... need to give people like mounir space to comment
... other con I see is that it is unclear what features require permissions up front and can change over time
... we've seen that with fullscreen, used to require permission, now doesn't in chrome
... more transparent we can be between something being permission gated and not makes that evolution easier

jyasskin: I think query covers things that might require permission, but not everything needs a revoke API

raymes: finding a way to provide consistency across APIs is good

jyasskin: could have a guideline for API shapes wouldn't be a requirement on UAs but be guidance for spec writers

mt: would be very useful, trying to imagine what it looks like; something like single entry point, returns a promise, resolves only after all machinery is complete

jyasskin: could incorporate Alex Russel's document of complaints about geolocation

mt: geolocation was built in the dark ages and would be an easy one to fix
... problem with notifications is an interesting one because we don't have any action the user has seen at the point the site has to make that request
... don't know how to solve the problem

jyasskin: one fundamental disagreement between requesting by using feature first time or providing ability to ask permission whenever to use later

mt: both are reasonable positions, need those people in the room

jyasskin: can emulate either with the other most of the time
... becomes a matter of taste
... think I have good direction for basic structure of spec, request/revoke needs input from other people not on this call
... will post a PR once that's cleaned up

mt: think you can close 95/96, should merge 97 and we can iterate on the rest of it
... will merge it

- DRAFT -

Permissions Spec ad-hoc call

08 Jun 2016

Attendees

Contents

request & revoke

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output