Coping with Java security changes | Hacker News Reader

Coping with Java security changes

4 pointswmnwmn6 comments

We really like Java for bioinformatics apps because the same app can run the heavy-duty backend processing, as well as the web-enabled front-end for querying results. We don't have to program two UI's, one for standalone use and one for public data access over the web. Also, it provides a full UI programming environment so you can be pretty sure you're going to be able to accomplish what you want to in that regard.

Problem is the security is getting ever more burdensome. I am wondering two things: 1) How are people coping with security? By paying a CA for signing? 2) Is there another platform we could be using to achieve the goals outlined above?

View on HN

The answer to the issue with Java security from the a web user's perspective is simple. Skip web certificates and rewrite the code with something less hazardous. A certificate doesn't solve their problem and it doesn't solve the organization's problem. It just solves the problem of a person within the organization tasked to do something about the problem but who is not looking forward to what is required.

Java on the web is technical debt whose note is coming due. Fortunately it's not onerous just a little painful, and repayment removes a possible impediment to user base growth.

What about using JSP? It's somewhat Java and doesn't require Java on the front end(which is the source of most security problem).

On the server side, you have to look for the vulnerability of the web container that you are using.

I do not see how would a CA helps you in your concern. Yes, having certs provides you encryption when your data is travelling, and client side cert may also helps you as a method as authentication if you wish, but all those does not help you in the Java security problem itself.

I'd be interested of a different opinion.

Sorry, I was not being very clear. We're not concerned with security per se, only with reducing the security-related hurdles that our users have to go through to run our applet. Signing with a proper cert will reduce that, and probably we'll do that, but it's not free and I'm guessing it will have its own inconveniences. We are worried that Java security could become so onerous that it just isn't usable on the public internet, but we're not seeing another similar option.

That could be true for general consumers, who could be scared into disabling Java altogether in their browsers(so that some part of the population wouldn't be reached by the app). On the other hand, if you're making B2B/scientific app for a specific niche, your target audience should be interested enough in what you have to offer so that, even if they disabled Java, they'll turn it back to check out your app. In other words, people will gladly suffer minor inconvenience for an app that adds value, while would be probably put off if the app is another social network/messaging app/game etc., where the perceived value is vague at best.

Yeah, you're probably right...I hope...and Java still seems to the only game in town for unified web + desktop functionality.I just don't see another choice.

My understanding is that web apps have some limitations that can be a show-stopper for scientific apps - for example, there's no way to gain an arbitrary access to file system (something that is easily doable with a signed applet), which can make bulk processing/import etc. impossible. That's the reason I recommended applets in the startup I work for.

Reply on news.ycombinator.com