Política de privacidade

Vale para o site e para o aplicativo, ambos em snapfork.app. Atualizado em 24 de setembro de 2026.

O que o servidor guarda

Só aquilo sem o que o acesso, a sincronização e a correspondência com o desenvolvedor não funcionam:

Onde fica o servidor. O servidor, o banco de dados e as cópias de segurança dele rodam no provedor de hospedagem Railway (Estados Unidos), na região de Singapura. Por isso, os dados de pessoas da União Europeia e do Reino Unido ficam armazenados fora delas.

O que acontece com o seu diário

O seu diário mora tanto no seu aparelho quanto no servidor — mas no servidor ele é criptografado. Entradas, prévias das fotos e registros de peso moram no armazenamento do seu navegador, e uma cópia lacrada vai para o servidor: a chave dela existe só no seu aparelho. O servidor consegue ver que entradas foram acrescentadas e quando — e não consegue ver o que você comeu, quanto, nem quanto você pesa.

Nós também não conseguimos ler o seu diário. Não é uma promessa de bom comportamento; é assim que o sistema é construído — nós não temos a chave. O que traz um preço que você deve saber antes: perca o código de recuperação junto com o aparelho e ninguém consegue trazer o diário de volta, nem nós. Não haveria de onde restaurá-lo. O código aparece nas Configurações, em “Dados” — anote e guarde em algum lugar que não seja o seu celular.

O servidor também guarda as versões em conflito — e isso é a seu favor. Se uma entrada foi editada em dois aparelhos, vale a edição mais recente, e a que perdeu não é jogada fora: ela fica no servidor por um mês, lacrada do mesmo jeito, e o aplicativo pode mostrá-la a você. Senão, «se consertou sozinho» seria a nossa palavra contra a sua memória. Nós também não conseguimos lê-la, claro — ela está no mesmo envelope de todo o resto.

As configurações só vão para o servidor se você ligar a sincronização delas. Metas, perfil (nome, sexo, ano de nascimento, altura, nível de atividade, objetivo, ritmo, peso-alvo, o que levar em conta e o que você não come), meta de água, divisão das refeições, funções do diário, configurações de alimentação, o registro de ajustes da meta, ações rápidas, unidades, o tema do cartão de compartilhamento e duas chaves — uma avaliação de produto oculta e uma busca na base aberta desligada — viajam num só envelope, lacrado com a mesma chave do diário. Parte disso citamos à parte, porque pode dar pistas sobre a sua fé ou a sua saúde: o conjunto pronto e as metas de alimentação (por exemplo, «À base de plantas» ou «Sem álcool»), a lista do que você não come e as suas próprias palavras nas configurações de alimentação — palavras de alerta e exceções — viajam no mesmo envelope, lacradas do mesmo jeito. Isso é ligado por uma chave própria na seção «Dados»; até você ligar, as configurações não são enviadas a lugar nenhum. Desliga-se no mesmo lugar — a cópia do servidor é apagada na hora, e a sincronização é desligada em todos os seus aparelhos. O servidor vê que o envelope existe, quando mudou, qual o tamanho dele e quando a sincronização foi desligada — e não o que está dentro. O tema do app, o idioma, os lembretes, a conexão com o Apple Saúde e a sua própria chave de provedor de reconhecimento nunca saem do aparelho: eles pertencem ao aparelho, não a você.

Seu país de residência, se você escolheu um, fica salvo neste aparelho. Ele vai no arquivo de backup junto com o idioma e é apagado com as suas outras configurações pessoais quando outra pessoa passa a usar o aparelho. Ele não faz parte do envelope de sincronização das configurações, e não o deduzimos do endereço IP nem do idioma da interface. Ao nosso servidor o código do país vai como campo do pedido só com um pedido de reconhecimento pela chave do Snapfork e só com o interruptor “Levar meu país em conta” ligado — de passagem, lá ele não fica (veja “Para onde os dados vão, sim”). A linha «Sugerido pelo aparelho» na escolha do país é calculada no próprio aparelho — pela região do sistema, pelo fuso horário ou pela região nas configurações de idioma do navegador — e não escolhe nada sozinha.

Um arquivo de backup continua sendo exportado e guardado por você. Ele não é criptografado, e é o único jeito de ler o seu diário sem o código.

