Web Real-Time Communications Working Group F2F

01 Feb 2012


See also: IRC log


Stefan, Harald
adam, anant, derf, dom


publish new WD

stefanh: the first draft is continuously updates, are there any objections to publishing the current version of the ED as a WD?

no objections noted

harald: we should push a new version of the WD when we have JSEP documented in the editor's draft

Incoming Notifications by Dan Druta

<Ted_Hardie> Just as a reminder for those used to WEBRTC methods, all the decisions from the RTCWEB meeting will need to be confirmed on the list.

DanD: there was an informal discussion around notifications at TPAC, following which I sent out a paper to the mailing list detailing the problem
... the main idea with this is to allow unsolicited notifications for incoming connection requests in WebRTC clients
... To make notifications available without user visible UI, and in a variety of different clients(and browsers)
... Presenting 2 use cases. 1) Bob uses Ringo's webrtc service on a mobile phone, calls alice and leaves a voice mail; Alice calls Bob later (and Bob, on a different webrtc-enabled client is able to receive it via a notification)

2nd use on slide, missed the transcription

DanD: Factors to consider while designing a notification system: multiple connection on battery constrained devices, web development effort to use them should be minimal, webapps working group has an API for server-sent events which could be extended
... discussing client scenarios. simplest one in which the user is available, online with the app in front (easy). second one is which the user is online and available but the app is in the background
... third one is when the user is available, but the app is closed. by available, it means the user has expressed an intent to receive incoming notificaions

<anant_> 2nd option is to use an existing solution, not particularly preferable by members in the past

3rd option is to define a notifications spec and define a basic structure for notifications

DanD: proposal is to register a URI scheme or data format (MIME) and associate the browser as the handler
... Create an API to parse this notification structure and for applications to attach themselves to certain notification events
... proposal was also sent to the webapps WG, members are requested to read it
... Could we implement the API as headless browser? No, because you would need to create a new browser for every notification service and it doesn't tie it well to the PeerConnection API
... Can we use sendMessage so that it isn't tied to the browser

opening up for questions

juberti: we have an asynchronous channel via websockets, signaling is an application provider issue. what are we trying to solve here?

DanD: Websocket solutions assume that the browser is running, not applicable to devices where the app is not running

juberti: there are already solutions to run web pages in the background, why not use that?

DanD: but those assume that the app is running on the client, which may not be true, especially on mobile?

juberti: it's what desktop clients do

DanD: Each individual connection on mobile costs battery

stefanh: you suggested that the incoming notification should be connected to the PeerConnection, should it not tie in to other parts of the API?

Cullen: I think the most important part about this is aggregating connections, we can copy the iOS model by making one connection to each aggregation source which pushes down blobs from the app (signed) and use webintents model to then dispatch them to apps. this allows flexibility in allowing apps to register themselves for particular intents

Adam: is this a webrtc problem or is this is a problem in general?
... Chat applications could use something like this too
... this feels a bit like the JavaME push registry

DanD: if we look at the two use cases there is definitely a gap regarding notification
... the keyword in the proposal is connection-less push, there are ways today to achieve this in efficient manners
... there still has to be a way for user A to notify user B that they are available
... the problem space is larger, webrtc is a subset that can benefit and is the primary beneficiary of notifications

juberti: I agree with Adam that there are many other applications that can use this and agree with Cullen that we can use many of the existing solutions for this
... I don't understand why we are in the business of defining a notification service, when there are already ways for apps to do this using existing technology
... contents of the notification should be a blob, structure need not be defined

DanD: defining the specific structure doesn't mean it has to be a laborious one
... it's the gluing piece that's most important

???: I agree this is a generic problem of how to allow webapps to use a generic notification service, what is the level of standardization that we can achieve? most existing system are proprietary anyway

DanD: I agree that this is a broader scope problem, but it also can be focused on particular requirements
... That's one of the reasons I was looking into what the specific structure we need
... is there a benefit of sending the offer blob, something to consider

