Kimda

Política de privacidade

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

Esta é uma tradução automática. Só a versão checa é juridicamente vinculativa.

A versão checa desta política é a vinculativa. As traduções para outros idiomas são apenas para fins informativos; em caso de discrepância, prevalecerá a versão checa.

Este documento descreve que dados a app Kimda («a app», «nós») e o site kimda.app tratam, porquê e com que fundamento jurídico, a quem os transmitimos, durante quanto tempo os conservamos e que direitos têm o utilizador e os seus filhos. A app destina-se a ser usada por toda a família, incluindo as crianças – por isso tratamos a proteção dos dados com especial cuidado.

1. Quem é o responsável pelo tratamento

O responsável pelo tratamento dos dados é Mgr. Ivo Slávka, operador da app Kimda enquanto pessoa singular que exerce atividade comercial inscrita no registo de atividades económicas mantido pelo Município de Praga 8, IČO 30070929, com sede em Bergerova 1115/2, 182 00 Praha 8 – Kobylisy, República Checa. E-mail de contacto para questões de privacidade e para o exercício dos seus direitos: privacy@kimda.app.

2. Que dados tratamos e porquê

Dados da conta: nome próprio, apelido, número de telemóvel, função (pai ou mãe/criança), idioma e tema de aspeto escolhidos, foto de perfil opcional, a versão desta política e a hora em que a aceitou, no caso do pai/mãe a hora em que confirmou a sua maioridade, e no caso da criança a hora, a versão da política e o pai/mãe que deu o consentimento por ela (ponto 5). O seu nome e foto de perfil são visíveis para outros membros da sua família na aplicação (um pai vê todos os membros, uma criança vê os seus pais e irmãos).
O número de telemóvel é usado para verificar a identidade (código SMS) e para iniciar sessão, e a sua impressão digital irreversível também para proteger o período de teste Premium (ponto 6), após a alteração do número para verificar o pedido de recuperação de uma conta usurpada (registos de segurança abaixo) e após o restauro da base de dados a partir de uma cópia de segurança para reter o início de sessão num número que a conta tenha anteriormente abandonado (diário de alterações de telemóvel abaixo) – a app não usa o número para contactar ninguém nem o partilha com terceiros além do fornecedor da verificação por SMS (Twilio, ver ponto 4).
Dados da família: nome da família, quem faz parte dela, que função e que definições tem cada um (percentagens de divisão da mesada, moeda, idioma e fuso horário da família) e o histórico de alterações às regras financeiras (quem alterou e quando, por ex., os juros, as percentagens de divisão, a moeda ou o fuso horário, e de que valor para que valor).
Pedidos de adesão: nome, apelido, função e número de telefone da pessoa que se quer juntar à família, e a hora do pedido - para que o pai/mãe veja quem está a aprovar.
Pedidos de consentimento parental: tipo de pedido (remoção de um pai/mãe ou eliminação da família inteira), quem o apresentou, a quem diz respeito e quem o aprovou, recusou ou cancelou (identificadores internos), carimbos de data/hora (apresentação, prazo, lembrete, conclusão) e resultado (aprovado, recusado, cancelado, executado após o termo do prazo ou invalidado); não guardamos nomes, números de telemóvel nem texto livre. Os pais da família veem os pedidos na app.
Dados das tarefas: nome da tarefa, pontos, quando foi cumprida/aprovada/recusada e fotos, se a tarefa exigir uma foto, incluindo a impressão digital técnica da foto (ver ponto 3).
Planos, rotinas e lembretes: a quem a tarefa está atribuída, dia e hora previstos, estado de cumprimento, atraso, ordem de rotação e se foi enviado um lembrete.
Recompensas e objetivos: catálogo familiar de recompensas, pedidos de recompensa, objetivos de poupança e montantes que a criança transferiu para um objetivo. A partir destes dados, a visão geral para os pais calcula a taxa de conclusão global, a pontualidade e o equilíbrio na atribuição; não cria nenhum ranking público das crianças.
Dados financeiros da app: pontos, mesada virtual e a respetiva divisão, pedidos de pagamento, empréstimos e juros dentro da família – trata-se de um registo interno da app, não de dados bancários ou de pagamento reais. A app não tem acesso a nenhuma conta bancária nem a nenhum cartão de pagamento. O resumo mensal de uma criança (número de tarefas aprovadas, pontos e com Premium também o valor do mês atual; não os saldos das caixas) também é visível para outras crianças da mesma família, a menos que um pai o desative nas configurações da família.
Registos de pagamentos diretos e reembolsos manuais: quando um pai/mãe paga diretamente à criança na app uma parte do seu saldo (sem pedido da criança) ou regista manualmente um reembolso do seu empréstimo, o servidor guarda um registo individual sobre cada uma dessas operações, que depois não é alterado. Contém os identificadores internos da família, da criança e do pai/mãe que realizou a operação, o tipo de operação (pagamento direto, reembolso manual), o montante, no pagamento a caixinha a partir da qual foi pago e o desdobramento do montante (no pagamento, numa parte de depósitos próprios e numa parte de juros creditados; no reembolso, em capital e em juros), a hora da operação e o identificador aleatório do pedido. O registo serve para comprovar o que o pai/mãe registou na app e quando, e para que uma eventual disputa na família possa ser avaliada com base no registo e não apenas pelo saldo final. Trata-se de um registo interno da app – a app em si não transfere qualquer dinheiro. Os registos fazem parte da exportação de dados (ponto 7) e são conservados de acordo com o ponto 6.
Subscrição: estado da subscrição da família (período de teste, Premium, a sua validade e renovação) e eventual acesso gratuito através de código promocional; o servidor guarda os próprios códigos promocionais apenas como impressão digital HMAC e regista a gestão dos códigos (quem, quando, que ação). Não vemos os dados de pagamento – o pagamento é processado pela Apple ou pela Google. O documento comprovativo do consentimento com o início imediato do Premium, que conservamos como prova deste consentimento, é descrito no ponto 6.
Início de sessão e segurança: sessões de início de sessão de cada dispositivo (quando foi criada, quando foi usada pela última vez e até quando é válida). O pai/mãe vê em O meu perfil uma visão geral dos seus dispositivos com sessão iniciada (apenas a hora de início de sessão e da última utilização, sem endereço IP nem nome do dispositivo) e pode terminar a sessão de cada um individualmente. O servidor guarda os tokens de atualização apenas como impressões digitais SHA-256, incluindo as impressões digitais de tokens já substituídos, para detetar o uso indevido de um token roubado. Ao pedir um código SMS, guarda a impressão digital codificada (HMAC-SHA-256) do número de telemóvel e a impressão digital SHA-256 do desafio de utilização única juntamente com o número de tentativas, na alteração do número e na confirmação da eliminação da família também a sua finalidade e o identificador interno da conta. Calcula os limites do número de pedidos, incluindo o limite diário de SMS enviados, com base na impressão digital codificada (HMAC-SHA-256) do endereço IP ou da sua rede (IPv4 /24, IPv6 /56), do número de telemóvel, do par número de telemóvel e rede ou da conta, ou de acordo com o país ou o indicativo do número de telemóvel. O servidor deriva a chave para estas impressões digitais a partir de uma chave secreta guardada fora da base de dados, pelo que a impressão digital não pode ser convertida de volta num número de telemóvel ou endereço IP sem ela. Os registos de segurança sobre eventos importantes (p. ex., início de sessão, pedido de adesão, aprovação, recusa ou remoção de um membro, novo código de convite, fim de sessão de um dispositivo, alteração do número de telemóvel, confirmação das políticas, consentimento do pai/mãe pela criança ou suspeita de uso indevido de um token) contêm o tipo de evento, a hora e os identificadores internos; na remoção de um membro, também a sua função (pai ou mãe/criança), na confirmação das políticas e consentimento do pai/mãe a versão das políticas e, na eliminação da conta de uma criança que tinha uma dívida, um saldo ou pedidos pendentes, também a moeda, os montantes anulados e o número de pedidos pendentes. O registo sobre a alteração do número de telemóvel contém ainda a impressão digital irreversível do número original (HMAC com chave secreta), para que o suporte possa verificar se o pedido de recuperação de uma conta usurpada é apresentado pelo verdadeiro titular do número original. Nomes, números de telemóvel ou endereços IP não estão incluídos. Além disso, as alterações do número de telemóvel e a remoção ou o restauro de um membro da família são registados num diário separado, descrito na alínea “Diário de alterações de telemóvel e de estado do membro” abaixo.
Avisos de segurança: quando um pai/mãe inicia sessão com um código SMS, os outros pais na família recebem um aviso genérico sem nome nem número de telemóvel; em cada início de sessão com um código SMS (do pai/mãe e da criança), os dispositivos já com sessão iniciada da mesma conta também recebem um aviso genérico sobre o novo início de sessão. Ao alterar o número de telemóvel (o novo número é verificado através de código SMS), o servidor termina a sessão dos outros dispositivos com sessão iniciada da conta e tanto os dispositivos atuais da conta como os pais na família recebem um aviso genérico; o número original não continua a ser conservado – permanece apenas a sua impressão digital irreversível no registo de segurança sobre a alteração (30 dias, ver secção 6), as impressões digitais irreversíveis do número original e do novo número no diário de alterações de telemóvel (60 dias, ver abaixo e secção 6) e, no caso de um pai/mãe que tenha sido membro de uma família durante o seu período de teste, também a impressão digital segundo a secção 6. Quando o suporte recupera o número a pedido do titular da conta, verifica primeiro a sua identidade: através de um código SMS enviado para o número original, cuja impressão digital deve coincidir com a impressão digital no registo de alteração do número. Quando tal verificação não for possível (o registo de alteração já não existe ou o titular não tem o número original), verifica-a através de uma confirmação de outro pai/mãe na família (verificada por um código SMS enviado para o número desse pai/mãe) e de respostas a perguntas feitas pelo suporte; nesse caso, envia primeiro um aviso aos dispositivos da conta e aos pais na família e devolve o número não antes de 72 horas, se ninguém se opuser; verá este aviso após iniciar sessão também diretamente na aplicação durante todo o prazo. Sem essa verificação, não recupera o número e não cancela nenhum pedido – podendo apenas terminar a sessão da conta em todos os dispositivos. Se o suporte já tiver devolvido a mesma conta uma vez nos últimos 30 dias, considera o próximo pedido uma disputa e não recupera o número sem verificação adicional. Após a recuperação, o servidor termina a sessão da conta em todos os dispositivos, os pais na família recebem um aviso genérico e a intervenção é registada (quem a realizou, quando, a que conta diz respeito e uma ligação para o seu pedido – sem número de telemóvel). Os pais recebem também um aviso genérico na eliminação da conta de uma criança, na remoção de outro pai/mãe (incluindo o pai/mãe removido) e em caso de suspeita de uso indevido do token de início de sessão; nesse caso, o servidor termina a sessão da conta em todos os dispositivos e cancela os seus registos para notificações. Os avisos de segurança (p. ex., sobre um novo início de sessão ou dispositivo, alteração do número de telemóvel, alteração das regras financeiras, remoção de um membro, eliminação da conta de uma criança ou suspeita de uso indevido de um token) são primeiro guardados pelo servidor numa fila (tipo de aviso, destinatário - token push do dispositivo ou identificador interno da família ou da conta e idioma - e tipo técnico geral do evento) e só a partir daí são entregues; os avisos aquando da recuperação de uma conta usurpada pelo suporte (acima) são enviados diretamente. Se a entrega de um aviso aos pais ou aos dispositivos da conta de um membro da família falhar mesmo após tentativas repetidas, o servidor guarda apenas o identificador interno da família, o tipo de aviso e a hora (sem o token push e sem nome), para que o pai/mãe possa ver de que aviso se tratava ao iniciar sessão na app da próxima vez e possa confirmá-lo; se o destinatário não tiver nenhum dispositivo para o qual o aviso possa ser enviado, tal registo não é criado. Os prazos de conservação são estabelecidos no ponto 6.
Diário de alterações de telemóvel e de estado do membro: a par dos registos de segurança acima, o servidor mantém um registo individual no diário para cada alteração do número de telemóvel da conta (quer a realize por si próprio no Perfil, quer seja realizada pelo suporte a seu pedido) e para cada remoção ou restauro de um membro da família. O registo contém um identificador aleatório do registo, os identificadores internos da conta e da família, o tipo de evento (alteração de número, recuperação de número pelo suporte, remoção de membro, restauro de membro), a hora do evento e – apenas na alteração de número – as impressões digitais irreversíveis do número original e do novo número (HMAC-SHA-256 com uma chave secreta que é guardada fora da base de dados). Na remoção e no restauro de membro não existem quaisquer impressões digitais. Números de telemóvel, nomes ou endereços IP não constam do diário. A impressão digital não pode ser convertida de volta num número de telemóvel sem a chave secreta, mas, como está associada ao identificador interno da conta, trata-se de um dado pseudonimizado e não de um dado anónimo. O diário serve apenas para proteger contra as consequências do restauro da base de dados a partir de uma cópia de segurança: para que não regresse à conta um número que a conta tenha entretanto abandonado (e que outra pessoa possa ter assumido) e para que seja novamente aplicada a remoção de um membro da família que a cópia de segurança não contenha. Por isso, no início de sessão por código SMS e na verificação do número de telemóvel, o servidor compara a impressão digital do número introduzido com o último registo do diário; se não coincidir, retém o início de sessão e encaminha para o suporte. O registo é guardado na base de dados e, regra geral em poucos minutos, também numa cópia num armazenamento privado separado Cloudflare R2 (ponto 4), para que sobreviva à perda da base de dados entre cópias de segurança. Os prazos de conservação são fixados no ponto 6.
Dados técnicos: token push e identificador aleatório do dispositivo, que a app cria para a entrega de notificações (não é um identificador de hardware), a hora do último registo do dispositivo, o início de sessão ao qual o registo pertence, e a impressão digital SHA-256 do segredo de instalação aleatório, com o qual o dispositivo prova que o token push lhe pertence. Após a libertação do registo (fim de sessão, remoção de membro, bloqueio de segurança ou limpeza automática), o servidor recorda dois registos com limite de tempo para que uma conta de terceiros não possa assumir as notificações do dispositivo: (a) um registo sobre o token push libertado – as impressões digitais SHA-256 do token push e do segredo de instalação, o identificador interno da família e a hora de libertação (o token libertado não pode assim ser assumido por uma conta de outra família); e (b) um registo sobre o dispositivo libertado – o identificador interno da conta, o identificador aleatório do dispositivo, as mesmas impressões digitais e a hora de libertação (o dispositivo libertado não pode assim, sem comprovar que se trata da mesma instalação, ser novamente ocupado por outra sessão de início de sessão da mesma conta, por exemplo, roubada). Além disso, o servidor conserva durante 30 dias um registo do registo do dispositivo (identificador interno da conta e do dispositivo, impressão digital do token push, tipo de evento e hora), através do qual controla o limite de registos de novos dispositivos por 24 horas. Os prazos de conservação são fixados no ponto 6; o registo sobre o dispositivo libertado não é mantido aquando da eliminação da conta. Além disso, registos operacionais do servidor (p. ex., estados de erro) sem números de telemóvel nem o conteúdo dos pedidos. No telemóvel, a app conserva os tokens de início de sessão num armazenamento seguro e recorda o idioma e o tema escolhidos; também comunica o idioma escolhido ao servidor para que as notificações cheguem no seu idioma. O que a app envia diretamente aos serviços Expo e Sentry é descrito no ponto 4.

