[Tutorial] Instalação manual do Ambiente de Execução Java (JRE) no *Ubuntu Linux

[paulobenedito]

Uau, que bela história! A minha é mais ou menos parecida com uma palavra que você vez ou outra cita no seu texto: uma história rudimentar.

Windows XP/LanHouse/Muitas pargas/Pouco dindin para manter o W7 que chegou/GNU/Linux/março de 2011

Desde então na minha máquina entra um monte de pinguim e nenhum windows, apesar de eu trabalhar na área de informática

===== Editado =====
Quase esqueci, muito obrigado por uma curiosidade ou outra que absorvi do seu texto, valeu mesmo

T+

[Sampayu]

Uau, que bela história! A minha é mais ou menos parecida com uma palavra que você vez ou outra cita no seu texto: uma história rudimentar.

Windows XP/LanHouse/Muitas pargas/Pouco dindin para manter o W7 que chegou/GNU/Linux/março de 2011

Desde então na minha máquina entra um monte de pinguim e nenhum windows, apesar de eu trabalhar na área de informática

===== Editado =====
Quase esqueci, muito obrigado por uma curiosidade ou outra que absorvi do seu texto, valeu mesmo

T+

Bacana, Paulo. E obrigado, também.

[Julio Cesar Gutierrez]

Olá Sampayu.

Em primeiro lugar, obrigado pela sua atenção e trabalho e desculpe pela demora para responder, pois no final de semana me ausentei do computador.

Agora vamos às considerações do tópico que eu postei.

Fiz tudo o que você ensinou e não tive problema para entrar na página do Banco do Brasil com o mozilla-firefox-24.1.0esr e o jre-8u65-b17.

Já quando tento atualizar o mozilla-firefox para 38.4.0esr (patch de segurança do Slackware) não consigo acessar a página nem com o jre-8u65-b17 nem com o jre-8u66-b17, que é a versão mais atual disponível hoje no site da Oracle (versão tar.gz), não sei se a versão para Ubuntu .deb foi atualizada para a 8u66-b18.

Quando atualizo o jre para a versão 8u66-b17, não consigo entrar no BB com a versão do mozilla-firefox-24.1esr, com a 38.4.0esr, com a 42 ou a 43b.

Parece que se trata em um bug do firefox e do java. Os dois, principalmente o java, são multiplataforma, sendo assim, não importa muito a plataforma no qual são executados.

De qualquer forma, minha intenção foi contribuir para o tópico, que eu observei, é o mais completo no assunto na língua portuguesa. Assim postei relatos do bug e posto abaixo mais um, relatado no Windows.

https://bugzilla.mozilla.org/show_bug.cgi?id=1221448

Em resumo, o que acontece é o seguinte:

O bug da versão 8u66-b17 foi corrigido na versão 8u66-b18 e no mozilla-firefox 42, que me parece, é a versão da atualização de segurança do Ubuntu (pesquisei no Distrowatch), não foi corrigido, ainda, na versão 38.4.0esr que é a versão da atualização de segurança do Slackware.

Daí eu ter conseguido acessar o BB com o openjreJRE 1.7.0_91. No caso do java da Oracle, a última versão 7 que possuo é a 79, sendo solicitado a atualizá-la quando tento acessar a página.

Sem mais, e obrigado pela atenção

[Sampayu]

Olá Sampayu.

Em primeiro lugar, obrigado pela sua atenção e trabalho e desculpe pela demora para responder, pois no final de semana me ausentei do computador.
(...)
Sem mais, e obrigado pela atenção

Oi, Julio. Desculpe, agora me dei conta do real problema que você está relatando. Eu havia entendido que você não estava conseguindo usar o JRE proprietário 1.8.0_66-b17 em nenhuma versão do Firefox (nem mesmo na 24.1.0), por isto comentei que usando o método anteriormente relatado eu consegui usar essa versão aí do JRE no Firefox 24.1.0, dentro do Slackware 14.1.

Estou digitando esta mensagem no XUbuntu, mas estou com o Slackware 14.1 aberto na VirtualBox. Usando o Slackware, acabei de obter o tarball https://ftp.mozilla.org/pub/firefox/candidates/38.4.0esr-candidates/build2/linux-x86_64/pt-BR/firefox-38.4.0esr.tar.bz2 (que nada mais é que o tarball de instalação do Firefox versão 38.4.0esr que você mencionou), daí descompactei-o dentro de /root/Downloads/firefox-38.4.0esr, em seguida criei a pasta /root/Downloads/firefox-38.4.0esr/browser/plugins e joguei o link simbólico lá dentro:

Código Selecionar Expandir

ln -sf /opt/java/jre/lib/amd64/libnpjp2.so /root/Downloads/firefox-38.4.0esr/browser/plugins/sunjava

Após isso, executei esse navegador:

Código Selecionar Expandir

/root/Downloads/firefox-38.4.0esr/firefox

...daí acessei about:plugins e o plugin apareceu. Em seguida, acessei http://www.java.com/pt_BR/download/installed8.jsp e o applet detectou o plugin. Daí fui até o website do Banco do Brasil e o Java também funcionou normalmente.

Você chegou a experimentar criar a pasta "plugins" dentro da pasta "browser" e então criar o link simbólico "sunjava" dentro de "../browser/plugins"? Se ainda não tentou esse método, fica a dica. Espero que funcione. Aqui deu certo.

Após o teste acima ter dado certo, ainda dentro do Slackware eu acessei https://www.mozilla.org/pt-BR/firefox e baixei a última versão do Firefox (versão 42.0), daí descompactei o tarball dentro de /root/Downloads/firefox-42.0, acessei /root/Downloads/firefox-42.0/browser, criei a subpasta "plugins" e joguei o link simbólico "sunjava" dentro dela, igualzinho ao que eu já havia feito com o Firefox 38.4.0esr. Depois disso, executei o navegador (com o comando /root/Downloads/firefox-42.0/firefox) e novamente deu tudo certo: o plugin JRE ficou visível em about:plugins, o applet em http://www.java.com/pt_BR/download/installed8.jsp detectou o plugin, e eu novamente consegui acessar o internet banking do Banco do Brasil sem problema nenhum.

A minha conclusão é que, se havia algum bug, esse bug estava no JRE (não no navegador) e já foi corrigido na versão 1.8.0_66-b17 do JRE, caso contrário eu não estaria conseguindo usá-lo para acessar o internet banking via Firefox 38.4.0esr.

Tenta aí esse esquema de criar a subpasta "plugins" dentro de "browser" e então criar o link simbólico dentro dela. Acredito que com isto o problema seja resolvido de uma vez por todas. Estou torcendo aqui para que dê certo.

[Sampayu]

Como todos os que leram a introdução deste tutorial sabem, em setembro/2013 a equipe da Google responsável pelo desenvolvimento do navegador Chromium anunciou que a Google começaria a gradualmente remover de seus produtos o suporte à tecnologia NPAPI, que é necessária para o funcionamento de plugins como p.ex. o que existe no JRE (e também no JDK) da Oracle. Em suma: o plugin Java deixaria de funcionar nos produtos Google (navegadores Chrome e Chromium, ambiente do sistema operacional Chrome OS etc.).

Assim, em abril/2014 a Google fez sua primeira vítima: o Chromium do Linux foi atualizado para a versão 35 sem suporte à NPAPI. Cerca de 2 meses depois, também o Chrome do Linux foi atualizado para a versão 35 sem suporte à NPAPI. Poucos meses depois, o suporte à NPAPI também foi removido do Chrome para sistema OS X. Então, em agosto/2015 a Google anunciou que encerraria o suporte à NPAPI também nos navegadores do Windows.

Como reação a isso, a Oracle emitiu um comunicado, no mesmo mês (agosto/2015), anunciando o fim definitivo do suporte da Google à NPAPI em todos os seus produtos, para todos os sistemas (Linux, OS X e Windows), e passou a recomendar aos desenvolvedores a tecnologia Java Web Start.

O problema é que, além de a Opera haver removido o suporte à NPAPI a partir da versão 34 do seu navegador de 64 bits, se até então os usuários ainda podiam contar com o suporte à NPAPI nos navegadores mantidos pela Fundação Mozilla (Firefox, SeaMonkey, Iceweasel...), agora devem começar a se preparar para a "contagem regressiva para o fim dos tempos": de acordo com um comunicado emitido em outubro/2015 pelo Benjamin Smedberg (gestor de qualidade do Firefox), a Fundação Mozilla pretende desativar completamente o suporte à tecnologia NPAPI, em todos os seus navegadores, até o final de 2016.

