Arquitetura de conta familiar e UX de consentimento — como os melhores produtos fazem

Resultados

Apple: Compartilhamento Familiar, Contas Infantis, Pedir para Comprar, API de Faixa Etária Declarada

Um organizador (pai/mãe, 18+, com Apple ID próprio) designa membros da família, incluindo crianças. As compras de um membro infantil são encaminhadas através do Ask to Buy: compras na App Store/iTunes/Books, compras dentro do app e upgrades de armazenamento iCloud geram uma solicitação que o organizador aprova ou nega antes de ser concluída [1]. As contas infantis são criadas e gerenciadas dentro do grupo familiar do organizador, nunca auto-registradas.

A mais recente Declared Age Range API (iOS/iPadOS/macOS 26, apresentada no WWDC 2025) permite que um app leia uma categoria de idade que preserva a privacidade (menor que 13 / 13–17 / 18+) em vez da data de nascimento. A idade é definida uma única vez, na criação da conta ou via Screen Time/Family Sharing, e os apps a leem por meio de uma API Swift sem ver a data de nascimento subjacente [2][3]. Ela é lançada junto com um mecanismo de Significant Change (PermissionKit) para novo consentimento quando o conjunto de recursos do app muda, e Notificações de Servidor quando um pai revoga o consentimento. A Apple apresenta isso como ferramenta de conformidade para as leis de garantia de idade de 2025–2026 (Texas, Louisiana, Utah, Brasil, Austrália, Cingapura) — um sinal de idade independente de jurisdição, não um método VPC.

Google Family Link

Um pai/mãe 18+ cria uma Conta Google para uma criança menor que 13 (ou idade de consentimento local) via Family Link, no mesmo país da criança [4]. A conta é marcada como supervisionada: o pai aprova/bloqueia instalações e compras no Play, define limites de tempo de tela e horários de dormir, filtra conteúdo adulto e visualiza a localização do dispositivo. O login é um login normal de Conta Google; em um dispositivo compartilhado, as contas de pai e filho coexistem e a criança alterna via o alternador de contas padrão do Android. Os detalhes exatos da mecânica de “graduação” da Google aos 13+ não puderam ser confirmados a partir de uma fonte primária obtida nesta sessão e devem ser verificados separadamente.

Microsoft Family Safety / Xbox / Minecraft

Family Safety agrupa a Conta Microsoft de um pai com contas infantis, oferecendo limites de tempo de tela, filtragem de conteúdo e resumos de atividade em Windows, Xbox e Android [5]. O Minecraft autentica através do mesmo sistema de Conta Microsoft, portanto sua interface parental é o grupo familiar Xbox/Microsoft: a própria Conta Microsoft da criança faz login, e as configurações familiares controlam o acesso a multiplayer/Realms, chat e classificações. O fluxo exato de criação e as mecânicas de transição 13/18 não puderam ser obtidos nas páginas acessadas nesta sessão (apenas conteúdo de visão geral carregado) e devem ser re-verificados antes de citar detalhes específicos.

Nintendo Switch parental controls

Um pai/mãe (18+) precisa de uma Conta Nintendo e emparelha o aplicativo gratuito Nintendo Switch Parental Controls ao(s) console(s) da casa [6]. Controles: filtragem de jogos baseada na classificação ESRB, limites diários/noturnos de tempo de jogo, restrição de mensagens/GameChat a contatos aprovados, exigência de aprovação para videochamadas com menores de 16 anos, bloqueio de compartilhamento de capturas de tela em redes sociais e limites de gasto na eShop. Isso é uma restrição de perfil ao nível do console, e não uma identidade infantil distinta autenticada — não é necessária uma conta separada protegida por senha para jogar; um PIN de pai/mãe substitui as restrições no console compartilhado.

Netflix and Disney+ kids profiles

Ambos utilizam perfis dentro de uma única conta familiar paga, não contas infantis separadas. O perfil Kids da Netflix oculta conteúdo acima de uma classificação de maturidade configurável e pode ficar protegido por um PIN numérico de Bloqueio de Perfil; a Disney+ oferece um modo Junior semelhante mais PIN de perfil. Esse é o padrão mais leve encontrado: nenhuma identidade infantil persiste fora da conta familiar, nada a migrar aos 13/18, e a fronteira de “consentimento” é a fronteira de compra da família, não a de coleta de dados de menor — nem um operador COPPA coleta PII de menor para criar uma conta, por isso os perfis são suficientes. (As páginas de centro de ajuda não foram acessíveis nesta sessão devido a bloqueio de bots; são recursos estáveis e bem estabelecidos, não resumidos de uma fonte ao vivo — verifique se for necessário copiar exatamente a interface.)

