Results 1 to 3 of 3

Thread: Is it possible to mix ExtJS and google-caja to enhance security ?

  1. #1
    Ext User
    Join Date
    Sep 2008
    Posts
    27
    Vote Rating
    0
      0  

    Default Is it possible to mix ExtJS and google-caja to enhance security ?

    This may be a stupid question but I'll take the risk :-). I'm under the impression ExtJS transfers all the work to implement security features to the developer and I just want to know if there is any way to make security a built-in feature

    http://due-diligence.typepad.com/blo...-investor.html

  2. #2
    Ext User
    Join Date
    Jul 2007
    Posts
    3,128
    Vote Rating
    4
      0  

    Default

    I have mixed feelings about automatic security features such as that. On one hand, it sometimes helps poor programmers prevent making major security holes. On the other hand, it usually gets in the way of good programmers that want to do advanced things. In other words, good programmers should always be aware of the security implications of their code and the system their code runs on. Now granted, a web browser is a very insecure place to begin with, and perhaps something like this is needed until a real solution exists within the browser itself.
    As a specific example of the above, take XMLHttpRequest itself. It was discovered at some point that allowing unrestricted access to foreign domains was a big problem. But instead of giving us some kind of multilevel access control, it was decided to just not allow it at all. We can tell by the number of newbies that come in confused and then angry when it doesnt "just work" that programmers nowadays rarely even think about security implications, so its generally a good thing. But when we do really need to access a foreign domain (and understand how to mitigate the security risks) the more advanced programmers are forced to come up with creative workarounds like ScriptTagProxy (which end up having alot of drawbacks and restrictions).
    I can imagine that javascript based solutions like google caja can bring with them a significant performance penalty, which is a problem in an arena where performance is already an issue.

  3. #3
    Ext User
    Join Date
    Jan 2009
    Posts
    1
    Vote Rating
    0
      0  

    Default

    Performance of web apps is a tricky thing. Usually the bottlenecks are the network and the DOM, which Caja doesn't effect at all. But Caja does slow down the compute speed of JS itself. Cajita is ballpark 6x and Valija is ballpark 40x. We're working on improving it, but don't expect Cajita to get better than ballpark 2x anytime soon. Once enough browsers support EcmaScript 3.1 that web developers can count on that, the Cajita translation can become trivial and have essentially no runtime overhead.

    If
    * the overhead of Caja is a problem, and
    * you can live with a small subset of JS -- enough for new code but unfriendly to old code, and
    * you can live with the dangers inherent in a blacklisting strategy for denying access to unsafe legacy APIs (as opposed to Caja's whitelisting strategy)
    Then you should checkout ADsafe, Jacaranda, and Dojo Secure. These have essentially no runtime overhead today, in exchange for the dangers of blacklisting. Adopting any of these now will prepare you to port to Caja at a later date if you decide to do that.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •