Política de Privacidade

Última atualização: 22 de outubro de 2026

A versão resumida. Os documentos, imagens, vídeos e arquivos que você cria no Lolly permanecem no seu dispositivo. Não existem contas para uso comum, nenhum cookie do próprio aplicativo e nenhuma análise ou rastreador em nenhum lugar do código-fonte - não é "nós não usamos os dados", é genuinamente ausente do código-fonte. Existe uma lista curta e completa de exceções para quando o software chega a conversar com uma rede, e cada uma delas é descrita abaixo em detalhes: o que sai, para quem e quando. A única exceção que envolve algo pessoal é um login que você precisa iniciar explicitamente. Se não está neste documento, não acontece.

O que esta política cobre

O Lolly é um software de código aberto - um mecanismo (engine), vários shells de aplicativo (web, desktop, móvel, CLI) e uma extensão de navegador - que qualquer pessoa pode executar. Esta política tem duas partes:

• O software em si: o que ele faz e não faz com seus dados, onde quer que seja executado. Isso é uma propriedade do código, portanto é verdade para toda implantação do Lolly, seja nossa ou de qualquer outra pessoa.
• lolly.tools, a implantação de referência operada pela SUSE: as escolhas específicas feitas na execução de suas partes opcionais do lado do servidor (o que é registrado, por quanto tempo, por quem).

Se você estiver usando uma instância autogerenciada (self-hosted) ou corporativa do Lolly, o comportamento do software abaixo ainda se aplica, mas o operador dessa instância - não a SUSE - é responsável por tudo do lado do servidor: seu endpoint de renderização, seu servidor MCP, sua autoridade certificadora de Content Credentials, se houver uma. Peça a eles sua própria política. Veja Adoção e Governança para o que envolve operar o Lolly.

O aplicativo: o que fica no seu dispositivo

Os shells web, desktop e móvel do Lolly executam todo o mecanismo de renderização no lado do cliente. Abrir uma ferramenta, preencher entradas, pré-visualizar e exportar, tudo acontece no seu dispositivo - nenhum servidor está envolvido, e o aplicativo funciona offline depois de carregado.

O aplicativo não define cookies. Para funcionar, ele mantém uma pequena quantidade de dados apenas no seu dispositivo, nunca transmitidos:

• Preferências de interface - tema, idioma, configurações de som, tamanho da barra lateral/zoom, ordenação e escolhas de visualização, quais dicas de integração você já viu - em localStorage, para que estejam disponíveis antes de o aplicativo terminar de inicializar.
• Um cache offline do catálogo de ferramentas e das pré-visualizações de recursos, para que a galeria funcione sem conexão.
• Contadores de uso locais para as estatísticas do seu cartão de perfil (quantas exportações, quais ferramentas) - um blob pequeno e limitado em localStorage, nunca lido por nós, nunca enviado a lugar nenhum.
• Seus próprios documentos, sessões salvas, recursos enviados e fontes - armazenados no IndexedDB no seu dispositivo, nunca enviados, nunca lidos por ninguém além de você.

Nada disso é compartilhado, vendido ou usado para identificar ou rastrear você. Não há nada a consentir, porque não há coleta acontecendo - só este aviso, para que você saiba o que é mantido e onde. Limpar o armazenamento do site no seu navegador remove tudo isso a qualquer momento, e o mesmo faz Configurações → Armazenamento → Limpar todos os meus dados, que também desliga a Sincronização primeiro. (Nos termos da Diretiva ePrivacy Art. 5(3), o armazenamento estritamente necessário para o serviço que você pediu não exige consentimento - só transparência, que é o que este documento e o aviso no app são, os dois.)

signed by Lolly2026-10-21vector SVG31 paths~4.2k nodes88 groups58 KBVerifique você mesmoBaixar o arquivo assinado signed by Lolly2026-10-21vector SVG31 paths~4.2k nodes88 groups58 KBVerifique você mesmoBaixar o arquivo assinado

Seu próprio backup desses dados - o pacote lolly-backup produzido por Exportar meus dados - é um arquivo que você guarda e controla. Ele nunca toca nossos servidores, a menos que você mesmo escolha enviá-lo para algum lugar. Veja Data Transfer.

