Aviso de Privacidade

1. Quem é o controlador

Responsável pelo projeto: Daniel Schroeder. Canal para privacidade e solicitações de titulares: develop.jgs@gmail.com.

O PescaRadar é atualmente um projeto pessoal e experimental, mantido para estudo. O nome do projeto, a marca, a logomarca e a identidade visual do aplicativo são provisórios e podem mudar. Essa natureza experimental não representa, por si só, dispensa de obrigações de proteção de dados: o tratamento efetivamente realizado e as hipóteses legais aplicáveis continuam determinantes.

A identificação e o canal de contato acima são os dados informados pelo responsável do projeto. A qualificação jurídica do controlador, a necessidade de encarregado e outras obrigações aplicáveis devem ser avaliadas conforme a natureza e a escala efetivas da operação; esta publicação não declara conformidade integral com a LGPD.

2. O que tratamos

O PescaRadar pode tratar coordenadas de geolocalização autorizadas pelo navegador, localização aproximada de rede, cidade/localidade derivada da posição, pontos de pesca, sessões, capturas, observações, medidas registradas pelo usuário, iscas e técnicas informadas e condições ambientais associadas à atividade. O uso básico não exige CPF ou documentos.

O serviço também usa um identificador técnico de visitante enviado pelo cliente e vinculado a um cookie HttpOnly no servidor. Esse identificador é pseudonimizado, mas pode constituir dado pessoal quando relacionado ao histórico do titular.

O aplicativo Android disponibiliza a Estação e a descoberta BLE nativas; o scanner mantém os resultados temporários em memória. O anúncio BLE/GATT do ESP32 expõe identificador público e estado Wi-Fi/portal para diagnóstico local. A característica de evento físico pode notificar o aplicativo Android após inscrição explícita; o evento é persistido localmente em Room e, quando há rede e sessão ativa, pode ser enviado ao backend pelo fluxo autenticado descrito na seção 4. O GATT não transmite senha, token ou credencial. A Estação nativa permite selecionar uma Data Base, armazenada localmente nas preferências privadas do aplicativo. O valor é sincronizado com o armazenamento local do WebView do domínio oficial PescaRadar, sem criar um histórico de datas no backend. O WebView mantém login, cookie HttpOnly de sessão, consentimento e demais dados conforme os fluxos do próprio site, em um perfil de navegação do aplicativo separado do navegador externo. Os dados enviados ou consultados dependem do módulo efetivamente utilizado, conforme descrito neste aviso.

O portal local do ESP32 pode receber temporariamente o e-mail e a senha da conta PescaRadar para solicitar o vínculo do equipamento. O firmware encaminha essas credenciais ao Worker por HTTPS; o backend valida a senha recalculando PBKDF2 com os parâmetros e o salt já cadastrados e exige que a conta esteja ativa. A senha é usada somente durante a requisição e não é persistida no ESP32 nem no registro do dispositivo. Após validação, o backend associa o identificador de hardware à conta e emite um token técnico exclusivo. O ESP32 grava em Preferences/NVS somente o UUID do registro e o token técnico; o backend mantém o hash do token. O token local não é a senha nem a sessão pessoal da conta. O armazenamento NVS não é declarado criptografado.

O firmware MultiSensor do ESP32 pode ler coordenadas precisas de GPS e sensores ambientais (BME280/NTC). Na versão 2.3.0, esses valores permanecem somente na memória volátil do equipamento e podem ser consultados por uma API HTTP na rede local do próprio dispositivo. Não são enviados automaticamente ao backend, a webhooks ou ao Discord e não formam histórico persistente. O acesso à rede local pode revelar coordenadas precisas enquanto houver fix GPS.

3. Finalidades e bases legais

Os dados são usados para exibir radar e condições ambientais, registrar e sincronizar a atividade de pesca, manter a continuidade offline e responder às funções solicitadas. No estado atual, operações pessoais que dependem de consentimento são habilitadas mediante manifestação expressa do titular. Outras operações técnicas somente devem ser realizadas pelo controlador após definição e registro da base legal aplicável.