No mesmo dia desse anúncio da Mozilla, a Oracle emitiu um comunicado reiterando que NÃO pretende desenvolver um plugin PPAPI para o Java poder funcionar em navegadores que suportam PPAPI (como é o caso, por exemplo, do Google Chrome, do Google Chromium, do Opera Browser, e, no futuro, também do Mozilla Firefox). No mesmo comunicado, a Oracle reiterou sua sugestão para que os desenvolvedores substituam a NPAPI pela tecnologia Java Web Start.

Em síntese, isso significa que num futuro bem próximo será jogada a "última pá de terra" sobre a NPAPI, e daí este tutorial "morrerá" junto, já que deixará de ser útil (exceto talvez para fins históricos e aproveitamento de algumas informações extras e off-topics que estão presentes ao longo da discussão do tutorial).

Vão se preparando, pessoas. Como a Oracle não está disposta a desenvolver um plugin Java com tecnologia PPAPI (como p.ex. ocorreu com o plugin Flash: o Google Chrome atualmente utiliza um plugin Pepper Flash, que nada mais é que um plugin Flash, só que de tecnologia PPAPI), o fim da NPAPI sacramentará o fim do plugin Java, e portanto os websites (como os dos bancos) adotarão outras soluções tecnológicas, como Java Web Start ou um desses módulos de segurança que são instalados a partir de um pacote à parte (um pacote DEB, por exemplo).

[galactus]

 Sampayu, você sabe algo a respeito  do desenvolvimento do Java Web Start  para Linux?

[Sampayu]

Sampayu, você sabe algo a respeito  do desenvolvimento do Java Web Start  para Linux?

Não, nunca estudei nada, li nada nem acompanhei nada relacionado ao desenvolvimento, instalação, configuração, execução etc. do Java Web Start (JWS). Há alguns anos cheguei a rodar uma aplicação JWS, mas foi há muito tempo, para fins de testes, e uma única vez. Não me lembro do que fiz, nem como fiz, rs.

Após ler as notícias que citei na minha última postagem, dei-me conta de que em breve eu acho que terei de estudar um pouco de JWS, para me familiarizar com o JWS (entender melhor como funciona e como pode ser usado no Linux). Mas por ora estou na completa ignorância. 

PS: escrevi "acho que" porque se os bancos migrarem todos para módulos de segurança que não dependam do JWS, então estudar JWS não terá utilidade prática. Consequentemente, por ora estou apenas "observando" os bancos. No meu Macbook (sistema OS X) o Banco do Brasil só funciona se eu instalar o módulo de segurança Trusteer Rapport, desenvolvido pela IBM. E recentemente vi o pessoal que é cliente da Caixa Econômica Federal afirmando que a CEF disponibilizou um pacote DEB para instalação de um módulo de segurança no Linux. Portanto, talvez familiarizar-se com o JWS nem venha a ser necessário, já que aparentemente os bancos estão migrando para soluções independentes. É esperar pra ver...

[EdvaldoSCruz]

Aff

Só brigas de poderes essas empresas e o povo oh !!!!Fica a Deus dará

[Flatac]

Olá,

Pegando uma carona no post.

Alguém conseguiu fazer funcionar  o pacote .deb do módulo de segurança do Santander para sistemas 32 bits?

Já tentei várias vezes.O pacote é instalado mas o tal módulo não funciona.

Obrigado

[Sampayu]

Olá,

Pegando uma carona no post.

Alguém conseguiu fazer funcionar  o pacote .deb do módulo de segurança do Santander para sistemas 32 bits?

Já tentei várias vezes.O pacote é instalado mas o tal módulo não funciona.

Obrigado

Olá.

Como não tenho conta no Santander, infelizmente não tenho como testar esse módulo. Eu até posso instalá-lo, mas para saber se ele funciona eu teria de efetuar login no internet banking do Santander, e para isto eu evidentemente teria de possuir conta corrente nesse banco.

Apesar disso, seu comentário foi interessante porque mostra que não apenas o BB e a CEF já estão usando módulos de segurança (acredito que o BB buscará portar o Trusteer Rapport também para o GNU/Linux), mas também o Santander já disponibiliza um módulo para GNU/Linux.

Espero que alguém que acompanha este tópico e possua conta no Santander consiga sanar sua dúvida.

[alevian]

A dúvida do colega veio bem a calhar,  em um momento que estou super decepcionado com o BB.

