Max在演讲中解释说，他观察到一场计算领域的变革正在发生，正从桌面软件向服务器端软件和云计算变迁。但他提醒道：
Web软件是错漏不断的，为攻击者发现和利用。结果技术数据被盗或者被毁坏。很多人都使用没法做静态分析的动态语言，很随意地使用第三方的代码、插件……照直说吧，为了让网站快速上线运行，我们做了很多草率的拼凑。
他定义了一个有意思的指标来粗略衡量软件的脆弱程度–用代码行数（LOC）除以装机数量。软件安装的次数越多，就像Linux，缺陷被发现及纠正的机会就越大，因此缺陷的数量就会越少。他用了几页幻灯片来列举Web应用的LOC和LOC/装机数量，以此阐明其观点。
Max的研究目标是为新类型的应用和架构定义一个安全模型。像Facebook这类应用允许开发者在平台中插入代码，甚至允许第三方服务器在Facebook平台上提供功能，问题变得更加严峻。
为了应对新挑战，Max和同事一起，以分布式信息流控制（Decentralized Information Flow Control，DIFC）模型为基础，开发了开源Web应用安全基础设施Flume:
DIFC这种安全手段，让应用程序的作者能够控制应用的组成部分与外部世界之间数据如何流动。
对于隐私数据，DIFC允许不被信任的软件使用隐私数据，但由受信任的安全代码控制是否透露该数据；同时在数据完整性方面，DIFC让受信任的代码保护不受信任的软件，使之免于意外的伪造输入之威胁。
他们将服务器视为一个黑盒，并在响应构造的时刻跟踪数据。整个安全架构由一个安全网关和一个操作系统库组成，Web应用可使用该操作系统库标记数据。核心思路是把所有安全决策集中在网关，防止不希望出现的数据访问。
典型的Flume应用由两类进程构成。不受信任的进程完成大部分工作，它们受到DIFC控制的约束，且有可能自身并不知道DIFC的存在。另一方面，受信任的进程知道系统中存在DIFC，它们设立隐私及数据完整性控制来约束不受信任的进程。受信任的进程还有特权，可以选择性地违反经典的信息流控制–例如可以解密隐私数据（以导出到系统外），或者为数据完整性做担保。
系统的核心建基于一组相当简单的数据跟踪规则，用标签（Tags and Labels）来跟踪数据。
标签t本身并无内在的涵义，但进程一般会将每个标签与某个加密或完整性的范畴联系起来。举例来说，Tag b可能标示（label）Bob的隐私数据。Label是标签集（tag set）的子集。
如果Flume进程p有一个label是进程q的子集，那么p可以向进程p发送数据。Flume模型假定在同一台机器上运行着许多进程，并且通过消息或"流"相互通信。模型的目标是通过管制进程的通信以及进程label的变化，实现对数据流的跟踪。
图：通信规则
Max指出这种思路并不是新的，而是从80年代就出现了。
网关是Flume安全架构的关键元素。首先Web应用不需要了解浏览器的任何情况，因为网关能够制定策略。但网关的中心角色使我们需要引入另一种新抽 象：Endpoint。由于网关需要协调多个系统的交互（浏览器、认证仓库、Web应用……），不能向所有的进程公开同一组label。Endpoint 有助于定义特别的label组合，专用于在网关与特定进程间实施通信。
演讲的第二部分集中展现一个基于MoinMoin Wiki的 用例。Max以此用例说明Flume能解决的问题远不止已知的缺陷类型（缓冲区溢出、跨站脚本以及SQL注入）。他演示了MoinMoin Wiki日历功能中的一处安全缺陷，利用该缺陷，原本应该只限于特定用户组的日历条目可以被所有用户看到。而仅仅用了标准策略，Flume就能阻止不该显示的日历内容。
图：系统调用委托
Max总结说需要做的工作还很多。他们希望使系统更加灵活，以便能够处理Web应用中第三方上传的软件。他们也在研究如何让人们用同样的原则去共享数据。还有计划将触角延伸到浏览器层，把JavaScript纳入到架构之中。Max预见在金融行业会有许多用途。
