É possível usar o Universal Game Translator (UGT) totalmente de graça?

É possível usar o UGT totalmente de graça?

Sim, é totalmente possível usar o Universal Game Translator (UGT) sem gastar nada, desde que você configure corretamente opções gratuitas de OCR e tradução.

🧰 Componentes principais do UGT

• OCR (Reconhecimento de texto): identifica o texto na tela
• Tradutor: converte o texto para outro idioma

✅ Opções gratuitas recomendadas

Para não depender de APIs pagas, configure o UGT com:

• Tesseract OCR – OCR local gratuito e offline
• Argos Translate – tradutor local com bons modelos de linguagem

🚫 O que gera custo?

• Google Translate API – tem cobrança por caractere
• Google Vision API – OCR online que consome créditos da Google Cloud
• DeepL API – gratuito até um limite, depois é pago

🛡️ Como garantir que não haverá cobrança

1. Use apenas Tesseract e Argos
2. Desative opções online no painel de configuração
3. Não insira chaves de API se não for usar serviços pagos

💡 Dica final

Embora a qualidade da tradução de serviços pagos seja geralmente superior, o uso local com ferramentas gratuitas já oferece uma ótima experiência para jogos, visual novels e textos simples.

---

“O acesso à compreensão não precisa custar nada — só requer as ferramentas certas.”

Como adicionar o Google Vision na Google Cloud e gerar a chave para usar no UGT?

Como ativar o Google Vision API e gerar a chave para o UGT

Para que o Universal Game Translator (UGT) possa usar OCR com alta precisão, é necessário configurar o Google Cloud Vision API. Veja como ativar e gerar sua chave de API em poucos passos.

📌 Passo 1 – Acesse a Google Cloud

1. Vá até: https://console.cloud.google.com
2. Crie um projeto ou selecione um já existente.

📌 Passo 2 – Ative a Vision API

1. No menu esquerdo, vá em APIs e serviços → Biblioteca
2. Procure por Cloud Vision API
3. Clique em Ativar

📌 Passo 3 – Gere a chave de API

1. Vá para APIs e serviços → Credenciais
2. Clique em Criar credenciais → Chave da conta de serviço
3. Escolha um nome e selecione o papel Editor ou Projeto → Proprietário
4. Escolha o tipo de chave como JSON e clique em Criar
5. O arquivo será baixado — guarde com segurança!

📎 Dica para o UGT

Coloque o arquivo JSON na pasta do UGT e, dentro das configurações, selecione o Google Vision como OCR e aponte o caminho da chave.

⚠️ Atenção

• Evite expor sua chave JSON publicamente
• Você pode configurar limites de uso e alertas no painel da Google
• Se não for usar por um tempo, desative a API ou a chave

---

“Com visão, até os jogos mais obscuros se tornam acessíveis.”

Onde encontrar sua Google API Key

Se você está usando alguma ferramenta que requer integração com os serviços da Google (como tradução, OCR, mapas), em algum momento vai precisar de uma API Key.

🔍 O que é a Google API Key?

É uma chave de autenticação que permite que seu aplicativo ou serviço acesse funcionalidades da Google Cloud Platform (GCP), como:

• Google Translate
• Google Vision
• Maps, YouTube, entre outros

📍 Como encontrar sua chave

1. Acesse o console da Google Cloud:
   https://console.cloud.google.com
2. Escolha ou crie um projeto.
3. No menu lateral, vá em APIs e serviços → Credenciais.
4. Lá você verá a seção Chaves de API.
5. Copie a chave desejada ou clique em Criar credenciais → Chave de API.

⚠️ Segurança

• Evite compartilhar sua API Key publicamente.
• Use restrições de IP e aplicação sempre que possível.
• Revogue chaves antigas ou não utilizadas.

📌 Dica extra

Alguns serviços exigem ativar APIs específicas antes de usar a chave (ex: Google Cloud Translation API, Vision API, etc.).

---

“Uma chave abre portas — mas uma chave exposta abre riscos.”

Traffic Shaping: Basics

Introdução