Nunca usei Java Oracle Sun no linux.
Usava sempre Open JDK, sem problemas, no Debian, Ubuntu, Trisquel...

Usava só com o Firefox, é bom frisar.

Até que um dia deixou de funcionar a parte da corretora, Tesouro Direto...

Reclamei pelo SAC, em vão: http://tentandoser.blogspot.com.br/2015/11/bb-precisa-dar-mais-atencao-que-opera-o.html
Vejam que esdrúxula a resposta: http://tentandoser.blogspot.com.br/2015/11/resposta-do-bb-referente-ao.html

Depois, quase toda vez eu era obrigado a digitar senha enviada para o celular.
Um dia, travou a conta (senha bloqueada).



O trouxa foi à agência, com CNH, pediram para eu retornar com a identidade. (Isso faz uns 10 dias). Aí tem que ouvir a brinhante sugestão do bancário: formatar a máquina.

Agora, travou de novo.

Tenho usado o Santander, de boa. Hoje mesmo peguei um cheque do BB no caixa eletrônico e com ele depositei meus trocados do mês no Santander.

Para usar Santander bastou ligar para o SAC e informar que era usuário Linux e a conta foi habilitada para uso sem o tal módulo.
(dica que o rudregues, aqui do fórum, me passou - acertada dica)

Foi em um tópico que eu abri aqui em março, justamente para falar do tal RAPPORT no BB: http://ubuntuforum-br.org/index.php/topic,115662.msg641505.html#msg641505



(Vejam que, na época, eu já alertava para a necessidade de nos mobilizarmos. Só não sabia que a "coisa" era da IBM. Pouca gente deu bola!)
O Bradesco também nem Java usa. Ambos, Bradesco e Santander, tem cartão com códigos de números.

Só o BB que está cada vez mais com palhaçada. E pelo que conversei, no Ruiwndow$ também bloqueiam senha por qualquer besteira.

Sei do esforço do Sampayu, que carrega esse tópico há tanto tempo. Mas convenhamos que é muita manobra para fazer algo comum aos brasileiros: acessar uma conta bancária.

Espero que o colega consiga usar o Santander como eu tenho usado ou de outra forma simples. Espero também que, ainda que com tremendo atraso, o BB caia na real e deixe de frescuras e de torrar a paciência do povo.

Ainda vou ter de retornar à agência do BB e pedir um novo desbloqueio de senha para ter acesso aos informes de IR ou que imprimam para mim ali mesmo. Mas o relacionamento não anda nada bom.

Terno abraço.

P.S.: Se os Ubunteiros / Linuxers fôssemos realmente unidos, faríamos logo um abaixo-assinado, ainda que virtual, com pelo menos umas 1000 assinaturas e enviaríamos à direção do banco, cobrando algo que funcionasse realmente de forma livre e segura. Mas, nunca vi uma iniciativa dessas ter adesão. O povo é conformado ou tolerante demais, com a Microsoft, com a Oracle, agora com a IBM  e assim  com NOSSO dinheiro, NOSSOS bancos,  empresas públicas  e o NOSSO conhecimento e NOSSA liberdade indo para o ralo...

[Sampayu]

A dúvida do colega veio bem a calhar,  em um momento que estou super decepcionado com o BB.

Nunca usei Java Oracle Sun no linux.
Usava sempre Open JDK, sem problemas, no Debian, Ubuntu...

(...)
Ainda vou ter de retornar à agência do BB e pedir um novo desbloqueio de senha para ter acesso aos informes de IR ou que imprimam para mim ali mesmo. Mas o relacionamento não anda nada bom.

Terno abraço.

Concordo: realmente, o BB nos estressa muito com esses empecilhos. Uma das coisas que mais me incomodam é o acesso ao internet banking ser bloqueado por qualquer besteira. Exemplo: há alguns meses, rodei o Linux Mint Debian Edition (LMDE) numa máquina virtual (mas a máquina host também estava com GNU/Linux) e tentei efetuar login no BB (conta corrente). Resultado: acesso bloqueado. Tentei desbloquear via aplicativo Android: não funcionou. Então tentei via outro computador cadastrado: não funcionou. Daí fui a um caixa eletrônico do BB (desses que leem a digital do cliente, e que por isto deveriam dar pleno acesso ao desbloqueio de qualquer coisa), daí tentei desbloquear usando meu cartão e impressão digital: não funcionou.

