Privacidade e acesso à rede

O Fetchpier é local-first: não possui conta, servidor de equipe, telemetria, analytics, relatório de uso nem sincronização em segundo plano. Workspaces continuam sendo pastas comuns sob seu controle.

Conexões de rede

Toda conexão nasce de uma ação ou configuração que você controla:

• as requisições HTTP que você envia, incluindo redirecionamentos e o tráfego de proxy implicado por essas requisições;
• as importações de schemas que você inicia explicitamente a partir de uma URL HTTP ou HTTPS;
• uma verificação de atualizações no catálogo de produtos, que só roda quando você clica em Check now no diálogo de atualizações.

A interface não carrega fontes, scripts, imagens nem páginas web remotas. O texto da licença é lido da cópia distribuída com o aplicativo. Com a máquina offline, a edição do workspace, o histórico, a gestão de ambientes e todos os outros recursos locais continuam funcionando; apenas as operações que realmente exigem um endpoint remoto não podem ser concluídas.

Essa fronteira é garantida por auditorias de build, testes end-to-end, a Content Security Policy do renderer e guards de navegação. O renderer não pode introduzir silenciosamente uma nova dependência remota.

Propriedade dos dados e sincronização

O Fetchpier não envia dados do workspace. Requisições, ambientes, configurações, certificados, cookies e histórico são arquivos no workspace; o estado pessoal do app fica na pasta local de dados do usuário. Use Git, um compartilhamento de arquivos ou seu próprio sistema de sincronização quando quiser colaborar.

Revise um workspace de origem desconhecida antes de executá-lo. Os scripts pre-request e post-response rodam em um sandbox síncrono deliberadamente pequeno, mas o sandbox protege contra exposição acidental de APIs, não contra código hostil. Trate um arquivo .http não confiável como um shell script não confiável e use uma barreira de isolamento externa, como um contêiner, quando apropriado.

Limites deliberados

O produto atual intencionalmente não oferece:

• uma cloud do Fetchpier ou um servidor de sincronização de equipe;
• plugins além da API de scripting fp.* documentada;
• mocks ou fixtures de requisições;
• respostas em streaming, Server-Sent Events ou WebSockets;
• scripts assíncronos, promises, timers, acesso ao sistema de arquivos ou acesso à rede a partir dos scripts;
• integração com o trust store do sistema operacional;
• um editor de runtime específico para GraphQL;
• recuperação após reinício de requisições sem título não salvas ou de alterações não salvas;
• recuperação de segredos, custódia de chaves (key escrow) ou destinatários de criptografia por usuário.

Schemas GraphQL ainda podem ser importados, mas as operações geradas rodam como requisições HTTP comuns. CAs próprias precisam ser importadas explicitamente. Abas salvas e associadas a arquivos são restauradas; o trabalho não salvo é protegido por confirmações ao fechar, mas não é persistido como rascunho entre reinícios.

Esses são limites de compatibilidade e de segurança, não recursos não documentados. Projete automações e fluxos de equipe em torno deles, em vez de presumir estado na cloud ou um runtime semelhante ao de um navegador.