Utilitários no dispositivo

Algumas ferramentas - Strip Hidden Data, Compress PDF e outras que exibem o selo "Runs on your device" - operam sobre um arquivo que você fornece. O arquivo é lido para a memória no seu navegador, transformado localmente e oferecido de volta como um download. Ele nunca é enviado, porque não há servidor no caminho para o qual enviá-lo. Esses utilitários funcionam offline, e sua saída não carrega nenhuma marca d'água ou metadado nosso - o objetivo da maioria deles é remover e proteger dados, não adicionar risco.

signed by Lolly2026-10-21vector SVG2 paths824 nodes5 groups12 KBVerifique você mesmoBaixar o arquivo assinado signed by Lolly2026-10-21vector SVG2 paths824 nodes5 groups12 KBVerifique você mesmoBaixar o arquivo assinado

O Prepare for sharing guarda entradas de trabalho, descobertas privadas e mapas de substituição em memória, sem adicioná-los automaticamente ao histórico, a links, a backups ou à sincronização. Inspeção e substituição não enviam o conteúdo do arquivo a um servidor nem validam credenciais on-line. Os usuários escolhem se copiam, baixam, enviam ou salvam explicitamente um resultado na biblioteca deles; um resultado salvo então segue as configurações normais de backup e sincronização da biblioteca. Arquivos de receita omitem cargas anteriores e mapeamentos literais. Relatórios de resumo contêm contagens, IDs de escopo e hashes de arquivo. A CLI também pode salvar um arquivo de revisão privado contendo os valores originais, só quando pedido explicitamente com --review-file. Limpar ou sair de uma visão de preparação no navegador libera seu estado de trabalho; isso não é uma promessa de apagamento forense da memória do navegador ou do sistema.

Cada requisição de rede que o app pode fazer

A tabela abaixo é a lista completa de tudo que o aplicativo busca ou envia por uma rede. Se não estiver aqui, o aplicativo não faz isso.

Cada host fixo naquela tabela também é a lista de permissões completa na Content-Security-Policy do app, que o navegador aplica. Então a lista não é só uma descrição do que o código faz hoje, é a fronteira que o navegador impõe ao app: uma mudança futura que tentasse contatar algum outro host seria bloqueada, não permitida silenciosamente. Uma linha é a exceção deliberada, e a própria célula dela explica isso: Enviar para o LinkedIn existe só nos apps de desktop, e a política do app web não lista nenhum dos hosts dele - o app web não conseguiria alcançá-los mesmo que o código tentasse. Mais duas linhas, Bluesky e Discord, são desktop-only da mesma forma, e seus hosts ficam de fora da política web pelo mesmo motivo. Cinco linhas não têm host fixo, porque você escolhe o endereço no momento de uso: uma URL que você pede a uma ferramenta para capturar, uma instância remota para a qual você aponta o shell, e seu próprio servidor Mastodon, servidor WebDAV ou bucket S3 (os dois últimos também como um lar de sincronização). Nenhum desses está na política, e cada um acontece só quando você digita um endereço e age sobre ele. A linha do Penpot alcança o Penpot pela própria origem do app, então ela está coberta por 'self'. Um deployment que não quer nenhum dos opcionais (uma instância corporativa com suas próprias fontes, por exemplo) remove esses hosts da própria política, e os recursos falham fechados em vez de tentar alcançá-los.

À parte dois tipos de linha, nenhuma delas envia seus documentos, projetos, sessões ou arquivos enviados para lugar nenhum: elas existem para trazer coisas ao seu dispositivo (ferramentas, fontes, modelos). Os dois tipos são as linhas de Enviar, que enviam o único arquivo que você escolheu, e a linha de sincronização, que envia uma cópia do seu trabalho para o armazenamento que você escolheu e para nenhum servidor do Lolly. Qualquer outra exceção é nomeada explicitamente nas seções abaixo.