Nos últimos dias ando vendo vários amigos reclamando consideravelmente sobre a velocidade de banda contratada ser diferente da velocidade real de uso de internet principalmente em determinados serviços, como nesse assunto sou pedra mas também sou vidraça, pois no serviço trabalho na equipe de infra-estrutura de um ISP (Provedor de internet) e em casa sou usuário de internet que utiliza: torrents, videos, EaD, servidores de games, etc; é relativamente comum amigos pedirem para eu ver o que pode estar acontecendo em suas conexões, e na maioria das vezes acabo, infelizmente, constatando que estão sendo vítimas de traffic shaping.

O que é Trafic Shaping?

Imagine a internet como uma enorme avenida, com vários acessos, e onde se misturam carros, motos, vans, ônibus e caminhões, todos carregando uma certa quantidade de pacotes, porém, cada um em uma determinada velocidade. Em horários de pico é normal que o tráfego fique mais lento e congestionado, fazendo com que a velocidade de todos os veículos fique consideravelmente menor. Por conta deste problema o governo decide banir os veículos mais pesados, no caso, vans, ônibus e caminhões, só permitindo sua circulação em determinados horários, enquanto cada vez mais carros e motos utilizam a avenida.

Troque governo por provedores de internet e caminhões por torrents, vans e ônibus por streaming de áudio e vídeo (youtube, radioonline, etc) e temos um exemplo de como funciona o traffic shaping.

A maioria dos usuários não percebem ou se preocupam com isso, mas o restante deles, aqueles que fazem downloads grandes via protocolos de transferência, já notaram que determinados programas ou em determinados horários a internet fica muito abaixo da velocidade contratada. Aproximadamente 10% dos usuários no Brasil são responsáveis por 80% do tráfego nos provedores nacionais. O que faz sobrar mais ou menos 20% de banda para todo o resto.

Por conta disso, vários provedores de acesso à internet, principalmente os que vendem os maiores acessos à clientes, começaram a moldar o tráfego, limitando o tamanho de banda ou número de conexões simultâneas para determinados protocolos que utilizam mais da rede, que são basicamente os protocolos P2P, usados em programas como o Limewire, Emule e o Ares Galaxy, ou os Torrent utilizados em larga escala por vários usuários domésticos. Em alguns casos já me deparei, inclusive, com limites para transmissão de arquivos via FTP, o protocolo utilizado para downloads e uploads.

Essa prática é chamada de Traffic Shaping, e significa literalmente a modelação de tráfego. Os ISP negam a prática por ela ser ilegal e camuflam muito bem a forma como isso é feito.

Como saber se seu provedor pratica traffic shaping

Como acabamos de afirmar, podemos simplificar e dizer que traffic shaping é um jeito que os provedores de acesso encontraram de economizar banda, diminuindo a velocidade com que certos pacotes são enviados e recebidos na sua rede. Essa é uma das causas lentidão de downloads em torrents ou no carregamento de vídeos em Flash, por exemplo.

Como poucos usuários sabem testar sua conexão contra esses métodos, a Google (sempre ela) criou o Measurement Lab, junto com outras 3 organizações onde podemos testar vários aspectos de nossa conexão. Vamos usar como exemplo um teste que detecta traffic shaping do procolo BitTorrent.

1. Acesse Glasnost test.

É usado um applet em java (talvez você tenha de instalar o plugin java em seu navegador) para tentar detectar se o seu provedor está modificando a velocidade de certos pacotes de acordo com a opção que você escolheu. Você pode testar vários tipos de traffic shaping em protocolos de P2P mais conhecidos, ou mesmo em protocolos padrão para a maioria dos aplicativos na internet como POP, IMAP4 , HTTP, SSH.

2. Aguarde a contagem regressiva.

É interassante deixar a conexão livre durante o teste. Vá tomar um café enquanto isso.

3. Descubra se existe o traffic shaping em sua conexão.

Caso houver alguma evidência de traffic shaping irão aparecer resultados em vermelho. No resultado completo é especificado em quais portas foi detectado maior lentidão ou um comportamento anômalo.

Meu provedor pratica Traffic Shaping o que faço?

