因此，您希望构建一个端到端加密的Web应用程序
因此，如果我们可以进行基于浏览器的端到端加密视频通话，就像我们在桌面应用程序或移动应用程序等设备之间所做的那样，那就太好了。我们希望这样，Zoom本身或影响Zoom或其基础设施的外部机构就不能窥探或干扰这些视频通话。然而，尽管将大量使用JavaScript的网页称为“应用程序”，但Web应用程序与桌面或移动应用程序完全不同。与已安装的桌面/移动应用相比，Web应用具有不同的、安全性较低的深度安全模型，但对于具有有限范围的身份机密材料的短暂E2EE(端到端加密)呼叫，这是可以接受的，并且应该继续这样做，以支持Web平台上的大量用户。
Web应用程序由Web服务器提供，通常(但并非总是)在您每次加载页面时都会由Web浏览器完全重新加载、服务和重新处理。这涉及到一些缓存，但通常每次加载页面时，您都会从边缘服务器(不一定是由应用程序编写人员控制的服务器)获取运行web应用程序的软件，然后下载该软件并在浏览器沙箱中运行该软件。
在桌面应用程序或移动应用程序中，应用程序开发人员拥有一个私人签名密钥，该密钥已由一些操作系统级别的可信签名机构(如Apple Store或Google Play Store)证明。应用程序开发人员使用此密钥对应用程序包进行签名。当您将软件包放到您的设备上时，您的操作系统会使用开发者的公共验证密钥检查软件包的签名，检查应该对其签名的开发者是否真的对其进行了签名，并检查这些密钥是否得到了您已经信任的签名机构的证明，因为您需要信任该机构的密钥是随您的操作系统一起分发的。
因此，这种信任关系与苹果、谷歌等相关，因此你既可以相信这些软件来自开发者，也可以相信至少开发者用来签署该软件的密钥是受操作系统开发者信任的。酷，太棒了，听起来不错。每次开发人员推送该软件的更新或您下载该软件的最新版本时，您也会执行此检查，并检查此特定版本的软件实际上是您应该信任并安装在您的计算机上的版本，而不是任何版本。这为我们提供了关于您在计算机上运行的软件的安全性和来源的非常好的保证。
嗯，我们在网上没有这方面的东西。对于这种软件交付安全模型，我们拥有的最接近的东西是我们信任下载此软件所通过的连接，但仅此而已-而且我们只信任最近的跃点，因为在我们的计算机和开发人员的发布服务器之间可能有许多连接跃点，或者它可能缓存在边缘服务器上。我们信任TLS(您正在使用TLS为您的Web应用程序提供服务，对吗？)，当您下载签名软件时，您也可以信任TLS；但是对于Web，您只信任连接，如果您不能信任该连接，则没有其他东西可以拯救您。由于您只信任最近的一跳，如果任何人都能连接到您的计算机和Web应用服务器之间的那个连接，那么他们可能会为您提供不同版本的Web应用，而您也信任它，因为您唯一信任的就是TLS连接。正因为如此，使用网络应用程序也比使用安装的应用程序更容易区分目标：因为你只需要妥协最后一跳的本地化，你可以缩小你的范围和曝光率，比方说，只在纽约市加载网络应用程序的人。要让人安装受攻击的已安装应用程序，您需要获得可验证的签名更新并在本地交付；第一部分比较困难。这是Web平台软件安全模型通常被认为不足以满足需要无限期保护本地敏感数据或材料的高安全性应用程序的根本原因。
然而，即使是在移动应用和桌面应用中，我们几乎每次使用这款应用都越来越接近更新。例如，Chrome和大多数现代浏览器被称为“长青”，因为它们更新如此频繁：每次重启浏览器时，你几乎总是在运行最新版本的浏览器。它几乎可以保证会运行一个新版本，该版本是在后台下载的，一旦重启应用程序就可以运行了。很多移动应用程序也是如此：现在很多应用程序更新非常频繁，包括你的移动浏览器。您在后台下载新版本的软件，然后经常运行新版本的软件，这些新版本是从互联网上新下载的。
因此，已安装的应用程序(如移动应用程序和桌面应用程序，可以签名和检查)和网络应用程序之间存在一些趋同。几乎每次您运行已安装的台式机/移动设备时
通常情况下，在网络上安全地做这些事情更难，因为在网络浏览器中保护长期秘密更难。整个平台都是转瞬即逝的：应用程序转瞬即逝，你下载的软件转瞬即逝，你正在进行的通信也转瞬即逝。在软件级别上，如果每次加载页面时，您所依赖的保证安全的软件都在变化，并且您无法验证这些更改来自何处，那么很难在浏览器中保证它的安全。有人有很多机会破坏你的软件，因为在正常的应用程序使用中，所有的软件都是通过互联网获取的，并且是隐式信任的，因为只有最后一个连接跃点是可信的，这是因为在正常的应用程序使用中，所有的软件都是通过互联网获取的，并且是隐式信任的。
考虑一下这样的场景：对手可以只选择一个机会来窃取您与服务器的连接，这是他们唯一一次修改Web应用程序代码以从您的浏览器存储中泄露您的长期密钥。下次加载该页时，您再也看不到该受危害的代码。但是，如果您的实际应用程序不一定需要长期身份怎么办？
对于短暂的音频或视频呼叫(而不是文本消息等长期永久记录)，您是否需要长期身份密钥，特别是当您将身份与现有的外部身份提供商捆绑在一起时？在这种情况下，身份提供者负责验证您是否就是您所说的那个人，并验证您是否有权以这个或那个身份访问事物和采取行动。即使独立于身份提供者，您的ID也可能只是访问会议数据的“您”，一个仅适用于该会议的ID，而会议主持人能够识别您和您的接入点；一个由主持人分发的个性化会议ID代码，应该是不可猜测和不可伪造的。如果您只为该会议生成您的ID密钥，会怎么样？我们相信，获得会议信息的人就是我们想要获得信息的人，因为我们信任首次使用该通道，然后他们就可以访问呼叫，生成密钥，这样他们就可以签名，我们可以单独在该呼叫的上下文中验证他们是否就是他们所说的那个人，然后像以前一样进行所有的E2EE通信。会议主持人可以在每次会议中管理这些身份：我们可以使用仅在此呼叫中存在的按用户身份引导用户，并阻止他们重新加入，因为他们应该只知道自己的每次会议参与者ID，不能伪造其他ID。
当通话结束时，我们扔掉所有的密钥材料。因为所有的关键数据在会议结束时都会被丢弃，所以将来没有什么需要保护的，甚至连软件也不需要保护！以每次会议为基础的信任链要浅得多：您为这一次呼叫下载的软件，以及您在传输会议信息时所通过的渠道。如果呼叫是短暂的，则可以仅在会议期间信任Web应用程序。
这种设计似乎更容易在web应用程序中实现，因为这基本上归结为豆腐(首次使用时信任)，但这种信任不会跨用途持续存在，所以它更像Toau(任何使用时信任)。信任是短暂的，相遇是短暂的，身份是短暂的。对于很多会议来说，这是完全可以接受的。这也类似于我们在常规世界中的电话信任模型：无论是谁接到你的电话，都是在拨号时有权访问被叫方电话号码的人，然后一旦通话结束，你就结束了，所有的“信任”几乎都被抛弃了。如果将来其他人拿到了那个电话号码，那么你要么信任他们，要么不信任他们。你可能会认为下次拨打这个号码会得到相同的人，但这并不能保证，知道这一点，如果另一端的声音和/或脸与我们的预期不符，我们可以挂断电话，但我们知道，如果另一端的声音和/或面孔与我们的预期不符，我们可以挂断电话。这是视频通话与持续文本聊天相比为我们提供的优势之一：能够在通话中快速建立信任，因为更难实时伪造视频或语音(并非不可能，但更难)。
如果要将这些允许身份绑定到其他长期ID，您可以使用身份提供商(如G Suite帐户、私人公司联系服务器等)来管理帐户，然后您可以证明临时会议ID密钥已绑定到这些受管理的身份，根据定义，这些身份必须经过身份验证和授权。但是在会议结束后，您可以扔掉每个会议的ID密钥，或者，如果您与您的ID提供商进行了某种集成，您可以根据需要随着时间的推移记录它们，作为一种密钥透明度。如果会议为每个参与者生成不可猜测和不可伪造的ID(我们可以使用HMAC之类的密码来实现这一点)，那么我们就可以像管理任何与Long-Term I相关联的任何人一样管理每次会议中的这些用户