Uma nota sobre o que removemos. O Verify pode checar assinaturas SEAL, um esquema no qual a chave de assinatura de um arquivo é publicada no DNS. Navegadores não conseguem fazer consultas DNS, então qualquer implementação web precisa rotear a busca por um resolvedor DNS-over-HTTPS de terceiros - o que mostraria a esse operador o domínio sendo verificado, além do seu endereço IP. Costumávamos usar o da Cloudflare. Não usamos mais, e não há substituto: o Verify agora não passa nenhum resolvedor, então a verificação SEAL não faz nenhuma requisição de rede. Nenhum app do Lolly consulta chaves SEAL no DNS hoje: os apps desktop e mobile rodam a mesma tela do Verify, e o lolly validate de linha de comando não checa SEAL. Um arquivo cujo registro SEAL traz a chave embutida é checado offline, e o Verify considera a assinatura internamente consistente sem confirmar o domínio. Um arquivo cuja chave está só no DNS mostra SEAL signature did not verify, com o motivo "no key resolver and no inline key".

signed by Lolly2026-10-21vector SVG11 paths~4.3k nodes18 groups52 KBVerifique você mesmoBaixar o arquivo assinado signed by Lolly2026-10-21vector SVG11 paths~4.3k nodes18 groups52 KBVerifique você mesmoBaixar o arquivo assinado Você pode confirmar isso você mesmo: verificações via grep para esta e cada outra afirmação nesta página, com os comandos exatos e a saída esperada, estão em Verify It Yourself.

URLs de renderização com hot-link

Ao vivo em lolly.tools. Toda URL https://lolly.tools/tool/<tool-id>.<ext>?<inputs> renderiza de verdade, e as entradas viajam naquela URL. A seção abaixo é o que isso significa para você, e um operador pode desligar o recurso na própria instância dele.

O aplicativo em si permanece inteiramente no seu dispositivo. Separadamente, um operador pode ativar URLs de renderização com hot-link - /tool/<tool-id>.<ext>?<inputs> - para que um link compartilhado do Lolly possa aparecer como uma imagem ao vivo em um README, uma wiki ou um dashboard. Buscar uma dessas URLs pede ao servidor que renderize dados públicos de ferramentas e catálogo com as entradas escritas na URL.

• Sem contas, sem cookies, sem estado. O endpoint é anônimo, e nada no seu dispositivo é lido. Seus documentos, sessões e uploads nunca saem do seu navegador - eles não conseguem aparecer nesses links de jeito nenhum.
• Mas a própria URL é registrada. A query string de uma URL faz parte da linha de requisição, então ela aparece nos logs de acesso comuns da plataforma de hospedagem, do mesmo jeito que todo caminho requisitado aparece. Se as entradas de um link contêm o nome ou e-mail de alguém - um crachá com nome, uma assinatura de e-mail - esse texto fica naqueles logs, e nenhuma quantidade de redação de política muda isso. Então uma URL de link direto é o lugar errado para detalhes pessoais: dê a ela só o que você colocaria em uma página pública.
• As entradas são públicas por construção de qualquer forma - elas são o que quer que o autor do link tenha digitado na URL, legível por qualquer um que o link alcance. Não coloque segredos em um link compartilhado. O Lolly oferece criptografia de link para conteúdo sensível.
• As respostas são cacheadas e limitadas por taxa como qualquer imagem pública, e marcadas noindex para que buscadores não indexem suas renderizações.

Está autohospedando o Lolly e não quer uma superfície de renderização pública? Defina LOLLY_DISABLE_RENDER_GET=1 e cada uma dessas URLs retorna 404.

O servidor MCP (opcional, para agentes de IA)

O Lolly também pode ser alcançado por um agente de IA pelo Model Context Protocol - um endpoint operado por um operador (lolly.tools roda um; qualquer um pode autohospedar o seu, incluindo totalmente isolado da rede). Ele compartilha a postura de sem-contas do caminho de renderização, mais quatro ferramentas que necessariamente lidam com bytes de arquivo:

