See also: IRC log
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
<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:
<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
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.
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 :)