Não pedimos aos provedores de acesso o seu nome, sobrenome nem foto de perfil — só a confirmação do endereço de e-mail. Um nome que você mesmo digitar no perfil só chega ao servidor dentro do envelope lacrado das configurações, e só se a sincronização das configurações estiver ligada; nós não conseguimos lê-lo.

O backup do seu próprio aparelho

Isto é sobre o aplicativo para iPhone. Ele ainda não está na App Store, e o que segue descreve como ele vai se comportar quando sair. O site não tem nada disso: num navegador não há contêiner de app nem esse tipo de backup.

Um backup do iPhone leva os dados dos apps para o iCloud — é assim que o backup funciona, não é algo que o nosso app faça. Se o seu diário entra nele é decisão sua, e por padrão ele não entra. Você é perguntado na primeira abertura e pode mudar a resposta a qualquer momento: Configurações → “Dados” → “Diário no backup do iCloud”.

O que se descreve aqui é o mecanismo, não o resultado, e isso não é evasiva: depois que você responde, a frase “o meu diário está no iCloud” é verdadeira para alguns leitores e falsa para outros. Diga sim e o backup é feito e guardado pela Apple, pelas regras da Apple — é a cópia dela, não a nossa: nós não a vemos nem conseguimos abri-la. Diga não, ou não diga nada, e a pasta do app é marcada como excluída do backup, então o diário não vai para lá.

Nada disso mexe no arquivo de backup que você mesmo exporta: esse você faz e guarda onde quiser. O que entra nele vindo dos amigos está descrito em Amigos.

Respostas de saúde

O app tem uma seção “Prevenção” — material de referência sobre recomendações publicadas de check-ups preventivos, selecionadas por idade, sexo e as suas respostas. Essas respostas são dados de saúde, e nós as tratamos com mais rigor do que o diário. A seção só abre depois de um consentimento à parte na tela de introdução; enquanto você não o der, ela não salva nada.

O que fica guardado. Onde você é atendido (o país); se você fuma, parou ou nunca fumou — com os maços-ano e o ano em que parou; se planeja uma gravidez; quais itens por órgão se aplicam a você; as marcas “feito” com o mês e o tipo de exame; os itens adiados; o botão “Nada sobre emagrecer” e quando você deu o consentimento. Do perfil, a seção lê o ano de nascimento, o sexo, o objetivo e a lista “O que você não come” — mas não o seu peso. Diagnósticos, histórico familiar e resultados de exames a seção não pergunta nem guarda.

Onde. No seu aparelho, no armazenamento do app. No app para iPhone, as respostas ficam lacradas com uma chave que só existe naquele telefone e não entra em nenhum backup: num backup do iCloud elas só entram lacradas, e em outro telefone nada consegue abri-las — lá a seção começa do zero. No navegador, as respostas ficam no armazenamento dele, como o diário.

Para o servidor — só lacradas e só se você decidir. As respostas de saúde vão para o servidor só se você ligar a sincronização delas entre aparelhos, e então lacradas com uma chave que só existe nos seus aparelhos, como o diário e as configurações. Essa sincronização tem o próprio botão e o próprio consentimento; vem desligada por padrão e só funciona dentro da sincronização das configurações — mas ligar esta não liga aquela. Se você informou que é atendido na Rússia, as respostas não vão para o servidor nem com a sincronização ligada.

Para onde nunca vão. Nem para o modelo de linguagem, nem para os amigos, nem para os dados do aparelho anexados a uma mensagem ao suporte. No arquivo de backup (o botão “Exportar JSON”) elas não entram por padrão: uma caixa de seleção à parte as inclui — e aí lembre que esse arquivo não é criptografado.

Ocultar, desligar a sincronização, apagar — três ações diferentes. “Ocultar a seção” tira a seção de vista e não mexe nas respostas. “Desligar e apagar as respostas do servidor” apaga a cópia do servidor, e os seus outros aparelhos apagam a deles na próxima sincronização; neste aparelho as respostas ficam. “Apagar as respostas deste aparelho” apaga as respostas aqui e, com a sincronização ligada, na próxima sincronização também no servidor e nos seus outros aparelhos; junto com as respostas, o consentimento é retirado, e a seção recomeça pela tela de introdução. Excluir a conta leva a cópia do servidor junto com todo o resto; quanto tempo vivem os backups do banco de dados está em Por quanto tempo cada coisa é guardada.

Para onde os dados vão, sim