• lolly_transform (roda um utilitário no dispositivo, do lado do servidor, em nome do agente que chamou), lolly_verify (checa Content Credentials) e lolly_redact (encobre regiões de uma imagem ou PDF) todas aceitam os bytes de um arquivo vindos de quem chamou. Eles são processados no próprio processo, em memória, e o resultado é devolvido naquela mesma chamada - o arquivo nunca é escrito em disco e nunca é armazenado depois que a requisição termina.
• lolly_rebrand (renova um slide deck antigo sobre um design system, pelas etapas plan, compile e inspect) aceita os bytes de um deck da mesma forma, e os processa em memória, só para aquela chamada - nada é escrito em disco nem mantido depois que a resposta é enviada. A primeira etapa dele, capabilities, diz em palavras para onde seus bytes iriam antes de você enviar qualquer um: em um servidor local autohospedado o deck nunca sai daquela máquina; em um servidor hospedado, chamar lolly_rebrand envia o deck para lá, até os limites de tamanho e de slides que essa mesma etapa dá.
• As ferramentas de imagem (lolly_look, lolly_sample_color e lolly_trace_edges) também podem receber um arquivo de imagem de quem chamou, tratado da mesma forma: em memória, só para aquela chamada. Toda outra ferramenta funciona a partir dos parâmetros da chamada: texto, números, cores, URLs, ids de ativos do catálogo ou um documento que quem chamou fornece.
• O acesso é ou um token compartilhado que o operador emite para clientes em quem confia, ou OAuth 2.1 sem estado: tokens assinados de curta duração verificados contra um segredo compartilhado, nada armazenado do lado do servidor e o próprio token nunca é escrito em um log ou em uma URL de renderização.

Identidade de Content Credentials (um login que você precisa iniciar você mesmo)

O Lolly pode selar uma Content Credential criptográfica em suas exportações para que qualquer pessoa possa verificar, offline, que um arquivo permanece inalterado desde que saiu do Lolly. Isso já vem ativado por padrão e totalmente local - a chave de assinatura é gerada no seu dispositivo e a própria assinatura acontece offline. Sem inscrição, essa chave é descartável: um par de chaves novo é gerado a cada exportação e descartado junto com ela. Depois que você se inscreve, a chave passa a ser permanente e é gerada não extraível - nem mesmo o próprio código do Lolly consegue lê-la, só pode pedir que ela assine. De um jeito ou de outro, ela nunca sai do seu dispositivo. Esta seção cobre a única etapa opcional além disso: inscrever uma identidade verificada, para que suas exportações digam "Verificado - assinado por \<your email\>" em vez de uma chave anônima. Se você pular a inscrição, nada nesta seção se aplica a você, e nenhum dado pessoal jamais sai do seu dispositivo.

signed by Lolly2026-10-21vector SVG7 paths~2.0k nodes11 groups24 KBVerifique você mesmoBaixar o arquivo assinado signed by Lolly2026-10-21vector SVG7 paths~2.0k nodes11 groups25 KBVerifique você mesmoBaixar o arquivo assinado

Se você se inscrever, aqui está exatamente o que acontece:

1. Você escolhe um método de login - GitHub, Google, SUSE (id.suse.com) ou um link por e-mail. Para os três provedores OIDC, você é redirecionado para a própria página de login daquele provedor, regida pela política de privacidade dele, não a nossa. O serviço de certificado do Lolly recebe de volta só um endereço de e-mail verificado e o nome do provedor. Para o link por e-mail, o endereço que você digita é passado ao Resend, uma API de e-mail transacional, só para entregar aquele link.
2. Um cookie de curta duração protege o redirecionamento. Este é o único cookie que todo o sistema Lolly define: lolly_ca_state, HttpOnly, restrito a /api/ca, expirando em até dez minutos. Ele carrega um valor aleatório, não um identificador de rastreamento, e existe só para impedir a falsificação do redirecionamento OAuth. Ele é apagado assim que o login termina.
3. Seu endereço IP é usado, brevemente, para prevenir abuso dos endpoints de login (para que um script não consiga entupir uma caixa de entrada ou esgotar a cota de e-mail). O Lolly faz o hash dele antes de criar um balde de controle de abuso de curta duração; o endereço bruto não é enviado a esse armazenamento. O balde expira depois de cerca de um minuto e não é usado para rastreamento. Os logs de acesso de hospedagem comuns são separados e descritos abaixo.
4. O serviço de certificado emite um certificado de curta duração (7, 30, 90 ou 365 dias, sua escolha, limitado pela política do operador) vinculando seu e-mail verificado à metade pública do par de chaves gerado no seu dispositivo. A metade privada nunca sai do seu navegador.
5. Nada sobre a emissão é registrado. O serviço de certificado não mantém log de emissão: nem seu e-mail, nem o provedor, nem um número de série, nem um timestamp. Sem banco de dados, sem linha de log, sem webhook. Seu endereço de e-mail existe na requisição só pelo tempo suficiente para ser escrito no certificado que o seu próprio dispositivo recebe, e depois disso ele desaparece completamente do nosso lado.
6. Depois disso, assinar volta a ser offline por toda a vida útil do certificado. Exportar um arquivo nunca contata o serviço de certificado - só a inscrição contatou.