O consentimento pode ser recusado e revogado. A recusa não bloqueia funções que não dependam desse tratamento.

4. Localização

A localização precisa depende da permissão do navegador ou da permissão de localização concedida ao aplicativo Android, além da solicitação da função correspondente. O WebView só concede geolocalização ao site quando a permissão de localização do Android já está concedida. Quando o GPS não está disponível, a aplicação pode usar localização aproximada fornecida pela rede/infraestrutura. A cidade pode ser obtida por serviço externo de geocodificação. A localização exata não deve ser publicada automaticamente.

Na área autenticada de conectividade, o titular pode consultar o estado operacional dos dispositivos IoT vinculados. O estado é derivado do horário da última telemetria autenticada e do limite de inatividade configurado: aguardando primeira leitura, ativo com telemetria recente ou offline. Esse indicador não comprova uma conexão BLE em tempo real. Quando configurados pelo titular, webhooks HTTP e Discord podem receber eventos de dispositivo offline e de retorno após nova telemetria. O app nativo recebe o evento físico por GATT e o persiste em Room no armazenamento privado do Android, com deduplicação por event_id e limite de 1.000 registros. Os registros não são removidos automaticamente e permanecem no app até limpeza dos dados ou desinstalação. Quando há conexão de rede e sessão ativa no WebView, WorkManager envia o evento ao endpoint autenticado do titular, que valida a propriedade do equipamento e deduplica por event_id. O cookie HttpOnly pr_session é lido em tempo de execução do CookieManager e enviado somente ao domínio oficial HTTPS; não é persistido na fila. A resposta do backend move o registro para BACKEND_ACCEPTED, mas o evento permanece no Room e ainda não há ACK ao ESP32.

5. Armazenamento

Pontos, sessões, capturas e observações podem ser armazenados no backend quando a sincronização é utilizada. O navegador também pode manter consentimento, cache ambiental e rascunhos locais para funcionamento offline. Registros físicos IoT e hashes de tokens técnicos permanecem enquanto o vínculo estiver ativo e são removidos/revogados pelo fluxo de desvinculação; o token técnico em texto claro permanece apenas no NVS do equipamento até reset ou nova emissão. As medições IoT recebidas a partir da ativação do histórico são armazenadas em buckets diários por equipamento e sensor, com expiração técnica de 90 dias. A consulta exige autenticação da conta proprietária, e a exclusão do equipamento remove também essas amostras. Leituras anteriores à ativação não são recuperadas.

6. Cookies, armazenamento local e publicidade

O PescaRadar não utiliza cookies de publicidade nem vende dados pessoais. O serviço usa um cookie técnico HttpOnly de visitante para vincular com segurança o navegador ao namespace pessoal; o estado do aviso também é mantido no armazenamento local do navegador. A Data Base escolhida é uma preferência funcional local: nos módulos web fica em localStorage e no app Android em SharedPreferences, com sincronização entre a Estação nativa e o WebView. O valor não constitui histórico de localização nem é persistido como registro de conta no backend. Essas tecnologias têm finalidade técnica e não devem ser utilizadas para publicidade ou perfilamento incompatível.

7. Consentimento

Quando o tratamento depender de consentimento, a escolha é registrada com uma versão do aviso e data/hora. A recusa não impede o uso de funções que não dependem desse tratamento. O consentimento pode ser revogado.

8. Compartilhamento, provedores externos e transferências internacionais

Para fornecer funcionalidades, o PescaRadar pode consultar Cloudflare, Vercel, GitHub, Open-Meteo, RainViewer, BigDataCloud, OpenStreetMap/Nominatim e outros provedores cartográficos, conforme o recurso utilizado. A qualificação jurídica de cada fornecedor deve ser documentada pelo controlador conforme contrato e atividade efetivamente realizada.

