Os bytes exatos que são enviados.
A investigação grava dois arquivos localmente: um relatório HTML e uma carga útil JSON. Nada sai da sua máquina até você clicar em Share. Quando você faz isso, o arquivo JSON é o que é enviado via POST. O relatório HTML mostra o mesmo JSON em um bloco <pre> na parte inferior para que você possa lê-lo antes de compartilhar.
O compartilhamento é intencionalmente limitado.
Seu nome, ID da máquina, software instalado e caminhos do sistema de arquivos não estão na carga e não saem da sua máquina. O servidor vê um IP de solicitação como qualquer site, mas armazena apenas um hash salgado diário para proteção contra abuso; IPs brutos não são gravados no banco de dados nem publicados. A carga compartilhada é o modelo/capacidades do seu stick, quais efeitos foram reproduzidos e as seleções de chips que você fez.
O contrato SubmissionPayload
Cada campo nesta lista contém dados de especificações do dispositivo compartilhados entre unidades idênticas (VID:PID, sinalizadores de capacidade, efeitos suportados, revisão de firmware), informações aproximadas do ambiente (família de sistema operacional + versão principal) ou seus próprios rótulos canônicos selecionados por chip e quaisquer notas de texto livre que você escolheu digitar.
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 / macOS), versão principal, build, arquitetura, versão de tempo de execução do .NET. Cada valor é compartilhado por milhões de instalações idênticas.responses— por efeito: rótulos canônicos selecionados por chip (publicados) e quaisquer notas de texto livre que você digitou (mantidas apenas no lado do servidor, nunca 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á na carga útil, não é aceito pelo servidor
O JSON compartilhado possui um esquema. Se um campo não estiver nesse esquema, o site o rejeitará em vez de armazenar dados extras. Eles nunca fazem parte de um envio 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 — a investigação não os solicita e o esquema do servidor não os aceita.
O único campo privado
A filosofia do banco de dados público é publicar tudo o que pudermos. A única coisa que deliberadamente retemos são as notas de texto livre por efeito — o que você digitou na caixa de texto da resposta. Esse é o único lugar onde um testador pode colar algo pessoal, copiar e colar um caminho ou manchar a garantia sem PII, por isso permanece no lado do 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].