New Web privacy system would revolutionize surfing safety
thereafter restricts the application receiving the information from communicating it to unauthorized parties. As a result, the site that shares data maintains control over it, even after sharing the information within the browser.”
Co-author Professor David Mazières (Stanford University Computer Science) said: “Security mechanisms for the Web must keep pace with the Web’s rapid evolution. Current measures, such as the Same Origin Policy (SOP), work by stopping JavaScript programs embedded within one Web site – malicious or otherwise – from reading data hosted by a separate Web site.
This brittle approach does not work for modern so-called “mashup” applications that combine information from multiple Web sites. Essentially, the SOP does not fit how many Web sites are built today. Prior attempts at weakening the SOP to allow this sort of sharing, such as with Cross-Origin Resource Sharing (CORS), make it trivial for malicious code to leak sensitive data to unauthorized parties.”
When building a modern Web site, Web developers routinely incorporate JavaScript library code written by third-party authors of unknowable intent. The study cites measurements indicating that 59% of the top one million Web sites and 77 percent of the top 10,000 Web sites incorporate a JavaScript library written by a third party. The team say such inclusion of JavaScript libraries is dangerous, as although the code includes features the Web developers want, it might also contain malicious code that steals the browser user’s data.
In such cases, the SOP cannot protect sensitive data, as the included library is hosted by the same Web site origin (that is, under the same Internet domain name).
Professor Karp said: “By blocking the building of Web applications that synthesize content from multiple Web sites, the SOP actually forces Web developers to make design choices that put users’ privacy at risk. That’s a problem we’ve solved with COWL.
“For example, one useful Web application would let users check they’re not being overcharged for items they’ve ordered from Amazon. The app would have to pull in information from the user’s bank statement and Amazon, reconcile the two, and present the result in the browser. To do this, a Web developer would need to write code that integrated data from the bank’s Web site with data from Amazon’s Web site but the SOP would block this, as the two data sources are hosted by different Web domain names. Today’s Web developers get around this by writing an app that asks the user for their bank and Amazon login credentials, so it can log into both services and collect information as if it is the user. This clearly compromises the user’s privacy as the provider of the app gains full access to the user’s online banking system and Amazon account.”
Deian Stefan, lead Ph.D. student on the project at Stanford, said: “What we’ve achieved in COWL is a system that lets Web developers build feature-rich applications that combine data from different Web sites without requiring that users share their login details directly with third-party Web applications, all while ensuring that the user’s sensitive data seen by such an application doesn’t leave the browser. Both Web developers and users win.”
The research team has shown how to use COWL to build four applications previously unachievable with strong privacy, including an encrypted document editor, a third-party mashup application, a password manager, and a Web site that safely includes an untrusted third-party library.
— Read more in Deian Stefan et al., “Protecting Users by Confining JavaScript with COWL” (paper presented at the OSD14, Broomfield, Colorado, 6-8 October 2014)