Alguns desses serviços podem processar dados fora do Brasil. Quando houver transferência internacional de dados pessoais, o controlador deve observar a LGPD e o regulamento da ANPD aplicável, adotando o mecanismo jurídico correspondente.

9. Cidade detectada

Quando você autoriza o GPS, as coordenadas atuais podem ser enviadas diretamente ao serviço de reverse geocoding usado para mostrar a cidade. A cidade exibida é uma referência administrativa e não substitui a coordenada GPS. A localização exata não deve ser incluída automaticamente em compartilhamentos públicos.

10. Meteorologia e limites

Valores meteorológicos podem ser provenientes de modelos, estações ou radar conforme indicado na interface. Um valor de 0 mm em um modelo não significa necessariamente ausência de chuva observada no ponto exato. O radar observado, quando disponível, deve ser identificado separadamente.

11. Direitos autorais e licenças

O código do PescaRadar e seus próprios conteúdos seguem a licença declarada no repositório. Dados, mapas, imagens, marcas e APIs de terceiros continuam sujeitos às licenças e termos dos respectivos fornecedores. O aplicativo exibirá atribuições necessárias e não assume propriedade sobre conteúdo externo.

12. Retenção e exclusão

O cookie técnico de visitante possui duração técnica configurada de até 1 ano. Os registros de pesca não possuem atualmente um prazo automático universal de eliminação; o controlador deve definir períodos ou critérios de retenção por finalidade e revisar sua necessidade.

O titular pode usar os recursos de revogação e apagamento disponíveis. A eliminação pode sofrer limitações quando a conservação for necessária para cumprimento de obrigação legal ou outra hipótese autorizada pela legislação.

13. Direitos do titular

Nos termos da LGPD, o titular pode requerer, conforme aplicável, confirmação da existência de tratamento, acesso, correção, anonimização/bloqueio/eliminação de dados inadequados, portabilidade, eliminação de dados tratados com consentimento, informação sobre compartilhamentos, informação sobre as consequências de não fornecer consentimento, revogação e revisão de decisões tomadas unicamente com base em tratamento automatizado, quando cabível.

Os botões desta página cobrem principalmente revogação e eliminação técnica do namespace. Direitos não disponíveis por botão devem ser solicitados pelo canal do controlador.

14. Segurança e incidentes

Aplicamos medidas técnicas proporcionais ao serviço, incluindo HTTPS, cookies HttpOnly/Secure, isolamento por namespace e proteção de endpoints pessoais. O controlador deve manter processo de resposta a incidentes e observar as regras da ANPD para comunicação de incidentes que possam acarretar risco ou dano relevante.

15. Atualizações

Alterações relevantes nas finalidades ou condições de tratamento devem ser comunicadas de forma transparente e, quando necessário, podem exigir nova manifestação do titular.

16. Conta, autenticação e segurança

Quando você cria uma conta, podemos tratar nome, e-mail, hash de senha, estado de aprovação, registros de aceite de termos/aviso e identificadores técnicos de sessão. A senha não é armazenada em texto puro. Cookies de sessão e visitante são usados para autenticação ou vínculo técnico conforme a funcionalidade. Cadastros podem permanecer pendentes de aprovação, conforme a configuração vigente.

17. Dispositivos Android e sensores IoT

Quando você autoriza localização no navegador ou no Android, as coordenadas podem ser usadas para centralizar mapa e condições ambientais. O aplicativo Android solicita permissões do sistema conforme a função utilizada. A permissão do sistema operacional não significa que a localização será publicada ou compartilhada automaticamente.

