Segurança, performance e sprint 1

No fim desta aula consegues

• Identificar os riscos do OWASP Mobile Top 10 que mais aparecem em apps Flutter.
• Tirar os segredos do repositório e passá-los com --dart-define ou ficheiro ignorado pelo git.
• Explicar o que o certificate pinning protege e o que custa manter.
• Pedir só as permissões necessárias, no momento certo, e cumprir o mínimo de privacidade: RGPD, App Tracking Transparency e formulários das lojas.
• Explicar o que é um isolate e quando usar compute() em vez de async/await.
• Identificar rebuilds desnecessários e reduzi-los com const, divisão de widgets e Selector.
• Medir a tua app em modo profile com o performance overlay e o DevTools, e dizer o que é jank.
• Fechar a sprint 1 com PRs merged, app a correr e demo preparada.

OWASP Mobile Top 10: os que mais aparecem

Para os testes: os três que mais aparecem são segredos no código, armazenamento inseguro e comunicação insegura.

Segredos: o que um atacante tira de um APK em 5 minutos

• Um APK é um zip: unzip app.apk, strings libapp.so | grep -i secret. O jadx descompila o Kotlin; o Dart compilado em AOT continua a ter as strings legíveis.
• Consequência: tudo o que vai no binário é público. Um "segredo" no cliente não é segredo, é ofuscação.
• Nunca no repositório: .env.json no .gitignore; --dart-define-from-file=.env.json em desenvolvimento; no CI vêm de GitHub Secrets.
• Se já foi commitado, está comprometido: rodar o segredo (pedir outro ao docente). Apagar do histórico não chega: alguém já clonou.
• O que pode ir no cliente: chaves públicas com restrição (Maps limitada ao package), identificadores sem poder. O que não pode: chaves de API com escrita, passwords, client secrets de OAuth.

Para os testes: tudo o que está no APK é público; segredos vivem no servidor ou entram por dart-define e nunca no git.

HTTPS sempre; certificate pinning quando vale a pena

• HTTPS é obrigatório: o Android bloqueia tráfego em claro desde a versão 9; o iOS exige TLS 1.2+ via App Transport Security. Desligar isto para "testar" é o erro M5.
• HTTPS protege de quem está no meio (Wi-Fi do café), mas confia em qualquer CA instalada no sistema. Um proxy com certificado instalado (Charles, mitmproxy) vê tudo.
• Pinning: a app só aceita o certificado ou a chave pública que conhece. O proxy deixa de funcionar; uma CA comprometida também.
• Custo: quando o certificado roda, as versões antigas da app deixam de ligar. Precisa de pin de reserva, plano de rotação e forced update (aula 30).
• Quem faz: bancos, saúde, apps com ataque dirigido. Uma app de meteorologia não precisa. Em Flutter: SecurityContext ou http_certificate_pinning.

Para os testes: pinning protege contra CAs comprometidas e proxies, ao custo de manutenção sempre que o certificado roda.

Permissões mínimas, pedidas no momento certo

• Cada permissão é uma pergunta ao utilizador e uma linha na revisão da loja. Pede só o que a funcionalidade precisa: localização aproximada chega para "localidade mais próxima".
• No momento certo: quando toca em "Perto de mim", não no arranque. Um ecrã a explicar antes do diálogo do sistema (pre-prompt) sobe a taxa de aceitação.
• Justificação obrigatória: NSLocationWhenInUseUsageDescription no iOS e a declaração de uso no Google Play. Texto vago ("precisamos da localização") é motivo de rejeição.
• Negação: a app continua a funcionar (lista completa em vez de "perto de mim"). Negação permanente: botão que abre as Definições, sem insistir.
• O que as lojas rejeitam: permissões sem funcionalidade visível, localização em background sem razão forte, SMS e registo de chamadas fora das apps por defeito.

Para os testes: permissão mínima, pedida em contexto, com justificação, e a app funciona se for negada.

Privacidade: RGPD, ATT, labels e data safety

