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

Eric Rescorla <ekr@rtfm.com> Fri, 22 March 2013 14:18 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBDF21F8B51 for <rtcweb@ietfa.amsl.com>; Fri, 22 Mar 2013 07:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.477
X-Spam-Level:
X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NQ8UXnpWKxZ for <rtcweb@ietfa.amsl.com>; Fri, 22 Mar 2013 07:18:07 -0700 (PDT)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 253E921F8AD8 for <rtcweb@ietf.org>; Fri, 22 Mar 2013 07:18:07 -0700 (PDT)
Received: by mail-qe0-f50.google.com with SMTP id k5so2385399qej.23 for <rtcweb@ietf.org>; Fri, 22 Mar 2013 07:18:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=E06goga/nD9zzc0r70FeFjEsqtMsE91uylUgmuyW6cw=; b=ooIgoMnrRrNM3ckimLE9NzxqtrwkP8GZpoU/r/H6sBHLj/g24bkSO5QRMOkSCKeKAH dh/0DP4VQ0KvXMAUhtO+E4cnb9PCGIgOnitg7KItOQWlou7T4u/myphSYSPEeUT+MVE+ 7IJ8QnQhFXhkwmVpzt+vVEjSlHxyiiqbJqzvVvDAMM2vxU6hd3U/A2aV6u+6sEbf5pMe N4nEgaogtFpyQUAUMn+hO06oQQPF5zOCF7/z3VQeIKU+Sm1ui0QoSDfuXbGLp4jm/r4p TovU5dKBsPD+SvhutHpNu+V2eQdzhhQ/d03Z2Z46ycWJKQ659108TCuIAb6uS8Zy84/y rxmg==
X-Received: by 10.224.168.6 with SMTP id s6mr300581qay.63.1363961881652; Fri, 22 Mar 2013 07:18:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.84.5 with HTTP; Fri, 22 Mar 2013 07:17:21 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB11342CB58@xmb-aln-x02.cisco.com>
References: <CABcZeBPs=znh-BUCRoVkPC1UuQt-xxf-COD+SGE59ASBzRZbJQ@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11342CB58@xmb-aln-x02.cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 22 Mar 2013 07:17:21 -0700
Message-ID: <CABcZeBN2R=dKYtoLEstNuT2K89k+Y_gD8_OdRS5MQOJNSzY5Kg@mail.gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary="089e0149ced47187a204d8841f49"
X-Gm-Message-State: ALoCoQmv77dclHvpvx1bRxNWfKSuMTNIsuAmZHpFtY1rSr8Tyb9DnKUahiEpLYrcgE7/pJo/zlDV
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] Notes on security for browser-based screen/application sharing
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2013 14:18:09 -0000

On Fri, Mar 22, 2013 at 6:50 AM, Cullen Jennings (fluffy)
<fluffy@cisco.com>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 gmail.com and the other to github.com 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
> (Gmail.com)", "Firefox (github.com) "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