redfetch ← Voltar
Privacidade

Política de Privacidade.

O que o RedFetch realmente processa, o que não coleta e quais serviços externos participam da operação.

Última atualização: 26 de setembro de 2026.

1. Quem é responsável

Para as operações de tratamento decididas pelo próprio RedFetch, o responsável identificado é Marcelo Fabiano / Slonney. O canal para questões de privacidade e exercício de direitos é redfetch@proton.me.

Esta política descreve a versão do código revisada em 26/09/2026. Serviços de terceiros, como Vercel, Cloudflare, RedGIFs e Proton Mail, também podem atuar como agentes independentes ou prestadores em relação aos dados que processam segundo suas próprias políticas.

2. O que o RedFetch não faz

  • não possui cadastro de usuários nem login próprio;
  • não pede credenciais da sua conta RedGIFs;
  • não possui banco de dados de histórico de consultas no servidor; o Histórico portátil opcional fica apenas na memória da aba e no arquivo .log que o próprio usuário decide importar/exportar;
  • não integra Google Analytics, Meta Pixel, publicidade ou Vercel Web Analytics no código revisado;
  • não usa cookies de publicidade ou analytics. O localStorage é usado apenas para guardar a preferência manual de idioma (pt-BR ou en-US), e o sessionStorage não é usado; após uma verificação anti-bot bem-sucedida, cria também um cookie técnico temporário de sessão, descrito abaixo;
  • não hospeda uma cópia persistente dos arquivos de vídeo HD/SD.

Isso não significa que nenhuma informação técnica exista na infraestrutura: a hospedagem e os serviços externos processam dados necessários para receber e entregar requisições, conforme explicado abaixo.

3. Informações processadas quando você consulta um link

URL enviada

O navegador envia ao endpoint /api/redgifs a URL do RedGIFs que você informou e opções técnicas indicando se aquela requisição precisa de prévia e/ou verificação de tamanho. O backend usa essa URL apenas para validar o domínio/caminho, extrair o identificador e executar a consulta solicitada.

O código do RedFetch não grava deliberadamente a URL enviada em banco de dados nem a inclui nos logs de aplicação. Ela é processada em trânsito e na memória necessária à execução da requisição.

Verificação anti-bot

Antes da primeira consulta, quando ainda não existe uma sessão de verificação válida, o RedFetch utiliza o Cloudflare Turnstile para reduzir abuso automatizado da API. O Turnstile pode processar sinais técnicos necessários à detecção de bots, como endereço IP, User-Agent, características TLS, sitekey e origem associada. O RedFetch envia ao backend apenas o token gerado pela verificação; o token é validado com o serviço Siteverify da Cloudflare.

Depois de uma validação bem-sucedida, o RedFetch cria o cookie estritamente necessário __Host-redfetch_human. Ele é assinado pelo servidor, marcado como HttpOnly, Secure e SameSite=Lax, e dura no máximo cerca de 2 horas. O cookie não contém URL consultada, ID de vídeo, histórico de consultas, e-mail ou conteúdo do vídeo; serve apenas para evitar repetir a verificação a cada item, inclusive em buscas em massa.

Dados técnicos de conexão e limitação de requisições

A infraestrutura da Vercel recebe requisições ao site e às funções. A própria Vercel informa que pode processar endereço IP do usuário final, localização aproximada derivada do IP, configuração do sistema, dados de tráfego, diagnósticos e logs técnicos. O RedFetch não recebe uma localização precisa pelo código da aplicação.

O endpoint POST /api/redgifs também está protegido por uma regra de rate limit configurada diretamente na infraestrutura da Vercel. Atualmente, a regra permite até 150 requisições por minuto por endereço IP e, quando o limite é excedido, a infraestrutura pode responder com HTTP 429 Too Many Requests. O endereço IP é usado tecnicamente pela infraestrutura para aplicar essa limitação e reduzir abuso. O código do RedFetch não grava esse IP em banco próprio para executar o rate limit; logs e demais dados técnicos tratados pela Vercel seguem os controles e políticas da própria infraestrutura.

Contato direto com o RedGIFs

O backend do RedFetch se comunica com serviços do RedGIFs para obter token temporário, metadados públicos do post (como criador, data, visualizações e curtidas quando disponíveis), tamanhos e, quando necessária, prévia. No modo em massa, a consulta principal não baixa automaticamente todas as thumbnails: a prévia é solicitada ao backend apenas quando o respectivo card se aproxima da área visível. Além disso, no modo individual, o navegador pode acessar diretamente a URL de mídia do RedGIFs para ler dimensões/duração e tentar gerar a prévia. Ao abrir HD ou SD, seu navegador também se conecta diretamente ao host informado pelo RedGIFs. Nesses acessos diretos, o serviço de origem poderá receber dados técnicos da sua conexão, como endereço IP e informações normalmente transmitidas pelo navegador.