Existem algumas técnicas para tentar enganar os limitadores, porém, caso esteja sofrendo de traffic shaping a saída geralmente é trocar de programa ou de provedor. Não crie falsas esperanças que algo mudará se reclamar com seu provedor ou mesmo com a ANATEL, as empresas negam a prática e estão amparadas pelo contrato que você assinou. E a ANATEL precisaria de tempo para investigar as denúncias. A solução é encontrar um provedor que permita a você fazer os downloads que quiser.

Porque alguns provedores fazem isso?

Quem compartilha recursos em uma rede, sabe que quando várias pessoas estão conectadas ao mesmo tempo a velocidade é reduzida, pois a capacidade da rede é divida entre vários computadores. O mesmo acontece com a internet, toda vez que os clientes se conectam eles dividem os recursos da rede de seu provedor de acesso, quando provedores vendem planos de 10Mb, 20Mb, 40Mb, 80Mb, etc, acabam por vender mais do que a capacidade total de suas redes, e como dissemos acima que a maioria dos usuários ou não percebem ou não se importam com variações na velocidade em determinados serviços como downloads, torrents, P2P, o provedor consegue economizar banda não entregando a totalidade de internet contratada em serviços que utilizam mais a rede.

Como tentar enganar o Traffic Shaping.

Como foi dito acima, provedores que praticam o traffic shaping estão sempre atualizando suas ferramentas para que você não consiga enganar as limitações, porém é possível fazer algumas tentativas para driblar essas ferramentas.

A primeira coisa que você pode fazer é usar criptografia no tráfego P2P em seus programas de Torrent. Desta forma dificultará consideravelmente as provedoras saberem que você está usando esses protocolos. Dependendo do programa existem formas diferentes para habilitar a função.

BitTorrent e uTorrent: Menu Preferences - BitTorrent. Escolha Protocol encryption e marque a opção Enabled.

Outra solução é utilizar uma ferramenta gratuita de VPN como SecureIX ou outra que forneça o mesmo tipo de serviço, a fim de criptografar não apenas o tráfego de P2P/torrent e sim toda a sua navegação.

Como um email supostamente do Google revelou uma imensa brecha de segurança

Era um estranho e-mail, vindo de um recrutador do Google, perguntando à Zachary Harris se ele estava interessado em atuar como engenheiro da confiabilidade.

"Você obviamente tem uma paixão por Linux e programação", dizia o e-mail do Google "Eu queria ver se você está aberto a explorar novas oportunidades junto com a Google?"Harris ficou intrigado, porém cético. O e-mail chegou em dezembro passado, e como um matemático, ele não parecia o candidato mais provável para o trabalho que lhe foi oferecido.

Então, ele se perguntou se o e-mail poderia ter sido falsificado - algo enviado para parecer vir da gigante das buscas. Mas quando Harris examinou as informações de cabeçalho do email, tudo parecia legítimo.

Então ele notou algo estranho. A Google estava usando uma chave de criptografia muito fraca para certificar aos destinatários que sua correspondência veio de um legítimo domínio corporativo do Google. Qualquer pessoa que quebrasse a chave poderia usá-la para se passar por um remetente qualquer de e-mail do Google, incluindo seus fundadores, Sergey Brin e Larry Page.

