- From: Eric Rescorla <ekr@rtfm.com>
- Date: Fri, 10 Feb 2012 15:42:52 -0800
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: public-webrtc@w3.org
> ekr: As a strawman, I believe we don't need capabilities at all. Trying to avoid sounding stupider than necessary here. I don't think I claimed that I actually thought this... I'd suggest that what I was trying to say was more like "As a strawman, can we get arguments that we need capabilities at all?" -Ekr > fluffy: I believe for some of the applications I want, I want to > know if I'm getting video from the front or back video camera. > ... Let's just say my application only ran on devices with two > cameras, front and back. > ... Matthew Kaufman has brought up this example many times: you may > very regularly have a workstation in front of you with three > monitors with three webcams, and only one of those is the right one. > > anant: Taking what current web applications do today is probably not > the best, but for the second point, what is actually available is > very transient. > ... So for example, the best model is to try to do what you want, > and fail if the resources aren't available. > ... For example, Skype will let you try to start a call with no > camera, and start a configuration wizard. > > Ted_Hardie: I totally disagree. > ... Presence systems are a great example. Not only do I want to know > what I have, I want to know what the other guy has. > ... Let's face it, there are applications out there that people do > where you might actually select people to talk to based on their > current capabilities. > ... One of the things that came up was the dating up. I might be > more willing to talk to someone on a dating site if I can see they > have a video camera and it's not just typing back and forth. > ... But I do think that we have to be kind of careful about what we > think we mean. > ... There is a difference between the capabilities of the system in > which the browser finds itself, and those that will be available at > application instantiation. > ... There needs to be a way to tell what the system capapbilities > are even if they're not currently available. > ... I may gray out my camera icon if it's being used by another > application as a real-time event, but I still need to know that a > camera is present. > ... When I think of capabilities, I think of what's available on the > system, and not what's currently availalb.e > ... The question of what are the free resrouces is a different > question. > > ???: I would love to see description of the output devices, > speakers, headphones, so you can give feedback about echo problems. > > anant: One of the points you made is that capabilities is different > from what's available, but how would you deal with a webcam that's > unplugged? > ... Are you suggesting the need for events of some sort, so that > browsers can be notified when capabilities change? > ... Here's the thing, the class of applications that need that level > of detail are the ones that will want to munge around in SDP. > ... There are actually two classes of things that we're trying to do > today. > ... There are web pages and webapps. > ... For example, I think it's aboslutely silly to tell Facebook that > they can't tell how many cameras you have. They already know > everything about you. > ... While I agree that capabilities are important for building > applications, the class of applications that need that is very, very > small. > ... Mozilla and others are working on web applications as a distinct > idea, that can be installed just like installing a native > application. > > ddruta: I think you need the actual availability of resources. > > Ted_Hardie: Three unrelated points: > ... 1) Whether or not the class of applications that care about this > and the class of application that munges SDP really depends on the > level of munging. > ... The class of application that needs to know how many m-lines you > need is different from the kind that wants to know the details of > every single codec you support. > ... 2) I would be very surprised if people thought navigating to the > pokerstars website was the same experience of installing a > pokerstars app. > ... 3) The perfect is the enemy of the good. If a guy plugs a camera > in, and then needs to manually referesh the page for it to show up, > before we get a pub-sub system for events. > > <dom> (getting hardware events is not something difficult by any > measure) > > Ted_Hardie: It's great if it figures this out on its own, but it's > not a great shock to a user if he needs to tell the page about it. > ... ekr: I've got a situation with 3 monitors and cameras. I say > give me a video stream, and it gives me the wrong one. What behavior > to you proscribe for the user to get the right camera? > > anant: The proposal that we have is for the user interface to be > able to switch between cameras is something that the browser chrome > provides. > > juberti: Speaking as someone who develops an application that does > want to have its fingers in everything, Hangouts probably needs > about 1 byte of information. > ... A bit for the camera, a bit for the microphone, and some notion > of a preferred device. > ... I think anant's suggestion that the browser provides the UI for > switching cameras is fine. > > burn: It seems to me that this won't scale. > ... If you have a lot of devices, it seems to me trying to put this > in the chrome... > > anant: I think it's exactly the right place. On a Mac, you have a > system control panel that tells you what the default camera is. > > juberti: Even on Windows 7, there's no notion of a default camera. > > anant: Why do you think the browser is not the place to switch > between cameras? > > burn: If you only need one camera and one microphone, then it's > probably fine. > > juberti: I want to make a telepresence system in a box... with three > monitors and three cameras, and that doesn't work if you can only > have one camera at a time. > > burn: Right, the browser isn't the place to decide any arbitrary > mapping of devices, so you can decide which camera is camera 1, > which camera is camera 2, etc. > > anant: We could come up with another API so the browser decides > which camera shows up in a preview in a given location of the > screen. > ... We want the ability to lie. > ... Even if I do have a web cam, I may just want to stream an AVI > file. > > burn: It puts it completely under user control, what stream is being > provided. Interesting. > > juberti: I really like the idea of having this in the chrome > somewhere, because it's going to be static. > ... Even in the telepresence scenario, the need to pick the cameras > is going to be fairly low. > > adambe: In the current proposal there is a textbox for selecting a > file, in order not to lock people out of applications that require > video. > ... Another thing is, I think a quite common way to interact with > this chrome dialog is you go to a page, it acquires your media > devices, you get a UI in the chrome, and it shows a preview and VU > meters for your microphones, and you see the camera you want is not > connected, you plug it in, and it pops up.... > ... I don't know, if you need events, and if you plug in a camera > and suddenly something happens, I think that may be scary for users. > > juberti: What applications do we see working well with a > pre-recorded video file? > > adambe: Like a chat application, I could just loop something. > > juberti: I'm not compelled by this argument. > > anant: I disagree. We should absolutely let people loop files if > they want to. > > juberti: I think having capabilities bits that are meaningless... > > anant: Maybe we rename them "has webcam" instead of "has video"... > > juberti: We keep bringing up the case of plugging in a camera to go > make a call, and I think that's an antiquated notion and very much > an edge case. > > ???: If we come up with an API that says "has audio", when we get to > smell-o-vision, we're going to be screwed. > > fluffy: I want to address two different things. > ... 1) W.R.T. pluggin in webcams going away... > ... My laptop has an incredible thin camera, but on the wall back > there is one with a lot of glass. > ... I think as we move to HD, people are going to want to use > devices that provide a lot higher quality. > ... 2) I think that when you're talking about a device with a small > amount of screen real-estate, but you have an application that wants > to easily be able to switch between front & back... > ... I don't see how we're going to get browser chrome that doesn't > use up a lot of screen real-estate, but still lets you easily > switch. > > burn: There's a lot of things happening on PCs right now, but we do > need to make sure it works for small, mobile devices. > > ???: I think two bits of information for capabilities is too > restrictive. > > ???: If I have three cameras and I want to write an app that picks > the best one, am I going to have to come to the W3C to get a new > spec for that? > > jlennox: For the plugging in the device thing... the use case I > think of is, I see who's calling, and I realize I don't want the > person in the cube next to me overhearing what they're saying, and I > plug in a headset. > ... The other thing is for the multiple cameras, I'll probably be > using them both in the same browser, even if it's not the same app. > > anant: The whole fundamental of the web is that APIs are simple, so > that JS does not have to worry about what camera is the best. The > browser is in a much better position to make this decision. > > ???: You're saying to me that the only thing I can do is write for > the lowest common denominator. > > anant: Why do you think, if there are three cameras, the browser > isn't going to provide you the best one? > > ???: What if I want to do some 3D thing? > > jlennox: For front and back there is no best, it depends on what > you're doing. > > jesup: There's some other issues involving capabilities. Talking > about the login issue for Google+. What happesn when you're logged > into 3 devices on your Google ID, and one of them has a camera, one > of them has a mic, and one of them has both. > > juberti: So the whole point of having capabilities is to give the > user some idea that they're going to have a good experience. > ... If you fork the call and it goes to one device that has a > camera, and one doesn't, that's probably okay. > ... It's not perfect, but for example Google routes the call to the > device that actually has the camera. > ... It's not perfect, but it's goal is to give the user less > frustration. > > jesup: My point is that as you have more of these devices on your > hip, they'll always show the ability to do voice and video, even if > you're at your desktop which has neither. > > hta: So, channeling Jim Gettys, of all people, I think we're talking > about what is the best camera... I think, anant, that I totally > disagree with you. > ... Because if I want to answer my phone, the default video I might > want is an image that kept just to my face that doesn't show that I > didn't put on my pants, that comes from a room security camera that > was slightly processed before it get there. > ... Which links multiple applications, some of which run in a > browser and some which do not. > ... The single capability bit of, "Do I have video?" is needed. > ... But the richness of what lies behind that answer should not be > underestimated. > > ekr: I'm glad I'm not writing these things, but I think the choices > are, you want a small list of do I have a camera, do I have a mic, > or I want everything that the hardware can possibly tell me about > the device. > > dom: For any feature, you can make up a use case for it. > ... The real question is what do we lose if we give more > information? > > burn: I think the answer [to do we need capabilities] is a very > strong yes, but there is the question of what level we need. > > ???: By my count we have one of five boxes to fill in: some, all, or > none, properties: no, and properties: yes. And if it's "none", > properties doesn't make sense. > > burn: I think the answer to this is that it is worth discussing > capabilities. Because there's enough use cases that it's worth > having the discussion. > > anant: I think we can eliminate the none option. > > burn: I think you were the only one who would have said none, so if > you're saying that, then I agree with that. > > dom: I might say the none option does appeal to me, until I get a > better picture of the risk. > ... Two bits of information is not a lot, but two bits are bits. > ... 0 bits in terms of privacy is better than 2 bits. > > fluffy: I think "having video" is a lot more than 1 bit. > ... If you look at the exact time that I plug in my camera and > remove my camera, that is likely to be very unique across a large > collection of devices. > > burn: I would just ask, since this is not the IETF, if you're > prepared to formally object to more than 0 bits? > > dom: Certainly not. > > hta: I would say you have less than half an hour left. > > burn: This is the second of the major topics. > ... Of the things we'll need to think about later is, what is the > relationship between capabilties and hints? > ... And what is the complexity of that, do you need two bits? do you > need more than that? > ... I put a quote on here: "Every additional bit of user > distinguishing information brings us closer to personal > identification by sites." > ... The key question is what level and quanitity of capabilities > information can be shared? > ... In general it would be nice to know what level and quantity of > information, but we might want to consider if that depends on the > state of the call? > ... Is this before the call is accepted, whether any media streams > have been requested, after the call has been accepted? > ... And what are the kinds of permissions associated with this? > > ekr: As always we have to start with a threat model. I assume the > concern here is the creation of a super-cookie? > > burn: Yes, without you saying who you are, they figure out who you > are. > > ekr: The way the browser is strucutred now, there is ample > opportunity to do this. > ... I think that implies operating in multiple modes. If you try to > turn off cookies now, the web doesn't work. If you only turn off > 3rd-party cookies, it barely works. > > <dom> (I'm browsing with 3rd-party cookies off without that much > trouble, actually) > > ekr: Unless the user has already expressed they're willing to > undergo some pain and suffering to avoid creating a super-cookie... > ... If the guy's running Tor, then I'm all excited about ways to > prevent fingerprinting, but otherwise I think give them all the > capabilities they want. > > <dom> [16]Panopticlick > > [16] https://panopticlick.eff.org/ > > anant: I want to mention a site called Panopticlick run by the EFF. > ... When I visited it, I had 21 bits of identifying information. > Give the number of people today, you only need 33 to uniquely > identify individuals. > ... So every bit we add gets us that much closer to allowing ad > networks uniquely identifying who you are without any collusion. > > burn: When I said a cookie tells them who you are, I meant they can > distinguish you from anyone else who's visited your site. > > anant: The threat that we're trying to tackle is you exposing enough > entropy that they can uniquely identify you without sharing > information with other websites. > > ekr: Let's stipulate the browser generates a 128-bit random number > at initialization time and sends that to every website in the > universe. > ... So that allows every site to see that you've visited them over > and over again. > ... And it allows them, in coordination, to figure out that the same > person has visited multiple sites. > > anant: The risk we're trying to protect against is the guy who finds > that you are the only person who bought Smell-o-Vision from this > Walmart, which means they can tell who you are without coorindate > with any other site. > > ???: I don't see these as bits that are unique. Audio and video are > so prevalent, they don't provide much value. > > ???: Let's say there's some guy who has 16 cameras attached to his > system, that's not 16 bits. > > anant: It's bits of entropy. For example, looking at the ordering > information that fonts are returned, you can figure out what > sub-version of the operating system they're using. > ... Audio and video may not be two bits, but each time you add more > information you're getting closer to 33 bits. > > juberti: Is this 21 bits counting the user agent or not? > > anant: Yes. > > juberti: Can't you already get the OS version, browser version from > the UA already? > > jlennox: Panopticlick claims that I'm the only person who visited > their site with my list of plugins. > > burn: Yeah, some of their results seem unlikely. > > fluffy: Yeah, I took a brand new Apple with nothing installed and > that showed up as unique. > ... But you look at what they actually check, and it's like whoa... > > anant: When you're actively telling the site who you are, none of > this is relevant. > ... When you go to Facebook and log in with your real name, there's > no harm at all. > ... If there's some way in which we can tie in... that's one way we > can elevate privileges for a site. Another way is installing an app, > but just clicking on a URL should not expose this information. > > ???: This seems like an entirely generic threat to me, and I don't > see why WebRTC feels the need to take on this threat by itself. > > dom: WebRTC is not the only group facing this issue. > ... It has come up in the Device APIs WG and the WebApps WG as well. > ... I guess the thing is that everyone is quite worried about it, > and there's no general solution that is available today. > ... One piece though is that we might be uniquely identifiable by > Facebook without wanting to tell them that you own 10 monitors, etc. > ... I don't think we can simply ignore it, even if we as a group... > we'd be very likely to get last call comments on this, but even > before that from implementors... > ... That doesn't mean we shouldn't play with capabilities and > identity, but I don't think we can just ignore this problem and hope > for the best. > > ???: This slide could be, I assume, in almost any working group, if > you put a different verb in there. > > ???2: I'm totally all for privacy, but saying that you have a > browser mode that turns off capabilities... is there a problem with > that? > > anant: There is a problem with that. In our experience with Mozilla, > preferences do not matter. > ... Default preferences matter. 98% of users don't change any knob. > ... Firefox is totally extensible, so there'll be a knob to turn it > off, but we're discussing what the default is. > > ???2: People who care about privacy will turn it off. > > anant: Ordinary people don't understand the issues of privacy. So > it's our responsibility as technical people to make reasonable > decisions for them. > ... Setting sane defaults for the general population is what we're > trying to do here. > > jlennox: Fingerprinting is not the only leakage we have to worry > about here. > ... Someone mentioned wanting to know whether or not the camera was > currently in use... > ... That seems like a serious information leakage if someone could > tell when I was on a phone call. > ... Even if it's not fingerprinting, it's still behavioral tracking. > > burn: So you mean if you have two websites open, while you're using > the camera on one, the other one knows you're using it. > ... Would you be okay with having a setting in the browser that > disables that? > > jlennox: I don't change preference either. > > Matthieu: I would be worried about going to Facebook and them having > the exact model of camera I have so they can better serve me ads. > ... I do want applications that are allowed to get information that > is useful to them, but there is probably a trade-off there. > > burn: I don't know a technology yet that says only use my > information for what I want you to use it for. > > jesup: There is also the political website example... if someone can > use that information to figure out who you are, your browser can be > very dangerous to you. > > burn: People who understand that their life might be in jeopardy, > are they likely to change their defaults? > > jesup: They won't even understand why that's an issue. > > hkaplan: If you go to a sight like light-reading or related message > boards... at work I'm not allowed to post at sites like that, so of > course I use a pseudonym. > ... I know to click the button that flushes my cookies, clears my > cache... > ... But I don't want them to know that I'm the same person that logs > in as both Hadriel Kaplan and Stalker. > ... But as for the site that gets my information in order to better > target ads... that's a feature! > > burn: As for the items on the slide, I don't think we've even > addressed half of them. > ... I don't think we have a clear consensus. > > anant: I have a proposal: I think we should expose the minimum > amount of information needed to implement something as complex as > Google hangout. > ... It sounds like we need the audio bit and the video bit and an > API to allow the user to flip between sources in Chrome. > > burn: I like the idea of picking an app or set of applications, but > whether Google Hangouts should be the reference... > > juberti: I'm okay with that choice. > ... When you're talking about APIs, are you talking about internal > browser APIs, or...? > > anant: No, not even APIs, but internal browser settings. > > juberti: I agree with anant's proposal. > > Data Streams API > > burn: We're moving on. Obviously there's a lot more to discuss. > ... So we'll continue the discussion on the mailing list, and on the > conference calls as well. > > <dom> [17]WebRTC Data Streams slides > > [17] > http://www.w3.org/2011/04/webrtc/wiki/File:WebRTCDataStreamsIETF82.5.pdf > > <dom> ScribeNick: dom > > Justin: Randell talked about the wire format for data streams > yesterday > ... it raises questions about the requirements > ... the core problem we're trying to solve today is to allow to send > data for low-latency/high bandwidth needs > ... we want support for multiple channels > ... [details use cases from slides] > > ???: there is also a requirement around in-order / not-ordered > > <JonathanLennox> JonathanLennox was me > > justin: [details changes since last draft] > ... unidirectional data streams make it much easier to deal with > multiparty use cases > > ???: re unidirectional for multicast, if you want to build a full > mesh, the number of streams will have to go up with the number of > participants > > scribe: so that makes it somewhat more complicated since you have to > deal with adding/removing streams > > justin: we already do that for mediastreams > ... [datastream design slide] > ... due to unreliability and unidirectional, we don't have full > fidelity with websockets > ... but the closer we stick to them, the better > ... [datastream and mediastream slide] > ... to avoid duplicating APIs, and given their commonality, I'm > proposing a basestream class > ... only addStream need to be specialized > ... ["changes to peerconneciton" slide] > > Adam: addDataStream() need to return a DataStream object > > Stefan: since DataStreams are unidirectional, you need @@@ > > Justin: [DataStream API] > ... there is currently no bit to distinguish in-order/not-in-order > > Eric: I assume the streams are in a single SCTP connection > > Justin: yes > ... Is there a max number of channels in a single association? > > Magnus: in the order of the 64K, so probably not a pb > > Justing: [DataStream API slide] > ... MTU is set in maxMessageSize > ... [Basic Flow slide] > ... [Full Example slide] > > Magnus: the mime type needs to come after the protocol (?) > ... in the SDP example > > Harald: why have you picked on signalling these channels, instead of > relying on channel events from the implementation > > Justin: will that you give you the label? The reliability? > > Harald: it will tell you the channel number > > Justin: I have another slide on signalling vs non-signalling > ... [multiparty example slide] > ... [open issues] > ... we've had the discussion on the list for a simple method as > proposed by Stefan > ... Want to get sure that the group agrees we need the more complex > API > ... ["CC" stands for congestion control] > > ???: on congestion control, I think it would be a dramatic mistake > to use bandwidth to signal packet drops > > Justin: getting feedback on the congestion control state can help > adjust it > > Randell: feedback on available bandwidth can be used to make a > number of adjustments > ... but not sure about feedback on specific packet drop > ... but feedback on congestion control in general seems useful > > Magnus: I don't think leaky buckets is a good model for this > ... what matters is the current state being acked by the other side > > Spencer: I wouldn't mind talking about the congestion control stuff > ... application-level congestion control is really hard > ... I would encourage to think hard about how much applications > should be doing > > Magnus: the only thing you can do is to try to adapt to the > congestion > ... you can't direct congestion control itself > ... but adapt the transmitted data for instance > > @@@: moving back from congestion control to the signalling issue > > scribe: I do think it's worth considering whether or not these > channel numbers can be used > ... one thing I remember from the data APIs we discussed yesterday > is that they're very application-specific > ... they're not going to a lot of filters > ... they could go through a central muxer (?) > ... There is some thoughts to be given here; labels may have a place > ... not sure about reliable/non-reliable — I think that should be > available directly from the SDP stack > ... the only remaining bit that seems to need signalling here is the > label > ... there is some use cases I thought of where you may have a very > high volume of channels coming and going > ... e.g. if you're acting as a proxy for the other person you're > talking to > ... you may have a very high number of channels closing and opening > ... or if you're doing a backup > ... if you make it expensive to open and close connections > ... the application developers will start implementing on top of a > single connection > > Justin: it's a good thought exercise to go through to identify which > use cases wouldn't work > ... I have a specific use case in mind that is hard to solve without > labels > > @@@: the description could be done via a separate data channel > (rather than via the signalling channel) > > scribe: given that a bunch of applications wouldn't need this > > Harald: signalling, I would like to study a case - I don't > understand why you want it > ... re congestion feedback, if you've played WoW, you've heard "Lag! > Lag! Lag!" > ... not communication transport information to the application level > has been a mistake we shouldn't repeat > > Jonathan: some examples for reliable/non-reliable > ... mouse pointer: you want in-order, but not necessarily reliable > ... for file transfer, you want reliable, but doesn't need to be > in-order > > ???: [help, I missed that] > > -> > [18]http://www.w3.org/2011/04/webrtc/wiki/File:Aligned_Data_API.pdf > Aligned Data API > > [18] > http://www.w3.org/2011/04/webrtc/wiki/File:Aligned_Data_API.pdf > > <JonathanLennox> It was asking about whether push notifications > should be aligned with data channels, either in technology or in > API. Justin said he hadn't thought about it at all. > > Stefan: I drafted a proposal to offer a simplified data API aligned > with other APIs > ... [Basic Proposal slide] > ... [Changes to PeerConnection slide] > ... [postMessage() spec extract] > > Justin: would this be reliable or unreliable? > > Stefan: only reliable as a starting point > ... [examples slide] > ... based on feedback, we could add DataOptions for reliability, > priority > > Ted: it seems that you want to set this up for every PeerConnection > ... so you would create a data channel even if you don't have use > for it > ... If so, I don't think many enterprise folks would be too happy > for that > ... because you've created an encrypted channels you don't know what > it is used for > ... I'm not sure what the benefit is > > Stefan: the point is to align it with web sockets > > Ted: I don't think that's quite as motivated as it might be > > Stefan: it could be simple to change the model to make the stream > > Anant: what does it bring over web sockets? > > Stefan: it's peer-to-peer > > Anant: I think not having unreliable data is a killer > > Harald: if the IETF side concludes that it will use a protocol that > has support for multiple channels with congestion control and > optional reliability > ... it would be a shame not to take advantage of it simply for > saving specification work > ... given that need for it has been identified in the requirements > document, it seems to me we should just go ahead with it > > Stefan: it's not clear that needs have been so well identified > ... also, the most advanced tool that Web developers can use today > is Web Sockets > > @@@: My discussions with people in Mozilla who have contacts with > the Web Game writing community > > scribe: and they all want this > > <hta> @@@ = Randell Jesup > > scribe: they're very interested in not having to implement > not-reliable/reliable, multiple channels > ... they clearly need channels with different characteristics > > Stefan: I think the conclusion is quite clear that we'll go for the > DataStream proposal > ... [reads action items he noted, that will be sent later to the > list] > > Harald: for Data API, the next iteration is to integrate that in the > spec > > Justin: and once it's in the spec, we can implement it :) > > > > >
Received on Friday, 10 February 2012 23:44:01 UTC