Esta é uma tradução automática; a versão em inglês é a que vincula. Ler a versão em inglês

Privacidade e cookies

Este aviso abrange duas coisas distintas: a aplicação FoxSDR que instala e este site. Recolhem dados diferentes, por razões diferentes, e são descritos separadamente abaixo — primeiro a aplicação, porque é a parte que corre na sua própria máquina. Foi escrito para ser completo e não curto: todos os campos que qualquer um deles guarda estão indicados, incluindo os que a maioria dos avisos omite.

A aplicação: o que envia

Não há conta, nem chave de licença, nem ativação, e o FoxSDR nunca comunica nada sobre o que ouve. Faz exatamente quatro tipos de pedido de rede por iniciativa própria: uma verificação de atualizações; um relatório de utilização anónimo, com um pequeno sinal de «ainda em execução» enquanto a aplicação está aberta; um relatório de falha ou de bloqueio depois de uma avaria; e — só quando o utilizador abre a loja de plugins ou prime VERIFICAR AGORA nela — um pedido ao catálogo de plugins. Cada um é descrito abaixo, campo a campo, e cada um pode ser desligado. Três interruptores controlam-nos: SISTEMA → Atualizações, SISTEMA → Relatório de utilização e SISTEMA → Diagnóstico. Nenhuma funcionalidade depende de algum deles estar ligado, e nada o importuna por desligar um.

O que fica na sua máquina

As suas gravações, tanto de áudio como de I/Q em bruto, as imagens que os descodificadores SSTV e de satélites meteorológicos constroem, tudo o que os descodificadores descodificam, os seus marcadores, planos de bandas, definições, a posição do seu recetor e os plugins que instalou são ficheiros no seu próprio disco. Nada os carrega para lado nenhum, e nenhuma frequência que sintonize sai da sua máquina.

A verificação de atualizações

Uma vez por arranque, a aplicação pergunta a este site se existe uma versão mais recente. O pedido completo é GET /api/update?v= seguido da versão que está a usar — sem identificador, sem id de instalação, sem cookie e sem nada que possa ser associado a um pedido posterior. Este servidor não escreve nenhum registo de estatísticas para ele: só são registadas as visualizações de páginas e as transferências de ficheiros, e o endpoint de atualizações não é nenhuma delas. Desligue-a em SISTEMA → Atualizações, e a aplicação nunca mais contacta o serviço.

A resposta também pode incluir uma breve mensagem nossa para quem usa uma versão mais antiga — por exemplo, a indicar que uma versão corrige algo que justifica a atualização — apresentada no mesmo aviso de atualização que as notas da versão. Não é enviado nem registado nada adicional para que isso seja possível: segue no mesmo pedido acima, com a mesma periodicidade, sob o mesmo interruptor.

Nada é transferido nem instalado a menos que prima o botão. Se o fizer, o instalador é obtido deste site por HTTPS e o seu SHA-256 é verificado face ao resumo que o servidor publicou antes de o ficheiro receber um nome que algo possa executar — e essa obtenção é uma transferência normal a partir deste site, por isso é registada como qualquer outra, com o endereço IP, a localização aproximada, o navegador e o sistema operativo descritos na parte deste aviso relativa ao site.

Uma cópia instalada a partir da Microsoft Store pergunta à Microsoft Store, nunca a este site (desde o FoxSDR 0.99.53). Uma vez por arranque, quando SISTEMA → Atualizações → Perguntar à Microsoft Store por atualizações ao iniciar está assinalado, o FoxSDR pergunta ao serviço Store do próprio Windows se existe um pacote mais recente para esta cópia. Nada do FoxSDR é enviado nesse pedido — nem versão, nem identificador: o Windows identifica a aplicação perante a Microsoft através da identidade do pacote que já possui, tal como faz nas atualizações em segundo plano da própria Store. A resposta fica na aplicação. Nada é transferido nem instalado a menos que prima Instalar a partir da Microsoft Store e confirme a caixa de diálogo que o Windows apresenta; a transferência e a instalação passam então a ser da Microsoft, ao abrigo da declaração de privacidade da Microsoft. Desassinale a caixa e a Store não é consultada.

Relatório de utilização

A partir da versão 0.53.0 existe um relatório de utilização anónimo, em SISTEMA → Relatório de utilização. Está ligado por predefinição e pode desligá-lo — desmarque essa caixa e os relatórios param imediatamente. É enviado um relatório por arranque, que descreve a sessão que acabou de terminar, e é isto na íntegra:

É esta a lista completa. É distribuída com a aplicação como PRIVACY.md, e um teste automático verifica o conteúdo enviado campo a campo, por isso não é possível acrescentar um campo novo sem que esse teste falhe e sem que ambos os documentos sejam atualizados. Desligar os relatórios apaga o identificador de instalação, por isso, se alguma vez os voltar a ligar, recebe um novo que não pode ser associado ao antigo.

O relatório é enviado no arranque, com a descrição da sessão que já terminou, e nunca à saída — uma chamada de rede no momento de sair pode bloquear uma aplicação que alguém está a tentar fechar, e um relatório escrito à saída perder-se-ia precisamente no evento que mais vale a pena contar. Nada na resposta é lido nem dá origem a qualquer ação.

As contagens de falhas, por extenso (a partir do FoxSDR 0.99.64). O campo é um texto curto de pares kind=count, como radio_fail.rtlsdr.busy=2 — um RTL-SDR que não abriu, duas vezes, porque outro programa o estava a usar. O FoxSDR constrói cada tipo a partir de uma tabela fixa e não envia nada que não esteja nela, e o servidor que recebe descarta tudo o que não estiver na mesma tabela. Quando um motivo é lido do que um controlador disse, o FoxSDR escolhe uma palavra de uma lista fixa e deita a frase fora. Para que uma falha numa sessão que depois bloqueia seja comunicada na mesma, as contagens ficam à espera num pequeno ficheiro chamado telemetry-health junto ao seu ficheiro de definições, juntamente com o seu identificador de instalação, até o servidor ter aceitado um relatório que as leve; desligar o relatório de utilização remove o ficheiro.

