tenkuma/web
tenkuma/web
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Complete rework + eleventy

Browse source
This commit is contained in:
天クマ 2025-09-06 20:04:53 -03:00
commit 5f2e7393f7
86 changed files with 2785 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

50
posts/android-developer-verification.html Normal file
View file

@ -0,0 +1,50 @@
---
postTitle: "On the Recent Changes to App Distribution Requirements in the Android System by Google."
langKey: en
layout: post.njk
date: 2025-08-30
background: android-jellybean.jpg
backgroundOpacity: .35
---
<h2>Recap</h2>
<p>Android is that open-source operating system that works well for users and is loved by developers. Always known for breaking barriers and being open, expandable, versatile, and even friendly to power users-something not every system dares to be (iOS, Windows Phone). For a long time, Android was seen this way compared to its competitors: a breath of fresh air against the abusive practices of companies like Apple. But it seems the Android we've nurtured for two decades no longer fits in the pockets of Google executives; it is too free, creating ethical and technical barriers to the profitable exploitation path adopted by its developer.</p>
<h2>What happened with Android?</h2>
<p>At the end of this month (August 2025), Google announced that starting September 2026, all apps installed on certified devices (those with Google Android and locked bootloader) will need to undergo a developer verification process. This process involves collecting personal data from the individual distributing the app, so they can be identified and held accountable for potential malicious activities related to their software. The same applies to companies, which must also pay a $25 USD fee. This process is mandatory even if the app is distributed outside Google's official stores, raising obvious concerns about user privacy and freedom.</p>
<h2>Implications, Justifications, and Motivations of the New Policy</h2>
<p>It is important to examine Google's justification and try to understand its true motivation behind this distribution policy. Let's start by analyzing Google's statement:</p>
<blockquote cite="https://developer.android.com/developer-verification">"By making Android safer, we're protecting the open environment that allows developers and users to confidently create and connect. Android's new developer verification is an extra layer of security that deters bad actors and makes it harder for them to spread harm."</blockquote>
<p>They argue that the new rules are intended to improve user security, preventing malicious software from being installed on certified Android devices. Again, we see "security" used to justify controversial practices that limit the end user's control over their device. This was also the justification given for the proven abusive sideloading restrictions that led Google to lose a lawsuit against Epic Games-a more sophisticated version of the same issue is happening here.</p>
<p>It is easy to sympathize with the company when the words are well-phrased, but as a user who loves alternative software outside the big tech ecosystem, I have seen enough examples of authority abuse to conclude that Google's recent actions are simply an attempt to regain part, if not all, of the control it had over Android devices before the previously mentioned case.</p>
<p>One example is the kio-gdrive software, widely used to integrate Google Drive with the KDE file manager on Linux systems. The software was blocked from asking users if they authorized access to their Google Drive account. Instead of the permission popup, Google displayed a warning implying that the legitimate software could be malicious. Developers reported:</p>
<blockquote cite="https://bugs.kde.org/show_bug.cgi?id=480779#c54">"Google blocked us from using this back in June because we weren't able
justify our API usage to their satisfaction. As such, the permission is now blocked [...] mamaking 25% of the KAccounts KCM non-functional. Remove the gdrive permissions [...] for now so at least other Google things can work (at least in theory)."</blockquote>
<blockquote cite="https://bugs.kde.org/show_bug.cgi?id=480779#c54">"It's beyond stupid (IMHO) if individual users can't indicate that they're fine with a particular piece of software accessing their supposedly sensitive data!"</blockquote>
<p>Although I couldn't find the exact internal conversations between developers-and I'm giving Google the benefit of the doubt-it is at least suspicious that Google did not agree that software performing its primary functions within Google Drive should have a valid reason to access it. This was not an isolated case; Google operates behind the scenes to control what happens on Android. For example, apps compiled for older system versions would show alarming security warnings because recent changes introduced more permission barriers, even though old apps didn't support them. A reasonable warning would emphasize that permissions must be granted to support optional features, but the actual messages were vague, conveniently scaring users attempting sideloading and helping maintain the Play Store monopoly.</p>
<p>Speaking of alarming warnings, let's discuss Play Protect, software embedded in the Google Play Store that scans installed sideloaded apps and reports the results back to Google. At first glance, this is a good idea, assuming the user opts in. The problem arises when the difference between malware detection messages and warnings triggered by outdated software is unclear, causing two serious effects: it renders Google's protection service almost useless while maintaining the Play Store monopoly.</p>
<p>Imagine sideloading for the first time: you try to install an old version of a favored software. You receive exaggerated warnings about the supposed dangers, abandon the installation, and install the latest version from the Play Store. Google thus indirectly forces more users to use its store, ensuring the lucrative 30% transaction fee.</p>
<p>Now consider a second scenario: you're an advanced Android user who understands sideloading and loves installing open-source apps outside the Play Store. You click a suspicious link and download a malicious APK. Play Protect warns you during installation, but the warnings are so frequent and exaggerated-even when no malware is detected-that you ignore them out of habit. The result: malware on your device, and Play Protect was ineffective.</p>
<p>Sometimes, downloading software outside the Play Store is the only option, because developers may not want to publish apps there-either for privacy reasons (developers must disclose personal data when publishing) or because of publishing fees, which may discourage donation-supported developers. Users must have the freedom to choose what runs on their devices.</p>
<p>According to current information, developers don't have to make their data public if they avoid distributing apps via the Play Store. This is the least Google could do to make the new distribution policies fairer. Google also claims the verification isn't meant to inspect app content or purpose; it is supposedly only to block malware distribution. Whether this holds up remains to be seen, given it could also serve as a convenient tool for abuse of power.</p>
<h2>Next Steps</h2>
<p>We must watch how these policies are applied and how they affect the Android ecosystem. An inevitable consequence is that countless abandoned apps, perfectly functional without the new requirements, will disappear overnight. Not all old software connects to the internet, and not all represents a constant threat. Google is taking away the option for experienced users to take responsibility and say: "I know what I'm doing!", treating us like children, as if they know what's best for everyone.</p>
<p>The commercial Android on phones is based on the <abbr title="Android Open Source Project">AOSP</abbr>, meaning Android's core remains open, and Google hasn't taken that from users yet. I plan to write another post explaining how to regain control of your device through system modifications, from the simplest, safest, most stable methods to advanced approaches, if you feel confident.</p>