4. Prévia, tamanho e token temporário

  • Prévia: o backend pode baixar uma imagem de thumbnail/poster do RedGIFs e convertê-la em data:image/...;base64 para devolver ao navegador. O código não grava essa imagem em armazenamento persistente.
  • Tamanho: o backend usa requisições HEAD e, quando necessário, uma requisição Range de um byte para descobrir o tamanho remoto do arquivo. Isso não equivale a armazenar o vídeo inteiro no RedFetch.
  • Token: o backend obtém um token temporário do endpoint técnico do RedGIFs e o mantém em memória por até aproximadamente 4 minutos para reduzir chamadas repetidas. Esse token é obtido pelo próprio servidor e não é uma credencial da conta do usuário.

Compatibilidade com GitHub Web

Quando a opção “GitHub Web — 25 MiB” é ativada, a comparação é feita no próprio navegador a partir dos tamanhos que o RedFetch já recebeu. Essa verificação não envia o vídeo, a URL consultada, o ID do vídeo nem o resultado da análise ao GitHub e não exige uma nova integração com o GitHub.

Ferramentas do lote

Resumos de tamanho, busca local por ID/criador, filtros, ordenação, limite personalizado, indicador de economia HD/SD e modo apresentação são calculados na memória do navegador usando os resultados já obtidos; não criam conta nem histórico no servidor. O botão de copiar envia à área de transferência apenas as URLs dos resultados exibidos, na ordem atual. A exportação cria no navegador um arquivo TXT somente com os resultados exibidos naquele momento, preservando a ordenação e registrando o filtro e a ordenação usados, além de IDs, URLs HD/SD, tamanhos, duração, status, mensagens de erro e, quando disponíveis, criador, data da postagem, visualizações e curtidas. O arquivo baixado e o texto copiado passam a ficar sob controle do seu dispositivo e dos aplicativos com que você decidir compartilhá-los. Tentar novamente consultas com erro executa novas chamadas ao endpoint do RedFetch somente para esses itens.

Preferência de idioma

Quando você escolhe manualmente português ou inglês, o RedFetch salva apenas essa preferência em localStorage sob uma chave técnica do próprio site. O valor não contém URL, ID de vídeo, histórico, e-mail ou outro conteúdo consultado e serve somente para manter o idioma escolhido em visitas futuras. Se não houver preferência salva, o primeiro acesso usa o idioma informado pelo navegador (navigator.languages/navigator.language) para escolher entre pt-BR e en-US.

Histórico portátil

O Histórico portátil é opcional e usa um arquivo .log escolhido pelo usuário. Ao importar, o conteúdo do arquivo é lido localmente pelo JavaScript no navegador e o arquivo .log em si não é enviado ao backend do RedFetch, à Vercel, ao RedGIFs nem a outro serviço por esse recurso. Os registros carregados permanecem somente na memória da aba; o RedFetch não os salva em localStorage, sessionStorage ou banco de dados. Recarregar ou fechar a página remove esse estado da memória, salvo se o próprio usuário exportar um novo .log para o dispositivo. Por compatibilidade, o importador também aceita arquivos .txt que contenham um histórico RedFetch válido.

O histórico pode conter IDs de vídeos, primeira e última data de consulta, número de consultas, último status, indicação de disponibilidade HD/SD, um snapshot opcional de metadados públicos recebidos na consulta (criador, data da postagem, visualizações e curtidas), metadados técnicos da família/revisão do próprio arquivo (como criação e número v1, v2, v3) e, se o usuário escolher preencher, um nome e uma descrição do histórico. Esses campos opcionais também são processados localmente e permanecem dentro do arquivo .log; esta função não os envia ao backend. O histórico registra consultas feitas pelo RedFetch e não comprova que um arquivo foi baixado. Se o usuário decidir consultar novamente um ID do histórico, a URL/ID correspondente volta a seguir o fluxo normal de consulta descrito nesta política; ativar “Ignorar IDs já consultados” evita essa nova requisição para os itens reconhecidos. O usuário também pode recolocar IDs do histórico na fila do modo Em massa; essa restauração acontece somente na memória do navegador e não envia qualquer consulta até que o usuário inicie uma busca. Remover IDs conhecidos da fila ou ocultar cards já consultados altera apenas o estado local/visual da operação atual e não apaga nem modifica os registros do histórico.

5. Logs e retenção

