Cool additions by Dropbox Interns(blog.dropbox.com)
blog.dropbox.com
Cool additions by Dropbox Interns
http://blog.dropbox.com/?p=875
18 comments
Nice to see that interns seem to choose the topic they'd like to work on and feel like making really useful work!
Pretty skeptical of the code obfuscator part. Even written from scratch this will not prevent people to deobfuscate it in the end.
It's not possible to reconstruct variable names that are replaced with arbitrary strings.
You seem to have not heard of the field of software reverse-engineering. If you think obfuscated JS is hard to understand, keep in mind that people like DVD Jon typically reverse-engineer algorithms out of optimized assembly.
You are completely making assumptions about who I am and what my comment means outside of what is literally there in the text of it. I never said you can't get algorithms out of obfuscated source, I said you can't get variable names.
A lot of JS code ends up getting deployed with references to future planned unreleased features. Fairly simple code obfuscation works completely to hide that form of leak. See the leak about Facebook's future integration with some music service that came out from a javascript string without there literally being any functionality to go along with it, among a number of Google+ feature leaks that came out similarly.
Obviously you can infer what the variable name might be, but you can't get the original variable name back. Was a variable count or counter? Index or i?
In reality I just thought that "Even written from scratch this will not prevent people to deobfuscate it in the end" is exceptionally silly; it's implying that existing deobfuscators use knowledge of the obfuscators in their process of reversing it. They clearly do not, and an obfuscator written from scratch is almost certainly strictly inferior to existing solutions.
I decided not to attack someone for being slightly naive and just mention something that is legitimately protected by obfuscation. Apparently that is the wrong thing to do on HN and I need to be snarky to avoid people assuming that I'm a moron.
A lot of JS code ends up getting deployed with references to future planned unreleased features. Fairly simple code obfuscation works completely to hide that form of leak. See the leak about Facebook's future integration with some music service that came out from a javascript string without there literally being any functionality to go along with it, among a number of Google+ feature leaks that came out similarly.
Obviously you can infer what the variable name might be, but you can't get the original variable name back. Was a variable count or counter? Index or i?
In reality I just thought that "Even written from scratch this will not prevent people to deobfuscate it in the end" is exceptionally silly; it's implying that existing deobfuscators use knowledge of the obfuscators in their process of reversing it. They clearly do not, and an obfuscator written from scratch is almost certainly strictly inferior to existing solutions.
I decided not to attack someone for being slightly naive and just mention something that is legitimately protected by obfuscation. Apparently that is the wrong thing to do on HN and I need to be snarky to avoid people assuming that I'm a moron.
You don't need variable names to understand what the code is doing, it's just harder without them.
Try going to google.com with chrome, opening the developer console, going to scripts right clicking and selecting 'de-obfuscate source'.
Try going to google.com with chrome, opening the developer console, going to scripts right clicking and selecting 'de-obfuscate source'.
I never intended to imply that you could not determine what the code is doing. I simply stated that you could not get the variable names back, I'm not sure why several people felt the need to inform me that "x therefore y" is false when all I said was x.
It would be possible to infer function and variable names, given enough thought.
I remember writing a code obfuscator for my first job at company XYZ ;-), not really a pleasant experience. That's why interns or entry level employees do that.
"and came from a variety of schools (MIT, Stanford, Brown, CMU, Tufts, Chapman and University of Ontario"
eyeroll Starting the elitism early, I see.
eyeroll Starting the elitism early, I see.
And the message of this comment is?
So Dropbox security is based on a code obfuscator? And was it an intern that let us log into any dropbox account with any password? Kidding, but seriously, they need to get more interns because one of the most requested feature for years on their site is remote wipe (https://www.dropbox.com/votebox/35/remote-destroy-purge-opti...) and they never implement it. Granted its not an entirely reliable method but its better than not offering it.
That's not what they are saying at all. The obfuscator is to protect their source code, it has nothing to do with your account and files being secured or not.
Remote wipe is a horrible way to implement security on a Dropbox account. Better is client side encryption - although Dropbox has no intention of implementing that either.
There are a few other companies that have, however: http://skeptu.com/secure-alternatives-to-dropbox
There are a few other companies that have, however: http://skeptu.com/secure-alternatives-to-dropbox
Every major company uses code obfuscation/minification/compilation on their javascript. It's not really clear what they mean though...
I think it's pretty clear that they mean their source code. This isn't about user security, it's about their intellectual property.
(To your parent, not you): Sometimes I'm sure people misunderstand on purpose just so they have something to be indignant about.
(To your parent, not you): Sometimes I'm sure people misunderstand on purpose just so they have something to be indignant about.
This isn't for their javascript, it's for their client which is Python code. Their previous obfuscator has been broken (by at least one nice hacker who told them).