Porquê tratamos os dados e com que fundamento jurídico:

Conta familiar e funções da app (registo, família, tarefas e fotos, planos, lembretes, recompensas, objetivos, mesada incluindo os registos de pagamentos diretos e reembolsos manuais, notificações e subscrição): execução de um contrato, ou seja, as condições de utilização (Art. 6(1)(b) RGPD). Tratamos adicionalmente os registos de pagamentos diretos e reembolsos manuais e o histórico de alterações das regras financeiras com base no nosso interesse legítimo na comprovabilidade das operações financeiras e das regras na app e na resolução de disputas na família (Art. 6(1)(f) RGPD). Tratamos adicionalmente o documento comprovativo do consentimento com o início imediato do Premium e a sua cópia fora da base de dados com base no nosso interesse legítimo em comprovar este consentimento e na defesa de reivindicações legais (Art. 6(1)(f) RGPD). Para os dados das crianças, ver ponto 5.
Início de sessão verificado por código SMS: execução de um contrato (Art. 6(1)(b) RGPD) – sem um número de telemóvel verificado não é possível iniciar sessão na app.
Segurança e proteção contra o uso indevido (sessões e impressões digitais de tokens, desafios de código SMS, limites do número de pedidos e limite diário de SMS, registos de segurança, diário de alterações de telemóvel e de estado do membro, memória de tokens push e dispositivos libertados, registo do registo de dispositivo e limite de registos de novos dispositivos por 24 horas, fila de notificações de segurança e registo de notificações não entregues, registos operacionais, impressão digital do número de telemóvel contra a utilização repetida do período de teste, pedidos de consentimento parental que protegem a família contra a remoção unilateral de um pai/mãe ou eliminação, e a verificação de identidade quando o suporte recupera uma conta usurpada, incluindo o registo de tais intervenções): o nosso interesse legítimo no funcionamento seguro do serviço, na proteção das contas de pais e filhos e na defesa contra o uso indevido da verificação por SMS (Art. 6(1)(f) RGPD).
Correção de erros e atualização da app (relatórios de erros através do Sentry, atualizações através da Expo): o nosso interesse legítimo numa app estável e segura (Art. 6(1)(f) RGPD).
Tratamento dos seus pedidos nos termos do ponto 7 e prova de como e quando os tratámos (p. ex., estado da eliminação efetuada, diário das eliminações efetuadas e tarefa de eliminação externa): cumprimento de uma obrigação legal (Art. 6(1)(c) RGPD).
Medição de publicidade no site kimda.app (Meta Pixel): o seu consentimento (Art. 6(1)(a) RGPD), ver ponto 9.