Os frames lentos e as recuperações, por extenso (a partir do FoxSDR 0.99.65). Estão no mesmo campo e na mesma forma kind=count. slow.rail.250ms=3 são três frames da janela que demoraram, cada um, um quarto de segundo ou mais, na parte do desenho que é a coluna de menus. A parte é uma de dezoito palavras, events, frame-start, pre-draw, plugin-panels, toolbar, rail, spectrum, patch, status, dialogs, polls, saves, render, present, recorder, plugins-reload, startup, other, e a lentidão é uma de três: 250ms para um quarto de segundo até menos de um segundo, 1s para um segundo até menos de cinco segundos e 5s para cinco segundos ou mais. O tempo que passou a responder a um pedido do Windows, ou a arrastar ou redimensionar a janela, é descontado e nunca contado. recovered.audio=1 é uma vez em que o FoxSDR encontrou uma falha e prosseguiu por si. A palavra é um de treze lugares, audio, reopen, srcthread, vendorcall, ringdrop, dspexc, cfgsave, enumchild, pluginapi, webroute, patchload, sdrenum, sdrlost, por esta ordem: a saída de som parou e o vigia reiniciou-a; um controlador de rádio do SoapySDR falhou e o FoxSDR reabriu o rádio por si; um controlador de rádio nunca regressou de uma leitura quando o recetor foi parado e o FoxSDR abandonou a thread; uma chamada a um módulo de fornecedor do SoapySDR não regressou a tempo e foi abandonada; o rádio entregou amostras mais depressa do que eram retiradas e algumas foram descartadas; a thread de processamento de sinal lançou um erro que foi capturado e o recetor parou; o ficheiro de definições não pôde ser gravado; o programa auxiliar que lista os rádios do SoapySDR falhou e foi contido; uma chamada de um plugin ao FoxSDR lançou um erro e foi respondida com um valor predefinido; um tratador da interface web lançou um erro e o servidor respondeu com uma falha; um patch guardado foi carregado com ligações omitidas; o serviço SDRplay não respondeu a um varrimento e o varrimento foi abandonado; a sessão SDRplay perdeu-se e o SDRplay ficou fechado até ao fim da sessão. O FoxSDR constrói cada um a partir de uma tabela fixa e não envia nada que não esteja nela, e o servidor que recebe descarta tudo o que não estiver na mesma tabela, pelo que nunca há nome de dispositivo, número de série, caminho, frequência nem texto de mensagem; um relatório leva no máximo os oito piores tipos de frame lento e oito tipos de recuperação. São contados sob os mesmos dois interruptores das contagens de falhas, só enquanto o Relatório de utilização e o Diagnóstico estiverem ambos ligados, ficam à espera no mesmo pequeno ficheiro chamado telemetry-health junto ao seu ficheiro de definições até o servidor ter aceitado um relatório que os leve, e desligar o relatório de utilização remove o ficheiro.

O sinal de «ainda em execução»

Um relatório que chega quando a aplicação arranca pode dizer quem a abriu, mas nunca quem ainda a tem aberta. Por isso, enquanto o FoxSDR está em execução — e só enquanto o relatório de utilização estiver ligado — envia também uma mensagem muito pequena a cada cinco minutos, com três campos e mais nada:

Nada da sessão vai junto: nem modos, nem painéis, nem modelo de rádio, nem durações, nem contadores. Os sinais são escritos num conjunto de dados próprio, separado dos relatórios de sessão, para que nenhum número de utilização mude de significado. O mesmo interruptor desliga ambos: o emissor recusa-se a arrancar sem um identificador de instalação válido, e desligar o relatório de utilização apaga-o, por isso desligado significa nenhum sinal. Um sinal ainda em trânsito quando o seguinte é devido é ignorado em vez de ficar em fila.

Para onde vão os relatórios de utilização

Para um Cloudflare Worker operado por este projeto em https://telemetry.foxsdr.com, que escreve os contadores acima num conjunto de dados do Cloudflare Workers Analytics Engine. A Cloudflare trata-os em nosso nome e guarda-os durante três meses, depois dos quais desaparecem. Mais ninguém os recebe, não são vendidos, alugados nem partilhados, e a única coisa que se lê deles são contagens agregadas, através do mesmo painel protegido por palavra-passe descrito mais abaixo. O código-fonte do Worker é publicado com a aplicação, por isso pode ler o que faz o lado que recebe. Os relatórios de falha não vão para aqui — vão para o próprio servidor deste site, descrito a seguir.

Relatórios de falha e de bloqueio

Se o FoxSDR falhar, ou deixar de responder, escreve um relatório que descreve a avaria em %LOCALAPPDATA%\FoxSDR\crashes\ na sua própria máquina, e envia o texto do relatório no próximo arranque — nunca de dentro da própria falha, porque um programa que acabou de falhar não pode abrir uma ligação de rede em segurança. Vai para POST /api/crash neste site — não para a Cloudflare, nem para terceiros — e é anónimo: não há conta, nem chave de licença, nem nada com que iniciar sessão.

O interruptor é SISTEMA → Diagnóstico, e controla por igual a escrita e o envio: com ele desligado, não é escrito nenhum relatório, não é criado nenhum diretório e nunca é feita nenhuma ligação. É um interruptor diferente do do relatório de utilização. Desligar o relatório de utilização não impede um relatório de falha — esvazia nele o campo do identificador de instalação, porque nesse caso não existe identificador e um relatório de falha nunca cria um (ver a última linha da tabela abaixo). Até esta versão, o aviso acima indicava o interruptor errado; o software sempre usou o Diagnóstico, e os dois dizem agora a mesma coisa.

É isto, na íntegra, o que um relatório contém:

Corrigido no FoxSDR 0.99.33. Antes da versão 0.99.33, a limpeza descrita acima era aplicada apenas às linhas do controlador do rádio, não às da própria aplicação, e algumas linhas da própria aplicação podiam por isso chegar a um relatório de falha ou de bloqueio com a frequência que tinha pedido ou em que estava a transmitir, a etiqueta de um rádio do patch (que pode incluir o seu número de série), os nomes que deu às partes do patch, a primeira linha de texto que um descodificador na página do patch tinha produzido, e a lista de dispositivos USB que o controlador USB imprimiu, incluindo os respetivos números de série. Isso contradizia este aviso. A partir da versão 0.99.33, cada linha é limpa antes de sair do seu computador, e essas linhas de registo deixam de conter esses valores à partida.