O problema estava com a chave DKIM (DomainKeys Identified Mail) que a Google havia utilizado para os emails google.com. DKIM envolve uma chave criptográfica que é usada para assinar a origem de domínios de e-mail - ou se passar por eles - para validar a um destinatário que o domínio nas informações de cabeçalho em um e-mail está correto e que a correspondência de fato veio do domínio declarado. Quando o e-mail chega a seu destino, o servidor de recebimento pode procurar a chave pública através de registros DNS do remetente e verificar a validade da assinatura.Por razões de segurança, as chamadas DKIM padrão para utilizar as chaves que são, pelo menos, 1024 bits de comprimento. Mas o Google estava usando uma chave de 512 bits - o que poderia ser facilmente quebrado com um pouco de ajuda de computação nas nuvens.Harris achava que não havia como a Google ter sido tão descuidada, então ele concluiu que devia ser um teste, um recrutamento falso para ver se os candidatos a emprego iria encontrar a vulnerabilidade. Talvez o recrutador criou a "vulnerabilidade", ou talvez tenha sido criado pela equipe de tecnologia do Google, nos bastidores, com os recrutadores como cúmplices involuntários.Harris não estava interessado em trabalhar na Google, mas ele decidiu quebrar a chave e enviar um e-mail para fundadores do Google, Brin e Page, como eles mesmos, só para mostrar-lhes que ele tinha decifrado a brincadeira."Eu amo fatorar números", diz Harris. "Então, eu pensei que isso seria divertido. Eu realmente queria resolver seu quebra-cabeça e provar que eu poderia fazer isso. "No e-mail, ele linkou seu site pessoal:

    Hey Larry,

    Aqui está uma idéia interessante que ainda está sendo desenvolvida:

    http://www.everythingwiki.net/index.php/What_Zach_wants_regarding_wiki_technology

    ou, se o link acima não funcionar, tente:

    http://everythingwiki.sytes.net/index.php/What_Zach_wants_regarding_wiki_technology.

    Acho que devemos analisar se o Google poderia se envolver com esse cara de alguma forma. O que você acha?

    -SergeyHarris fez com que o caminho de resposta para os e-mails fosse a sua conta de e-mail próprio, de modo que Brin e Page poderiam perguntar a ele como ele tinha resolvido seu enigma. Mas Harris nunca teve uma resposta dos fundadores do Google. Em vez disso, dois dias depois, ele percebeu que a chave de criptografia do Google, de repente mudou a 2.048 bits. E ele teve um grande número de acessos repentinos de seu site a partir de endereços IP do Google.Ops, pensou Harris, era uma vulnerabilidade real que tinha encontrado."Eu assumi que o e-mail foi analisado por alguma pessoa influente do setor de tecnologia que olhou para ele e disse: 'Espere um segundo, como isso é obviamente falsificado e ainda assim recebemos esse e-mail?" E eles aparentemente perceberam a vulnerabilidade por conta própria ", diz ele .Harris começou a explorar outros locais e notou o mesmo problema com as chaves DKIM usadas ​​por PayPal, Yahoo, Amazon, eBay, Apple, Dell, LinkedIn, Twitter, SBCGlobal, US Bank, HP, Match.com e HSBC. Enviar um e-mail como jeff.bezos @ accounts.amazon.com? Sem problemas. Spoofing como marissa.meyer @ yahoo-inc.com? Muito simples.

Falsificação de e-mails é um dos métodos que os atacantes usam em ataques de phishing que enganam os usuários fazendo-os abrir e-mails que parecem ser mensagens legítimas do eBay, PayPal ou de um banco, a fim de enganar os usuários a divulgar suas credenciais de login de conta.