Pode opor-se ao tratamento com base no interesse legítimo (ponto 7). O número de telemóvel é necessário para o registo e o início de sessão; sem ele não é possível usar a app. A foto de perfil é voluntária e a foto da tarefa cumprida só é necessária para as tarefas em que o pai/mãe a exija. Não utilizamos decisões automatizadas nem definição de perfis com efeitos jurídicos ou de importância semelhante (Art. 22 RGPD); os limites de segurança automáticos, que por exemplo bloqueiam temporariamente novas tentativas de código SMS, servem apenas para proteger as contas e o serviço.

3. Fotos das tarefas

As fotos que a criança (ou o pai/mãe por ela) carrega numa tarefa são vistas apenas pelos membros da mesma família (pais e crianças na app). Não são públicas, a app não as partilha com nenhuma outra app nem rede social. A foto para a tarefa só pode ser tirada com a câmara da app. A app e, em seguida, também o servidor removem os metadados da foto antes de a guardar (por exemplo, a localização GPS ou os dados da câmara). As fotos são guardadas num armazenamento de objetos não público (ver ponto 4) e o servidor apenas as fornece a um membro da mesma família com sessão iniciada. O pai/mãe pode pedir a sua eliminação a qualquer momento.

Para cada foto carregada, o servidor calcula uma impressão digital técnica (soma de verificação e uma impressão digital de imagem simplificada de 64 bits). Serve apenas para que a app reconheça quando a mesma foto ou uma quase igual é usada novamente numa tarefa, e para que a foto pertença à tarefa para a qual a criança acabou de a tirar na app. A partir da impressão digital não é possível visualizar nem reconstruir a foto, e esta é eliminada juntamente com a foto. O registo do desafio de tempo para a foto (quem a solicitou na app, para que tarefa e quando) é eliminado pelo servidor após 7 dias. O pai/mãe vê um aviso junto à foto quando esta não tem uma verificação de tempo válida da app ou é muito semelhante a uma foto anterior, como ajuda na aprovação; a verificação não garante que a foto não possa ser falsificada.

