← 2026-01-31 の一覧へ戻るホーム
**メール実験：外部画像のフィルタリング**

2026/01/30 21:01

**メール実験：外部画像のフィルタリング**

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Summary

著者は、外部ホストされた画像を含むメッセージを「Automated」フォルダーに移動する Sieve ルールを作成しました。これにより、自動化されたメールや企業メールと手で送信したメールを分離できます。電子メールクライアントは通常、プライバシー保護のため外部画像をブロックし、ユーザーが手動でメールを送る際に URL を介して画像を埋め込むことはほとんどなく（代わりに添付ファイルとして扱われることが多い）ので、このルールでは 

src
が 
https
で始まる 
<img>
タグを単純な正規表現でマッチさせています。1 日使用した結果、ほとんどの自動化メールは正常にリダイレクトされましたが、メーリングリストへの手送信メール 1 件だけがフィルタを回避して主要受信箱に残りました。著者は後で除外ルールを追加し、選択した連絡先のメールを主フォルダーに保持できるようにする予定です。このアプローチは December Adventure 2025 シリーズの一部であり、受信箱をクリーンに保ちつつ、外部画像トラッキングへの曝露と帯域幅の節約を実現します。

本文

最近、受信トレイにあるほぼすべてのメールに「外部画像を表示」オプションが付いていることに気づきました。多くのメールはHTMLで外部から読み込む画像を参照しています。この仕組みには、ニュースレターなどで毎回画像を添付しなくても済むという利点と、リモートサーバーが画像の閲覧場所や時間を追跡できてしまうという悪意ある側面があります。そのため、ほとんどのメールクライアントはプライバシー保護の観点からデフォルトで外部画像を読み込まないようになっています。

そこで逆に考えてみました。外部画像を含まないメールとは何でしょうか？答えは、ほぼ「実際に人が手動で送ったメール」だと思われます。個人的なやり取りで外部画像を添付したことは一度もありませんし、仕事上のメールであっても、会社の署名付きで追跡されているケースがほとんどです。人に画像を送る場合は、通常添付ファイルとして渡します。

そこで、手作業で送られたメールと自動生成されたメールを自然に分別するための簡易プロキシとして、以下のSieveルールを作成しました：

if body :regex "<img[^>]*src=\"https" {
    fileinto "Inbox.Automated";
}

（HTML に対して正規表現を使うのは一般的に推奨されませんが、今回のマッチングはシンプルで問題ないと考えています）

このルールを数日間試した結果、驚くほど効果的でした。自動化フォルダに残る重要なメッセージもありますが、通常受信トレイへ入ってきたメールのうち、手作業で送られたものはマイルストリームリストからの一通だけです。本当にありがたい！これで通常の受信トレイに溜まるメール量が格段に減り、そこに届くメールは本当に注意したい内容ばかりになると期待しています。

さらに、連絡先に登録している人からのメールにはこのルールを適用しないようにする別規則も必要でしょう。まだ実装していませんが、自然な次のステップです。

これは「2025年12月冒険」シリーズの一環です。

同じ日のほかのニュース

一覧に戻る →

2026/01/31 9:51

**Show HN:** 私は自分の中国語（普通話）の声調を直すため、9Mパラメータの音声モデルを訓練しました。