Já mal humorado, resolvi ir a uma agência BB, entrei na fila do caixa, mas não deu certo: o caixa não conseguiu desbloquear meu acesso, e me disse que eu teria de me dirigir à minha agência (não podia ser qualquer agência). Então fui à minha agência, peguei fila novamente... Mas o caixa da minha agência também não conseguiu efetuar o desbloqueio, e me disse que somente meu gerente conseguiria.

A essa altura do campeonato eu já estava p da vida, então fui conversar com meu gerente: ele queria que eu formatasse minha máquina, porque o sistema do banco estava acusando falha de segurança no meu computador e a diretiva do banco consistia em exigir do cliente que formatasse a máquina e instalasse um antivírus (mania que esse povo tem de achar que tudo é vírus...). Após eu rir e explicar que meu sistema é GNU/Linux e não possui vírus, e que eu estava apenas rodando uma máquina virtual com GNU/Linux, meu gerente me dispensou de ter de formatar minha máquina (ainda bem que ele ao menos é uma pessoa sensata) e daí chamou a chefe dele. Então tive de me identificar com RG e CPF, e após isso digitei minha senha de acesso ao internet banking, num pequeno teclado que meu gerente me forneceu. Em seguida, tive de digitar também a senha do meu cartão (senha de débito), e o gerente em seguida digitou a senha dele, daí digitei novamente minha senha de débito, então ele digitou novamente a senha dele, e em seguida a chefe dele digitou a senha dela. Uau!!!

Uma das premissas de segurança de dados em Tecnologia da Informação é que, se a sua solução de segurança penaliza o usuário e a prestação do serviço (ou a execução do sistema) que deveria estar sendo protegido, isso significa que você é incompetente, pois a sua solução de segurança não é uma solução de verdade: é apenas um mecanismo retrógrado que consiste em desabilitar tudo ao menor sinal de fumaça, para você não ter de realmente lidar com as possíveis falhas de segurança que existem no seu sistema e nos mecanismos de proteção que você implementou para protegê-lo.

Só continuo sendo cliente do BB porque já viajei para os quatro cantos do Brasil e em todos sempre encontrei maior oferta de caixas eletrônicos do BB do que de outros bancos, e eu considero isso uma forma de conforto, claro: nada melhor do que você viajar para o "fim do mundo" (onde normalmente não há Internet, nem sinal de celular, nem muita gente que aceite cartão de débito) e encontrar um caixa eletrônico do seu banco. Também uso BB porque boa parte das pessoas para as quais transfiro (e de quem recebo) dinheiro possui conta no BB. Mas essa segurança burra, neurótica e amadora do BB realmente me incomoda, sempre incomodou...

De qualquer modo, como optei por continuar sendo cliente do BB, sigo à risca os requisitos técnicos do BB: o BB informa explicitamente que o cliente que usa GNU/Linux deve usar um kernel cuja versão seja igual ou posterior à 2.4, e que o Java Runtime Environment (JRE) a ser usado tem de ser o da Oracle que se encontra disponível para download em http://java.com/pt_BR

Eu sigo à risca o que o BB determina porque se algum dia sumir dinheiro da minha conta e o banco não quiser me indenizar, e por isto eu ingressar na Justiça contra o banco, o banco não poderá alegar que minha conta corrente só foi violada porque eu estava usando um software não homologado pelo banco (e que portanto seria em tese um software menos seguro do que o software que o banco disse para eu instalar). É por isto que recomendo a todos os clientes do BB que não usem o OpenJDK: somente o JRE proprietário da Oracle. Não é apenas uma questão técnica (se o OpenJDK vai ou não vai funcionar no website do BB): trata-se de uma questão legal, de Direito mesmo.

Embora eu não goste dos problemas ligados ao plugin do JRE, particularmente gosto menos ainda desses módulos de segurança, pois eles são obscuros e invasivos. Como comentei neste mesmo tópico, há algum tempo, ao meu ver uma solução mais simples e elegante seria algo como a verificação em duas etapas, que nada mais é que um token, só que na forma de software. Isso nos livraria não apenas dos plugins NPAPI, mas também dos plugins PPAPI, do Java Web Start e desses módulos de segurança.

