- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 08 Feb 2012 11:01:19 +0100
- To: public-webrtc@w3.org
Hi,
The draft minutes of our 1/2 F2F meeting in Mountain View on February
1st are available at:
http://www.w3.org/2012/02/01-webrtc-minutes.html
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.
Dom
Web Real-Time Communications Working Group F2F
01 Feb 2012
[2]Agenda
[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
Attendees
Present
Regrets
Chair
Stefan, Harald
Scribe
anant, derf, dom
Contents
* [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
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
JSEP
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> [11]Code samples for JSEP/ROAP
[11]
http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0093.html
<jesup> If later on we a chance to discuss congestion interaction
apis, this is the document to use:
[12]http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0000.h
tml
[12]
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> [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
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> [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
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, 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
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 Wednesday, 8 February 2012 10:05:11 UTC