New web privacy system could revolutionize the safety of Internet surfing; University College London (UCL); press release; 2014-10-06.
Teaser: Researchers have built a new system that protects Internet users’ privacy whilst increasing the flexibility for web developers to build web applications that combine data from different web sites, dramatically improving the safety of surfing the web.
<quote>In practice, web developers turn their backs on privacy
Confinement with Origin Web Labels (COWL)
Content Security Policy (CSP)
Cross Origin Resource Sharing (CORS)
Discretionary Access Control (DAC)
Mandatory Access Control (MAC)
Same Origin Policy (SOP)
Document Object Model (DOM)
Decentralized Label Model (DLM) of Myers & Liskov
Circular flow of information (fixed points?)
iframe containment (IFC)
Data-Confined Sandbox (DCS)
Secure-Multi Execution (SME)
D. Akhawe, F. Li, W. He, P. Saxena, and D. Song. Data-confined HTML5 applications. In ESORICS, (CSP). 2013.
L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, and S. A. Haghighat. Practical domain and type enforcement for UNIX. In Proceedings of the IEEE Symposium on Security and Privacy. 1995.
A. Barth, C. Jackson, and J. Mitchell. Securing frame communication in browsers. In Communications of the ACM (CACM). Volume 52, Number 6. pages 83–91, 2009.
K. Bhargavan, A. Delignat-Lavaud, and S. Maffeis. In USENIX Security, 2013. Language-based defenses against untrusted browser origins. In Proceedings of USENIX Security. 2013.
N. Carlini, A. P. Felt, and D. Wagner. An evaluation of the Google Chrome extension security architecture. In Proceedings of USENIX Security, 2012.
E. Y. Chen, S. Gorbaty, A. Singhal, and C. Jackson. Self-exfiltration: The dangers of browser-enforced information flow control. In Proceedings of Web 2.0 Security and Privacy. 2012.
W. De Groef, D. Devriese, N. Nikiforakis, and F. Piessens. FlowFox: a web browser with flexi- ble and precise information flow control. In Proceedings of the ACM Conference on Computer & Communications Security (CCS). 2012.
D. Devriese and F. Piessens. Noninterference through Secure Multi-Execution. In Proceedings of the IEEE Symposium on Security and Privacy. 2010.
P. Efstathopoulos, M. Krohn, S. VanDeBogart, C. Frey, D. Ziegler, E. Kohler, D. Manzières, F. Kaashoek, and R. Morris. Labels and event pro- cesses in the Asbestos operating system. In Proceedings of the USENIX Conference on Operating Systems Design & Implementation (OSDI). 2005.
J. Howell, B. Parno, and J. R. Douceur. Embassies: Radically refactoring the Web. In Proceedings of the USENIX Conference on Networked Systems Design & Implementation (NSDI). 2013.
C. Hriţcu, M. Greenberg, B. Karel, B. C. Pierce, and G. Morrisett. All your ifcexception are belong to us. In Proceedings of the IEEE Symposium on Security and Privacy. 2013.
E. G. Sirer, W. de Bruijn, P. Reynolds, A. Shieh, K. Walsh, D. Williams, and F. B. Schneider. Logical attestation: an authorization architecture for trustworthy computing. In Proceedings of the ACM Symposium on Operating Systems Principles (SOSP). 2011.
S. Son and V. Shmatikov. The postman always rings twice: Attacking and defending postMessage in HTML5 websites. In Proceedings of the Network and Distributed System Security Symposium (NDSS). 2013.
D. Stefan, A. Russo, D. Manzières, and J. C. Mitchell. Disjunction category labels. In Proceedings of the Nordic Security Conference (NordSec). 2011.
D. Stefan, A. Russo, J. C. Mitchell, and D. Mazières. Flexible dynamic information flow control in Haskell. In Proceedings of the Haskell Symposium. 2011.
D. Stefan, A. Russo, P. Buiras, A. Levy, J. C. Mitchell, and D. Manzières. Addressing covert termi nation and timing channels in concurrent information flow systems. In Proceedings of the International Conference on Functional Programming ICFP. 2012.
S. Van Acker, P. De Ryck, L. Desmet, F. Piessens, and W. Joosen. WebJail: least-privilege integration of third-party components in web mashups. In Proceedings of the Annual Computer Security Applications Conference (ACSAC). 2011.
E. Yang, D. Stefan, J. Mitchell, D. Mazières, P. Marchenko, and B. Karp. Toward principled browser security. In Proceedings of HotOS. 2013.
A. Yip, N. Narula, M. Krohn, and R. Morris. Privacy-preserving browser-side scripting with BFlow. In Proceedings of EuroSys. 2009.
N. Zeldovich, S. Boyd-Wickizer, E. Kohler, and D. Mazières. Making information flow explicit in HiStar. In Proceedings of the USENIX Conference on Operating Systems Design & Implementation (OSDI). 2006.
is founder and CTO at WhiteHat Security, founder WASC (Web Application Security Consortium)
is a researcher at Microsoft Research and an affiliate professor at the University of Washington.
Rebecca Gurley Bace
is president/CEO of Infidel, a network security consulting practice, and chief strategist for the Center for Forensics, Information Technology, and Security at the University of South Alabama.
is a software engineer, previously with Yahoo! Paranoids
The SSL CA Model (Certificate Authority); i.e. PKI
Robert Hampton & Jeremiah Grossman on CSRF into RFC 1918 space circa 2006.
Dan Greer, a risk management domain expert
[Stanza]Only when users begin to see the value of their data and demand more protection for it will privacy measures get their due. If the market shifts in this direction and vendors see that adding better protection to their browsers could actually increase market share, then and only then will those measures become standard operating practice.
GN-N We talked a little earlier about how it’s the browser users, rather than the browsers themselves, that are the real products here. Anyone care to expand on that?
RB Well, that is the case, and it’s fundamental to this whole space. I would argue that every last conundrum in the area of browser security is rooted in the fact that we’re not dealing with a classic commercial model. That is, at present users don’t pay browser makers for software or, for that matter, the maintenance and upkeep of that software.
JG The browser makers are monetizing your data, directly or indirectly, and therefore cannot see a way to protect that data without losing money. That makes for a really difficult situation.
BL I’m not sure you can actually say it’s the browser makers who are “monetizing your data.” If anything, it’s the sites that are monetizing your data.
JG Actually, there’s a clear interplay there. Just look at Google Chrome; it’s pretty obviously monetizing your data. The Mozilla guys derive 98 percent of their revenue directly from Google. Then you’ve got Microsoft, which you could argue is also desperate now to get into the advertising business. So that raises the question: How can you work to institute healthier business incentives when those efforts are so obviously at odds with the foundation the whole business sits upon?
BL I don’t know. One of the problems with privacy is that it’s difficult to put a value on it. It’s difficult even to convince the users that their own privacy is actually worth all that much.
JG Maybe users just aren’t all that aware of what they’re giving up with every single mouse click.
JG I can share how I try to protect myself and how I’ve instructed my mom to do it. Take two browsers—any modern browsers that have been updated will do. The important thing is to have two of them so you can compartmentalize risk. The first of these will be the primary browser, the one you use for all your promiscuous browsing—read the news, visit your favorite Web sites, click on the links in your Twitter feed, and whatever else you feel tempted to do. But don’t ever use the primary browser to do anything with online accounts you consider sensitive or important.
If you’re using Chrome or Firefox, you should also turn on ad blocking and tracker blocking as extensions in the browser. That’s not just for sanity purposes, but also to prevent a whole lot of malware, which often ends up getting propagated over advertising networks. Bonus points if you run in incognito or private mode. That might save you a little bit of privacy as well. Another thing you should do is to block plugins from playing by default. You can run them whenever you want to with a right click, but don’t let them automatically run. Generally, when you get infected with a virus or a piece of malware, it’s because of some invisible plugin that runs automatically.
Your secondary browser is the one you want to fire up only when it’s time to do online banking or online shopping or anything involving a credit card number, an account number, or anything else you want to protect. Once you’ve fired up that browser, get in and do what you need to do quickly, and then close that thing down.
If you can manage to keep those two worlds separate, when you’re out surfing the Web with your primary browser, it won’t even be possible to hack your bank with a cross-site request forgery request because it will be like you’ve never logged in at that bank. So clickjacking, cross-site request forgery, and cross-site scripting pose almost no threat, since there effectively is no cross site.