Fotografias de refeições, embalagens ou rótulos são enviadas para reconhecimento, e por onde elas viajam depende de qual chave assina o pedido. São dois caminhos, e a escolha é sua:

O aplicativo começa pela sua própria chave e só passa para a nossa depois que a sua falha — ou vai direto para a nossa se o modelo que você escolheu não olha fotografias. Esse é o padrão, e uma opção nas configurações o desliga — aí a fotografia nunca passa pelo nosso servidor, em nenhuma circunstância.

Comida em palavras, e recalcular a partir de uma descrição. Quando você descreve uma refeição em texto, o texto que você digitou é enviado para reconhecimento pelos mesmos dois caminhos de uma fotografia, para que o modelo estime calorias, proteínas, gorduras e carboidratos. Quando você pede ao aplicativo para recalcular os números de um item a partir da descrição dele, a descrição do item — o que diz o campo de nome — vai para o modelo do mesmo jeito. A descrição de uma refeição também leva o peso total dela, se você o informou, e os nomes de produtos da sua biblioteca junto com quanto de cada um você costuma comer (a porção em gramas), que ajudam o modelo a reconhecer o que ele já conhece e a julgar o peso; os mesmos nomes da biblioteca, com as porções em gramas, vão também com a fotografia de um prato. A descrição de uma refeição, assim como uma fotografia, leva também o idioma da interface, para que o modelo nomeie os pratos nele. O texto não fica guardado aqui, assim como a fotografia: só fica a linha de números.

Seu país de residência, se você escolheu um. Uma foto, um rótulo ou uma descrição de uma refeição levam também, junto com o idioma da interface, o código de duas letras do seu país, para que o modelo reconheça pratos locais e tamanhos de porção. Com a chave do Snapfork, o código do país vai pelo nosso servidor até a plataforma de reconhecimento; com sua própria chave vai direto para a plataforma, sem passar por nós. Nosso servidor só o repassa: como com uma foto, no log de chamadas ficam só o modelo, os tokens e o custo. O recálculo de um item e a classificação de produtos por grupos nunca recebem o país, e sua lista “Não como” nunca vai para o modelo. Isso se desativa com o interruptor “Levar meu país em conta” na seção “Reconhecimento de comida”.

O texto da sua busca de produtos — se você tocou em “Buscar na base aberta”. O aplicativo tem uma tela de Produtos: ela busca nos seus próprios produtos e no catálogo baixado no seu aparelho, e tudo isso acontece sem rede nenhuma. Quando o catálogo não tem o que você procura, aparece um botão “Buscar na base aberta” embaixo da lista. Com esse toque — e só com ele — o que você digitou no campo de busca sai do seu aparelho para o Open Food Facts, sem passar pelo nosso servidor: nós nem vemos esse texto nem o guardamos. Não há autocompletar enquanto você digita nem pedido em segundo plano: sem o toque, nada sai.

Nada mais vai junto com esse texto: nenhuma entrada do diário, nenhuma fotografia, nenhum peso, nenhum identificador de conta — o pedido não precisa de nada disso, e o aplicativo não acrescenta nada. A partir daí valem os termos do Open Food Facts, não os nossos. Uma opção desliga isso: Configurações → Produtos por código de barras → “Buscar na base aberta com um toque”; desligada, ela tira o próprio botão, e nada sai. Procurar um produto pelo código da embalagem, e buscar no catálogo baixado, nunca vão à rede — nem com a opção ligada nem desligada.

O aplicativo baixa a base de produtos do nosso servidor como o arquivo de um país, e o endereço do arquivo nomeia esse país (por exemplo, /products/de.2026-09-24.csv). Por isso o país da base baixada, junto com o seu endereço IP, fica visível para o nosso servidor, para a rede da Cloudflare por onde passam todas as requisições a snapfork.app e nos registros da nossa hospedagem Railway, que guarda essas entradas de 7 a 30 dias. A requisição sai sem o cookie de login: não temos como ligar o download a uma conta. A base só é baixada pelo botão em Configurações; depois, a busca nela funciona sem rede.

Os e-mails com o código de acesso passam pelo provedor de e-mail escolhido pelo responsável pelo serviço. Além do que está listado aqui, nada é repassado a ninguém: não há análise, nem publicidade, nem script de terceiros no site ou no aplicativo.

