Os bytes exatos que são enviados.
O probe grava localmente dois arquivos de relatório: HTML e JSON. Os dados do relatório e do dispositivo não saem da máquina até você clicar em Share; então o arquivo JSON é enviado por POST. A GUI lê separadamente na inicialização um pequeno manifesto público de versões para procurar atualizações, sem enviar ID de instalação, informações do dispositivo ou resultados do probe.
O compartilhamento é intencionalmente limitado.
Seu nome, ID da máquina, software instalado e caminhos do sistema de arquivos não fazem parte dos dados do relatório. O servidor vê um IP de solicitação como qualquer site, mas guarda apenas um hash diário com sal para proteção contra abuso; IPs brutos não são gravados no banco nem publicados. Os dados compartilhados abrangem manche, ambiente, efeitos, diagnósticos, rótulos escolhidos e notas da resposta; as páginas públicas omitem o campo de notas. A verificação de atualização é uma solicitação de manifesto separada e sem identificadores.
O contrato SubmissionPayload
Cada campo desta lista é uma especificação compartilhada entre unidades idênticas, informação geral do ambiente, diagnóstico de teste, rótulo canônico selecionado ou nota da resposta. No Linux, as notas podem incluir movimento X/Y medido pela sonda, além de qualquer texto opcional digitado.
device— VID:PID, nome do dispositivo do fabricante, eixos, botões, povs, período de amostragem, resolução de tempo, revisão de firmware, revisão de hardware, versão do driver FF, sinalizadores de capacidade e a lista de efeitos suportados com sinalizadores de tipo.os— família (Windows / Linux), versão principal, build, arquitetura e versão do runtime .NET. Cada valor é um dado geral do ambiente compartilhado por muitas instalações.responses— por efeito: rótulos canônicos selecionados (publicados) e um campo de notas da resposta que pode conter texto opcional e movimento medido pela sonda no Linux (armazenado, mas nunca exibido na página pública de hardware).diagnostics— resultadosOK/FAIL: DIERR_…por efeito (vocabulário fechado, endereços de ponteiro removidos), o roll-up de efeitos com falha e quaisquer erros do orquestrador com caminhos de arquivo redigidos por regex para<path>. Publicados na página pública de hardware para que autores de drivers e criadores de ferramentas possam agir sobre eles.probe_versionesubmitted_date— apenas a data (sem hora do relógio).
Leia o formato literal da carga útil na página do relatório de amostra →
Não está no payload do relatório nem é aceito por /submit
O JSON do relatório compartilhado tem um único esquema. Se um campo não estiver nele, /submit o rejeita em vez de armazenar dados extras. Estes itens nunca fazem parte de um envio de relatório aceito:
- GUID da instância DirectInput — hash por máquina, um identificador direto da máquina.
- GUID do produto — identidade de hardware duplicada além de VID:PID.
- Nome bruto do dispositivo DirectInput — às vezes definido pelo usuário. Os envios usam um nome amigável da tabela VID:PID.
- Lista de dispositivos USB — todos os dispositivos USB e HID no host. Superfície pesada de impressão digital.
- Lista de software instalado — sem percorrer o registro, sem inventário de simulador, sem inventário de SDK/tempo de execução.
- Descrição completa do sistema operacional — as strings exatas do host são muito detectáveis. A carga útil usa campos grosseiros de família/versão do sistema operacional.
- Caminhos de arquivo em mensagens de erro — caminhos como
C:\Users\…ou/home/…são redigidos antes da serialização. - Registros de depuração — não aceitos pelo endpoint de submissão pública.
- Tempo de execução do relógio de parede — a data de envio é apenas a data, não a hora precisa.
- Campos de e-mail e contato — nunca fazem parte do payload do relatório. Depois que um relatório é compartilhado, a GUI oferece uma inscrição opcional separada para notificações, que envia apenas e-mail + VID:PID para
/notifye a armazena separadamente dos envios.
O único campo privado
A filosofia do banco público é publicar tudo o que pudermos com segurança. Retemos deliberadamente todo o campo responses[].notes de cada efeito. Ele pode conter texto digitado por quem testou, que pode incluir dados pessoais por acidente, e movimento medido pela sonda no Linux armazenado junto; o campo inteiro permanece no servidor.
Todo o resto — sinalizadores de capacidade, efeitos suportados, família + versão do sistema operacional, rótulos de chips, códigos HRESULT (nomes de vocabulário fechado S_OK / DIERR_…), roll-up de efeitos com falha, erros de execução redigidos por caminho, a nota da investigação — é renderizado na página do dispositivo exatamente como a investigação o relatou. Autores de drivers, desenvolvedores de simuladores e criadores de ferramentas precisam desses dados para agir; torná-los públicos é o objetivo do projeto.
Removendo um envio
Se você compartilhou um relatório e deseja removê-lo, envie um e-mail para [email protected] com o VID:PID do dispositivo e a data aproximada de envio. Não solicitamos uma conta ou ID de rastreamento — esses são os únicos campos que usaríamos para encontrar a linha.
Se você optou por receber o e-mail de notificação pós-envio, esse endereço será armazenado separadamente e poderá ser removido de forma independente. Envie a mesma caixa de entrada com “remover email” e o endereço.
Publicado pela Rohsam Inc.
O FFB Probe é publicado pela Rohsam Inc., uma editora de software canadense sediada em Toronto, Ontario.
Rohsam Inc.2727 Steeles Ave West, Unit 103-886
Toronto, ON M3J 3G9
Canada
Para solicitações de privacidade, exclusão ou suporte ao produto, entre em contato com [email protected]. Para consultas comerciais ou de validação de editora, entre em contato com [email protected].