Eu já uso verificação em duas etapas para acessar alguns serviços online. O aplicativo token que eu uso para isso é o Google Authenticator. Alguns serviços online que possuem verificação em duas etapas e são compatíveis com o Google Authenticator: Outlook (Hotmail), Google (Gmail, YouTube, Google+ etc.) e Facebook.

[alevian]

Sampayu,

Muito bons seus esclarecimentos.
Essa solução do token / verificação em duas etapas é a que o Bradesco usa. Há o cartãozinho e também o token por software.
No Santander tem o cartão.

Incrível como os bancários do BB abusam do peão consumidor.
O cara fala e faz o que ele quer e tá valendo.
Para você só conseguiram desbloquear sua na agência! (Ainda bem que não tive que ir até Itaquera (local da agência), se trabalho na Barra Funda e moro no Cangaíba!)
E. bem lembrado, falaram para mim também do vírus.
Em suma, não sabem o que dizem.

Agora, convenhamos, se nem o bancário, concursado, supostamente capacitado para operar e orientar a operar com o sistema do banco, ou seja COM CONHECIMENTO MUITO SUPERIOR AO DO HOMEM MÉDIO, sabe o que dizer, imagina exigir isso dos milhões / milhares de simples mortais que usam a conta, ainda que sejam LINUXERS.

Sinceramente duvido que teriam a coragem de alegar, em uma disputa judicial o uso de sistema não homologado como a causa do sumiço de $.
Duvido até que teriam organização suficiente para pensar nessa possibilidade / brecha.
E duvido ainda mais que um juíz cairia numa dessas. Se não for em juizado, haverá o auxílio técnico. É possível ao consumidor pedir que o banco PROVE o que está a alegar. (inversão do ônus da prova, a critério do juiz)
E o Direito procura sempre o HOMEM MÉDIO.
É verdade que o sistema deve funcionar com o que foi homologado. Mas deve ter também agir como barreira para todo e qualquer tipo de uso indevido. Além disso, o que limita o direito deve ser colocado EM DESTAQUE, coisa que nunca fizeram.

Pelo contrário, o banco vem permitindo e transacionando há anos e provavelmente com muita gente, com o uso do OPEN JDK. Lucrando, assim, com esses clientes e suas transações "irregulares".
Não me parece justo tentar fugir da raia quando surge o problema.
Enfim, nessa questão ficaríamos argumentando até o fim da vida, inutilmente, no campo das conjecturas.

De todo modo, seu procedimento é plausível, usar o sistema homologado para eliminar o argumento do banco, ainda que bizarro, dentro da conjuntura - não apenas técnica / tecnológica, mas dos cidadãos com quem se lida, do jeito que é dada a orientação etc.

Se havia um brasileiro que sempre foi partidário do BB era eu.
Mas, até que implantem sua sugestão elegante, agora vou de Santander ou Bradesco tanto quanto puder.

Abraço.

[Sampayu]

Sampayu,

Muito bons seus esclarecimentos.
Essa solução do token / verificação em duas etapas é a que o Bradesco usa. Há o cartãozinho e também o token por software.
No Santander tem o cartão.

Incrível como os bancários do BB abusam do peão consumidor.
O cara fala e faz o que ele quer e tá valendo.
Para você só conseguiram desbloquear sua na agência! (Ainda bem que não tive que ir até Itaquera (local da agência), se trabalho na Barra Funda e moro no Cangaíba!)
E. bem lembrado, falaram para mim também do vírus.
Em suma, não sabem o que dizem.

Agora, convenhamos, se nem o bancário, concursado, supostamente capacitado para operar e orientar a operar com o sistema do banco, ou seja COM CONHECIMENTO MUITO SUPERIOR AO DO HOMEM MÉDIO, sabe o que dizer, imagina exigir isso dos milhões / milhares de simples mortais que usam a conta, ainda que sejam LINUXERS.

Sinceramente duvido que teriam a coragem de alegar, em uma disputa judicial o uso de sistema não homologado como a causa do sumiço de $.
Duvido até que teriam organização suficiente para pensar nessa possibilidade / brecha.
E duvido ainda mais que um juíz cairia numa dessas. Se não for em juizado, haverá o auxílio técnico. É possível ao consumidor pedir que o banco PROVE o que está a alegar. (inversão do ônus da prova, a critério do juiz)
E o Direito procura sempre o HOMEM MÉDIO.
É verdade que o sistema deve funcionar com o que foi homologado. Mas deve ter também agir como barreira para todo e qualquer tipo de uso indevido. Além disso, o que limita o direito deve ser colocado EM DESTAQUE, coisa que nunca fizeram.

