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