

Coping with Java security changes - wmnwmn

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&#x27;t have to program two UI&#x27;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&#x27;re going to be able to accomplish what you want to in that regard.<p>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?
======
brudgers
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.

------
fadzlan
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.

~~~
wmnwmn
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.

~~~
lgieron
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.

~~~
wmnwmn
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.

~~~
lgieron
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.