Pelo contrário, o banco vem permitindo e transacionando há anos e provavelmente com muita gente, com o uso do OPEN JDK. Lucrando, assim, com esses clientes e suas transações "irregulares".
Não me parece justo tentar fugir da raia quando surge o problema.
Enfim, nessa questão ficaríamos argumentando até o fim da vida, inutilmente, no campo das conjecturas.

De todo modo, seu procedimento é plausível, usar o sistema homologado para eliminar o argumento do banco, ainda que bizarro, dentro da conjuntura - não apenas técnica / tecnológica, mas dos cidadãos com quem se lida, do jeito que é dada a orientação etc.

Se havia um brasileiro que sempre foi partidário do BB era eu.
Mas, até que implantem sua sugestão elegante, agora vou de Santander ou Bradesco tanto quanto puder.

Abraço.

Em agosto/2014 eu postei um comentário a respeito dessa questão jurídica. Em suma, é isso que você comentou mesmo: o ônus da prova é invertido em favor do cliente (parte mais fraca da relação de consumo). Eu optei por usar o JRE proprietário mais para não dar margem mesmo a qualquer tipo de contestação do banco, embora eu acredite ser mesmo bastante difícil o banco conseguir elaborar uma perícia tão minuciosa e aprofundada que consiga realmente comprovar que a falha se deveu às diferenças de código que existem entre os dois binários (OpenJDK e JRE proprietário).

Eu resido na região do Sacomã (zona sul de São Paulo) e minha agência fica em Santana (zona norte). Tive de fazer uma viagem até minha agência. Gastei uma tarde inteira com esse problema. Realmente desgastante. Nesse dia fiquei com vontade de trocar de banco. Acabei desistindo por causa do que comentei anteriormente, mas a "coceira" para trocar de banco sempre volta quando meu acesso volta a ser bloqueado (o que felizmente raramente ocorre, embora eu saiba que não posso sequer testar meu acesso ao BB usando máquina virtual, senão meu acesso volta a ser bloqueado pelo sistema amador do BB).

Não sabia que o Santander já está usando token por software. Bacana! Eu sei que o BB possui token, mas é apenas físico (pendrive USB) e não funciona em qualquer Linux (certa vez consegui fazer um desses tokens funcionar no meu sistema, mas foi um parto, daí larguei pra lá, devolvi o token pro banco). Quanto a token por software, não há. Acho bizarro que eu tenho um aplicativo no meu smartphone (o que não chega a ser muito diferente de eu ter um aplicativo token como o Google Authenticator) mas não posso usar meu smartphone para desbloquear meu acesso. Mais impressionante ainda que, quando o BB suspeita de tentativa de invasão a partir de um determinado dispositivo, bloqueia o acesso à conta, ao invés de bloquear o acesso do dispositivo a partir do qual ocorreu a suposta tentativa de invasão. Completamente ilógico.

Para fechar a falta de lógica com chave de ouro, é inacreditável que num caixa eletrônico que se vale de identificação por dermatoglifo eu não possa desbloquear meu acesso à conta. Fico me perguntando qual é a finalidade de um caixa eletrônico ler minha digital, se, embora isso garanta que eu realmente sou eu, ainda assim o banco não me deixa desbloquear meu acesso. "Incompetência" é mesmo a única palavra em que consigo pensar...

Frustrações com o BB à parte, o fim do suporte à tecnologia NPAPI forçará o BB a migrar para soluções alternativas. Se o BB seguir o que já fez no OS X, provavelmente pagará à IBM para que desenvolvam uma versão do Trusteer Rapport para o Linux. Vamos ver...

[EdvaldoSCruz]

Infelizmente isso ocorre nos bancos porque há pessoas de má fé, queridos, por isso os bancos usam essas ferramentas.

Já que estão julgando os bancos, vamos lá, vocês devolveriam uma carteira ou maleta cheia de dinheiro, ao acharem ?

Observação: Muitas pessoas que usam o bb desabilitaram o dermatoglifo, pois não leem quem tem excesso de ácido úrico nas mãos.

Já no banco Santander, eles deixaram duas opções no próprio caixa eletrônico quando ocorrer esse tipo de problema acima citado.

A ignorância é uma Bênção de Deus.