Corrigido no FoxSDR 0.99.59. Este aviso sempre disse que um relatório de falha não contém nenhum nome de máquina e que a aplicação nunca envia o seu endereço IP, mas até 0.99.59 o filtro de limpeza não procurava endereços de rede nem nomes de host. Algumas linhas do registo podiam, por isso, chegar a um relatório de falha ou de bloqueio, ou ao registo de diagnóstico de um relatório de erros, com o endereço ou o nome de host que escreveu para um rádio de rede, como um ADALM-Pluto, ou um endereço ou endereço web que o controlador de um rádio de rede registou; podiam também conter o número de uma porta série e, em algumas linhas de erro, o nome de uma placa de som. Isso contradizia este aviso. A partir de 0.99.59, os endereços e os nomes de host são substituídos e os números de porta série mascarados, como descrito acima, as linhas do próprio ADALM-Pluto já não imprimem o seu endereço e nenhuma linha do registo indica o nome de uma placa de som.

Um relatório de falha não contém nenhuma frequência, nada descodificado, nenhum caminho de ficheiro, nenhum nome de utilizador, nenhum nome de máquina, nenhum endereço de rede e nenhuma localização. Os relatórios ficam no próprio servidor deste site, atrás do mesmo painel protegido por palavra-passe que tudo o resto, e são guardados durante 90 dias depois de a avaria ter sido vista pela última vez, e depois apagados — os mesmos três meses durante os quais os relatórios de utilização são guardados. O primeiro relatório de cada avaria é guardado na íntegra, juntamente com um relatório adicional por cada compilação para a qual a avaria transite, até três; todos os outros relatórios dessa mesma avaria são contados em vez de guardados. Um teste automático vincula à tabela acima tanto o que o endpoint aceita como o que escreve em disco, nos dois sentidos, por isso não é possível acrescentar um campo a nenhum deles sem que esta tabela também mude.

Nunca é enviado um dump de memória completo, com nenhuma definição. Um dump de memória é uma cópia da memória do programa e pode conter nomes de ficheiros, títulos de janelas e dados de sinais recebidos. Está desligado por predefinição; se o ligar em SISTEMA → Diagnóstico, é escrito um .dmp junto do relatório de texto, apenas localmente, e o programa de envio abre os ficheiros com o nome crash-*.txt e hang-*.txt e mais nenhum.

Um relatório da sentinela, a partir do FoxSDR 0.99.64. Alguns finais nada dentro do FoxSDR consegue comunicar: uma falha que salta todos os tratadores, um excesso de pilha, uma janela tão bloqueada que o vigia de bloqueios também ficou preso. Por isso, numa sessão interativa com o Diagnóstico ligado, o FoxSDR inicia uma segunda cópia do seu próprio programa, sem janela, que só espera que a primeira termine — a sentinela. Pode ler como o FoxSDR terminou (o código de saída e quando começou e parou), uma pequena página partilhada de números que o FoxSDR mantém atualizada (em que fase está, quantas imagens desenhou e quando desenhou a última, que parte do desenho da janela está em curso, se há um menu aberto ou se a janela está a ser arrastada) e o final do registo da sessão, limpo como o de qualquer outro relatório. Não lê nada da memória do FoxSDR e não faz nenhum dump, e a página de números não tem espaço para texto, pelo que não pode conter um nome, um caminho, uma frequência ou um endereço. Quando o FoxSDR termina, a sentinela escreve um relatório na mesma pasta e no mesmo formato dos outros — nenhum se o FoxSDR terminou normalmente ou já tinha escrito um —, cujo motivo é feito só de palavras fixas e segundos inteiros, com as linhas do recetor substituídas por uma frase fixa a dizer que não as consegue ler. Não envia nada por si: o relatório sai no arranque seguinte, sob o mesmo interruptor e os mesmos limites de qualquer outro, e apenas se o FoxSDR falhou, se a janela tinha deixado de desenhar ou se terminou antes da primeira imagem. Um fim vindo de fora (o Gestor de Tarefas ou um script) e um fim porque o Windows terminou a sua sessão ficam na sua máquina e nunca são enviados. Com o Diagnóstico desligado, a sentinela não é iniciada.

Com que frequência. No máximo cinco relatórios por dia a partir de uma máquina, e a mesma avaria só uma vez por dia, por muitas vezes que aconteça — ambos os limites são guardados no seu próprio ficheiro de definições, por isso uma máquina num ciclo de falhas deixa de enviar por si própria em vez de lhe ser dito que pare, e um relatório que falhe é tentado de novo em arranques posteriores no máximo três vezes e depois deixado de lado. Transformar um offset de um relatório no nome de uma função exige a base de dados de depuração dessa compilação exata, que fica nas nossas próprias máquinas e nunca é carregada para lado nenhum: a resolução é feita localmente, não no servidor.

O que a aplicação nunca envia

• As frequências que sintoniza. O que alguém ouve é a coisa mais sensível que este software conhece, e nunca é recolhida. No Reino Unido, intercetar uma mensagem que não está autorizado a receber, ou divulgar o seu conteúdo, é crime nos termos da secção 48 da Wireless Telegraphy Act 2006.
• Os nomes ou caminhos dos ficheiros que abre. O nome de ficheiro de uma gravação são dados seus — pode indicar um serviço, um lugar ou uma frequência. Quando um ficheiro I/Q não volta a abrir, o registo indica que não voltou a abrir; o nome fica no ecrã, onde já o conhece.
• Nada do que é descodificado — mensagens de pagers, aeronaves, navios, imagens, tráfego de satélites.
• A sua posição, nem a posição de nada do que recebe — incluindo a posição do recetor que define, que nunca é transmitida em nenhum relatório. Ver abaixo.
• O seu endereço IP, nem qualquer localização dele derivada. Um pedido chega necessariamente a um servidor a partir de um endereço, porque é assim que a internet funciona; o endpoint de utilização não lê nenhuma informação de ligação e não escreve registos de pedidos. A partir do FoxSDR 0.99.59, um endereço de rede ou nome de host nas linhas de registo que um relatório contém também é substituído por <host>.
• Números de série do hardware. O modelo do rádio é útil; o número de série identifica o seu rádio individual, e é removido antes do envio.
• O seu nome, o nome da sua máquina, a sua conta de utilizador, qualquer caminho de ficheiro ou o nome de uma placa de som.
• Um dump de memória completo.