4. A quem transmitimos os dados e transferências para fora da UE

Transmitimos os dados apenas aos fornecedores que nos prestam serviços para o funcionamento da app (subcontratantes), e apenas na medida em que necessitem deles. Os subcontratantes só podem usar os dados para a prestação do seu serviço para nós e de acordo com as nossas instruções. A Apple e a Google atuam como responsáveis independentes nas compras nas lojas.

Fornecedor de alojamento (Railway) – opera o servidor da app e a base de dados na qual estão guardados os dados da app.
Cloudflare – o armazenamento privado de objetos R2 conserva, com transmissão encriptada, as fotos de perfil e as fotos das tarefas cumpridas, as cópias de segurança da base de dados (encriptadas antes do envio de tal forma que só podem ser desencriptadas com uma chave privada que conservamos fora da cloud), o registo das eliminações efetuadas (apenas identificadores internos, tipo de eliminação e hora), o diário de alterações de telemóvel e de estado do membro (ponto 2: identificadores internos, tipo e hora do evento e, na alteração do número, impressões digitais irreversíveis dos números) e a cópia da prova de consentimento para o início imediato do Premium (ponto 6: identificadores internos da família e do utilizador, hora do consentimento, plano escolhido, início do período pago, identificador da transação da loja e versão do texto apresentado) em buckets não públicos; o acesso às fotos continua a ser controlado pelo backend autenticado da Kimda. A Cloudflare também opera o site kimda.app (ponto 9).
Twilio (verificação do telemóvel por código SMS) – recebe o número de telemóvel e o código que introduz apenas para a entrega e verificação do código SMS.
Expo (650 Industries) – em primeiro lugar, entrega as notificações: recebe o token push do dispositivo, o identificador de instalação para as notificações, o token nativo da Apple ou Google, um texto ou emoji genérico da notificação e um tipo técnico genérico do evento. Não enviamos na mensagem push IDs da base de dados, nomes, nomes de tarefas nem montantes. A Expo reencaminha a mensagem para o serviço push da Apple (Apple Push Notification service) ou da Google (Firebase Cloud Messaging). Em segundo lugar, entrega as atualizações da app (EAS Update): a app pergunta aos servidores da Expo em cada arranque se há uma correção disponível. A Expo recebe então o endereço IP do dispositivo, a plataforma, a versão da app, o identificador da atualização instalada, eventualmente o texto do último erro que encerrou a app, e um identificador aleatório de instalação EAS-Client-ID, que a app guarda permanentemente no telemóvel e que não muda mesmo depois de terminar a sessão. Não o associamos à sua conta e a app não o envia ao nosso servidor.
Apple e Google – como responsáveis independentes, processam a compra e a gestão da subscrição na App Store e no Google Play; como serviços push (Apple Push Notification service, Firebase Cloud Messaging), entregam as notificações aos dispositivos.
RevenueCat (processamento de subscrições através da App Store / Google Play, apenas em contas de pais) – trata o identificador da família, o histórico de compras, o recibo da Apple ou o token de compra da Google, a hora da última utilização e dados técnicos do dispositivo (p. ex., tipo de dispositivo e sistema operativo). Não recebe da Kimda o nome nem o número de telemóvel dos pais ou da criança. Na app não estão ativadas as integrações publicitárias/de atribuição da RevenueCat nem a recolha manual de identificadores publicitários.
Sentry (relatórios técnicos de erros da app e do servidor, para a correção de erros) – recebe o tipo de erro, o local no código, a versão da app e do sistema operativo. A app e o servidor estão configurados para não lhe enviar o nome, o telemóvel, o token de início de sessão, o conteúdo dos pedidos nem o endereço IP. A organização Kimda no Sentry encontra-se na região de dados da UE (Alemanha).
Fornecedor de e-mail (Spaceship, serviço Spacemail) – entrega e conserva os e-mails que nos envia para privacy@kimda.app ou support@kimda.app.

Railway, Cloudflare, Twilio, Expo, RevenueCat, Sentry, Spaceship, Apple, Google e Meta (ponto 9) são empresas com sede ou infraestrutura nos EUA, pelo que podem tratar os dados também fora do Espaço Económico Europeu. Para transferências fora do Espaço Económico Europeu, utilizamos um mecanismo do Capítulo V do RGPD que se aplica ao destinatário e ao tratamento específicos – regra geral, a certificação do destinatário no âmbito do EU-USA Data Privacy Framework (decisão de adequação da Comissão Europeia, Art. 45 RGPD) ou cláusulas contratuais-tipo aprovadas pela Comissão Europeia (Art. 46(2)(c) RGPD). Fornecer-lhe-emos informações sobre o mecanismo de um destinatário específico e sobre onde obter uma cópia das respetivas garantias, a pedido, em privacy@kimda.app.

Não vendemos os dados da app, não os partilhamos com anunciantes nem os usamos para publicidade direcionada. A medição de publicidade no site kimda.app, mediante consentimento do visitante, é descrita no ponto 9.

5. Consentimento dos pais e função das crianças

Só uma pessoa adulta pode criar a app (a função "pai/mãe" e uma nova família). Uma conta com a função "criança" só é criada depois da adesão através de um código de convite que apenas os pais conhecem – a criança só pode, portanto, participar com o conhecimento e o consentimento do pai ou da mãe que partilha o código. Além disso, cada adesão de uma criança e de outro pai/mãe tem de ser expressamente aprovada pelo pai/mãe na app; até à aprovação, o novo membro só vê o nome da família. O código de convite da família é válido por 48 horas, um pedido não aprovado é eliminado automaticamente após 72 horas e um recusado ou cancelado imediatamente. Ao registar-se com a função "pai/mãe", confirma que é maior de idade e que tem o direito legal de consentir o tratamento dos dados dos seus filhos na app.

