Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing

Randell Jesup <> Mon, 19 September 2011 14:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 292DA21F8BB6 for <>; Mon, 19 Sep 2011 07:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id alPk6w4U8ap0 for <>; Mon, 19 Sep 2011 07:02:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A270121F8BB5 for <>; Mon, 19 Sep 2011 07:02:22 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1R5eSj-0000FD-Or for; Mon, 19 Sep 2011 09:04:45 -0500
Message-ID: <>
Date: Mon, 19 Sep 2011 10:01:24 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Sep 2011 14:02:23 -0000

On 9/19/2011 6:39 AM, Hadriel Kaplan wrote:
> On Sep 19, 2011, at 3:02 AM, Magnus Westerlund wrote:
>> A) Where the RTCWEB enabled browser can use a local application window,
>> the whole desktop or a Screen as a media source that can be encoded and
>> transported over the peerConnection for displaying/playback at the peer.
>> B) Where a remote peer can provide one or more input types such as mouse
>> and keyboard to control the local system, not only including the
>> browser, but also other operating system resources. This clearly can
>> only happen after additional consent, most likely on a per occasion
>> consent.
> I think scenario A is less worrisome than B.  Scenario A is a lot like webex, obviously, and from a logical perspective if we're going to be able to take a local video file as input to a PeerConnection LocalMediaStream, and the video file could be of me doing stuff on my screen, then this is just a shortcut to taking the video and sending the file at the same time.
> Scenario B, on the other hand, is the other half of VNC and my IT dept. would probably freak if a browser could do this, even with user consent.  (in fact, they'd probably freak at Scenario A too)  There's a big difference between installing an application for a specific purpose such as VNC, vs. random Javascript on websites turning the browser into VNC.  Was there discussion on the con call about what IT department types would think of these two scenarios?

To be honest, no, it wasn't discussed, and it very much should be.  This might get tied
into the more general discussions of "ongoing" permission, and the related topic currently
being worked on in various bodies is permissions for HTML5 "webapps".  This capability
might not even be offered for the user to accept unless installed as part of a webapp
(mirroring the permissions model of installing applications, such as installing VNC).

BTW, your IT department does know that Windows has Remote Desktop and Remote Assistance,
right?  ;-)

Randell Jesup