Por que o suporte gratuito também deve dar respostas de verdade
Uma fila de suporte que só dá respostas bem pensadas a clientes pagantes está dizendo aos usuários gratuitos que as perguntas deles não merecem ser resolvidas direito.
O problema das chaves de API que nunca expiram
Uma chave que nunca expira é conveniente justamente da forma que torna fácil esquecer que ela existe. Ela é gerada uma vez, colocada em um arquivo de configuração ou em uma variável de ambiente e então simplesmente continua funcionando, indefinidamente, sem que ninguém reavalie se deveria. Anos depois, a pessoa que a gerou pode ter saído da empresa, o projeto para o qual ela foi criada pode ter sido desativado, e a própria chave pode estar em um servidor esquecido, em um repositório vazado ou em um backup antigo, ainda totalmente válida, porque nada no sistema jamais pediu que ela provasse que ainda era necessária.
Esse é um problema de segurança real e subestimado, não hipotético. Chaves vazam por arquivos de configuração commitados, por logs que capturaram um cabeçalho de requisição por acidente, por backups antigos que sobrevivem ao projeto a que pertenciam. Uma chave que nunca expira significa que cada um desses vetores de vazamento continua perigoso indefinidamente, sem nenhum ponto natural em que a exposição se encerre sozinha. Uma chave que é trocada ou revisada periodicamente pelo menos limita por quanto tempo um vazamento continua explorável, mesmo que o vazamento em si nunca tenha sido detectado.
Não achamos que a resposta seja impor datas de expiração que quebram integrações sem aviso, o que troca um problema por outro igualmente frustrante: uma chave que para de funcionar no meio da produção por causa de uma política de rotação que ninguém comunicou com clareza. A resposta é visibilidade e controle que façam da rotação uma escolha deliberada e informada, em vez de algo que nunca acontece ou que acontece como uma surpresa não planejada. Os cabeçalhos de cota em cada resposta, incluindo a contagem de quantas vagas de IP de uma chave estão em uso, dão um sinal contínuo sobre se o padrão de uso de uma chave ainda corresponde àquilo para que ela foi emitida originalmente, que é exatamente o tipo de informação que deveria motivar uma revisão periódica do tipo "esta chave ainda precisa existir?".
O hábito mais amplo do setor de tratar uma chave como uma credencial permanente, instalada uma única vez, vem de priorizar a conveniência da integração inicial em vez de todo o tempo de vida dessa credencial. É realmente mais fácil, no primeiro dia, gerar uma chave que nunca mais precisa ser tocada. Essa conveniência vem toda no início, e o custo, uma chave antiga, sem monitoramento e sem rotação parada em algum lugar como um risco permanente, fica todo para o fim, em um incidente futuro em que ninguém está pensando no primeiro dia.
Achamos que o padrão mais saudável é tratar uma chave menos como uma instalação fixa e mais como uma credencial com uma relação contínua com a conta: visível em tempo real por meio das requisições que faz, revisável periodicamente e revogável sem drama quando o projeto a que pertencia realmente terminou. Nada disso exige impor expiração a ninguém. Exige tornar fácil o bastante ver o que uma chave está realmente fazendo, a ponto de deixar uma chave antiga esquecida para sempre deixar de ser o caminho mais fácil.