Web聚合运用跨域通信机制

导语：Web聚合运用跨域通信机制一文来源于网友上传，不代表本站观点，若需要原创文章可咨询客服老师，欢迎参考。

1引言

在传统的web1.0应用程序中，每个Web站点相互隔离，用户访问Web站点仅能得到来自本站点的信息。即使需要访问其他站点，也是通过编辑拷贝已存储在本地的信息或者用户调换网站地址的方式来访问内容，而不是直接访问信息源数据。在新的Web2.0潮流之下，希望网站之间打破隔离进行数据融合，使之能够共享信息。在这种背景下，聚合型网站设计方式应运而生，这就是新型的Web应用程序——聚合应用(mashupapplication)。Mashup这个名词来源于流行音乐，将不同风格的音乐拼接，混杂在一起，构成自己独特的新曲子；Mashup在Web环境中代表着整合不同来源的内容以提供交互式体验的Web站点或应用程序[1]。利用其他网站开放应用接口所提供的内容进行混搭，从而创造出独特的、具有新价值的Web应用。Mashup把不同源或站点的信息进行融合以保证信息共享，打破站点之间“孤岛林立”的现状，由此浏览Web站点更加直观便捷，用户体验更加富。典型的Mashup应用当属Housingmap，它将第三方网站Craigslist的租房信息和GoogleMaps提供的地图信息有机地组织起来，让租房的信息直观显示在地图上，创造出一个崭新的、互动性强的房屋搜寻站点[2]。根据以上实例背景，本文建立一个Housingmap聚合应用模型，由电子地图与租房信息2部分组成，如图1所示。传统的Web浏览器安全机制遵守同源策略(SOP,same-originpolicy)。同源策略规定JavaScript(JS)代码只能访问其来自同源服务器上的数据，把来自不同源的内容相互分离。这种策略给JS提供安全保障的同时限制了基于JS的跨域访问。Mashup是对多个站点资源的优化组合，需要从多个分散的站点获取信息源，而不要求各个站点之间相互信任。传统同源策略过渡的安全设计没有考虑多个站点之间交互时整体的快速通信需求，也没考虑新的信任模型下的安全问题。如图1所示，电子地图与租房信息的数据分别来自www.map-和www.housing-2个不同源的网站，在现有的同源策略下是不能够相互访问和通信。怎样整合相互独立的第三方数据、实现不同源数据之间的通信是聚合应用需要解决的问题。另外，恶意攻击者可能重写来自其他源的网页属性，例如来自www.map-的脚本可能重写www.housing-网页的location属性，操纵原页面跳转到某个恶意的页面，而导致框架钓鱼攻击。如何保证不同源数据间通信的安全性与完整性是聚合应用需要解决的另外一个问题。针对上述问题，研究人员在聚合应用跨域交互方面做了大量研究，其中，文献[3]利用内嵌框架(iframe)实现客户端通信。这种方法的缺点是不但很难保证消息的完整性，而且攻击者很容易进行框架钓鱼攻击。文献[4]提出了一种跨域通信方案，兼容主流浏览器。聚合应用能与一个或多个网络服务应用交互，交互过程包括2个阶段：设置阶段(建立中间帧，非信任帧，传输JS通信对象)与数据交换阶段。文献[5]提出了一种基于值的跨域通信机制，对象序列化后进行传输。其中，分批处理数据减少了整合者与小部件之间信息交换次数，由此提升了系统性能。美中不足的是，如何解决跨域通信带来的安全问题以及如何共享JS对象还有待进一步研究。本文在研究相关工作的基础上提出了一种适合于聚合应用的安全跨域通信(SCDC，securecross-domaincommunication)系统。首先，从各个不同的域入手，同一信任域的内容封装为组件表示，建立聚合应用的安全组件；其次，利用分层通信栈实现域间通信，即聚合应用与组件间通信；最后，利用封装技术安全实现组件间细粒度对象共享。该方案具有安全可靠性强、效率高、支持对象共享的特点，旨在为聚合应用提供一种安全可靠的跨域通信系统。

2相关跨域通信方案

