O Java Web Start esconde, proteje o acesso direto ao jar?

Se você vai disponibilizar um programa a partir da Internet (via http/https, como é seu caso), fique sabendo que não há proteção alguma.

A idéia principal não é proteger a aplicação em si e sim o seu código.
E se não for http? Uma intranet por exemplo.

Meu maior objetivo neste caso é proteger o jar. posso fazer isso com o JWS?

obrigado thingol

Intranet ainda é http.

Se você quer proteger contra descompilação, use uma linguagem que gera código nativo e “não-descompilável”, como o C++ (argh) ou talvez o Delphi. Não indicaria nenhuma das linguagens de código gerenciado (Java, C#, VB.NET, Delphi.NET etc.) ou que usam pseudo-código (VB 6.0). Nem mesmo o Assembly é muito indicado, porque um programa em Assembly puro é mais fácil de descompilar que um programa gerado por um compilador (o mais notório é o Intel C++, cujo código gerado requer um batalhão de russos para ser compreendido corretamente.)

Você pode tentar dificultar a descompilação com um obfuscador, mas acho que gera mais problemas que os resolve.

O objetivo de proteger o código é por motivos de segurança do sistema contra ataques ou proteção do patrimônio da empresa?

Se for o primeiro caso, eu aconselharia a repensar o modelo de segurança, validando tudo no lado do servidor.

No segundo, bem, um obfuscador faz o trabalho, desde que você não queira debugar ou decompilar teu programa de volta.

Na verdade, eu gostaria de matar alguns coelhos com uma só paulada.

Gostaria de facilitar a atualização para meus clientes via JWS e de quebra garantir que o código não corra
risco de ser descoberto tanto por questão de patrimônio quanto da segurança do código.

Mas, ainda não consegui visualizar como eu poderia fazer isso com a minha aplicação desktop. A não ser criando meu próprio atualizador.

se possível, gostaria de algumas dicas.

obrigado.

Olha Zakim, eu tenho 2 sistemas relativamente grandes que estão trabalhando nesse sistema (usando JWS fazendo atualizações diretamente de um servidor na web) há 5 anos, no qual meu cliente simplesmente fecha o sistema e abre novamente para ele se atualizar, quando eu preciso fazer qualquer alteração eu nunca tenho que ir até ao cliente (mesmo porque eu já fiz alterações até fora do Brasil e resolveu o problema imediatamente), então não vejo porque o pânico sobre proteger o código, lembre-se que java é uma linguagem onde as pessoas não ficam muito afixadas nesse pronto, tente proteger bem o banco de dados e guardar a documentação do seu projeto.

Isso também depende do tipo de cliente que você vai utilizar, eu tenho um contrato com meus clientes onde eles assumem certas responsabilidades sobre o sistema.

Veja o que acontece, se você seguir o que tem no atalho (digamos numa máquina windows):

C:\WINDOWS\system32\javaws.exe "C:\Documents and Settings\Francisco Souza\Application Data\Sun\Java\Deployment\cache.0954162dd-7f9c0b09"

Aí você decide abrir o arquivo que o javaws.exe está chamando, nesse caso 654162dd-7f9c0b09, você verá exatamente o conteúdo do seu arquivo .jnlp, ou seja, com um pouquinho de conhecimento alguém já consegue ver seu .jnlp, então ele já vai visualizar os links para os .jars no servidor, com isso ele vai tentar baixar .jars, se ele conseguir ele vai tentar descompilar com alguma ferrametna de descompilação.

Você pode também usar algum tipo de segurança no servidor.

Obrigado pelas informações Javer.

Que tipo de segurança eu poderia colocar em meu servidor de forma que o JWS só atualiza-se após alguma validação?

Isso é uma idéia que tive recentemente… mas nunca pensei se realmente ia proteger algo.

Criar na aplicação do cliente apenas um Main que tenha um URLClassLoader e carregar a classe direto do servidor.

Mesmo assim seria possivel alguém que entenda pegar os arquivos… mas também em caso de muitas classes ou classes grandes voce teria uma lentidão para carregar.