Fetch API of HTML5


  • Fetch bodies are read “at most once.”
  • Fetch responses may use streams, some day.
    … to deliver data to the applicatino “as it arrives.”
  • <quote cite=”ref“>Along with the transition to streams, Fetch will eventually have the ability to abort running fetch()es and some way to report the progress of a fetch. These are provided by XHR, but are a little tricky to fit in the Promise-based nature of the Fetch API.</quote>




Via: article

fetch("/data.json").then(function(res) {
  // res instanceof Response == true.
  if (res.ok) {
    res.json().then(function(data) {
  } else {
    console.log("Looks like the response wasn't perfect, got status", res.status);
}, function(e) {
  console.log("Fetch failed!", e);
fetch("http://www.example.org/submit.php", {
  method: "POST",
  headers: {
    "Content-Type": "application/x-www-form-urlencoded"
  body: "firstName=Nikhil&favColor=blue&password=easytoguess"
}).then(function(res) {
  if (res.ok) {
    alert("Perfect! Your settings are saved.");
  } else if (res.status == 401) {
    alert("Oops! You are not authorized.");
}, function(e) {
  alert("Error submitting form!");

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). Erights.org (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.


JavaScript checkers & linters

Checking The Do Not Track (DNT) Header from JavaScript

See navigator.doNotTrack

var isDNT = navigator.doNotTrack == “yes” || navigator.doNotTrack == “1″ || navigator.msDoNotTrack == “1″;

Browser Leaks

Previously noted

Why Mobile Web Apps are Slow | Drew Crawford



He puts the abstract-summary at the end.


  • Javascript is too slow for mobile app use in 2013 (e.g., for photo editing etc.).  
    • It’s slower than native code by about 5
    • It’s comparable to IE8
    • It’s slower than x86 C/C++ by about 50
    • It’s slower than server-side Java/Ruby/Python/C# by a factor of about 10 if your program fits in 35MB, and it degrades exponentially from there
  • The most viable path for it to get faster is by pushing the hardware to desktop-level performance.  This might be viable long-term, but it’s looking like a pretty long wait.
  • The language itself doesn’t seem to be getting faster these days, and people who are working on it are saying that with the current language and APIs, it will never be as fast as native code
  • Garbage collection is exponentially bad in a memory-constrained environment.  It is way, way worse than it is in desktop-class or server-class environments.
  • Every competent mobile developer, whether they use a GCed environment or not, spends a great deal of time thinking about the memory performance of the target device
  • JavaScript, as it currently exists, is fundamentally opposed to even allowing developers to think about the memory performance of the target device
  • If they did change their minds and allowed developers to think about memory, experience suggests this is a technically hard problem.
  • asm.js show some promise, but even if they win you will be using C/C++ or similar “backwards” language as a frontend, rather than something dynamic like JavaScript



By section

The genre of “Which is better: native or HTML5″ “Who will win?”

Three criticisms about benchmarks

  1. Whether JIT is appreciably slower where it matters (benchmarks do not matter).
  2. JIT gets better every day, native does not; oOne day soon, JIT will be “faster than native.”
  3. Python, PHP, Ruby (fully-interpreted code) is already fast enough for ultra-high scale, this is single-user, so what’s the point?

Performance Baseline & Benchmarks

Performance Evolution and Possibilities

Language Tradeoffs: Native vs Managed

Managed languages optimize for developer productivity with JIT thrown in to recover some of the drain.  Native languages don’t have that overhead.  Even the proponents admit this. In archaeological order, not article order:

On Garbage Collection contra Explicit Memory Management

Screen Shot 2013-05-14 at 10.15.29 PM

Hertz, Berger; Quantifying the Performance of Garbage Collection vs Explicit Memory Management

Claim: Garbage Collectors need 6x (4x) more memory than “is necessary” in order to be efficient enough for real-time UX-type applications.  See the chart where the relative memory footprint approaches 1x; consider that 1.5x to 2x is “acceptable performance degadation.”

How Much Memory is Available on iOS?

  • iOSMemoryBudgetTest by Jan Ilavsky
  • Observed limits in the field, on his gear
    • iPhone 4S
      • warn => 40MB (around)
      • killed => 213MB (around)
    • iPad 3
      • warned => 400MB (around)
      • killed => 550MB (around)
  • Walk the scenarios against the limits
  • Multiple copies of the same photo in memory
    Citing also the slide from Session 242, iOS App Performance – Memory, 2012

    1. The camera screen that shows you what the camera sees,
    2. the photo that the camera actually took,
    3. the buffer that you’re trying to fill with compressed JPEG data to write to disk,
    4. the version of the photo that you’re preparing for display in the next screen
    5. the version of the photo that you’re uploading to some server,
    6. the buffer that is going to hold a smaller photo suitable for display in the next screen,
    7. the buffer that resizes the photo in the background because it is too slow to do it in the foreground.</quote>
  • Multiple copies of the same video frame in memory
    Citing also Technical Q&A QA1708 Improving Image Drawing Performance on iOS

    • Q: What can I do to improve my image drawing performance (CGContextDrawImage, UIImage/-drawInRect:, etc)?
    • “Every UIView is backed with a CALayer and images as layer contents remain in memory as long as the CALayer stays in the hierarchy.”
  • Compare the iPad 3 display with a pure display
    (though these are larger, brighter, faster, etc.)

Packaging of ARM Technology

Addressing the need/ability to add more memory to ARM PoP in order to make garbage collection performant; i.e. can one get 6x more memory on some future hypothetical ARM PoP in order to make GC be performant enough to use?

In archaeological order

On JavaScript and Garbage Collection


  • Benchmarks
  • Hardware
    • Intel x86
    • ARM
  • Native (C, Objective-C, C++)
    • GCC
    • LLVM
    • ICC (Intel-closed-secret-proprietary)
  • Java
    • There is only One. True. Compiler. here, right?
  • JavaScript
    • V8 of Google
    • Nitro JS
    • Nitro/SFX
    • TraceMonkey/IonMonkey
    • Chakra,
    • ASM.js
  • Lua
    • A simpler language with a simpler interpreter, via Brendan Eich
  • Period Pieces
    • Internet Explorer 8 (veeerrrryyyy sllllooowwwww)
    • Firefox 3.0.3, when Firefox becomes “fast”
      • Firefox 19 (Firefox 22), current
    • Chome 8, when Chrome became “fast”
      • Chrome 26, current




Apple Developer Documentation


  • Andreas Gal’s dissertation



Pithy, trenchant, money (quote), etc.
Unless otherwise stated, from: Why mobile web apps are slow; In His Blog; 2013-07-09.

  • <quote>The thing is, JITing JavaScript was a 60-year old idea with 60 years of research, and literally thousands of implementations for every conceivable programming language demonstrating that it was a good idea.  But now that we’ve done it, we’ve run out of 60-year-old ideas.  That’s all, folks.  Show’s over.  Maybe we can grow another good idea in the next 60 years.</quote>

Ahem …


  • <quote>The ground truth is that in a memory constrained environment garbage collection performance degrades exponentially.  If you write Python or Ruby or JS that runs on desktop computers, it’s possible that your entire experience is in the right hand of the chart, and you can go your whole life without ever experiencing a slow garbage collector.  Spend some time on the left side of the chart and see what the rest of us deal with.</quote>
  • <quote>With garbage collection, the winning move is not to play.  A weaker form of this “the winning move is not to play” philosophy is embedded in the official Android documentation:

    Object creation is never free. A generational garbage collector with per-thread allocation pools for temporary objects can make allocation cheaper, but allocating memory is always more expensive than not allocating memory. As you allocate more objects in your app, you will force a periodic garbage collection, creating little “hiccups” in the user experience. The concurrent garbage collector introduced in Android 2.3 helps, but unnecessary work should always be avoided. Thus, you should avoid creating object instances you don’t need to… Generally speaking, avoid creating short-term temporary objects if you can. Fewer objects created mean less-frequent garbage collection, which has a direct impact on user experience.


  • <quote>I can give you three frames of reference that are both useful and approximately correct.
    • If you are a web developer, think about the iPhone 4S Nitro as IE8, as it benchmarks in the same class.  That gets you in the correct frame of mind to write code for it.  JS should be used very sparingly, or you will face numerous platform-specific hacks to make it perform.  Some apps will just not be cost-effective to write for it, even though it’s a popular browser.
    • If you are an x86 C/C++ developer, think about the iPhone 4S web development as a C environment that runs at 1/50th the speed of its desktop counterpart.  Per the benchmarks, you incur a 10x performance penalty for being ARM, and another 5x performance penalty for being JavaScript. Now weigh the pros and cons of working in a non-JavaScript environment that is merely 10x slower than the desktop.
    • If you are a Java, Ruby, Python, C# developer, think about iPhone 4S web development in the following way.  It’s a computer that runs 10x slower than you expect (since ARM) and performance degrades exponentially if your memory usage goes above 35MB at any point, because that is how garbage collectors behave on the platform.  Also, you get killed if at any point you allocate 213MB.  And nobody will give you any information about this at runtime “by design”.  Oh, and people keep asking you to write high-memory photo-processing and video applications in this environment.


  • <quote>The desktop market is shrinking year-on-year.    Computers are going to be what the hardcore professionals use–Photoshop  and Visual Studio will always stick around–but mere mortals who spend all day in Excel or Outlook or Powerpoint are going to migrate to ARM tablets.  (Maybe even ARM notebooks.)  Some of us like desktop computers for ideological reasons, or like x86 on the technical merits, or whatever.  But the truth on the ground is that ARM is rising and x86 is falling, like it or not.  Even if we throw out all the smartphones and tablets, you have reasonable research firms projecting things like a 60-40 ARM-Intel netbook split for 2013. And once you throw the tablets and smartphones back in, well, let’s just say that more ARM chips were fabbed last yearthan all the x86 chips ever made.  The sky is falling.  The building is on fire.Whenever you make a platform decision, you’re making a bet.  If you’re writing a web app, you’re essentially betting either 1) that ARM doesn’t matter, 2) that ARM customers will just suck it up and use your slow product,  3) that the web browser guys will wave a wand and make it faster, or 4) that the WiFi guys will fix the speed of light so that everybody has a zero-latency always-on connection to an x86 chip.  Unless you’re writing Photoshop, or writing an app with two buttons, I think you’re nuts.</quote>
    From: Mobile web apps are slow; In His Blog; 2013-05-06.


Humorous, ironic or off-the-cuff

Via: backfill