61
posts/telnet-en.html Normal file
View file

@ -0,0 +1,61 @@
---
postTitle: "Telnet"
layout: post.njk
date: 2025-08-27
background: redes.jpg
authors: Adrian Victor & Arthur Borges
langKey: en
---
<script src="/static/scripts/telnetSimulator.js" defer></script>
<h2>What the protocol is, its function and history</h2>
<p>Telnet (from <b>TEL</b>ecommunication <b>NET</b>work) is a TCP/IP stack network protocol that allows remote text-mode communication between computers. Its main function is to provide an interactive session where a user can access and control another device as if they were on a local terminal.</p>
<p>Created in 1969, Telnet was one of the first protocols developed for ARPANET (the network that gave rise to the Internet) and became fundamental for system and device administration in the 1970s, 1980s, and 1990s. Over time, it fell out of use due to lack of security, being replaced by more modern alternatives such as SSH (Secure Shell).</p>
<h2>Implementation</h2>
<p><b>Default port:</b> 23/TCP.<br>
Works at the application layer of the OSI model.<br>
<b>Format:</b> Based on ASCII character exchange, without encryption.<br>
<b>RFC:</b> Defined by RFC 854 (1983).<br>
<b>Architecture:</b> Follows the client-server model</p>
<h2>How it works</h2>
<p>In practice, Telnet works relatively simply. The process starts when the client establishes a TCP connection to the server via port 23. Then a remote terminal session is initiated and the user must provide credentials such as username and password. After authentication, commands typed on the client are transmitted in plain text to the server, which processes them and returns the corresponding output. The session remains active as long as the user wants, normally ending with commands like <i>exit</i> or <i>logout</i></p>
<h2>Use cases</h2>
<p>For many years, Telnet was widely used for remote access to Unix, Linux, and Windows servers, especially older versions of these systems. It also became common in network device administration, such as routers and switches, until SSH became the standard. Additionally, mainframes and some legacy devices still use Telnet today. Another practical application is in educational environments and network diagnostics, where it is used to test open ports and check service connectivity, such as running “telnet server.com 80” to see if a web server port is operational.</p>
<h2>Encryption: the inherent problem</h2>
<p>Telnet has no native encryption, which makes it extremely vulnerable. To solve this problem, more secure alternatives were developed. The main one is SSH (Secure Shell), created in the 1990s as a direct Telnet replacement. SSH offers the same functionality while ensuring data protection through strong authentication and full traffic encryption. Another, less common approach is using SSL/TLS to tunnel Telnet sessions, but in practice this is rarely used.</p>
<h2>Advantages and disadvantages</h2>
<p>Telnet’s advantages include simplicity, low resource usage, and compatibility with various older systems, which facilitated its adoption over the years. However, these benefits are outweighed by its disadvantages. The main one is the lack of encryption, exposing all transmitted data—including passwords—in plain text. This makes it vulnerable to attacks such as sniffing, which captures network packets, and hijacking, which takes over active sessions. For this reason, Telnet is considered obsolete and unsafe for use on open networks like the Internet.</p>
<h2>Relation to other protocols</h2>
<p>Telnet is part of the TCP/IP protocol family and uses TCP to ensure reliable communication. Like other protocols in this stack, such as HTTP, FTP, and SMTP, it relies on stable connections to perform its functions, but its distinguishing feature has always been terminal-mode interactivity. Due to security flaws, it was replaced by its natural successor, SSH, which retained Telnet’s conceptual base but added robust protection layers.</p>
<h2>Functional example</h2>
<p>Below is a Telnet connection simulator written in JavaScript.</p>
<div id="telnetSimulationLoadingHolder">
<p id="telnetSimulationLoadingText">Loading...</p>
<div class="ellipsis-loader" aria-role="alert" aria-label="Loading. Please wait">
<div class="ellipsis-loader__dot"></div>
<div class="ellipsis-loader__dot"></div>
<div class="ellipsis-loader__dot"></div>
<div class="ellipsis-loader__dot"></div>
</div>
</div>
<div id="telnetSimulation">
<div id="telnetSimulationServer">
<h3>Server</h3>
<textarea name="" id="telnetSimulationServerScreen" readonly>Welcome to Zubuntu 30.1!
Running startup script: start_telnet_server.sh
Telnet Server started on localhost:23
Ready to receive commands.
----
</textarea>
<button id="telnetSimulationServerClean">Clear</button>
</div>
<div id="telnetSimulationClient">
<h3>Client</h3>
<textarea name="" id="telnetSimulationClientScreen" readonly>Send help to see the list of commands supported by the server!
----
</textarea>
<div id="telnetSimulationInput">
<input type="text" id="telnetSimulationInputBox">
<button id="telnetSimulationClientSend">Send</button>
</div>
</div>
</div>

