ServiceWorker of HTML5



  • Push Notifications
  • Offline First
  • Background Sync


  • ServiceWorker is like SharedWorker
    • Own thread.
    • No DOM, no page access, no need for a page.
    • Has an upgrade model.
    • HTTPS only.
  • Cross Origin Resource Sharing (CORS)
    • by default,
    • but no-cors is possible
  • ECMAScript
    • ECMAScript 5 (ES5)
    • ECMAScript 6 (ES6)
    • ECMAScript 7 (ES7)
      • async functions
      • await




  • about:config
    • dom.serviceWorker.enabled
    • dom.serviceWorkers.testing.enabled





User Agent Detection


Protecting Users by Confining JavaScript with COWL | Stefan, Yang, Marchenko, Russo, Herman, Karp, Mazières

Deian Stefan, Edward Z. Yang, Petr Marchenko, Alejandro Russo, Dave Herman, Brad Karp, David Mazières; Protecting Users by Confining JavaScript with COWL; In Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI); 2014-10; 14 pages; landing.


Modern web applications are conglomerations of JavaScript written by multiple authors: application developers routinely incorporate code from third-party libraries, and mashup applications synthesize data and code hosted at different sites. In current browsers, a web application’s developer and user must trust third-party code in libraries not to leak the user’s sensitive information from within applications. Even worse, in the status quo, the only way to implement some mashups is for the user to give her login credentials for one site to the operator of another site. Fundamentally, today’s browser security model trades pri- vacy for flexibility because it lacks a sufficient mechanism for confining untrusted code. We present COWL, a robust JavaScript confinement system for modern web browsers. COWL introduces label-based mandatory access control to browsing contexts in a way that is fully backward-compatible with legacy web content. We use a series of case-study applications to motivate COWL’s design and demonstrate how COWL allows both the inclusion of untrusted scripts in applications and the building of mashups that combine sensitive information from multiple mutually distrusting origins, all while protecting users’ privacy. Measurements of two COWL implementations, one in Firefox and one in Chromium, demonstrate a virtually imperceptible increase in page-load latency.


  • 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.

