- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 May 2019 02:11:41 +0000
- To: public-webrtc-logs@w3.org
@jan-ivar Consider the use case of a screen shot https://github.com/w3c/mediacapture-screen-share/issues/107. Whether the user is expecting the permission/application menu UI to be captured or not could span from yes to no. However, if the sole purpose is the take a screen shot of an HTML element in an HTML `document` - not the permission/application menu, then the developer will have to determine if the permission UI is not displayed - how the developer determines the visibility state of the screen capture permission UI/scree menu is left to them. Relevant to security, the permission UI/tab menu displayed not only the tab selected, but also all of the tabs, open applications, windows. If a developer is not aware of that the contents of various applications can be leaked simply by selecting a screen unrelated to the content of the screen that is not and was not intended to be selected. Developers and a wide range of users of browsers take screen shots and capture media for a wide range of reasons. Some of the reasons are directly related to capturing the entire contents of the current screen, and all open tabs and applications; filing bug reports, minimal complete verifiable examples. Other reasons are not directly related to the entire contents of a screen, but rather specific elements and media playback, for which capturing a permission UI is not only useless, but an artifact to find a workaround for, and exposes wholly unrelated open applications, tabs, screens to data leak, if the user is for example, not aware that all of the text they typed in a text editor or a `window` which was not intended to be capture is being captured nonetheless. -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/108#issuecomment-497549380 using your GitHub account
Received on Friday, 31 May 2019 02:11:43 UTC