Roblox parental controls and age verification

Roblox exige uma conta para jogar (modo convidado removido em 2017); desde uma reformulação em novembro de 2024, um pai pode criar uma conta de pai vinculada separada que controla tempo de tela, mensagens privadas e configurações de comunicação. Desde dezembro de 2025 (primeiros mercados)/janeiro de 2026 (global), o Roblox exige verificação de idade para qualquer comunicação dentro da plataforma, via fornecedor Persona: upload de documento de identidade governamental ou vídeo de estimativa facial de idade, com correção manual se a estimativa estiver errada; usuários verificados são agrupados em faixas etárias (por exemplo, um usuário de 12 anos pode enviar mensagens apenas para idades 9–15) [7]. Este é um exemplo atual e em produção de estimativa facial de idade implantada em escala de consumo para controlar comunicação em vez de criação de conta — relevante caso o Math Challenge venha a considerar recursos de chat/social.

Khan Academy, Duolingo, Prodigy

Khan Academy Kids (idades 2–7) é um aplicativo gratuito separado; a Khan Academy propriamente dita usa um modelo de treinador-aluno onde um professor cria uma turma e um fluxo separado permite que um pai visualize o progresso — os detalhes exatos de login da criança não puderam ser confirmados a partir de uma fonte ao vivo nesta sessão. Duolingo ABC (2020, pré-leitores, sem anúncios/IAP) é totalmente separado do produto principal; o Super Duolingo Family Plan agrupa assinaturas familiares, mas os detalhes exatos de vinculação pai-filho não puderam ser verificados a partir de uma fonte primária e devem ser checados diretamente antes de usá-los como referência de design.

Prodigy separa a conta de jogo da criança (geralmente criada pela escola para uso em sala) de uma conta de pai que o pai cria independentemente e vincula à criança, desbloqueando um painel de Associação: relatórios de progresso em tempo real e mensais, definição de metas, recompensas no jogo e planilhas imprimíveis [8]. Esse é o análogo existente mais próximo ao modo professor do Math Challenge: a identidade da criança na sala de aula existe primeiro, e um pai posteriormente anexa sua própria conta para monitorar e autorizar, em vez de criar a criança do zero.

Verifiable parental consent (VPC) under COPPA

A FTC certificou programas de porto-seguro cujos membros projetam seu próprio fluxo VPC aprovado: TrustArc, ESRB, CARU, PRIVO, Samet Privacy/kidSAFE, iKeepSafe (Aristotle Inc. retirou-se em agosto de 2021) [9]. Fora do porto-seguro, a COPPA §312.12 permite que qualquer operador solicite aprovação de um método inovador — o processo que a PRIVO usou em 2023 para obter aprovação de um método de estimativa facial de idade (construído sobre a tecnologia Yoti) como ferramenta de verificação de consentimento. Métodos enumerados de base: um formulário assinado (correio/fax/escaneamento), uma transação monetária (cobrança de cartão), um número gratuito com equipe treinada, uma videoconferência com pessoal treinado e verificação de documento governamental cruzada com foto ao vivo — este último, “comparação facial com documento de foto verificado” (FMVPI), foi uma aprovação da FTC datada de 19 de novembro de 2015 [9][10]. Nota de verificação: as emendas finais da Regra COPPA de janeiro de 2025 (relatadas como efetivas em junho de 2025) são amplamente descritas como adicionando novos métodos enumerados e apertando o consentimento de divulgação a terceiros, mas as páginas de regra/comunicado de imprensa da ftc.gov retornaram 403/404 ao acesso automatizado nesta sessão — apenas contexto, confirme antes de confiar nisso.

Age-assurance vendors: k-ID and Yoti

k-ID é uma plataforma de conformidade: AgeKit (classificação de idade grosseira gratuita), AgeKit+ (verificação de alta garantia via estimativa facial, checagens de ID ou credenciais reutilizáveis), Family Connect (portal de consentimento parental com aprovação em nível de portfólio em títulos de clientes, alegando taxas de conclusão de até 96%), AgeKey (credencial de idade reutilizável entre plataformas) e neimo (rastreio regulatório) — alegando cobertura em mais de 200 jurisdições, incluindo COPPA, GDPR Artigo 8, o Código de Design Apropriado para Idade do Reino Unido/Online Safety Act, a lei australiana para menores de 16 anos e equivalentes do Brasil/Índia [11]. O produto de estimativa facial de idade da Yoti não pôde ser obtido diretamente nesta sessão (403) — suas alegações de precisão e certificações devem ser verificadas diretamente em yoti.com antes de citar números.