No próprio e-mail, o provedor acrescenta um contador de abertura — uma pequena imagem carregada do servidor dele quando o e-mail é aberto. Por ela ele sabe que o e-mail foi aberto e quando; os programas de e-mail que baixam as imagens direto também mostram a ele o endereço de onde o e-mail foi lido. No nosso plano isso não pode ser desligado. O e-mail do jeito que nós o montamos não tem imagem nem link nenhum.

O contador de visitas

O site conta as visitas por conta própria, sem cookies e sem scripts de mais ninguém. O que chega à base são números diários: página, idioma, de onde veio a visita. Nem o endereço IP nem o User-Agent são guardados de forma nenhuma — eles viram uma chave com um sal diário, e o próprio sal não é gravado em lugar nenhum, então nem nós conseguimos cruzar dois dias. O cabeçalho Sec-GPC é respeitado: com ele, nada é contado.

Correspondência com o desenvolvedor

As configurações do aplicativo têm uma seção “Suporte”: você pode escrever sobre algo quebrado ou algo que falta, e receber a resposta no mesmo lugar. É uma conversa, não um formulário — o que significa que ela fica guardada no servidor: senão não haveria onde responder.

O que fica guardado é o texto das suas mensagens e as respostas do desenvolvedor, ligados à sua conta. Só os leem aqueles cujos endereços confirmados o responsável pelo serviço colocou na lista de desenvolvedores: a lista é fechada, fica nas configurações do servidor, e ninguém mais vê a correspondência. Ao lado dela não há endereço de e-mail nem nome — o servidor, de todo modo, não os guarda em texto simples —, e a conversa é mantida com um diário, não com uma pessoa.

Os dados do aparelho só são anexados se você marcar a opção, e antes de enviar você vê exatamente o texto que vai viajar: a versão do aplicativo e da base de dados, a plataforma e o navegador, o idioma, o tamanho da janela, a tela de onde você escreve e o código da falha, se você veio de uma, quantas entradas e pesagens você tem como números simples, se o aparelho estava com rede, se o app foi aberto pelo ícone ou numa aba do navegador, se o modo de depuração está ligado e se há uma chave de plataforma definida — “sim” ou “não”, nunca a chave em si. Nenhuma entrada do diário, fotografia, registro de peso ou campo do perfil vai ali.

O e-mail de aviso que chega ao desenvolvedor não contém nem o texto da mensagem nem o seu identificador: só “há uma mensagem nova na conversa”. O conteúdo da correspondência nunca chega ao provedor de e-mail e nunca aparece nos registros do servidor.

Links de convite

O aplicativo pode dar a você um link de convite permanente. Se alguém se cadastrar por ele, vocês dois ganham reconhecimentos extras com a nossa chave — nada mais muda, e ninguém ganha acesso ao diário de outra pessoa.

O que fica guardado é o fato de que uma conta chegou pelo link de outra: qual link, quando e se a recompensa foi ganha. É um registro de uma ligação entre duas pessoas, então é guardado no mínimo e não é mostrado a ninguém: quem convidou só vê números — quantos chegaram, quantos voltaram, quantos reconhecimentos recebeu. Nem nome, nem endereço, nem momento de acesso. Não dizemos quem aceitou, porque isso seria contar a um terceiro que uma pessoa específica começou a manter um diário alimentar.

O link em si traz um código e nada sobre você. Abri-lo é contado pelo contador de visitas como uma campanha própria — só o rótulo: o código nunca chega ao contador, senão os números diários virariam uma tabela de quais links funcionam.

Excluir uma conta remove o link e o registro de onde aquela conta veio; os lançamentos de recompensa ficam, sem o identificador da conta, porque é por eles que se contam os limites de quanto pode ser dado.

Os lançamentos de recarga se comportam do mesmo jeito: excluir uma conta os deixa no lugar, mas eles param de nomear alguém. O motivo não é contabilidade, e sim você — um banco pode contestar um pagamento um mês depois de a conta sumir, e sem valores não haveria com o que responder a essa contestação. O saldo que sobrar é queimado na exclusão, e isso é registrado como um lançamento próprio: o dinheiro pelo qual nenhum serviço foi prestado fica visível como exatamente isso, em vez de se dissolver na receita.

Amigos