Quando um dispositivo IoT é cadastrado e envia medições, o backend trata identificador do dispositivo, vínculo à conta, identificador do sensor, métrica, valor, unidade, horário medido, horário de recebimento e metadados operacionais. O token exclusivo do dispositivo é uma credencial de autenticação e não é incluído em logs ou payloads de webhook. O firmware 2.3.4 foi observado em execução no painel local em 07/11/2026, com telemetria HTTPS opt-in ativada pelo titular e último envio aceito pelo servidor. O código versionado declara o candidato 2.4.0, que detalha as três grandezas do BME280, apresenta NTC em °C/°F apenas localmente e informa a cadência nominal de 900 segundos; a compilação completa e a validação física dessa versão ainda estão pendentes. A telemetria ambiental transmite somente temperatura do ar, umidade relativa, pressão atmosférica e temperatura da água, por token técnico individual, sem GPS, estado de relés/botões ou credenciais Wi-Fi/conta. Cada amostra aceita pelo Worker (HTTP 202) atualiza o snapshot operacional e também é persistida em bucket KV diário por equipamento e sensor, com expiração técnica de 90 dias. O endpoint autenticado de histórico consulta apenas amostras recebidas após a implementação; não há backfill, fila offline nem recuperação automática de amostras perdidas durante desconexões. O KV não oferece transações, e atualizações concorrentes do mesmo bucket podem disputar gravações. O prazo configurado não constitui backup nem garantia de recuperação. O ESP32 mantém localmente, na NVS, o horário da última medição aceita para exibir a confirmação após reinicialização.

Localização GPS do ESP32: o backend possui endpoints próprios para receber e consultar a última posição. O código candidato 2.4.0 inclui ativação explícita do compartilhamento no portal local do ESP32, preferência em NVS e envio HTTPS da última posição válida a cada 60 segundos, além de limpeza remota após desativação. A compilação Arduino completa e a validação física desse candidato ainda não foram confirmadas; não se declara que o equipamento em uso já esteja transmitindo coordenadas à nuvem. Quando ativa e recebida, a API mantém somente a posição mais recente (latitude, longitude, velocidade, altitude, satélites e horário de recebimento) no registro do dispositivo; não cria histórico de trajetos e não envia coordenadas a webhooks ou Discord. A posição permanece até ser substituída, até o compartilhamento ser desativado — quando a posição armazenada é removida — ou até a exclusão do equipamento. O registro não possui prazo de expiração próprio declarado; o controlador ainda deve confirmar a retenção e a base legal aplicável antes da ativação em campo. A exportação autenticada inclui a última posição e a preferência de compartilhamento. O dashboard autenticado `/iot` exibe essa posição em mapa e sincroniza a seleção do equipamento com os gráficos de telemetria ambiental; somente a última posição é exibida, sem histórico ou trilhas. O mapa utiliza tiles do OpenStreetMap: o serviço recebe o IP do navegador e os identificadores z/x/y dos tiles solicitados, que revelam a área cartográfica visualizada, mas não recebem a latitude/longitude bruta no URL. A biblioteca Leaflet é carregada de unpkg, que recebe requisições dos arquivos da biblioteca e o IP, sem receber diretamente as coordenadas do equipamento.

O firmware de provisionamento Wi-Fi do ESP32 inclui um portal HTTP local para configurar a rede sem recompilar o dispositivo. O SSID e a senha informados são enviados pelo navegador diretamente ao ESP32 conectado ao ponto de acesso temporário e, após a conexão ser validada, ficam armazenados localmente em Preferences/NVS no equipamento. Esse firmware não envia essas credenciais nem o MAC do dispositivo à API PescaRadar ou a terceiros. O ponto de acesso de bancada utiliza a senha padrão `pescaradar`, documentada no firmware. Após a configuração, o novo firmware integrado mantém uma API HTTP local na rede Wi-Fi do equipamento para consultar identificador, estado, SSID, IP, RSSI, canal, uptime e memória livre; esses metadados são acessíveis a dispositivos na mesma rede local e não são enviados à nuvem por esse firmware. A API não retorna a senha da rede. O código não declara criptografia de NVS/flash habilitada. A API local também poderá ser utilizada por uma futura integração com o aplicativo Android oficial; o cliente nativo ainda não está implementado.

