Re: [rtcweb] Security and browser/screen access

Harald Alvestrand <harald@alvestrand.no> Mon, 26 September 2011 07:59 UTC

Return-Path: <harald@alvestrand.no>
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 D44B221F8A97 for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 00:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.524
X-Spam-Level:
X-Spam-Status: No, score=-109.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 BznYtsBCOlou for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 00:59:55 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D606B21F8A6C for <rtcweb@ietf.org>; Mon, 26 Sep 2011 00:59:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3999139E112; Mon, 26 Sep 2011 10:02:36 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZtROP8Y2cgL; Mon, 26 Sep 2011 10:02:35 +0200 (CEST)
Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9F04739E048; Mon, 26 Sep 2011 10:02:35 +0200 (CEST)
Message-ID: <4E80319B.2000109@alvestrand.no>
Date: Mon, 26 Sep 2011 10:02:35 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Randell Jesup <randell-ietf@jesup.org>
References: <4E7FA1A3.60908@jesup.org>
In-Reply-To: <4E7FA1A3.60908@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, public-webrtc@w3.org
Subject: Re: [rtcweb] Security and browser/screen access
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: Mon, 26 Sep 2011 07:59:55 -0000

On 09/25/2011 11:48 PM, Randell Jesup wrote:
> This is an issue that impacts at a usecase we've been discussing: 
> access to the
> browser or screen bitmap is inherently very risky, security-wise.
>
> See Robert O'Callahan's blog post triggered by discussions of these 
> usecases at
> our recent Mozilla All-Hands:
> http://robert.ocallahan.org/2011/08/securing-full-screen.html
>
> This directly affects use-cases like WebEx (of course), remote 
> assistance, etc.
> We've glossed the security side of those so far.
This also is something that affects the W3 side of things more than it 
affects the IETF side of things; can I encourage people to join the W3C 
WEBRTC mailing list and take those discussions there?
>
> Note that these use-cases replace desktop or plugin installs which 
> implicitly gave
> the provider access to far more than just the screen, so from that 
> perspective
> screen access is actually a reduction in exposure.  However, there's a 
> definitive
> decision (whether well-informed or not) to install these apps, and 
> most of them
> (not all!) don't auto-update without asking; and you can un-install them.
>
> This once again as I've mentioned in some other cases wanders into the 
> same territory
> as WebApp installation, which we also talked about looking at for 
> handling "ongoing
> permissions" for camera/mic for services similar to Skype - tie it to 
> a user "install".
> Whether that's good enough, and how that actually works are good 
> questions.
>
Fully agree on the situation description.