• RGPD: base legal para cada dado recolhido, minimização, direito a apagar. Consentimento explícito e não pré-marcado para analytics e marketing.
• App Tracking Transparency (iOS 14.5+): diálogo obrigatório antes de rastrear o utilizador entre apps. Sem "Permitir", sem IDFA. A Apple rejeita quem tenta contornar.
• Privacy nutrition labels (App Store) e Data safety form (Play): declaras o que recolhes e porquê. Uma declaração falsa é motivo de remoção.
• Na prática: política de privacidade com URL público, mesmo para uma app de tempo. Logs e crash reports sem dados pessoais.
• No Tempo Açores: localização usada uma vez para a localidade mais próxima e não guardada; favoritos ligados ao grupo, não a pessoas.

Para os testes: o ATT pede-se antes de rastrear; as labels e o data safety form têm de bater certo com o que a app faz.

Ofuscação e deteção de root em uma frase cada

• flutter build apk --obfuscate --split-debug-info=build/symbols renomeia os símbolos Dart. Dificulta ler o binário; não esconde strings nem segredos.
• Guarda a pasta split-debug-info por versão: sem ela os stack traces dos crashes em produção são ilegíveis (aula 26).
• A minificação Android (R8) está ativa por defeito em release. Alguns plugins precisam de regras ProGuard; o flutter build avisa.
• Root e jailbreak: detetar dispositivo comprometido e limitar funcionalidades. Os bancos fazem-no; é contornável; não substitui nenhuma das defesas anteriores.

Para os testes: ofuscação dificulta a engenharia inversa mas não protege segredos; a deteção de root é uma camada extra, não uma garantia.

Isolates: memória separada, trabalho pesado fora da UI

• Dart corre numa thread com um event loop. async/await liberta a thread enquanto espera (rede, disco), mas não liberta nada enquanto calcula.
• Um isolate é outra thread com a sua própria memória. Não partilha objetos: o que entra e sai é copiado por mensagem.
• compute(funcao, argumento) (ou Isolate.run) cria um isolate, corre a função e devolve o resultado como Future.
• Usa-o para: JSON grande (centenas de KB), ordenar ou filtrar milhares de itens, processar imagens, cifrar.
• Não pode passar entre isolates: BuildContext, controllers, sockets, instâncias de plugins. Passa dados simples e modelos.

import 'dart:convert';
import 'package:flutter/foundation.dart';

List<Previsao> _parsePrevisoes(String corpo) {
  final lista = jsonDecode(corpo) as List<dynamic>;
  return lista.map((e) => Previsao.fromJson(e as Map<String, dynamic>)).toList();
}

// A função tem de ser top-level ou static: vai correr noutro isolate.
Future<List<Previsao>> parsePrevisoes(String corpo) => compute(_parsePrevisoes, corpo);

Para os testes: async/await resolve espera; isolates resolvem cálculo. Um parse de 5 MB com await continua a bloquear a interface.

Rebuilds: baratos, mas não grátis

• setState reconstrói o widget inteiro e tudo o que está abaixo. Se o ecrã inteiro é um StatefulWidget, um contador a mudar reconstrói a lista toda.
• const: um widget const é criado uma vez e reutilizado; o framework salta-o no rebuild. O lint prefer_const_constructors aponta os candidatos.
• Dividir widgets: o que muda fica num widget pequeno com o seu próprio estado; o que não muda fica fora.
• Selector e context.select: reconstruir só quando o campo que interessa muda, e não a cada notifyListeners().
• Chaves: ValueKey(localidade.id) em itens de lista que se reordenam ou removem, para o framework reutilizar o estado certo.
• Ver: DevTools → Inspector → Track widget builds; Android Studio → Flutter Performance → rebuild counts.

Para os testes: build correr muitas vezes é normal; o problema é reconstruir muitos widgets que não mudaram.

Listas e imagens

Para os testes: a memória de uma imagem é largura × altura × 4 bytes, descodificada, e não o tamanho do ficheiro.

Frames: medir em profile, nunca em debug

• 60 fps dá 16,6 ms por frame; 120 fps dá 8,3 ms. Cada frame passa pela thread de UI (Dart, build, layout) e pela thread de raster (pintar). Se uma delas passa do orçamento, o frame salta: jank.
• Performance overlay (P no terminal do flutter run, ou showPerformanceOverlay: true): dois gráficos, raster em cima e UI em baixo. Barra vermelha = frame lento.
• Modo debug corre JIT, com asserts e verificações extra: é 2 a 5 vezes mais lento e não representa nada. Mede com flutter run --profile num telemóvel real.
• Shaders: com Impeller (por defeito em iOS e Android atuais) o jank da primeira animação praticamente desapareceu; o antigo SkSL warm-up era um remendo do Skia.
• DevTools → Performance: timeline de frames, o que demorou em cada um, e o botão Enhance tracing para ver builds e layouts.

