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
06:02:18 [jyasskin]
06:02:24 [bhill2]
Meeting: Permissions Spec ad-hoc call
06:02:36 [bhill2]
bhill2 has changed the topic to:
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]
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]
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 I believe that permissions for that can extend to, 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]
... and separately, both will get denied if you deny either
06:19:36 [bhill2]
hta2: if you deny you also deny
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 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 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]
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 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]
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]
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 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