What's the Opportunity?
All mash-ups, whether an advertisement, mapping service, or a widget, share the same fate: They are built on technology that while capable, was never designed to meet the scenarios that have been driving web innovation and business models.
The issue is rooted in the inability to establish proper trust and quality boundaries among the disparate components. When a site consumes a third-party advertisement, affiliate program script, third-party script (e.g., maps), etc., they are creating an implicit trust relationship with that partner. They assume their partner will protect the privacy and trust of all their users. If any partner is compromised, so is your site. Beyond the trust relationship, you are also assuming that your partner will never create a conflict with your site’s construction or implementation.
This broken trust model occurs because of the existing sandbox security model in the browser. Sandboxing currently occurs at the web page domain boundary. This sandbox model is designed to prevent the communication between web pages from different domains. While the browser protects at the page level, there are no protections at the script level. Mash-ups work by including the third-party scripts directly into the context of your web page. These scripts have the same rights as native scripts –they can interact with the web page or other pages in your domain, examine your cookies, and even make requests on behalf of your users against your server and communicate any of this information to another domain.
Therefore, whenever any third-party script is included, whether it be a rich ad, affiliate program, mapping service, etc., on your page, you are explicitly trusting that script will neither do anything malicious nor destabilize your page. This is potentially dangerous, especially for your users and your services.
Gadgets and some ads are designed to avoid the security issue by always loading from another domain via an iframe. While this may seem like a reasonable solution it greatly limits the capabilities of the gadget (e.g., ads wouldn’t be able to “fly-out” or augment the existing experience), and it makes tighter integration with the page much more difficult (e.g., it would be hard for a host to set the coordinates of a map). The techniques to work around the boundary issues compromise performance, especially as multiple components are integrated. Furthermore, even iframed components can still compromise your user’s trust and your site’s experience by attempting to install ActiveX controls, interrogate your browsing history, and attempt click-jacking, or simply by consuming resources and degrading your overall experience.
While the predominant focus is on establishing boundaries for security, there is also a need for boundaries around quality of service. Today, a poorly coded add-on can easily bring down the entire application. Furthermore, since many sites are consuming code directly from the third party, your site can be affected by an update outside of your control. Since the entire application shares a single execution context, a script error, infinite loop, or other error often creates a cascading effect that essentially crashes the web page. Additional boundaries also need to be established to detect, prevent, and even report the potential degradation of the overall experience by third-party code.
The opportunity can be encapsulated into the following technical questions: How do sites expand their client experience with third-party scripts without compromising user trust or site stability? How do sites control the policies that define the integration? These are just some the questions we are trying to answer with the Web Sandbox.