Tratamos os dados da criança apenas na medida necessária para o funcionamento da conta familiar que o pai/mãe criou e gere, ou seja, para a execução do contrato com o pai/mãe (Art. 6(1)(b) RGPD). O pai/mãe, como representante legal, decide sobre a participação da criança: partilha o código de convite, aprova expressamente a adesão da criança e pode remover a criança da família a qualquer momento ou pedir a eliminação da sua conta. No registo, a criança apenas toma conhecimento da política; o consentimento para o tratamento dos seus dados é dado pelo pai/mãe quando aprova a adesão da criança na app, e o servidor regista a hora, o pai/mãe e a versão da política. Para as crianças aprovadas com uma versão mais antiga da app, a app solicitará posteriormente ao pai/mãe o consentimento em falta. Se o tratamento exigisse consentimento e a criança ainda não tivesse 15 anos (limite de idade na República Checa nos termos do Art. 8 RGPD e do artigo 7.º da Lei n.º 110/2019 sobre o tratamento de dados pessoais), o pai/mãe dá o consentimento em nome da criança. Os direitos da criança nos termos do ponto 7 podem ser exercidos pelo pai/mãe em seu nome.

6. Durante quanto tempo conservamos os dados

Conservamos os dados da conta e da família até que o utilizador peça a eliminação da conta ou da família inteira. A simples inatividade da app não desencadeia qualquer eliminação automática. O utilizador não tem, por isso, de abrir a app regularmente para não perder o histórico da família e pode iniciar a eliminação a qualquer momento diretamente na app ou pedi-la em privacy@kimda.app. Conservamos o histórico de alterações às regras financeiras (ponto 2) durante toda a existência da família, sem limite de tempo ou de número total (a família pode guardar alterações às regras financeiras no máximo 30 vezes por hora), porque serve como prova imutável de quem alterou as regras e quando, por exemplo, num litígio entre os pais; não pode ser editado ou eliminado na app. Após a eliminação da família inteira (ponto 7), o servidor elimina-o na limpeza seguinte; a eliminação da conta de um membro individual não o altera e mantém apenas um identificador interno sem nome.

Para os restantes registos aplicam-se os seguintes prazos:

Desafios de código SMS (impressões digitais do número de telemóvel e do desafio): são válidos por 10 minutos; após uma verificação bem-sucedida, o servidor elimina-os imediatamente, caso contrário, o mais tardar uma hora após a sua expiração.
Limites do número de pedidos e limite diário de SMS (impressões digitais): o servidor elimina-os 24 horas após o fim do período monitorizado; o limite diário de SMS termina sempre à meia-noite UTC.
Sessões de início de sessão: o token de início de sessão é válido por 15 minutos; a sessão termina após 30 dias de inatividade, o mais tardar após 90 dias, ou antes ao terminar a sessão. O servidor elimina a sessão terminada, incluindo as impressões digitais dos tokens, 30 dias após o seu fim.
Convites e pedidos de adesão: o código de convite da família é válido por 48 horas e o convite para outro pai/mãe por 24 horas; um pedido de adesão não aprovado é eliminado automaticamente após 72 horas, e um recusado ou cancelado imediatamente. O servidor elimina o registo do convite para outro pai/mãe (código, quem o criou e quem o usou) 30 dias após a sua expiração, utilização ou cancelamento.
Registos de segurança na base de dados (ponto 2): o servidor elimina-os por si próprio após 30 dias. O diário de alterações de telemóvel e de estado do membro rege-se pelo seu próprio prazo indicado abaixo.
Diário de alterações de telemóvel e de estado do membro (ponto 2): o servidor elimina o registo na base de dados no mínimo 60 dias após a sua criação, e apenas depois de o ter copiado para um armazenamento separado (a cópia é criada, regra geral, dentro de poucos minutos). Um registo que não tenha sido possível copiar não é eliminado pelo servidor até que a cópia seja bem-sucedida, permanecendo por isso na base de dados mesmo por mais de 60 dias. A cópia no armazenamento privado separado Cloudflare R2 é eliminada pelo próprio armazenamento decorridos 60 dias após o seu armazenamento. Aquando da eliminação da conta ou da família inteira (ponto 7), o servidor elimina da base de dados os registos do diário da conta ou família eliminada; a sua cópia no armazenamento extingue-se o mais tardar 60 dias após o armazenamento.
Fotos: as fotografias não associadas, que não foi possível atribuir a um perfil ou a uma tarefa, o servidor remove-as após 24 horas; elimina o registo do desafio de tempo para a foto após 7 dias (ponto 3) e o registo técnico da foto eliminada (apenas identificadores internos) 30 dias após a eliminação da foto.
Token push e identificador do dispositivo: até ao fim de sessão do dispositivo, à remoção do membro da família ou à eliminação da conta, ou até que a Apple ou a Google o marquem como inválido. Além disso, o servidor elimina-os por si próprio quando a app não renova o registo do dispositivo durante 90 dias (renova-o em cada início de sessão e arranque), ou quando o utilizador não tem uma sessão de início de sessão válida há mais de 30 dias. Após o fim de sessão do dispositivo (mesmo remotamente no Perfil) ou o fim do seu início de sessão, nada é entregue ao dispositivo. Uma exceção são os registos de antes da implementação desta versão, que a app não renovou desde então: o fim de sessão de um dispositivo remotamente não os desligará, a opção Terminar sessão em todos os dispositivos sim; caso contrário, o servidor elimina-os de acordo com os prazos acima. O servidor elimina o registo sobre o token push libertado (impressões digitais, família e hora) após 30 dias, ou antes, se o dispositivo se registar novamente. O servidor elimina o registo sobre o dispositivo libertado (identificador interno da conta, identificador aleatório do dispositivo, impressões digitais e hora) após 91 dias – ou seja, apenas após expirar a validade máxima possível da sessão de início de sessão (90 dias) – ou antes, se um dispositivo da mesma conta se registar novamente. O registo sobre o dispositivo libertado não é mantido aquando da eliminação da conta; se já tiver sido criado no início da eliminação, o servidor elimina-o na sua conclusão. O prazo do registo sobre o token push libertado permanece inalterado. A impressão digital técnica do token push num lembrete enviado serve apenas para verificar a entrega; o servidor elimina-a após avaliar a entrega, o mais tardar 30 dias após o envio. O servidor elimina o registo sobre o registo do dispositivo (identificador interno da conta e do dispositivo, impressão digital do token push, tipo de evento e hora; ponto 2) após 30 dias da sua criação, mesmo que a conta seja eliminada entretanto.
Fila de avisos de segurança e avisos não entregues (ponto 2): o servidor remove do registo guardado na fila os dados do destinatário do aviso (token push do dispositivo ou identificador interno da família ou da conta e idioma) logo após a entrega ou a renúncia da entrega, o mais tardar 7 dias após a criação do aviso; apenas o identificador interno da família (num erro excecional da base de dados, temporariamente também da conta) pode permanecer nele até à gravação do registo sobre um aviso não entregue (abaixo). O registo restante (tipo de aviso, tipo técnico geral do evento, hora e mensagem técnica de erro) é eliminado 30 dias após o processamento. O registo sobre o aviso não entregue para os pais (identificador interno da família, tipo de aviso e hora, sem token push e sem nome) é conservado até que o pai/mãe o confirme na app; o registo confirmado é eliminado assim que tiver mais de 90 dias. O registo de uma família que já não exista é eliminado na limpeza seguinte.
Respostas guardadas de operações financeiras: para que um pedido repetido após uma falha de rede não registe um pagamento, um empréstimo ou outra operação financeira duas vezes, o servidor recorda a resposta ao mesmo durante 30 dias. O próprio registo da operação (tipo de operação, o seu identificador aleatório, identificadores internos da família, do interveniente e do membro em causa, impressão digital SHA-256 do pedido e hora) faz parte do histórico financeiro e é conservado até à eliminação da conta ou da família.
Registos de pagamentos diretos e reembolsos manuais (ponto 2): ao contrário da resposta guardada acima, que é eliminada após 30 dias, estes registos são conservados até à eliminação da criança a que dizem respeito ou da família inteira (ponto 7).
Registos guardados de pedidos repetidos do programador: para que um pedido repetido após uma falha de rede não crie o plano de tarefas duas vezes, o servidor conserva durante 60 dias um registo da sua criação (identificadores internos da família e do pai/mãe, tipo de operação, identificador aleatório do pedido, impressão digital SHA-256 dos parâmetros do plano inseridos, ligação para o plano criado e hora). O servidor também elimina o registo aquando da eliminação da conta do pai/mãe que criou o plano e aquando da eliminação da família inteira (ponto 7).
Pedido de eliminação de conta: um pedido de eliminação não confirmado é invalidado após 45 dias e eliminado o mais tardar após mais 400 dias; conservamos o registo da eliminação efetuada (apenas identificadores internos e o estado, sem nomes nem contactos) como prova de que tratámos o seu pedido, e isso por 3 anos a partir do tratamento. Na mesma medida (identificador interno aleatório da conta ou da família, tipo de eliminação e hora) mantemos um registo das eliminações efetuadas, para que, após um eventual restauro da base de dados a partir de uma cópia de segurança, todas as eliminações posteriores sejam novamente aplicadas. O servidor elimina o registo do diário na base de dados, o mais cedo, 180 dias após a sua criação, e apenas depois de o ter copiado para um armazenamento separado (a cópia é geralmente criada em poucos minutos); o registo que não for copiado não é eliminado pelo servidor até que a cópia seja bem-sucedida. A cópia no armazenamento separado não público é eliminada pelo próprio armazenamento 60 dias após o seu armazenamento. A exportação encriptada do diário, que faz parte da cópia de segurança da base de dados, extingue-se juntamente com a cópia de segurança (o mais tardar após 30 dias).
Pedidos de consentimento parental: um pedido aberto é válido por 14 dias; só é prorrogado se, entretanto, for adicionado um progenitor à família (no caso de um pedido de eliminação da família, o novo progenitor recebe os seus próprios 14 dias, no máximo, porém, até ao fim de um eventual período de proteção após a remoção de outro progenitor), ou após o restauro da base de dados a partir de uma cópia de segurança (exceto o pedido de eliminação da família, que é válido apenas até ao fim do período de proteção). Um pedido para eliminar a família, que caducaria durante o prazo de 14 dias após a remoção de outro progenitor, perdura até ao fim desse prazo e depois caduca. Durante o prazo de 14 dias após a remoção de outro progenitor, a família não pode ser eliminada; um pedido para eliminar a família apresentado neste prazo caduca após o seu termo. Após o termo do prazo, o único progenitor restante pode eliminar a família diretamente no Perfil. O servidor elimina o pedido concluído após 90 dias.
Impressão digital do número de telemóvel após a eliminação da conta ou a alteração do número: para que o período de teste Premium não possa ser obtido repetidamente através da eliminação da conta e de um novo registo, aquando da eliminação da conta de um pai/mãe que tenha sido membro de uma família durante o seu período de teste e aquando da alteração do número de tal pai/mãe (mesmo que o suporte altere o número a seu pedido), o servidor guarda apenas a impressão digital do número de telemóvel anterior (HMAC com chave secreta) e a hora – não o número em si. Um novo registo com o mesmo número não terá direito ao período de teste. O servidor elimina a impressão digital após 12 meses.
E-mails que nos envia: durante o tempo necessário para tratar a sua questão ou pedido e para documentar como o tratámos.
Registo de intervenções do suporte e de gestão: o registo da intervenção na base de dados (tipo de intervenção, quem a realizou, quando, a que família diz respeito e número do pedido – sem nomes nem números de telemóvel; assim registamos a recuperação do número e o término de sessão de dispositivos pelo suporte, a exportação de dados da família a pedido e a gestão de códigos promocionais e de acesso gratuito) é eliminado pelo próprio servidor após 3 anos. O diário de pedidos de suporte (número do pedido, data, identificador interno da conta, método de verificação de identidade e resultado – sem número de telemóvel) é mantido de forma encriptada fora da base de dados e também é conservado durante 3 anos como comprovativo de como tratámos o pedido.

Os registos operacionais e de segurança de produção do alojamento podem ser conservados no máximo 30 dias. O Sentry conserva os relatórios técnicos de erros da app e do servidor no máximo 90 dias, para que possamos identificar e corrigir erros que apenas se manifestem após o lançamento de uma nova versão da app; eventuais cópias de segurança operacionais do Sentry expiram o mais tardar 90 dias após a sua criação. As cópias de segurança da base de dados são feitas diariamente, encriptadas antes do envio do ambiente de produção e eliminadas 30 dias após a sua criação, pelo que os dados anteriormente eliminados permanecem nelas no máximo 30 dias; não são utilizadas para a recuperação normal de uma conta eliminada. Se tivermos de restaurar a base de dados a partir de uma cópia de segurança, voltaremos a aplicar as eliminações efetuadas após a criação da cópia de segurança de acordo com o registo de eliminações. As configurações do alojamento, da base de dados e do armazenamento têm de impor tecnicamente estes prazos, e o operador verifica-as regularmente.