Via: backfill


  • <quote>In practice, web developers turn their backs on privacy
    in favor of flexibility because the browser doesn’t offer primitives that let them opt for both. For example, a developer may want to include untrusted JavaScript from another origin in his application. All-or-nothing DAC leads the developer to include the untrusted library with a script tag, which effectively bypasses the SOP, interpolating untrusted code into the enclosing page and granting it unfettered access to the enclosing page’s origin’s content. And when a developer of a mashup that integrates content from other origins finds that the SOP forbids his application from retrieving data from them, he designs his mashup to require that the user provide the mashup her login credentials for the sites at the two other origins [2]—the epitome of “functionality over privacy.”</quote>


  • 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)
  • postMessage
  • XMLHttpRequest (XHR)
  • Chromium
    • Blnk
  • Firefox
    • Gecko
  • Web Worker
    • LWorker
  • XHR
  • JSON


  • symmetric confinement
  • hierarchical confinement
  • delegation
  • mutually-distrusting parties
  • Decentralized Label Model (DLM) of Myers & Liskov
  • Nexus
  • First-order logics
  • Circular flow of information (fixed points?)
  • membrane pattern


  • coarse-grained
  • fine-grained
  • protection zones
  • iframe containment (IFC)
  • symmetric confinement
  • tainting
    • over-tainting


  • BFlow
  • Data-Confined Sandbox (DCS)
    • data:URI iframes
  • JSFlow
  • Secure-Multi Execution (SME)
  • Caja
  • BrowserShield
  • WebJail
  • TreeHouse
  • JSand
  • SafeScript
  • Defensive JavaScript
  • Embassies


  1. Google Caja. A source-to-source translator for securing JavaScript-based web content. 2013.
  2. Mint. 2013.
  3. jQuery Usage Statistics: Websites using jQuery. 2014.
  4. P. Agten, S. Van Acker, Y. Brondsema, P. H. Phung, L. Desmet, and F. Piessens. JSand: complete client-side sandboxing of third-party JavaScript without browser modifications. In Proceedings of the Annual Computer Security Applications Conference (ACSAC). 2012.
  5. D. Akhawe, F. Li, W. He, P. Saxena, and D. Song. Data-confined HTML5 applications. In ESORICS, (CSP). 2013.
  6. 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.
  7. A. Barth. The web origin concept. Technical report RFC 6454, IETF, 2011.
  8. 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.
  9. 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.
  10. N. Carlini, A. P. Felt, and D. Wagner. An evaluation of the Google Chrome extension security architecture. In Proceedings of USENIX Security, 2012.
  11. 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.
  12. 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.
  13. D. Devriese and F. Piessens. Noninterference through Secure Multi-Execution. In Proceedings of the IEEE Symposium on Security and Privacy. 2010.
  14. 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.
  15. D. Hedin, A. Birgisson, L. Bello, and A. Sabelfeld. JSFlow: tracking information flow in JavaScript and its APIs. In SAC, 2014.
  16. 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.
  17. 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.
  18. L. Ingram and M. Walfish. Treehouse: JavaScript side sandboxes to help web developers help themselves. . In Proceedings of the USENIX Annual Technical Conference (ATC). 2012.
  19. C. Kerschbaumer (Mozilla). Faster Content Security Policy; In Their Blog. 2014.
  20. R. Kotcher, Y. Pei, P. Jumde, and C. Jackson. Cross-origin pixel stealing: timing attacks using CSS filters. In Proceedings of the ACM Conference on Computer & Communications Security (CCS). 2013.
  21. M. S. Miller. Robust composition: towards a unified approach to access control and concurrency control. PhD thesis, Johns Hopkins University, 2006.
  22. M. S. Miller and J. S. Shapiro. Paradigm regained: Abstraction mechanisms for access control. In Proceedings of the Asian Computing Science Conference (ASIAN). 2003-12. 20 pages; landing, presentation; also SRL Technical Report SRL2003-03, Department of Computer Science, Johns Hopkins University; also Hewlett-Packard Technical Report HPL-2003-222 (unabridged). (the E Language)
  23. M. S. Miller, K.-P. Yee, and J. Shapiro. Capability myths demolished. Technical Report SRL2003-02, Johns Hopkins University Systems Research Laboratory, 2003.
  24. S. Moitozo. Password Meter, JavaScript. 2006.
  25. B. Montagu, B. C. Pierce, and R. Pollack. A theory of information-flow labels. In Proceedings of the IEEE Conference on Security Foundations (CSF); 2013-06.
  26. Mozilla. Add-on builder and SDK. 2013.
  27. A. C. Myers and B. Liskov. Protecting privacy using the decentralized label model. In ACM Transactions on Software Engineering and Methodology (TOSEM). Volume 9, Number 4. 2000.
  28. C. Reis, J. Dunagan, H. J. Wang, O. Dubrovsky, and S. Esmeir. Browsershield: Vulnerability-driven filtering of dynamic HTML. In ACM Transactions on the Web (TWEB). Volume 1, Number 3. 2007-09.
  29. J. Reisg. Dromaeo: JavaScript performance testing. 2014.
  30. 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.
  31. 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.
  32. E. Stark, M. Hamburg, and D. Boneh. Symmetric cryptography in JavaScript. In Proceedings of the Annual Computer Security Applications Conference (ACSAC). 2009.
  33. D. Stefan, A. Russo, D. Manzières, and J. C. Mitchell. Disjunction category labels. In Proceedings of the Nordic Security Conference (NordSec). 2011.
  34. 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.
  35. 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.
  36. M. Ter Louw, P. H. Phung, R. Krishnamurti, and V. N. Venkatakrishnan. SafeScript: JavaScript transformation for policy enforcement. In Proceedings of Secure IT Systems. 2013.
  37. 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.
  38. A. Van Kesteren. Cross-Origin Resource Sharing (CORS), 2012.
  39. B. Vibber. CSRF token-stealing attack (user.tokens). Mozilla, a ticket. 2014.
  40. G. Wagner, A. Gal, C. Wimmer, B. Eich, and M. Franz. Compartmental memory management in a modern web browser. In SIGPLAN Notices. Volume 11, Number 46 part 2. 2011.
  41. H. J. Wang, X. Fan, J. Howell, and C. Jackson. Protection and communication abstractions for web browsers in MashupOS. In ACM SIGOPS Operating Systems Review. Volume 41, Number 6. 2007.
  42. WC3. Content Security Policy (CSP) v1.0. 2012.
  43. WC3. HTML5 web messaging. 2012.
  44. WC3. Web Workers. 2012.
  45. WC3. Cross-Origin Resource Sharing (CORS). 2013.
  46. WC3. Content Security Policy (CSP) v1.1. 2013.
  47. WC3. HTML5. 2013.
  48. WHATWG. HTML living standard. 2013.
  49. E. Yang, D. Stefan, J. Mitchell, D. Mazières, P. Marchenko, and B. Karp. Toward principled browser security. In Proceedings of HotOS. 2013.
  50. A. Yip, N. Narula, M. Krohn, and R. Morris. Privacy-preserving browser-side scripting with BFlow. In Proceedings of EuroSys. 2009.
  51. 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.
  52. M. Zelwski. Browser Security Handbook, Part 2, 2011.


