Capítulo 3 — Proposta de contribuição original

Capítulo 3 — Proposta de contribuição original

Mapa da aula

Aula 03 publicada. Mapa, exemplo, EX015.

flowchart TD
  N0["3.1 Da pergunta às hipóteses"]
  N1["3.2 Escolher o desfecho"]
  N2["3.3 Desenho e poder estatístico"]
  N3["3.4 Registro e plano de análise"]
  N4["3.5 Riscos para a parceira"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX015"]

Desenho lógico

flowchart LR
  N0["3.1 Da pergunta às hipóteses"]
  N1["3.2 Escolher o desfecho"]
  N2["3.3 Desenho e poder estatístico"]
  N3["3.4 Registro e plano de análise"]
  N4["3.5 Riscos para a parceira"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX015"]

[3.1 Da pergunta às hipóteses]
    |
    v
[3.2 Escolher o desfecho]
    |
    v
[3.3 Desenho e poder estatístico]
    |
    v
[3.4 Registro e plano de análise]
    |
    v
[3.5 Riscos para a parceira]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX015]

Objetivos de aprendizagem

Você vai (1) escrever hipóteses falseáveis para um estudo de redução do uso indevido; (2) escolher um desfecho primário e a análise antes de ver os dados; (3) registrar o plano para que mudanças posteriores fiquem visíveis.

3.1 Da pergunta às hipóteses

Nadia transforma sua pergunta numa hipótese primária e numa secundária. A H1 afirma que as equipes que usam o checklist e a etapa de lint terão, ao longo de um trimestre, uma média menor de achados confirmados de uso indevido a cada dez mudanças integradas do que as equipes que usam a revisão habitual. A H2 afirma que uma parcela maior das equipes com checklist registrará zero uso indevido naquele trimestre. As duas são direcionais e falseáveis: uma diferença nula ou invertida conta contra elas. Ela também escreve uma expectativa nula para a ferramenta de lint sozinha, porque os examinadores vão perguntar se uma ferramenta barata, e não a atenção humana, explica algum efeito.

3.2 Escolher o desfecho

O desfecho primário é o uso indevido confirmado a cada dez mudanças integradas que tocam código criptográfico, medido por equipe. Confirmação significa que um auditor cego, que não sabe o braço, concorda que a mudança viola uma regra do livro de códigos. Nadia rejeita duas alternativas tentadoras. Os avisos do lint recompensariam a ferramenta por sinalizar seus próprios padrões, e os incidentes seriam raros demais para medir num trimestre. Ela define "toca código criptográfico" de forma mecânica, como qualquer mudança que importe o wrapper criptográfico aprovado da Meridian ou os módulos da biblioteca padrão hashlib, hmac ou secrets, para que a inclusão não dependa de julgamento.

3.3 Desenho e poder estatístico

Há vinte e quatro equipes disponíveis, então Nadia planeja um desenho randomizado por conglomerados com doze equipes por braço, estratificado por linha de produto, para que as equipes de tokenização, de webhooks e de armazenamento apareçam nos dois braços. A randomização no nível da equipe evita a contaminação, já que os engenheiros de uma equipe compartilham hábitos de revisão. Ela estima o poder a partir da linha de base que vai medir no capítulo 4 e declara a limitação honesta: com doze conglomerados por braço, só efeitos grandes são detectáveis com confiabilidade. Por isso, ela se compromete de antemão com um teste de permutação, que não pressupõe normalidade e se adapta a poucos conglomerados.

3.4 Registro e plano de análise

Antes que exista qualquer dado de desfecho, Nadia deposita um plano com carimbo de tempo no escritório de pesquisa da universidade. Ele lista as hipóteses, os desfechos primário e secundário, a regra de inclusão, a política de semente da randomização, o teste de permutação com 20.000 embaralhamentos e a regra para tratar equipes que saiam da Meridian. Também lista o que contaria como desvio. O registro não é burocracia por si mesma: permite que os examinadores distingam os resultados confirmatórios dos exploratórios e protege Nadia da tentação de trocar de desfecho quando o primeiro decepcionar.

3.5 Riscos para a parceira

A proposta também protege a Meridian. O checklist nunca pede que os revisores testem explorações; ele faz perguntas como se cada chave do GCM tem um contador de invocações e um gatilho de rotação, se as chaves vêm de um serviço gerenciado de chaves, e não do código-fonte, e se o armazenamento de senhas usa uma função com alto custo de memória (memory-hard), como o Argon2 da RFC 9106. As equipes de controle mantêm sua revisão habitual, então nenhuma equipe recebe proteção mais fraca do que antes. O dever de escalonamento do capítulo 1 continua valendo nos dois braços, e o líder de segurança pode interromper o estudo se algum braço causar dano.

Exemplo resolvido

O registro de uma página de Nadia enuncia H1 e H2, o desfecho a cada dez mudanças que tocam criptografia, o desenho estratificado por conglomerados de 12 contra 12 e o teste de permutação, e depois é depositado com carimbo de tempo antes que os dados da linha de base sejam revelados.

Caso sintético. O escritório de registro e o checklist são inventados para fins didáticos; a RFC 9106 e o SP 800-38D são referências reais para os itens do checklist.

Erros e limites

O registro não conserta uma medida de desfecho fraca, e um número pequeno de conglomerados limita o poder, qualquer que seja o teste. Relate os desvios abertamente, em vez de emendar o plano em silêncio.

Exercícios

• EX015 — Hipótese primária. Escreva a H1 com precisão. Rubrica: 3 = as equipes com checklist+lint têm média menor de uso indevido confirmado a cada dez mudanças integradas que tocam criptografia ao longo de um trimestre;; 2 = direção sem unidade;; 1 = sem direção;; 0 = nenhuma.

• EX016 — Desfechos rejeitados. Por que Nadia rejeitou os avisos do lint e os incidentes como desfechos? Rubrica: 3 = os avisos recompensam os próprios padrões da ferramenta; os incidentes são raros demais num trimestre;; 2 = um motivo;; 1 = vago;; 0 = nenhuma.

• EX017 — Regra de inclusão. Como é definido "toca código criptográfico"? Rubrica: 3 = a mudança importa o wrapper criptográfico aprovado, hashlib, hmac ou secrets;; 2 = importa criptografia;; 1 = julgamento do revisor;; 0 = nenhuma.

• EX018 — Escolha dos conglomerados. Por que randomizar equipes, e não mudanças individuais? Rubrica: 3 = os engenheiros de uma equipe compartilham hábitos, então a atribuição por mudança contamina os braços;; 2 = contaminação citada;; 1 = conveniência;; 0 = nenhuma.

• EX019 — Conteúdo registrado. Liste quatro itens do plano registrado. Rubrica: 3 = quatro entre hipóteses, desfechos, regra de inclusão, política de semente, teste de permutação, regra de atrito, definição de desvio;; 2 = três;; 1 = um ou dois;; 0 = nenhuma.

• EX020 — Item de senhas do checklist. O que o checklist pergunta sobre o armazenamento de senhas, e que fonte o apoia? Rubrica: 3 = função memory-hard como o Argon2, RFC 9106;; 2 = Argon2 sem fonte;; 1 = "fazer hash das senhas";; 0 = nenhuma.

Síntese

Um plano registrado com hipóteses falseáveis, um desfecho cego e definido mecanicamente e um desenho ajustado aos conglomerados disponíveis transformam uma boa pergunta num teste.

Continue estudando — aula 03 (capítulo 03 de 08)

← Capítulo 02 · Índice das aulas · Capítulo 04 →

Continue para a próxima aula já escrita.