Exoneração de responsabilidade: os resumos das políticas e as Principais Considerações são apenas visões gerais. Sempre consulte a política na íntegra para verificar a conformidade. A política completa prevalecerá em caso de conflito.
Política: resumo
Para manter um ecossistema Android seguro, o Google Play proíbe qualquer código malicioso, incluindo SDKs de terceiros integrados aos apps, que possa colocar os usuários, os dados ou os dispositivos em risco. Por favor, revise a política completa para garantir a compliance.
Malware é qualquer código capaz de colocar um usuário, os dados dele ou um dispositivo em risco. O malware inclui aplicativos potencialmente nocivos (PHAs), binários ou modificações do framework que consistem em apps de trojans, phishing e spyware, entre outros. Além dessas, estamos continuamente atualizando e adicionando novas categorias.
Com diferentes tipos e recursos, o malware geralmente tem um dos seguintes objetivos:
- Comprometer a integridade do dispositivo do usuário
- Controlar um dispositivo do usuário
- Ativar operações controladas remotamente para que um invasor acesse, use ou explore um dispositivo infectado
- Transmitir dados pessoais ou credenciais do dispositivo sem a divulgação e o consentimento adequados
- Enviar spam ou comandos do dispositivo infectado a outros dispositivos ou redes
- Enganar o usuário
Um app, binário ou uma modificação do framework podem ser nocivos e gerar um comportamento malicioso, mesmo que essa não tenha sido a intenção. Eles podem agir de diferentes maneiras, de acordo com uma série de variáveis. Portanto, o que é nocivo para um dispositivo Android pode não provocar risco algum em outro dispositivo Android. Por exemplo, um dispositivo que executa a última versão do Android não será afetado por apps nocivos que usam APIs obsoletas para realizar comportamentos maliciosos, mas um dispositivo que use uma versão muito antiga do Android pode estar em risco. Apps, binários ou modificações do framework serão sinalizados como malware ou PHA se claramente colocarem em risco vários ou todos os dispositivos e usuários do Android.
As categorias de malware abaixo refletem nossa crença fundamental de que os usuários devem compreender como os dispositivos deles estão sendo usados e promover um ecossistema seguro que permita uma inovação robusta e uma experiência confiável do usuário.
Acesse o Google Play Protect para saber mais.
Principais considerações
| O que fazer | O que não fazer |
| Examinar todo o código do app, incluindo SDKs de terceiros, para garantir que ele não apresenta comportamentos semelhantes a malware, como spyware, cavalos de troia ou phishing, mesmo que não intencionalmente. | Integrar código que abuse de privilégios elevados para comprometer a integridade do sistema, faça root em dispositivos sem consentimento e conhecimento explícitos do usuário ou use técnicas de maskware para evitar a detecção de comportamento mal-intencionado. |
| Considerar o uso de ferramentas para identificar vulnerabilidades de segurança ou backdoors que possibilitem operações remotas indesejadas. | Usar SDKs de terceiros que coletem e transmitam dados pessoais para monitoramento sem consentimento e declaração adequados do usuário (por exemplo, stalkerware). Incorporar código que cause práticas de faturamento enganosas envolvendo SMS, ligações ou fraude de cobrança. |
| Verificar se os SDKs de terceiros não coletam e/ou extraem dados do usuário sem uma funcionalidade em conformidade com a política e/ou aviso ou consentimento adequados (spyware). | Usar SDKs de terceiros que realizem ataques de negação de serviço ou atuem como um componente de download hostil. |
| Garantir que o app não inclui SDKs de terceiros que violem o modelo de permissões do Android ao receber privilégios elevados com acesso aos dados do dispositivo para uma finalidade não divulgada. |
Acessos "backdoor"
Política: resumo
Para proteger seus usuários, remova qualquer código que funcione como um backdoor, ou seja, que facilite operações remotas indesejadas ou prejudiciais. Por favor, revise a política completa para garantir a conformidade.
É um código que permite a execução de operações indesejadas, potencialmente nocivas e controladas remotamente em um dispositivo.
Essas operações podem incluir comportamentos que fazem com que o app, binário, ou a modificação da framework se classifique em uma categoria de malware quando a execução é automática. Em geral, o termo "backdoor" descreve como uma operação potencialmente nociva pode ocorrer em um dispositivo. Portanto, ele não se enquadra exatamente em categorias como fraude de faturamento e spyware comercial. Como resultado disso, em algumas circunstâncias, determinados acessos "backdoor" podem ser considerados uma vulnerabilidade pelo Google Play Protect.
Principais considerações
| O que fazer | O que não fazer |
| Teste minuciosamente o código do app e todas as bibliotecas de terceiros para detectar recursos ocultos de controle remoto | Não inclua recursos ou funcionalidades ocultas que possam ser exploradas para prejudicar os usuários |
| Proteja todos os endpoints de execução remota contra acesso não autorizado | Não ofusque o código para ocultar recursos de acesso remoto |
| Corrija imediatamente as vulnerabilidades de segurança conhecidas no seu app | Não ignore avisos sobre possíveis vulnerabilidades nas suas dependências |
Fraude por faturamento
Política: resumo
Para evitar fraudes de faturamento, remova qualquer código que cobre os usuários de forma enganosa sem o consentimento explícito deles. Isso inclui fraudes de SMS, de chamada e de cobrança, que enganam os usuários para que façam pagamentos ou assinaturas indesejados. Por favor, revise a política completa para garantir a conformidade.
É um código que cobra o usuário automaticamente de forma enganosa.
As fraudes de faturamento de dispositivos móveis estão divididas entre SMS, chamada e cobrança.
Fraude de SMS
É um código que emite cobranças pelo envio de SMS premium sem o consentimento do usuário ou que tenta encobrir a atividade de SMS ao ocultar acordos de divulgação ou mensagens SMS da operadora de telefonia móvel com notificações sobre cobranças ou confirmações de assinaturas.
Alguns códigos, apesar de tecnicamente exporem o envio de SMS, também apresentam um comportamento adicional que inclui fraude de SMS. Os exemplos incluem ocultar partes de um acordo de divulgação do usuário para que não seja legível e bloquear intencionalmente as mensagens SMS da operadora de telefonia móvel informando o usuário sobre cobranças ou confirmando uma assinatura.
Fraude de chamada
É um código que emite cobranças ao realizar chamadas para números premium sem o consentimento do usuário.
Fraude de cobrança
É um código que engana o usuário para que ele assine ou compre conteúdos por meio da conta do celular.
A fraude de cobrança inclui qualquer tipo de faturamento, exceto SMS e chamadas premium. Por exemplo, o faturamento direto via operadora, o protocolo de aplicação sem fio (WAP, na sigla em inglês) e a transferência de créditos para dispositivos móveis. A fraude por WAP é um dos tipos mais comuns de fraude de cobrança. Ela pode levar os usuários a clicar em um botão ou em um WebView transparente e carregado de forma discreta. Ao realizar a ação, uma assinatura recorrente é iniciada, e geralmente a mensagem por e-mail ou SMS é invadida para evitar que os usuários percebam a transação financeira.
Principais considerações
| O que fazer | O que não fazer |
| Receba o consentimento explícito e inequívoco dos usuários antes de iniciar qualquer transação financeira | Não oculte nem mascare informações relacionadas a cobranças ou assinaturas |
| Garanta que todas as declarações de faturamento sejam claras, transparentes e claramente visíveis para o usuário | Não use visualizações da web ocultas nem envie mensagens SMS premium ou faça ligações automaticamente sem consentimento |
| Envie todas as notificações de faturamento via operadora para o usuário | Não use métodos como o faturamento direto via operadora para enganar os usuários e fazer com que assinem serviços |
Stalkerware
Política: resumo
O Google Play proíbe que apps monitorem outro indivíduo por meio da coleta e transmissão de dados pessoais e sensíveis do usuário, a menos que o app seja projetado e comercializado exclusivamente para que os familiares responsáveis monitorem as crianças ou para que a administração de uma empresa monitore funcionários individuais, desde que atendam totalmente a requisitos rigorosos. Por favor, revise a política completa para garantir a conformidade.
Código que coleta dados pessoais ou confidenciais do usuário de um dispositivo e os transmite a terceiros (outra empresa ou indivíduo) para monitoramento.
Os apps precisam incluir uma declaração em destaque adequada e receber consentimento conforme exigido pela política de dados do usuário.
Diretrizes para aplicativos de monitoramento
Os únicos apps de vigilância aceitáveis são os projetados ou comercializados exclusivamente para monitorar outro indivíduo, por exemplo, o monitoramento dos filhos pela família ou de funcionários individuais pela administração de uma empresa, desde que atendam totalmente aos requisitos descritos abaixo. Eles não podem ser usados para monitorar outras pessoas (um cônjuge, por exemplo), mesmo com conhecimento ou permissão delas e ainda que os apps exibam uma notificação contínua. Esses apps precisam usar a sinalização de metadados IsMonitoringTool no arquivo de manifesto para se designarem adequadamente como apps de monitoramento.
Os apps de monitoramento precisam atender a estes requisitos:
- Eles não podem se apresentar aos usuários como soluções de vigilância secreta ou de espionagem.
- Eles não podem usar técnicas de cloaking ou ocultar o comportamento de rastreamento nem tentar enganar os usuários sobre essa funcionalidade.
- Eles precisam apresentar aos usuários uma notificação contínua sempre que estiverem em execução e ter um ícone que os identifique facilmente.
- Os apps precisam divulgar a funcionalidade de monitoramento ou rastreamento na descrição da Google Play Store.
- Os apps e as páginas "Detalhes do app" no Google Play não podem apresentar meios de ativar nem acessar funcionalidades que violem esses termos, como links a um APK não compatível hospedado fora da plataforma.
- Os apps precisam obedecer às leis aplicáveis. Você é exclusivamente responsável por determinar a legalidade do app na localidade de destino.
Principais considerações
| O que fazer | O que não fazer |
| Divulgue o app exclusivamente para uso de controle da família ou gerenciamento empresarial | Não promova o app como uma solução de espionagem ou vigilância |
Inclua a flag IsMonitoringTool no manifesto |
Não monitore outros adultos, incluindo cônjuges, mesmo com a permissão deles |
| Mostre uma notificação persistente e um ícone exclusivo durante a execução | Não oculte, use técnicas de cloaking nem engane os usuários sobre as práticas de monitoramento |
| Divulgue todos os recursos de monitoramento na descrição da loja | Não vincule o app a APKs hospedados fora do Google Play que não estejam em conformidade. |
| Inclua uma declaração em destaque adequada e receba consentimento | Não forneça meios para ativar recursos que violam estes termos |
Negação de serviço (DoS, na sigla em inglês)
Política: resumo
Para proteger seu app e outros sistemas, remova qualquer código que, sem o conhecimento do usuário, ataque outros sistemas ou gere carga excessiva na rede. Por favor, revise a política completa para garantir a conformidade.
É um código que, sem o conhecimento do usuário, executa um ataque de negação de serviço (DoS) ou faz parte de um ataque de DoS distribuído contra outros sistemas e recursos.
Por exemplo, isso pode acontecer ao enviar um volume alto de solicitações HTTP para gerar um carregamento excessivo em servidores remotos.
Principais considerações
| O que fazer | O que não fazer |
| Teste minuciosamente seu código e os SDKs de terceiros para detectar abuso de rede | Não oculte nem incorpore código que gere um alto volume de tráfego ou solicitações de rede |
| Garanta que todas as solicitações de rede do app são legítimas e necessárias para a funcionalidade dele | Não inclua recursos que possam ser ativados remotamente para atacar sistemas externos |
Componentes de downloads hostis
Política: resumo
O Google Play proíbe componentes de download hostis, ou seja, apps que baixam outros softwares indesejados para dispositivos móveis (MUwS, na sigla em inglês). Um app é sinalizado como um componente de download hostil se acreditamos que ele foi criado para espalhar MUwS, ou se pelo menos 5% dos downloads dele forem classificados como MUwS. Essa política não se aplica aos principais navegadores ou apps de compartilhamento de arquivos, desde que eles baixem software apenas com iniciativa e consentimento explícitos do usuário. Por favor, revise a política completa para garantir a conformidade.
É um código que não é potencialmente nocivo por si só, mas que faz o download de outros PHAs.
Ele pode ser um componente de downloads hostil se:
- houver razões para acreditar que ele foi criado para espalhar PHAs e que fez download de PHAs ou contém um código que poderia fazer o download de PHAs e instalá-los; ou
- pelo menos 5% dos downloads feitos por ele são de PHAs com um limite mínimo de 500 downloads de apps observados, ou seja, 25 downloads de PHAs observados.
Os principais navegadores e apps de compartilhamento de arquivos não serão considerados componentes de downloads hostis desde que:
- não façam downloads sem a interação do usuário; e
- todos os downloads de PHA sejam iniciados por usuários que deram consentimento.
Principais considerações
| O que fazer | O que não fazer |
| Garanta que o app não inclua nenhum código que espalhe MUwS | Não inclua no app nenhum código que espalhe MUwS |
| Monitore os downloads para ficar bem abaixo do limite de 5% de MUwS | Não exceda o limite de 5% de MUwS (25 MUwS por 500 downloads) |
| Garanta que todos os downloads de apps sejam iniciados por um usuário que deu consentimento, caso o objetivo do app seja baixar outros arquivos (como um navegador ou um app de compartilhamento de arquivos) | Não inclua recursos que gerem downloads de apps sem interação explícita do usuário, se o objetivo do app for baixar outros arquivos (como um navegador ou um app de compartilhamento de arquivos) |
Ameaça que não atinge o Android
É um código com ameaças que não atingem o Android.
Esses apps não causam danos ao usuário ou dispositivo Android, mas têm componentes potencialmente nocivos a outras plataformas.
Phishing
Política: resumo
Remova qualquer código que faça phishing solicitando de forma enganosa as credenciais ou informações de faturamento dos usuários e enviando esses dados a terceiros. Por favor, revise a política completa para garantir a conformidade.
É um código que finge ser de uma fonte confiável, solicita credenciais de autenticação do usuário ou informações de faturamento e envia esses dados a terceiros. Esta categoria também se aplica a código que intercepta a transmissão de credenciais do usuário.
Alguns alvos comuns de phishing são credenciais bancárias, números de cartão de crédito e credenciais de contas on-line para redes sociais e jogos.
Principais considerações
| O que fazer | O que não fazer |
| Use APIs oficiais e métodos seguros para tratar credenciais de usuário e informações de pagamento | Não se passe por uma fonte confiável para enganar os usuários e fazer com que eles forneçam dados pessoais ou financeiros |
| Garanta que todos os dados do usuário sejam transmitidos com segurança e não possam ser lidos por terceiros | Não intercepte nem colete credenciais de usuários ou informações sensíveis sem consentimento |
| Seja transparente com os usuários sobre quais dados você está solicitando e por quê | Não envie informações sensíveis do usuário a terceiros sem a declaração adequada e o consentimento explícito do usuário |
Abuso de privilégios elevados
Política: resumo
Para evitar violações por abuso de privilégios elevados, seu app não pode ter código que receba esses privilégios ou viole o sandbox de segurança do Android. Isso inclui código que roube credenciais de outros apps, ignore o modelo de permissões do Android ou desative os principais recursos de segurança. O app também precisa respeitar o controle do usuário sobre o dispositivo. Por favor, revise a política completa para garantir a conformidade.
É um código que compromete a integridade do sistema ao romper o sandbox do app, conseguindo privilégios elevados ou alterando ou desabilitando o acesso a funções centrais ligadas à segurança.
Por exemplo:
- Um app que viola o modelo de permissões do Android ou rouba credenciais (como tokens OAuth) de outros apps
- Apps que abusam de recursos para impedir que sejam desinstalados ou interrompidos
- Um app que desativa o SELinux
Apps com escalonamento de privilégios que dão acesso root a dispositivos sem a permissão do usuário são considerados apps de acesso root.
Principais considerações
| O que fazer | O que não fazer |
| Desenvolva um código que respeite o modelo de permissões do Android | Não crie apps que comprometam o sistema violando o sandbox |
| Projete seu app para funcionar com privilégios de usuário padrão | Não escreva código que impeça a desinstalação do app pelo usuário |
Ransomware
Política: resumo
Ransomware é um software mal-intencionado que sequestra o dispositivo ou os dados de um usuário, exigindo pagamento ou uma ação para restaurar o controle. Não bloqueie o acesso dos usuários, criptografe dados nem impeça a desinstalação. Essa política protege as pessoas contra extorsão. Por favor, revise a política completa para garantir a conformidade.
É um código que toma o controle parcial ou total de um dispositivo ou dados de um dispositivo e exige que o usuário faça um pagamento ou realize alguma ação para recuperá-lo.
Alguns tipos de ransomware criptografam dados no dispositivo e exigem o pagamento para descriptografá-los e/ou aproveitam os recursos de administração do dispositivo para que não possa ser removido por um usuário típico. Por exemplo:
- Bloquear um usuário do próprio dispositivo e exigir dinheiro para devolver o controle ao usuário
- Criptografar dados no dispositivo e exigir o pagamento para descriptografar os dados
- Aproveitar os recursos do Gerenciador de políticas do dispositivo e bloquear a remoção pelo usuário
O código distribuído com o dispositivo que tenha como objetivo principal o gerenciamento subsidiado do dispositivo pode ser excluído da categoria de ransomware, desde que cumpra com os requisitos de bloqueio e gerenciamento seguros e de divulgação e consentimento do usuário adequados.
Principais considerações
| O que fazer | O que não fazer |
| Garanta que o código do app esteja livre de funcionalidades mal-intencionadas de ransomware | Não criptografe os dados do usuário nem bloqueie o acesso ao dispositivo |
| Receba o consentimento explícito do usuário para todos os recursos de gerenciamento do dispositivo | Não use recursos de admin do dispositivo para bloquear a desinstalação |
| Ofereça aos usuários uma maneira clara e fácil de remover seu app | Não exija pagamentos nem ações para restaurar o controle do dispositivo |
Acesso root
Política: resumo
O Google Play permite o acesso root quando ele não é mal-intencionado, mas proíbe códigos com acesso root mal-intencionado. É preciso informar os usuários com antecedência sobre o acesso root e garantir que o app não realize outras ações nocivas. O objetivo é garantir que as pessoas consintam com essa mudança significativa no dispositivo e não sejam expostas a outros comportamentos mal-intencionados. Por favor, revise a política completa para garantir a conformidade.
É um código que faz root no dispositivo.
Há uma diferença entre códigos de root maliciosos e não maliciosos. Por exemplo, apps de root não maliciosos permitem que o usuário saiba antecipadamente que eles farão root no dispositivo e não executam outras ações potencialmente nocivas que se aplicam a outras categorias de PHA.
Os apps de root maliciosos não informam o usuário que farão root no dispositivo ou informam antecipadamente, mas também executam ações que se aplicam a outras categorias de PHA.
Principais considerações
| O que fazer | O que não fazer |
| Informe os usuários com antecedência de que o app vai fazer root no dispositivo | Não faça root em um dispositivo sem informar o usuário |
| Receba o consentimento explícito do usuário antes de fazer root | Não realize outras ações prejudiciais em um app de root |
| Confirme que o código do app não tem outros comportamentos mal-intencionados | Não use código de root para ocultar outros recursos mal-intencionados |
Spam
Spyware
Política: resumo
O Google Play proíbe a coleta ou o compartilhamento mal-intencionados de dados do usuário ou do dispositivo. Seja qual for o consentimento do usuário ou a divulgação, a coleta de dados e o compartilhamento precisam ser relacionados à funcionalidade em conformidade com a política. Por favor, revise a política completa para garantir a conformidade.
O spyware é um comportamento, código ou aplicativo malicioso que coleta, extrai ou compartilha dados do dispositivo ou do usuário que não têm relação com as funcionalidades que obedecem à política.
Um código ou comportamento malicioso que pode ser considerado espionagem ou extrai dados sem o devido consentimento ou aviso também é identificado como spyware.
Confira alguns exemplos de violações de spyware:
- Gravação de áudio e de chamadas telefônicas
- Roubo de dados do app
- Um app com código malicioso de terceiros (por exemplo, um SDK) que transmite dados para fora do dispositivo de forma inesperada ao usuário e/ou sem o devido consentimento ou aviso
Todos os apps precisam obedecer a todas as Políticas do programa para desenvolvedores do Google Play, incluindo as políticas de dados de dispositivos e usuários como Software indesejado para dispositivos móveis, Dados do usuário, Permissões e APIs que acessam informações sensíveis e Requisitos de SDK.
Principais considerações
| O que fazer | O que não fazer |
| Avise de forma clara e receba o consentimento explícito do usuário antes de qualquer coleta ou transmissão de dados | Não permita que SDKs de terceiros no seu app gravem áudio, chamadas ou obtenham dados do app sem receber consentimento explícito do usuário e sem ter uma funcionalidade que obedeça à política |
| Implemente uma geração de registros e uma auditoria robustas para todo o acesso e transmissão de dados de SDKs de terceiros para detectar e resolver a exfiltração de dados não autorizada | Não faça coleta de dados oculta nem colete mais dados do que o app precisa para a função declarada |
| Garanta que os SDKs integrados ao app coletem apenas os dados mínimos necessários e que a finalidade ou o comportamento deles não faça com que o app viole as políticas do Google Play | Não inclua SDKs de terceiros no app que transmitam dados de maneiras inesperadas ou sem o consentimento adequado |
| Não presuma que os SDKs de terceiros envolvidos nas práticas de coleta de dados do app estejam em conformidade sem fazer uma análise completa |
Cavalo de Troia
Política: resumo
Um cavalo de troia é um código que tem um componente mal-intencionado oculto. Essa política proíbe apps que realizem ações indesejáveis contra o usuário sem o conhecimento dele. Os desenvolvedores precisam garantir que o código do app seja transparente e livre de funcionalidades ocultas e nocivas. Por favor, revise a política completa para garantir a conformidade.
É um código que parece ser benigno, como um jogo que afirma ser só um jogo, mas que realiza ações indesejáveis contra o usuário.
Essa classificação geralmente é usada em combinação com outras categorias de PHA. Um cavalo de Troia tem um componente inofensivo e um nocivo oculto. Por exemplo, um jogo que envia mensagens SMS premium do dispositivo em segundo plano e sem o conhecimento do usuário.
Principais considerações
| O que fazer | O que não fazer |
| Garanta que o código do app seja transparente e atenda à finalidade declarada | Não oculte recursos mal-intencionados em um app aparentemente inofensivo |
| Confirme que todas as funcionalidades do app são divulgadas ao usuário | Não realize ações em segundo plano sem o conhecimento e consentimento explícitos do usuário |
| Confirme que os SDKs de terceiros incluídos são seguros e não têm comportamentos ocultos | Não deturpe a finalidade do app para enganar os usuários |
Observação sobre apps incomuns
Política: resumo
Se o Google Play Protect não tiver informações suficientes para verificar a segurança do seu novo app, ele poderá ser classificado como incomum. Esse status não significa que o app é nocivo, mas que ele precisa de uma análise mais detalhada. Por favor, revise a política completa para garantir a conformidade.
Principais considerações
| O que fazer | O que não fazer |
| Disponibilize informações completas e precisas na página de detalhes do app | Não oculte recursos nem use código ofuscado |
| Garanta que o código do app esteja limpo e bem-documentado para análise | Não use bibliotecas de terceiros não verificadas |
Observação sobre a categoria "backdoor"
Política: resumo
Backdoors são códigos que permitem comportamentos mal-intencionados. Se o carregamento dinâmico de código é usado para realizar ações prejudiciais, seu app viola nossas regras. Garanta que o código do app não ative recursos ocultos ou mal-intencionados. Se uma vulnerabilidade for encontrada, você deverá corrigi-la mesmo que não seja maliciosa. Por favor, revise a política completa para garantir a conformidade.
A classificação na categoria de malware "backdoor" depende de como o código funciona. Uma condição necessária para que qualquer código seja classificado como de "backdoor" é que, ao ser executado automaticamente, ele permita comportamentos classificados em uma das outras categorias de malware. Por exemplo, se um app permitir o carregamento dinâmico de código, e o código carregado dinamicamente extrai mensagens de texto, o app será classificado como malware "backdoor".
Porém, se um app permitir a execução arbitrária de código, mas não tivermos motivos para acreditar que esse código tenha sido adicionado com o objetivo de realizar um comportamento malicioso, o app será considerado vulnerável, e não malware "backdoor". Nesse caso, será solicitado que o desenvolvedor crie um patch para corrigir o problema.
Principais considerações
| O que fazer | O que não fazer |
| Teste rigorosamente qualquer código que permita a execução dinâmica | Não use o carregamento dinâmico de código para realizar ações ocultas e mal-intencionadas |
| Garanta que o código do app esteja livre de vulnerabilidades que possam ser exploradas | Não permita a execução arbitrária de código sem verificações de segurança cuidadosas |
| Corrija imediatamente as vulnerabilidades de segurança encontradas no app | Não use bibliotecas de terceiros não verificadas que possam permitir um backdoor |
Riskware
Política: resumo
Riskware é um app que usa técnicas de evasão para ocultar recursos mal-intencionados. Ele se disfarça de um app legítimo, usando métodos como ofuscação ou carregamento dinâmico de código para revelar conteúdo nocivo mais tarde. Você precisa garantir que seu app seja transparente e não use essas técnicas para enganar revisores ou usuários. Por favor, revise a política completa para garantir a conformidade.
São aplicativos que utilizam diversas técnicas de evasão para disponibilizar funcionalidades diferentes ou falsas para os usuários. Esses apps se disfarçam como jogos ou aplicativos legítimos de modo a parecerem inofensivos para as app stores e usuários, além de usarem técnicas como ofuscação, carregamento dinâmico de código ou cloaking para revelar o conteúdo potencialmente nocivo.
O riskware é semelhante a outras categorias de PHA, principalmente os cavalos de troia, e a principal diferença está nas técnicas usadas para ocultar as atividades mal-intencionadas.
Principais considerações
| O que fazer | O que não fazer |
| Garanta que o código do app seja claro e fácil de analisar | Não use ofuscação nem técnicas de cloaking para ocultar recursos |
| Seja transparente sobre todas as funções do app | Não use o carregamento dinâmico de código para veicular conteúdo mal-intencionado |
| Divulgue todos os recursos na descrição do app | Não faça com que o comportamento do app seja diferente para revisores e usuários comuns |
Help us improve this policy article by taking a 2-minute survey.