Ben Adida谈论BrowserID和身份

这是“使命:Mozilla”系列访谈的第二篇,该系列访谈将Mozilla员工、他们开发的技术以及Mozilla的使命联系在一起。今天,Ben Adida 作为访谈对象,将讨论Mozilla的身份验证计划 BrowserID

Tristan Nitot – 嗨,Ben,你能简单介绍一下自己吗?

Ben Adida – 我从高中就开始编程,从大学开始,我就对密码学、安全和控制自己的数据很感兴趣。我在cookie出现之前就创建了第一个基于数据库的网站。从1997年开始,我运行了自己的IMAP邮件服务器,因为没有人像我那样做。2000年,我创建了自己的开源web开发公司,2003年回到研究生院研究安全投票,在哈佛医学院研究了健康数据的安全性和隐私,并于2011年3月加入Mozilla。我现在是身份和用户数据的技术主管,而且玩得很开心。

TN – 我的天...1997年就运行自己的IMAP服务器?这可是瞬间提升技术宅信誉的事情 ;-)

BA – 没错,大技术宅,我对此感到自豪!

TN – 所以你现在加入了Mozilla,专注于身份和用户数据。你能更新一下Mozilla在这些方面的进展吗?

BA – 在Mozilla,我与之交谈过的每一个人都意识到,开放式Web不仅依赖于Firefox网络浏览器。人们在网上存储了大量个人数据,使用数十种服务,而开放式浏览器不足以确保他们拥有真正的选择权,真正的控制权,他们可以根据自己的喜好塑造网络。因此,我们还需要努力为基于网络的服务提供用户选择权。这方面的第一个关键是可用的、联合的、分布式的身份系统。这就是我们使用BrowserID所做的事情。

TN – “联合、分布式”,用户拥有控制权...这听起来像是网络的最初支柱,对吧?我的意思是,与我们如今所见的情况相反,身份认证权集中在少数大型商业机构手中...你打算如何实现这一点?

BA – 没错,分布式/联合 *是* 网络的方式,但如果你看看今天的身份认证解决方案,大多数都极其集中,那些在协议方面更分布式的解决方案,往往因为所谓的NASCAR问题而在实现方面变得集中:你可以使用Google或Yahoo登录,如果你真的非常了解,那么也许你可以使用自己的身份提供商登录。我们认为,在易用性和采用方面,我们可以为用户和开发者做得更好。

TN – 那么隐私呢?

BA – 我们专门设计了BrowserID,以将用于身份验证所需的私有数据量减少到最低限度。例如,在今天的所有其他基于网络的身份认证系统中,你登录的网站都会向你的身份提供商发送信息。在现实世界中,等效的情况是:你在酒店办理入住手续,出示身份证以确认你的姓名,前台会打电话给政府机构,说“您好,这里是旧金山凯悦酒店,Tristan 现在正在办理入住手续,可以吗?”为什么政府机构或,在私人物体识别的情况下,商业实体需要知道你在哪里以及什么时候办理入住?在现实世界中,前台只需检查身份证上的印章,而无需打电话给任何人。BrowserID 为基于网络的登录重新创建了这种更加谨慎、更能保护隐私的数据流。

TN – 那么你如何才能两全其美:用户体验和用户控制?

BA – 首先,我们让浏览器成为协议的重要组成部分。毕竟,浏览器是用户的代理。在当今的网络中,你通常会打开一个标签页访问你的Gmail,然后另一个网站要求你使用Google或Yahoo登录,这不是有点愚蠢吗?为什么浏览器不能帮助协调这两个标签页?你已经登录了Gmail,当然你有一个Gmail电子邮件地址可以用来身份验证!在企业环境中,你登录了公司的网络邮件,当然可以使用该企业身份进行身份验证!浏览器可以帮助大幅降低用户的复杂性。

TN – 但是,我想使用另一个电子邮件地址,而不是我用来访问网络邮件的那个电子邮件地址...

BA – 没错,所以我们永远会给用户选择权。用户可以选择他们想要展示的具体身份。BrowserID的一个主要设计要点是,用户将电子邮件地址视为身份。他们通常有家庭和工作电子邮件地址,而且他们使用的方式不同。如果他们有兼职工作,他们通常会为此创建一个单独的电子邮件地址。因此,BrowserID 是基于用户已经了解的这个概念:登录只是以网站可以轻松验证的方式向网站提供电子邮件地址。

TN – 很酷。假设我是一个想要在我的网站上使用BrowserID的Web开发者。这有多难?我必须向Mozilla交出多少用户的控制权?

BA – 集成BrowserID大约需要5行JavaScript代码和10行后端代码,而且它现在就可以使用。它是目前所有可用身份认证解决方案中最容易的。短期来看,这意味着你依赖Mozilla服务器来提供BrowserID界面和验证用户的电子邮件地址。也就是说,这只是我们分布式系统的临时支架。