Classroom-join patterns

Google Classroom: cada turma tem um código de classe gerado automaticamente, reapresentável nas Configurações; um estudante ingressa ao fazer login em classroom.google.com e inserir o código [12]. O Workspace for Education tem limites por turma (50 professores, 1.000 membros) via Google Groups; contas pessoais enfrentam limites de atividade, e convites entre domínios são restritos a menos que um código/link compartilhável seja usado. Clever é uma camada de listagem/SSO, não uma camada de consentimento: importa dados de lista de um SIS escolar e fornece um único login em ferramentas ed-tech; a responsabilidade de consentimento fica com a escola (geralmente a exceção “funcionário escolar” da FERPA, permitindo que a escola autorize um fornecedor em seu nome) ou com o próprio fluxo COPPA do fornecedor. Kahoot usa um PIN de jogo: hospedar requer registro, mas ingressar em um jogo ao vivo precisa apenas do PIN, sem conta — o padrão de ingresso de menor atrito encontrado, construído para participação anônima e efêmera sem identidade persistente ou estado de consentimento.

Tabela comparativa de mecanismos de consentimento

Método	Atrito (pai)	Custo por consentimento	Aceito por	Recomendação
Formulário assinado (correio/fax/escaneamento)	Alta, lenta	Baixo $, alto custo operacional	FTC enumerated [9]	Não — muito lento para integração
Microcobrança em cartão de crédito/débito	Média — requer cartão	Taxa de processador + risco de fraude	FTC enumerated [9]	Só se a MC cobrar por uma assinatura
Número gratuito, equipe treinada	Alta — equipe real	Alta (mão de obra)	FTC enumerated [9]	Não — inviável em escala PWA
Videoconferência, equipe treinada	Alta — agendamento	Alta (mão de obra)	FTC enumerated [9]	Não
ID governamental + correspondência de foto ao vivo (FMVPI)	Média-alta	Taxa do fornecedor (unverified)	FTC-approved 2015 [9][10]	Não — desproporcional para um app de matemática
Estimativa de idade facial (Yoti/k-ID/PRIVO)	Baixa-média, segundos	Taxa do fornecedor (unverified)	FTC-approved via §312.12 (2023) [9][11]	Não necessário para “é este um pai”; relevante apenas para futuro chat/controle por faixa etária
E-mail + clique	Baixa	Quase zero	Lower COPPA bar (internal use only)	Boa camada base combinada com controle apenas por pais
Criação de conta controlada por pais, sem auto-registro da criança	Baixa para o pai, zero para a criança	Quase zero	Contorna VPC — o gatilho de consentimento é a coleta de PII de uma criança, o que nunca ocorre aqui	Padrão primário recomendado — corresponde a Apple/Google/Microsoft/Prodigy
Credencial de idade reutilizável (k-ID AgeKey, Apple Declared Age Range)	Muito baixa após a primeira verificação	Amortizado	Emergente; não é um método VPC	Monitorar, não necessário no MVP

Implicações de design para Math Challenge