跨域，简单的理解就是在JS同源策略的限制，域名下的JS无法操作或是域名下的对象。跨域通信面临着许多挑战，下面分别介绍3种传统处理跨域的方案：服务器端、动态创建脚本、段标识通信。跨域请求发送至本地服务器端，然后由服务器端请求相应的数据发送到浏览器端。在服务器端的帮助下，浏览器端所有请求发送至同一域，实现了跨域通信。此方案适用于几乎所有的跨域访问，支持各种类型格式的数据，但是经过了中间，延迟高、开发工作量大，并且加重了本域服务器的负荷。至于动态创建脚本方案，虽然浏览器禁止跨域访问，但仍可以引用其他域的JS文件，由此能够通过创建script节点完全实现跨域通信。该方案实现非常简单，但返回的数据格式只能是JSON数据，对于其他格式的数据无能为力。最常见的跨域通信解决方案是利用URL段标识符(fragmentidentifier)[6]交换信息，传输的数据一旦超过浏览器对URL长度的限制则必须对数据进行分段传输。这种方法的优势在于同一页面浏览不同分段时不必刷新整个页面。不足之处在于不同浏览器URL长度限制有所不同，数据容量都是有限的。数据直接暴露在URL中，一些浏览器会删除段标识符，不能保证应用程序的一致性与可靠性。面对复杂的聚合应用环境，以上这些方案或多或少存在下列问题：首先是开销问题，服务器方案经过了中间，开发工作量大，因此并不适合于大规模的Mashup应用；其次是灵敏度问题，段标识通信机制中数据容量都是有限的，消息一旦超过当前浏览器最大传输限制则必须分段进行传输。在动态的Mashup网络环境下，通过轮询URL探测分段是否变化，响应时间往往不确定，会有一定的延迟；最后一个问题是安全性，无论是动态创建脚本还是段标识通信，消息内容或者不安全或者不是预期的。Mashup应用的通信环境往往是不完全受信任的环境，如不采取特别的安全防范措施容易导致恶意攻击或私有信息泄漏。随着浏览器跨域通信的需求越来越强烈，HTML标准的下一个版本HTML5新增了跨域通信功能，即提出了跨文档通信(crossdocumentcom-munication)机制。在希望发送消息的窗口或内嵌框架中调用postMessage方法，接收方设置一个事件处理函数来接收发送过来的消息[7]。为了解决上述问题，本文先将不同源网站视为独立的信任域，并封装为可相互直接交互的内部组件，利用HTML5新增的跨文档通信机制，实现组件间的通信。这种方案主要有如下优势：①安全系数高，该方案适用于不完全受信任的环境，开发人员可以选择性接收来自域的消息，如果消息的内容不安全或者不是预期的，则可以放弃相应的消息；②可靠性强，与其他跨域通信方案不同，此方案以一致的方式处理未丢弃的消息；③性能提升，此方案允许双向通信，具有安全、简单、快速的特点，不依赖于帧或其他页面，也不需要轮询URL查找数据。

3SCDC系统设计与实现

3.1系统概况

本文系统为聚合应用及其各个组件(component)实现了SCDM系统的JS库，解决了跨域通信与域间对象共享的难题。SCDM系统把不同信任域的内容封装到不同组件，且每个组件有其输入输出端口，为组件通信提供了接口；事件中心维护系统通信，通过建立分层通信栈来实现组件间的通信，跨域通信依赖于跨文档通信机制；对象共享是聚合应用域间通信的高级应用。系统支持多个较新版本的浏览器，InternetExplorer8.0+(IE8.0及以上版本)，Firefox3.1+，Safari4.0+，Opera9.5+，GoogleChrome1.0+。对于不同的浏览器，实现代码大体上类似。图2以2个组件之间的通信为例说明系统的整体框架，多个组件之间通信时架构与此类似。SCDC系统包含3个主要模块：域封装模块、域间通信模块、细粒度对象共享模块。域封装模块是系统的入口和核心。聚合应用由不同源(域)的内容组成。鉴于安全性考虑，不同信任域的内容封装到不同组件中以起到域间隔离的作用，并且组件的输入输出端口为域间通信模块提供接口。域间通信模块为组件模块和对象共享模块提供服务。判别通信双方是否处于同一个域，完成域间通信识别的任务，并且为不同域之间通信搭起桥梁，完成系统跨域通信的任务。细粒度对象共享模块是系统的高级应用模块。目前组件间并不能直接跨域共享对象，但是借助基于值传输的跨文档通信机制能在对象序列化为字符串后能进行对象的共享。为了更好地安全地实现信息共享，本模块根据域封装模块所提供的组件，及域间通信模块提供的服务获取通信状态，实现组件间细粒度的对象共享。细粒度对象共享的过程是先建立封装对象，并且由策略系统明确定义策略以控制对象共享，然后对象序列化后通过域间通信模块进行传输。