Se você convida um amigo e ele aceita, algo derivado do seu diário começa a sair do seu aparelho — e são exatamente dois fatos por dia dos últimos sete dias: se você anotou alguma coisa e, se você compartilhou isso à parte, se você ficou dentro da sua própria meta. Além disso, há quantos dias seguidos você anota. Não o que você comeu, não quantas calorias, não o seu peso — nada disso sai, em nenhum nível de compartilhamento.

O compartilhamento é igual nos dois sentidos e em cada nível: você vê a semana de um amigo só se compartilhou a sua semana com ele, e o fato da meta dele só se também compartilhou a sua meta; o seu amigo vê de você exatamente tanto quanto você vê dele: o seu aparelho mostra a semana de um amigo só com consentimento mútuo. O fato da sua meta vai para o seu amigo num envelope criptografado sempre que você compartilhou a sua meta com ele, mas é mostrado a ele só se ele também compartilhou a meta dele com você. O consentimento é pedido por amizade e por nível, e registramos com qual texto você concordou: se o sentido desse texto mudar, perguntamos de novo em vez de ampliá-lo em silêncio. Dá para desfazer em qualquer dia, e há dois botões: “parar de compartilhar” mantém a amizade, “apagar a amizade” remove a ligação e apaga o que cada um viu do outro.

Há uma exceção — o arquivo de backup que você mesmo exporta: ele não é criptografado, e leva a semana do seu amigo — exatamente o que você viu dele. As respostas não estão nele. Apagar uma amizade apaga o que foi visto aqui e no aparelho, mas não chega aos arquivos que você já salvou: o que acontece com eles depende de você.

Há um terceiro botão para quando encerrar não basta: uma recusa. Depois dela, um novo convite daquela pessoa não passa — senão “apagar a amizade” só quereria dizer “até o próximo convite”. Para isso o servidor guarda uma lista das pessoas que você recusou: identificadores e uma data, sem motivo e sem uma palavra sua; ela dura até você desfazer. Não contamos ao outro lado — quem foi recusado vê exatamente o que veria depois de um encerramento comum: não há amizade. Essa lista fica de fora de propósito da exportação “O que o servidor guarda sobre você”: é um arquivo que você pode encaminhar a alguém.

Não conseguimos ler nada disso — desde que a chave seja autêntica. O conteúdo viaja lacrado com uma chave que não temos, todo envelope tem o mesmo tamanho, e nem o tamanho revela quantos dias há dentro. Mas algumas coisas nós vemos, sim, e dizemos isso com clareza:

O que não vemos: o que está dentro, quanto há lá, como você chamou o seu amigo no seu próprio aparelho e quem olhou a semana de quem.

Essa ressalva sobre a chave não é força de expressão. As chaves que vocês trocam passam pelo nosso servidor — o que significa que, em teoria, poderíamos trocá-las. Você pode conferir: oito dígitos calculados a partir das duas chaves públicas precisam bater para você e para o seu amigo. Nós oferecemos essa verificação em vez de exigi-la — e, até fazê-la, você confia que o servidor entregou a chave verdadeira. A tela da amizade sempre mostra se ela foi verificada.

A chave que lacra a sua semana fica guardada no seu aparelho e nunca viaja — nem para nós, nem para o seu backup. Então, num aparelho novo, as amizades precisam ser confirmadas de novo.

Quanto dura cada coisa: um convite não aceito vale 30 dias e funciona uma vez; a sua semana fica no servidor até a próxima e é apagada na hora quando uma amizade termina; as notas duram sete dias; a ligação dura até ser encerrada ou até a conta ser excluída. As funções sociais não são oferecidas a ninguém cujo perfil diga ter menos de 16 anos.

Você pode ter no máximo 50 amigos, e esse teto é nosso, não do produto: quanto mais longa a lista, mais ligações o servidor conhece. Os convites têm limite pelo mesmo motivo — cinco ativos ao mesmo tempo, dez por dia.

Cookies

Exatamente um no domínio inteiro: a sessão de acesso. Ele é técnico, só é colocado quando você entra, dura até 180 dias desde o último acesso e não é visível para nada além do aplicativo. Antes de você entrar não há nenhum — e depois ele vai junto com cada página daqui, esta incluída, porque o site e o aplicativo respondem num mesmo endereço. Não há aviso porque não se pede consentimento para o cookie sem o qual não dá para entrar, e não há mais nada a perguntar: nem análise, nem publicidade.

Base legal

Cada finalidade tem sua própria base legal no RGPD (artigos 6 e 9):