Se a eliminação do registo junto do fornecedor externo de subscrições não puder ser concluída imediatamente, a Kimda anonimiza sem mais demora os dados pessoais locais depois de remover os ficheiros multimédia. Para repetir em segurança o pedido externo, conserva apenas um identificador interno aleatório da família e o estado técnico da eliminação, não nomes nem números de telemóvel. O servidor elimina o registo sobre esta tarefa de eliminação externa (identificador interno da família, designação do fornecedor, número de tentativas, horas e código do último erro, sem nomes nem números de telemóvel) 90 dias após a sua conclusão; uma tarefa não concluída é conservada até ser concluída.

Conservamos a prova de consentimento para o início imediato do Premium (identificadores internos da família e do utilizador, hora do consentimento, plano escolhido, início do período pago, identificador da transação da loja, identificador interno da tentativa de compra e versão do texto apresentado) durante o tempo necessário para provar este consentimento num eventual litígio, por norma 3 anos a partir da sua concessão. Após o termo deste prazo, a prova é eliminada de forma controlada. A prova não é eliminada juntamente com a conta nem com a família (ponto 7). Guardamos também uma cópia da mesma (sem o identificador interno da tentativa de compra) num armazenamento separado não público Cloudflare R2 (ponto 4), para que a prova sobreviva à perda da base de dados entre cópias de segurança; o próprio armazenamento elimina-a 1125 dias após o seu armazenamento.

7. Os seus direitos

Tem o direito:

ao acesso a todos os dados que a app conserva sobre si e a sua família (Art. 15 RGPD),
à retificação de dados inexatos (Art. 16 RGPD) – pode alterar o número de telemóvel autonomamente em O meu perfil após verificar o novo número através de código SMS; se perder o acesso à conta (por exemplo, porque outra pessoa alterou o número a partir de um dispositivo com sessão iniciada), alteramo-lo a seu pedido após verificação de identidade,
à eliminação da conta de um membro individual (Art. 17 RGPD) – diretamente na app (O meu perfil → Eliminar conta), a app elimina ou anonimiza de forma irreversível o nome, o telemóvel, a foto e o token push e elimina todas as fotos que carregou; no caso da conta de uma criança, também as fotos das suas tarefas que o pai/mãe carregou por ela. Deixa de ser possível iniciar sessão com essa conta e não fica nela qualquer nome ou contacto. No histórico de tarefas e pagamentos permanecem apenas os factos contabilísticos indispensáveis à continuidade do resto da família (pontos, montante, estado e hora); a nota livre é eliminada e os nomes das tarefas e objetivos são substituídos por um valor neutro. Este histórico não é eliminado, porque continua ligado ao resto da família (caso contrário, a sua continuidade contabilística mútua deixaria de bater certo), mas fica associado apenas a um registo sem nome nem contacto. Os registos de pagamentos diretos e reembolsos manuais da criança (ponto 2) são eliminados juntamente com a criança. O servidor elimina da base de dados os registos do diário de alterações de telemóvel e de estado do membro (ponto 2); a sua cópia no armazenamento separado extingue-se o mais tardar 60 dias após o armazenamento. Se a criança tiver uma dívida, um saldo ou pedidos pendentes, a app mostrar-lhe-á antes da eliminação que montantes irá perder, e a eliminação tem de ser expressamente confirmada; os pais receberão depois um aviso genérico. Um membro que o pai/mãe removeu da família pode, após verificação por código SMS na app, eliminar definitivamente a sua conta por si próprio e libertar assim o seu número de telemóvel,
à eliminação em cascada da família inteira – quando o pai ou mãe confirma expressamente a eliminação da família inteira, anonimizamos todos os seus membros, eliminamos as suas fotografias e, além disso, substituímos os textos livres e os nomes das tarefas, objetivos e recompensas personalizados por valores neutros; eliminamos também os registos de pagamentos diretos e reembolsos manuais da família (ponto 2), o histórico de alterações das regras financeiras da família (na próxima limpeza) e os registos do diário de alterações de telemóvel e de estado do membro dos seus membros (a cópia do diário no armazenamento separado extingue-se o mais tardar 60 dias após o armazenamento). A remoção de outro pai/mãe exige o consentimento do pai/mãe visado: a recusa expressa impede a ação; sem resposta, é executada após 14 dias. A eliminação da família inteira em que exista outro pai/mãe exige o consentimento expresso de cada um dos outros pais; sem o consentimento de todos, o pedido é cancelado após 14 dias e a família não é eliminada. Uma família da qual tenha sido removido outro pai/mãe nos últimos 14 dias só pode ser eliminada decorridos pelo menos 14 dias após a sua remoção. Os registos contabilísticos sobre a família eliminada, incluindo os saldos e o estado dos empréstimos e das poupanças das crianças, são removidos da base de dados operacional no prazo máximo de 30 dias após a eliminação; podem permanecer nas cópias de segurança encriptadas, no máximo, por mais 30 dias até que a cópia de segurança seja eliminada. O documento comprovativo do consentimento com o início imediato do Premium não é eliminado com a eliminação da família (ponto 6). Os registos anonimizados da utilização de códigos de parceiro, que não contêm dados pessoais, são conservados para o registo de parceiros e proteção contra o uso indevido. Depois de removidos os ficheiros multimédia, a anonimização local é efetuada mesmo quando a RevenueCat está temporariamente indisponível; o pedido externo é posteriormente repetido em segurança apenas com o identificador interno da família. A RevenueCat efetua a eliminação de forma assíncrona. Isto não cancela a subscrição gerida pela App Store ou pelo Google Play – os pais têm de a cancelar separadamente nas definições da respetiva loja,
à limitação do tratamento (Art. 18 RGPD), por exemplo, quando contestar a exatidão dos dados, durante o período necessário para a verificarmos,
à portabilidade (Art. 20 RGPD) – fornecer-lhe-emos os dados que nos forneceu e que tratamos com base num contrato num formato estruturado, de uso corrente e de leitura automática (p. ex., JSON), ou, a seu pedido, transmiti-los-emos a outro responsável, se for tecnicamente viável,
de se opor (Art. 21 RGPD) ao tratamento com base no nosso interesse legítimo (ponto 2); nesse caso, cessaremos o tratamento, a menos que demonstremos motivos legítimos imperiosos que prevaleçam sobre os seus interesses, direitos e liberdades, ou precisemos dele para a declaração, o exercício ou a defesa de um direito num processo judicial,
de retirar o consentimento a qualquer momento (Art. 7(3) RGPD) – pode retirar o consentimento para a medição de publicidade no site através da ligação "Definições de cookies" no rodapé do site (ponto 9); a retirada não afeta o tratamento anterior à mesma,
de apresentar reclamação a uma autoridade de controlo (Art. 77 RGPD) – na República Checa é o Gabinete de Proteção de Dados Pessoais (Úřad pro ochranu osobních údajů), Pplk. Sochora 27, 170 00 Praha 7, web uoou.gov.cz; também se pode dirigir à autoridade de controlo do Estado-Membro da UE onde reside ou trabalha.