A posição do recetor, e o GPS

O FoxSDR precisa de saber onde está o recetor, porque todas as distâncias e azimutes no mapa e no ecrã de radar são medidos a partir dele. Pode escrevê-la, clicar nela no mapa ou lê-la de um recetor GPS numa porta série.

A posição fica na sua máquina. É guardada no seu próprio ficheiro de definições e nunca é transmitida — nem no relatório de utilização, nem no sinal, nem num relatório de falha, nem em lado nenhum. Lê-la de um GPS é algo que o utilizador inicia: indica a porta e prime «Ler posição do GPS». A porta só fica ocupada até chegar a primeira posição, e no máximo durante 60 segundos. O registo de diagnóstico guarda o nome da porta, a velocidade em baud, as contagens de frases e de satélites e qualquer erro — nunca a posição, e nunca o texto de uma frase NMEA. Um campo de porta que contenha algo que não tenha a forma de uma porta é registado pelo tipo e pelo comprimento («um caminho de dispositivo escrito, 27 caracteres»), para que um caminho de ficheiro com o seu nome de utilizador não possa ir parar a um relatório. Dois testes automáticos garantem isto: um sobre o anel de registo e outro sobre o ficheiro de registo que a aplicação real escreveu.

O catálogo de plugins

O catálogo é contactado quando abre a janela da loja de plugins (na primeira vez numa sessão, desde o FoxSDR 0.99.16), sempre que prime VERIFICAR AGORA nela e quando decide instalar alguma coisa. Nada é obtido no arranque, a janela não volta a abrir sozinha e nenhum plugin se atualiza sozinho. O catálogo é um ficheiro publicado no GitHub (raw.githubusercontent.com), por isso esse pedido chega aos servidores do GitHub, que — como em qualquer pedido web — veem o endereço de onde veio. Nenhum identificador seu é enviado com ele: nem id de instalação, nem cookie, nem nada que possa ser associado a um relatório de utilização. Todas as transferências são feitas por HTTPS, têm um tamanho máximo, são recusadas perante um redirecionamento para outro servidor e são verificadas face ao sha256 publicado no catálogo antes de poderem tornar-se um ficheiro. A origem é uma definição: pode apontá-la para outro catálogo, ou para um index.json no seu próprio disco, caso em que não é feito nenhum pedido de rede.

Sites de plugins que adiciona

Desde o FoxSDR 0.99.74, pode adicionar catálogos de plugins de outras pessoas, chamados sites de plugins, e cada um que adicionar é mais um endereço que a aplicação contacta. Só o utilizador adiciona um: prima SITES na barra superior da loja de plugins, cole um endereço e assinale a caixa que diz que o FoxSDR não analisou o site. O FoxSDR não adiciona nada nem contacta nada por iniciativa própria. Um site é lido nos mesmos dois momentos que o catálogo público — a primeira vez que abre a loja numa sessão e sempre que prime VERIFICAR AGORA — e tem alguns segundos para responder. O pedido leva o endereço que indicou e nada mais do FoxSDR: nenhum identificador, nenhum cookie e um nome de cliente (cascade-plugin-repo/1.0) igual em todas as cópias. Assim, o site vê o seu endereço IP, como qualquer servidor web.

Os ficheiros e as imagens de um plugin de um site são obtidos apenas do mesmo anfitrião do seu catálogo, e somente quando prime OBTER ou ATUALIZAR num dos plugins do site ou abre a respetiva página. O catálogo de cada site é guardado sem alterações na pasta de plugins do seu próprio disco, relido no arranque e apagado quando prime REMOVER no site; os endereços em si ficam no seu ficheiro de definições. As contagens de falhas do catálogo de plugins e das instalações de plugins (veja acima a secção sobre os relatórios de utilização) são as do catálogo público: um site que não pode ser alcançado, ou um plugin seu cuja instalação falha, não é contado.

Plugins disponibilizados apenas em alguns países

Alguns plugins são disponibilizados apenas a ligações de determinados países. Quando a aplicação obtém o catálogo de plugins, pede também a este site uma pequena lista regional, e um plugin dessa lista é transferido deste site em vez do GitHub. Para decidir o que responder, o site lê o código de país de duas letras que a Cloudflare envia juntamente com o pedido (CF-IPCountry), e que a Cloudflare deduz a partir do endereço de onde o pedido vem. O código de país e o endereço são usados apenas para essa resposta e não são guardados, não é enviado nenhum identificador seu, e estes pedidos não são registados nas estatísticas deste site. Uma ligação cujo país não pode ser determinado, ou que chega através do Tor, recebe uma lista vazia. Uma VPN altera o país que o site vê. A lista regional não é pedida quando configurou a loja para outro catálogo.

Um plugin que pode transmitir

Desde o FoxSDR 0.99.74, um plugin pode pedir para enviar áudio através do seu transmissor; a loja de plugins e a janela «Módulos montados» mostram-no então como «Pode transmitir através do FoxSDR». Só pode acionar o transmissor se tiver premido CONCEDER TRANSMISSÃO na página do plugin e armado a página TRANSMITIR durante 5, 15 ou 60 minutos. A concessão é guardada no seu próprio ficheiro de definições pelo nome de ficheiro do plugin e nunca é enviada para lado nenhum; a janela de armamento não é guardada de todo. O registo de diagnóstico na sua máquina anota o acionamento — tx: armed 15 min, tx: plugin <name> keyed, tx: plugin <name> unkeyed (<why>) e tx: disarmed (<why>) — como o nome declarado do plugin, um motivo de uma lista fixa e um número de minutos, nunca uma frequência, e essas linhas são higienizadas como qualquer outra linha do registo quando se prepara um relatório ou um pacote de diagnóstico. Os relatórios do próprio FoxSDR não têm nenhum campo para nada disto.

Conjuntos de elementos de satélites

