Re: Draft text for identity-bound streams

On 2013-06-13 09:34, Harald Alvestrand wrote:
> On 06/13/2013 08:09 AM, Stefan Håkansson LK wrote:
>> On 2013-06-12 19:00, Martin Thomson wrote:
>>> On 12 June 2013 03:12, Stefan Håkansson LK
>>> <stefan.lk.hakansson@ericsson.com> wrote:
>>>> * talking about isolated MediaStreams - splitting it down on Tracks
>>>> would be
>>>> to confusing
>>>
>>> I disagree.  This all comes down to tracks.
>>
>> Perhaps it does. But then we need to define how a MediaStream with a
>> mix of isolated and non-isolated tracks (or
>> peerIdentified/non-peerIdentified tracks) is defined - since that is
>> what you deal with when attaching to PeerConnection's, media elements
>> etc. Certainly doable.
>>
>> But, at least to me, the use of isolated MediaStreamTrack's is
>> unclear. I assume the purpose is to allow the UA to inform the user
>> that this app only has isolated access to media, is that right?
>
> I think the purpose is to cause attempts to get at the media
> (screenshots, recording) to fail, so that (for instance) an injected
> script on a page that attempts to steal your microphone output will fail
> to do so.

But that has no value if the user can't verify it in any way. If you 
don't trust the app to not record, do screenshots or to protect from 
injected scripts, why would you trust that it applies the "noaccess" 
constraint (if there is no way to check)?

>
>>
>> Could you elaborate a bit on the thinking?
>
> I think both the important actions on streams (adding to a MediaElement
> and adding to a PeerConnection) are dependent on the isolation status of
> the elements being consistent.
>
> Would it make sense to say that a MediaStreamTrack with noaccess=true or
> peerIdentity=<something> could only be added to a MediaStream where all
> the other tracks were either non-isolated or had the same isolation state?

I think we're heading towards something like this.

Still I'm puzzled: if this application we're talking to about has 
MediaStreamTrack's with noaccess=true, and MediaStreamTrack's (perhaps 
with the same source) with noaccess=false - what have we accomplished? 
Recording etc. could be done on the noaccess=false tracks.

>
>
>

Received on Thursday, 13 June 2013 07:48:46 UTC