TN – 但是随着BrowserID成为浏览器的原生功能,并且身份提供商出现,这种情况会改变吗?

BA – 我们非常谨慎地设计了系统,这样一来,当浏览器开始原生支持BrowserID API时,我们就可以移除我们的支架,留下一个真正分布式的协议。最棒的是,网站不需要为此更改一行代码:当身份提供商和浏览器开始支持BrowserID时,我们的支架会自动消失。假设你是一个Web开发者,并且出于任何原因想要停止使用BrowserID:只需向你的用户发送一封包含他们新密码的电子邮件,就完成了。没有其他身份认证系统能够像它一样最大限度地减少用户和Web开发者的锁定。

TN – 所以,最小化锁定是BrowserID设计目标的一部分?

BA – 绝对!这是我们使命和宣言的一部分。我们不想拥有用户,我们想赋予他们权力。Mozilla处于一个独特的位置来构建这种身份认证系统,因为,正如我们大家都喜欢说的一样,Mozilla只对用户负责,我们可以利用Firefox来部署这些面向用户的方案。

TN – 太棒了!你建议那些想要在他们的网站上进行测试运行的网站怎么做?以及想要立即体验BrowserID的用户应该怎么做?

BA – Web开发者可以查看我们的文档。用户可以查看http://current.openphoto.me,这是一个非常有前景的分布式照片存储系统,由WebFWD维护,他们选择了BrowserID。只需点击醒目的BrowserID登录按钮,就可以体验一下用户体验。

TN – 我相信我们的读者会立即尝试!非常感谢你抽出时间,Ben。BrowserID 万岁!

关于 Tristan Nitot

更多Tristan Nitot的文章...