102
posts/telnet-pt.html Normal file
View file

@ -0,0 +1,102 @@
---
postTitle: "Telnet"
layout: post.njk
date: 2025-08-27
background: redes.jpg
authors: Adrian Victor & Arthur Borges
langKey: pt
---
<script src="/static/scripts/telnetSimulator.js" defer></script>
<h2>O que é o protocolo, sua função e histórico</h2>
<p>O Telnet (do inglês <b>TEL</b>ecommunication <b>NET</b>work) é um protocolo de rede da pilha
TCP/IP que permite a comunicação remota entre computadores em modo texto. Sua
função principal é proporcionar uma sessão interativa, em que um usuário pode
acessar e controlar outro dispositivo como se estivesse em um terminal local.</p>
<p>Criado em 1969, o Telnet foi um dos primeiros protocolos desenvolvidos para a
ARPANET (a rede que deu origem à Internet) e tornou-se fundamental para a
administração de sistemas e dispositivos nas décadas de 1970, 1980 e 1990. Com o
tempo, caiu em desuso devido à falta de segurança, sendo substituído por
alternativas mais modernas, como o SSH (Secure Shell).</p>
<h2>Implementação</h2>
<p><b>Porta padrão:</b> 23/TCP.<br>
Funciona na camada de aplicação do modelo OSI.<br>
<b>Formato:</b> Baseado em troca de caracteres ASCII, sem criptografia.<br>
<b>RFC:</b> Definido pela RFC 854 (1983).<br>
<b>Arquitetura:</b> Segue o modelo cliente-servidor</p>
<h2>Funcionamento</h2>
<p>Na prática, o Telnet funciona de maneira relativamente simples. O processo começa
quando o cliente estabelece uma conexão TCP com o servidor por meio da porta 23.
Em seguida, uma sessão de terminal remoto é iniciada e o usuário deve fornecer
suas credenciais, como nome de usuário e senha. Após a autenticação, os
comandos digitados no cliente são transmitidos em texto puro ao servidor, que os
processa e retorna a saída correspondente. A sessão permanece ativa enquanto o
usuário desejar, sendo encerrada normalmente com comandos como <i>exit</i> ou <i>logout</i></p>
<h2>Cenários de uso</h2>
<p>Durante muitos anos, o Telnet foi amplamente utilizado para acesso remoto a
servidores Unix, Linux e Windows, especialmente em versões mais antigas desses
sistemas. Também se tornou bastante comum na administração de dispositivos de
rede, como roteadores e switches, até que o SSH passou a ser adotado como
padrão. Além disso, grandes computadores centrais, conhecidos como mainframes,
e alguns dispositivos legados ainda utilizam Telnet até hoje. Outra aplicação prática
do protocolo está em ambientes educacionais e no diagnóstico de redes, onde é
usado para testar portas abertas e verificar conectividade de serviços, como ao
executar “telnet servidor.com 80” para checar se a porta de um servidor web está em
funcionamento.</p>
<h2>Criptografia: o problema inerente</h2>
<p>O Telnet não possui criptografia nativa, o que o torna extremamente vulnerável. Para
solucionar esse problema, surgiram alternativas mais seguras. A principal delas é o
SSH (Secure Shell), desenvolvido nos anos 1990 como um substituto direto do
Telnet. O SSH oferece as mesmas funcionalidades, mas garante a proteção dos
dados por meio de autenticação forte e criptografia de todo o tráfego. Outra
possibilidade, embora menos comum, é o uso de SSL/TLS para tunelar sessões
Telnet, mas na prática essa abordagem raramente é utilizada.</p>
<h2>Vantagens e desvantagens</h2>
<p>Entre as vantagens do Telnet, destacam-se sua simplicidade, baixo consumo de
recursos e compatibilidade com diferentes sistemas antigos, o que facilitou sua
adoção ao longo dos anos. Contudo, essas qualidades são superadas por suas
desvantagens. A principal é a ausência de criptografia, que expõe todos os dados
transmitidos, incluindo senhas, em texto puro. Isso o torna vulnerável a ataques
como o sniffing, que captura pacotes de rede, e o hijacking, que sequestra sessões
ativas. Por esse motivo, o Telnet é considerado obsoleto e inseguro para uso em
redes abertas, como a própria Internet.</p>
<h2>Relação com outros protocolos</h2>
<p>O Telnet faz parte da família de protocolos da pilha TCP/IP e utiliza o TCP para
garantir a confiabilidade na comunicação. Assim como outros protocolos dessa pilha,
como HTTP, FTP e SMTP, ele se baseia em conexões estáveis para realizar suas
funções, mas seu diferencial sempre foi a interatividade em modo terminal. No
entanto, devido às falhas de segurança, acabou sendo substituído por seu sucessor
natural, o SSH, que manteve a mesma base conceitual do Telnet, mas adicionou
camadas robustas de proteção.</p>
<h2>Exemplo funcional</h2>
<p>Abaixo há um simulador de conexão Telnet feito em JavaScript.</p>
<div id="telnetSimulationLoadingHolder">
<p id="telnetSimulationLoadingText">Loading...</p>
<div class="ellipsis-loader" aria-role="alert" aria-label="Loading. Please wait">
<div class="ellipsis-loader__dot"></div>
<div class="ellipsis-loader__dot"></div>
<div class="ellipsis-loader__dot"></div>
<div class="ellipsis-loader__dot"></div>
</div>
</div>
<div id="telnetSimulation">
<div id="telnetSimulationServer">
<h3>Servidor</h3>
<textarea name="" id="telnetSimulationServerScreen" readonly>Bem vindo ao Zubuntu 30.1!
Rodando script de inicialização: start_telnet_server.sh
Servidor Telnet iniciado em localhost:23
Pronto para receber comandos.
----
</textarea>
<button id="telnetSimulationServerClean">Limpar</button>
</div>
<div id="telnetSimulationClient">
<h3>Cliente</h3>
<textarea name="" id="telnetSimulationClientScreen" readonly>Envie help para ver a lista de comandos suportados pelo servidor!
----
</textarea>
<div id="telnetSimulationInput">
<input type="text" id="telnetSimulationInputBox">
<button id="telnetSimulationClientSend">Enviar</button>
</div>
</div>
</div>