3.2域封装模块

信任域(trustdomain)[8]可认为是处于聚合应用完全控制下的安全域(域指的是DNS域或IP地址)。信任域与DNS域有着密切联系，前者在后者的基础上加入了安全防范措施。组件可以定义为同一信任域内容的封装。组件源由第三方提供，每个组件逻辑上相互独立。组件拥有独特的输入端口和输出端口，为后面的异步传输消息垫定基础。为了安全性考虑，系统需要隔离各个组件以防止恶意攻击。解决方法是将不同的组件置入不同的内嵌框架iframe中以达到隔离目的，任意组件不能改变domain属性以攻击其他组件。对于上例，Housingmap聚合应用模型组合了来自www.map-的电子地图与www.housing-的租房信息，分别把这2个来自不同信任域的内容封装为电子地图组件与租房信息组件。然后，电子地图组件与租房信息组件分别置入各自的iframe起到域间隔离的作用。对于来自同一服务器的数据，但属于不同信任域，也可以建立多重DNS域从而保证组件间隔离。例如，对于来自服务器www.map-与信任域为t1、t2的数据，能够建立2个DNS域t1.map-和t2.map-，分别封装到不同的组件，为下文的域间通信打下基础。

3.3域间通信模块

域间通信模块负责各个信任域之间的通信。该模块借鉴与结合了浏览器安全模型的实现方法，在组件端口与事件通道之间通过发送/接收消息方式实现聚合应用与组件间的内容交互。事件中心(eventhub)由仲裁域间通信的事件通道(channel)组成，是维护系统通信的核心部件。事件中心实际上是在多对多通道上发送与接收消息的pub/sub系统，但又不同于传统的pub/sub系统。事件中心管理连接组件端口与事件通道之间的通信，组件端口与事件通道的命名空间相互隔离，由此避免了组件端口的冲突，提高了组件的重用性。组件有其输入端口(读端口)与输出端口(写端口)，从组件的输出端口发送消息到与之相连的事件通道上；组件的输入端口从与之相连的事件通道接收消息，由此构成了组件与聚合应用，以及组件与组件之间的通信。如图3所示，组件1发送消息到事件通道1、3，组件1从事件通道3接收到消息。在一般情况下，组件可发送消息到多个事件通道，同时也可从多个事件通道接收消息。如何保证组件之间通信顺畅，文献[8]中采用的方法是借助于URL段标识符实现域间通信。消息一旦超过当前浏览器最大传输限制则必须分段进行传输，直到上一分段读取完毕后才能读取下一个分段。图3简化通信本文的解决思路是通过跨文档通信机制实现聚合应用与组件的域间通信。对于聚合应用，组件在域封装模块已置入iframe帧中，以组件帧表示。而且每个组件均包括隐藏的通道帧，通道帧与聚合应用主页面()属于同一个域，因此通道帧与聚合应用主页面实现域内同步通信。而通道帧与组件帧通过跨文档通信机制实现域间通信。具体实现架构利用JS库底层实现聚合应用与组件的域间通信，实现架构类似分层通信栈，由事件中心层、事件通信层及跨文档通信层3部分组成，在组件及聚合应用中的同等层使用较低层进行通信。如图4所示，事件中心层管理组件端口与事件通道，对于聚合应用，事件中心层的主要任务是装载组件与卸载组件，建立事件通道与删除事件通道，连接组件端口与事件通道等；对于组件，这一层负责处理该组件各端口发送与接收的事件。事件通信层负责多路传送多个组件端口的消息。跨文档通信层是为聚合应用与组件实现跨域通信，也就是通道帧与组件帧的通信过程。下面列出实现域间通信的常用API，如表1所示，重点描述下组件状态的生命周期，参照getComponentState函数。从loaded到wired状态转换由聚合应用控制，意味着组件能够开始发送消息；从wired到startedCleanup状态也是由聚合应用所控制，意味着开始卸载组件；而从startedCleanup到doneCleanup状态则是由于超时或组件处理不当引发的，这个过程由组件所控制；剩下的状态转换则是由系统自身初始化的。为了避免轮询组件状态，在组件及聚合应用状态转换时注册监听函数。组件与聚合应用都通过发送与接收消息方式进行通信。用一个简单的例子描述利用分层通信栈的通信过程。首先，聚合应用主页面中装载2个组件，初始化通信，发送消息message给组件，主要调用如下API：