A contrapartida, dita sem rodeios. Uma versão anterior deste serviço registrava cada emissão em log, para que um certificado emitido incorretamente ou comprometido pudesse ser rastreado. Nós removemos isso, porque esse log era o único lugar em todo o Lolly onde dados pessoais chegavam a repousar em um servidor, e preferimos não guardá-los a guardá-los com cuidado. O que abrimos mão é da rastreabilidade do lado do servidor: se um certificado é usado indevidamente, não conseguimos consultar quem o obteve. Certificados têm vida curta por design - de 7 a 365 dias, à sua escolha, limitado pelo operador - e expiram por conta própria, que é a mitigação em que confiamos em vez disso. Quem autogerencia o Lolly e cujas próprias obrigações exigem um log de auditoria pode adicionar um, e assim se tornar o controlador desses dados.

A extensão de navegador

A extensão de navegador Lolly URL Screenshot não coleta nenhum dado pessoal para nós. Ela não tem analytics, nem rastreamento, nem servidor próprio. A página Extensão de navegador descreve como ela funciona.

O que ela faz. O aplicativo web do Lolly pode pedir a ela um screenshot de uma página web, ou o conteúdo de uma página para iniciar um design system a partir de um site. Cada requisição abre na extensão uma janela de aprovação que mostra o site solicitante, se ele quer um screenshot ou o conteúdo da página, e o endereço da página. Só depois que você clica em Approve once a extensão abre essa página em uma aba temporária em segundo plano, tira o screenshot ou lê a página, entrega o resultado à aba do Lolly que pediu e fecha a aba. Cada requisição precisa da sua própria aprovação.

Dados.

• Não coletamos nada. O resultado vai só para a página do Lolly que pediu, no mesmo navegador. A extensão não armazena o conteúdo das páginas e não acrescenta nenhum outro destinatário.
• Requisições de rede. A página que você aprova carrega como carregaria em qualquer aba, junto com tudo que a própria página requisita. Ler o conteúdo de uma página também busca as folhas de estilo dela e alguns de seus ícones e logos, de dentro da página, e essas buscas não enviam cookies a outros sites. A extensão não faz nenhuma outra requisição, e nenhuma vai para um servidor do Lolly.
• A sessão do seu navegador. A página carrega com a sessão do seu navegador, como carregaria se você mesmo a abrisse, então uma página em que você está conectado pode colocar informações privadas no resultado.
• Os endereços que você aprova são usados apenas para carregar aquela página para aquela requisição. Eles não são registrados em log nem compartilhados.

Permissões.