A fila local durável de eventos físicos BLE já está implementada em Room, limitada a 1.000 registros e sincronizada por WorkManager com o endpoint autenticado do titular quando há sessão ativa. Os registros aceitos pelo backend permanecem no Room até um futuro protocolo de ACK com o ESP32. A fila offline de telemetria e o provisionamento BLE seguro (Security 2) ainda não são recursos concluídos. O portal web atual não utiliza BLE para transportar credenciais.

18. Integração Discord

Se você configurar a integração Discord, podemos tratar Discord User ID, IDs de servidor e canal, Application ID, Public Key, Bot Token e OAuth Client Secret quando fornecido, além de registros de vínculo, alertas e tentativas de entrega. As credenciais da aplicação são associadas à conta PescaRadar no backend para operar a integração; não são incluídas em respostas públicas nem nos eventos de webhook. A remoção da integração pelo painel apaga a configuração associada conforme o escopo implementado. Registros de infraestrutura e cópias controladas por terceiros podem ter retenção própria.

19. Webhooks e compartilhamento iniciado pelo usuário

Ao cadastrar webhook, tratamos URL HTTPS do destino, tipos de evento escolhidos, segredo de assinatura HMAC, identificadores de entrega, tentativas, status HTTP e latência. O segredo é exibido uma única vez na criação e não é retornado em listagens. O endpoint de destino recebe os dados mínimos definidos pelo evento. O usuário escolhe o destinatário e deve verificar que possui autorização para encaminhar os eventos a esse sistema.

Eventos não devem conter credenciais, tokens, coordenadas pessoais precisas ou conteúdo desnecessário. O teste de webhook envia evento sintético identificável como teste. A entrega é best-effort, pode sofrer retentativas e duplicidades e não garante processamento pelo destinatário.

20. Fornecedores, transferências e retenção

Serviços de infraestrutura, autenticação, meteorologia, mapas, geocodificação, e-mail e integrações podem receber dados técnicos ou os parâmetros necessários à funcionalidade. A lista de fornecedores e as limitações conhecidas estão em Licenças e créditos e no inventário técnico Inventário de dados e retenção disponível no repositório. A utilização efetiva varia por recurso. Alguns fornecedores podem operar fora do Brasil; a base e o mecanismo de transferência internacional devem ser avaliados pelo controlador conforme a LGPD e a regulamentação da ANPD.

Não existe hoje um prazo universal de retenção validado para todas as categorias. Prazos de cookie, sessões, cache, telemetria, eventos, histórico, backups e logs variam conforme o mecanismo e o fornecedor. O controlador deve definir critérios de retenção por finalidade e revisar sua necessidade. Não presumir que a exclusão de dados de visitante apague automaticamente conta, configurações Discord, segredos de webhook, logs de infraestrutura ou dados mantidos por destinatários externos.

21. Exportação, exclusão e solicitações de titulares

Os endpoints automatizados de exportação e exclusão cobrem somente as tabelas e namespaces explicitamente incluídos no código. A exportação pode indicar dados parciais. A exclusão pode exigir novas chamadas até confirmação explícita de conclusão. Recursos de visitante não representam, por si só, exclusão completa de conta ou de todos os dados tratados por integrações e fornecedores.

Para confirmação de tratamento, correção, informações sobre compartilhamento, oposição, portabilidade quando aplicável, exclusão ou outras solicitações que não estejam cobertas pelos controles automatizados, entre em contato pelo e-mail develop.jgs@gmail.com. Não envie senhas, tokens ou segredos nesse canal.

22. Incidentes de segurança

O controlador avalia incidentes que possam acarretar risco ou dano relevante aos titulares e realiza as comunicações exigidas pela LGPD e pela regulamentação vigente da ANPD. O procedimento interno está documentado no repositório; a existência do documento não significa que haja monitoramento 24 horas, equipe dedicada ou certificação de segurança.

