Firefox Android：即使手机锁定，摄像头仍保持活动状态

预期效果：手机锁定后，视频流(摄像头和麦克风)采集应立即停止。

David：我怀疑修复这个问题更多的是在Android前端，而不是Jya(Triage Owner)所做的任何事情。你能帮我找个人拥有这个吗，如果需要的话，也许还能找个更好的部件？

JNA-IVAR这是需要在相机平台代码中还是在Fennec/Fenix前端代码中修复的问题？

Jan-ivar这是需要在相机平台代码中还是在Fennec/Fenix前端代码中解决的问题？

听起来是这样。我想说，现有的行为是有意的，以至于以前没有人认为这是一个问题。例如，有人可能特别希望此行为记录一种情况。这就是说，我同意这不是大多数用户所期望的，因此是有问题的，因为用户可能会在他们认为自己不是的时候意外地记录下自己。当类似的手机浏览器在这方面的工作方式不同时，更是如此。这一隐私问题似乎胜过了这一功能的任何用例，我同意Chrome的行为在这里似乎是可取的。

我不知道关于这一点的任何规范语言，所以我建议我们看看Chrome，不管它是将曲目静音还是触发结束事件(无论是哪种情况，Firefox都会关闭摄像头/麦克风设备和任何硬件指示灯)。然后，我们可以引导Android团队触发此操作，分别将曲目静音或撤销权限。

我还联系了一些DOM权限人员，看看以前是否有其他强大的功能或Firefox中考虑终止手机锁定的功能出现过，或者这是否是相机和麦克风独有的问题。如果有先例，我们也许会想要效仿。

预期效果：手机锁定后，视频流(摄像头和麦克风)采集应立即停止

在我们继续这件事之前..。这些结果与我在我的三星S8(Android 9)上的Chrome(73和75)上看到的结果不匹配：

当我使用Chrome for Android连接到桌面并锁定手机时，视频确实会冻结，但音频仍在录制(我已将桌面上的麦克风静音，但仍能听到手机麦克风录制的声音)。我还会不断听到电话上的呼叫(当我取消桌面静音时)。当我解锁手机时，视频恢复。重要的是，通话仍在进行中；我必须解锁手机并离开通话，或者关闭Chrome应用程序才能终止通话。

我不清楚Chrome在这里静音视频是错误还是功能。无论是哪种情况，这都让我质疑理想的行为应该是什么。我们应该挂断电话吗？可能不会。这可能也不是用户想要的。也许可以将摄像头和麦克风都设为静音，但否则会继续通话吗？我想我投后者一票。一些Android应用程序，如YouTube，已经切换到在手机锁上继续播放音频，所以这似乎是方向。

作为对比，我试用了视频聊天应用Zoom&34；。当放到后台时，视频会立即停止，但音频会继续播放。当应用程序重新聚焦时，视频会再次出现。当我锁定电话时，音频仍在继续，但视频录制停止。这非常类似于在同一设备上进行电话呼叫的模式。就像打电话一样，屏幕顶部和锁定屏幕上有一个正在进行的缩放会议通知/图标。

就像Zoom和手机一样，那里也有一个通知，即Firefox在解锁时和锁定屏幕上都会在屏幕顶部录制视频。与Zoom不同的是，除了音频之外，视频还会继续录制。有通知，但这是微妙的。关于这是否有用，还有一个很好的问题。有时，也许你会重新转播，但如果你重新拍摄而没有反馈，那么拍摄工作可能会很糟糕。考虑到其他应用程序的行为，这对人们来说可能更多的是一种惊喜和带宽浪费。这可能是一个选项，但不是默认选项？我们的竞争对手可能已经在这方面做了用户研究，我们可以从他们相当一致的选择中学习。无论如何，在其他应用中保持一致的行为让我们的不同之处对用户来说更是一个惊喜，也可能是一个令人不快的惊喜，因为这样做并不会让人信服地赢得(用户利益)。

继续播放音频是有意义的。我经常会把手机或视频会议放在后台，同时在另一个应用程序中查找一些东西，或者在走路/开车时锁着手机听耳机。事实上，我也听到了所有其他参与者的声音，这是一条线索，如果我不将自己静音，我也可能会被录音。这种行为在不同的应用程序中是一致的，不太可能是令人不快的惊喜。

对于测试而言，https://appr.tc/不需要创建帐户即可在浏览器上试用WebRTC。

摘要：当FF在后台或电话被锁定时，摄像机/麦克风保持活动状态，并且仍然捕获视频。当FF在后台或电话被锁定时，→摄像机/麦克风保持活动状态

当我们使用Vidyo应用程序时，手机锁定时切断了连接，这激怒了我。如果我们决定改变行为，那么我们应该让Firefox在WebRTC调用时保持屏幕清醒。在处理全屏视频时，我们有一些这样的代码。

同意。尽管有记者的期待，但其他浏览器和类似的应用程序即使在手机锁定的情况下也能保持连接和音频。我将从错误摘要中删除麦克风。如果Trishul真的想这样做，他们可以在单独的bug(几乎可以肯定是WONTFIXed)中进行争论。