• debugger - para tirar o screenshot via o DevTools Protocol (o mesmo mecanismo que o aplicativo desktop do Lolly usa).
• tabs - para abrir e fechar a aba temporária, e para verificar que nem a página do Lolly nem a página de destino mudaram desde que você aprovou.
• scripting - para ler o conteúdo de uma página na aba temporária, depois que você aprova aquela requisição.
• storage - para anotar os ids das suas abas temporárias em session storage, para que elas ainda fechem se o navegador parar a extensão durante uma requisição. Nenhum conteúdo de página é armazenado.
• *Acesso opcional a sites (http:///, https:///) - não concedido na instalação. Quando você clica em Approve once*, a extensão pede ao Chrome acesso ao único site daquela requisição, e o Chrome pergunta a você na primeira vez para cada site. Um site que você permitiu antes ainda precisa de uma nova aprovação para cada requisição.

Nada disso é usado para ler, monitorar ou transmitir sua navegação além da única requisição que você aprovou.

Logs de infraestrutura

Como qualquer site, os servidores por trás de lolly.tools - e por trás de qualquer deployment do Lolly - geram logs de acesso padrão de servidor web sempre que uma requisição os alcança: endereço IP, caminho requisitado, timestamp, user agent. Esse é comportamento básico de hospedagem, não algo que o Lolly adiciona por cima, e nunca contém o conteúdo dos seus documentos, porque eles nunca chegam a um servidor para começo de conversa. A única exceção deliberada é um arquivo que você explicitamente entrega a uma chamada MCP lolly_transform, lolly_verify, lolly_redact ou lolly_rebrand, que é processado em memória e nunca escrito em disco ou em um log, como descrito acima.

Os serviços públicos minimizam o log da aplicação. O servidor MCP registra inicialização, configuração e avisos de renderização; ele não mantém nenhum log de requisições próprio e não registra tokens nem endereços de quem chama. A passagem do Penpot registra o nome de cada comando e o status de resposta do Penpot, nunca cabeçalhos, tokens nem o arquivo. O serviço de certificados registra suas configurações de inicialização e avisos de configuração, mais duas linhas reduzidas em caso de falha: um código de status de falha de envio sem endereço de destinatário, e uma linha fixa de falha sem texto de erro, stack trace ou URL (um erro do provedor pode carregar valores de identidade ou credenciais). Tudo mais no log é da plataforma de hospedagem, não nosso.

No caso do lolly.tools, a hospedagem é a Vercel, e a retenção dos logs de acesso segue os padrões da própria plataforma Vercel para o nosso plano. Não configuramos nenhum log drain, nenhuma exportação de log de longo prazo e nenhum produto de analytics ou monitoramento por cima. Não mantemos nenhuma cópia desses logs por conta própria, o que também significa que não temos como buscá-los para você - veja Seus direitos.

Bases legais, retenção e destinatários

Quase nada aqui precisa de uma base legal, porque quase nada é processado. Para completude, a lista inteira:

Destinatários. As categorias de destinatário são: nosso provedor de hospedagem (Vercel Inc.); nosso provedor de armazenamento de controle de abuso, que recebe só chaves de balde de curta duração, derivadas em uma via, e nunca o endereço IP bruto; e - só se você usar a opção de login por e-mail - um provedor de e-mail transacional (Resend). Se você fizer login com GitHub, Google ou SUSE (id.suse.com), você interage com esse provedor diretamente, sob a própria política de privacidade dele. Eles nos dizem um endereço de e-mail verificado e nada mais. Não compartilhamos dados pessoais com mais ninguém, e não vendemos dados, não fazemos publicidade nem perfilamos usuários.

Transferências para fora do EEE. Vercel e Resend são empresas dos EUA. A computação de funções para lolly.tools é fixada na região de Frankfurt (fra1) da Vercel, então o processamento acontece na UE, mas, como provedores sediados nos EUA, eles ainda podem acessar dados como processadores a partir dos EUA. Essas transferências se apoiam nas Cláusulas Contratuais Padrão da Comissão Europeia e/ou no Data Privacy Framework UE-EUA, como definido no acordo de processamento de dados de cada provedor. Como os dados pessoais que chegam a esses provedores são tão limitados - um endereço de e-mail repassado para enviar uma mensagem, logs de acesso comuns, e um balde de controle de abuso derivado de curta duração - a exposição é correspondentemente pequena.

Decisões automatizadas. Nenhuma. Não há criação de perfis nem decisão automatizada que produza efeitos legais ou similarmente significativos (Art. 22).

Privacidade de crianças

O Lolly não coleta intencionalmente informações pessoais de ninguém, de qualquer idade, no uso normal do app - não há nada a coletar. O único lugar em que informações pessoais (um endereço de e-mail) são coletadas é o cadastro em Content Credentials, descrito acima, que não é direcionado nem destinado a crianças.

Seus direitos

Como quase tudo que o Lolly toca é armazenado só no seu próprio dispositivo, a maior parte do que a lei de proteção de dados chama de "seus direitos" - acesso, correção, exclusão, portabilidade - são coisas que você já pode fazer sozinho, instantaneamente, sem pedir a ninguém: seus dados vivem no armazenamento do seu navegador, em uma forma que você pode inspecionar, exportar (Exportar meus dados, acima) ou excluir (limpando o armazenamento do site no seu navegador, como acima).

Formalmente, nos termos dos Artigos 15-22 do GDPR, você tem o direito de acessar seus dados pessoais, de retificá-los, de apagá-los, de restringir ou se opor a seu processamento (incluindo se opor a qualquer coisa que baseemos em interesses legítimos), à portabilidade de dados e - quando o processamento se basear em consentimento - de retirar esse consentimento a qualquer momento, sem afetar a legalidade do que aconteceu antes de você retirá-lo.

Aqui está a posição honesta sobre exercer esses direitos contra nós. Já que não mantemos mais um log de emissão, não temos nenhum dado pessoal seu que possamos consultar, corrigir, exportar ou excluir. Se você escrever e perguntar o que temos sobre você, a resposta verdadeira é nada, e diremos isso. A única categoria que existe de fato é a de logs de acesso de hospedagem indexados por um endereço IP, mantidos pelo nosso provedor de hospedagem sob os padrões de retenção dele. Não temos como buscar ou apagar seletivamente esses logs, e diremos isso a você em vez de fingir o contrário. Tudo o que é de fato seu está no seu dispositivo, onde você já pode ler, exportar e destruir sem pedir permissão a ninguém.

Você tem o direito de reclamar. Se você acha que tratamos seus dados de forma inadequada, pode registrar uma reclamação junto a uma autoridade supervisora de proteção de dados - na UE, a autoridade do seu país de residência, local de trabalho ou onde você acredita que a infração ocorreu (Art. 77). Nossa autoridade supervisora principal é o Bayerisches Landesamt für Datenschutzaufsicht (BayLDA), em Ansbach, Alemanha. Você não precisa nos contatar primeiro, embora gostaríamos da chance de corrigir o problema.

Não vendemos dados. Não temos nenhum para vender.

Alterações nesta política

A data no topo muda sempre que este documento muda. Uma alteração que muda o que sai do seu dispositivo ou o que é retido ganha sua própria linha aqui, não é uma edição silenciosa - se quiser ver o que mudou, pergunte (abaixo) ou compare com a fonte pública.

22 de outubro de 2026: corrigida a descrição do comportamento existente. A seção da extensão de navegador agora cobre a janela de aprovação para cada requisição, o acesso a sites pedido um site de cada vez e as buscas de folhas de estilo e ícones na leitura de um site. Também corrigidos: as linhas de Enviar ao Google Drive e do Meeting Planner, a nota sobre SEAL (nenhum app do Lolly consulta chaves SEAL no DNS), o nível padrão de telemetria de uso do serviço da organização, as ferramentas de imagem do MCP e o log de aplicação dos serviços públicos. O software em si não mudou.

Quem é responsável e como nos contatar

O controlador de dados do lolly.tools é:

SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Alemanha

A SUSE nomeou um Encarregado de Proteção de Dados, que pode ser contatado em privacy@suse.com. Use esse endereço para qualquer solicitação formal sob "Seus direitos" acima.

Para qualquer coisa sobre o Lolly em si - como funciona, por que algo é do jeito que é ou uma correção a este documento - entre em contato com Andy Fitzsimon, fitzy@suse.com.

Para uma instância do Lolly self-hosted ou empresarial, entre em contato com quem a opera em vez de nós: o operador é o controlador da própria implantação. A SUSE e o projeto open source Lolly não mantêm dados de implantações que não operam.