23. Integração WhatsApp — Evolution API e WAHA

Se você configurar a integração WhatsApp, o PescaRadar trata o endereço HTTPS do servidor escolhido (na exportação é apresentado somente o host), o nome da instância/sessão, credenciais de API e, na Evolution API, um token próprio da instância, o número de telefone destinatário em formato internacional, os eventos selecionados e datas de configuração/conexão. Esses dados ficam associados à sua conta no armazenamento KV do PescaRadar. As credenciais não são devolvidas ao navegador nas respostas de configuração nem incluídas na exportação de dados; a exportação informa apenas se cada credencial está configurada.

Ao iniciar a conexão, o Worker encaminha solicitações ao servidor Evolution API ou WAHA indicado por você. O QR Code de pareamento é obtido sob demanda e retornado sem cache, para uso temporário na tela de conexão; não é persistido pelo PescaRadar. Quando você aciona “Enviar teste”, o PescaRadar envia uma mensagem de teste fixa ao número previamente configurado. O servidor externo e o serviço WhatsApp correspondente recebem os dados necessários à conexão e à entrega. A região, hospedagem, operadores e retenção desse servidor dependem da instalação que você escolheu.

Quando a configuração estiver habilitada e um evento estiver selecionado, o PescaRadar enfileira alertas de telemetria, limites de sensores, disponibilidade de dispositivos e alertas ambientais para o provedor correspondente. A fila e o histórico técnico ficam associados à conta e ao provedor, com expiração configurada em 14 dias. O conteúdo enviado é montado a partir dos campos do evento; podem ser compartilhados nome/identificador do dispositivo, sensor, valor, unidade, limite e horário. Coordenadas GPS e trilhas não são incluídas. O despacho usa tentativas limitadas e pode gerar mensagens duplicadas em falhas ou concorrência; não há garantia de entrega, leitura ou processamento pelo destinatário. O provedor e o serviço WhatsApp recebem os dados necessários à entrega e aplicam suas próprias regras de retenção e tratamento.

Ao usar “Remover” no painel de integrações, o PescaRadar tenta desconectar a sessão remota antes de apagar as credenciais locais; se o provedor estiver indisponível, a configuração permanece para permitir nova tentativa. A exportação autenticada inclui metadados de fila e histórico. O apagamento do diário remove localmente configuração, fila e histórico WhatsApp, mas não executa logout remoto; para revogar a sessão no provedor, desconecte/remova a integração no painel antes de solicitar o apagamento. Nenhum desses fluxos remove mensagens já entregues nem dados mantidos pelo provedor externo.

24. WhatsApp Cloud API oficial da Meta

Na integração direta Meta Cloud API, o PescaRadar trata Phone Number ID, versão da Graph API, token de acesso, destinatário em formato internacional, nome/idioma opcional de template aprovado, eventos selecionados, estado de ativação e timestamps. O token fica associado à conta no KV, não é devolvido ao navegador nem incluído na exportação; a resposta pública informa apenas se há token configurado.

O Worker envia os alertas sanitizados diretamente à Graph API da Meta por HTTPS. O conteúdo pode incluir nome do dispositivo, sensor, valor, unidade, limite e horário; coordenadas GPS e trilhas não são incluídas. O texto livre depende da janela de atendimento de 24 horas. Fora dela, o titular precisa cadastrar um template aprovado e configurá-lo no PescaRadar. A integração atual é somente de saída: recebimento por webhook Meta e Embedded Signup ainda não estão implementados. A remoção da configuração apaga o token local, mas não revoga a credencial na Meta nem remove mensagens já entregues. Meta e WhatsApp processam os dados conforme seus próprios termos; região, subprocessadores e transferências internacionais devem ser confirmados pelo controlador.

Versão do aviso: 1.9 · Atualizado: 12/11/2026

Revogar meu consentimento neste dispositivoSolicitar apagamento dos meus dados deste dispositivo