Envie o pedido para privacy@kimda.app. Para não entregarmos nem eliminarmos os dados de outra pessoa, primeiro verificaremos se o pedido é apresentado pelo titular da conta (por exemplo, através de confirmação a partir do número de telemóvel associado à conta); nunca nos envie códigos de SMS de início de sessão. A única exceção é o código do SMS com a indicação “Kimda obnova účtu”, que o suporte solicitará apenas em resposta ao seu próprio pedido de devolução de conta usurpada, ou à sua própria confirmação de um pedido idêntico de outro pai/mãe da sua família (ponto 2); mesmo assim, comunique-o apenas ao suporte, nunca a outro membro da família. O suporte solicita este código exclusivamente por e-mail do endereço support@kimda.app com o número do seu pedido, nunca por telefone nem através de outro membro da família. Tratamos o pedido de acesso ou portabilidade exportando os dados da família no formato JSON (sem tokens de início de sessão e as suas impressões digitais e sem as impressões digitais dos números de telemóvel originais dos registos de segurança, que servem apenas para verificar um pedido de devolução de conta, e sem o diário de alterações de telemóvel e de estado do membro, que serve apenas para proteção contra a usurpação do número; a exportação contém os registos de pagamentos diretos e reembolsos manuais (ponto 2); para as fotos, contém a sua impressão digital técnica de acordo com o ponto 3, a pedido, forneceremos as próprias fotos separadamente); registamos cada exportação (quem a preparou, quando e com base em que pedido). A pedido, comunicar-lhe-emos os dados sobre os eventos do diário de alterações de telemóvel e de estado do membro (tipo e hora, sem impressões digitais). Responderemos sem demora injustificada, no prazo máximo de um mês; em casos complexos, podemos prorrogar o prazo por mais dois meses, do que o informaremos atempadamente. Os direitos da criança podem ser exercidos pelo pai/mãe como representante legal em seu nome.

8. Segurança

A app não utiliza palavras-passe (o início de sessão é feito apenas através de um telemóvel verificado). O acesso é protegido por um token de início de sessão de curto prazo com validade de 15 minutos e um token de atualização, que o servidor guarda apenas como impressão digital; em caso de uso repetido comprovado de um token de atualização já substituído, o servidor termina a sessão da conta em todos os dispositivos, cancela os seus registos para notificações, escreve um registo de segurança e avisa os outros pais. Em produção, a comunicação entre a app e o servidor é feita por HTTPS. As fotografias estão num armazenamento não público e, antes de as disponibilizar, o backend verifica a conta e a pertença à mesma família. As cópias de segurança da base de dados são encriptadas antes da transmissão e só podem ser desencriptadas com uma chave privada guardada fora da cloud; os códigos promocionais estão na base de dados apenas como impressão digital HMAC com a chave fora da base de dados e registamos a gestão dos códigos promocionais. O servidor não escreve números de telemóvel, tokens nem o conteúdo dos pedidos nos registos operacionais.

9. Site kimda.app e cookies

Este ponto aplica-se apenas aos visitantes do site kimda.app e não à utilização da app. O site funciona na rede da Cloudflare, que, em cada visita, trata tecnicamente o endereço IP e dados sobre o navegador para poder disponibilizar a página e protegê-la contra ataques; a Cloudflare conserva os registos para o diagnóstico de erros do site no máximo 3 dias. Consoante o idioma do navegador (na ligação de transferência também consoante o tipo de dispositivo), o site reencaminha-o para a versão adequada da página. O fundamento jurídico é o nosso interesse legítimo num site seguro e funcional (Art. 6(1)(f) RGPD). O tema escolhido fica guardado apenas no seu navegador (localStorage). A sua decisão sobre cookies é guardada no localStorage e num cookie técnico estritamente necessário kimda-consent-proof (validade de 180 dias), que contém apenas o tipo de escolha e a hora da decisão, sem qualquer identificador de pessoa ou de conta. O seu navegador envia-o tecnicamente com cada pedido ao site; o servidor não o avalia, serve apenas ao script no seu navegador para verificar que o consentimento não foi retirado. Este cookie não requer consentimento e não é utilizado para medição nem para publicidade.

Só se escolher "Aceitar" na barra do site é que este carrega o Meta Pixel da Meta Platforms Ireland Limited. Este guarda um cookie no navegador (por exemplo, _fbp com validade até 90 dias) e envia à Meta dados sobre a visita: a página visitada, o endereço IP, dados sobre o navegador e o identificador do cookie. Serve-nos para medir a eficácia dos anúncios no Facebook e no Instagram. O fundamento jurídico é o seu consentimento (Art. 6(1)(a) RGPD e o artigo 89.º(3) da Lei n.º 127/2005 sobre comunicações eletrónicas). Somos responsáveis conjuntamente com a Meta pela recolha e transmissão destes dados; o tratamento posterior dos mesmos, incluindo uma eventual transferência para os EUA com base no quadro EU-USA de proteção de dados (Data Privacy Framework), é efetuado pela Meta como responsável pelo tratamento independente, de acordo com a sua política em facebook.com/privacy/policy. Nunca enviamos à Meta dados da app, da conta ou da família.

Sem consentimento, o Meta Pixel não é carregado de todo. Pode retirar o consentimento a qualquer momento através da ligação "Definições de cookies" no rodapé do site; o site elimina então os cookies do Pixel e deixa de o carregar.

Se através da página para testadores se juntar ao grupo de testadores no Google Groups, o administrador do grupo verá o e-mail da sua conta Google; usá-lo-emos apenas para testar a app e para o acesso à sua versão de teste no Google Play. A Apple distribui a versão de teste para iPhone através do TestFlight. A Google e a Apple tratam os dados como responsáveis independentes de acordo com as suas políticas. O fundamento jurídico é o seu pedido de participação nos testes (Art. 6(1)(b) RGPD). O e-mail permanecerá no grupo até que anule a subscrição do mesmo ou até que os testes terminem.

10. Alterações a esta política

Informá-lo-emos na app e no site kimda.app de qualquer alteração substancial a esta política. A app reconhece qual a versão da política que aceitou: pedirá aos pais que confirmem a nova versão (e, se for o caso, o consentimento pelas crianças), a criança tomará conhecimento da mesma. Registaremos a hora e a versão da confirmação.

11. Contacto

Questões sobre a proteção de dados pessoais: privacy@kimda.app