https://chromewebstore.google.com/detail/one-click-file-attachment/…
Une fonctionnalité qui permet d’insérer un lien vers un fichier dans un champ de saisie de texte d’un simple clic droit.
Je l’ai publiée, mais comme je suis le seul à la connaître, elle est « personnelle ».

 

On dirait qu’il y a plus d’infos en demandant simplement à GPT, et que l’accès à des ressources spécialisées est aussi meilleur.

 

Il y avait l’air d’avoir énormément de monde.... Ça laguait dès la création du personnage. Respect, boss.

 

https://github.com/sjeon87/code-radio-ext

  • J’ai créé cette extension parce que ça m’agaçait de devoir garder https://coderadio.freecodecamp.org/ ouvert dans un onglet séparé quand je l’écoute en travaillant. À part ça, elle n’a pas vraiment d’autres fonctionnalités.
 

Une vidéo de présentation de l’auteur, où il explique la même chose, a aussi été publiée sur la chaîne YouTube AI Engineer : https://www.youtube.com/watch?v=WkBPX-oDMnA

 

J’ai répondu tard, je viens seulement de le voir ! Le mieux, c’était l’intégration.
Comme c’est un SDK JS pur, contrairement à Firebase Analytics qui, avec Expo, nécessite du natif, on a pu l’ajouter immédiatement sans rebuild, et avec l’autocapture, pas besoin d’implémenter chaque événement un par un au début, donc c’était moins contraignant pour un développeur solo.
Dans la limite du forfait gratuit, c’était largement suffisant pour voir les tendances par tranche horaire et les funnels.

 

Même le navigateur Chrome lui-même semble contribuer à rendre les passkeys confus. Mes passkeys sont dans 1Password, mais il me demande sans cesse de connecter une clé USB matérielle, par exemple.

 

Je l’utilise aussi de la même manière. Les gestionnaires de mots de passe et les passkeys dépendants de l’OS ou du navigateur sont vraiment trop liés à l’appareil, donc je ne pourrais pas les utiliser.

 

Exact. C’est pourquoi les passkeys posent problème si on les utilise comme méthode principale ; à mon avis, leur valeur se révèle vraiment lorsqu’elles sont associées à un moyen d’authentification extrêmement robuste mais peu pratique.

 

En lisant l’article, je comprends le propos, mais avec le seul titre, on dirait complètement les paroles d’un fou. Moi y compris, les gens qui utilisent les passkeys les utilisent très bien. J’ai l’impression que Nikita Bier a probablement été gêné soit par un mauvais choix de nom pour les passkeys, soit par une mauvaise UX du service utilisé.
On dit que c’est un mode d’authentification que l’utilisateur ne comprend pas, mais en réalité, pour l’authentification, si c’est pratique pour l’utilisateur et sécurisé, cela suffit. Est-ce vraiment nécessaire de la comprendre ?

Je pense que ce problème vient de la mauvaise manière dont Google ou d’autres plateformes de services proposent les passkeys. Qu’il s’agisse de l’empreinte digitale ou autre, il faut améliorer l’UX autour de la question « comment authentifier une passkey côté utilisateur », ce n’est pas la faute des ingénieurs qui l’ont introduite. Le nom lui-même est aussi un peu étrange (si on avait dit « clé sur l’appareil », cela aurait-il été plus intuitif ?). Quoi qu’il en soit, je considère que le mécanisme en lui-même est une bonne méthode d’authentification du point de vue de la sécurité.
Comprendre « passkey = authentification biométrique » rend les choses encore plus difficiles. En y réfléchissant, avant de comprendre le principe du PIN, je me disais moi aussi : « En quoi un nombre à 6 chiffres est-il sûr ? » Mais quand j’ai compris que la vraie clé était une autre clé complexe, et que le PIN était un mot de passe de l’appareil servant à déverrouiller la clé stockée sur cet appareil, j’ai trouvé ça logique et j’ai compris pourquoi c’était sûr. Est-ce qu’un utilisateur lambda va comprendre tout cela avant de l’utiliser ? Non, il l’utilise parce qu’il fait confiance à ce que lui proposent les ingénieurs de l’OS (comme avec Windows Hello PIN).

