Comments on scenarios doc - 9 Feb Version

Travis

Some additional suggestions

(1) I suggest we move section 5.10 capturing media stream to be a new subsection in section 2, as it is a major use case.

(2) section 2.1, hat scenario

Add (after list 1-7)

"Note that the permissions Amy has given are not persistent , so every subsequent use of the webcam or microphone will require Amy granting permission. 
This is to avoid the possibility of unauthorized camera or microphone use after Amy finishes sharing her hat information."

(This is in contrast to 2.2 Election podcast which assumes persistent permission).

(Although one could image a "life cam").

(3) section 2.2 election podcast

are the persistent permissions based on time, or just general permissions? Is this permission aspect in scope for the API work here?

Additional item  "Schedule by time period video and audio capture permissions."

(4) section 2.4 video diary

Add 
7. Integration of video audio capture with battery status to enable save and termination.

(5) 2.4.1.2 picture-in-picture

Is this really picture-in-picture, or capture of multiple time-sync'd videos that can subsequently be edited? Sounds like the latter.

(6) Add to 5.1.1 privacy

Add

"In addition, care must be taken that webcam and audio devices are not able to record and stream data without the user's knowledge. 
Explicit permission should be granted for a specific activity of a limited duration.  Configuration controls should be possible to enable age-limits on webcam use."

I'm not sure how to address concerns about age and granting permissions, I believe there have been some "child exploitation center" concerns noted in the UK regarding 
children being mislead into using video inappropriate. Possible issue.

(7) 5.1.2 privacy Issues

add

4.  Enabling control configuration of webcam based on age?

5. Phishing and other attacks using webcam, audio (possible issue to note)

(8) section 5.4 stopping

rather than muting, isn't the alternative to "pause" the capture?

(9) 5.5 pre-processing

support of something like "zakim, mute george" seems very valuable.

gain control might be tricky if it enhances unwanted background noise on a specific un-muted input.

Sounds like there is enough work in v1 to suggest not including video pre-processing, as is suggested in issue 1.

(10) 5.7.1 privacy

Does  [[A selected device should provide some state information that identifies itself as "selected"]] mean that I could write a monitor app to determine when the 
webcam is in use and by which apps? (Or should my request for a device simply fail without reason if in use? 
this goes back to the earlier issue of multiple web pages wanting simultaneous access and how to handle it,

(11) Seems that issue of multiple web apps desiring simultaneous access, or interrupting access to a device, warrants separate section and detailed discussion.

Thanks for a great draft.

regards, Frederick

Frederick Hirsch
Nokia



On Feb 8, 2012, at 4:04 PM, ext Travis Leithead wrote:

> I've updated the MediaStream capture scenarios doc as noted below.
> 
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
>> 
>> I have gone through the scenarios doc (version of Jan 19, sorry for not
>> updating), and have some comments. This is transcribing from my
>> marked-up copy, so forgive me for commenting in serial order rather than
>> in order of importance.
>> 
>> Overall, I'm happy with the document as it stands!
>> 
>> - Section 1, scope: I think that you should not claim that networking
>> scenarios are out of scope for this task force, rather they should be
>> included by reference; what comes out of the task force must satisfy
>> both the scenarios described here and the scenarios described in the
>> WebRTC scenarios doc.
> 
> Removed. The intro now only excludes declarative capture.
> 
> 
>> - Section 2.1: Permisssions - you are assuming, both here and in the
>> other scenarios, that ask-before-use is the only possible permission
>> mechanism. This is not aligned with draft-ietf-rtcweb-security-01
>> section A.3.2, where a means of granting permanent access to a
>> particular service is a MUST. This is to avoid training the user to
>> "always click through", which is a perennial problem with security dialogs.
> 
> I spread the permissions models around among the scenarios so that they are not always the same prompt-before-use technique. Now using prompt, pre-approval, no notice, and "activation" for variety.
> 
> 
> 
>> - Section 2.2 Election podcast - you don't specify whether the recording
>> is happening locally or at a server. These alternatives might be
>> mentioned under "Variations" - the Hangouts On Air service is very close
>> to the proposed service, and does recording at server.
> 
> This was intended to be local to the client; I've now specified it as such. I'm not comfortable putting a scenario in place that involves server-size capture. Frankly servers can do whatever they want with the media stream and only need to know the low-level details of how the media stream works in order to accomplish that. Those details (I believe) are out of scope--at least for capture scenarios (they feel like a protocol-level spec).
> 
> 
>> - Section 2.3 Find the ball - if you really want low resolution, 640x480
>> might not be a good example.
> 
> Now 320x200. 243,200 fewer pixels to examine :-)
> 
> 
>> - Section 2.4 Video diary - one thing I was thinking while reading this
>> was Picture-in-Picture approaches - which would feed directly into
>> manipulation functions on the stream while it is being recorded. Perhaps
>> mention under Variations?
> 
> I like this scenario. Added as variation 2.4.1.2.
> 
> 
> 
>> - Section 2.4 Conference call product debate - this seems like a
>> videoconference scenario with a recorder. You might want to point to the
>> RTCWEB videoconference scenarios (with or without server) for discussion
>> about non-recording concepts.
> 
> You're referring to this?
> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06
> 
> Rather than call out to this doc in a one-off location, I now link to it in the introduction.
> 
> 
>> - Section 4 Concepts:
>> Stream: I suggest you don't define "Stream". That word is used entirely
>> too much, with too many meanings. Just don't use it. The text can be
>> moved under MediaStream.
> 
> I care more about the conceptual understanding of Stream as described in the text. I moved that text under the following definition and removed the "Stream" definition.
> 
> 
>> Virtualized device: I think this section mixes up the concept of
>> shareable devices and devices which have manipulatable state. We can
>> have shareable cameras and non-shareable microphones. I suggest finding
>> two terms here.
> 
> I tried to separate the concepts. This change had a down-stream effect on section 5.2.1#3, and 5.8 (3rd paragraph).
> 
> 
>> - Section 5.5: Applying pre-processing doesn't require the UA to do it
>> if the UA provides a means of presenting a media stream in a known
>> format on a known interface, and consume the media stream again after
>> transformation that can be done outside the UA. Implementations that do
>> this have been demonstrated (face recognizers in JS, for instance).
> 
> You missed the point. If the UA provides a means of access to the media
> stream in a known format on a known interface, then that interface itself
> is a media stream sink, and now you're talking about a post-processing 
> scenario. I updated the second paragraph of 5.5 to make that more clear.
> 
> 
>> - Section 5.6.3 Examples. If the canvas functions defined here work
>> today, that should be made clear. It's not easy to see now whether these
>> are real examples or suggestions for future extensions.
> 
> I'm not sure that it matters much. I added a note saying that these are all 
> based on W3C draft specifications (to my knowledge, none of these have reached
> Recommendation status), and many of them are implemented.
> 
> 
>> - Section 5.7.1 Privacy. The *developer* is probably not the term you're
>> looking for here about who information is exposed to; the developer is
>> not involved when an application runs. You might be thinking about the
>> application.
> 
> Corrected that. Thanks.
> 
>

Received on Thursday, 9 February 2012 15:10:59 UTC