49
posts/verificacao-de-desenvolvedor-no-android.html Normal file
View file

@ -0,0 +1,49 @@
---
postTitle: "Sobre as recentes mudanças nos requisitos de distribuição de apps no sistema Android feitas pela Google."
layout: post.njk
date: 2025-08-30
background: android-jellybean.jpg
backgroundOpacity: .35
langKey: pt
---
<h2>Recapitulando</h2>
<p>Android é aquele sistema operacional open-source que funciona bem para os usuários, e que os desenvolvedores amam. Sempre conhecido por quebrar barreiras e por ser aberto, expansível, versátil e até amigável com os mais nerds, coisa que nem todo sistema tem a cara e coragem de ser (iOS, Windows Phone). É assim que, por muito tempo, o Android foi visto em relação aos seus concorrentes: Um suspiro de ar puro em relação às práticas abusivas de empresas como a Apple. Mas parece que o Android que cultivamos por duas décadas não cabe mais no bolso dos executivos da Google, é livre demais, e isso criou barreiras éticas e técnicas no lucrativo caminho de exploração adotado pela sua desenvolvedora.</p>
<h2>O que aconteceu com o Android?</h2>
<p>A Google anunciou no final deste mês (Agosto de 2025) que a partir de Setembro de 2026 todos os apps instalados em dispositivos certificados (aqueles com o Android da Google e de bootloader bloqueado) precisarão passar pelo processo de verificação de desenvolvedor, processo cujo consiste da coleta de dados pessoais do indivíduo que vai distribuir a aplicação para que o mesmo possa ser identificado e atribuído a possíveis atividades maliciosas relacionadas ao seu software, o mesmo vale para empresas, que além disso precisam pagar uma taxa de 25 USD. O processo é forçado e necessário mesmo com a distribuição do app sendo feita fora das lojas oficiais da Google, o que trouxe óbvias preocupações sobre privacidade e liberdade dos usuários do sistema.</p>
<h2>As implicações, justificativas e motivações da nova política</h2>
<p>É importante analisar a justificativa e tentar entender a real motivação que a Google teve ao criar tal política de distribuição. Portanto começamos analisando a fala da Google:</p>
<blockquote cite="https://developer.android.com/developer-verification">"Para tornar o Android mais seguro, estamos protegendo o ambiente aberto que permite que desenvolvedores e usuários criem e se conectem com confiança. A nova verificação de desenvolvedor do Android é uma camada que detém atores maliciosos e faz com que seja mais difícil para que eles espalhem o mau."</blockquote>
<p>Ela argumenta que as novas regras do sistema foram feitas com a intenção de aprimorar a segurança do usuário, evitando que software malicioso seja instalado em dispositivos Android certificados. Outra vez vemos segurança sendo usada como forma de justificar práticas controversas que limitam o poder do usuário final no seu próprio dispositivo. Essa também era a justificativa dada para a prática comprovadamente abusiva de bloqueio de sideloading de apps que levou a Google a perder seu caso no tribunal contra a empresa Epic Games, aqui vemos uma versão mais sofisticada da mesma.</p>
<p>É fácil simpatizar com a empresa quando as palavras são bem colocadas, mas como usuário ávido de softwares alternativos aos das big-techs, eu já vi exemplos de abuso de autoridade suficientes para concluir que as recentes ações da Google não passam de uma forma de recuperar parte, se não todo o controle que ela tinha sobre os dispositivos Android antes do caso mencionado anteriormente.</p>
<p>Um exemplo desses abusos é o caso do software kio-gdrive, que era amplamente utilizado para integrar o Google Drive ao explorador de arquivos do KDE, um ambiente para sistemas Linux. O software foi bloqueado de perguntar para os usuários se eles autorizavam o acesso a sua conta do Google Drive, no lugar do popup de permissão, a Google colocou um aviso informando os usuários que o software legítimo poderia ser malicioso, seguem os relatos dos desenvolvedores:</p>
<blockquote cite="https://bugs.kde.org/show_bug.cgi?id=480779#c54">"Google bloqueou o nosso acesso a essa função em junho porque não conseguimos explicar o nosso uso da API de forma que eles julgam satisfatória. Por causa disso o sistema de permissões agora está bloqueado [...] tornando 25% das KAccounts KCM não funcionais. Remova as permissões [...] para que pelo menos o restante das integrações funcione (pelo menos em teoria)."</blockquote>
<blockquote cite="https://bugs.kde.org/show_bug.cgi?id=480779#c54">"É mais que estúpido (na minha humilde opinião) usuários individuais não poderem indicar que eles concordam com um software específico acessando seus dados supostamente sensíveis!"</blockquote>
<p>Por mais que durante minhas pesquisas eu não tenha achado exatamente quais conversas foram trocadas pelo time de desenvolvedores - e com isso estou dando um grande benefício da dúvida para a Google -, é no mínimo suspeito que a Google não tenha concordado que um software que exerce suas funções primárias dentro do ambiente do Google Drive tem um motivo válido para usufruir do mesmo. Esse não foi um caso único, a Google age nas entrelinhas para controlar o que acontece ou não no Android, como quando apps compilados para versões mais antigas do sistema mostravam um aviso assustador sobre segurança pois mudanças recentes haviam colocado mais barreiras no sistema de permissões, porém os apps antigos não tinham suporte a elas. Um aviso sobre as permissões que seriam dadas ao aplicativo instalado, enfatizando que elas teriam que ser dadas ao aplicativo por ele não suportar as permissões opcionais é razoável, entretanto a mensagem exibida foi bem mais vaga do que deveria ser, o que convenientemente serviu para assustar os usuários que experimentavam sideloading e ajudou a manter o monopólio da Google Play Store.</p>
<p>Falando em avisos assustadores, chegou a hora de falar do Play Protect, um software embutido na Google Play Store que escaneia os apps instalados no seu dispositivo via sideloading e retorna o resultado para a base de dados da Google, uma ideia boa a primeira vista, levando em conta que a empresa respeita a escolha do usuário com o modelo <i>opt-in</i>, questionando o mesmo se ele gostaria de enviar seus apps instalados para a análise. O grande problema aparece quando a diferença entre as mensagens de detecção de malware e as que são acionadas pelo simples fato do software estar desatualizado é tão turva que causa dois efeitos graves, que juntos tornam o serviço de proteção da Google praticamente inútil para o usuário, enquanto mantém o monopólio da Google.</p>
<p>Suponhamos que você está experimentando sideloading pela primeira vez: você tenta instalar uma versão antiga de um software que você gosta. Você recebe a mensagem exacerbada sobre os supostos perigos de instalar o software desatualizado, desiste da instalação e instala a versão atual pela Google Play Store. Assim a Google força, mesmo que indiretamente, mais um usuário a usar sua loja, garantindo os lucrativos 30% de taxa nas transações dos apps.</p>
<p>Agora apresento um segundo cenário hipotético: você é um usuário mais avançado do sistema Android que tem total noção do que se trata o sideloading e adora instalar seus aplicativos de código aberto por fora da Play Store. Porém você clica em um link duvidoso e baixa um arquivo APK malicioso. Na hora de instalar você recebe o aviso do Play Protect, mas ele é tão frequente e exagerado - até mesmo quando nenhum malware foi detectado - que você acaba dispensando-o por já estar acostumado a ter que fazer isso (isso quando o usuário já não desativou ele nas configurações da Play Store). Agora o usuário tem um malware em seu dispositivo, o Play Protect foi inútil.</p>
<p>Em certas situações baixar um software por fora da loja da Google é a única opção, pois existem casos onde o desenvolvedor não quer publicar seu app na Play Store, tanto por questões de privacidade - já que os desenvolvedores são forçados a revelar certos dados pessoais para o público quando publicam seus apps -, quanto pela taxa imposta na publicação e vendas internas do aplicativo, que pode afastar desenvolvedores sustentados puramente por doações dos usuários. Pouco importa o motivo, os usuários devem ser livres para escolher o que roda em seus dispositivos.</p>
<p>De acordo com as informações disponibilizadas até agora, os desenvolvedores não precisarão tornar seus dados públicos caso optem por não distribuir sua aplicação na Play Store, e isso é o mínimo que a Google poderia fazer para tornar as novas políticas de distribuição mais justas para os desenvolvedores. A empresa também afirma que essa verificação não tem o objetivo de verificar o que há dentro da aplicação ou sua finalidade, portanto estaria sendo imposta puramente para barrar a distribuição contínua de malwares, resta ver se a afirmação se sustenta, tendo em vista que isso também pode ser uma ferramenta de abuso de poder conveniente para a Google, como outras serviram nos exemplos citados acima.</p>
<h2>Próximos passos</h2>
<p>Devemos ficar atentos a como essas novas políticas vão ser aplicadas, e como as mesmas afetarão o ecossistema do Android. Uma consequência inevitável das mudanças é que um número inestimável de aplicações abandonadas pelos desenvolvedores, que - se não fosse pelos novos requisitos - seriam perfeitamente funcionais serão perdidas de um dia para o outro. Nem todo software antigo se conecta à internet, nem todo software antigo representa um perigo constante ao usuário. A Google está tirando do usuário experiente a opção de assumir a responsabilidade e dizer: "Eu sei o que estou fazendo!", nos segurando como crianças, como se soubessem o que é melhor para todos.</p>
<p>O Android comercializado nos celulares é baseado no <abbr title="Android Open Source Project">AOSP</abbr>, o que significa que a força vital do Android é aberta, e isso a Google ainda não tirou dos usuários. Portanto pretendo fazer um outro post explicando como você pode recuperar o controle do seu dispositivo por meio de modificações no sistema, da forma mais simples, segura e estável possível, até as formas mais avançadas, caso você se sinta confiante.</p>