W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

[minutes] F2F meeting Feb 1st

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 08 Feb 2012 11:01:19 +0100
Message-ID: <1328695279.9268.37.camel@altostratustier>
To: public-webrtc@w3.org

The draft minutes of our 1/2 F2F meeting in Mountain View on February
1st are available at:

and copied as text below. Please send corrections as you find errors.

When the chairs send the list of resulting action items to the list,
I'll probably integrate them in the minutes.


            Web Real-Time Communications Working Group F2F

01 Feb 2012


      [2] http://www.w3.org/2011/04/webrtc/wiki/February_1_2012

   See also: [3]IRC log

      [3] http://www.w3.org/2012/02/01-webrtc-irc


          Stefan, Harald

          anant, derf, dom


     * [4]Topics
         1. [5]publish new WD
         2. [6]Incoming Notifications by Dan Druta
         3. [7]JSEP
         4. [8]Capabilities API and fingerprinting
         5. [9]Data Stream API
     * [10]Summary of Action Items

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

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

   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

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

   <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
   ... editor's draft must also look like what the group has consented

   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

   <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

   looking at code samples for jsep

   <dom> [11]Code samples for JSEP/ROAP


   <jesup> If later on we a chance to discuss congestion interaction
   apis, this is the document to use:


   <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> [13]Permissions for Device API Access Editors draft

     [13] http://dev.w3.org/2009/dap/api-perms/

   <dom> sorry, I meant:

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

     [14] http://dev.w3.org/2009/dap/perms/FeaturePermissions.html

   <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

   <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

   <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
   ... We pulled together e-mail topics for people to comment on.
   ... Proposals on WebRTC, RTCWeb, Media Capture lists about

   <dom> [15]Addressing fingerprinting issues @ mozilla

     [15] https://wiki.mozilla.org/Fingerprinting

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

   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

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

   ekr: As a strawman, I believe we don't 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

   ???: 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
   ... 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
   ... 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
   ... Mozilla and others are working on web applications as a distinct
   idea, that can be installed just like installing a native

   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

   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

   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
   ... We want the ability to lie.
   ... Even if I do have a web cam, I may just want to stream an AVI

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

   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

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

   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

   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

   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

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

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


   <dom> ScribeNick: dom

   Justin: Randell talked about the wire format for data streams
   ... 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

   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
   ... ["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
   ... 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
   ... 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

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

   ???: [help, I missed that]

   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,

   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

   Harald: for Data API, the next iteration is to integrate that in the

   Justin: and once it's in the spec, we can implement it :)
Received on Wednesday, 8 February 2012 10:05:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC