錯誤試行

PCや生活の試行錯誤の成果を報告するブログ

ブラウザ閲覧履歴内全文検索方法についての調査

(2020/5/8)「SSL通信の設定について」にSSL通信のキャッシュ・データベース登録について追記

ふとしたときに、ネットのどこかで読んだ文章を読み返したいが、一体どこで読んだのかどうしても思い出せず、閲覧履歴をしらみつぶしに当たっても全く見つけられずに歯痒い思いをすることがある。これを何とかしたいと常々思ってきたため、その解決方法を調べてみた。環境はUbuntu16.04 LTS。


結論

wwwoffleとHyper Estraierで実現できた。以下は解決方法を検討したところから。

ブラウザの拡張機能などでの対応

Chromeでは履歴内を全文検索する拡張機能が存在するが、Firefoxのアドオンは使い勝手が良くない。また複数のブラウザを使い分けていると、ブラウザ別に検索しなければならなくなるのがやや面倒。

  • Firefox
    CacheViewerというアドオンで閲覧キャッシュの全文検索が可能だが、ブラウザのキャッシュサイズを最大(1024MB)に設定していると途方もなく動作が重くなり、実用上支障が大きい。他に同じようなアドオンとしてCacheSearchや、閲覧したページを全てローカルに保存するSloggerといったアドオンがあったようだが、現行のFirefoxでは使えなかったり公開停止となっている模様。
  • Chrome
    Falconという拡張機能で実現されているらしい。ただし調べ物は主にFirefoxで行うことが多いため使い勝手については検証していない。
  • 風博士
    ブラウザそのものに履歴内全文検索の機能が付いているらしい。ただし以下同文。
  • Opera
    Operaもブラウザ自体に全文検索機能が付いていた模様。寡聞にして知らなかった。しかも2008年からであるらしい()。ただし以下同じ。

キャッシュサーバの調査

  • polipo
    簡単に導入でき、ウェブ閲覧を高速化できることで有名になったローカルキャッシュサーバ。キャッシュファイルが平文ではないため、全文検索は不可能。
  • squid
    企業などでも使われるという、polipoより大規模なキャッシュサーバ。キャッシュファイルが平文ではないため、全文検索は不可能。ウェブ検索結果ではnamazuとの組み合わせに触れているページがあるので、昔の古いバージョンは平文だったのかもしれない。
  • wwwoffle
    キャッシュファイルが平文。これが使える。ただしubuntuではパッケージ化されていないため、ソースからコンパイルする必要がある。インストール方法は参照サイトを参照。

検索エンジン

  • Fess
    全文検索サーバ。公式サイトで「5分で簡単に構築可能な全文検索サーバー」と説明されている通り簡単にできそう。Elasticsearchを検索エンジンとして利用しており、Elasticsearchは完全ヒットでなくても検索結果を拾ってくれる利点があるとのこと()。
    使ってみたところ、設定が悪いせいか検索結果から元URLにダイレクトに飛べなかったため、惜しくも選外とした。→(追記)「パスマッピング」で可能かもしれないが試していない。
  • Hyper Estraier
    全文検索システム。wwwoffleのキャッシュファイルを処理することで検索結果から元URLにダイレクトに飛ぶことができる! これが良さそう。設定方法は公式サイトに掲載されている。参照サイトを参照。また、wwwoffleにはHyper Estraierが同梱されているので、別途用意しなくていい。
  • Namazu
    全文検索システム。かなり昔にNamazuを使ったローカルwiki全文検索+検索結果からの元URLジャンプを設定した記憶があるが、検索性能的にHyper Estraierに優位性があるようなので()今回は使用しない。

SSL通信の設定について

(2022/7/3追記)
Firefox100.0.2までは問題なく使えていたが、102.0にアップデートしたところSSLのエラー(「SSL_ERROR_BAD_CERT_DOMAIN」)が出て使えなくなった。ダウングレードしたいが、リポジトリからFirefox100.0.2が消えておりdebファイルも手に入らないため、やむなくfirefox-esrの91.11.0(
Firefox ESR and Thunderbird stable builds : “Mozilla Team” team)に変更したところ元通りエラーなく利用できるようになった。将来的にfirefox-esrでも使えなくなる可能性があるので、/var/cache/apt/archives/にダウンロードされたfirefox-esrのdebファイルを別の場所に保存しておいた方がいいかもしれない。

(2020/5/8追記)

SSL通信をキャッシュする

昨今はサイト全体でhttpsでの通信を行なうサイトが一般的となっているが、デフォルトではhttpしかキャッシュできず有用性が低い。
https通信のキャッシュに対応するには、wwwoffleをコンパイルする際に--with-gnutlsオプションを付けておく必要がある。

./configure --with-gnutls

設定ファイル(wwwoffle.conf)は、「SSLOptions」で以下の項目を追記する。

SSLOptions
{
enable-caching = yes
allow-cache = *:443
}

そして、「(wwwoffleキャッシュディレクトリ)/certificates/root/root-key.pem」のファイルが既に存在している場合、パーミッションが777になっているとうまく行かないので一旦ファイルを削除して、wwwoffleを再起動して同ファイルを再度作成させておく。
次に、「http://(サーバ):(wwwoffleポート番号)/certificates/root」のURLをブラウザで開き、[Download Certificate]から証明書をブラウザにインストールする。
「証明書の信頼性を設定してください」のダイアログで「ウェブサイトの識別に使用する」にチェックを入れると、httpsページもキャッシュすることができるようになる。