O código da aplicação registra apenas informações mínimas sobre falhas do serviço externo — tipo do erro e status HTTP quando disponível — sem registrar deliberadamente a URL consultada, o ID do vídeo ou o corpo da requisição nesse log.

A Vercel mantém logs e telemetria próprios da infraestrutura. Os prazos variam conforme o plano e os recursos contratados. Na documentação consultada em setembro de 2026, os Runtime Logs padrão eram mantidos por cerca de 1 hora no Hobby, 1 dia no Pro e 3 dias no Enterprise, com opções de retenção maior em produtos adicionais. Esses limites podem ser alterados pela Vercel.

E-mails enviados a redfetch@proton.me ficam sujeitos ao armazenamento e às políticas do Proton Mail até serem apagados ou enquanto precisarem ser mantidos para atender à solicitação ou cumprir obrigação legal.

6. Finalidades e bases legais

Quando uma informação puder ser considerada dado pessoal, o RedFetch procura limitar o tratamento ao necessário para:

  • executar a consulta solicitada pelo usuário e entregar o resultado;
  • manter segurança, prevenir abuso e diagnosticar falhas de forma proporcional;
  • responder contatos, reclamações e pedidos relativos a direitos;
  • cumprir obrigações legais, regulatórias ou ordens válidas quando aplicável.

Conforme o caso, essas finalidades podem se apoiar nas hipóteses previstas no art. 7º da LGPD, como execução do serviço solicitado, legítimo interesse compatível com os direitos do titular e cumprimento de obrigação legal. O RedFetch não usa “consentimento genérico” como justificativa para qualquer tratamento.

7. Compartilhamento e terceiros

Vercel
Hospedagem, entrega do site, execução da função serverless e logs/telemetria da infraestrutura.
Cloudflare Turnstile
Verificação anti-bot antes de consultas à API; processa sinais técnicos necessários para distinguir pessoas de tráfego automatizado.
RedGIFs
Fonte técnica consultada para metadados e mídia; também recebe conexões diretas do navegador em situações descritas nesta política.
Proton Mail
Processa o endereço do remetente, conteúdo e metadados de mensagens quando você escolhe enviar um e-mail ao RedFetch.

O RedFetch não vende dados pessoais a anunciantes e não contém rede de publicidade no código revisado.

8. Seus direitos

Nos casos em que o RedFetch seja controlador de dados pessoais seus, você pode solicitar, conforme aplicável, confirmação de tratamento, acesso, correção, anonimização, bloqueio ou eliminação de dados desnecessários ou tratados irregularmente, informações sobre compartilhamento, oposição e demais direitos previstos no art. 18 da LGPD.

Como o RedFetch não mantém um banco de histórico de consultas, em muitos casos não haverá um registro persistente da URL pesquisada para localizar ou apagar no banco do projeto. Isso não impede que você peça esclarecimentos sobre o tratamento técnico ou sobre mensagens enviadas por e-mail.

Exercer direitos de privacidade

9. Segurança

O projeto adota medidas técnicas compatíveis com seu porte, incluindo HTTPS fornecido pela hospedagem, validação de domínio/caminho no frontend e no backend, ausência de credenciais do usuário, proteção anti-bot com validação server-side do Cloudflare Turnstile, sessão técnica assinada de curta duração, cache curto do token temporário, cabeçalhos de segurança, política de referência restritiva, minimização dos logs da aplicação e capacidade de bloquear identificadores específicos no RedFetch quando necessário.

Nenhum sistema conectado à internet é absolutamente invulnerável. Se você identificar uma falha de segurança, envie detalhes para redfetch@proton.me e evite explorar dados de terceiros além do necessário para demonstrar o problema.

10. Crianças e adolescentes

O RedFetch não é dirigido a crianças ou adolescentes. Como a ferramenta pode apresentar prévias e links para conteúdo adulto de terceiros, existe uma obrigação regulatória relevante de impedir acesso indevido de menores a conteúdo impróprio. A legislação brasileira atual veda tratar uma simples autodeclaração de idade como mecanismo confiável suficiente para esse tipo de acesso.

Em 22/09/2026, a ANPD ainda informa que os guias definitivos de escopo e de aferição de idade estão em consolidação. O responsável acompanhará essas regras e poderá modificar, restringir ou suspender funcionalidades conforme necessário. Esta política não afirma que a mera publicação de textos legais torna o serviço integralmente conforme ao ECA Digital.

11. Alterações e contato

Esta política pode mudar se o código, os fornecedores, a infraestrutura ou a legislação mudarem. A data de atualização ficará indicada no topo.

redfetch@proton.me

Fontes e referências