Re: [mediacapture-main] What happens when laptop lid is closed / phone display is turned off? (#670)

Is "MBP" "Mac Book Pro"? 

Some uses cases of continued transmission of `MediaStreamTrack` data while laptop lid is closed are:

- Creating an audio book. There is no need to view a screen to read a physical book that is recorded  and then transcribed to text with other API's, e.g., speech recognition technologies.
- Voice commands. Note, the voice does not necessarily need to be a live human voice. The laptop lid does not need to be open to provide the voice command to launch a headless version of a browser, navigate to a page, execute `getDisplayMedia()` to grab a still image or record the screen. This can be done multiple times to create a collage of media from fragments which are then merged into one media stream that is edited and exported - again using `MediaStream`.
- Working on a project that is, for example, an exclusive premiere of media. The developer might not want anyone else to be able to view their work in progress, they close the lid on their device for a few moments. Then re-open the lid on the device. All work should not be lost because a specification wants to stop media capture  when the lid is closed. 

> Mention privacy issues/guidelines for vendors to avoid users being "surprised" recording is on.

Users should not be surprised recording is on. They turned it on. They navigated to the site and were prompted to capture their media devices, which they granted permission for. Nor should users rely on automation alone to turn recording off. They did not physically turn off recording, instead they bypassed that critical step to close the machine lid. The simplest approach, since physical  activity by the human is necessary to both type `MediaStreamTrack.stop()` or `MediaStreamTrack.disabled` or to click the relevant UI the implementer provides, is to not omit clicking to revoke permissions _before_ closing the lid on the device. 

The proposed presumptive solution to just stop the stream has the initial theme of not trusting the user to perform their own due diligence, and therefore since the specification authors do not trust the users to handle their own streams - perhaps from a specification author having the occasion not handling their own media stream themselves in a certain case - will now attempt to place the entirety of the world in the category of their case where they expected the stream to stop when _they_ individually close their device lid. 

A rational solution to the case of a user expecting a media stream to stop when the lid is closed is apparently to use a "MBP" machine and *pple OS. 

Even then, since the specification author would, presumably,  consider the opposite of their experiences and use cases as well as their own experiences and use cases, yet another solution is to advise (include a **_Note_**) the user that the media stream MAY or MAY NOT stop capture when lid is closed, then the user is aware and can take steps to configure their power manager at the OS, to either continue capture or stop capture when lid is closed, rather than to have only one option of stopping the stream, which  appears to be  a  would-be  safeguard against the user making  a mistake,  or omitting revoking permissions previously  granted before closing the  lid, which does not make  sense if they truly intend to affirmatively stop the stream -  they  need to do that before closing the lid,   which is the logical steps of the  procedure if that is in fact what they intend to occur: 

1. Do not want media capture to occur when lid is closed.
2. Revoke permissions.
3. Close lid.

Skipping 2. is not logical when the user is  aware of the stream ongoing.

For the case of users who are using a "smart" phone to capture media, well, that entire landscape is rife with issues that this specification  cannot remedy. In essence what is being proposed is the elimination of "butt-dials" or "pocket calls", or in this case, ongoing "pocket media stream captures" where the actual solution for that dilemma is to not walk around with  a "smart" phone in your pocket all of the time. It actually is possible to simply set the device down, and not have a "smart" phone leashed to one's person at all times, while performing all sorts of human activities and  simultaneously expecting the device to not have a button or key pressed unintentionally.

In summary, users  are responsible for their media capture  -  not the specification. 

GitHub Notification of comment by guest271314
Please view or discuss this issue at using your GitHub account

Received on Saturday, 28 March 2020 16:20:30 UTC