How to remove/alleviate public users' fear of downloading java for your web app?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Probably this question has been asked many times, however, I have not
found a satisfactory answer, hence, post it here.

We in the industry know that there's nothing to fear for downloading
and installing it. However, lots of others fear downloading software,
how would you alleviate, if not eliminate, this problem for public
users? Saying, java is like "info infrastructure" like "highway" to a
vehicle may not gain user's confidence, does it?


Re: How to remove/alleviate public users' fear of downloading java for your web app?

Gazing into my crystal ball I observed writing in

Quoted text here. Click to load it

I would imagine that certicates from various agencies would help, eg.
Verisign, Truste, etc.  If you are a member of the BBB, etc.

Adrienne Boswell at Home
Arbpen Web Site Design Services
Please respond to the group so others can share

Re: How to remove/alleviate public users' fear of downloading java for your web app?

the lovely and talented broadcast on

Quoted text here. Click to load it

Assuming making your browser slow for a stupid applet that is a waste of
everyone's time and which could accomplish the same purpose (if it has any
purpose other than feeding the ego of someone who considers himself a 'web
designer') by simpler and sleeker means is nothing to fear.

Quoted text here. Click to load it

Jave sucks.  You suck.

Lars Eighner     < <
                         Countdown: 486 days to go.
                    What do you do when you're debranded?

Re: How to remove/alleviate public users' fear of downloading java for your web app?

DonLi2006 wrote:

Quoted text here. Click to load it

Justified fear.

You can digitally sign your Java archives.
You can buy a VeriSign identity: ;jsessionid=G0WcNHORKGUeWdMOiX42Fb9lU4trWfMYVgDSezH9HC2C4xCynWbd!-312669494

It won't prove that you're not a malicious entity.
It just gives you an identity. It proves that all your software comes from  
the same company and has not been modified.

Users of your services will acquire trust to your company by testing your  
software and seeing that it doesn't contain any malware, then:

1) They will trust your identity.
2) They will download other software from your site without fear that you  
intentionally put malware in it or that the software has been modified and  
virii put in it. This thing typically happen when a domain name is sold,  
or a mirror of your site is created, and a new malicious entity masks  
virii in old resources.
3) They may say to friends or other entities that the entity known under  
your identity is not malicious.
4) Your identity may be white-listed on lists of trustable entities.

*Once* your entity is trusted, your identity proves that your software is  
yours and gives trust to your software.

On the other hand, if an entity sign some malicious software with some  
identity, some users will notice that, and may black-list this identity.

Or you may try to make a highly trusted third party entity, such as  
Microsoft, sign your software. This company would review your code. I  
don't think Microsoft provides this service, but other companies may. Of  
course, the cost (in dollars) would be very high.

Quoted text here. Click to load it

Trying to convince somebody that something unsafe is safe and doesn't need  
trust may have two effects:
1) Convince stupid people who anyway click YES to every dialog box.
2) Render normal people suspicious because of your lie. Executing software  
IS unsafe.

Similarly, if you find somebody in the street who ask you for $1 to phone  
in a phone cabin, you may not be very suspicious, but you will be much  
more suspicious if he say "Please, give me $1. I'm not a pickpocket or a  
thief. I haven't a loaded handgun. You don't risk anything."

PS: This question is off-topic on comp.infosystems.www.authoring.html. I  
cross post to comp.infosystems.www.authoring.misc and set follow-up to  
this group, but a more general group may be more appropriate.


Re: How to remove/alleviate public users' fear of downloading java for your web app?

When I see something telling me that I have to download a newer release
of Java my heart sinks; I know I'm in for a few months of trying to get
other Java applications to work again. It's one of the few messages that
strike dark terror in me. About its only saving grace is that it makes
the possible future migration to Vista look more attractive by comparison.

I'm not averse to software updates; I've been using computers since 1967
and apply upgrades to everything else on a routine basis.

Steve Swift

Re: How to remove/alleviate public users' fear of downloading java for your web app?

On 22 Sep, 00:18, wrote:

Quoted text here. Click to load it

Don't use Java applets for "public users".

Java is an excellent technology for delivering rich clients over the
web, especially if you use one of the more recent approaches rather
than traditional Applets (look at the work coming out of the Eclipse
project). However it is slow on initial download. For casual users
this is a problem.

Serious (i.e. long-term) users don't have a problem with Java download
times (they only see it once) and if they bother with that much, then
they've probably got a serious and long-term connection to your site,
company, product or service. They will usually have trust in that site
itself (for other reasons, such as being a business partner), so the
security issue becomes secondary (technical security and trust is
superseded by inter-personal trust).

If you're installing an Applet into a browser, then it must be signed.
Contemporary browser settings make it impractical to do it any other
way. In many commercial environments it's technically impossible to
deploy one that isn't signed. However signing is easy, as a Java
developer can self-sign a JAR with a self-generated certificate.

If you're selling an intranet app, the customer trusts your business,
and your download/delivery channel is secure, then this is enough
security for most cases. The customer already trusts you, the browser
technically trusts the certificate (to a limited extent), and the
customer instructs their browser to extend this degree of trust.

These self-signed certificates are still relatively low security
though. They're signed, but it's foolish to trust the signature (even
if you trust the body who claims to have signed them, you can't trust
that it's actually them and not a spoofer). So the next step is to use
an externally verifiable certificate, either one that's given to you
by a trustworthy body (Verisign, Truste et al., who certify that
you're not someone they would refuse to take money from (Matt

Alternatively you can use a PKI-verified PKCS certificate, verified
through the usual PGP-like "web of trust" and indirect references
through some mutually trusted 3rd parties. The advantage of this is
that it doesn't involve paying money to Verisign etc., and it's more
reliable (in terms of provable identity) than relying on Verisign etc.
However this approach is still little used or understood, and it
scares the IE-using punters who barely understand a mainstream X.509
certificate, let alone something that relies on networks of
trustworthy hippies and squid-obsessed crypto-wonks.

Site Timeline