Re: Comments on scenarios doc - 9 Feb Version

Travis

Regarding 5.10 I was thinking capture to a file was in itself a scenario (or sub-scenario), for example in 2.2 you might have george stream/store the podcast to a local file to view later. 

Your comments in your email make sense to me,

Thanks for the updates, I'll send the CfC.

regards, Frederick

Frederick Hirsch
Nokia



On Feb 10, 2012, at 3:38 PM, ext Travis Leithead wrote:

>> -----Original Message-----
>> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
>> 
>> 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.
> 
> Section 5.10 is just general commentary on media stream capture. The points I make in that section are actually incorporated into all the scenarios of section 2 already. For example, the four bullets in that section actually map to scenarios 2.2, 2.1, 2.1, and 2.5 respectively. Since section 2 is all about the complete end-to-end scenario, having this single bit about capture doesn't make sense to me as suggested.
> 
> Is there something specific about section 5.10 that you would like to emphasize as a variation?
> 
> 
> 
>> (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).
> 
> This sounds too much like a requirement statement rather than part of the scenario in my view. Rather than add the text as you requested, I added a parenthetical to re-enforce the idea (which I agree with) inline in the scenario. I also specified this idea in the first bullet.
> 
> 
> 
>> (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."
> 
> I'm intentionally not clarifying how the permissions are managed, as I'm a strong believer that different UAs will want the freedom of managing the experience differently. What I did want to convey via the scenario is that there is such a concept as persisted permissions.
> 
> I believe it is definitely in scope of this TF to think through the permissions model and how it relates to getUserMedia. Based on these scenarios, I think that generally-speaking there are cases when you want to establish least-privilege trust, and cases where you want full-trust, and there are probably many gradients in between.
> 
> This is directly pertinent to the ongoing issue regarding capabilities vs. hints in the API.
> 
> What I don't want to see happen in the spec are requirements regarding permissions that tie the hands of implementations with regard to how they want to do permission management. I would like to see some UA guidelines and I would like to ensure the API is designed with those guidelines in mind such that the right amount of privacy can be maintained under these various scenarios.
> 
> 
> 
>> (4) section 2.4 video diary
>> 
>> Add
>> 7. Integration of video audio capture with battery status to enable save
>> and termination.
> 
> Added.
> 
> 
>> On 02/09/2012 12:00 PM, Randell Jesup wrote:
>>> On 2/9/2012 10:10 AM, Frederick.Hirsch@nokia.com wrote:
>>>> (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.
>>> 
>>> I think Travis added this after I commented on the list; in any case I 
>>> was driving towards synchronized capture from both cameras, not 
>>> locally composited before saving. You could make an argument that 
>>> local compositing and recording multiple streams are equivalent from 
>>> this view of the spec (in terms of requirements), but I think they're 
>>> different in how users understand them.  If the requirements work out 
>>> the same, I'm ok with it.
>> The reason I suggested picture-in-picture as a variant was that having 
>> both exposed "record multiple streams" and "manipulate streams and 
>> record the result" as two separate requirements.
> 
> Since we already have 2.4.1.1 "simultaneous recording from multiple webcams" (which I think covers the ability to start two+ isolated recorders at the same time (on supporting hardware), my view for 2.4.1.2, now renamed "capture a composed video" is about making one capture of a video that is composed of two webcam's sources. 
> 
> There's no details here as to how this is done (for example, it might be bit-blitting the preview of each webcam onto a Canvas by way of post-processing, and the recording the canvas element; it might be done by media stream compositing API). I think we should keep an open mind. I also think we should spec the minimum functionality required to meet the scenarios even if it means leaning on other web platform features to complete the scenario.
> 
> 
> 
>> (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.
> 
> Thanks. I added that.
> 
> 
> 
>> (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)
> 
> Great considerations. I added them.
> 
> 
>> (8) section 5.4 stopping
>> 
>> rather than muting, isn't the alternative to "pause" the capture?
> 
> Pausing works better. I made the edit.
> 
> 
>> (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.
> 
> I agree. End-pointing/level detection would allow the "zakim" scenario to work. No spec change made.
> 
> 
> 
>> (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,
> 
> Upon re-reading this paragraph, I couldn't tease-out the point I was trying to make. Since 
> it is leading to confusion I just removed it.
> 
> 
> 
>> (11) Seems that issue of multiple web apps desiring simultaneous access, or
>> interrupting access to a device, warrants separate section and detailed
>> discussion.
> 
> I'd love to hash this out more. Right now, the topic is located mostly in section 5.2. I think as the TF works on the hints/permissions issue, that this may come up again and perhaps have an elegant solution.
>

Received on Friday, 10 February 2012 22:33:53 UTC