wood burning stoves
The moose likes HTML, CSS and JavaScript and the fly likes On security and intellectual property Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » HTML, CSS and JavaScript
Bookmark "On security and intellectual property" Watch "On security and intellectual property" New topic

On security and intellectual property

Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Hello Chris. I have a question regarding security and overall intellectual property issues.

As more apps become "richer" you end up with more exposed logic in the form of Java Script. And we're not talking about fancy form renders and stuff.

In the good ol' day it was all magic. You had a page. Posted. Work was done on the server and the response was returned to you. On this side of the graph we have more latency, but greater security.

As we move to the right we decreace the latency as more work is being done by AJAX in an asyncronous manner. But more of our business logic is being exposed. Our pages look more "active" so to speak, but they're less secure and reveal more of our "implementation" to the world.

On the extreme right of the graph we reach a "no post required" scenario. In this I see a web page becoming almost an applet. All is handled by AJAX and JavaScript, but I see it extremely insecure. Given javascripts scripted nature it is easy to reverse engineer and alter. You also need to expose more and more calls from your server. So latency should start to increase if you want to keep your "know how" secret (do the real interesting/hiden stuff on the server). As each action on screen calls for a connection to the server. Unless you expose calculations and algorithms in JavaScript.

An example to illustrate this would be a table with price quotes. In the ol' days way I'd fill up the form, submit, get and updated quote and then hit accept. A more AJAX way is to update the price as the quantity increases (posibly checking inventory for availability). Problem here is that I get an AJAX request everytime the user changes quantity ordered (this is because I give discounts on volumen so I can't just multiply with js). To reduce this I could download the price steps to the client when the product ID or type is selected, but then I'm exposing my price steps. Which is something I might not want to do. Although this is simple example I hope it shows my worries of something that in the world of desktop apps and applets was hidden form the average user.

Is this a generalized concern with AJAX developers? Is there something being done to address these types of issues? And will this eventually be the barrier for rich clients?
Christian Gross
Ranch Hand

Joined: Feb 20, 2006
Posts: 85
In the thread http://www.coderanch.com/t/117472/HTML-JavaScript/Ajax-Security-Libraries I was rambling incoherently about this point. The actual question was "Are there security libraries", and that made me ramble... (Go near the end of the thread).

From the thread when creating Ajax applications you have to consider the client insecure and not under your control. Of course this is a problem as we don't know which client is doing what thing. This is the point where I started rambling about DRM. EBay, and Amazon for their web services have begun implementing DRM, more so with EBay. In the stated examples the DRM is very primitive and it is used to track API usage from a given application. With the acceptance of Ajax we cannot avoid the DRM argument, even though many in the Open Source community dispise it (but not Linus).

With DRM we can manage who accesses our application, but that still leaves open the question of being able to see the business logic. For that I say, "Get over it!". If you believe desktop apps are safe, then you are only fooling yourself. I wrote an article regarding obfuscation and the tools that are available for Java and .NET. For kicks I decided to decompile a typical C, and C++ program. Wow, it is scary how easy it is to see what is going on. The reason is because these days we code for the most part against API's. API's are publically declared and cannot be mangled, and hence you can follow the execution of the application, by following the calling of the API's.

The only real solution to "hidding" your business logic is obfuscation because obfuscation tries to lead you astray. Potentially combining DRM with obfuscation you could stop a large number of hackers, or the casual curious user but not the most determined hacker.

Will this stop us from developing applications? Not at all. Because if you don't develop the application somebody else will. Think about the impact of Open Source. Before Open Source the value of the source code to a product like SQL Server, or Oracle would be gargantuan! Imagine today if you were allowed to look at the sources of SQL Server or Oracle would you want to? Outside of curiosity, and competitor interest, I don't think anybody would be interested because there are Open Source alternatives. The value of source code has dropped! This is why I believe companies are interested in IP protection (eg copyright and patents) and why I believe DRM is inevitable.

Author of Ajax Patterns and Best Practices
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
I agree entirely that desktop applications are not secure by a long shot, but I think I should give it my best shot to keep our know how as secret as possible. Sure you can decompile something, but seeing source code javascript is so much easier, even your off the self tech support guy could do it in a second without special tools or training.

I've given this issue a bit more thought and after reading your posts I have a few more brainstorm ideas to throw out.

First and furthermost to clarify some positions. I'm totally pro DRM and I'm totally pro Linux and open source and the whole nine yards. To the point that about 50% of my installed user base runs Linux on the desktop and we use mostly open source development tools and web services.

Of course there are certain companies (particularly one) that will want to make you think that the OS is all that matters. For me what matters is what I run on top of that OS and what I hold in information. There's another one that does the same with music, but I don't buy any CDs, TVs, sound systems, game consoles or games from them. I do watch CSI though

I totally agree with you that the value of source is falling. While the value of what you do with it is not and there is the importance of DRM. Hence it is DRM over your business information not software. But to have that you need to DRM your software.

I think the inclusion of DRM in open source software will be the do or die for getting into the corporate world. As software development tools commoditize themselves and the software developed with them I think DRM will be a key tie breaker. How secure is your application. How secure is the info in it. Are you sure that the right people are watching the right stuff? This is even more important with distributed computing.

Now back to the topic of AJAX. I see AJAX as a communication tool for distributed computing. I also have an axe to grind when it comes to Swing and similar based applications. There is the whole GUI stuff. How it looks different on different systems. Having to keep two interfaces up to date, etc.

Here are a few things I would really like to see growing in the HTTP world.

-With XML we could have just about any tag and visual widget. Not only selects, inputs, buttons, but just about anything that could be plugged into the browser and not be Active X stuff that only runs on one. This way we can solve all the worlds GUI problems with a browser and be done once and for all with the look and feel issue and for all (well not technically, but it's a nice thought once).
-Downloadable code libraries that run like applets, but without a GUI. So the page can talk to it and get some work done. These libraries can be Java for example and have hooks for JavaScript so certain methods can be called.
-We then use AJAX to do the communication between the GUI and the server or even between the loaded libraries and the server.

But hey you'd say. That sounds just like Java Web Start. Yea but it isn't because you don't need Java Web Start. Why load an Swing render engine when you already have one with the browser? Say a mobile device. Why load all the Swing libraries if I already have a JVM and a browser (say Opera)?

To further develop this point lets take the pricing scenario and extend it to a real life case. For example we organize events. So we need to give price quotes to our clients. How much equipment we need, number of participants, vehicles, staff etc. All those are variables that are held inside a spreadsheet, but it is hell to keep up and keep secret. We can't have that laying around or people would know how much it costs us and how to under cut us.

So lets build a web app. So the knowledge is centralized in an application. I have two ways to go. An applet or an HTML based client. I decide to use HTML. I start to code in all the variables and then decide this posting and getting an update is too slow. So I use AJAX. Now hey I can even check to see how many vans I'm using. If I have enought or need to rent.

When a user changes a value AJAX posts all the variables and gets a digested result from the server. But then I realize I'm calling the server just to add this or that which could be calculated on the client side. So why not download that logic to the server (DRM here!!) If I download it as simple java script then I expose a lot of the know how and beat the whole webserver based application benefit. So I need to download a .jar file that does all the math for me on the client side, but still use the clients HTML render engine.

There just seems to be a chasm between the applet-GUI world and the HTML-browser world. At least I don't know of a system that allows you to download the game logic in three modules (to say a number). Then the graphic engine in another four and show them in a browser. You could then have an HTML page with a few frames or views. Some holding pure html code linked to the modules to do all the "math". These modules are then hooked to the graphic modules that allow you to display graphic information in four spots across the screen.

Wow, almost ran out of breath there. Hope I didn't wear you all out with my ranting.
Christian Gross
Ranch Hand

Joined: Feb 20, 2006
Posts: 85
Yeah I can see what you are getting at and by and large we are in agreement. Though there is one thing that REALLY caught my eye and it was in your last paragraph. It is the chasm between the applet-GUI world and HTML browser world.

If I wanted to be cynical about this, and I understand you properly you are making the argument for ActiveX. ActiveX can do what you want. When I was coding ActiveX what I liked is the ability to intermingle from the HTML page to component and back again. I once wrote a sample where C++ was hosting a browser, that loaded a page that hosted an ActiveX component that was able to communicate with my outer C++ application through the HTML browser. The sample ended up being used at the PDC and illustrated how seamless it was to go between HTML and components.

What makes IE clever is that everything is a container, and if your component plays well with IE, it is a container as well. Thus it allows scripts to pass through your container to manipulate GUI elements that your container is managing. It's rather clever when you look closely at it.

Though, we all know what is *wrong* with ActiveX! I say this cynically because for the wrong parts (and they were REALLY wrong) there were also some very good parts to ActiveX.
Eric Pascarello

Joined: Nov 08, 2001
Posts: 15385
This may be a little off your subject, but I just have some free time and want to add why it really can not change.

The whole problem lies in if we change something you will run into a hell of a lot of cross browser differences.

I really do not want to see JavaScript version 2 coming out. Imagine the hell that is going to create since people that developed browsers do not think about how can we upgrade just that part. Instead you have to download the whole thing. So then we need code to support 2 versions of JS. Firefox introduced new array functionality, but we can not use it!

If we change the way the browser works, we are going to break everything that we know today. Look at companies that require NN 4.x support. The browser is roughly 9 years old. Updating technology on the client is totally different than updating the version of the serverside framework. My production site sees tons of windows 98 users with IE 5 and 5.5. People do not upgrade! (I have seen windows 3.1!)

I say if security is a major problem, then you should not venture into the world of the web and look into client apps. New version of the .NET framework has ClickOnce which is a new way to install client apps from the web/network. That is really the only secure way.

We have always dealt with data problems since we put a form on the page. Is the data correct, did it come from my page, is it a robot, etc. I do not ever see this going away. Every talk I do I show the user's the form hack of disabled elements and hidden elements by using the address bars. I just can not believe how many people think that disabled = safe.

So it comes down to, we integrate a new technology into the browser such as some sort of compiled runtime thingy, then we need to face the fact that only 1/10 of the web will be able to use it in the near future.

As mentioned ActiveX was a way an answer to this, but look at the security issues. That trust was broken by people that use the web for bad. Mozilla is supposed to come out with their version, but I am sure holes will appear in that too.

Yes the borwser and web is broken as we know it, but there is no easy fix. When the web was first started, no one would have thought this is how it would turn out.

I agree. Here's the link: http://aspose.com/file-tools
subject: On security and intellectual property
It's not a secret anymore!