Você também pode reclamar à autoridade de proteção de dados do seu país.

Por quanto tempo cada coisa é guardada

Sessão — até 180 dias desde o último acesso. Código por e-mail — 10 minutos. Números diários do contador — por tempo indeterminado, mas eles não contêm nada sobre uma pessoa. Conta — até você excluí-la. Correspondência com o desenvolvedor — exatamente tanto quanto a conta: ela vai junto com a conta e não tem prazo próprio. Escolhemos de propósito não dar um prazo próprio: seria uma promessa de apagar segundo um calendário, e não há calendário — então a promessa seria falsa desde a primeira vez que alguém conferisse.

As entradas do diário no servidor — enquanto a conta existir. Elas não têm prazo próprio, e isso é uma decisão, não um esquecimento. O servidor guarda uma cópia lacrada do diário por causa do seu segundo aparelho — e uma cópia que some sozinha não serve para um segundo aparelho: ele não teria de onde recuperar o que o servidor esqueceu, e o diário nele ficaria, sem aviso, mais curto do que no outro. As entradas vão junto com a conta e só com ela: exclua-a, e a cópia lacrada do diário sai da base de dados do servidor na hora, e das cópias de segurança à medida que elas giram — quanto tempo isso leva está dito no fim desta seção. O diário no próprio aparelho continua seu e é apagado à parte.

Os trinta dias citados abaixo não são das entradas em si, e os dois prazos não devem ser confundidos. Trinta dias é a vida das prévias das fotos (no aparelho e no servidor) e das versões de entradas que perderam um conflito de sincronização. As duas ficam AO LADO de uma entrada, não no lugar dela: o que vai embora é uma imagem ou um rascunho anterior da linha, enquanto a própria entrada continua onde está. Os dois prazos contam na base de dados de trabalho do servidor; nas cópias de segurança dela, uma imagem ou uma versão pode sobreviver a eles por até 14 dias — veja o último parágrafo desta seção.

Prévias das fotos das refeições — 30 dias. O aplicativo guarda uma cópia pequena da imagem ao lado da entrada e a apaga do aparelho trinta dias depois de a foto ser tirada. A entrada fica: só a imagem vai embora. Este prazo nós citamos, justamente porque aqui existe um calendário — a limpeza roda toda vez que o aplicativo abre e logo depois de um backup ser restaurado —, e dá para conferir abrindo um dia antigo. A fotografia em tamanho real nunca entra no diário: a entrada guarda só esta prévia.

Uma foto adiada — no aparelho, por no máximo 30 dias. Uma foto que você deixa para reconhecer depois fica no aparelho inteira, não como prévia: até ser reconhecida e você salvar a entrada, e por no máximo trinta dias depois de ser tirada. Quando o prazo acaba, a foto é apagada, e o lembrete da refeição fica, para você anotá-la na mão. Ela sai do aparelho só no momento do reconhecimento — pelo mesmo caminho de qualquer outra foto (veja Para onde os dados vão, sim) — e não fica no nosso servidor, assim como nenhuma outra foto. Ela nunca entra na cópia lacrada do diário no servidor.

No servidor a prévia vive pelo mesmo prazo — no máximo trinta dias. Ela vai para lá lacrada, junto com o diário, para poder aparecer no seu segundo aparelho; nós não conseguimos abri-la, assim como não conseguimos abrir as entradas. O servidor conta o prazo a partir do dia em que a imagem chegou, não do dia em que foi tirada: ele não sabe o dia em que foi tirada — isso está dentro do texto cifrado. Então a prévia sai primeiro do aparelho e depois do servidor, e a limpeza roda num calendário, uma vez por dia, e não «algum dia».

Versões de entradas que perderam um conflito de sincronização — no máximo trinta dias. Quando você edita uma entrada, substitui a versão anterior dela; o servidor não joga fora a anterior na hora, e sim a guarda à parte — para que «se consertou sozinho» não seja a nossa palavra contra a sua memória. Você pode vê-las e trazê-las de volta no aplicativo, no cartão de versões em conflito. Elas ficam lacradas, como as entradas: também não conseguimos abri-las. A limpeza roda num calendário, uma vez por dia — e é por isso que citamos o prazo aqui.

