Is GWT's obfuscate compilation safe enough to protect the js code?

[OrNOt]

Hi, there,
If I have some algorithms which are implemented with GWT and
obfuscated to JS, is it safe enough to protect it from being hacked?
Suppose no RPC is involved
here?


Regards
OrNot

[Harpal Grover]

I too am quite curious about the strength of the obfuscation w/r/t GWT, I know no obfuscation algorithm is unbreakable and I know some people are going to point out you should be protecting your most valuable IP behind the server, but IP also entails UI design and functionality. 

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Jens]

http://en.wikipedia.org/wiki/Security_through_obscurity

GWT does not obfuscate your JS in order to protect it. It does so to shrink the JS code. The same applies to CSS classes via CssResource. 

An attacker has complete control of your JS code. He can set breakpoints, edit the code, log variable contents. So with some work he can identify these algorithms you want to "protect" and analyze/change it. It does not really matter if the code is obfuscated or not.

[OrNOt]

So,how can I protect my js code suppose for some reason I must put
that algorithm to client side?

[rpromjr]

You originally stated "suppose no RPC is involved here," yet if you
must put it in the client side you may want to review your design and
redesign to use some RPC.

[Jens]

You can't. To protect your code you have to use some RPC and implement the algorithms on server side.

[OrNOt]

OMG,it's a really sad news. Anyway, obfuscation can at least make the
codes hard to readable and its reader must pay more efforts to
recover the original codes somehow, doesn't it?

Second question: Even the code can not be recovered, it still can be
used arbitrarily by anybody as long as it is deployed on one server,
right?

[Uemit]

Depends. You can apply authentication and authorization on the server/backend to make sure that not anyone can use it.

[Palo G.]

I think that poeple not fully understand what is Google Web Toolkit. I
saw time consuming computations on cliend side code, and similiar
mess. You have to clear that if you have some valuable alghorithm you
have to put it into server side code. Of course as Uemit said, you can
protect generated javascript. But obfuscation is just another tool to
security by obscurity - which is efficient only for little time.
Hackers are spending time mostly by reading source code, so some
obfuscation is just another step for them.

[Uemit]

@Palo G.

Actually I wasn't suggesting to protect the generated javascript but to put the algorithm on the server/backend and access it from the client via RPC or any other method. 

I think what OrNot wanted to know is whether he can somehow make sure that only specific user can execute the RPC call and this can be done if the RPC is secured via some authentication/authorization mechanism. 

I also agree security by obscurity is not the right approach. 

However I do believe there is a use case for time consuming computations on the client side. With each browser iteration/version Javascript Engine becomes faster and faster and nowadays a common desktop machine/laptop has enough horse power to do computational intense calculations on the client side. So I think more and more some computational tasks which used to be done on the backend will move to the client. 

[Harpal Grover]

Yes, this is correct, and this is why more and more people want better IP protection for client-side browser code. Unfortunately it just isn't possible with modern browsers, hopefully one day it will be.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/c83YRnzgjYcJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Harpal Grover
President
Harpal Grover Consulting Inc

[Uemit]

@Harpal Grover: 

Actually there might be a solution right now. You can use Native Client SDK to develop a C++/C application which runs in the browser.  The application will be compiled to a binary and then transmitted to the client/browser where it is executed in a sandbox. It is still possible to use a Dis-assembler in order to figure out the algorithm however it is much harder than obfuscated javascript code.

However until now NaCl is only supported in Chrome. 

[OrNOt]

@Palo,G:
Uemit is correct. There are many cases that need client computing and
specific algorithms, for instance, image processing, especially for
those which
need prompt interactivity. You can not always push the data to the
sever to
process and then get the result back to show. In low bandwidth
internet,
that will bring the user to kill himself.

At least till now, the GWT is commonly used for text-based
applications, say
,information system. As the HTML5 comes into play, more and more
canvas or
webgl based web applications will be made by J.S.and most of them need
intensive client computing.I believe the IP issue will become more and
more important.

Actually it is hard for me to understand why J.S., such a poor
language, is becoming so popular. Sun,the stupid giant, made too many
mistakes that let java , so great language, lose his position in
internet era. In some sense, the GWT project is damn ironic,isn't?

On Nov 8, 12:29 am, Uemit <uemit.se...@gmail.com> wrote:
> @Harpal Grover:

> Actually there might be a solution right now. You can use Native Client SDK<http://code.google.com/chrome/nativeclient/>to develop a C++/C application which runs in the browser.  The application

[Palo G.]

I have to disagree with this attitude about time consuming
computations. It's about how are we looking at this problem. I agree
that client side code shouldn't be just presenter of text data or "eye-
candy" animation maker. I'll try to explain why I think that time
consuming computations don't belongs to cliend side. As @Uemit said,
yes computers are still faster and faster, but you forget to mobile
devices which are getting more and more popular in daily use. Last two
years are in trend of tablets and smartphones as main work tools, yes
they are faster and faster but still, can you imagine that most pages/
apps will do time consuming or high CPU operatoions in browsers? If I
said that I hate when my smartphone is drained after end of every day,
then most of you will agree with me that you hate it too.

And this is my only reason why I don't recommend to have these kind of
alghoritms on cliend side code. You can create highly valuable
applications without need of creating they native app clone on
smartphones, because your web app is too big or too slow or after 2
hours of using it mobile user will be very upset about battery state.

OrNOt: for image processing has Google API very good interface.

[Jens]

I would see it from a slightly different angle. I'll put my code on the server if one or more of these points matches:

- Algorithm is so time consuming that its impossible to implement on client side without having the browser to freeze. (UI responsiveness/speed, user experience)

- I have to fetch a lot of data for computation but the result I am interested in is pretty small. (save bandwidth with respect to mobile devices)

- I want to keep the algorithm private. (protect code)

- GWT cant compile the code to JavaScript (GWT restrictions)

So if you have a pretty complex algorithm, but its fast enough that a browser does not freeze and you don't need tons of data from your backend as input for that algorithm its totally fine to implement that algorithm on client side. 

Basically it all comes down to user experience. If the user experience is great, you have done it correctly.

-- J.

[Uemit]

@Palo G.: 

I agree that there battery consumption on mobile devices is an issue and I wasn't actually referring to "traditional" web-applications. 
However there are some special use cases (scientific field) where it does make sense to use the available computational potential of the client machines (which are idle most of the time). 
In these special use cases mobile devices only play a minor role. 
I also think that to some extend there is no way around having separate implementations of parts of the application for different devices. At a minimum different view implementations are necessary in order to cope with different screen sizes. Take the mobilewebapp from the last I/O as an example. 

Theoretically one could have a fallback mode for mobile devices where the algorithm is run on the server.