Browser Security & Web Security in ACM Queue circa 2012-11

  • Jeremiah Grossman, Ben Livshits, Rebecca Bace, George Neville-Neil; Browser Security Case Study: Appearances Can Be Deceiving; In ACM Queue; 2012-11-20.

    • Participants
      • Jeremiah Grossman
        is founder and CTO at WhiteHat Security, founder WASC (Web Application Security Consortium)
      • Ben Livshits
        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.
      • George Neville-Neil
        is a software engineer, previously with Yahoo! Paranoids
    • Concepts
      • HTML5
      • The SSL CA Model (Certificate Authority); i.e. PKI
      • Convergence, the notary method of CA assessment
      • The DoD model (of security, undefined)
      • CSRF
      • RFC-1918
      • FTC
      • DNT (Do Not Track)
      • robots.txt
      • Allow
      • Facebook button
      • Cross-Site Referral Hijacking
      • Local Storage
      • CSP (Content Security Policy)
      • SQL Injection via parameterized SQL statements
    • Quips, Citations
      • Moxie Marlinspike
      • Robert Hampton & Jeremiah Grossman on CSRF into RFC 1918 space circa 2006.
      • Dan Greer, a risk management domain expert
    • Quotes (two)
      • [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.

  • Jeremiah Grossman (Whitehat Security); The Web Won’t Be Safe or Secure until We Break It; In ACM Queue; 2012-11-06.

    • Scope
      • HTML
      • CSS
      • JavaScript
    • Classifications
      • XSS => Cross Site Scripting
      • CSRF => Cross-Site Request Forgery
      • Clickjacking
      • Browser intranet hacking
      • “Drive-by” Downloads
      • History sniffing via CSS
      • Invisible iframes
    • Purposes
      • login detection
    • Techniques
      • iframe onload
      • img onload
      • img onerror
    • Market forces
      • Browsers need market share
      • Hard to mandate repairs that “break things”
      • “a more secure platform” is not a value add, not given the porting headache
      • Opt-in features
    • Opt-in Schemes
      • Content Security Policy
      • X-Frame-Options
      • Origin
      • Strict Transport Security
      • SSL (Secure Sockets Layer)
      • Secure cookie flag
      • HttpOnly cookie flags
    • Proposal
      • Full in-browser sandboxing
      • Make the desktop apps like the “mobile apps”