13:35:48 <RRSAgent> RRSAgent has joined #mediacap
13:35:48 <RRSAgent> logging to http://www.w3.org/2013/02/05-mediacap-irc
13:35:50 <trackbot> RRSAgent, make logs public
13:35:50 <Zakim> Zakim has joined #mediacap
13:35:52 <trackbot> Zakim, this will be MCAP
13:35:52 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:35:53 <trackbot> Meeting: Media Capture Task Force Teleconference
13:35:53 <trackbot> Date: 05 February 2013
13:36:09 <dom> s/Teleconference/F2F Meeting/
13:36:19 <dom> Chair: hta, stefanh
13:39:41 <ekr> ekr has joined #mediacap
13:39:48 <ekr> zakim: who is here?
13:39:50 <JonLennox> JonLennox has joined #mediacap
13:39:50 <dom> ScribeNick: ekr
13:39:55 <hta> hta has joined #mediacap
13:40:16 <dom> Agenda: http://www.w3.org/wiki/Feb_5-6_2013
13:40:19 <ekr> martin: proposes slides...
13:40:32 <stefanh> Martin's slides: http://www.w3.org/wiki/images/7/7f/Device_Enumeration.pdf
13:40:34 <dom> -> http://www.w3.org/wiki/images/7/7f/Device_Enumeration.pdf Device Enumeration presentation
13:41:32 <ekr> requirement: two different sites get different identifiers
13:41:57 <stefanh> ekr:: what's wrong with numbers?
13:42:10 <dom> ekr: what's wrong with just numbers?
13:43:29 <dom> burn: they can't have the same meaning across sites
13:43:45 <adambe> adambe has joined #mediacap
13:43:49 <dom> [several]: they may be the same, but there is no guarantee they are
13:44:17 <dom> burn: it's important that browsers don't implement it in the way that in practice, people can rely on it
13:44:47 <ekr> martin: monotonically increasing is a management exercise per browser.
13:45:10 <ekr> juberti: this is all without any permissions. a site can find out how many audio and video devices you have?
13:45:11 <Ted_Hardie> Ted_Hardie has joined #mediacap
13:45:17 <ekr> martin: yes
13:45:45 <ekr> martin: are people comfortable with the privacy properties and is this a valuable function?
13:46:08 <dan_romascanu> dan_romascanu has joined #mediacap
13:46:13 <ekr> fluffy: this is the right thing to do, but I think you also need to be able to ask for a human-readable string that might be used to identify the device.
13:46:29 <ekr> fluffy: this adds fingerprinting surface.
13:46:42 <fjh> fjh has joined #mediacap
13:46:56 <ekr> martin: privacy-preserving option would be to make this available to the site only after granting consent.
13:47:36 <ekr> fluffy: is thete a way to get permission to all cameras?
13:47:41 <Ted_Hardie> fluffy: is there some easy way to ask:  I want permission for all cameras?
13:48:01 <Ted_Hardie> Dan: I don't think that's necessary cullen.  The browser is the one who actually knows.
13:48:11 <wonsuk_> wonsuk_ has joined #mediacap
13:48:18 <Ted_Hardie> Dan: the application requests a source id; the browser has the opportunity to name it to the user.
13:48:39 <Ted_Hardie> Dan: one of the values became clear to me at WEBRTC expo.  A user asked about setting up medical devices.
13:49:05 <Ted_Hardie> Dan:  The nurses won't know about this, and this would provide them the right info.
13:49:34 <Ted_Hardie> Justin: is this the right approach?  Hey the browser should have a way to know and expose this (the user selects in the browsers)
13:49:46 <Ted_Hardie> Martin: this is a poor user experience.
13:49:54 <Ted_Hardie> Justin:  do you have a use case in mind?
13:50:10 <Ted_Hardie> Justin:  We need to have a strong use case that justifies this.
13:50:25 <Ted_Hardie> Dan: This is a constraint—if it is not satisfied, then it goes back to the default.
13:51:02 <Ted_Hardie> Justin:  We need to have a strong use case that justifies this if we are going to do this work; if
13:51:06 <Ted_Hardie> Room:  HAAAH
13:51:16 <Ted_Hardie> (Speaker excitement)
13:51:21 <Ted_Hardie> Justin:  I get the hint.
13:52:12 <Ted_Hardie> ekr: first of all, I can't tell you how much I despise every new (mumble) gets a new name.
13:52:28 <Ted_Hardie> We can't have a smellovision constraint.
13:53:20 <Ted_Hardie> fluffy:  the current API does have a method for getting all the types.  There is another "tell me about everything" intended here.
13:53:25 <Ted_Hardie> room:  can you clarify, ekr?
13:53:38 <DanD_> DanD_ has joined #mediacap
13:53:56 <Ted_Hardie> ekr:  I hate that we enumerate only audio and video and those separately.  If we come up with something new, like smellovision, testing for it using this system will be painful.
13:54:03 <burn> burn has joined #mediacap
13:54:50 <Ted_Hardie> ekr:  I do think this functionality is needed.  Desktop applications do provide "select camera" functionality.  We don't want to go out to OS or browser to get a preference dialog.
13:55:01 <Ted_Hardie> Martin: to be clear about interrogation: after the consent only.
13:55:16 <Ted_Hardie> ekr: fluffy suggested something different
13:55:33 <richt_> richt_ has joined #mediacap
13:55:44 <fjh> +1 to ekr re ability to control which device from application for usability;
13:55:58 <ekr> abr: is this functionality we need? I would be unhappy if I always have to select the camera on web sites.
13:56:36 <ekr> jesup: certain applications are interested in different devices. you don't want to have to flip the browser or OS default whenever you switch applications.
13:57:15 <ekr> giri: unclear how you implement the unique ids.
13:57:31 <fischman> fischman has joined #mediacap
13:57:44 <ekr> martin: plan was to run the GUID through a hash in order to generate the site-specific mappings
13:58:27 <ekr> martin: one global browser secret.
13:58:35 <ekr> giri: how does the user clear out the mapping.
13:59:09 <ekr> martin: when you clear cookies.
13:59:09 <ekr> giri: native apps? looks like an uninstall/deletion event.
13:59:58 <ekr> fluffy: in the name of protecting privacy, we have constructed a situation where every app will ask for full permission.
13:59:58 <ekr> ... this is what happens if we don't give you any access before full permissions.
14:00:12 <ekr> martin: I don't have any research on that.
14:00:34 <dom> dom has joined #mediacap
14:00:48 <dom> RRSAgent, draft minutes
14:00:48 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/05-mediacap-minutes.html dom
14:01:22 <ekr> hirsch: this is like cookies? [yes]. What about correlation across sessions and across users.
14:01:30 <JonLennox> JonLennox has joined #mediacap
14:01:34 <dom> [re use case of device enumeration, it seems to me that Google Hangout exposes available devices in its UI for the user to select FWIW]
14:02:05 <ekr> ... needs to be more details in the doc.
14:02:29 <ekr> juberti: the proposal is that initially you can only get ids, but then once you have permission for a device you can interrogate its properties.
14:02:54 <ekr> ... what about access to the names of the other devices.
14:03:14 <ekr> ... the microphone about camera and microphone seems more sensitive
14:04:00 <ekr> ... this seems like the right compromise
14:04:24 <ekr> barnett: what if the user could pass in a usable string...
14:04:38 <gmandyam> gmandyam has joined #mediacap
14:04:39 <fjh> medical device case makes it clear that privacy risks and mediations need to be enumerated
14:05:12 <fjh> apart from fingerprinting knowledge of names of devices seems benign, or am I missing something?
14:05:14 <ekr> clarification on the proposal: the app gets to provide a string that the user can use to choose.
14:05:37 <ekr> ekr: users ignore all the information in the choosers
14:05:45 <ekr> jesup: app can explain anything it wants outside of the picker.
14:05:46 <adambe> adambe has joined #mediacap
14:07:06 <fluffy> "Bad guys would use this for more than the good guys" - Martin
14:08:11 <ekr> ekr: so new devices that were conceptually like cameras and microphones would be interrogated this way
14:08:26 <ekr> juberti: once you had permissions you could ask for anything?
14:08:53 <Dan_Druta> Dan_Druta has joined #mediacap
14:09:18 <Josh_Soref> RRSAgent, pointer
14:09:18 <RRSAgent> See http://www.w3.org/2013/02/05-mediacap-irc#T14-09-18
14:09:44 <ekr> fluffy: trying to make certain we leave with a decision
14:10:09 <ekr> ... You can get all the device IDs and then they are stable.
14:10:13 <Josh_Soref> s/zakim: who is here?/zakim, who is here?/
14:10:17 <dom> [not so much "site" as much as "origin"]
14:10:19 <ekr> .... Once you have the device IDs you can ask for type.
14:10:42 <ekr> ... Given a device ID, you can ask for the device subsequently
14:11:08 <Josh_Soref> s/..../.../
14:11:15 <ekr> juberti: so how do I make the picker? Given that I don't have access to other devices
14:11:45 <Ted_Hardie> fluffy:  how much other information are we now providing without consent?
14:12:03 <Ted_Hardie> Justin:  Do we return this information off what we get from this or from getDevices?
14:12:25 <Ted_Hardie> ekr:  one thing people talk about is allowing the javascript to ask for camera and mic, but in a restricted domain.
14:13:25 <Josh_Soref> RRSAgent, draft minutes
14:13:25 <RRSAgent> I have made the request to generate http://www.w3.org/2013/02/05-mediacap-minutes.html Josh_Soref
14:13:48 <Ted_Hardie> ekr:  This is bound to a different domain, so it can't be seen by the javascript.  I think we need to be clear whether we believe giving people access to one camera gives access to all of them or whether we can let them see what the camera sees without "getting access to it", so we can build this picker.
14:13:49 <ekr> to clarify my statement at the microphone, you would probably need to have that request not require a permission grant.
14:16:24 <gmandyam> +q
14:16:44 <ekr> ted_hardie: mobile cameras often point in different directions.
14:16:53 <dom> [I think the first requirement for a good proposal is to be an actual proposal :) ]
14:17:19 <ekr> fluffy: need to be able to grant access to some cameras and not others. don't want to get dialogs for each camera.
14:18:14 <Milan_Patel> Milan_Patel has joined #mediacap
14:18:27 <ekr> paulk: is it possible to have two levels of permission?
14:19:02 <Josh_Soref> s/+q/q+/g
14:19:25 <JeromeMarcon> JeromeMarcon has joined #mediacap
14:19:26 <ekr> giri: are we considering changing the requirements to potentially accomodate this proposal
14:19:40 <ekr> harald: the chairs don't think this is inconsistent with the requirement
14:20:01 <ekr> giri: it seems inconsistent to me.
14:20:17 <ekr> hta: we discussed this at the last meeting. the number of devices isn't sensitive
14:20:59 <ekr> juberti: you probably want some sort of callback if the list of devices changes.
14:21:15 <ekr> martin: polling?
14:21:50 <ekr> juberti: what's the rationale for not exposing a callback?
14:22:22 <ekr> Josh_Soref: do you have WebIDL for this API
14:22:28 <ekr> ... is it mutable or fixed?
14:22:36 <ekr> hta: closes mic
14:22:57 <gmandyam> From Giri:  the requirement P5 in the use cases and requirements doc will not allow for human-readable descriptions of devices not available to the user, but Martin's proposal does not cover this feature
14:22:58 <ekr> fluffy: when do permissions get re-asked? if someone says no....
14:23:11 <ekr> Josh_Soref: can't this be an implementation detail.
14:23:42 <martin__> martin__ has joined #mediacap
14:25:30 <Ted_Hardie> speaker:  you can have a "re-insertion" type event that makes a new device that looks remarkably similar to one that was previously excluded.
14:25:32 <ekr> ekr has joined #mediacap
14:26:02 <dan_romascanu> we hear 80% of the speakers
14:26:06 <Josh_Soref> topic: Error Handling
14:26:18 <burn> scribenick: burn
14:26:21 <Ted_Hardie> speaker: that allows you to get past the "accidentally no means forever no"
14:26:39 <timeless> timeless has joined #mediacap
14:26:44 <timeless> scribe: Josh_Soref
14:26:47 <timeless> scribenick: timeless
14:26:55 <timeless> hta: define some terms for Error Handling
14:27:00 <timeless> ... there are two things we can call Errors
14:27:06 <timeless> ... application asks API to do somehting
14:27:12 <timeless> ... what it does succeeds or fails
14:27:18 <timeless> ... the other thing is "oops, something went wrong"
14:27:27 <timeless> s/somehting/something/
14:27:32 <timeless> ... i'm not talking about the last category
14:27:39 <timeless> ... that's obviously going to be a callback/event thing
14:27:45 <martin___> martin___ has joined #mediacap
14:27:47 <timeless> ... i'm focusing on the Application asks the Browser to do something
14:27:50 <timeless> ... and it goes wrong
14:27:53 <timeless> ... currently, in the API,
14:27:58 <timeless> ... there's a function called
14:28:06 <timeless> ... you know exactly one and only one thing will happen
14:28:14 <timeless> ... you get thrown an exception (e.g. illegal argument)
14:28:20 <timeless> ... you get a success callback
14:28:23 <timeless> ... or you get an error callback
14:28:26 <timeless> [ Next slide ]
14:28:30 <timeless> [ Current language ]
14:28:45 <timeless> hta: this is what's in the spec atm
14:28:54 <timeless> ... i'm not all happy with the language of the spec
14:28:56 <timeless> ... i'ts more or less
14:29:01 <timeless> s/i'ts/it's/
14:29:06 <timeless> ... saying what i want to say
14:29:15 <timeless> stefanh: is this WebRTC or MC?
14:29:20 <timeless> hta: this is WebRTC
14:29:47 <timeless> burn: we decided these are not the only conditions under which an exception can be thrown
14:29:52 <timeless> ... i need to look up the specific wording
14:29:59 <timeless> hta: if you parse it as logical statement
14:30:13 <timeless> ... that one [points to something] is not what we want
14:30:17 <timeless> ... we also decided
14:30:22 <timeless> ... error identifiers are strings, not numbers
14:30:29 <timeless> [ Next slide ]
14:30:38 <timeless> [ Desirable properties not found yet ]
14:30:42 <timeless> hta: when we have illegal params
14:30:50 <timeless> ... we should have exactly the same behavior as any other API
14:30:58 <timeless> ... what compilers do... it's specified in WebIDL
14:31:05 <timeless> ... i forget what those errors are
14:31:11 <timeless> ... it should be easy for an application to predict
14:31:20 <timeless> ... if i do this mistake, and if i do that mistake, i get an error callback
14:31:29 <timeless> ... browsers should be reasonably consistent
14:31:32 <timeless> [ Next slide ]
14:31:32 <martin__> consistency is a crutch for the weak-minded
14:31:36 <timeless> [ Alternative API structure ]
14:31:49 <timeless> hta: alternatively, you make a call, and return an object
14:31:59 <timeless> ... and then success/failure is available from the returned object
14:32:08 <timeless> ... indexeddb is doing this
14:32:18 <timeless> ... whereas we're doing what geolocation does
14:32:24 <timeless> burn: from the January call
14:32:39 <timeless> ... programming errors are thrown exceptions
14:32:43 <timeless> ... others are error callbacks
14:32:45 <timeless> ekr: +1
14:32:53 <timeless> [ Next slide ]
14:32:59 <timeless> s/ekr/martin/
14:33:07 <martin__> that was +1 to Justin doing more work
14:33:11 <timeless> [ Emulating "alternative" in JavaScript ]
14:33:29 <timeless> [ slide shows it's relatively easy to convert from one style to the other ]
14:33:33 <timeless> [ Next slide ]
14:33:38 <timeless> [ Evaluating this change proposal ]
14:33:49 <timeless> hta: there's no clear advantage
14:33:56 <timeless> ... developers will have to deal w/ both patterns anyway
14:34:02 <timeless> ... library developers can mask one with the other
14:34:07 <timeless> ... changing stuff is disruptive
14:34:12 <timeless> ... proposed: No Change
14:34:31 <timeless> stefanh: you're talking about getUserMedia ?
14:34:37 <timeless> hta: i'm talking about getUserMedia and also
14:34:44 <timeless> ... AddStream, AddTrack, GetStats
14:34:51 <timeless> stefanh: that's for the other group
14:35:02 <timeless> hta: having the two groups being consistent would be a "bad" idea
14:35:08 <Markus_Isomaki_> Markus_Isomaki_ has joined #mediacap
14:35:08 <timeless> ... there's reasonable overlap between the two groups
14:35:20 <timeless> ... i'd like to see if there are comments on this proposal (no change)
14:35:34 <timeless> ekr: this is just on promises v. errors
14:35:37 <timeless> hta: yes
14:35:42 <timeless> ekr: i support this decision
14:35:45 <timeless> ... i see no benefit
14:36:03 <timeless> ... are we proposing to continue w/ success+error callbacks for all calls?
14:36:09 <timeless> hta: i think so
14:36:16 <timeless> ... it's trivial to ...
14:36:29 <timeless> ... we'd like people to be unwise explicitly
14:36:45 <martin__> adam.roach speaking
14:36:51 <richt> richt has joined #mediacap
14:36:53 <timeless> adam.roach: [ something ]
14:37:12 <timeless> adambe: A style or Session style ?
14:37:25 <timeless> ... we can't force people to ...
14:37:38 <timeless> ... we can't run a call without an error callback
14:37:40 <timeless> ekr: you could
14:37:48 <martin__> adambe: looking at error callbacks against promises - it's impossible to force the setting of error handlers on a promise
14:37:49 <timeless> gmandyam: dom exceptions, they're defined
14:37:53 <timeless> .... in the html 5 spec
14:38:37 <timeless> dom: webapps group is asking that if you want new types/errors, you should coordinate with them
14:39:21 <timeless> ... once we know what we want, we need to communicate with them
14:39:40 <timeless> jim: we define an object
14:39:51 <timeless> ... where values are only valid during the scope of the error
14:40:00 <timeless> ... there are async errors, like OOM
14:40:11 <timeless> ... which is from global
14:40:20 <timeless> hta: errors i'm not talking about are a different topic
14:40:22 <timeless> [ Next slide ]
14:40:26 <timeless> [ New API points - design ]
14:40:30 <timeless> hta: from previous discussion
14:40:47 <timeless> ... there's no chance of getting consensus in the room to change the api
14:40:57 <timeless> ... we add GetStats(), Recorder
14:41:05 <timeless> ... we should have a principled decision for these
14:41:09 <timeless> ... use Callbacks
14:41:12 <timeless> ... use Status objects
14:41:18 <timeless> ... "no consistency needed"
14:41:23 <timeless> ... i'd like a decision on this
14:41:42 <timeless> cullen: i'd like consistency with callbacks
14:41:45 <timeless> ... for peer connection
14:41:48 <burn> +1
14:41:52 <timeless> martin__: i like disagreeing w/ cullen
14:41:57 <timeless> ... consistency is a clear sign of a weak mind
14:42:02 <timeless> ... be as inconsistent as possible
14:42:04 <timeless> ... invent something new
14:42:07 <timeless> [ laughter ]
14:42:25 <timeless> dom: question about consistency is defining scope
14:42:36 <timeless> .... i don't know that every other WG is agreeing w/ status object
14:42:49 <timeless> ... in one of the documents that Robin Berjon is editing
14:42:54 <timeless> ... Web API cookbook
14:42:56 <timeless> s/..../.../
14:43:08 <timeless> ... if Callbacks work for all cases, then let's keep using callbacks
14:43:16 <timeless> ... but there are cases involving extending the api
14:43:24 <timeless> martin__: what dom said is more along the lines of what i believe
14:43:31 <timeless> ... we have a narrow focus in this group
14:43:32 <dom> -> http://darobin.github.com/api-design-cookbook/#specifying-callbacks "Specifying callbacks" in Web API Design cookbook
14:43:35 <timeless> ... people doing WebRTC
14:43:39 <timeless> ... and IETF
14:43:47 <timeless> ... consistency within this narrow wedge of the web platform
14:43:50 <timeless> ... isn't that wise
14:43:59 <timeless> ... if there's good guidance, then we'd be stupid to ignore it
14:44:14 <timeless> cullen: i agree with martin__ on that
14:44:30 <timeless> hta: 0, 0, 0, and we should read another document
14:44:41 <timeless> stefanh: we have onEnded events
14:44:47 <timeless> ... and onError for recorder
14:44:52 <timeless> ... we already have a mixed model
14:45:02 <timeless> ... as long as it seems fitting, we should do callbacks
14:45:15 <timeless> hta: you ask the api and it has exactly one result
14:45:24 <timeless> ... and stuff where you ask and things just happen
14:45:36 <timeless> ... this principled decision
14:45:42 <timeless> ... we have arguments for Callback
14:45:49 <timeless> ... and we have pointers to sage advice
14:45:57 <timeless> ... if we look and aren't swayed, we don't change?
14:46:00 <timeless> [ Next slide ]
14:46:20 <timeless> hta: i always have a next slide
14:46:23 <timeless> ... oh, i deleted it
14:46:43 <timeless> jim: we need to decide on error classes/not, maybe not now
14:46:50 <timeless> martin__: dom's advice
14:46:54 <timeless> ... stuff just happens advice
14:46:57 <timeless> ... we have events
14:47:02 <timeless> ... does that work for you jim?
14:47:06 <timeless> ... we generate an event and fire it
14:47:10 <timeless> ... and everything works?
14:47:19 <timeless> jim: sounds like another group wants to control those events
14:47:25 <timeless> martin__: events we know how to define
14:47:30 <timeless> ... dom was talking about DOMError
14:47:40 <timeless> jim: i'm thinking about Error
14:47:54 <timeless> gmandyam: DOMException requires modifying the HTML5 spec
14:47:57 <timeless> ... DOMError you don't
14:48:11 <timeless> jim: you have an attribute inside an object
14:48:18 <timeless> ... it's only valid within scope
14:48:25 <timeless> ... but avoids having to coordinate with another group
14:48:38 <timeless> hta: what happens if you have 2 errors happening in quick succession?
14:48:43 <timeless> martin__: it doesn't work that way
14:48:48 <timeless> ... it's a single threaded application
14:49:00 <timeless> ... you have two events
14:49:04 <timeless> ... you generate a callback
14:49:09 <timeless> ... during the scope of that callback, it's set,
14:49:12 <timeless> ... on return, you clear
14:49:24 <timeless> ... and for the next, you set the next values for the next callback
14:49:29 <timeless> hta: i'm not understanding this
14:49:35 <timeless> ... who is you?
14:49:37 <timeless> martin__: the browser
14:49:41 <timeless> ... it queues events
14:49:58 <timeless> ... and sets values for the callback scope and clears on return
14:50:05 <timeless> jim: there's another limitation
14:50:16 <timeless> ... a bunch of our objects now have an error name and an attribute
14:50:25 <timeless> dom: the DOMError interface has a `name` attribute
14:50:35 <timeless> ... which we should reuse names that exist
14:50:40 <timeless> ... but what to do when we need new names?
14:50:49 <timeless> ... DOM4 says if you need new names, contact us
14:50:55 <timeless> ... we should maybe try the path or discuss it
14:51:05 <timeless> ... on the callback question
14:51:21 <timeless> ... are there many cases where we expect the developer will need to react to several error callbacks?
14:51:31 <timeless> hta: Recorder...
14:51:37 <timeless> ... you get Data + Ended at roughly the same time
14:51:48 <timeless> ... but only one is really an error...
14:52:10 <timeless> dom: XXX
14:52:21 <timeless> adambe: it seems there's some confusion if an attribute is an error callback
14:52:23 <timeless> ... or an error
14:52:47 <timeless> jim: the attribute is a string, the name of the error
14:52:50 <dom> s/XXX/we should be clear in our algorithms when and if there are cases where an error callback invocation doesn't end the operation
14:52:52 <timeless> ... you raise a standard DOMError
14:53:02 <timeless> ... when you process that, you read the error and see what it says
14:53:08 <timeless> ... it keeps you from defining new classes
14:53:25 <timeless> adambe: why have an error string that's overwritten?
14:53:36 <timeless> ... if you dispatch objects, you can store them in a queue
14:53:45 <timeless> jim: we could also use custom events
14:54:08 <timeless> hta: we need a presentation on that,
14:54:13 <timeless> ... but by someone who has read the specs
14:54:23 <timeless> hta: Further study on Errors that happen
14:54:30 <dom> -> https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#error-names-0 DOM4 definition of errors
14:55:52 <lgombos> lgombos has joined #mediacap
14:56:02 <martin__> ACTION: hta to come up with a concrete proposal on what to do with error classes, based on the discussion on DOMErrors/DOMEvents.
14:56:02 <trackbot> Created ACTION-14 - Come up with a concrete proposal on what to do with error classes, based on the discussion on DOMErrors/DOMEvents. [on Harald Alvestrand - due 2013-02-12].
14:56:26 <timeless> hta: i think we'll have coffee
14:56:37 <timeless> cullen: what do we change?
14:56:37 <timeless> hta: atm, nothing
14:56:54 <timeless> ... but we may eventually change every class which has Error to something maybe like DOMError
14:57:09 <timeless> [ Coffee break for 15 minutes ]
15:18:46 <richt> richt has joined #mediacap
15:19:08 <Ted_Hardie> Ted_Hardie has joined #mediacap
15:19:39 <JonLennox> JonLennox has joined #mediacap
15:20:23 <burn> burn has joined #mediacap
15:21:09 <dom> dom has joined #mediacap
15:23:01 <lgombos> lgombos has joined #mediacap
15:23:31 <timeless> topic: "immediate stream" gUM
15:23:57 <fluffy> fluffy has joined #mediacap
15:24:00 <timeless> martin__: the basic problem that came up in the WebRTC meeting
15:24:07 <timeless> ... it became difficult to make a good UX
15:24:12 <timeless> ... with gUM and PeerConnection
15:24:15 <Ted_Hardie1> Ted_Hardie1 has joined #mediacap
15:24:20 <timeless> ... the consent dialog blocked the creation of the MediaStream
15:24:23 <JonLennox> timeless — are you scribing?
15:24:30 <timeless> ... but the MediaStream was needed to negotiate the stream
15:24:34 <JonLennox> (I am happy not to)
15:24:40 <timeless> ... the idea was that we would create placeholder streams
15:24:50 <timeless> ... we went back and forth a number of ways
15:24:52 <Milan_Patel> Milan_Patel has joined #mediacap
15:24:55 <timeless> ... there were concerns about usability
15:25:05 <timeless> ... the conclusion was to create a bastard step child of the two proposals
15:25:11 <timeless> ... and merge them together
15:25:18 <timeless> ... there's an email on the list w/ WebIDL for these things
15:25:24 <timeless> ... it isn't really synchronous anymore
15:25:25 <Markus_> Markus_ has joined #mediacap
15:25:28 <timeless> ... you have the existing api
15:25:31 <timeless> ... constraints
15:25:38 <timeless> ... pass in success callback, error callback
15:25:42 <timeless> ... if you want two video streams
15:26:08 <timeless> ... you'd call this twice before relinquishing control to the browser
15:26:08 <timeless> ekr: the premise appears to be
15:26:08 <timeless> ... that i can't generate an Offer-Answer
15:26:16 <timeless> ... the appropriate SDP
15:26:18 <timeless> ... prior to having a Stream Permission grant
15:26:25 <timeless> ... because i don't know the exact characteristics
15:26:37 <timeless> ... i have no way to tell the PeerConnection what i want
15:26:48 <timeless> ... the only info that PeerConnection needs is the number of cameras
15:26:56 <timeless> ... i don't think any syntax lets it do it
15:27:02 <timeless> ... describe addressing the requirement
15:27:10 <timeless> ... regardless of syntax
15:27:17 <timeless> ... for SDP, you need more than just count
15:27:27 <timeless> martin__: there's an assumption that there's a single SDP
15:27:39 <timeless> cullen: all existing video codecs transmit Resolution in SDP
15:27:51 <timeless> martin__: you have 2 cameras and don't know what they are
15:27:57 <timeless> ekr: browser knows the cameras
15:28:00 <stefanh> stefanh has joined #mediacap
15:28:02 <timeless> ... app doesn't know anything
15:28:08 <timeless> .... user hasn't granted permission
15:28:09 <fjh> fjh has joined #mediacap
15:28:23 <timeless> martin__: you can't send resolution in SDP because you aren't supposed to reveal it before permission is granted
15:28:31 <timeless> justin: you can mask it
15:28:34 <timeless> ... send resolution in band
15:28:43 <timeless> cullen: doesn't work for any video codec
15:28:51 <timeless> ... there isn't an RFC for doing that in VP8
15:29:08 <wonsuk> wonsuk has joined #mediacap
15:29:16 <timeless> XQ: for XR
15:29:17 <timeless> ... there's XXX
15:29:17 <timeless> ... characteristics of the encoder
15:29:22 <timeless> ... the encoder implementation is probably fingerprintable
15:29:37 <JonLennox> s/XQ/JonLennox/
15:29:38 <timeless> justin: you can do a reoffer
15:29:48 <timeless> ... what need to do is get the ID in the
15:30:02 <timeless> ... and when i get authorization, i don't need to do additional signalling
15:30:09 <timeless> martin__: i'm less concerned about audio clipping
15:30:16 <timeless> ... as JonLennox points out
15:30:19 <JonLennox> JonLennox: in H.264 you negotiate profiles and levels
15:31:13 <timeless> ... it isn't possible for video to make sense of the data from camera
15:31:18 <timeless> cullen: for audio, it's just a clipping issue
15:31:18 <timeless> ... you could always send an invite that's just a data channel
15:31:18 <timeless> ... and then send an invite over the data channel
15:31:18 <timeless> ... be careful about the problems you're trying to solve here
15:32:09 <timeless> martin__: we spent a lot of time in Lyon
15:32:09 <timeless> ... we concluded on Clipped Hello
15:32:09 <timeless> ... someone answering the phone
15:32:09 <timeless> ... you wouldn't be able to do your ICE negotiation
15:32:17 <timeless> ... so once microphone is granted
15:32:17 <timeless> ... you wouldn't be able to send right away
15:32:17 <timeless> ... for Video, people expect to wait some time
15:32:17 <timeless> ekir: i think it's useful to define the problem
15:32:17 <timeless> ... for Clipped Audio Hello
15:32:17 <timeless> ... they don't require tihs
15:32:18 <timeless> martin__: no one's proposed one
15:32:26 <timeless> ekr: cullen suggested negotiating the data channel
15:32:41 <timeless> ... in the case where there are devices w/ different capabilities
15:32:47 <timeless> ... what do you expect the Browser SDP to be
15:32:54 <timeless> ... when it isn't known what the user is going to select
15:33:01 <timeless> justin: is the case that
15:33:05 <JeromeMarcon> JeromeMarcon has joined #mediacap
15:33:05 <timeless> ... the browser doesn't know what to do
15:33:08 <timeless> ... are they enumerable?
15:33:14 <timeless> ... i think they're fairly finite
15:33:20 <timeless> ekr: camera 1. H264 encoder
15:33:28 <timeless> ... camera 2, no H264 encoder
15:33:34 <timeless> ... and i don't have H264 software
15:33:43 <timeless> justin: please tell me how i'd set up that configuration
15:33:48 <timeless> cullen: you have a logitech camera
15:33:58 <timeless> justin: what percent of people will people have aftermarket camera
15:34:09 <timeless> cullen: iPad, H264 encoder for the hardware
15:34:22 <timeless> justin: the H264 there is hardware distinct from the Camera
15:34:42 <timeless> justin: depending on which camera is chosen, the offer in SDP will be different
15:34:47 <timeless> ... you could offer the best you can do
15:34:50 <Markus_> Markus_ has joined #mediacap
15:34:54 <timeless> ... and you could always go lower
15:35:06 <timeless> jesup: on the receive side, there's an issue about receiving something you can't decode
15:35:13 <timeless> ... to the main point, how we avoid clipping
15:35:20 <timeless> ... there are options
15:35:26 <timeless> ... using fake/empty streams for negotation
15:35:34 <timeless> ... if the app is asking for permission for audio/video
15:35:40 <timeless> ... you can use fake/disconnected streams
15:35:51 <timeless> ... as soon as it gets permission, it can re-swizzle the streams being fed in
15:36:00 <timeless> ... much as you would do for mute
15:36:05 <timeless> ... you wouldn't need another negotiation
15:36:13 <timeless> ... if you need it, you do, if not, you don't
15:36:22 <timeless> ... cullen's proposal of using a half-RTT
15:36:34 <timeless> ... it's a direct to the Peer, without the server
15:36:40 <timeless> martin__: that's perfectly reasonable to do
15:36:49 <timeless> jesup: do we need another solution to the same problem?
15:36:57 <timeless> martin__: that's where i was going to get into other things this potentially provides
15:37:14 <timeless> ... how you provide multiple cameras is kinda weird
15:37:19 <timeless> ... you call gUM twice
15:37:31 <timeless> ... it's possible for the browser to give you the same camera twice
15:37:37 <timeless> justin: weird, but is it inconsistent?
15:37:43 <timeless> martin__: if i want 2 cameras
15:37:49 <timeless> ... what is the obvious api to get 2 cameras?
15:37:54 <timeless> ... we don't do it that way
15:37:58 <timeless> ... you ask for a camera
15:38:02 <timeless> ... you ask for another camera
15:38:07 <timeless> ... it gives you the same camera
15:38:15 <timeless> justin: it could give you a reference counted object
15:38:19 <timeless> martin__: but you wanted two cameras
15:38:23 <timeless> ... not the same twice
15:38:29 <timeless> justin: source ids?
15:38:36 <timeless> martin__: this slide uses source ids
15:38:41 <timeless> justin: you call gUM
15:38:46 <timeless> ... you get an object back w/ ids
15:38:50 <timeless> ... you have space for tracks
15:38:58 <timeless> ... and once you get consent, you pipe in w/ media
15:39:07 <timeless> ... once media fills in, you don't need signalling
15:39:12 <timeless> ... you don't have clipping
15:39:29 <timeless> cullen: you thought that was the current spec or the proposed change?
15:39:37 <timeless> justin: i thought that was the goal
15:39:47 <timeless> martin__: there were benefits, providing the constraints to the tracks
15:39:57 <timeless> justin: you call gUM
15:40:03 <timeless> ... you don't get the stream back immediately?
15:40:07 <timeless> martin__: you make a dummy stream
15:40:21 <timeless> ... you ask gUM to fill in the stream
15:40:38 <timeless> ekr: can i pass this stream to peer connection
15:40:44 <timeless> ... prior to gUM filling it in?
15:40:55 <timeless> martin__: partially, peer connection never really works correctly
15:41:09 <timeless> hta: it's fairly normal to call something twice when you want to do something twice
15:41:25 <timeless> martin__: if you call it twice from the same context
15:41:38 <timeless> ... if you call it once, and then settimeout and call it again
15:41:43 <timeless> ... it could behavior differently
15:42:23 <timeless> hta: ok to receive audio, ok to receive video
15:42:27 <timeless> ... we can make more constraints
15:42:32 <fluffy> fluffy has joined #mediacap
15:42:32 <timeless> ... for `number of n-lines`
15:42:52 <timeless> s/n-/m=/
15:43:00 <fluffy> M- lines
15:43:02 <timeless> burn: i like this proposal
15:43:13 <timeless> ... we'll talk about settings tomorrow
15:43:19 <timeless> ... when we originally talked about how gUM worked
15:43:29 <timeless> ... if you called gUM and
15:43:34 <timeless> ... got access
15:43:39 <timeless> ... then it wasn't available for someone else to get it
15:43:44 <timeless> ... but even in that model
15:43:53 <timeless> ... MediaStreams can be created from other Streams
15:44:01 <timeless> ... that gives you multiple Tracks pointing to the same source
15:44:15 <timeless> ... i don't know if we have to allow gUM to give access to the same source
15:44:32 <timeless> ... i don't know if you need gUM to get multiple tracks pointing to the same source
15:44:47 <timeless> cullen: i think this discussion has pointed out how confusing this is if you call it multiple times
15:44:57 <timeless> ... you create a PeerConnection, add tracks to it
15:45:12 <timeless> ... it's the Create Offer that's problematic
15:45:25 <timeless> ... i don't think you can have the Offer before you bind the stream
15:45:33 <timeless> ... i think there's existing SDP that won't work that way
15:45:39 <timeless> martin__: that's another problem w/ offer-answer
15:45:45 <timeless> cullen: i understand that
15:45:58 <timeless> ekr: everything is interconnected, unfortunately
15:46:07 <timeless> ... burn pointed out you can synthesize streams from others
15:46:13 <timeless> ... points to difficulty and a way out
15:46:15 <timeless> ... tim maybe
15:46:21 <timeless> ... another way to dig myself out
15:46:25 <timeless> ... instead of rewriting gUM
15:46:31 <timeless> ... you synthesize a dummy media stream
15:46:37 <timeless> ... w/ generic audio-video tracks
15:46:44 <timeless> ... and when gUM returns, we swap those out
15:46:50 <timeless> martin__: it's kind of what this does
15:46:58 <timeless> ekr: i'm suggesting we create a fake media stream
15:47:07 <timeless> ... and those objects have no meaningful information
15:47:18 <timeless> ... the only thing you could offer what you can do in software w/ no hardware support
15:47:23 <Ted_Hardie1> Comfort-noise only audio....
15:47:25 <timeless> ... maybe you can produce an offer
15:47:27 <timeless> ... maybe you can't
15:47:40 <timeless> burn: how does attachment happen?
15:47:48 <Ted_Hardie1> Fluffy:  the peer connection would have a replace track action
15:47:49 <timeless> cullen: peerconnection would have a replace track
15:47:54 <timeless> scribe: Ted_Hardie1
15:48:10 <Ted_Hardie1> Jesup:  the original idea had the ability to take a track and construct it from other tracks and other places.
15:48:34 <Ted_Hardie1> Jesup:  we can re-use that idea.  This is similar to mute, so you don't have to have renegotiation.
15:49:01 <Ted_Hardie1> Martin:  turns out that you have to renogtiate if there is a serious change in the characteristics anyway
15:49:08 <Dan_Druta> Dan_Druta has joined #mediacap
15:49:34 <Ted_Hardie1> Paul:  apologize, because I don't follow this that well, but it seems like if you have info about the device, even if you don't have access the device, you can do what you want here.
15:50:09 <Ted_Hardie1> burn:  I was going to say that one thing that is interesting about moving this to be a replace track on a peer connection, is that the issues only show up when you're sending it to a peer.
15:50:17 <Ted_Hardie1> burn: they don't show up when you're using it locally
15:50:38 <Ted_Hardie1> burn:  those already look like a dummy track—the source and sink are local, but there isn't a clear notion of a track
15:51:11 <Ted_Hardie1> burn; we've created a virtual track, and that's convenience.  All of this trickiness comes about because we're negotiationing it over a peerconnection,
15:51:32 <Ted_Hardie1> burn: so it might be better to doing it in peer connection, not gUM
15:51:47 <Ted_Hardie1> Tim:  Jesup's suggestion was what I suggested in Lyon,
15:52:15 <ekr> ekr has joined #mediacap
15:52:16 <Ted_Hardie1> Action item: Tim Teriberry: investigate ReplaceTrack as a solution to the problem.
15:52:16 <trackbot> Error finding 'item'. You can review and register nicknames at <http://www.w3.org/2011/04/webrtc/mediacap/track/users>.
15:52:17 <stefanh> ACTION: Tim Terriberri to investigate replace track
15:52:17 <trackbot> Created ACTION-15 - Terriberri to investigate replace track [on Timothy Terriberry - due 2013-02-12].
15:53:30 <Ted_Hardie1> Martin: if you have an API that shows you all of the devices, but doesn't allow you tot turn them on, then you could negotiate in advance of the consent for turning them.
15:54:17 <Ted_Hardie1> Fluffy: instead, we're doing dummy tracks that allow you to default blank one.  Those might create fingerprinting problems.
15:54:28 <Ted_Hardie1> Martin: you do one pixel by one pixel
15:54:36 <Ted_Hardie1> Fluffy:  but then you need renogitiation.
15:54:49 <Ted_Hardie1> Martin: audio doesn't
15:55:20 <Ted_Hardie1> Justin:  what about advertising HD, but then negotiating down
15:55:34 <Ted_Hardie1> Martin: that's the other way to do it—say everything you can do, then negotiate down to what you will.
15:56:23 <Ted_Hardie1> Justin: there seem to be two different approaches here: do we want to keep bimodal functionality?  Why not just shift this to the second approach?
15:56:59 <Ted_Hardie1> Martin:  you were there in the December teleconf, where we thought of this, and we didn't return promises or streams that weren't open yet etc.
15:57:25 <Ted_Hardie1> Ekr:  Isn't this the same thing?  What if attach this a "black" stream?
15:57:45 <Ted_Hardie1> Martin: seems to be reasonable to me
15:58:02 <Ted_Hardie1> Justin:  I would prefer this be a single syntax, so we don't have two ways to do everything.
15:58:21 <Ted_Hardie1> ekr:  Large step back:  what's the problem we're trying to solve here.  Is it only media clipping?
15:58:49 <Ted_Hardie1> room:  can somebody walk through the clipping problem.
15:59:09 <Ted_Hardie1> Martin: walks through the set-up/user experience issues.
15:59:38 <Ted_Hardie1> Martin:  when the user clicks "yes, you can have the camera", that is the expectation that it is setting up the call.
16:00:22 <Ted_Hardie1> Fluffy:  send a provisional answer that marks them all receive only, that will set up the ice negotiation, then you can send the video before sending the offer.
16:00:30 <Ted_Hardie1> room:  various questions
16:00:42 <Ted_Hardie1> ekr:  this seems like a pretty heavy weight change to solve this problem.
16:00:51 <Ted_Hardie1> Martin:  I'm just the messenger
16:01:09 <Ted_Hardie1> ekr:  But I'm not the only person who thinks this isn't the most awesome thing ever.
16:01:33 <Ted_Hardie1> ekr:  If we must have a way to set up a temp stream.  I am not sold that this last syntax (fake stream plus pieces) is what we want
16:01:39 <Ted_Hardie1> Martin:  accepting proposals
16:01:46 <ekr> ekr has joined #mediacap
16:01:48 <Ted_Hardie1> ekr:  replace track would have to be mine
16:02:24 <Ted_Hardie1> Mandy:  there are some video conditions in which it is obvious that it needs to be asynchronous.  I think you're going to have a difficult time finding a method that works in all conditions.
16:02:42 <Ted_Hardie1> Mandy:  You're going to have set various constraints.
16:02:59 <Ted_Hardie1> Martin:  Note that the set constrains operates on ones that are already live
16:03:18 <dom> s/Mandy/Giri/
16:03:24 <Ted_Hardie1> Sorry, thansk.
16:03:45 <Ted_Hardie1> Giri: that is not the equivalent of set constraints?
16:03:50 <Ted_Hardie1> Martin: yes,
16:04:28 <Ted_Hardie1> Stefan:  this is both a method to solve the clipping problem and using getUserMedia with finer grained control.
16:05:25 <Ted_Hardie1> Stefan: what am I saying is that you can start sending media before you send the answer, but that won't work, because the other browser won't be able to process it.
16:05:59 <Ted_Hardie1> There can be multiple ssrcs arriving, and you have no clue what they corresponding.
16:06:21 <Ted_Hardie1> Justin: this is a PRANSWER for everything,
16:06:29 <Ted_Hardie1> Martin: common 22 (explitive)
16:07:55 <Ted_Hardie1> Justin:  why this is actually useful: you can get DTLS and ICE hot through PRANSWER—that's the critical part of why we need the IDs (to allow the remote UI to set up).  The second is we already have a complicated state machine—we have a lot of other asynchronous pieces-having this be asynchronous is going to prove interesting.  having this be synchronous makes the application writers' lives much easier.
16:08:11 <Ted_Hardie1> Fluffy:  I think there are ways of solving that track/mapping issue without breaking this.
16:09:01 <Ted_Hardie1> Fluffy:  but as a general rule of thumb, if I send early media that matches what the "dummy" thing set (two audio and one media claimed and that's what's delivered)
16:09:07 <wonsuk> wonsuk has joined #mediacap
16:09:23 <Ted_Hardie1> Martin:  we don't have a good way of ensuring that the configurations of streams and tracks on one end matches the configurations on the other end.
16:09:58 <Ted_Hardie1> Justin: you're bundling as a simple thing and you don't have a demultiplex method
16:10:21 <Ted_Hardie1> Justin: cites rtcp
16:10:31 <Ted_Hardie1> Fluffy:  but that's statistics, not media
16:11:02 <Ted_Hardie1> Justin: but we can't use them by media type without going down a long complex series of special cases.  Let's do this the easy way.
16:11:21 <Ted_Hardie1> ekr:   comment not caught
16:11:30 <ekr> ekr has joined #mediacap
16:11:41 <Ted_Hardie1> Jesup:  I think Tim's method will simplify the state machine.
16:11:59 <Ted_Hardie1> Jesup: In some of these cases when you change track, you have to renegotiate; in other cases you don't.
16:12:20 <Ted_Hardie1> Fluffy: the easy way to do this is to pull Bundle, that makes this simple
16:12:20 <gmandyam> gmandyam has joined #mediacap
16:12:36 <Ted_Hardie1> Justin:  All because you don't want to return objects synchrously
16:13:28 <fluffy> fluffy has joined #mediacap
16:13:39 <dom> [Justin's (tongue-in-cheek) question was "why don't we get rid of SDP?"]
16:13:59 <Travis> Travis has joined #mediacap
16:13:59 <Ted_Hardie1> Fluffy: no,  when you have complex negotiations with multiple streams and tracks Bundle is complex.  It may be easy now in your situation, because it will be complex ten years from now.
16:14:09 <Ted_Hardie1> Justin: let's get read of SDP
16:14:14 <Ted_Hardie1> (groans, laughs)
16:14:34 <burn> burn has joined #mediacap
16:14:56 <Ted_Hardie1> Hta:  can you repeat your comment for the minutes?
16:15:06 <Ted_Hardie1> Martin:  I need a plan.
16:16:02 <hta> The idea that each video stream needs its separate source/destination IP port pair is incompatible with the SDP of 20 years ago, it's incompatible with stuff that's practiced today, and it's just plain stupid.
16:16:10 <Ted_Hardie1> Justin:  We discarded this but we could revisit:  what if media would not flow on a media stream until there was user consent?
16:16:18 <Ted_Hardie1> ekr: that's syntactic sugar on this.
16:16:24 <hta> The question of whether audio and video can travel on the same port pair is a different question.
16:16:29 <Ted_Hardie1> ekr:  I can barely distinguish these two.
16:17:13 <Ted_Hardie1> burn:  is this a muted stream effectively?
16:17:16 <Ted_Hardie1> Martin: yes
16:17:26 <Ted_Hardie1> burn: that works well with the amended setting proposal.
16:17:52 <Ted_Hardie1> burn: you can always have things go away. no matter what you have negotiated, that can happen
16:18:05 <Ted_Hardie1> burn: the settings proposal talks about an over-constrained situation
16:18:06 <ekr> ekr has joined #mediacap
16:18:41 <Ted_Hardie1> burn: lots of things can cause this.  Instead of breaking all your track connections—you can call "muted" any track that has become over constrained.
16:18:56 <Ted_Hardie1> burn: mute anything that's wrong
16:19:32 <Ted_Hardie1> Justin: you get audio and video track, if it was negotiated but there was no video camera?  It just stays there?
16:19:59 <Ted_Hardie1> Martin, Burn:  if it's an immediate failure, you can just fail, but if you have it later, that works.
16:20:32 <Ted_Hardie1> speaker:  you didn't show the last slide with advantages of the template method.
16:21:08 <Ted_Hardie1> speaker:  I like return Media stream for some things, but I like this for other reasons.
16:21:24 <dom> s/speaker/adambe/
16:21:25 <dom> s/speaker/adambe/
16:21:33 <Ted_Hardie1> Fluffy:  I have a concrete high level proposal, but without ditching bundle.
16:22:12 <Ted_Hardie1> Fluffy: You create all of these tracks, muted; once permission is granted are unmuted.  Any that did not get permission are treated as if the "camera/device* were unplugged.
16:22:31 <Ted_Hardie1> ekr: Doesn't this create a media stream for every camera?
16:22:44 <Ted_Hardie1> Fluffy: yes, but the ones you don't use get blown away.
16:23:07 <Ted_Hardie1> Justin: I don't like having two ways to do this.
16:23:23 <Ted_Hardie1> Martin:  I want to get rid of the constraints can be imprecisely specified option
16:23:31 <Ted_Hardie1> Justin:  I did not get that
16:23:42 <Ted_Hardie1> Martin: probably Harald that wanted that.
16:24:06 <Ted_Hardie1> Justin:  I would like to see more info on the cases in the next slide.
16:24:29 <Ted_Hardie1> ekr:  I don't think what Cullen suggested fixes the problem
16:24:47 <Ted_Hardie1> ekr:  the problem is the sdp for the platonic ideal for devices I might have
16:25:02 <Ted_Hardie1> ekr: it doesn't help me to add five camers and not know which one the user is going to select
16:25:14 <Ted_Hardie1> ekr:  I am concerned that we're going to end up with replace track anyway.
16:25:30 <Ted_Hardie1> ekr:  I claim replacetrack will solve this.
16:26:16 <Ted_Hardie1> ekr:  I would like to solve this problem once—if we are going to ditch replacetrack or agree it doesn't work, I'm ok on this approach, despite its warts.  We're going to need a lot mroe clarity on how muted/black devices behave.
16:26:27 <Ted_Hardie1> ekr: (goes back a slide)
16:26:59 <Zakim> Zakim has left #mediacap
16:27:15 <Ted_Hardie1> ekr: Goes through case with dummying out the streams—you get some cases when you get full permisions, some where you get partial, some none.  Need concrete understanding for each of these
16:27:21 <Ted_Hardie1> ekr: what's the timeline on replacetrack
16:27:29 <ekr> ekr has joined #mediacap
16:28:34 <Ted_Hardie1> frederick:  not following the full set of technical issues:  privacy issues vs. clipping.  I thought what Cullen was suggesting using muting to do call set-up before media flows.  Trying to understand if that's the proposal?
16:28:40 <Ted_Hardie1> Martin: basically yes.
16:29:20 <Ted_Hardie1> Burn:  if you want different constraints for different tracks, this approach (as an alternate syntax) is going to be difficult. The combination of constraints and this is not going to work well.
16:30:01 <fjh> seems like we are combining discovery with call setup with permissions
16:30:03 <Ted_Hardie1> Burn:  I like either Justin's approach or a synchronous approach that doesn't have this issue
16:30:14 <richt_> richt_ has joined #mediacap
16:30:42 <Ted_Hardie1> Martin: the issue is that the algorithm for which camera gets which constraints is not deterministic.
16:31:10 <ekr> ekr has joined #mediacap
16:31:20 <Ted_Hardie1> Martin: this imposes the constraint you don't get the same camera in two different getUserMedia
16:31:50 <Ted_Hardie1> Burn:  You are talking about setting a constraint with source idea
16:32:00 <fjh> cullen's example had a user action both giving permission and accepting a call leading to clipping, the fundamental issue being receiver permission (as opposed to sender)?
16:32:01 <Ted_Hardie1> Burn: it's a failure of a mandatory constraint if you call it twice
16:32:21 <Ted_Hardie1> Martin:  this is a short-hand for mandatory or optional
16:32:47 <Ted_Hardie1> Burn:  But if it's optional, it will move on when the first one is busy
16:33:26 <Ted_Hardie1> Burn:  the issue is that once you get access to the source you can send them to as many sinks as you like.
16:33:28 <dom> "Subsequent calls to getUserMedia() (in this page or any other) should treat the resource that was previously allocated, as well as resources held by other applications, as busy. Resources marked as busy should not be provided as sources to the current web page, unless specified by the use" http://dev.w3.org/2011/webrtc/editor/getusermedia.html#implementation-suggestions
16:33:47 <dom> (in other words, it's not normative that two calls to getUserMedia results in two different cameras being attached)
16:33:52 <Ted_Hardie1> Fuffy:  the problem started as clipping, and I'm pretty dubious about that; then it changed to disambiguation.
16:34:17 <Ted_Hardie1> Fluffy: there are various games to solve different problems, but we need to be clear on what th eproblem really is.
16:34:46 <Ted_Hardie1> Fluffy:  in most cases that I can think of sending fake sdp won't really help.
16:35:04 <Ted_Hardie1> Fluffy: we need to be really crisp about the problem
16:35:39 <fluffy> fluffy has joined #mediacap
16:35:58 <Ted_Hardie1> Harald: next time you send this to the mailing list:  please be clear that you're requesting two video streams, because it wasn't clear to me  One thing you haven't addressed is whether the same stream that goes into getUserMedia the one that comes out?
16:36:01 <Ted_Hardie1> Martin: yes
16:36:08 <Ted_Hardie1> Harald: is it changed?
16:36:28 <Ted_Hardie1> Martin: the object attached to the tracks changes.
16:36:46 <Ted_Hardie1> Harald:  if you think of tracks being replaced by getUserMedia,
16:37:11 <Ted_Hardie1> Martin:  I don't think this proposal sees it that way: it's a pipe and now you're hooking it up to the mains.
16:37:21 <Ted_Hardie1> ekr: reads spec to mic
16:37:52 <Ted_Hardie1> Justin: reads different aspect of spec
16:38:03 <dom> "A MediaStreamTrack object represents a media source in the user agent. Several MediaStreamTrack objects can represent the same media source, e.g., when the user chooses the same camera in the UI shown by two consecutive calls to getUserMedia() ." http://dev.w3.org/2011/webrtc/editor/getusermedia.html#mediastreamtrack
16:38:04 <Ted_Hardie1> ekr: at best, this is inconsistent
16:38:12 <Ted_Hardie1> Justin: the bits I read were normative.
16:39:05 <Ted_Hardie1> One use case: mashup application.  If you set it up so that the user cannot get multiple copies of the source, then they won't be able to use them in the mashup.
16:39:22 <Ted_Hardie1> Martin: good point
16:40:09 <Ted_Hardie1> Burn: it's interesting that the spec says what you sent—when I discussed this with Anant, he added text to that section.  I am not sure where to go from that—it doesn't match.
16:40:20 <Ted_Hardie1> Stefan:  Travis in his proposal changed a bit of that
16:40:36 <Ted_Hardie1> … you would get multiple access, but it would be a read-only device etc.
16:41:20 <Ted_Hardie1> Burn:  that non-normative secution, there was a concern that we did not want to mandate how user agents would represent multiple media.
16:41:37 <Ted_Hardie1> Burn:  reads a new spec section….
16:42:00 <Ted_Hardie1> Burn:  I think the spec is at best inconsistent
16:42:09 <Ted_Hardie1> Cullen: I'm shocked!
16:42:18 <Ted_Hardie1> Cullen: but is there anything we do have consensus on?
16:42:33 <Ted_Hardie1> ekr:  I propose what we ought to be able to do, without syntax
16:43:06 <Ted_Hardie1> ekr: somehow acquire the same camera twice and alternatively get two different camers. Anyone disagrees?
16:43:34 <Ted_Hardie1> Burn:  yes:  the question is whether you send the source multiple times or re-use, sending to multiple sinks.
16:43:59 <Ted_Hardie1> Then you can set different constraints on them.
16:44:11 <Ted_Hardie1> Martin:  In the mashup, you can ask for the same source twice.
16:44:18 <Ted_Hardie1> Martin: it should be possible to do that.
16:44:45 <Ted_Hardie1> Harald:  suprisingly, that topic is relevant to our next presentation.
16:45:02 <Ted_Hardie1> Harald: it's clear that we have no consensus, but we have two action items assigned
16:45:36 <Ted_Hardie1> Tim is sending mail to the list on replace track.  Martin is going to mail to the list with the syntax for multiple cameras.  It's clear that people have more use cases in mind.
16:46:12 <Ted_Hardie1> Harald: so we better have more mail to the list, showing where it matters.
16:46:49 <Ted_Hardie1> Justin:  I thought ekr was going down a good road, trying to see what people carry about.
16:47:13 <Ted_Hardie1> Justin: f we can solve those problems, I will be happy.
16:47:22 <fjh> +1 t clarity of use cases on list
16:47:29 <fjh> s/1 t/1 to/
16:47:48 <Ted_Hardie1> Cullen: I want to see use cases before we going down the path for "dummy track" pieces.
16:48:28 <Ted_Hardie1> Martin:  this whole thing hinges on the other thing—what do you do with media arrives.  I don't know what to do with that, but it is not what Cullen is proposing.
16:49:16 <Ted_Hardie1> Burn: we got into a bunch things there.  I want to make sure we preserve the simple case of having multiple different video sources with one audio.  I want "your two video camera".
16:49:50 <timeless> scribe: Josh_Soref
16:49:55 <timeless> scribenick: timeless
16:50:06 <timeless> topic: Device reservation
16:50:21 <timeless> jesup: the presentation which only exists as of a few hours ago
16:50:28 <timeless> ... this touches on issues already discussed today
16:50:33 <timeless> ... and issues that came up in the past
16:50:34 <ekr> ekr has joined #mediacap
16:50:38 <timeless> ... they will provoke discussion
16:50:39 <burn> I said I wanted the simple (and original) use case of calling getUserMedia twice requesting video and get the user's two video cameras
16:50:43 <timeless> ... i have opinions on some of these things
16:50:46 <timeless> ... but not all of them
16:50:52 <timeless> ... i'm hoping to make progress on a few of them
16:50:56 <timeless> ... the basic things
16:51:00 <timeless> ... who gets to access a device
16:51:05 <timeless> ... who gets to modify a device
16:51:12 <timeless> ... how does it affect others who are accessing a device
16:51:16 <timeless> ... how are they notified
16:51:20 <timeless> ... how do you set up a secure call
16:51:29 <timeless> [ Slide: Who gets to access a device? ]
16:51:37 <timeless> jesup: basic possibilities for access:
16:51:40 <timeless> ... exclusive
16:51:49 <timeless> ... once one thing has a camera, nothing else can get it
16:52:08 <timeless> burn: your list of items sounds similar to my Settings proposal
16:52:23 <timeless> jesup: i'm primarily talking about multiple applications/across tabs
16:52:28 <timeless> ... our original implementation was purely exclusive
16:52:32 <timeless> ... even within a tab
16:52:36 <timeless> ... and you had to use a fake stream
16:52:44 <timeless> ... it wasn't a big deal
16:52:46 <fluffy> fluffy has joined #mediacap
16:52:47 <timeless> ... but for mashups
16:52:49 <timeless> ... it matters
16:52:57 <timeless> ... so, exclusive, either by default, or by locking it
16:53:03 <timeless> ... constraint{ mandatory }
16:53:08 <timeless> ... sharing it w/ another tab/app
16:53:14 <timeless> ... so i have it and Engadget has it as well
16:53:21 <timeless> ... the assumption is that the user has in some manner ok'd this
16:53:25 <timeless> ... sharing w/ tabs that are same origin
16:53:28 <timeless> ... mostly same time
16:53:33 <timeless> ... but in some cases, in the same origin
16:53:37 <timeless> ... shared w/ a friend app
16:53:43 <timeless> ... willing to share w/ X but not w/ anyone else
16:54:01 <timeless> ... so normally non same-origin apps could exchange a permission token to allow this other app to have access
16:54:07 <timeless> ... what do we surface to the user?
16:54:14 <timeless> ... in the current Firefox UI implementation
16:54:21 <timeless> ... the user is involved in every access/grant
16:54:27 <timeless> ... this isn't the same for Chrome
16:54:41 <timeless> ... there's an implicit decision that the user is wanting to share the device w/ multiple apps
16:54:47 <timeless> ... it's assumed they know they're sharing
16:54:53 <timeless> ... that's trickier w/ persistent permissions
16:54:58 <timeless> ... the user isn't informed directly
16:55:03 <timeless> ... the second point is speaking to that
16:55:17 <timeless> ... should there be an indication that a source is in use when they're asked
16:55:28 <timeless> ... do you need an explicit grant that it's shared?
16:55:39 <timeless> ... does an application need to know that a source it has got shared w/ someone else
16:55:45 <timeless> ... to warn the user, or to change how it's acting
16:55:52 <timeless> ... before i get to my thoughts on this
16:55:57 <timeless> ... there are UCs for these things
16:56:06 <timeless> ... I have an app that is doing Voice Commands
16:56:11 <timeless> ... it runs in the background in a tab
16:56:15 <timeless> ... and it's listening to the Mic
16:56:20 <timeless> ... and i make a phone call
16:56:27 <timeless> ... and i say "computer, please bring up my spreadsheet"
16:56:31 <timeless> ... and it acts on the command
16:56:58 <timeless> ... a real world application where sharing a stream w/ something in the background is really useful
16:56:59 <timeless> ... perhaps the user needs to give permission for that, on a onetime basis, or a permanent permission
16:57:07 <timeless> ... same for Video, if you do Video-gesture-recognition
16:57:19 <timeless> justin: are there UCs where you wouldn't want this sharing?
16:57:24 <timeless> jesup: for Secure Call
16:57:36 <timeless> ... even though you gave Voice Recognition permission
16:57:45 <timeless> ... if you're doing a Secure Call, you might not want to give it access
16:57:55 <timeless> ... my gut feeling is there are UCs for that
16:58:04 <timeless> XQ: access to the stream
16:58:08 <timeless> ... doesn't mean access to the media
16:58:13 <timeless> ... i have a screen sharing app
16:58:26 <timeless> ... and i have a tab which is getting access to pixels
16:58:30 <timeless> ... but the source of the media capture
16:58:36 <timeless> ... is the piece of the system that grabs my screen
16:58:42 <timeless> ... not the thing that grabs my camera
16:58:47 <JonLennox> Speaker is Ted Hardie, not sure what nick he uses
16:58:50 <timeless> ... we could say that there's a permission for the camera
16:59:03 <timeless> ... but it doesn't necessarily cover screen sharing
16:59:12 <timeless> s/XQ/TedHardie/
16:59:26 <timeless> jesup: Screen sharing while useful, is fraught with...
16:59:39 <timeless> TedHardie: users can hang themselves w/ someone else's rope
16:59:50 <timeless> ekr: is this Read access or Write access?
16:59:54 <Ted_Hardie> Ted_Hardie has joined #mediacap
16:59:56 <timeless> jesup: i was talking about gUM
17:00:05 <timeless> ... there's a separate slide for writes
17:00:23 <timeless> ekr: there's a reason to not allow other accessors to fight over pan/zoom
17:00:28 <timeless> jesup: we could, but we'd be sorry
17:00:37 <timeless> ekr: there are arguments for having an explicit lock down of a device
17:00:46 <timeless> ... it isn't that you couldn't have secure ...
17:00:52 <timeless> ... i think we'll need locking for write anyway
17:00:57 <timeless> ... for Secure Coms
17:01:09 <timeless> ... i'd be satisfied for the throb that blocks write to block read
17:01:16 <timeless> ... the issue about non-exclusive-read
17:01:19 <timeless> ... is about user privacy
17:01:36 <timeless> ... whether or not having access to a device allows you to find out about other sites with access to the device
17:01:41 <timeless> ... 1-XZ
17:01:52 <timeless> ... 2. if user is crazy to give access to a site they shouldn't trust
17:02:04 <timeless> ... then we can't protect them from being discovered as using a sex site
17:02:08 <timeless> ... 3-XW
17:02:21 <timeless> ... if you think you're allowed to set whitebalance/pan/tilt/zoom
17:02:29 <timeless> justin: i think we need examples to indicate there's a real threat
17:02:37 <timeless> jesup: there's certainly a privacy leak issue there
17:02:39 <ekr> ekr has joined #mediacap
17:02:47 <timeless> ... for x and time y, you're in a hangout
17:02:53 <timeless> ... those are in theory possible
17:02:57 <timeless> ... that said
17:03:18 <timeless> ... i think i've come around to the opinion that it isn't a good argument for disabling the feature
17:03:18 <timeless> ... given implicit permission
17:03:22 <timeless> ekr: as long as there's a way to lock it
17:03:41 <timeless> jesup: for a secure call, as long as there's a way to mandate
17:03:52 <timeless> JonLennox: is there an exclusive access and there are other apps on the device
17:04:10 <timeless> ... is it reasonable that the browser be expected to make the OS api call for exclusive?
17:05:24 <stefanh> josh: the UA should handle exclusivity, not the app
17:05:49 <martin__> timeless: I don't want to leak the user to be exposed into DoS based on this constraint
17:06:12 <martin__> timeless: maybe the user needs a way to specify exclusive access for a given app during the permission grant
17:07:12 <martin__> jesup: for example, a personal recording app might be used, even though you want to make a call, you might want to continue recording despite the permissions requested by the app
17:07:34 <martin__> ... even if the app requests mandatory constraints, the UA doesn't need to respect those
17:07:47 <martin__> timeless: I can live with that
17:07:59 <timeless> s/timeless:/Josh_Soref:/
17:08:01 <timeless> s/timeless:/Josh_Soref:/
17:08:02 <timeless> s/timeless:/Josh_Soref:/
17:08:07 <timeless> jesup: right now
17:08:14 <timeless> ... if user gives permission to a second app
17:08:17 <timeless> ... we let them access it
17:08:25 <timeless> ... that gets more interesting with persistent permissions
17:08:36 <timeless> ... locking with exclusive
17:08:45 <timeless> ... pure exclusive seems overly-restrictive
17:08:52 <timeless> ... an alternative is to default to exclusive
17:09:01 <ekr> ekr has joined #mediacap
17:09:03 <timeless> ... but permissive, if the app/user says so
17:09:22 <timeless> ... i suspect you get better utility out of default-permissive
17:09:35 <timeless> ... the apps interested in mandatory exclusive are a small subset
17:09:40 <timeless> ... but you could go the other way around
17:09:49 <timeless> ... as permission doubles as selection in Firefox
17:09:59 <timeless> ... same origin doesn't matter to us
17:10:06 <timeless> ... once we get persistent, we'll need a better solution
17:10:15 <timeless> ... lastly, if i have access to a device, and someone starts sharing it
17:10:22 <timeless> ... does my app know that it's being shared?
17:10:31 <timeless> ... to indicate to the other person that it's being shared w/ someone else
17:10:37 <timeless> ... i'm not certain about this
17:10:45 <timeless> ... the mechanism is simpler than what you do w/ it and why
17:10:50 <timeless> ... an event perhaps
17:10:56 <timeless> [ Who gets to modify a shared device? ]
17:11:05 <timeless> jesup: First user, everyone?
17:11:07 <timeless> ... [random]
17:11:13 <timeless> ... first asks to lock down access?
17:11:29 <timeless> ... there are probably arguments for only one app being able to modify a device
17:11:31 <richt> richt has joined #mediacap
17:11:32 <timeless> ... gets tricky
17:11:39 <timeless> ... my example of the background voice commands
17:11:45 <timeless> ... has very little interest in modifying
17:11:49 <timeless> ... but it's likely the first opener
17:11:58 <timeless> ... so it'd need to be able to specify disinterest in modifying the device
17:12:06 <timeless> ... or a way for multiple to be able to modify
17:12:14 <timeless> ... can you lock a param, e.g. 30fps
17:12:21 <timeless> ... a subset of reader-writer issue
17:12:27 <timeless> ... is it per item or the whole stream
17:12:35 <timeless> ... i don't think that complexity is worthwhile
17:12:41 <timeless> stefanh: do you have a proposed api?
17:12:49 <timeless> jesup: i don't think it's worthwhile
17:12:52 <timeless> ... so no api
17:13:08 <timeless> ... i defer to travis's discussions
17:13:20 <timeless> ekr: there's got to be a way to ask for exclusive access to pan/tilt/zoom
17:13:29 <timeless> ... i'm aware someone asked for access, but ignore him
17:13:36 <timeless> jesup: at least a lock, or an exclusive writer
17:13:44 <timeless> ekr: anything manipulable on this device
17:13:53 <timeless> ... i have write, and anyone can share read
17:14:00 <Travis> I think one interesting part of this discussion is being able to manage the exclusivity of a source.
17:14:03 <timeless> ... i could imagine living with a setting where there's a way
17:14:09 <timeless> ... for the other guy to steal the lock
17:14:26 <timeless> ... but i don't know how to have shared devices and have fights over writes
17:14:35 <timeless> jesup: that could be resolved culturally
17:14:39 <timeless> martin__: in the settings proposal
17:14:45 <timeless> ... you ask for a track w/ pan/tilt/zoom constraint
17:14:50 <timeless> ekr: i'm going to move them around
17:14:57 <timeless> ... you don't set a range, you set a value
17:15:04 <timeless> s/.../martin__:/
17:15:14 <timeless> ... if someone else sets a constraint, they'll be told they can't change it
17:15:21 <timeless> ekr: but that's exclusive writer
17:15:32 <timeless> martin__: that's my understanding of the settings proposals
17:15:36 <timeless> s/proposals/proposal/
17:15:45 <timeless> ... you set pan/tilt/zoom for the source
17:15:54 <timeless> ... and it's incompatible w/ anyone else setting values
17:15:59 <timeless> jesup: for pan/tilt/zoom
17:16:10 <timeless> ... i can see plenty of cases where multiple people want to have access to control something
17:16:11 <jeromemarcon> jeromemarcon has joined #mediacap
17:16:15 <timeless> ... in a shared control situtation
17:16:25 <timeless> ... it isn't smart to be able to control at the same time
17:16:39 <timeless> martin__: exclusive for the first guy to set a property
17:16:47 <timeless> jim: can you get deadlocks?
17:16:56 <timeless> ... there's a track or device detail
17:17:02 <wonsuk> wonsuk has joined #mediacap
17:17:08 <timeless> burn: that's why i asked about within an app or across apps/tabs
17:17:12 <timeless> ... solutions may be different
17:17:20 <timeless> ... settings has ways for within an app
17:17:27 <timeless> ... on what you do for a track which is shared
17:17:36 <timeless> ... we can talk about that tomorrow
17:17:41 <timeless> jesup: i'd like to focus on between apps
17:18:04 <timeless> Ted: i wonder about a way to give up exclusive access
17:18:11 <timeless> ... you set pan/tilt/zoom
17:18:14 <timeless> ... from a remote location
17:18:18 <timeless> ... but allow people to change it
17:18:23 <Travis> +1 This resonates with me...
17:18:26 <timeless> jesup: multiple rooms dialed in
17:18:29 <timeless> ... you set a value
17:18:33 <timeless> ... but let the room change it
17:18:43 <timeless> s/Ted/TedHardie/
17:18:46 <martin__> which resonates with you specifically travis?
17:18:48 <timeless> TedHardie: does that work for you?
17:19:00 <timeless> jim: you could have a way to decide to allow it?
17:19:07 <timeless> jesup: you get to an area of diminishing returns
17:19:11 <Travis> Exclusive by default w/option to give up your rights...
17:19:18 <timeless> TedHardie: if you have the ability to give it up, seems enough
17:19:24 <martin__> Yeah, that's sounding good to me.
17:19:27 <timeless> jim: do you get notified if it's changed if you give it up?
17:19:28 <timeless> TedHardie: no
17:19:34 <timeless> ... you notice the video looks different
17:19:48 <timeless> EE: pan/tilt/zoom isn't how it actually works
17:20:03 <timeless> s/EE/JonLennox/
17:20:09 <timeless> [ Security and Trust Model ]
17:20:20 <timeless> jesup: this maps to the whole sharing thing
17:20:26 <timeless> ... by default an app gets access to bits
17:20:33 <timeless> ... if you don't trust the app, it can send them anywhere
17:20:41 <timeless> ... not directly related to what we just talked about, but indirectly
17:20:45 <timeless> ... a local photobooth app
17:20:52 <timeless> ... could connect to a peerconnection and send it anywhere
17:20:56 <timeless> ... you play w/ a sample app
17:21:02 <timeless> ... and the person who wrote it could be watching you
17:21:04 <timeless> ... that's bad
17:21:10 <timeless> ... the first time it happens, it'll get in the press
17:21:15 <timeless> ... it'll be bad for all of us
17:21:19 <timeless> ... we need to think about it
17:21:23 <timeless> ... we haven't solved the problem
17:21:25 <timeless> martin__: i think we had
17:21:31 <timeless> ekr: tomorrow,
17:21:39 <timeless> ... i'll be talking about restricted access on a binary basis
17:21:53 <timeless> ... for the restricted media streams, that's covered
17:21:59 <timeless> jesup: preview for tomorrow's discussion
17:22:07 <timeless> ... but think about that for sharing media streams
17:22:14 <timeless> ... you may have to lock down streams in secure mode
17:22:17 <timeless> ... a lot of useful
17:22:23 <timeless> ... UCs may suddenly become hard
17:22:31 <timeless> ... you must trust those apps
17:22:37 <timeless> ... that they don't ship your data off
17:22:44 <timeless> ... the other option would be to constraint
17:22:48 <timeless> s/constraint/constrain/
17:22:56 <timeless> ... give access to bits, but not allow them to ship
17:23:03 <timeless> ... you could prevent them from wiring to a PeerConnection
17:23:15 <timeless> ... but they could put them into a Canvas and send them to same-origin
17:23:21 <timeless> Dan_Druta: the browser should know
17:23:25 <timeless> ... if there's a bit
17:23:31 <timeless> jesup: but it doesn't have to be an RTC session
17:23:37 <timeless> ... it could be WebSocket or XHR
17:23:44 <timeless> justin: is this a solvable problem?
17:23:57 <timeless> ... we spent time this morning talking about "easy" problems,
17:24:01 <timeless> ... and didn't make progress
17:24:39 <timeless> adambe: for a booth
17:24:50 <timeless> ... if i do funny stuff with a secure file
17:25:10 <timeless> jesup: there are existing cases of people hacking into computers and getting mics/cameras
17:25:14 <timeless> ... and using them for blackmail
17:25:23 <timeless> ... justin's right, if this isn't a solvable problem
17:25:27 <timeless> ... we should just put up warning flags
17:25:36 <timeless> justin: if you give access to the camera
17:25:47 <timeless> ... is there an expectation that the site won't upload the data to a site?
17:25:53 <timeless> jesup: right now, there's no way to block this
17:26:01 <timeless> ... there are technical ways we could do so
17:26:08 <timeless> ... via tainting and origin protection
17:26:15 <timeless> ... you could let them manipulate w/o bit access
17:26:23 <timeless> martin__: if you give bit access, you've given bit access
17:26:37 <timeless> ... if you've tainted the stream, you aren't giving bit access
17:26:46 <timeless> jesup: in that case you've given stream access but not bit access
17:26:55 <timeless> ... you could hook it up to <Video> but not <Canvas>
17:27:03 <timeless> ... this also applies to image security in browsers... mostly
17:27:14 <timeless> justin: what can you do that's interesting if you can't access the bits?
17:27:21 <timeless> gmandyam: on raw bits
17:27:26 <timeless> ... i thought this was encoded data
17:27:31 <timeless> jesup: gUM is raw-bits
17:27:42 <timeless> gmandyam: hta corrected me, there's no such thing as raw-bytes
17:27:49 <timeless> ... it's feasible to eventually get raw data
17:28:11 <timeless> ... our devices have face detection and such
17:28:19 <timeless> ... but the argument for taking it out was you could do it in JS
17:28:26 <timeless> jesup: there are other ways to
17:28:42 <timeless> ... if we revived media stream processing
17:28:45 <timeless> [ Time Check ]
17:28:59 <timeless> jesup: such that you could get access to the camera, manipulate it for face recognition
17:29:07 <timeless> ... but not give access to the bits w/in the app
17:29:12 <timeless> ... it's tricky, i agree, it's doable
17:29:15 <timeless> ... i'm not sure it'll get done
17:29:24 <timeless> ekr: we'll talk about this tomorrow
17:29:35 <timeless> ... interesting reasons for Calling/Preview apps to render or transmit
17:29:43 <timeless> ... anything more complicated will be very complicated
17:29:47 <timeless> [ Security (cont) ]
17:29:56 <timeless> jesup: leave most of this for ekr's discussion tomorrow
17:29:59 <timeless> ... enjoy lunch
17:30:05 <timeless> [ Lunch - 1 hour ]
17:30:24 <timeless> hta: we've identified needs for some degree of locking
17:30:27 <JonLennox> JonLennox has left #mediacap
17:30:51 <Travis> See ya all tomorrow!
17:35:33 <lgombos> lgombos has joined #mediacap
17:52:48 <richt_> richt_ has joined #mediacap
18:06:05 <Ted_Hardie> Ted_Hardie has joined #mediacap
18:18:56 <hta> hta has joined #mediacap
18:24:52 <Ted_Hardie> Ted_Hardie has left #mediacap
18:31:59 <dom> dom has joined #mediacap
18:36:09 <lgombos> lgombos has joined #mediacap
18:39:42 <richt> richt has joined #mediacap
18:42:50 <ekr> ekr has joined #mediacap
19:14:00 <dom> dom has joined #mediacap
19:22:00 <dom> dom has joined #mediacap
19:36:02 <dom> dom has joined #mediacap
19:47:32 <dom> dom has joined #mediacap
20:22:32 <adambe> adambe has joined #mediacap
20:36:24 <dom> dom has joined #mediacap
20:43:19 <ekr> ekr has joined #mediacap
20:48:55 <ekr> ekr has joined #mediacap
21:03:52 <ekr> ekr has joined #mediacap
21:04:07 <lgombos> lgombos has joined #mediacap
21:05:35 <hta> hta has joined #mediacap
21:09:57 <dom> dom has joined #mediacap
21:13:21 <lgombos_> lgombos_ has joined #mediacap
21:20:27 <lgombos__> lgombos__ has joined #mediacap
21:41:29 <dom> dom has joined #mediacap
21:45:11 <ekr> ekr has joined #mediacap
21:49:24 <dom> dom has joined #mediacap
22:00:55 <ekr> ekr has joined #mediacap
22:06:42 <ekr> ekr has joined #mediacap
22:09:32 <hta1> hta1 has joined #mediacap
22:15:37 <ekr> ekr has joined #mediacap
22:17:27 <dom> dom has joined #mediacap
22:54:58 <ekr> ekr has joined #mediacap