https://chromewebstore.google.com/detail/one-click-file-attachment/…
テキスト入力欄で右クリック一回でファイルリンクを挿入する機能。
公開はしましたが、自分しか知らないので「個人的」です

普通にGPTに聞いたほうが情報量が多いし、専門的な資料へのアクセスもしやすそう。

ものすごく殺到しているみたいですね……キャラクター作成の時点からラグっていました。尊敬します、兄貴。

haha、ありがとうございます！

エラーだったようです。デバッグします。

ありがとうございます！改善します！

ありがとうございます。改善します :)

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

• 作業中に聴いている https://coderadio.freecodecamp.org/ を別タブで開いておくのが気になったので、拡張機能として作りました。それ以外の機能は特にありません

AI EngineerのYouTubeチャンネルに、著者が同じ内容を発表した動画が上がっていますね - https://www.youtube.com/watch?v=WkBPX-oDMnA

返信が遅くなりました、今見ました！ 一番良かったのは導入のしやすさでした。
Expoなので、ネイティブ連携が必要な Firebase Analytics と違って純粋な JS SDK なので再ビルド
なしですぐに導入できましたし、autocapture によって初期段階でイベントを一つひとつ埋め込まなくてもよく、
個人開発では負担が少なかったです。無料枠の範囲内でも時間帯別のパターンやファネルを
見るには十分でした。

Chromeブラウザ自体も、passkeyそのものをわかりにくくするのに一役買っている気がします。私のpasskeyは1Passwordにあるのに、しきりにハードウェアUSBを接続しろと言ってきたりします。

私も同じ方法で使っています。OSやブラウザに依存するパスワードマネージャーやパスキーは本当にデバイス依存的なので、使えないと思いました。

その通りです。だからこそ、パスキーを主役として使うのは難しく、本当に強力ではあるものの不便な認証手段と組み合わせてこそ価値が光るのだと思います。

記事を読んでみると理解はできますが、タイトルだけ見ると正気とは思えない人の言い分のように感じました。私を含め、パスキーを使っている人はとても快適に使っていますから。Nikita Bier は、おそらくパスキーの命名が悪かったか、利用しているサービスの UX が良くなかったためにそう判断したのだと思います。
ユーザーが理解できない認証方式だと言っていましたが、実際のところ認証というのは、ユーザーにとって便利でセキュリティが高ければそれで十分です。必ず理解しなければならないのでしょうか？

私はこの問題は、Google や他のサービスプラットフォームがパスキーを提供する方法が間違っているために感じられる問題だと思います。指紋であれ何であれ、ユーザーに「パスキーをどのように認証するのか」に関する UX を改善すべきであって、それを導入したエンジニアのせいではありません。名前自体も変ですし（「オンデバイスキー」と呼んでいたら、もっと直感的だったのでしょうか？）。いずれにせよ、方式自体はセキュリティの高い認証方式だと思います。
「パスキー＝生体認証」のように理解すると、かえって難しくなります。考えてみれば私も PIN の仕組みを知るまでは、「6桁の数字の何が安全なんだ？」と思っていましたが、実際のキーは別の複雑なキーであり、PIN はその端末内のキーを開くための端末パスワードだと考えると、セキュリティが高いのだと理解できました。一般ユーザーがこれを理解して使うでしょうか？ それを提案する OS エンジニアの言葉を信じて使うのです（Windows Hello PIN のようなものです）。

端末紛失の場合も同じです。2FA は複数の端末にインストールでき、パスキーは端末を失うと鍵を失うのでそれが欠点だ？ この言い方は「昔ながらの家の鍵より、リモート操作できるドアロックのほうがセキュリティが高い」と言っているのと同じです。どこからでも認証できる手段と、所有している端末でのみ認証できる手段を比較するなんて。俗説です。もちろんそれぞれ長所と短所はあるでしょうが、そういう比べ方をするなら「2FA よりパスワードのほうがましだ」も成り立つと思います。「自分の端末からしかログインできない」というのは、セキュリティの世界では「他人が自分の端末を手に入れない限り認証できない」という意味です。パスキーの利点はそこにあると思います。生体認証のようなものは、端末が提供するキーチェーンの認証手段にすぎません。パスキーの本質を改めて正しく理解する必要があると思います。

1Passwordを4年間使っていますが、むしろPasskeyが主流になって便利です。
iPhoneやAppleエコシステム、会社のコンピューターなどすべてにインストールして、標準のパスワードマネージャーを無効化すれば、1Passwordだけで使えます。
Passkeyを発行してもらうと、クリック1回で保存され、サイトがPasskey APIを呼び出すと、右上にPasskeyでログインするか尋ねるウィンドウが表示されます。
このときEnterを1回押すだけで、パスワード入力やCAPTCHA認証をスキップしてログインに成功します。

1. 目次にあるリンクが再帰的にこのページへ戻ってきます。
2. すべての内容を手作業で要約してくださったのか、AIで要約したものを転載してくださったのかは分かりませんが、YouTubeには Ask 機能があるので、すべての内容をまとめていただかなくても問題なさそうです。むしろ、これを共有してくださった理由がいちばん気になりましたし、内容は3行要約でも十分だと思います。

「passkeyは良い。代案もない批判はするな!!」と。
でも当のpasskeyこそ既存方式に対する代替案という立場なのに、まともな代案を提示できていないまま良いものだとごり押ししている

パスキーを快適に使うには、すべてのプラットフォームをまたいで使える、たった1つのパスワード管理アプリを使うしかない……
そうでないと、自分がどこでどうやってパスキーを作成したのかも分からなくなるし、ブラウザがパスキーの要求を見当違いの相手に尋ねていることにも気づきにくい。だから、よく使ういくつかのプラットフォーム以外では不便で、パスキーを使わない。
今見ると、パスワード管理アプリを売るために作られた機能みたいだ。

サイトのURLは以下の通りです。
https://bookoverflow.io/

// 検索 API 状態確認テスト
async function testSearchAPI() {
const url = 'https://bookmarking.kr/api/search/…';

console.log('API リクエスト開始:', url);

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

console.log(`応答時間: ${(endTime - startTime).toFixed(0)}ms`);  
console.log(`HTTP ステータスコード: ${response.status} (${response.statusText})`);  

if (response.ok) {  
  const data = await response.json();  
  console.log('API は正常動作中です！ レスポンスデータ:', data);  
} else {  
  console.warn(`サーバーエラーが発生しました (ステータスコード: ${response.status})`);  
  const errorText = await response.text();  
  console.log('サーバーエラーのレスポンス内容:', errorText || '(レスポンス本文なし)');  
}  

} catch (err) {
console.error('ネットワーク接続不可または CORS エラー:', err);
}
}

// 実行
testSearchAPI();

F12 コンソールで試してみたところ、まだ 503 error ですね。おそらくバックエンドサービスがダウンしている状態だと思います。