3.4细粒度对象共享模块

Web主体间共享资源通常有2种处理方案：共享所有资源，或者相互隔离，实现零共享[9]。通常各个主体共享所有资源容易导致跨站脚本攻击(XSS)，由此研究人员提出了多种方法来隔离各个主体。进一步，如何在各个隔离的主体间共享部分对象，针对这个问题，提出了细粒度共享对象策略。首先，利用SCDC系统的JS库中对象封装策略，建立与原对象一致的、可控制的封装对象view[10]。一致性表示封装对象view可以取代原对象进行访问；可控制性意味着可以定义策略限制接收方访问共享对象的某些属性或方法。其次，建立细粒度策略(基于通知的策略)约束访问共享对象。细粒度策略由方面系统(aspectsystem)实现，能控制对象的行为。如图5所示，为对象map建立封装对象map_control.view来取代原对象的访问，并通过为原对象的属性与方法引入getters、setters、caller访问器利用map_control.definePolicy设置策略以控制访问封装对象view。view可以看作是与策略的组合体，相当于一个封装器，策略即为一个函数。为每个不同的对象建立一个新的封装对象。同样地，对于一个函数对象，相应地定义一个新的封装函数以取代对原函数的访问，并为其定义策略函数。如图5所示，电子地图组件与租房信息组件共享某一对象，如地图类型(包括普通地图、卫星地图、地形地图等类型)。首先，电子地图组件建立其封装对象view(map_control.view)以代替原对象。然后通过定义策略控制对封装对象的访问，如定义策略即编码白名单，租房信息组件只能读其属性Type，调用方法getType，但不能重定义方法或属性，也不能操作电子地图组件的其他对象。建立封装对象view后，怎样实现组件间view对象的共享。针对这一问题，浏览器并未为跨域传送消息设定特定的事件通道，但能够借助于跨文档通信机制与分层通信栈结构，对象能够序列化后实现共享传输。如图6所示，组件1与组件2共享封装对象时，利用SCDC的JS库发送方序列化对象后通过分层通信栈发送给对方；接收方收到消息后把字符串反序列化为对象。由此，当租房信息组件要请求map_control.view的属性Type时，首先发送请求给电子地图组件，依据view策略得到结果，然后返回给租房信息组件。图6封装对象view共享过程示例细粒度对象共享一定程度上解决了对象传输的安全性，同时也引入了一些新的问题，如异步问题。1)封送处理库负责序列化与反序列化对象，并对基本的JS操作如调用函数、读写属性、抛出异常等进行译码。如果组件1远程共享一个表格对象table给组件2，组件2请求封送处理库获取table.parentNode.parentNode.parentNode.cookie的值，这将泄露了文档的cookie值；如果组件1远程共享其封装对象table_control.view，view能执行策略代码仅能访问table对象的白名单属性或方法。封装对象机制限制访问对象，解决了远程对象共享带来的部分安全问题。2)浏览器的同源策略规定每个框架有独自的类型链与全局对象集合，一定程度上确保了框架间的隔离。由于聚合应用需要跨域访问对象，同源策略受到限制。SCDC系统的细粒度对象共享模块在访问对象之前进行检查，以确认是发送方对象的封装对象view或接收方对象的。如果get、set、call等触发某个对象既不是veiw也不是，则拒绝此对象，进一步保证对象传输的安全性。3)由于跨文档通信机制本身的异步性，通过分层通信栈实现的远程对象共享引入了异步问题。如图7所示，图7(a)中转化为远程对象的封装对象view，调用2个“.”则是异步调用。这就需要转化代码结构，调用者必须提供一个回调函数以保持传输的完整性与连续性，这就是连续传递模式(CPS，continuationpassingstyle)。如图7(c)所示，客户端自动全局转化为CPS形式进行交互，在调用y()与z()时，为了保持连续性注册回调函数以控制当前线程。

4安全策略

4.1SCDC系统整体安全策略