O plugin de satélites mantém atualizados os seus conjuntos de elementos orbitais ao obtê-los das origens indicadas no seu satellite.cfg, a cada doze horas enquanto está carregado. Este site guarda uma cópia desses conjuntos de elementos em GET /tle/all.tle — os grupos de estações, de radioamadores e meteorológicos da CelesTrak, mais os NOAA 15, 18 e 19, atualizados aqui a cada doze horas — e o Satélites 1.0.4 e versões posteriores recorrem a este ficheiro por si próprios sempre que todas as origens em satellite.cfg falham, para que uma máquina que a CelesTrak recuse possa continuar a segui-los. O ficheiro não tem de indicar este site para que isso aconteça; uma linha com fallback-url none desativa essa alternativa, e refresh-hours 0 desativa todas as obtenções. O pedido não leva identificador, nem id de instalação, nem cookie, e este servidor não escreve nenhum registo de estatísticas para ele — tal como na verificação de atualizações, só são registadas as visualizações de páginas e as transferências de ficheiros, e o espelho não é nenhuma delas. Os conjuntos de elementos propriamente ditos são da CelesTrak (celestrak.org), e todas as respostas o indicam.

Consultas de registo de aeronaves

O plugin opcional Informação de aeronaves mostra quem é cada aeronave no mapa — a matrícula, o tipo e o operador. A aplicação nunca faz este pedido; é a instalação desse plugin que o ativa. A partir da versão 1.1.0, o plugin pergunta primeiro a este site, em GET /api/aircraft/<address>, e envia apenas o endereço ICAO de seis dígitos hexadecimais da aeronave — o número que a própria aeronave transmite — sem identificador, sem id de instalação e sem cookie. Cada aeronave é consultada uma vez e a resposta fica guardada na sua própria máquina, para não voltar a ser pedida. Só quando este site não conhece uma aeronave, ou não pode ser contactado, é que o plugin pergunta ao api.adsbdb.com, um serviço gratuito de terceiros, como as versões anteriores sempre fizeram. O conjunto de aeronaves que um recetor ouve é uma indicação aproximada de onde ele está, e é por isso que o plugin é opcional e o diz antes de o instalar.

O que este servidor guarda sobre uma consulta: nada por pedido. Não é escrito nenhum registo de estatísticas, e nem o endereço da aeronave nem o endereço de onde veio o pedido são registados. O único registo são cinco totais acumulados desde o último arranque do servidor — consultas, encontradas, não encontradas, malformadas e limitadas por taxa — que o painel mostra. Para impedir que alguém copie a tabela por atacado, cada endereço que se liga tem uma quota de consultas mantida em memória, exatamente como os outros endpoints daqui, e nunca escrita em disco; é esquecida quando o servidor reinicia ou quando estão a ser acompanhados mais de dez mil endereços, o que acontecer primeiro.

As respostas vêm da base de dados de aeronaves da OpenSky Network (opensky-network.org): para cada aeronave, a matrícula, o designador de tipo, o fabricante, o modelo e, quando registado, o operador. A OpenSky disponibiliza essa base de dados tal como está e pede aos utilizadores que citem: Matthias Schäfer, Martin Strohmeier, Vincent Lenders, Ivan Martinovic e Matthias Wilhelm, “Bringing Up OpenSky: A Large-scale ADS-B Sensor Network for Research”, em Proceedings of the 13th IEEE/ACM International Symposium on Information Processing in Sensor Networks (IPSN), abril de 2014. O proprietário registado que lá consta não é copiado para este site nem servido por ele, porque, no caso de uma aeronave privada, é o nome de uma pessoa; só o operador, que é uma companhia aérea, uma força aérea ou uma empresa, o é.

A interface no navegador

O FoxSDR pode servir a sua interface por HTTP a outras máquinas da sua própria rede. Está desligada por predefinição e limitada à sua própria máquina até alterar isso; é obrigatória uma palavra-passe para qualquer associação além dessa, e sem ela a associação mais ampla é recusada em vez de aberta. As palavras-passe são guardadas em hash (PBKDF2-HMAC-SHA256) e as sessões são revogadas sempre que as definições mudam. Não há TLS, de propósito, porque a aplicação não inclui nenhuma biblioteca criptográfica e não vai afirmar uma segurança de transporte que não pode oferecer — coloque um proxy inverso ou um túnel privado à frente dela, e nunca a exponha diretamente por reencaminhamento de portas. Qualquer pessoa a quem dê acesso pode ver e controlar o que o recetor está a fazer.

Pedidos de funcionalidades enviados a partir da aplicação

A aplicação tem uma caixa «Pedir uma função» na página principal, onde pode escrever o que gostaria que ela fizesse e premir Enviar. Nada é enviado até premir esse botão, nunca acontece automaticamente, e um pedido que não nos chegue não fica em fila nem é repetido em segundo plano — o que escreveu fica na caixa, apenas em memória, para voltar a premir Enviar, e nunca é escrito no ficheiro de configuração nem no registo. É isto, na íntegra, o que um pedido contém:

Vai para POST /api/feature-request neste site. O seu endereço IP é usado apenas para manter a taxa de envio num nível razoável, e nunca é escrito em disco — o registo efetivamente guardado é a sua mensagem, o seu endereço de contacto se indicou um, a versão da aplicação, a plataforma, a arquitetura e o seu país aproximado quando a nossa consulta o consegue obter a partir da ligação, e mais nada. É lido pelo responsável do projeto no painel de administração, atrás da mesma palavra-passe que tudo o resto aqui, e é guardado até ser apagado desse painel, ou até o pedir. Um pedido que tenha sido tratado — acrescentado ao FoxSDR, ou respondido de outra forma — pode ser arquivado aí em vez de apagado, para que o projeto possa acompanhar o que foi pedido e o que foi construído; um pedido arquivado continua guardado, com tudo o que está indicado acima. Se indicou um endereço de contacto e quer que o pedido seja apagado, escreva para o endereço abaixo e cite o suficiente do que enviou para que possa ser encontrado.

Relatórios de erros e de coisas de que não gosta enviados a partir da aplicação