C’est pareil pour la perte d’un appareil. On dit que la 2FA peut être installée sur plusieurs appareils, alors qu’avec une passkey, si on perd l’appareil, on perd la clé, et que c’est donc un inconvénient ? C’est exactement comme dire : « une serrure connectée à distance est plus sûre qu’une vieille clé de maison ». On compare un moyen permettant de s’authentifier depuis n’importe où avec un moyen permettant de s’authentifier uniquement depuis l’appareil possédé. C’est absurde. Bien sûr, chacun a ses avantages et ses inconvénients, mais si on compare de cette façon, alors on peut aussi prétendre que « le mot de passe est meilleur que la 2FA ». Dire « on ne peut se connecter que depuis mon appareil » revient, dans le monde de la sécurité, à dire « l’authentification n’est possible que si quelqu’un obtient mon appareil ». C’est là, selon moi, que réside l’avantage des passkeys. Des choses comme la biométrie ne sont qu’un moyen d’authentification du trousseau de clés fourni par l’appareil. Je pense qu’il faut à nouveau bien comprendre la vraie nature des passkeys.

 

J’utilise 1Password depuis quatre ans, et le fait que les passkeys se généralisent rend plutôt les choses plus pratiques.
Si on l’installe partout — sur l’iPhone, dans l’écosystème Apple, sur l’ordinateur de l’entreprise, etc. — et qu’on désactive le gestionnaire de mots de passe par défaut, on peut l’utiliser uniquement via 1Password.
Quand on émet une passkey, elle est enregistrée en un clic, et lorsque le site appelle l’API Passkey, une fenêtre apparaît en haut à droite pour demander si l’on veut se connecter avec une passkey.
À ce moment-là, une simple pression sur Entrée permet de se connecter en sautant la saisie du mot de passe et la vérification Captcha.

 
  1. Les liens dans la table des matières renvoient récursivement vers cette page.
  2. Je ne sais pas si vous avez résumé tout le contenu à la main ou si vous avez repris un résumé généré par IA, mais comme YouTube propose une fonction Ask, il ne me semble pas nécessaire de résumer l’intégralité du contenu. En fait, ce qui m’intéressait le plus, c’était la raison pour laquelle vous avez partagé cela, et un résumé en trois lignes aurait largement suffi.
 

« Les passkeys, c’est bien. Ne critiquez pas sans proposer d’alternative !! »,
Sauf qu’en réalité, les passkeys sont censées être l’alternative à la méthode existante, et on insiste pour dire que c’est bien alors qu’elles ne proposent pas vraiment d’alternative correcte.

 

Pour utiliser les passkeys confortablement, il faut utiliser une seule application de gestion de mots de passe qui traverse toutes les plateformes....
Sinon, on ne sait même plus où ni comment on a créé une passkey, et il est aussi difficile de se rendre compte que le navigateur pose la demande de passkey au mauvais acteur. Du coup, en dehors de quelques plateformes qu’on utilise souvent, c’est trop peu pratique, donc je n’utilise pas les passkeys.
Maintenant que j’y pense, on dirait une fonctionnalité conçue pour vendre des applications de gestion de mots de passe.

 

// Test de vérification de l’état de l’API de recherche
async function testSearchAPI() {
const url = 'https://bookmarking.kr/api/search/…';

console.log('Début de la requête API :', url);

try {
const startTime = performance.now();
const response = await fetch(url);
const endTime = performance.now();

console.log(`Temps de réponse : ${(endTime - startTime).toFixed(0)}ms`);  
console.log(`Code d’état HTTP : ${response.status} (${response.statusText})`);  

if (response.ok) {  
  const data = await response.json();  
  console.log('L’API fonctionne normalement ! Données de réponse :', data);  
} else {  
  console.warn(`Erreur serveur survenue (code d’état : ${response.status})`);  
  const errorText = await response.text();  
  console.log('Contenu de la réponse d’erreur du serveur :', errorText || '(aucun corps de réponse)');  
}  

} catch (err) {
console.error('Connexion réseau impossible ou erreur CORS :', err);
}
}

// Exécution
testSearchAPI();

J’ai essayé dans la console F12, et c’est toujours une erreur 503. Le service backend est probablement indisponible.