???: existing systems let you push blobs around, we don't need to specify what exactly the structure is, it could be application specific

DanD: what are the elements that are neccesary, and having a consistent behavior for what happens when someone is calling me would be nice to standardize

Ashish: can we handle the use-case where I want to get a notification from mom, doesn't matter what provider, some way of establishing an identity; only ring if she calls

stefanh: this group's core competence is not that; DanD: to my understanding, no

Adam: if you are running the webapp on your phone there has to be some level of trust

ekr: It is reasonable to have a system dispatch events to an app, and you have app-level permissions

juberti: do we know what the status is on bryan sullivan's proposal on sms events?

DanD: it was submitted at the last TPAC, do not know what the status is

juberti: it seems like that's the kind of place to work out this problem

<rillian> hey, look at all the people

DanD: I was trying to recommend in the paper is to use webrtc use cases to accelerate that work, and if there are any specific elements of that spec to be captured (if need be)
... let's piggy back on that proposal, do we need to do anything specific? and support that work in webapps WG

harald: conclusion from the chairs: there is generic work that needs to be done which is done elsewhere in the w3c, and we need to link there when it is done

cullen: that work is about sms, harald: no sms is just one channel
... is the aggregation part being done elsewhere in the w3c?

harald: we will continue to monitor and figure stuff out


harald: we had a pretty clear decision at the IETF that the next version of the API draft be based on JSEP

ted: decisions at the IETF required confirmation on the mailing list

harald: we also need confirmation at w3c whether we accept IETF's recommendation or not

cullen: if we are moving away from 3264, myself and matthew kaufman have an alternative proposal that we would like to bring up

adam: do we have a recommendation for API? or is it a protocol?

harald: speaking as myself, we should sit down tomorrow and modify the spec, and experiment to see if it works

adam: is it necessary to put it in the spec to see if it works out?

juberti: things don't get implemented in chrome unless they are in a written spec that we can point at. we would like to see if jsep works, working build of chrome by Paris

harald: roap could be implemented without changes to webkit API, jsep is not like that

derf: one of the things that the current API lacks (that roap brought clarity to) is the state machine from 3264, helps browser implementers figure out. JSEP as currently specced lacks a lot of those things, and I would like to see that fleshing out done before it is added to the draft

juberti: I would also like that fleshing out!
... that will occur between now & paris but it doesn't need to block inclusion in spec
... given the benefit of getting implementation experience, still worth doing

cullen: did not suggest that jsep not be iterated on and experimented in code, but we also have alternative proposals which need to be considered

stefanh: for larger changes to spec we need a consensus, I would like to see jsep fleshed out before inclusion

<burn> anant: does spec need to be in w3c for it to be in chrome?

<stefanh> anant: is there a req that the spec in w3c space or not (for the webkit people)

<stefanh> justin: don't know really

juberti: what do we gain by that instead of just reving the ED?

dom: I don't have a strong opinion on this, but there is a fair amount of work to put it in the editor's draft

juberti: we've already thrown away a lot of implementation in chrome already, additional proposal become available; but we should try what we have now and was recommended yesterday and move forward

dom: you're right but we don't have consensus on what the API looks like
... editor's draft must also look like what the group has consented to

cullen: I do not get why having this text in the ED is important, other than just having a document for implementors to look at
... it's very difficult to evaluate if the spec is incomplete, what happens when setLocalDescription is called?

harald: how much time do you need for the alternative proposals?

cullen: lesser time than what it took for JSEP to form since the last interim (-3 weeks for Christmas!)
... we shouldn't rule out a whole class of proposals based on that
... it will be healthy to explore the range of possibilities

harald: im looking for a drop-date by which if we have no alternative proposals that we go forward with implementing JSEP

harald; we don't want to be in a situation like in december where we couldn't do anything while waiting for a proposal

tim: my fear (for putting the API in the spec) is that it's easy to put the API calls themselves but specifying the behavior is hard and will end up being whatever chrome implements