1. Três entidades: Parent (credenciais, e-mail verificado), ChildProfile (pertence a exatamente um pai, sem credenciais independentes por padrão), Teacher (credenciais, cria Classroom). Um Classroom contém muitas referências de ChildProfile, cada uma com seu próprio registro de autorização por pai — espelha a identidade infantil primeiro da sala de aula da Prodigy mais a anexação da conta do pai [8], e o fluxo de ingresso por código do Google Classroom [12].
2. Sem auto-registro de criança, jamais — corresponde ao design decidido e Apple/Google/Microsoft [1][4][5]. Como a criança nunca fornece PII de forma independente, isso se enquadra na linha mais leve de “criação controlada por pais” acima, não em uma cerimônia completa de VPC da COPPA por criança.
3. Login da criança em tablet compartilhado, menos de 5 segundos, sem leitura: grade de avatares (ícone/cor escolhido pelos pais) + teclado numérico PIN de 4 dígitos, sem teclado — ecoa o PIN-override da Nintendo [6] e o Bloqueio de Perfil da Netflix, dimensionado para pré-leitores; mais rápido e mais agnóstico a dispositivos que QR ou biometria.
4. Atalho “último perfil” vinculado ao dispositivo: em um dispositivo pessoal, lembrar o último perfil usado e ir direto para “toque para continuar”, retornando à grade de avatares somente quando um segundo perfil for detectado — mantém o caso comum de uma criança por tablet em ~1 toque.
5. PIN do pai, separado dos PINs das crianças, para acessar configurações da conta, adicionar/remover crianças ou aprovar a entrada em uma sala de aula — mesma forma que o PIN de sobrescrita da Nintendo [6] e o Bloqueio de Perfil da Netflix, aplicado para proteger ações apenas de pais.
6. Professor convida por código de turma, não busca por e-mail: um código de 6 caracteres (evitando 0/O, 1/I) exibido como texto/link/QR — espelha o Google Classroom [12] e o PIN do Kahoot, mas ao contrário da sessão efêmera do Kahoot, deve persistir e ser controlado por aprovação dos pais.
7. Entrada na sala de aula é um aperto de mão em duas etapas: (a) o pai adiciona o código a partir de seu próprio painel, nunca do dispositivo da criança; (b) o status torna-se pendente ou ativo conforme modelo de confiança; (c) o pai sempre mantém um controle “Remover da sala de aula”, atendendo ao requisito “qualquer pai pode retirar sua criança a qualquer momento”.
8. Modelar autorização como uma tabela de associação, não como booleano: ClassroomMembership(child_profile_id, classroom_id, parent_id, status: pending|approved|revoked, approved_at, revoked_at) — um registro de auditoria gratuito caso surja uma disputa de consentimento.
9. Lógica de faixa etária baseada na idade declarada pelos pais, não em data de nascimento inserida pela criança: armazenar birth_year_month em ChildProfile, inserido uma vez pelo pai; derivar “menor que 13”/“13+” apenas no servidor — ecoa a filosofia da Apple de Declared Age Range de expor uma categoria, não uma data [2][3].
10. Aos 13 anos: não é uma barreira rígida para um app que coleta PII mínima, mas defina um evento (child_profile.crossed_13) que deixa de tratar o perfil como “criança” para qualquer prática futura relevante à COPPA (chat, análise de marketing) e, opcionalmente, ofereça ao pai um prompt de conversão de conta. Modele a conversão como acionada pelo pai, não automática — o padrão de graduação ao atingir a idade de consentimento da Google/Microsoft existe [4][5], mas os mecanismos exatos não foram confirmados independentemente nesta sessão, portanto não os copie cegamente.
11. Aos 18 anos (ou maioridade local): oferecer um fluxo explícito “converter para conta independente” que exige que o usuário agora adulto defina suas próprias credenciais, após o que o perfil se desvincula e o pai perde a visibilidade padrão — o formato geral corresponde às saídas de grupos familiares da Apple/Google/Microsoft, embora nenhuma fonte desta sessão tenha fornecido um mecanismo preciso; valide contra a documentação atual antes de implementar.
12. Não construa estimativa de idade facial ou consentimento com ID governamental para o MVP. O design decidido já protege todos os dados da criança atrás de uma conta de pai registrada, portanto a exposição se assemelha mais a “e-mail + criação controlada por pais” do que a um operador COPPA coletando PII de uma criança sem supervisão. Revisite apenas se um recurso futuro permitir que a criança forneça PII a terceiros (ex.: placar público com nome real) ou que a criança inicie a criação de conta sem supervisão.
13. Reserve o caminho §312.12/safe-harbor apenas se a assessoria determinar que o VPC completo da COPPA se aplica — Netflix, Disney+ e Nintendo usam perfis em vez de contas especificamente para evitar ser um “operador que coleta PII de uma criança” da COPPA; o modelo de Math Challenge onde o pai cria o perfil deve buscar a mesma forma legal.
14. Roteirização Clever/ClassLink é Fase 2+, não MVP: resolve importação em massa de SIS e SSO, relevante apenas quando o Math Challenge tiver clientes institucionais/distritais; o modelo de código de turma (item 6) é suficiente para iniciar, correspondendo ao modo como Kahoot e Google Classroom funcionam antes de qualquer integração SIS existir.

Perguntas abertas para o dono do projeto

1. O PIN do pai para sair do Modo Infantil deve ser compartilhado entre todas as crianças do pai, ou por criança?
2. A entrada na sala de aula deve exigir também confirmação do professor (aperto de mão bilateral), ou a aprovação do pai é suficiente?
3. Aos 13 anos, o Math Challenge deve solicitar proativamente a conversão de conta, ou deixá-la indefinida até que o usuário/pai a inicie?
4. Algum recurso planejado (chat, placar com nome real, conteúdo gerado por usuário) provavelmente elevará o nível da COPPA/VPC além da “criação de perfil controlada por pais” — isso altera se os itens 12–13 permanecem válidos?
5. Os tablets de sala de aula compartilhados devem suportar múltiplas crianças via a grade de avatar+PIN, ou assume-se um tablet-por-criança no lançamento inicial?