相机的事值得讨论。在相机锁定的情况下继续拍摄视频是没有意义的(如果你不知道相机指向哪里，那你在拍摄什么呢？)，浪费带宽，而且可能会出人意料地侵犯隐私。它唯一的用处似乎是作为一个秘密的远程摄像头(侵犯隐私作为一项功能)。对于我们的大多数用户来说，关闭摄像头是正确的选择，而且还有专用的间谍摄像头(电池性能更好！)。用来窥探。

摘要：当FF在后台或电话被锁定时，摄像机/麦克风保持活动状态。当FF在后台或电话被锁定时，→摄像机保持活动状态。

我不认为我们会改变Firefox for Android的行为，因为它已经启动了ESR过程。这应该是一个GV漏洞，还是应该由前台应用程序或AC自己来解决这个问题？

我不认为我们会改变Firefox for Android的行为，因为它已经启动了ESR过程。这应该是一个GV漏洞，还是应该由前台应用程序或AC自己来解决这个问题？

问得好。我们可能应该修复这个GV，这样每个GV驱动的应用程序都能做正确的事情。我现在会把这个错误发送到GV分诊。

安德烈亚斯，GV通知应用程序何时(Gecko告诉GV)相机被激活。我们需要产品输入关于GV是否应该暂停或关闭相机录制(当屏幕关闭时，手机被锁定，或者应用程序处于后台)，或者GV是否应该只通知应用程序，应用程序负责关闭相机。这可能是每个GV驱动的应用程序都需要正确解决的安全问题，但如果GV自己关闭摄像头，那么想要不间断拍摄的应用程序要么不可能用GV实现，要么需要一个新的GV API来选择退出关闭摄像头。

当相机处于活动状态时，GV是否保持适当的屏幕尾锁以保持屏幕打开和手机解锁？这将避免意外关闭相机，但不能解决用户手动关闭屏幕或锁定手机的情况。

很抱歉延迟了回复，我认为你们进展顺利，我认为这不会对网站的权限状态产生任何影响(我想这正是我需要信息的原因)。我也赞成在保持录音正常的同时以某种方式关掉摄像机。

同意。尽管有记者的期待，但其他浏览器和类似的应用程序即使在手机锁定的情况下也能保持连接和音频。我将从错误摘要中删除麦克风。如果Trishul真的想这样做，他们可以在单独的bug(几乎可以肯定是WONTFIXed)中进行争论。

相机的事值得讨论。在相机锁定的情况下继续拍摄视频是没有意义的(如果你不知道相机指向哪里，那你在拍摄什么呢？)，浪费带宽，而且可能会出人意料地侵犯隐私。它唯一的用处似乎是作为一个秘密的远程摄像头(侵犯隐私作为一项功能)。对于我们的大多数用户来说，关闭摄像头是正确的选择，而且还有专用的间谍摄像头(电池性能更好！)。用来窥探。

我认为让麦克风保持活动状态仍然是有效的用例，我想这是可以接受的。锁定状态下关闭摄像头是我真正想要推动的事情。

我也同意这里的方向。幸运的是，当一首曲目被暂时禁用时，Firefox已经关闭了摄像头，所以临时暂停应该足以关闭任何摄像头硬件(灯)。

这里有一些平台工作，因为规范说明在这种情况下触发事件：静音对于应用程序来说是失控的，但是应用程序可以通过读取静音属性并侦听相关的静音和取消静音事件来观察。MediaStreamTrack静音可能有几个原因：用户按下麦克风上的物理静音按钮、用户在操作系统中切换控件、用户点击浏览器Chrome中的静音按钮、用户代理(代表用户)静音等；

我检查了Chrome for Android，它只针对视频而不是音频触发这些事件，这支持Chrome的行为是故意的(打开这个小提琴，共享摄像头/麦克风，然后关闭手机屏幕，然后再打开)：

事实上，只需将Chrome应用程序推到后台并返回，就会发出这些事件。这表明Chrome即使在那时也会暂停视频。这或许表明，我们可能只在平台上就能做到这一点，通过监听对Android的疏忽-或者有时这会是错误的吗？Android的人会不会有明确的方法来解决这个问题呢？

我认为让麦克风保持活动状态仍然是有效的用例，我想这是可以接受的。锁定状态下关闭摄像头是我真正想要推动的事情。

那么想要不间断摄像的应用程序要么是不可能用GV实现的。

我想这是可以的。如果事实证明它有真正的用例，我们可以在它发生时重新考虑。

Fenix在系统通知栏中显示了一个摄像头图标，因此当应用程序处于后台或锁定状态时，用户并不是完全不知道摄像头处于打开状态。当屏幕关闭时，通知图标显然无济于事。：)。

摘要：当FF在后台或手机被锁定时，摄像头保持活动状态。当应用程序在后台或手机被锁定时，→摄像头保持活动状态。

这不是我们赏金计划要找的那种远程攻击。这听起来像是一个合理的隐私改善。

您需要先登录，然后才能对此错误进行评论或更改。