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, softwares instalados e caminhos do sistema de arquivos não fazem parte do payload do relatório. O servidor vê o IP da requisição como qualquer site, mas armazena apenas um hash diário com salt para proteção contra abuso; IPs brutos não são gravados no banco de dados nem publicados. O payload compartilhado abrange o joystick e a classe do dispositivo, o ambiente, a intensidade do teste, os efeitos, os diagnósticos, as seleções de chips e as notas da resposta; as páginas públicas omitem o campo de notas da resposta. A verificação de atualizações é uma requisição de manifesto separada, sem identificadores.
O contrato SubmissionPayload
Cada campo desta lista é um dado de especificação do dispositivo compartilhado entre unidades idênticas, informação geral do ambiente, a intensidade do teste, diagnóstico de teste, rótulo canônico selecionado por chip ou nota da resposta. As notas da resposta podem incluir movimento X/Y medido pela sonda, no Windows e no Linux, além de qualquer texto opcional que você digitou.
device— VID:PID, nome do dispositivo, classe do dispositivo (device_type: flight, joystick, gamepad, wheel, other ou unknown), 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.run— a intensidade do teste com que cada efeito foi reproduzido (strength_pct) e se ela era o padrão do dispositivo ou foi escolhida por você (strength_source). As páginas de dispositivos mostram quantos relatórios foram executados em cada intensidade.responses— por efeito: rótulos canônicos selecionados por chip (publicados) e um campo de notas da resposta que pode conter texto digitado opcional mais o movimento medido pela sonda, picos X/Y com sinal como porcentagem da meia amplitude de cada eixo (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, e o app não envia nada fora dele. Se uma solicitação trouxer um campo que não está no esquema, /submit nunca o publica. Estes itens nunca fazem parte de um relatório enviado pelo app:
- 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 de hardware reconhecido — às vezes definido pelo usuário. Para um VID:PID da tabela de dispositivos do app, é enviado o nome amigável da tabela. Para um dispositivo que a tabela não conhece, o app envia o nome do modelo que você digitou quando solicitado ou, na falta dele, um nome higienizado informado pelo driver; esse nome é publicado como nome do dispositivo.
- 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.
- Nomes de outros programas em execução — o aviso da tela de boas-vindas e a mensagem de acesso exclusivo indicam programas que podem tomar o seu dispositivo, mas apenas na sua tela. Esses nomes não são adicionados ao relatório.
- 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 de dados 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, além do movimento medido pela sonda armazenado junto; o campo inteiro permanece no servidor.
Todo o resto — classe do dispositivo, sinalizadores de capacidade, efeitos compatíveis, família + versão do sistema operacional, intensidade do teste, rótulos de chips, códigos HRESULT (nomes de vocabulário fechado S_OK / DIERR_…), resumo de efeitos com falha, erros de execução com caminhos removidos, a nota da sonda — é exibido na página do dispositivo exatamente como a sonda informou. Autores de drivers, desenvolvedores de simuladores e criadores de ferramentas precisam desses dados para agir; torná-los públicos é a razão de ser do projeto.
Removendo um envio
Se você compartilhou um relatório e quer removê-lo, envie um e-mail para [email protected] com o código de suporte que o aplicativo mostrou após o compartilhamento (ele começa com PRB-). Sem o código, envie o VID:PID do dispositivo e a data aproximada do envio. Em nenhum dos casos é preciso ter conta.
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].