[rtcweb] UI for getUserMedia()

Randell Jesup <randell-ietf@jesup.org> Wed, 19 October 2011 15:04 UTC

Return-Path: <randell-ietf@jesup.org>
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 82B8121F8C63 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 08:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.256
X-Spam-Level:
X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
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 XDyRXWsJMI84 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 08:04:27 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B21D921F8C0E for <rtcweb@ietf.org>; Wed, 19 Oct 2011 08:04:27 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1RGXgw-0006E5-5q; Wed, 19 Oct 2011 10:04:26 -0500
Message-ID: <4E9EE5E2.2090201@jesup.org>
Date: Wed, 19 Oct 2011 10:59:46 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org, "public-webrtc@w3.org" <public-webrtc@w3.org>
References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><CABRok6n33QK0Si1Y0kT7+U0zgAWsJ4d5GENK_KL-JPx5a4erYg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com> <CALiegfmrncjsLVSiWk0tEgzwB00YaBGiqj0SDf9JTm9p1ZNoVA@mail.gmail.com> <2E239D6FCD033C4BAF15F3 86A979B F51159950@so nusinmail02.sonusnet.com> <0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com> <6398F67A-5E41-44BB-ABB2-831AB7C48DCC@ag-projects.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091CA3@ucolhp4d.easf.csd.disa.mil> <2E2B1F85-1DED-460D-B17D-0850DB3ACBA9@phonefromhere.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D31@ucolhp4d.easf.csd.disa.mil> <7357A569-83A3-43B6-80A7-E2374D78CE28@phonefromhere.com> <4E9E7887.400 0806@jesup.org> <898B2A25-BF04-4F48-91FD-CA868FB5A79F@phonefromher e.com>
In-Reply-To: <898B2A25-BF04-4F48-91FD-CA868FB5A79F@phonefromhere.com>
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 - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [rtcweb] UI for getUserMedia()
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: Wed, 19 Oct 2011 15:04:28 -0000

Changed title; see below for why.

On 10/19/2011 7:06 AM, Tim Panton wrote:
>
> On 19 Oct 2011, at 08:13, Randell Jesup wrote:
>> This example you give raises some security issues based on the current proposals.  We require that the user ok access to the camera and microphone; this is a call set up "on the fly" with apparently no individual certification from the user.
>>
>> This use-case would require the JS application get pre-authorization of media access, before any actual access occurs, and have that access persist until<something>, across multiple individual connections.
>>
>> So is this outside of the current security model, since it seems to bring in a number of new requirements?  To support this, we would need:
>>
>> 1) pre-authorization of camera/mic access
>> 2) authorization continues until a particular active state with the server ends (leaving the game)
>
> Oh, I thought that there had been some discussion on preserving authorization for a site - so that I can mark a site as
> 'trusted' and not have to see the permission request again. Without that sort of feature, rtcWEB/webRTC will get annoying _really_ fast.
> Once it is 'trusted' the game can create and tear down calls at will, with no need to fork anything.
> (I have to authorize each call separately in the current model ?!?)

This has not yet been decided; people have certainly talked to wanting 
to find ways to minimize or avoid user authorizations for certain 
classes of services, and I have also pushed such efforts, both here and 
within Mozilla.

However, at this point, no clear solution has been proposed; there are 
several ideas in play (leveraging "installed webapps", etc), but without 
some decision to modify the threat model it's tough.

Without that, the app will probably want to use UI generated by 
getUserMedia() as part of their UI.  That would also mean that the app 
would want to be able to present some indication as to *why* they're 
being asked to enable (incoming caller id, name of application since 
they may have many tabs open, etc), since they don't control the UI for 
getUserMedia() itself.  This is W3C territory, so I'm cc'ing this to 
that list.


-- 
Randell Jesup
randell-ietf@jesup.org