Re: Separating simple camera access and P2P authorization (was: Re: Clarification on media capture split between WebRTC and DAP)

(chopping some quoting)

On 08/17/11 14:46, Rich Tibbett wrote:
> Harald Alvestrand wrote:
>> On 08/16/11 17:07, Rich Tibbett wrote:
>>> Harald Alvestrand wrote:
>>>
>> When you say "taint", are you referring to the CORS concept as described
>> in http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html? I'm afraid
>> that document doesn't define the term, but it seems to be used a lot in
>> discussions around CORS - do you mean that we regard the Stream object
>> as having an Origin outside any current context?
>
> This section of the WHATWG spec summarizes the concept of tainting an 
> object via the origin-clean flag, applied to <canvas> elements with 
> content coming from a different origin:
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#security-with-canvas-elements 
>
Thanks! It wasn't using the word "taint", so I wasn't sure it was 
talking about the same thing.
So I'll assume for the moment that "tainted" means the same as "not 
origin-clean".
>
>>> 5. On user click of any of the stream control buttons presented,
>>> enable the inferred functionality, fire a callback to the web app and
>>> let it continue about it's intended business.
>>
>> Doesn't this mean that we're back to "click a button to allow access
>> every time you call"?
>
> Clicking to provide 'telephony' or 'streaming' could be sticky. When 
> you activate such a permission it remains active until the user 
> actively clicks to deactivate it again or disconnects by some other 
> means such as browsing to a different URL.
I think we're imagining different levels of stickiness - what has been 
imagined in other discussions is that one would do like current 
implementations of the geolocation API and permanently install trust in 
any instance of the same application, which would presumably be 
preserved across browsing sessions (the spec in 
http://dev.w3.org/geo/api/spec-source.html#privacy_for_uas 
<http://dev.w3.org/geo/api/spec-source.html#privacy_for_uas>is somewhat 
light on detail here, but chrome users can see the geolocation stuff here:
chrome://settings/contentExceptions#location).

>
> The model is a reversal on previous thinking: provide an unauthorized 
> but tainted webcam/microphone view to the web page and allow the user 
> to elevate the permissions at their discretion as and when they are 
> requested by the web page.
>
> If we simplify to the point of sticky permission sets, does that 
> alleviate some of the concern? Once you've clicked the telephony 
> button the page can make as many calls as it likes with the untainted 
> Stream object.
See above about the different levels of stickiness..... I'm worried, but 
I don't feel that I can take a strong position yet.
Let's see if the group has a consensus opinion once the alternatives are 
clear.