<burn> anant: need to have implementation first to demonstrate that it works. We need multiple implementations before we put into the draft.

<burn> anant: when we put it in a document it does not have to be the ED

juberti: the original version of the spec was something that didn't work, and that's why we had to make ROAP

cullen: matter of taste, how big things are before moving to the draft. there are exceptions to the spec but the history of the spec is that it was from the WhatWG

ted: one of the things i've heard in terms of this spec is that we want to get implementation experience, it would be nice to show what particular use cases an implementation tackles

Mathieu: comment on JSEP/ROAP - IETF/W3C. I think they are an evolution for SDP and I think the IETF should define how the data flows but the W3C is defining the API there is overlap which is causing this debate

harald: a lot of the back and forth is exactly that process, I don't see any clear answer

Christer: we have made decision yesterday to move away from 3264, but isn't JSEP just an extension to offer/answer? independent of whether it's O/A there's a question of whether it's actually SDP that we used to define the paramters

<Ted_Hardie> Speaker is Christer

harald: trying to get to some degree of conclusion. clearly we have some amount of work to do on the current jsep spec, we have to find a timeline for other proposals and criteria by which we judge whether they are better/worse than JSEP
... take it to the list! we'll get implementations and try it out somehow

looking at code samples for jsep

<dom> Code samples for JSEP/ROAP

<jesup> If later on we a chance to discuss congestion interaction apis, this is the document to use: http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0000.html

<stefanh> discussion on getUserMedia vs. HW reservation of camera

<stefanh> what happens if several tabs have right to use camera, and suddenly many wants to use it

<dom> Permissions for Device API Access Editors draft

<dom> sorry, I meant:

<dom> Feature Permissions "This document defines APIs for web pages to request permission to use privileged user agent features. "

<adambe> jesup: That would be the same as if the page in the iframe was loaded in a separate window

<adambe> eric: The default should be that the app manipulate the media

<adambe> eric: An app would get a "gold star" if it didn't manipulate media

<adambe> cullen: I think the default should be "no access", the app knows whether it will need to access the stream or not

<adambe> cullen: The app can decide

<adambe> cullen (via an API)

<adambe> eric: we should do work on securing local access to media

<adambe> jesup: that's it

<derf> dom, yes.

<derf> burn: There has been some interesting discussion on capabilities.

<dom> ScribeNick: derf

Capabilities API and fingerprinting

burn: We actually decided that rather than talking about specifics, we'd talk about higher level topics and give people an opporunity to comment.
... We pulled together e-mail topics for people to comment on.
... Proposals on WebRTC, RTCWeb, Media Capture lists about capabilities.

<dom> Addressing fingerprinting issues @ mozilla

burn: I'm not presenting answers, presenting questions so we get a lot more opporunity for discussion.
... The questions are, what do we actually need from a user interface standpoint?
... We're going to talk about fingerprinting.
... What APIs do we actually need?
... The key topics are what do we need for user interface reasons?
... And to reach consensus on the user privacy issues.
... I believe that the reason people want capabilities is for user interfaces.
... There are really two categories of user inteface needs:
... 1) For the app author to know what can be used (is there a camera? what resolution can it produce?)
... If you're trying to do remote surgery, you might not want a low-resolution video.
... 2) The other category is to show the user what is available or not available.

<dom> (not wanting low-resolution is different from detecting it in advance)

burn: These are different: for the first category you might want more detail than the second.
... You may only need to show the user whether or not there is a camera, but an application may want to know if the camera can do face recognition, etc.
... First question, are these really needed?

fluffy: Question about your question: when do we need these capabilities?

burn: First we should decide if we need them at all.

ekr: As a strawman, can we get arguments that we need capabilities at all?

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> Panopticlick

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> WebRTC Data Streams slides

<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]

-> http://www.w3.org/2011/04/webrtc/wiki/File:Aligned_Data_API.pdf Aligned Data API

<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 :)

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/02/13 13:12:54 $