Uma versão assim pode ir embora antes do prazo, e é mais honesto dizer isso com clareza: por entrada o servidor guarda no máximo vinte delas, e a vigésima primeira desloca a mais antiga. É um limite técnico contra código descontrolado, não uma promessa de guardar vinte. A versão atual de uma entrada não é tocada nem pelo prazo nem pelo limite: é o seu diário, e só vai embora junto com a conta.

Cópias de segurança do servidor — até 14 dias. Uma vez por hora o servidor copia a base de dados inteira — um seguro para o dia em que um disco com defeito ou uma atualização quebrada levariam as contas de todo mundo. Das cópias das últimas 48 horas guarda-se uma por hora, das mais antigas uma por dia, e uma cópia com mais de 14 dias é apagada na próxima rotação de hora. As cópias só são apagadas por um servidor em funcionamento: enquanto ele está desligado, todas ficam, e quando ele volta as vencidas vão embora na hora. Uma ressalva: a cópia mais recente sempre fica — mesmo vencida, se as cópias novas pararam de dar certo — até a próxima que dê certo, porque uma cópia velha serve mais do que uma prateleira vazia. Uma cópia contém exatamente o que a base de dados tinha naquela hora, e da mesma forma. O que é lacrado com a sua chave — o diário, as prévias, as configurações, as versões em conflito — continua lacrado na cópia, e não temos chave para isso; o que o servidor vê abertamente — a correspondência com o desenvolvedor, quem é amigo de quem — ele vê também na cópia. É por isso que todo prazo acima é um prazo na base de dados de trabalho: o que foi apagado lá — pela limpeza ou junto com a conta — fica nas cópias de segurança no máximo 14 dias depois disso, exceto nos casos acima. Catorze dias é um limite superior, não uma promessa de guardar: uma cópia pode ir embora antes, por exemplo quando falta espaço no disco.

Uma cópia fora do provedor de hospedagem — até 35 dias, ainda não ativada. A base de dados e as cópias dela ficam num único provedor de hospedagem, e perdê-lo levaria as duas coisas. Para esse caso, o servidor pode mandar uma cópia por dia para um armazenamento separado, em outro provedor — a mesma cópia, da mesma forma. Lá as cópias só são apagadas pela própria regra do armazenamento, depois de 35 dias, e até lá ninguém pode apagá-las, nem nós — é isso que as protege de uma chave roubada. O que foi apagado na base de dados de trabalho ficaria lá por até 35 dias depois disso. Hoje isso não está ativado: as cópias só existem no servidor. Antes de ativar, vamos nomear o armazenamento aqui e mudar a data no alto da página.

Exclusão

No aplicativo: configurações → “Excluir a conta”. Isso apaga a conta, todas as formas de acesso dela, todas as sessões e toda a correspondência com o desenvolvedor; no acesso pela Apple também revoga a permissão do lado da Apple. O que o servidor guardava para a sincronização também vai junto com a conta: a cópia lacrada do seu diário, as prévias das fotos, a cópia lacrada das suas configurações, o registro das versões em conflito e a lista dos seus aparelhos — nada disso fica na base de dados do servidor. As cópias de segurança de hora em hora ainda guardam isso por até 14 dias, da mesma forma, e depois também some delas (desde que o servidor estivesse funcionando e as cópias novas dessem certo); como as cópias funcionam está descrito em Por quanto tempo cada coisa é guardada. Os números diários do contador de visitas ficam: eles não contêm nada sobre uma pessoa e não podem ser removidos por conta, porque não há conta neles. O diário no seu aparelho é apagado por um botão separado — ele é só seu, e não vamos decidir o destino dele por você.

Mudanças

Esta política muda junto com o serviço; a data no topo da página é a da última edição. As mudanças importantes são anunciadas aqui, e não por e-mail: o servidor não guarda nenhum endereço para o qual possa escrever — só uma impressão dele.

Contato

O controlador dos dados — quem decide o que é guardado aqui e responde por isso — é uma pessoa física, não uma empresa: por trás do Snapfork não há pessoa jurídica. Essa pessoa é Oleksandr Trifonov. Tudo sobre o serviço, incluindo os pedidos sobre os seus próprios dados, vai para o endereço abaixo. O que esse arranjo significa na prática está na página sobre quem está por trás.

Perguntas, acesso aos seus próprios dados e exclusão — pela página de perguntas ou escrevendo para hello@snapfork.app.

Termos de uso · Abrir o aplicativo