上文已经提到组件隔离及组件间通信，至于哪些组件之间可以交互，哪些组件之间禁止交互，则由SCDC系统的安全策略所定义。具体的策略来自多种高级策略，例如企业级聚合应用，安全策略则可能是企业级策略、部门策略、终端用户策略的组合。一方面，组件提供方明确它们的组件怎样整合到聚合应用中；另一方面，聚合应用提供方可能不同等看待各个组件，可能会阻止部分组件相互交互。总之，安全策略依赖于具体的实体应用程序，包括组件间访问控制策略与组件到服务器端的访问控制策略。组件间访问控制策略包括建立与删除组件、建立与删除事件通道、哪个组件能在某个事件通道上发送或接收事件等。事件中心负责执行策略，一种方式可以在聚合应用的代码中明确定义策略；另一种方式为事件中心定义一个配置策略文件，可以从中读取安全策略，这样分离了策略定义与聚合应用中真正的代码实现。组件到服务器端的访问控制策略包括认证组件与受限访问权限。在组件装载之前，必须先核实认证，并且根据组件所在域确保组件装载到合适的iframe帧中，使其不易受到人为攻击。这种方式不管是客户端聚合应用还是服务器端聚合应用都有统一的访问控制策略。上述定义了SCDC系统的整体安全策略，但是跨域通信容易导致框架钓鱼攻击，共享信息容易泄露个人隐私信息，针对这2个问题本文特别加入了针对性的安全策略。

4.2防范框架钓鱼攻击

框架钓鱼攻击，对于利用iframe来隔离不同信任内容的网站来说是很常见的漏洞，也是比较严重的攻击类型[11]。它一定程度上破坏了应用程序的完整性，但并不意味着应用程序被恶意组件所控制。框架钓鱼攻击还能窃取输入的信息，包括个人认证信息或密码等。在聚合应用中，这种攻击不仅能改变组件帧的location属性，也能作用于事件通道帧与聚合应用主页面之上。对于聚合应用，组件、事件通道、聚合应用主页面三者易发生框架钓鱼攻击。由于URL栏仅能提供微弱的钓鱼保护能力，而且不像传统的钓鱼攻击，聚合应用中框架钓鱼攻击的时机是任意的。本文在各个页面中利用onunload事件处理器，超时设置及通道帧三者相结合共同防范框架钓鱼攻击。首先，当组件受到攻击时触发onunload事件并发送通知消息给聚合应用，然而组件与聚合应用通过事件通道进行异步通信，不能保证在组件卸载完之前通知消息传送完毕。换个角度考虑，替换某个组件时将会触发通道帧的onunload事件，通过调用JS函数通道帧与聚合应用实现同步通信，因此在onunload事件完成之前必能成功通知聚合应用。根据上述分析得知，可以用统一的方法来处理针对组件与事件通道的攻击。其次，另一种可能的情况是在通道帧装载完毕之前取代组件，这时在聚合应用中设置一个超时处理成功初始化事件通道通信。一旦超时，触发错误处理程序以决定是卸载或重载组件。利用事件通道的onunload事件处理程序面临一个挑战，当用户操作离开聚合应用页面时，该事件也被触发。为了避免错误判断，可以延迟计时器的警告时间，如果用户仍停留在聚合应用中，超时则通知聚合应用存在潜在的框架钓鱼攻击。最后，检测聚合应用主页面的框架钓鱼攻击。有时很难区分是框架钓鱼攻击还是用户任意操作离开这个网页。针对这个问题，设计一个警告框来通知用户URL的变化，没有浏览器的支持很难区分上述2种情形。虽然这种方法对系统性能有一定的影响，但是这是唯一一种确保用户安全性的方法。

4.3对象共享安全性

随着计算系统的不断发展，资源共享变得越来越重要，而由此导致的安全问题也变得不容忽视。SCDC系统的对象共享模块容易泄露私有信息，所以做好安全防范工作显得尤为重要[12]。为了保证私有信息不被泄露，递归封装对象是理想的选择。递归封装即为某个对象的所有属性（包括继承的属性）及返回值定义访问器或函数，并且建立封装对象须遵循引用一致性策略。引用一致性指以对象ID为索引存储一个原对象与封装对象的关联表，如果请求的对象不在表中则生成一个新的封装对象，否则返回同一个对象以保持引用对象的一致性。同时，双重的输入输出封装构筑另一道安全屏障。除了不允许原对象引用泄漏(exporting)外，同时不允许不受信任的代码进入(importing)访问。输入封装是为第三方对象(参数和重定义的属性)设计的，即当一个封装对象的某个方法接收参数或某个属性重赋值时都必须进行输入封装。下面举个实例说明怎样保证对象共享安全性，例如定义对象obj，包含一个属性prop与一种方法proc，其中方法proc可读写，属性prop则不可读写。

