06:02:09 RRSAgent has joined #webappsec 06:02:09 logging to http://www.w3.org/2016/06/08-webappsec-irc 06:02:18 Agenda: https://docs.google.com/document/d/1nuLxHqO20mR5XMoQyBRuxQQVtMLNQNjydKUonhk2S70/edit 06:02:24 Meeting: Permissions Spec ad-hoc call 06:02:36 bhill2 has changed the topic to: https://docs.google.com/document/d/1nuLxHqO20mR5XMoQyBRuxQQVtMLNQNjydKUonhk2S70/edit 06:02:41 scribenick: bhill2 06:02:47 present+ Brad Hill 06:03:02 present+ Jeffrey Yasskin 06:03:31 present+ Harald Alvestrand 06:03:40 present+ Raymes Khoury 06:03:46 present+ Martin Thompson 06:03:55 s/Thompson/Thomson 06:04:06 hta2 has joined #webappsec 06:04:19 OK, I'm here. 06:05:46 bblfish has joined #webappsec 06:06:23 jyasskin: guess chaals won't be making it... let's start 06:07:00 ... 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 06:07:18 ... between doing the 2nd and 3rd, Anne suggested I document how UAs actually behave and future plans 06:07:34 ... that is the UA behavior doc linked from the agenda 06:07:47 https://docs.google.com/document/d/1_YTpXijrkKNlmSlpA0fEwc5WMmZvRvdTRwF81g_gndk/edit 06:08:04 jyasskin: FF asks multiple times even in the same frame for multiple requests 06:08:23 ... revoking doesn't impact existing streams / sequence of callbacks from already granted sources 06:08:38 ... safari lets you call watchLocation multiple times, only shows bubble on first time 06:08:50 ... callbacks continue if blocked in another frame 06:09:02 ... chrome, edge, show a bubble, if user accepts, can call from other frames with no bubble 06:09:20 ... camera is basically the same but Edge switches behavior and acts more like Safari 06:09:37 mt: not really different for other permissions 06:09:47 jyasskin: didn't rigorously test, but don't expect 06:09:57 mt: probably would just be a browser bug if there were differences 06:10:16 jyasskin: in chrome you can manually grant permission to an entire domain (+ subdomains) not just an origin 06:10:28 ... can also grant permissions without user having done anything 06:10:48 ... and changes in various specs for future UI, e.g. persistent storage requiring a persistent permission (not like Safari/FF default) 06:11:08 ... media wants to require consent in context of top-level domain 06:11:20 ... chrome planning to experiment with auto-deny and auto-grant 06:11:44 ... permission delegation and feature policy proposals which would constrain possible grants to those from parent or headers 06:12:27 ... midi and push behave a bit differently from other complex permissions, some imply others (e.g. midi with sysex implies without as well) 06:12:33 ... the PRs interact in different ways 06:12:39 ... skip to agenda item 3 06:12:44 ... starting with first 06:12:56 ... there are 3 different ways to describe how permission stores work 06:13:02 ... leaning toward 3rd 06:13:14 ... specifically we don't describe permission stores at all, but describe a query that algorithms can make 06:13:23 ... UA returns what it believes user intent is for those queries 06:13:36 mt: this is consistent with my original understanding 06:13:58 jyasskin: original spec didn't say anything about how query happened or got an answer 06:14:06 ... that's what issue #97 goes back to 06:14:23 ... other PRs are more concrete but allow same behaviors from the UA 06:14:49 mt: hard to test assertion that these are functionally equivalent as they are difficult to comprehend 06:14:59 jyasskin: look like they require UA to do things but don't in practice 06:15:05 mt: not certain that's true 06:15:26 jyasskin: 96 is halfway between the other two, defines a per-realm store initialized and changed however UA wants 06:15:47 ... provides a concrete place to put data but doesn't really constrain anything so I think more straightforward to just take 97's suggestion 06:16:04 hta2: the reason we've gotten into specifying is there are things we don't want the UA to do 06:16:14 ... e.g. we don't want permissions to cross origins or have inconsistent answers 06:16:35 ... can always find inconsistencies when UA can 'intuit' intent of the user 06:16:47 mt: permissions do cross origins and it varies how that happens 06:16:58 ... how do the subtle variations on origin allow this to happen 06:17:30 ... in FF www.google.com I believe that permissions for that can extend to a.www.google.com, and port numbers are irrelevant 06:17:41 ... that's how permissions work when they first landed in the dawn of time 06:18:01 ... point of spec is to make sure that when the application makes a request it understood on what terms it was making the request 06:18:10 ... so it can avoid asking awkward questions in inappropriate situations 06:18:30 jyasskin: heard questions from Anne and Harald about forbidding that kind of behavior, if FF is doing it it is hard to forbid it 06:18:58 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 06:19:15 ... we look at public suffix list and actually go to public suffix and scrub to that level in case you've given permission for 06:19:28 ... www.google.com and google.com separately, both will get denied if you deny either 06:19:36 hta2: if you deny hangouts.google.com you also deny google.com? 06:19:54 mt: think so but not certain; code is a rats nest, may depend on permission too 06:20:19 ... getUserMedia is different code from notifications stuff 06:20:49 hta2: good to have a recommended implementation and allow UAs to do elsewise 06:20:59 mt: I think denying permissions is an interesting part here 06:21:14 ... means that hangouts may need to go back to the prompt if appRTC gets denial 06:21:43 ... 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 06:21:59 jyasskin: don't think I've said anything about revocation in the 97 proposal 06:22:12 mt: spot on, says "if you learn user wants to deny... deny" 06:22:41 jyasskin: not consistent in restricting to an origin everywhere 06:22:48 RRSAgent, make minutes 06:22:48 I have made the request to generate http://www.w3.org/2016/06/08-webappsec-minutes.html bhill2 06:23:12 raymes: some feel strongly permissions should only be origin scoped, that's the model of the web 06:23:26 ... but we are talking about different UX treatments of address bar and hiding various things 06:23:57 ... if user thinks of them as same thing, seems like we may end up scoping to something like that, probably not now in Chrome 06:24:03 ... too much momentum to keep scoped to origin for now 06:24:19 jyasskin: fine for this difference in behavior and want to allow it in the spec 06:24:33 hta2: would like to have a recommendation and sharply differentiate between what the sites can do and what the user can do 06:24:40 ... request vs. revoke 06:25:16 ... if a blog on blogspot was able to programmatically manipulate permissions for another blog, very bad 06:25:22 ... user denying all of blogspot.com is fine 06:25:32 mt: yes, but I believe blogspot has an entry in the PSL 06:25:41 hta2: at any given time it is dangerous if PSL is not updated 06:25:53 mt: grants need to be narrower than revocations 06:26:24 hta2: if user wants to grant widely, fine, but application should not be able to programmatically have ability to modify state beyond itself 06:26:47 jyasskin: as written shouldn't grant to parallel application 06:27:01 mt: not strictly true, port is scrubbed; cert is good enough 06:27:06 jyasskin: parallel domain should be safe 06:27:23 hta2: consider an attack from a domain that is unfriendly 06:27:29 jyasskin: at most a DoS 06:27:40 hta2: an irritation to the user, kind of a DoS 06:27:50 mt: think it is managable 06:28:07 jyasskin: think people like 97? 06:28:31 mt: on point D there is some work to be done 06:28:49 jyasskin: details will need work but other PRs don't specify an algorithm 06:28:58 ... 97 lets the algo call into other specs 06:29:08 mt: not that much to write out 06:29:22 hta2: in getUserMedia it took quite a few rounds 06:29:38 ... a joint spec will make it easier to argue for merged implementations 06:29:49 mt: I think 97 as a hook is pretty good 06:30:02 ... prompt user to choose I have comments on 06:30:21 jyasskin: I think we can iterate on choice topic offline 06:31:27 ... ask users permission is intended to refer to the bubble or whatever UA does 06:31:41 mt: the way I modeled this is "yes | no | I don't know" 06:31:53 ... IDK is "get some more info", prompt user to choose is one implementation of that 06:31:59 ... could allow browser to do other things 06:32:31 hta2; choose vs. prompt is relevant if e.g. 3 cameras vs 1 06:33:11 s/hta2;/hta2:/ 06:33:20 rrasgent, make minutes 06:33:26 RRSAgent, make minutes 06:33:26 I have made the request to generate http://www.w3.org/2016/06/08-webappsec-minutes.html bhill2 06:34:25 hta2: problem with prompt to choose is it introduces notion of option which I can't find defined 06:34:41 ... should say prompt to select a descriptor 06:35:09 jyasskin: in media capture argument is mediaStreamConstraint 06:35:24 hta2: getUserMedia first looks at list of configurations, resolutions, framerates, camera direction 06:35:48 ... filters those before asking user to choose among remaining 06:36:01 ... don't want to pass constraints directly to user, but results of applying constraints 06:36:22 mt: think we need to refine the "i don't know" aspect of this 06:36:27 ... but think the basics are fine 06:36:44 raymes: what should the choose algorithm return? 06:36:54 jyasskin: returns one of the choices, or denied 06:37:02 raymes: what _is_ it 06:37:10 jyasskin: whatever structure the caller passed in 06:37:21 ... options must be both human understandable and something useable by the algorithm later 06:37:34 ... in getusermedia may be a list of media source ids 06:37:42 mt: which prompt will have to change into meaningful names 06:38:12 hta2: should be able to treat permission for each camera individually 06:38:20 mt: that's one way to model it 06:40:11 hta2: one complication of getUserMedia is that devices come and go 06:40:35 jyasskin: api can expose list of present devices which is a subset of those granted 06:40:57 mt: subset of all devices ever known, superset of those available as it may return denied devices 06:41:12 jyasskin: in bluetooth we don't return devices not tranted 06:41:17 s/tranted/granted/ 06:41:46 mt: only concern I see is how to present e.g. mic and camera concurrently from POV of spec 06:42:20 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 06:42:38 mt: that is one way to implement, but do you need to say anything in the spec 06:42:49 hta2: if anything, implementation guidance, people will ask about this 06:43:11 mt: what if you've got a prompt in front of someone and geolocation is asked for? do you consolidate or show another one? 06:44:39 jyasskin: thoughts on powerful features? 06:44:59 mt: would avoid that term, use something value neutral; maybe talk about resources that require permissions? 06:45:20 hta2: resource works, capability works for me to; vague enough to mean anything 06:46:14 raymes: feature? 06:46:34 hta2: feature doesn't work, if I have 2 cameras, both are not features; camera is the feature 06:46:56 jyasskin: camera is the feature, you grant access to a specific device; same with bluetooth 06:47:09 mt: how would you model file upload with this spec? 06:47:22 jyasskin: file is a resource, picker grants you access to contents once 06:49:02 IP addresses need to be modeled as a resource/feature/capability. 06:49:12 hta: access to IP addresses in WebRTC specifically 06:49:36 My point was that #97 allows us to weasel things nicely 06:49:47 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. 06:49:53 TOPIC: request & revoke 06:50:21 mt: maybe issue 83 is summary of issue? 06:51:27 https://github.com/w3c/permissions/issues/83 06:51:44 jyasskin comment on Apr 27 (Pro / Con) 06:52:14 mt: for new APIs we can have consistent spelling, but not particularly compelling 06:52:33 raymes: I lean towards not including these; people who want these the most aren't here 06:52:43 ... need to give people like mounir space to comment 06:53:01 ... other con I see is that it is unclear what features require permissions up front and can change over time 06:53:14 ... we've seen that with fullscreen, used to require permission, now doesn't in chrome 06:53:29 ... more transparent we can be between something being permission gated and not makes that evolution easier 06:53:56 jyasskin: I think query covers things that might require permission, but not everything needs a revoke API 06:54:11 raymes: finding a way to provide consistency across APIs is good 06:54:28 jyasskin: could have a guideline for API shapes wouldn't be a requirement on UAs but be guidance for spec writers 06:54:54 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 06:55:11 jyasskin: could incorporate Alex Russel's document of complaints about geolocation 06:55:26 mt: geolocation was built in the dark ages and would be an easy one to fix 06:55:59 ... 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 06:56:06 ... don't know how to solve the problem 06:56:34 jyasskin: one fundamental disagreement between requesting by using feature first time or providing ability to ask permission whenever to use later 06:56:55 mt: both are reasonable positions, need those people in the room 06:57:04 jyasskin: can emulate either with the other most of the time 06:57:13 ... becomes a matter of taste 06:59:02 jyasskin: think I have good direction for basic structure of spec, request/revoke needs input from other people not on this call 06:59:06 ... will post a PR once that's cleaned up 06:59:22 mt: think you can close 95/96, should merge 97 and we can iterate on the rest of it 06:59:40 mt: will merge it 06:59:48 rrsagent, make minutes 06:59:48 I have made the request to generate http://www.w3.org/2016/06/08-webappsec-minutes.html bhill2 06:59:54 rrsagent, set logs public 07:53:24 bblfish has joined #webappsec 08:28:35 Zakim has left #webappsec 11:52:21 yoav has joined #webappsec 12:03:49 bblfish has joined #webappsec 12:51:50 bblfish has joined #webappsec 13:16:57 yoav has joined #webappsec 15:12:10 yoav has joined #webappsec 16:06:40 yoav has joined #webappsec 16:27:22 bhill2 has joined #webappsec 16:27:47 bhill2 has joined #webappsec 16:37:51 yoav has joined #webappsec 17:50:20 yoav has joined #webappsec 18:01:36 yoav has joined #webappsec 18:12:23 yoav has joined #webappsec 18:36:29 bblfish has joined #webappsec 18:47:34 francois has joined #webappsec 18:51:27 bblfish_ has joined #webappsec 19:15:14 yoav has joined #webappsec 19:24:14 hta3 has joined #webappsec 21:30:02 bblfish has joined #webappsec 21:30:06 bblfish_ has joined #webappsec 21:30:19 yoav has joined #webappsec 21:53:10 yoav_ has joined #webappsec 22:14:23 yoav has joined #webappsec 23:15:10 yoav has joined #webappsec