Hey Mark, Thanks for the response, and for clarifying those points for me. The platforms we are focussing on are: iOS 7, Android 4+, Chrome and Firefox (current), and IE10+ (and if possible IE9). Security is a concern, but sandboxing a widget/app and allowing DOM event pass-through is why we are using Caja.
Performance is very important for us, and loading times have been particularly bad on mobile devices; due to a combination of poor es5 support (iOS) and lower processing power, initial load can take upwards of 2s for a single widget, of which almost all time is spent in parsing and rewriting. I have been profiling and trying to fix performance bottlenecks, but I am not familiar enough with es5/ses to be certain that I am not introducing security issues. Is the current test coverage complete enough that I should feel comfortable with my changes? Which areas of the code should I be careful around? Also, I'm pretty sure that https://code.google.com/p/google-caja/issues/detail?id=1893 is a small bug, that prevents uriPolicy.mitigate from working. But again, I am not sure if this is intentional and/or required for some security reasons. Are there any good resources that I could use to get a better understanding of ses, mitigation, domado, etc other than the source itself? I will discuss with our general counsel about the CLA, so that we could potentially (if you and the rest of the team are interested) collaborate better on these issues. Thanks again, On Sun, Feb 23, 2014 at 12:39 AM, Mark Miller <[email protected]> wrote: > On Fri, Feb 14, 2014 at 11:29 PM, James Keane > <[email protected]<https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]> > > wrote: > >> I have been running into a few issues w.r.t initial loading... speed and >> browser locking due to (client side) script rewriting. >> > > Hi James, sorry for the delay. We'll look into it. So we might be able to > align the platforms we're testing on, what platforms are you using? > > > >> >> I am wondering why scripts are always fully mitigated >> (htmlemitter.js:593|1089 & startSES.js:307). What is the point of all of >> the SES repairing, if full mitigation needs to be done anyways? Some >> clarification on this would help immensely. I feel as if I am lacking some >> crucial information here. >> > > The point of the repairing is indeed to avoid parsing and translation for > programs that don't need it. And also to be able to run SES standalone > without a parser, and therefore without mitigation, when we're willing to > live with the unmitigated semantic differences < > http://es-lab.googlecode.com/svn/trunk/src/ses/>. > > > >> >> Also, in the worst-case mitigateSrcGotchas and full program parsing can >> happen _three times in a row_. Forgive my notation on this manual stack >> trace >> > >> --- >> startSES:compileModule() calls mitigateSrcGotchas. >> compileModule() also calls securableWrapperSrc() which >> calls verifyStrictExpression() >> verifyStrictExpression() calls ses.verifyStrictFunctionBody() TWICE >> >> ses.verifyStrictFunctionBody() could (worst-case) evaluate to >> verifyStrictFunctionBodyByParsing() which again calls >> mitigateSrcGotchas(). >> --- >> > > Thanks for catching and reporting this! This behavior is indeed odd and > unintended. We'll see what we can do about reducing it. > > > > >> >> For now I will try to use uriPolicy.mitigate to partially resolve this >> issue (jquery) but browser locking due to parsing is a serious concern for >> me especially on mobile. >> >> Do you think it would be feasible to optionally support >> mitigateSrcGotchas in a webworker? My brief investigation makes me believe >> only minimal code changes would be required to make mitigateSrcGotchas a >> promise. If mitigateSrcGotchas is a promise then caja.js can load a >> webworker (if supported) in place of utility-frame.js and boom, no more >> browser locking. >> > > This is an interesting direction to explore. But let's get back to it > after we investigate the perverse behavior you've identified. Thanks again! > > > -- > Cheers, > --MarkM > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Google Caja Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- James Keane Wishabi.com | 647-460-3634 -- IMPORTANT NOTICE: This message, including any attachments (hereinafter collectively referred to as "Communication"), is intended only for the addressee(s) named above. This Communication may include information that is privileged, confidential and exempt from disclosure under applicable law. If the recipient of this Communication is not the intended recipient, or the employee or agent responsible for delivering this Communication to the intended recipient, you are notified that any dissemination, distribution or copying of this Communication is strictly prohibited. If you have received this Communication in error, please notify the sender immediately by phone or email and permanently delete this Communication from your computer without making a copy. Thank you. -- --- You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