Logo abaixo de «Pedir uma função», a aplicação tem uma caixa «Reportar erro / não gosto», onde diz que algo está avariado ou que há algo de que não gosta, e prime Enviar. Funciona exatamente como a caixa de pedidos de funcionalidades: nada é enviado até premir esse botão, nada fica em fila nem é repetido em segundo plano, e o que escreveu fica apenas em memória — nunca no ficheiro de configuração, nunca no registo. Não é um relatório de falha, embora o registo de diagnóstico descrito abaixo passe pelo mesmo filtro e possa conter parte do que um relatório de falha contém. É isto, na íntegra, o que um relatório contém:

A partir do FoxSDR 0.99.69, o registo de diagnóstico inclui ainda mais uma linha, que indica apenas pelo nome de ficheiro (nunca uma pasta ou uma versão) os componentes de outros programas carregados no FoxSDR — uma sobreposição ou um hook que outro programa aí colocou; é a mesma lista que a tabela do relatório de falhas acima descreve, e faz também parte do relatório de falha ou de bloqueio que o FoxSDR envia automaticamente.

Vai para POST /api/problem-report neste site. O seu endereço IP é usado apenas para manter a taxa de envio num valor razoável e nunca é escrito em disco — o registo efetivamente guardado indica se foi um erro ou uma crítica, a sua mensagem, o seu endereço de contacto, se o indicou, a versão da aplicação, a plataforma, a arquitetura, o seu país aproximado quando a nossa consulta o consegue obter a partir da ligação, e o registo de diagnóstico se o deixou anexado, o tipo de qualquer relatório reconhecido na sua mensagem (acima), e nada mais. É lido pelo responsável do projeto no painel de administração, protegido pela mesma palavra-passe que tudo o resto aqui, e um relatório é mantido até ser eliminado desse painel, ou até o pedir. Um relatório que já foi tratado — corrigido no FoxSDR, ou respondido de outra forma — pode ser arquivado aí em vez de eliminado; um relatório arquivado continua guardado, com tudo o que foi indicado acima. Se indicou um endereço de contacto e quer que o relatório seja eliminado, escreva para o endereço abaixo e cite o suficiente do que enviou para que possa ser encontrado.

O site: o que é registado quando o visita

É escrito um registo por cada visualização de página e cada transferência, quer aceite cookies quer não. São estatísticas próprias: os dados ficam no servidor que serve este site, não são partilhados com nenhuma rede de publicidade e não há nenhum script de terceiros na página.

O que deliberadamente não é feito

• Nenhuma impressão digital do navegador: nenhuma sondagem de canvas, áudio, tipos de letra ou WebGL, e nada que tente voltar a identificá-lo depois de ter recusado.
• Nenhum rastreador de terceiros, pixel de publicidade, widget de redes sociais ou serviço de estatísticas. Nada nesta página é carregado de outro domínio.
• Nenhuma tentativa de ler a sua área de transferência, a sua bateria, a sua câmara, o seu microfone, as suas palavras-passe guardadas ou o seu histórico de navegação — nada que diga respeito a uma página de transferências.
• Os seus dados não são vendidos, alugados nem partilhados com ninguém. O único pedido externo que o servidor faz sobre si é a consulta de localização a partir do IP descrita acima.

Designs de interface que publica

Este site pode guardar um design de interface do FoxSDR — um pacote .foxui — que decida publicar. Nada é enviado até premir Publish, e o envio vai para POST /api/gui/publish. O que é guardado é o que o pacote contém: o próprio design, o nome, a versão e a descrição que escreveu, um nome de autor, se tiver escrito um, a hora da publicação e um identificador aleatório. O seu endereço IP é usado apenas para manter o ritmo de publicação dentro do razoável, e nunca é gravado em disco. Um pacote publicado não aparece em nenhuma lista; qualquer pessoa que tenha a ligação pode transferi-lo. É guardado até ser eliminado do painel de administração, ou até o pedir — escreva para o endereço abaixo e indique a ligação.

Se se inscrever como testador da beta

O formulário da beta e a inscrição nas novidades são os únicos sítios onde este site lhe pede alguma coisa, para além da publicação de um design de interface (ver acima). Enviá-lo guarda o seu endereço de email e aquilo que tenha escolhido indicar de entre o seguinte: um nome ou indicativo, a sua plataforma, o rádio que tenciona usar, as suas notas e a lista de funcionalidades que se ofereceu para testar. Junto com isso guardamos o mesmo contexto de visita descrito acima — localização aproximada, rede, navegador e sistema operativo — porque um relatório de erro lê-se de forma muito diferente consoante a configuração de onde veio.