5实验

实验平台：全部实验在频率为1.5GHz的IntelCeleronM的处理器，512MB内存的机器上实现的，所用的操作系统是WindowsXP，采用服务器ApacheTomcat5.5发送数据到浏览器(InternetEx-plorer8.0，Firefox3.6.3，Safari4.0.5，Opera10.54，GoogleChrome6.0.401.1)。服务器端需要修改服务器，对服务器不透明；动态创建script节点，需要引用其他域的JS文件且支持的数据格式有限；而段标识通信机制是传统跨域通信方案中最常见的通信方案，应用广泛，对服务器透明且不需引入其他JS文件等，可比性强，所以本文选择采用段标识跨域通信机制的系统(FIC系统)与本文系统进行测试，对比了两者在数据吞吐率(datathroughput)和事件发生率(eventrate)以及组件装载延迟(componentloadlatency)3方面的实验数据，同时还测试比较了SCDC系统支持对象共享前后的JS执行时间开销。

5.1数据吞吐率

组件数从1、2递增到32个，轮询时间间隔取10ms、20ms、40ms、80ms不等，测试数据吞吐率(横纵坐标为对数刻度)。开始从聚合应用传输4KB，8KB等小数据量到各个组件中，耗时非常短。然后传送1MB的数据，对比系统所用的时间。所有的实验数据都是测验5次后取平均值得到的，减少了随机因素的影响。实验结果表明随着组件数目的增加，SCDC系统的吞吐率随之增长，只是组件数越大，吞吐率增长幅度越小些。由于篇幅限制，在此只给出Firefox、GoogleChrome2个常用浏览器的测试结果，如图8(a)和图8(b)所示。同时对比SCDC系统与FIC系统，比较图8(a)与图8(c)，实验结果显示SCDC系统比FIC系统的吞吐率高出5倍之多。主要原因在于FIC系统受到浏览器URL长度的限制，当传输数据量比较大时，则要分段进行传输，而SCDC系统则无此限制，由此数据吞吐率明显提高。

5.2事件发生率

事件发生率，衡量对于小事件，系统所能支持的最大事件率。对于许多聚合应用来说，组件之间需要交换小事件以响应用户行为。事件发生率系统传输15个字符的小负载(简单的名/值对)进行测试事件发生率。测试结果如图9(a)和图9(b)所示，对于各个浏览器，存在一定的差异，随着组件的数量，轮询时间间隔的变化，事件发生率呈现上升的增长趋势，主要缘于跨文档通信机制是异步传输的机制。同时对比SCDC系统与FIC系统，实验结果显示，SCDC系统的事件发生率比FIC系统提高了5倍左右，如图9(a)和图9(c)所示。事件发生率系统传输1MB的大负载进行测试事件发生率。大负载测试结果如图10所示，比较图9(a)与图10，可以发现与小负载测试结果相似。由此可知，事件发生率与负载的大小无关。

6结束语

聚合应用组合了来自不同源的信息，由此信息的交互就成为一个瓶颈。本文在分析比较传统跨域通信方案优缺点的基础上，利用HTML5新增特性跨文档通信机制以及借助于分层通信栈结构实现了适合聚合应用的安全跨域通信系统；并且在系统中引入了细粒度的对象共享，通过封装对象及定义策略来约束控制对象，以代替对原对象的访问。同时，跨域通信与对象共享导致的安全问题也不容忽视，相应地增加了针对性的安全防范措施。通过一系列实验及对其结果进行比较分析可知，运用该SCDC系统的聚合应用程序，性能有了大幅度的提升，事件发生率、吞吐率明显较之前的通信方案提高了5倍以上；减少了组件装载延迟时间；同时，对象共享也仅引入很小的开销。今后的研究工作包括在聚合应用环境下进一步完善跨域通信系统的安全性，研究更全面的安全措施。同时在对象共享方面有所突破，使得所有浏览器本身支持细粒度对象共享。