Criei como uma extensão porque me incomodava deixar o https://coderadio.freecodecamp.org/, que ouço enquanto trabalho, aberto em uma aba separada. Fora isso, não há nenhuma funcionalidade em especial.
Desculpe pela demora na resposta, só vi agora! O melhor foi a adoção.
Como é Expo, diferentemente do Firebase Analytics, que exige integração nativa, ele usa um SDK em JS puro, então deu para integrar direto sem rebuild;
e, com o autocapture, não precisei instrumentar cada evento no início,
o que reduziu bastante o peso para um desenvolvedor solo. Dentro do limite gratuito, foi suficiente para ver padrões por faixa horária e funis.
Acho que até o próprio navegador Chrome contribui para tornar as passkeys confusas. A minha passkey está no 1Password, mas ele fica pedindo para conectar um USB de hardware, ou coisas assim.
Eu também uso da mesma forma. Gerenciadores de senhas e passkeys dependentes do sistema operacional ou do navegador são realmente tão dependentes do dispositivo que não dá para usar.
Isso mesmo. Por isso, acho que passkeys são problemáticas como opção principal, e seu valor realmente aparece quando combinadas com um meio de autenticação extremamente forte, mas inconveniente.
Lendo o texto, eu até entendo, mas só pelo título parece coisa de maluco. Eu, inclusive, e as pessoas que usam passkey, usamos muito bem. Acho que o Nikita Bier provavelmente teve essa impressão porque nomeou mal a passkey, ou porque o UX do serviço que ele usa não é bom.
Ele disse que é um método de autenticação que o usuário não entende, mas, na verdade, quando se fala em autenticação, se for conveniente para o usuário e seguro, já basta. Será que precisa mesmo entender?
Eu acho que esse problema é percebido porque o Google e outras plataformas de serviço oferecem passkeys da forma errada. Seja com biometria ou qualquer outra coisa, o que precisa melhorar é o UX de como apresentar ao usuário "como a passkey será autenticada", e não culpar os engenheiros que adotaram isso. O próprio nome também é meio estranho (será que se chamasse "chave no dispositivo" seria mais intuitivo?). De qualquer forma, considero que o método em si é uma forma de autenticação segura.
Entender como "passkey = autenticação biométrica" deixa tudo mais confuso. Pensando bem, antes de eu entender o princípio do PIN, eu também pensava: "como assim 6 dígitos são seguros?". Mas quando entendi que a chave real é outra, bem mais complexa, e que o PIN é a senha do dispositivo para desbloquear a chave que está nele, aí fez sentido para mim que a segurança é boa. O usuário comum vai entender isso e usar? Não; ele usa porque confia no que o engenheiro de OS está propondo (como no Windows Hello PIN).
O mesmo vale para a perda do dispositivo. Dizer que 2FA pode ser instalado em vários aparelhos, enquanto com passkey você perde a chave se perder o aparelho, e que isso seria uma desvantagem? Isso é a mesma coisa que dizer: "uma fechadura remota é mais segura do que uma chave física antiga". Como dá para comparar um meio que permite autenticação de qualquer lugar com outro que só permite autenticação no dispositivo que você possui? É um argumento sem sentido. Claro que cada um tem vantagens e desvantagens, mas, comparando desse jeito, então até "senha é melhor que 2FA" passaria a fazer sentido. A frase "só é possível fazer login no meu dispositivo" no mundo da segurança equivale a "alguém só consegue se autenticar se obtiver o meu dispositivo". Eu vejo aí a grande vantagem da passkey. Coisas como biometria são apenas meios de autenticação do chaveiro fornecidos pelo dispositivo. Acho que precisamos voltar a entender corretamente a essência da passkey.
Uso o 1Password há 4 anos e, na verdade, é mais prático justamente porque Passkey virou tendência.
Se você instalar em tudo — iPhone, ecossistema Apple, computador da empresa etc. — e desativar o gerenciador de senhas padrão, dá para usar apenas o 1Password.
Ao emitir uma Passkey, ela é salva com um clique e, quando o site chama a API de Passkey, aparece no canto superior direito uma janela perguntando se você quer fazer login com a Passkey.
Nesse momento, basta pressionar Enter uma vez para fazer login com sucesso, pulando a digitação da senha e a verificação por Captcha.
O link no índice volta recursivamente para esta página.
Não sei se você resumiu tudo manualmente ou se apenas transcreveu um resumo feito por IA, mas como existe a função Ask no YouTube, acho que não haveria problema mesmo sem resumir todo o conteúdo. Na verdade, o que mais me deixou curioso foi o motivo de você ter compartilhado isso; quanto ao conteúdo, acho que até um resumo em 3 linhas já seria suficiente.
“Passkey é bom. Não faça críticas sem apresentar uma alternativa!!”
Mas, na prática, o passkey é justamente a alternativa ao método existente, e estão insistindo que é bom mesmo sem oferecer uma alternativa decente.
Para usar passkeys de forma conveniente, é preciso usar um único app de gerenciamento de senhas que funcione em todas as plataformas...
Se não for assim, você nem sabe onde e como criou a passkey, e também é difícil perceber que o navegador está perguntando a entidade errada sobre a solicitação de passkey. Por isso, fora algumas poucas plataformas que uso com frequência, acabo não usando passkeys porque é inconveniente.
Vendo agora, parece um recurso feito para vender apps de gerenciamento de senhas.
console.log(`Tempo de resposta: ${(endTime - startTime).toFixed(0)}ms`);
console.log(`Código de status HTTP: ${response.status} (${response.statusText})`);
if (response.ok) {
const data = await response.json();
console.log('API funcionando normalmente! Dados da resposta:', data);
} else {
console.warn(`Erro no servidor (código de status: ${response.status})`);
const errorText = await response.text();
console.log('Conteúdo da resposta de erro do servidor:', errorText || '(sem corpo na resposta)');
}
} catch (err) {
console.error('Não foi possível conectar à rede ou erro de CORS:', err);
}
}
// Executar
testSearchAPI();
Testei no console com F12 e ainda dá erro 503. Parece provável que o serviço de backend esteja fora do ar.
https://chromewebstore.google.com/detail/one-click-file-attachment/…
Função para inserir um link de arquivo em um campo de texto com apenas um clique direito.
Está pública, mas como só eu sei dela, é “pessoal”.
Parece que simplesmente perguntar ao GPT traz mais informações e também oferece melhor acesso a materiais especializados.
Parece que lotou demais... já começou a travar desde a criação do personagem. Respeito, mano.
Haha, obrigado!
Acho que era um erro. Vou depurar.
Obrigado! Vou melhorar isso!
Obrigado. Vou melhorar :)
https://github.com/sjeon87/code-radio-ext
No canal do YouTube AI Engineer, foi publicado um vídeo de apresentação do autor com basicamente o mesmo conteúdo - https://www.youtube.com/watch?v=WkBPX-oDMnA
Desculpe pela demora na resposta, só vi agora! O melhor foi a adoção.
Como é Expo, diferentemente do Firebase Analytics, que exige integração nativa, ele usa um SDK em JS puro, então deu para integrar direto sem rebuild;
e, com o autocapture, não precisei instrumentar cada evento no início,
o que reduziu bastante o peso para um desenvolvedor solo. Dentro do limite gratuito, foi suficiente para ver padrões por faixa horária e funis.
Acho que até o próprio navegador Chrome contribui para tornar as passkeys confusas. A minha passkey está no 1Password, mas ele fica pedindo para conectar um USB de hardware, ou coisas assim.
Eu também uso da mesma forma. Gerenciadores de senhas e passkeys dependentes do sistema operacional ou do navegador são realmente tão dependentes do dispositivo que não dá para usar.
Isso mesmo. Por isso, acho que passkeys são problemáticas como opção principal, e seu valor realmente aparece quando combinadas com um meio de autenticação extremamente forte, mas inconveniente.
Lendo o texto, eu até entendo, mas só pelo título parece coisa de maluco. Eu, inclusive, e as pessoas que usam passkey, usamos muito bem. Acho que o Nikita Bier provavelmente teve essa impressão porque nomeou mal a passkey, ou porque o UX do serviço que ele usa não é bom.
Ele disse que é um método de autenticação que o usuário não entende, mas, na verdade, quando se fala em autenticação, se for conveniente para o usuário e seguro, já basta. Será que precisa mesmo entender?
Eu acho que esse problema é percebido porque o Google e outras plataformas de serviço oferecem passkeys da forma errada. Seja com biometria ou qualquer outra coisa, o que precisa melhorar é o UX de como apresentar ao usuário "como a passkey será autenticada", e não culpar os engenheiros que adotaram isso. O próprio nome também é meio estranho (será que se chamasse "chave no dispositivo" seria mais intuitivo?). De qualquer forma, considero que o método em si é uma forma de autenticação segura.
Entender como "passkey = autenticação biométrica" deixa tudo mais confuso. Pensando bem, antes de eu entender o princípio do PIN, eu também pensava: "como assim 6 dígitos são seguros?". Mas quando entendi que a chave real é outra, bem mais complexa, e que o PIN é a senha do dispositivo para desbloquear a chave que está nele, aí fez sentido para mim que a segurança é boa. O usuário comum vai entender isso e usar? Não; ele usa porque confia no que o engenheiro de OS está propondo (como no Windows Hello PIN).
O mesmo vale para a perda do dispositivo. Dizer que 2FA pode ser instalado em vários aparelhos, enquanto com passkey você perde a chave se perder o aparelho, e que isso seria uma desvantagem? Isso é a mesma coisa que dizer: "uma fechadura remota é mais segura do que uma chave física antiga". Como dá para comparar um meio que permite autenticação de qualquer lugar com outro que só permite autenticação no dispositivo que você possui? É um argumento sem sentido. Claro que cada um tem vantagens e desvantagens, mas, comparando desse jeito, então até "senha é melhor que 2FA" passaria a fazer sentido. A frase "só é possível fazer login no meu dispositivo" no mundo da segurança equivale a "alguém só consegue se autenticar se obtiver o meu dispositivo". Eu vejo aí a grande vantagem da passkey. Coisas como biometria são apenas meios de autenticação do chaveiro fornecidos pelo dispositivo. Acho que precisamos voltar a entender corretamente a essência da passkey.
Uso o 1Password há 4 anos e, na verdade, é mais prático justamente porque Passkey virou tendência.
Se você instalar em tudo — iPhone, ecossistema Apple, computador da empresa etc. — e desativar o gerenciador de senhas padrão, dá para usar apenas o 1Password.
Ao emitir uma Passkey, ela é salva com um clique e, quando o site chama a API de Passkey, aparece no canto superior direito uma janela perguntando se você quer fazer login com a Passkey.
Nesse momento, basta pressionar Enter uma vez para fazer login com sucesso, pulando a digitação da senha e a verificação por Captcha.
Askno YouTube, acho que não haveria problema mesmo sem resumir todo o conteúdo. Na verdade, o que mais me deixou curioso foi o motivo de você ter compartilhado isso; quanto ao conteúdo, acho que até um resumo em 3 linhas já seria suficiente.“Passkey é bom. Não faça críticas sem apresentar uma alternativa!!”
Mas, na prática, o passkey é justamente a alternativa ao método existente, e estão insistindo que é bom mesmo sem oferecer uma alternativa decente.
Para usar passkeys de forma conveniente, é preciso usar um único app de gerenciamento de senhas que funcione em todas as plataformas... Se não for assim, você nem sabe onde e como criou a passkey, e também é difícil perceber que o navegador está perguntando a entidade errada sobre a solicitação de passkey. Por isso, fora algumas poucas plataformas que uso com frequência, acabo não usando passkeys porque é inconveniente. Vendo agora, parece um recurso feito para vender apps de gerenciamento de senhas.
O endereço do site está abaixo.
https://bookoverflow.io/
// Teste para verificar o status da API de busca
async function testSearchAPI() {
const url = 'https://bookmarking.kr/api/search/…';
console.log('Iniciando requisição à API:', url);
try {
const startTime = performance.now();
const response = await fetch(url);
const endTime = performance.now();
} catch (err) {
console.error('Não foi possível conectar à rede ou erro de CORS:', err);
}
}
// Executar
testSearchAPI();
Testei no console com F12 e ainda dá erro 503. Parece provável que o serviço de backend esteja fora do ar.