Re: [rtcweb] Notes on security for browser-based screen/application sharing

Cullen Jennings <> Fri, 22 March 2013 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38B7B21F8CF7 for <>; Fri, 22 Mar 2013 08:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Be2B0J8eheC2 for <>; Fri, 22 Mar 2013 08:57:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 71B9521F8CAC for <>; Fri, 22 Mar 2013 08:57:45 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6836E22E253; Fri, 22 Mar 2013 11:57:38 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Cullen Jennings <>
In-Reply-To: <>
Date: Fri, 22 Mar 2013 09:57:36 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.1499)
Cc: "Cullen Jennings (fluffy)" <>, "" <>, "" <>
Subject: Re: [rtcweb] Notes on security for browser-based screen/application 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: Fri, 22 Mar 2013 15:57:46 -0000

On Mar 22, 2013, at 8:17 AM, Eric Rescorla <> wrote:

> On Fri, Mar 22, 2013 at 6:50 AM, Cullen Jennings (fluffy) <> wrote:
> One comment on this from a requirements point of view…
> Clearly sharking the "desktop" has far more security concerns that sharing a single applications such as PowerPoint. All the use cases I am interested in only need to share an application not a desktop. I think we should separate the handling of permissions along these lines. So I would be fine with "share desktop" needed an explicit grant of permission every time it was invoked (preferably by the user selecting this as part to choosing what to share in a browser chrome window). On the other hand, when sharing an application I might be OK with a persistent permission based on an install model but when I think about the real uses cases, I'm not sure that is needed if we have a good browser based dialog box to pick what will be shared.
> The main point of my note is that the user has basically no idea what sharing
> the browser means. I don't see how this is remediated by a dialog box
> telling them that they are sharing the browser.
> When the applications being shared is the browser there are also the additional problems as you point out. My view of the best way to solve these would be to scope the "application" being shared to the origin. What I mean by this is assume that I have my browser open to two webpages, one with an origin of and the other to and I am also running powerpoint and word. When the browser pops up a dialog box asking me what I wanted to share, it would give me 5 choices "Firefox (", "Firefox (, "Word", "PowerPoint", and "Everything" and let me pick.
> This doesn't sound very implementable. First, if you're sharing primarily by pixel
> capturing out of the window, trying to figure out which pixels represent which
> origins is going to be a huge pain for the implementor. Second, many sites
> as a practical matter are composed of content from multiple origins
> (images out of a CDN, domain sharding, etc.) The result of what you propose
> is going to be that such sites will not render properly when shared. I
> suspect that sites will simply ask for "The browser".
> -Ekr

Yah, I get your point. Sad but I agree.