• O endereço é usado para uma única coisa: contactá-lo sobre compilações beta e sobre o que testar. Sem newsletter, sem marketing, e nunca é passado a mais ninguém.
• Nada acontece até confirmar. A inscrição envia um email com um código de seis dígitos, que escreve na página para confirmar que o endereço é seu. O código é válido durante 30 minutos e é recusado depois de cinco tentativas erradas. Até ser introduzido, a inscrição fica inativa: não está na lista de testadores, não é contado e nunca mais é enviado nada. Se outra pessoa escreveu o seu endereço, ignore esse email e a inscrição nunca se torna real — não há nada de que cancelar a subscrição e nenhuma ação que tenha de tomar. Essa mensagem é o único email automático que uma inscrição pode gerar.
• Se nos escreveu, podemos convidá-lo. Alguém que nos tenha escrito e deixado um endereço — através da caixa de sugestões da aplicação, por exemplo — pode receber de nós um convite pessoal, com uma ligação de utilização única que abre a tecla Confirmar deste site. Esse convite fica guardado como uma inscrição pendente, exatamente como uma inscrição não confirmada: não é testador nem é contado a menos que prima Confirmar, e se o ignorar não voltamos a escrever-lhe. Uma inscrição pendente não expira por si própria; é apagada quando a retiramos da lista ou quando o pedir, com um email para o endereço abaixo.
• Depois de confirmar, recebe a sua ligação de gestão privada, e escrevemos-lhe quando chegar uma compilação que precise do que se ofereceu para testar. É uma pessoa a escrever-lhe, não uma lista de correio. Se perder a ligação, podemos emitir uma nova: a antiga deixa de funcionar de imediato, a nova é-lhe enviada por e-mail, e guardamos quando isso foi feito e se o e-mail foi enviado.
• Esse email passa pela Apple. O correio de foxsdr.com é transportado pelo serviço iCloud Mail da Apple, por isso o seu endereço e a mensagem passam pelos servidores da Apple a caminho de si, nos termos da Apple enquanto nosso fornecedor de correio. Nada mais sobre si lhes é enviado.
• Fica separado das estatísticas. As inscrições ficam num ficheiro próprio, legível apenas pela conta que corre o servidor; o registo de estatísticas indica que uma inscrição aconteceu e quantas funcionalidades foram escolhidas, nunca quem. Um teste automático faz falhar a compilação se algum endereço chegar ao registo de estatísticas.
• Inscrever-se de novo com um endereço que já está na lista não altera essa inscrição. As alterações fazem-se na sua própria página de testador. Em vez disso, o endereço recebe um e-mail: a respetiva ligação privada, se já estiver confirmado, ou um código novo, se não estiver, e nunca mais de uma vez em cada 15 minutos.
• Guardamos uma cópia do que lhe enviámos. Todas as mensagens que este site envia a um testador — a confirmação e cada mensagem sobre uma compilação — são guardadas com o respetivo texto, para podermos ver o que foi dito e se chegou. A cópia é arquivada com o seu id interno, não com o seu endereço, e as partes pessoais (o código ou a ligação de confirmação e a sua própria ligação de gestão) são removidas antes de ser guardada, para que uma mensagem guardada nunca possa ser usada para agir em seu nome. Estas cópias são apagadas com o resto da sua inscrição quando sair.
• As mensagens entre si e nós são guardadas. A caixa Mensagens do seu portal de testador é uma conversa com a pessoa que desenvolve o FoxSDR: o que lhe escrevemos e o que responde, cada uma com a hora em que foi escrita e, se escolheu um, o relatório a que diz respeito. É arquivada pelo seu identificador interno, não pelo seu endereço, e só o utilizador (com a sua ligação privada) e nós a podemos ler. Registamos também quando teve as nossas mensagens no ecrã, para sabermos que lhe chegaram. Enquanto a sua página estiver aberta, pede novas mensagens de poucos em poucos segundos, pelo que aparecem assim que são escritas, e indica há quanto tempo a usou pela última vez; enquanto continuar a pedir, e meio minuto depois, e só se a tiver usado nos últimos cinco minutos, o servidor sabe que está lá. Isso fica apenas na memória dele e nunca é gravado. Não lhe enviamos um e-mail por cada mensagem: quando escrevemos enquanto não está, recebe um único e-mail curto a dizer que há uma mensagem à espera, com a sua ligação e sem a mensagem em si. Enquanto essa mensagem não for lida, não segue nenhum outro e-mail destes durante até 12 horas, nem dentro de meia hora do anterior; e se estava na página quando escrevemos mas dez minutos depois ainda não viu a mensagem, o e-mail segue nessa altura. Uma cópia desse e-mail é guardada como descrito acima; quando escreve, não é enviado nenhum e-mail. A conversa é guardada até sair ou nos pedir que a apaguemos, e sair apaga-a por completo.
• Guardado até ao fim do programa beta, ou até o pedir. Um email para o endereço abaixo retira-o da lista e apaga a inscrição — não tem de dar nenhuma razão.
• A base jurídica aqui é o seu consentimento, dado ao assinalar a caixa; o formulário não é enviado sem ele.

Se é testador beta e introduz o seu código de testador no FoxSDR

A sua página de testador (acima) dá-lhe um link privado de gestão e, a partir dele, um código de testador que pode introduzir no próprio FoxSDR, em SISTEMA → Código de testador. Isto é diferente do relatório de utilização anónimo descrito acima: o relatório de utilização não pode ser associado a si, de propósito, enquanto uma sessão relatada com o seu código de testador fica associada à sua ficha de testador por design — esse é precisamente o objetivo, para podermos ver que funcionalidades e plugins quem realmente os testa experimentou. Está desativado a menos que introduza um código, e o campo está vazio por definição.

Associar o FoxSDR, na sua página de testador, dá ao FoxSDR um código da aplicação separado, para que a sua ligação privada nunca tenha de ser introduzida na aplicação. O código da aplicação só pode fazer duas coisas: enviar os relatórios de sessão descritos abaixo, e enviar e ler as mensagens da sua caixa de Mensagens. Não pode ver o seu endereço, alterar a sua inscrição nem removê-lo. É guardado com a sua inscrição de testador; premir Nova ligação anula-o, e depois o FoxSDR tem de ser associado novamente, e sair do programa apaga-o com o resto da sua inscrição.

Enquanto um código estiver introduzido, aproximadamente uma vez por sessão o FoxSDR envia isto, e mais nada:

• O que é guardado é o seu ID de tester (nunca o seu código ou endereço), a hora em que o relatório foi aceite, o início de sessão indicado acima, a versão, a plataforma, a duração da sessão, e as funcionalidades, plugins e rádios listados acima — uma linha por cada sessão aceite, guardada até um ano e depois removida automaticamente, contada a partir do início real da sessão, não de quando o relatório chegou a este servidor.
• O que é mostrado publicamente é uma contagem, nunca um nome. O cartão de um plugin na página inicial ganha uma pequena nota “testado por N testadores beta” assim que a sua versão atual publicada tiver sido usada por pelo menos dois testadores distintos durante pelo menos dez minutos somados — abaixo disso, nada é mostrado, e nenhuma página indica quem são esses testadores. As contagens na sua própria página de testador e no painel de administração são os mesmos valores, vistos com mais detalhe; os testadores nunca são identificados uns aos outros.
• O seu endereço IP é usado apenas para manter a taxa de envio a um nível razoável, e nunca é gravado em disco.
• Como o interromper: remova o código de testador das definições do FoxSDR, e nada mais é enviado. Não precisa de abandonar o programa beta para isso.
• Abandonar o programa apaga-o. Remover a sua ficha, a partir da sua página de testador ou pedindo-nos, apaga todos os relatórios de sessão já registados para si juntamente com o resto da sua ficha — o mesmo apagamento descrito no resto desta secção, aplicado também a estes dados.
• A base legal é o mesmo consentimento que cobre o resto da sua ficha de testador: introduzir o código é uma ação sua, e nada é enviado sem ela.

Se se inscrever nas novidades por email