Para os testes: só se mede desempenho em modo profile ou release, num dispositivo físico.

Bateria e rede

• O rádio (Wi-Fi, 4G/5G) é dos maiores consumidores. Cada pedido acorda-o e mantém-no ligado alguns segundos: agrupa pedidos em vez de fazer dez seguidos.
• Sem polling. Perguntar ao servidor "há novidades?" de 30 em 30 segundos esgota a bateria. Alternativas: push (aula 19), sincronização em background com restrições (aula 23), atualizar ao abrir.
• Localização só quando precisa, com a precisão mínima que chega. O GPS ligado em contínuo esgota um telemóvel em poucas horas (aula 21).
• Respeita o modo de poupança e o Data Saver: menos animações, menos imagens, sem pré-carregar.
• Exemplos: o Instagram pré-carrega imagens em lote enquanto o rádio já está acordado; o Google Maps só liga o GPS de alta precisão em navegação.

Para os testes: o custo de um pedido não é só os bytes; é acordar o rádio.

Sprint 1: ponto de situação

Cada grupo, um minuto, em pé, sem ligar o portátil:

1. O que está merged em main e corre no telemóvel neste momento.
2. O que está em PR aberto e quem está a rever.
3. O que não vai entrar na sprint 1 e passa para a sprint 2. Dizer isto agora é melhor do que na segunda, na review.
4. Um bloqueio, se houver. O docente resolve primeiro os bloqueios, depois circula.

Exercício de 20 minutos: mede a tua app

1. Corre em profile com o telemóvel ligado por cabo:

   flutter run --profile

2. Liga o overlay: carrega em P no terminal. Faz scroll na lista de localidades, abre um detalhe, volta. Procura barras vermelhas.
3. Abre o DevTools (v no terminal) → Inspector → ativa Track widget builds. Interage outra vez e vê que widgets se reconstroem a cada toque.
4. Encontra um rebuild desnecessário: um widget que se reconstrói sem os seus dados mudarem. Corrige com const, extraindo um widget, ou com Selector.
5. Encontra um widget que pode ser const e ainda não é. Corre flutter analyze: o lint prefer_const_constructors ajuda.

O que interessa quando estás a medir

• Uma barra vermelha isolada ao abrir um ecrã é normal (primeira construção). Barras vermelhas seguidas durante scroll são o que procuras.
• Se o gráfico de cima (raster) está alto, o problema é pintar: imagens grandes, sombras, Opacity em listas, ClipRRect em cada item.
• Se o gráfico de baixo (UI) está alto, o problema é Dart: build pesado, parse na thread principal, lógica dentro de build.
• Um ecrã inteiro a reconstruir quando só mudou um texto quer dizer que o setState ou o watch está alto demais na árvore.
• Não otimizes o que não mediste. Um const a mais não faz mal; uma arquitetura torcida por um ganho imaginário faz.

Fechar a sprint 1 até segunda às 16:00

Para casa: auditoria de segredos e permissões

1. Segredos no histórico e no código. Corre no repositório do grupo:

   git log -p | grep -inE 'secret|token|password|api_key' | head -20
   grep -rniE 'secret|password' lib/ android/app/src/main/ ios/Runner/

   Qualquer resultado com um valor real é um achado. Um nome de variável não é.
2. .gitignore tem de incluir .env.json, *.jks, key.properties e *.keystore. Confirma com git check-ignore -v .env.json.
3. AndroidManifest.xml: lista cada <uses-permission>. Para cada um, há uma funcionalidade que o usa? Verifica também android:allowBackup e usesCleartextTraffic.
4. Info.plist: cada chave NS…UsageDescription tem um texto real e específico? Não há NSAllowsArbitraryLoads?
5. Regista o resultado na issue "Auditoria de segurança": o que foi encontrado, o que foi corrigido, quem corrigiu. Fecha-a por PR.

São 15 minutos por grupo. Faz-se em casa, ou no fim da aula se o exercício de medição acabar cedo.

Até segunda