注意する点として、オンラインバンクのような機微情報を扱うサイトについては、通信内容をキャッシュしないよう「disallow-cache =」にオンラインバンクのサイトを登録する必要がある。
手元の環境では、設定が悪いのかもしれないが、Amazonや日経など一部のページでスタイルシートを読み込まなかったり、twitterなどでページが全く表示されなかったりといった不具合があった。そうしたサイトはブラウザ設定の「プロキシなしで接続」リストに記述して、wwwoffleを介さずにアクセスするようにした。

SSL通信のキャッシュをHyper Estraierデータベースに登録する

Hyper Estraierのestwolefindコマンド(/usr/bin/estwolefind)がデータベース作成の対象とするディレクトリは、wwwoffleキャッシュディレクトリ下のhttpディレクトリ決め打ちとなっているため、httpsでアクセスしたページはそのままではHyper Estraierのインデックス対象とならない。
estwolefindコマンドの中身の'http'を'https'で全置換し、estwolefind-httpsのように改名してコピーしたコマンドを作成し、このコマンドをインデックスを作成する自動実行ファイルに追記すれば、httpsページも自動でインデックスを作ることができ、検索結果からリンククリックで元ページに飛ぶことができる。

その他

  • polipoの親プロクシ設定について
    polipoをwwwollfeの親プロクシとして使う場合は、parentProxyでpolipoを設定できる。「Proxy Loop」のエラーが出た場合は「proxyName」をアンコメントすればよい。
  • wwwoffle使用時にページが更新されない場合
    端末から「wwwoffle -online」を実行してみる。
  • Hyper Estraierの検索結果画面の初期状態でフォームにフォーカスを当てない設定
    一般的な話ではないが、FirefoxアドオンVimperatorやChrome拡張Vimium(いずれもキーボードオンリーでブラウザを操作するブラウザ拡張)を使っていて、マウスを使わずにブラウザを操作している場合に、Hyper Estraierの検索結果のページ表示直後の状態だと入力フォームにフォーカスが当たっていて、いちいちEscを押してフォーム入力状態を抜けなくてはならないのが煩わしく感じる。
    これを解決するため、estseek.tmplの295行目を以下のように修正した。この修正をしても、「検索前」の画面では初期状態として入力フォームにフォーカスが当たるままとなるので面倒はない(余談として、元のコードで「#」を数えている箇所があるが、なぜ「#」を数えているのかは分からなかった)。
  • <script type="text/javascript">function startup(){
    if((document.location + "").indexOf("phrase") != -1) return; // ←修正
    //  if((document.location + "").indexOf("#") != -1) return;    // ←元
    var elem = document.getElementById("phrase");
    if(elem) elem.focus();
    }
    

課題点など

  • 別ホストから利用する際の不具合
    ローカルネットワークの別のホストからwwwoffleのキャッシュサーバを利用しようとすると著しく反応が遅いが原因不明。時おりローカルホストからのアクセスでも反応が遅いことがある。
    スマホやタブレット端末のプロキシにwwwoffleを設定してhttpsのページを閲覧しようとしたところ、iPhoneの場合、Safariでは警告が出て閲覧できたりできなかったり、Firefoxは警告が出て閲覧不能、はてなブックマークアプリも閲覧不能だった。Androidの場合は証明書を入れても閲覧できなかった。このためスマホやタブレットからの利用は断念した。
  • Chromeから利用する際の不具合
    Chromeで使う際、オプションの「--proxy-pac-url=」で自動プロキシ設定を指定しているが、どうもwwwoffleに接続していないような気がする。Firefoxをメインで使っているのであまり気にしていないが、Chromeを使う場合は検討が必要かもしれない。
    (追記)
    結論としては、現状Chromeからwwwoffleを使うことはできない。
    理由としては、wwwoffleの証明書がChromeの様式と合わないことが原因らしい。
    以下は詳しい内容。

    chrome72ぐらいからproxy-pac-urlにfile://プロトコルを受け付けなくなったらしく、webサーバの公開ディレクトリにproxy.cfgを置いて、http://で記述してやれば接続できる。

    At some point (around Chrome 77 it seems), Chrome stopped accepting file:// URLs for --proxy-pac-url.

    you are probably better either installing a browser plugin that lets you define PAC settings, or use an http(s) PAC file.

    ただし、Chromeでは以下のエラーが出てwwwoffleの自己署名証明書が受け付けられなかった。

    この接続ではプライバシーが保護されません
    yahoo.co.jp では、悪意のあるユーザーによって、パスワード、メッセージ、クレジット カードなどの情報が盗まれる可能性があります。詳細
    NET::ERR_CERT_COMMON_NAME_INVALID
    このサーバーが yahoo.co.jp であることを確認できませんでした。このサーバーのセキュリティ証明書で SAN(サブジェクトの別名)が指定されていません。設定が不適切であるか、悪意のあるユーザーによって接続が妨害されている可能性があります。

    これは、Chromeの仕様変更により、ドメイン名のチェックにSANを使用するようになったからとのこと。

    ローカル環境でhttpsを実現するために、オレオレ(自己署名)SSL証明書を作成したのですがchromeではNET::ERR_CERT_COMMON_NAME_INVALIDとなってしまいました。
    Chromeの仕様変更により、ドメイン名のチェックをCommon Name(通称CN)ではなくSubject Alternative Names(通称SAN)を参考にする様になったためだそうです。


所要時間

調査・設定には10時間を所要した。だが、「自分にパーソナライズされた(閲覧履歴内の)ウェブ全文検索」という利便性は代えがたいものになるだろう。

参照サイト