Além disso, alguns dos ataques mais utilizados nos últimos anos - contra o Google, a RSA e outros - usaram ataques phishing em funcionários específicos de uma empresa, enviando-lhes um e-mail malicioso que parecia vir de um confiável colega ou fonte, a fim de convencer o destinatário a entrar em algum site comprometido onde o malware seria baixado para sua máquina. Um falso e-mail que realmente é assinado com a chave de uma empresa DKIM pode ajudar os atacantes a ter sucesso em seus ataques de phishing visto que essa chave foi criada justamente para detectar ataques desse tipo.Encontrar a vulnerabilidade no próprio domínio Google foi irônico, já que o Google tem inúmeras ferramentas para bloquear e-mails enviados para usuários do Gmail a partir de outros domínios falsificados.Uma porta-voz do Google disse que a empresa Wired levou o problema muito a sério e que implementou a correção tão logo tomou conhecimento do problema. Ela disse que a empresa revogou as chaves para todos os seus domínios afectadas e re-emitiu novas que são maiores que 1.024 bits.Harris encontrou três classes de comprimentos de chaves utilizadas pelos domínios vulneráveis ​​- 384 bits, 512 bits, e 768 bits."Uma chave de 384 bits eu posso fatorar no meu laptop em 24 horas", diz ele. "As chaves de 512 bits eu posso fatorar em cerca de 72 horas com a Amazon Web Services por US$75,00, eu assim como uma série de outras pessoas. Depois, há as chaves de 768 bits. Esse não é possível ser fatorado por uma pessoa normal como eu, com apenas os meus próprios recursos. Mas o governo do Irã, provavelmente, poderia, ou um grande grupo com recursos de computação suficientes poderia. "Além do Google, ele descobriu que eBay, Yahoo, Twitter e Amazon todos usavam chaves de 512 bits. PayPal, LinkedIn, US Bank e HSBC estavam usando chaves de 768 bits."Que bom que o PayPal e os bancos estavam na categoria de 768, mas ainda assim, para domínios que são tão fortemente atacados por phishing como PayPal, 768 não é suficientemente bom", diz Harris. "Eles realmente deveriam ter usado 1024."A maioria das empresas contactadas por Harris ao longo dos últimos meses têm arrumado suas chaves, embora alguns ainda estão fazendo isso muito lentamente, observa ele. Depois de entrar em contato com Centro de Coordenação CERT da Universidade Carnegie Mellon para relatar a vulnerabilidade em agosto, Harris decidiu ir a público para avisar outros domínios sobre a necessidade de verificar suas chaves DKIM.Michael Orlando, analista de vulnerabilidade do CERT, disse que seu grupo planejava lançar um anúncio sobre o assunto nesta semana para espalhar a notícia.A correção é fácil - as empresas simplesmente precisa gerar uma nova chave no comprimento mais forte e colocá-lo em seus registros de DNS. Mas eles também precisam se lembrar de revogar sua chave antiga, diz Harris."Enquanto a antiga ainda estiver no registro DNS, mesmo se você não a estiver usando, um atacante ainda poderá usá-la", diz ele.Harris acha que o problema é que muitas empresas definem suas chaves uma vez e depois esquecem, apesar dos avanços em inovações de criptografia que fazem suas chaves obsoletas."As pessoas que usam ferramentas de criptografia precisa perceber que as configurações locais precisam ser mantidas assim como atualizações de software precisam ser mantidas", diz ele. "Em 1998, foi um avanço acadêmico de enorme esforço quebrar uma chave de 512 bits. Hoje, eu posso fazer isso por mim mesmo em 72 horas no AWS. O campo de criptografia mantém o desenvolvimento como todo o resto, e você não pode simplesmente instalar uma chave privada, ou selecionar um algoritmo de hash, e espera que ele seja bom para sempre. "Mas Harris diz que o problema não é apenas com os domínios do remetente, ele descobriu que os domínios que recebem também apresentam vulnerabilidades em aceitar chaves DKIM que foram claramente marcados como testes. Em alguns casos, domínios de remetentes geraram chaves de teste quando eles montaram seus sistemas, mas nunca revogaram elas. Embora Harris tenha encontrado chaves que eram claramente sinalizadas como sendo chaves de teste, domínios beneficiários que viram essas bandeiras aceitaram os e-mails como sendo legítimos, ao invés de considerá-los sem sinal, como deveriam ter feito."Então isso é um problema em ambos os lados;. Os remetentes estão recebendo estas chaves de testes que estão saindo nos registros de DNS mesmo muito tempo após o período de testes ter sido concluído, e então os verificadores estão ignorando a tag de testes", diz.Harris não é um pesquisador de segurança, e ele não sabia nem mesmo o que era DKIM antes de começar a investigar a autenticidade do e-mail do Google que ele recebeu."O fato de que eu entrei nisto sem saber nem mesmo o que era um cabeçalho DKIM mostar o que alguém com conhecimento técnico suficiente pode acabar fazendo", diz ele.

Oracle X Google

O juiz Alsop destruiu o argumento da Oracle dizendo que regras API's não são protegidas por direitos autorais (rules APIs are not copyrightable). Com isso, cai por terra, a alegação de propriedades do Java no Android.

Uma decisão contrária permitiria uma impossibilidade jurídica de escrever sua própria versão de código para realizar a totalidade ou parte dos mesmos comandos de um código patenteado.

fonte (Alsup destroys Oracle's case rules APIs are not copyrightable).