W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: What is missing for building "real" services?

From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 8 Jan 2014 21:45:22 -0800
Message-ID: <CABcZeBMxXDYq29B4u2QbHcjUsJBPoQ5mfdUrUT8KQT99+cL_cQ@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: Alex Gouaillard <alex.gouaillard@temasys.com.sg>, "public-webrtc@w3.org" <public-webrtc@w3.org>
People also want to be able to share the browser.

-Ekr


On Wed, Jan 8, 2014 at 9:39 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
> Okay, so here is my second attempt at this:
>
> We should be able to share any part of the display that the application does
> not control. Meaning, the webapp might allow users to share the contents of
> Excel so long as it has no control over what gets displayed by Excel.
> Similarly, it should be allowed to share any browser tab so long as it plays
> within its own host/origin.
>
> Assuming that co-browsing is a non-goal for now, is the above (read-only
> screen sharing) safe from a security point of view?
>
> Gili
>
>
> On 09/01/2014 12:19 AM, Alex Gouaillard wrote:
>>
>> importance of the interest:
>> We, and the 50 Millions pool of clients we already serve, want this
>> scenario (full screen sharing), even though we would prefer the
>> version where only the display of a given (potentially masked on the
>> origin computer own desktop) window is shared. I cannot speak for
>> others, but I remember seeing quite a few hints of interest on the
>> mailing list, and some experiments with chrome screen sharing seem
>> pretty popular out there. Some of the video conferencing product we
>> used to sell (*cough*vidyo*cough*) and others already propose this
>> functionality and it was the main sales point. Many of
>> not-yet-customers have expressed utmost interest in the use case
>> described below for either education purpose, or in hospital
>> environment (regulation are different for tablets, and iPad with a
>> specific casing are allow in surgery. What was only prototyping in
>> Research Units when I was at Harvard Medical School (2008-ish) is now
>> a reality in "standard" hospital and radiology Units as well.
>>
>> use case / scenario:
>> The most usual case is sharing a presentation, table, or text document
>> as a stream in a multi stream (document display + self video + self
>> audio + potentially other stuff) call. Screen sharing allows to share
>> the document, but then, you don't see yourself. Sharing separate
>> window content (as in desktop composition's window), would allow a
>> better presentation experience for the sender, who who be able to see
>> the document he is sending (as a local stream), and himself, basically
>> mirroring what the remote peer could see.
>>
>> On Thu, Jan 9, 2014 at 12:02 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>> On Wed, Jan 8, 2014 at 7:52 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>>>
>>>> Remind me again, what was wrong with this approach?
>>>
>>> It doesn't enable essentially any screen sharing scenario that
>>> people want.
>>>
>>> -Ekr
>>>
>>>> Enable screensharing without a flag/plugin.
>>>> Prompt the user for permission.
>>>> Allow screensharing for a single browser tab (can't capture the general
>>>> screen or foreign processes).
>>>> Prevent pages that use screensharing from issuing requests to foreign
>>>> hosts
>>>> (i.e. Same Origin policy minus any exceptions).
>>>>
>>>> Lets start with something that is fairly restrictive (but doesn't
>>>> require a
>>>> flag/plugin which kills traction), enable *some* use-cases, and built up
>>>> from there.
>>>>
>>>> Gili
>>>>
>>>>
>>>> On 08/01/2014 9:03 PM, Eric Rescorla wrote:
>>>>
>>>> On Wed, Jan 8, 2014 at 5:53 PM, piranna@gmail.com <piranna@gmail.com>
>>>> wrote:
>>>>
>>>> I'm not ccomparing both in the way I accept whatever of both, but
>>>> instead in
>>>> the way both (plugins and flags) are equally bad ideas. Screen and
>>>> application sharing should be included and enabled on browsers by
>>>> default,
>>>> and not hidden behind a flag or whatever other method.
>>>>
>>>> For the reasons described in:
>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-security-05#section-4.1.1
>>>>
>>>> The browser vendors don't think this is that great an idea.
>>>>
>>>> If you think that screen sharing should be available by default, you
>>>> should perhaps suggest some security mechanisms which would
>>>> make the threats described here less severe.
>>>>
>>>> -Ekr
>>>>
>>>> Send from my Samsung Galaxy Note II
>>>>
>>>> El 09/01/2014 02:42, "Alex Gouaillard" <alex.gouaillard@temasys.com.sg>
>>>> escribió:
>>>>
>>>> @ piranha.
>>>>
>>>> while I agree with you for social users and most of the population out
>>>> there, the difference between clicking a flag and installing a plugin
>>>> is the process required by IT teams to accept the product and deploy
>>>> it in an enterprise environment. Everything needs to validated
>>>> beforehand, including (especially?) plugins. They have a very long
>>>> list of products to screen and maintain, and are very reluctant to add
>>>> yet another one. Moreover, google's chrome start with a higher
>>>> credibility than any small or medium sized company's plugin.
>>>>
>>>> On Thu, Jan 9, 2014 at 8:54 AM, Silvia Pfeiffer
>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>
>>>> On Thu, Jan 9, 2014 at 10:10 AM, Randell Jesup <randell-ietf@jesup.org>
>>>> wrote:
>>>>
>>>> On 1/7/2014 8:50 PM, Alexandre GOUAILLARD wrote:
>>>>
>>>> here are a few proposition on things that are really biting us, and how
>>>> to
>>>> (perhaps) make it easier:
>>>>
>>>> - bandwidth control
>>>> 1. It seems that the number one sdp munging cause is the now infamous
>>>> B=AS:
>>>> line to put a cap on bandwidth. Since that capacity exists in the
>>>> underlying
>>>> code, it would be great to have an API that can help us put caps,
>>>> either on
>>>> each stream, and/or on the full call.
>>>>
>>>>
>>>> yes.
>>>>
>>>>
>>>> 2. I also see that there is a "auto-mute" feature being implemented
>>>> that
>>>> depend on an arbitrary threshold. It might be interested (but
>>>> overkill?), to
>>>> give user the capacity to set that limit (currently 50k I guess)
>>>> somehow.
>>>>
>>>>
>>>> Pointer to this auto-mute implemetation?
>>>>
>>>>
>>>> 3. Additionally, and perhaps not unrelated, we would alike to be able
>>>> to
>>>> decide what happen when bandwidth goes down. Right now it feels like
>>>> the
>>>> video has the priority over the audio. We would like to be able to
>>>> explicitly set the audio priority higher than the video in the
>>>> underlying
>>>> system, as opposed to implement a stats listener, which triggers
>>>> re-negotiation (with the corresponding O/A delay) when bandwidth goes
>>>> below
>>>> a certain threshold.
>>>>
>>>>
>>>> Right now they have the same "priority", but really audio is typically
>>>> fixed, so the video reacts to changes in the apparent level of
>>>> delay/buffering.  What you may be seeing is better (or less-obvious)
>>>> error
>>>> control and recovery in the video; the eye is often less sensitive to
>>>> things
>>>> like dropped frames than the ear.
>>>>
>>>> I'd love to see a trace/packet-capture/screen-scrape-recording where
>>>> you see
>>>> that apparent behavior.
>>>>
>>>>
>>>>
>>>> - call controls like mute / hold
>>>> Right now, you can mute a local stream, but it does not seem to be
>>>> possible
>>>> to let the remote peers know about the stream being muted. We ended up
>>>> implementing a specific off band message for that, but we believe that
>>>> the
>>>> stream/track could carry this information. This is more important for
>>>> video
>>>> than audio, as a muted video stream is displayed as a black square,
>>>> while a
>>>> muted audio as no audible consequence. We believe that this mute / hold
>>>> scenario will be frequent enough, that we should have a standardized
>>>> way of
>>>> doing it, or interop will be very difficult.
>>>>
>>>>
>>>> There is no underlying standard in IETF for communicating this; it's
>>>> typically at the application level.  And while we don't have good ways
>>>> in
>>>> MediaStream to do this yet, I strongly prefer to send an fixed image
>>>> when
>>>> video-muted/holding.  Black is a bad choice....
>>>>
>>>> It would be nice if browsers sent an image, such as "video on hold" -
>>>> just like they provide default 404 page renderings. This is a quality
>>>> of implementation issue then. Maybe worth registering a bug on
>>>> browsers. But also might be worth a note in the spec.
>>>>
>>>>
>>>> - screen/application sharing
>>>> We are aware of the security implications, but there is a very very
>>>> strong
>>>> demand for screen sharing. Beyond screen sharing, the capacity to share
>>>> the
>>>> displayed content of a given window of the desktop would due even
>>>> better.
>>>> Most of the time, users only want to display one document, and that
>>>> would
>>>> also reduce the security risk by not showing system trays.
>>>> Collaboration
>>>> (the ability to let the remote peer edit the document) would be even
>>>> better,
>>>> but we believe it to be outside of the scope of webRTC.
>>>>
>>>>
>>>> yes, and dramatically more risky.  Screen-sharing and how to preserve
>>>> privacy and security is a huge problem.  Right now the temporary kludge
>>>> is
>>>> to have the user whitelist services that can request it (via extensions
>>>> typically)
>>>>
>>>> Yeah, I'm really unhappy about the screen sharing state of affairs,
>>>> too. I would much prefer it became a standard browser feature.
>>>>
>>>> Cheers,
>>>> Silvia.
>>>>
>>>>     Randell
>>>>
>>>>
>>>>
>>>> - NAT / Firewall penetration feedback - ICE process feedback
>>>> Connectivity is a super super pain to debug, and the number one cause
>>>> of
>>>> concern.
>>>> 1. The 30s time out on chrome generated candidate is biting a lot of
>>>> people.
>>>> The time out is fine, but there should be an error message that
>>>> surfaces
>>>> (see 5)
>>>> 2. Turn server authentication failure does not generate an error, and
>>>> should
>>>> (see 5)
>>>> 3. ICE state can stay stuck in "checking" forever even after all the
>>>> candidate have been exhausted
>>>> 4. Not all ICE states stated in the spec are implemented (completed?
>>>> fail?)
>>>> 5. It would due fantastic to be able to access the list of candidates,
>>>> with
>>>> their corresponding status (not checked, in use, failed, ….) with the
>>>> cause
>>>> for failure
>>>> 6. In case of success, it would be great to know which candidate is
>>>> being
>>>> used (google does that with the googActive thingy) but also what is the
>>>> type
>>>> of the candidate. Right now, on client side, at best you have to go to
>>>> chrome://webrtc-internals, get the active candidate, and look it up
>>>> from the
>>>> list of candidates. When you use a TURN server as a STUN server too,
>>>> then
>>>> the look up is not an isomorphism.
>>>>
>>>> right now, the only way to understand what's going on is to have a
>>>> "weaponized" version of chrome, or a native app, that gives you access
>>>> to
>>>> the ICE stack, but we can not expect clients to deploy this, nor to
>>>> automate
>>>> it. Surfacing those in an API would allow one to:
>>>> - adapt the connection strategy on the fly in an iterative fashion on
>>>> client
>>>> side.
>>>> - report automatically the problems and allow remote debug of failed
>>>> calls,
>>>>
>>>>
>>>>
>>>> On Tue, Jan 7, 2014 at 2:15 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> On Mon, Jan 6, 2014 at 10:10 AM, piranna@gmail.com <piranna@gmail.com>
>>>> wrote:
>>>>
>>>> That's not really going to work unless you basically are on a
>>>> public
>>>> IP address with no firewall. The issue here isn't the properties of
>>>> PeerConnection but the basic way in which NAT traversal algorithms
>>>> work.
>>>>
>>>> I know that the "IP and port" think would work due to NAT, but
>>>> nothing
>>>> prevent to just only need to exchange one endpoint connection data
>>>> instead of both...
>>>>
>>>> I don't know what you are trying to say here.
>>>>
>>>> A large fraction of NATs use address/port dependent filtering which
>>>> means that there needs to be an outgoing packet from each endpoint
>>>> through their NAT to the other side's server reflexive IP in order to
>>>> open the pinhole. And that means that each side needs to provide
>>>> their address information over the signaling channel.
>>>>
>>>> I strongly recommend that you go read the ICE specification and
>>>> understand the algorithms it describes. That should make clear
>>>> why the communications patterns in WebRTC are the way they
>>>> are.
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>> --
>>>> Randell Jesup -- rjesup a t mozilla d o t com
>>>>
>>>>
>
Received on Thursday, 9 January 2014 05:46:31 UTC

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