A página de novidades pede uma coisa: o seu endereço de email. É guardado para lhe podermos enviar um email quando houver uma nova versão do FoxSDR e, de vez em quando, sobre o que está a ser construído. Não é usado para mais nada e nunca é passado a ninguém.

• Nada acontece até confirmar. A inscrição envia um email com um código de seis dígitos para escrever na página. Até ser introduzido, não é enviado mais nada, e um endereço que não tenha sido confirmado no prazo de uma semana é apagado - por código que corre no servidor todos os dias. Se outra pessoa escreveu o seu endereço, ignore esse email.
• Cada email tem uma ligação que o retira da lista com um só clique. Sair apaga o endereço do ficheiro do servidor, juntamente com as cópias que guardámos do que lhe foi enviado; nada sobre ele é guardado.
• É uma lista à parte. Um subscritor das novidades não é um testador da beta: o endereço é guardado num ficheiro separado, legível apenas pela conta que corre o servidor, e não é contado nem mostrado como testador. Se também for testador, recebe cada mensagem uma só vez.
• Guardamos uma cópia do que lhe enviámos, arquivada com um id interno e não com o seu endereço, com o código de confirmação e a ligação para cancelar a subscrição removidos, exatamente como para os testadores.
• Esse email passa pela Apple, como descrito acima para os testadores.
• O registo de estatísticas indica que uma inscrição aconteceu, nunca quem.
• A base jurídica é o seu consentimento, dado ao assinalar a caixa; o formulário não é enviado sem ele.

Cookies

Se recusar, não é definido nenhum cookie identificador. As visitas passam então a ser agrupadas por um hash do seu endereço e navegador que muda todos os dias, o que distingue os visitantes para efeitos de contagem e não serve para o seguir de um dia para o outro nem entre sites. Pode mudar de ideias se limpar os cookies deste site e recarregar a página.

Que idioma vê

As páginas podem ser mostradas noutros idiomas além do inglês. Qual recebe é decidido no servidor para cada página que pede, por esta ordem: um idioma que tenha escolhido por si (o cookie foxsdr_lang acima, ou ?lang= na ligação); caso contrário, os idiomas que o seu navegador diz preferir, a partir do seu cabeçalho Accept-Language; caso contrário, o idioma principal do país de onde vem a sua ligação, que a Cloudflare, a rede à frente deste site, envia com o pedido como um código de país de duas letras (CF-IPCountry); caso contrário, inglês. Nada é guardado para fazer essa escolha: o cabeçalho e o código de país são lidos para essa resposta e não são guardados por causa dela. São as mesmas duas coisas que a tabela acima já indica como registadas em cada visualização de página, onde o código de país é usado quando a nossa própria consulta de endereços não tem resposta. As traduções são feitas por máquina e, neste aviso e nas licenças, o texto em inglês é o que vincula.

Porquê, e com que fundamento

A finalidade é restrita: saber quantas pessoas encontram este projeto, mais ou menos onde estão, em que o usam e quantas acabam por transferi-lo. É isso que decide se o trabalho continua e o que é construído a seguir.

Os registos do lado do servidor são guardados com base no interesse legítimo em compreender e proteger o site. Os detalhes comunicados pelo navegador e os cookies identificadores são guardados com base no seu consentimento, e é por isso que estão por trás do aviso e que recusar não lhe custa nada neste site.

Durante quanto tempo é guardado, e quem o vê

Os registos são guardados durante 24 meses e depois apagados. Estão num ficheiro no servidor, por trás de um painel protegido por palavra-passe que só o responsável do projeto pode abrir. Não há outros destinatários nem nenhuma transferência para um país terceiro além da consulta de IP já descrita.

Há duas coisas guardadas durante menos tempo. Os relatórios de falha e de bloqueio são apagados 90 dias depois de a avaria que descrevem ter sido vista pela última vez, e os relatórios de utilização que a Cloudflare trata são apagados ao fim de três meses. Cada um desses prazos é aplicado por código que corre no servidor todos os dias, e não por alguém se lembrar de o fazer.

Os seus direitos

Se estiver no Reino Unido ou na UE, pode pedir uma cópia do que se guarda sobre si, pedir que seja corrigido ou apagado, ou opor-se a que seja sequer recolhido — incluindo os registos do lado do servidor que não dependem do consentimento. O identificador prático para encontrar os seus registos é o seu endereço IP no momento da visita, por isso indique-o, bem como a altura aproximada em que visitou o site.

No caso da aplicação, os controlos estão no próprio software, e são três:

• SISTEMA → Relatório de utilização desliga o relatório de utilização e o sinal de cinco em cinco minutos, e apaga o identificador de instalação. Se o voltar a ligar mais tarde, recebe um novo identificador que não pode ser associado ao antigo.
• SISTEMA → Diagnóstico impede que os relatórios de falha e de bloqueio sejam escritos ou enviados.
• SISTEMA → Atualizações desliga a verificação de atualizações (numa cópia da Microsoft Store, a pergunta à Microsoft Store).

Os relatórios não contêm nada que possa ser associado a si, por isso não há nada a que pedir acesso; se quiser que um identificador de instalação seja removido de relatórios já enviados, escreva para o endereço abaixo e indique-o, e será apagado.

Crianças. O FoxSDR é um instrumento técnico para amadores de rádio. Não se destina a crianças, não recolhe informações pessoais de ninguém e, por isso, não recolhe nenhuma de crianças.

Escreva para [email protected]. Também pode apresentar queixa ao Information Commissioner's Office (ico.org.uk) se considerar que isto foi mal tratado.

Última atualização: 28 de setembro de 2026, face ao FoxSDR 0.99.42 — a compilação que este site oferece atualmente, e aquela com cujo código-fonte todas as afirmações acima foram verificadas. O FoxSDR é publicado por Steven Fox; escreva para o endereço acima com qualquer pergunta sobre este aviso ou para que um identificador de instalação seja apagado de relatórios já enviados. Se este aviso deixar alguma vez de corresponder ao que o software faz, é o software que está errado — a recolha do site está implementada em store.go e app.js, ambos legíveis no próprio código-fonte do site, e a lista da própria aplicação é distribuída com ela como PRIVACY.md, com um teste que vincula a ela o conteúdo enviado.