## Japanese Translation: > **概要:** > AISHELL‑1 と Primewords から約300時間分の文字起こし済み中国語音声を用い、SpecAugment と4台の RTX 4090 GPU を使用して、約9 Mパラメータのコンフォーマーモデル（Conformer）を訓練しました。ネットワークは40 msごとにトークン確率を出力し、Viterbi アルゴリズムでピンイン音調トークン列（各音節＋音調がユニークなトークン；中性音調はトーン5へマッピング）に沿ってアラインメントを強制します。語彙には1,254個のトークンと `<unk>`、`<blank>` が含まれます。 > このモデルでは Token Error Rate（TER）が約 5.3 %、音調精度が約 98.3 %です。INT8 量子化によりサイズを約37 MB から約11 MB に縮小し、TER は +0.0003 の増加のみで済みました。先頭の無音によるアラインメントミスを修正するため、 `<blank>` 確率が0.7 を超えるフレームは採点前に除外しました。 > 最終的な量子化モデル（約13 MB のダウンロード）は ONNX Runtime Web 経由でブラウザ上で完全に実行され、リアルタイムの発音フィードバックを可能にします。今後は Common Voice などの会話データセットを取り入れ、カジュアルまたは子供の話し言葉（通常より速く変動が大きい）に対する頑健性を向上させる予定です。 **短縮版（すべてのポイントを網羅）:** > **概要:** > AISHELL‑1/Primewords から約300時間分の中国語音声で、SpecAugment と4× RTX 4090 を用いて9 Mパラメータのコンフォーマーを訓練しました。40 ms ごとにトークン確率を出力し、ピンイン‑音調語彙（1,254トークン＋`<unk>`、`<blank>`）で Viterbi アラインメントを行います。TER は約 5.3 %、音調精度は約 98.3 %です。INT8 量子化によりモデルサイズが約11 MB に縮小され、TER は +0.0003 の増加のみでした。先頭無音のバグは、高い `<blank>` 確率（閾値0.7）を持つフレームを除外することで修正しました。13 MB の ONNX Runtime Web バージョンはブラウザ内で完全に動作し、即時発音フィードバックを提供します。将来的には会話データを追加してドメインシフトへの対処を図ります。

2026/01/31 5:40

ペアウェブ：WebTorrent を利用した分散型ウェブサイトホスティング

## 日本語訳: PeerWebは、WebTorrent技術を利用したピアツーピア（P2P）ネットワーク上で静的ウェブサイトを無料かつ検閲耐性のある形でホストできるサービスです。サイトはトレントハッシュ経由で配布され、少なくとも1人のユーザーがブラウザタブまたはデスクトップクライアントを開いている限りオンラインに留まります。 **動作原理：** - ユーザーはインターフェースにファイルをドラッグ＆ドロップするだけで、シンプルなHTML/CSS/JSプロジェクトをアップロードできます。各サイトにはユニークなPeerWebリンクが付与され、どこからでもアクセス可能です。 - サイトは `index.html` ファイルを必ず含み、相対パスのみを使用し、静的コンテンツで構成されている必要があります。 - キャッシュ前に PeerWeb は DOMPurify で全ファイルをサニタイズし、XSS 攻撃から保護します。 - キャッシュされたサイトは IndexedDB に保存され即座に再読み込みが可能です。キャッシュは7日間の非アクティブ後に自動的にクリアされます。 **セキュリティとパフォーマンス：** - コンテンツはサンドボックス化された iframe 内でレンダリングされ、リソース検証によって正当な資産のみが表示されます。 - 開発者はデバッグモード（`&debug=true`）を有効にして詳細な進行状況とリアルタイムメトリクスを確認できます。 **使用例：** デモリンクではテストページ、SomaFM ラジオ、チェスゲーム、およびテキストエディタアプリが紹介されています。 多くのピアにコンテンツを分散させることで、PeerWeb は従来のホスティング費用なしでサイトを利用可能にし、キャッシュによる高速ロードとマルウェアからの保護を提供しつつ、検閲にも耐えます。

2026/01/31 8:47

**Stonebraker氏のCAP定理とデータベースに関する論考**

## 日本語訳: **要約：** マイク・ストーンブレーカー氏は、CACMブログ記事「データベースシステムにおけるエラー、最終的な一貫性、およびCAP定理」で、CAP定理が最終的一致性を強制するという広く受け入れられているNoSQLの見解に挑戦しています。彼は、多くのデータベース障害はネットワーク分断ではなく、アプリケーション、管理、実装上のバグから生じており、実際にはパケット損失や設定エラーなど他のネットワーキング欠陥と比べても稀であると主張しています。ストーンブレーカー氏は、2ノード冗長スキームが大規模では不十分であり、業界が最終的一致性に依存することで実際の問題を隠してしまう可能性があると指摘しています。 彼はAmazon SimpleDB が最近完全一致性へ移行したことを、高いスケールでも厳密な正確性を保証できる証拠として挙げ、実用的な緩和策として「遅延削除」（削除マークを付けてからガベージコレクションを遅らせる）を提案しています。ストーンブレーカー氏は完全一致性を早期に放棄すると微妙なバグが発生し、運用リスクが増大する可能性があると警告しています。 この記事はNoSQLコミュニティに対し、多くのワークロードで最終的一致性が適切かどうかを再検討し、強い一致性が大規模でも達成できることを示唆しています。