9条评论

  1. pd

    我开发的所有网站都不依赖于JavaScript进行登录,所以我想BrowserID不适合我?

    2011年10月20日 08:36

    1. zoulou

      你可以使用你喜欢的任何东西。你*不必*使用BrowserID,但如果每个人都使用它,没有人会损失(好吧,除了那些收集数据的公司)。

      从技术上讲,为了确保正确的身份验证链,必须使用javascript(即*客户端*必须完成身份验证工作,其他所有内容都是http-auth或服务器端)。

      2011年10月20日 10:37

  2. Stephan Sokolow

    我打算在我的网站中避免使用BrowserID,原因如下:

    1. 据我所知,对于没有JavaScript运行时的客户端没有支持。(我称之为“PDF并不意味着可下载的漂亮表单”问题、“为什么我必须将我的网站爬虫基于GTKWebKit的副本”问题和“除了HTTP还有其他协议,你知道”问题)。

    2. 我无法认可一个UI,它会因为我在我登录的每个网站上提供一个唯一的电子邮件别名而严重惩罚我。

    3. 我觉得它重新发明了很多轮子,OpenID+WebFinger 已经在这方面努力了(它甚至支持一个易于使用的模拟器,将WebFinger和OpenID委托结合起来,例如,让Gmail充当 foo@bar.com 别名的身份验证方?)而且,改进现有的OpenID+WebFinger 解决方案会更好。(我会在我的作品中支持这些解决方案)。

    4. 我很生气BrowserID 占用开发者时间和精力,而这些时间和精力本该用于“将OpenID处理集成到浏览器中,作为过时的HTTP基本身份验证UI的继任者”的工作,这是我真正想要的。

    它也没有帮助我摆脱KDE 基本上弃用Konqueror 作为文件管理器并编写Dolphin(它只允许标签包含DolphinPart,因为,否则,人们会看到它实际上是多么重新发明轮子)以及使用“我们不喜欢它前进的方向,讨论结束”作为他们的理由的往事。

    2011年10月20日 15:07

    1. Ben Adida

      Stephan,

      一些快速要点:

      (1) 是的,需要JavaScript。

      (2) 我们正在努力改进UX,如果你想要为每个网站提供一个唯一的电子邮件地址,我们正在考虑提供自动化的解决方案来创建化名。

      (3) BrowserID 相比OpenID 有几个重要的优势:
      http://identity.mozilla.com/post/7669886219/how-browserid-differs-from-openid

      此外,我们才刚开始解释主要身份提供者将如何运作。我们绝对打算将其作为一项关键功能
      http://lloyd.io/primary-identity-authorities-in-browserid

      (4) 我们必须考虑整个用户体验。我们认为 OpenID 的用户体验还不够好。

      我们希望您能重新审视 BrowserID。

      2011 年 10 月 20 日 下午 6:09

      1. Stephan Sokolow

        对于 #1,我是一个重度 NoScript 用户,我也喜欢编写各种非浏览器 HTTP 用户代理(例如网络抓取器),因此 Javascript 被要求作为不仅仅是 polyfill 的存在对我来说是不可接受的。

        然而,如果未来的发展解决了这个问题,鉴于你所说的其他内容,我认为我会全力支持它。(尽管我讨厌特定网站的密码,并且 OpenID 的效率低下,但它们都更容易在没有 Javascript 引擎的抓取器中进行脚本编写)

        对于 #2,这将是我使用它的一个重要理由……但请记住,当你提到“化名”时,必须包含电子邮件别名。我向每个网站提供唯一地址的主要原因是,这样我就可以在收到垃圾邮件或取消订阅表格出现问题时撤销他们给我发邮件的权限。

        至于 #3,我承认 WebFinger 出现得有些晚,但我不会将其视为 BrowserID 的优势,因为考虑到市面上所有半 drop-in 的 OpenID 库,支持 WebFinger 更多的是一个版本升级,而不是一种新的身份验证方法。

        我不完全清楚 BrowserID 如何提供更好的隐私,但我相信你在这方面的说法。

        最后,关于 #4,我承认 OpenID 确实存在用户体验问题。我一直对此有些担心。

        为了我自己使用,由于我不常在旅途中使用计算机,我一直计划通过使用委托、DynDNS 子域和一个特殊用途的 OpenID/HTTP 守护程序来解决这些问题,该守护程序在网站尝试进行身份验证时会弹出一个本地 GTK+ 允许/拒绝对话框。

        (如果我需要旅行,我会通过 SSH 连接并在一个隧道化的 X 会话中运行 OpenID 提供程序)

        我想,除了化名之外,我对它的最大问题是,如果你想成为下一个主要的认证机制,我强烈认为你应该尝试做一个更像现代 Kerberos 的东西,它可以与共享主机协作,并可以使用 Javascript 作为 polyfill 用于那些没有直接实现它的浏览器……而不仅仅是一个去中心化的、保护隐私的“使用 Facebook 登录”按钮。

        说到这里,你对 OAuth 有什么计划?我还没有用到它,所以据我所知,它依赖于 OpenID,我担心其他人可能会得出相同的结论。

        2011 年 10 月 21 日 上午 0:50

        1. Stephan Sokolow

          哎呀。真的应该有一个“最初一两分钟,你可以编辑”的功能,用于修复诸如在你的思维卡在“with no”和“without a”之间时输入“without no”之类的错误。

          2011 年 10 月 21 日 上午 0:52

        2. Ben Adida

          您好,Stephan,

          感谢您查看这些额外信息。关于 BrowserID 和隐私,您可能觉得有用的一些更多信息

          http://identity.mozilla.com/post/7899984443/privacy-and-browserid

          http://identity.mozilla.com/post/11145921163/browserid-design-for-privacy

          关于 JavaScript,请记住我们主要的用例是用户与网站交互。大多数网站现在在没有 NoScript 的情况下都无法正常工作,因此我们很难针对这种用例进行优化。对于自动访问,我们可能需要考虑一个额外的 REST API,它可以接受 BrowserID 断言并向您返回某种会话令牌。如果您愿意,我们很乐意就此提出建议吗?

          2011 年 10 月 21 日 上午 9:43

          1. Stephan Sokolow

            我绝对喜欢你在第一篇“Mozilla 的身份”文章中提到的观点。这正是我经常说的话。我将在有更多空闲时间的时候观看视频。

            但是,我认为我们需要进行一些研究,然后才能就禁用 Javascript 后有多少网站无法正常工作做出断言。从我的角度来看,只有少数非常受欢迎的网站在禁用 Javascript 后会无法正常工作(杀死广告并破坏我从未注意到被破坏的功能,因为我从未尝试使用它们,不算数),我会不遗余力地反对任何使得逐步增强功能的完全实施变得更加困难的技术。(从我的角度来看,要求 Javascript 进行登录,而不仅仅是一个 polyfill,就像在 Javascript 中重新实现 :hover 以用于下拉菜单一样)

            至于 ReST API,从技术角度来看,这将满足我,但考虑到 WebFinger 的采用速度如此之慢,以及其他地方的先前经验,我担心如果它仅仅是默认 API 的替代方案,许多网站将因为懒惰或由于某种错误的信念而无法实现它,认为拒绝实现它会作为某种临时的验证码……此时,我们将回到起点,自动化工具的开发人员必须要么传递用户名/密码对,要么在其他最小、轻量级的工具中嵌入 WebKit。

            2011 年 10 月 21 日 下午 5:08

  3. R Stephens

    如果我理解错误,请原谅我,但 BrowserID 如何“解决”NASCAR 问题?

    很少,很少有用户会运行自己的 BrowserID 主机。大多数用户会依赖他们的巨型公司电子邮件提供商(例如 Google 或 Yahoo)充当主机。那么,它将如何真正地去中心化认证?这将如何赋予用户权力?

    如果 BrowserID 用户想要控制他们的身份,他们将不得不放弃他们当前的电子邮件主机并转移到其他地方。

    2012 年 1 月 21 日 下午 12:35

本文评论已关闭。