Hi Colin, please find my answers inline: On Tue, Aug 20, 2013 at 11:35 PM, Colin Alworth <[email protected]> wrote:
> I got a tweet from you asking for a donation (or rather a 'partner', which > apparently means 'money'), but couldn't frame a useful response in 140 > chars, so since this thread is coming back, I thought to do so here > instead. > Yes, I wanted to see if Sencha would be interested in funding this project. I agree, 140 chars is not enough :) Just couldn't find your contact info other than Twitter. What license are you offering these code samples under - if it isn't > something open and available, what is the benefit to an advance copy of the > jar if I, an author of a library and several open source tools and > applications, cannot provide it to my customers or other downstream users? > That's a good point which I hadn't considered. I'd be willing to immediately release the code under the same license as GWT if the project gets funded. (For anyone who's just joining this thread now, here's the link to my project on IndieGoGo: http://igg.me/at/gwt-stack-traces/x/3494291) > We've found that https://gist.github.com/niloc132/3906501 goes a heck of > a long ways toward offering optional debug info - if not enabled, the user > gets the normal-size application with zero size or performance hit, and by > redirecting to a slightly different url, the full trace info can be pulled > out (with the quirks you mention of course*), which typically goes a long > ways toward identifying the real issue. > Yes, and you'd still be able to use that same config with my patch, except the debug permutation will be much smaller, cleaner, and more accurate. In fact, the overhead is so insignificant now, that I have that debug configuration enabled for all users on my site (typeracer.com). > * How often have you needed to know which line of Impl.java or > DOMImpl.java a stack trace intersects? To make your case more effectively, > you might consider using code where it is meaningful to see those lines, > something other than the equivelent of > java.lang.reflect.Method.invoke(Method.java:601). Perhaps some real life > JSNI, or an annoying IE6-9 focus() or setAttribute issue? > > Certainly. At the time of writing I only had a few artificial examples available. But now that I've been gathering real data from my users in production for a month, I will add an appendix with much better real-world examples. I'll update this thread when I finish doing that (most likely tomorrow). > You touch briefly on the risk of '[exposing] your application’s > implementation details', but unless I am mistaken, the extra metadata > included in the file:line ints should still be enough to take apart an app > and map it to discrete files and reconstruct methods, even un-inlining (as > you mention) to pull out clearer details. My understanding was that the > premise of the sourceMap was to work entirely from the stack to allow the > actual source to be obfuscated, and avoid any other metadata from being > left in the compiled output. Combine this with the fact that many of those > classes are publicly available (GWT itself, etc), and it seems that you > could reverse out a significant portion of the app - the "secret sauce". > Can you comment on using this for public applications and any reverse > engineering attempts you've made? > Let me first just clarify how my implementation obfuscates file names (I think you understood it correctly, but I just want to be sure). So in my implementation of stack emulation, the filenames are obfuscated, so you have strings like '23:234'. The decoding table for this "cipher" is not published (it's written as a new file in the same directory as the symbolMap). So the only thing that you can reconstruct is that the obfuscated JavaScript expression X is on line '234' of file '23'. I understand that you can use this info to separate the JS output into discrete files, but I'm just not overly concerned with that, because I don't think it's that much more helpful to have many obfuscated files with prettier whitespacing instead of just one lump file. If necessary, I suppose you could modify the compiler to add some additional obfuscating "salt" to the output. Thanks for your questions! Alex -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
