ひぐまのひまグ

日本の住宅街を

こんな人が徘徊してたら明らかに変質者扱いされるし警察に通報されて連行される可能性が極めて高いと思われるのに

これだと

出典：Noriyukiのblog: あやしいプリウスとの遭遇(^^)

何も言われないのは何故だろう。実に興味深い。

>>続きを読む

自分ははてなユーザーではありませんが、はてなブックマークのhotentryは情報収集に利用させてもらっています。勿論その多くは有益な情報で構成されているので情報源のひとつとしてはかなり重宝しているのですが、反面ある特定エントリにネガティブコメントが集中したり、はてなユーザー同士の内紛が繰り広げられている様子が延々と上がってきたりすることがありました。

個人的にはそういったエントリには興味がないのであまり見たくはないのですが、確か現在のはてブでは「○○を含むエントリ」を抽出することはできても逆はできなかったと思います。幸いにして自分が使っているSage++ (Higmmer's Edition)では広告ブロック機能が実装されており、それを利用すればURLでフィルタをかけることが可能なので、何度も目にする嫌なサイトはこれで除去してそれ以外は脳内フィルターを適用するなどの対策を取ってきました。

ところが最近では論争が拡大の一途を辿り、遂には外部サイトを巻き込んで一種の「同時多発はてな紛争」とでも言うべき状態になっているように思います。こうなってくるとURLフィルタだけではとても間に合いません。というわけで作ったのが次に紹介する「Hatebu Tag Killer」と「Hatebu Tag Killer G」です。

Hatebu Tag Killer

• Hatebu Tag Killer

Yahoo! Pipesで記述したフィードフィルタです。はてブが生成するフィードから特定タグを含むエントリを除去することができます。除外するタグは16個まで指定可能(*1)。現在のYahoo! Pipesでは出力フィードのタイトルを設定することができないようなので、代わりに各エントリタイトルの先頭に特定文字列を付加する機能も付けてみました。

ただ残念ながらhotentryのRSSフィードでは最大で5つまでしかタグが出力されず、しかもその選別基準がイマイチ不明(*2)なのでこれだけでは多くのエントリがスルーしてしまいます。そこで以下の2つのPipeを用意しました。

• Simple Title Filter
• Simple Url Filter

これらはその名の通りタイトルやURLに特定の文字列を含むエントリを除去します(各16個まで指定可能)。URL欄にHatebu Tag Killerで生成したフィードのURLを入れることで更に絞り込みを行うことができます。勿論、他にも例えば広告エントリを除去したいような場合にも利用可能です。

注意点として、これらのフィルタを組み合わせる場合は必ず最初にHatebu Tag Killerから適用して下さい。これはYahoo! Pipesが出力するフィードからは何故かdc:subject要素＝タグ情報が削られてしまうため、後からでは選別することができなくなるためです。

Hatebu Tag Killer G

上記のフィルタでhotentryのフィードを見ている分にはかなり快適になったのですが、実際には特定エントリのコメントページを開きたい場合も多々あります。実ははてなにログインすると非表示ユーザーの設定も可能らしいのですが、ユーザーでない自分はこの機能を利用することができません。というわけで同様の動作をGreasemonkeyで実現するスクリプトを書いてみました。

• hatebutagkillerg.user.js

このスクリプトを導入することで個別のエントリページから指定した条件に一致するコメントを除去することができます。指定できるのは「はてなID」「タグ」「コメント文字列」の3つで、条件にはプレーンテキスト(完全一致)又は正規表現が使えます。条件を設定するには直接コードを開いて該当箇所を編集して下さい。例えば以下のように記述します。※ファイルのエンコードをUTF-8にして保存するのをお忘れなく！

更にコメント無しのブックマークを除去することもできます。その場合は変数killEmptyCommentsの値をtrueに設定して下さい(デフォルトでtrue)。またlogOutputをtrueにするとフィルタの適用結果がエラーコンソールに出力されます。

ちなみにコメント欄上部に追加される [show/hide] ボタンを押すことで除去されたコメントの表示/非表示を切り替えることもできます。フィルタに引っ掛かったコメントは背景色がピンクで表示されるので、これを逆に利用して敢えて特定コメントをウォッチしてみるのもなかなか面白いかも知れません(笑)。

CPU使用率上昇問題が復活

これはずいぶん前から気づいてはいたんですが、NoScriptの現在公開されているバージョンには一度直ったはずの「NoScriptを長時間使い続けるとCPU使用率が上昇する問題」が復活しています。逐一追いかけていたわけではありませんがどうやら

v 1.1.4.6.070325
x Fixed regression, leak happening on window closure (10x pirlouy)

NoScript CHANGELOG より

この修正によってこちらが提案したパッチが外されてしまった模様orz。でも「ウィンドウを閉じる際のリークを修正」とありますが少なくとも当方の環境ではLeak Monitorで観察する限り特にリークは確認できませんでした。仮に何らかのタイミングで発生するとしても(自分の使い方では)NoScriptが通知バーを出す頻度の方が圧倒的に高いわけで、どちらの対策を優先すべきかは明らか(*)だと思うんですが…。

というわけでNoScriptの最新バージョンを使う場合は通知バーの表示を切っておくことをおすすめします。

NoScript作者とAdblock Plus作者がフォーラムでバトル

さて前記修正が入ったのと同じ頃、NoScriptの作者Maone氏はXSS対策の実装に取りかかりました。きっかけは恐らくこのフォーラムでAdblock Plusの作者Palant氏が「NoScriptは(Adblockも)セキュリティ対策としては使えない」と主張したことです。彼の主張(*)を自分なりに解釈すると、

1. NoScriptを入れるとまともに動かなくなるサイトが多すぎるので、ユーザーは「動作や表示がおかしかったらとりあえずスクリプトを許可」するのが癖になってしまう。
2. 一見無害かつ有用そうに見えるサイトを用意してユーザーの気を引くのは簡単。一時的にでも許可してくれたら攻撃者にとっては十分。
3. ホワイトリスト(信頼サイト)モデルの欠点：
   1. そのサイトにXSS脆弱性があったら細工したリンクを設置するだけであらゆるサイトから攻撃が可能(サーバー側スクリプトを動かすことができればJavascriptさえ不要)。
   2. 今日安全だったサイトが明日も安全であるという保証はどこにもない(誰かに書き換えられるかも知れないし、実は管理者が悪人かも知れない)。
   3. yahoo.comのような(メジャーで共同空間としても使われる)サイトがデフォルトでホワイトリストに入っているのは問題。
4. Firefoxといえども未知・未修正の脆弱性を突かれたらひとたまりもない。現実にFirefoxに対して行われた攻撃でNoScriptを入れていれば防げたという事例が示されない限りNoScriptは被害妄想ユーザーのためのものとしか思えない。

このPalant氏の容赦ない主張を受けて最終的にMaone氏は"I gave up answering."と応えています。私個人としては(脆弱性問題で苦い経験をした一人として)Maone氏に同情しつつもPalant氏の主張にも一理あると思います。個人的にはSageの問題が表面化するまではNoScriptは使ってなかったですし、今もどちらかというとセキュリティ対策というより各種トラッキング広告やアクセス解析などが裏で動くのを防ぐという意味合いの方が強いです(といいつつ当ひまグにも解析仕込んでますが…すみません)。

余談ではありますが、Palant氏によるとFirekeeperのようなIDS型――普段は何もせず実際に怪しいコードを検出した時だけ警告を出すというアプローチ(*)の方が好みだそうです。但し新たな脆弱性の発見から修正までの「繋ぎ」として適切なルールセットが提供されることが前提ですが。

XSS対策で深みにはまるNoScript

それはともかく、"Firefox with NoScript is safer than Firefox"というキャッチコピーを掲げるMaone氏にも意地があったのでしょう。それから怒涛の更新ラッシュが始まり現在まで続いています。公式アナウンスを見る限り前述の3-aの問題、つまりサイトのXSS脆弱性を突いた攻撃を防ぐ仕組みを実装しようとしているようです。詳しくは調べてませんがリクエストヘッダ(URL/Referer/POSTデータ等)に含まれる「危険な」文字をエスケープないし削除することで対策を試みている模様。

その手法がどこまで有効なのかの判断は専門家に任せるとして、表面的にはまともに動かないサイトを更に増やす結果になったようで(特にマルチバイト圏で)、公式フォーラムにも不具合報告が少なからず寄せられています。一応Anti-XSSフィルタを回避するフィルタも実装されていますがとても素人に扱えるものではなくなってしまっています。しかも突貫工事でコードを改修した弊害からか(?)様々なデグレードも発生しているようです。

結果としていつまで経ってもリリースが安定せず、特に1.1.4.8系ではほぼ毎日のように更新版がリリースされるという事態に陥ってしまっています(*)。作者の努力には敬意を表しますが、個人的にはここまでする必要があるのかというのがというのが正直なところだったりします。完璧を求めるあまり多くの一般ユーザーのことが見えなくなっているような気が……。

ちなみに私自身はXSS対策導入前(で自分のパッチが入っている)最後の安定版である1.1.4.6.070317までで更新を止めました。何か問題があったらその時また考えるつもり。

もう他に誰か作っている人がいるかも知れませんが、Yahoo!ブックマークで特定URLの情報ページを開いた時に登録者一覧とコメント一覧が同じタブに表示されるようにするGreasemonkeyスクリプトを書いてみました。

こんな風に表示されます。

URL情報ページの登録者一覧タブにコメントを挿入
(画面は404 Blog Not Foundを開いたところ)

動作確認はFirefox 2.0.0.3 + Greasemonkey 0.6.8.20070314.0で行いました。欲しい方は下のリンクをクリックしてインストールして下さい(使用は自己責任で)。

• yahoobookmarkembeddedcom.user.js
  →Yahoo! Bookmarks Usability Improvementsに機能を統合しました。(4/19追記)

ちなみに個人的にはこの方と同じくSocialなやつはあまり好きじゃないので、Yahoo!ブックマークは「アリ」だと思っています。でもやっぱりコメントも気になるのでこんなスクリプトを書いてしまう私はイケテナイorz。

本日Wiiのインターネットチャンネル正式版が配信開始されたということで早速試しに使ってみました。

• (お試し版と比べて)良くなった点
  • 起動時間が短くなった
  • お気に入りの表示が速くなった
  • ツールバーを消して全画面表示が可能になった
  • 細かいズームが可能になった
• イマイチな点
  • Bボタンスクロールがしにくくなった
  • Bボタンショートカットが誤爆しやすい
  • このページを開くとフリーズする

お試し版での不満点が着実に解消されているのは良かったんですが、Bボタン操作の仕様変更は個人的には改悪な気がします。特にスクロールはBボタンを押した位置からポインタをずらした方向にスクロールするように変更されたのが非常にやりづらい。動作としてはマウスの中ボタンを使ったオートスクロールに似ているのですが、あくまでそれはマウスではポインタが固定できるからこそ便利なのであって、位置をホールドしにくいWiiリモコンで同じことをやるのはとても疲れます。それに一旦スクロールを止めた後に再開させるにはその位置からまたポインタをずらす必要があってそのうち画面外に出てしまうので定期的に元の位置に戻す操作が必要なのが煩わしいことこの上なし。以前の仕様ではポインタを画面外に向けてBボタンを押したり離したりするだけでスクロールのON/OFFができて便利だったので、できれば従来操作に戻すオプションが欲しかったところ。

もっともその辺は新しく十字キーに割り当てられたスクロール機能を使えばある程度は改善するのですが、こちらはスムーズスクロールではなく行単位のスクロールですし、連続スクロールになるまで一瞬のタイムラグが設定されているので若干ストレスが溜まります。なので思わず力が入ってしまい、Bボタン＋十字キーに割り当てられたショートカットが暴発することもしばしば。これもできればショートカットを無効にできるオプションがあれば良かったなと。

それらはまぁ馴れてしまえば問題ないのかも知れませんが、個人的に最も残念だったのはこのページを開こうとすると100%フリーズしてしまうということorz。お試し版の時はちゃんと表示されていたので明らかな改悪です(*)。巷の評判を見ているとmixiとか表示できなかったページが表示できるようになっているらしいというのになんでうちだけ…orz。というか表示できないページがあったとしてもせめてフリーズじゃなくエラーメッセージくらいでるようにしやがれおながいします(ﾉД`)

先日NoScriptを長時間使い続けるとCPU使用率が上昇する問題について書きましたが、そこで示したパッチでは対策が不十分なことが判明しました。この修正を行っても依然としてCPU使用率が上昇する現象が発生することがあったのでおかしいとは思っていたのですが…。

原因は通知バーを閉じるタイミングにありました。複数タブを開いた状態でバックグラウンドのタブを閉じた場合、先日のパッチではそのタブではなくアクティブなタブの通知バーが閉じられてしまいます。結果、閉じるのに失敗した通知バーは無駄にCPU資源を喰い続けていました(*)。

今回これを修正するパッチ(*)を作ってみました。対象はNoScriptの1.1.4.6.070302です。適用する場合はくれぐれも自己責任で…(前回のパッチが適用済みの場合は先に元に戻して下さい)。

• noscript-1.1.4.6.070302-fix-cpu_usage_problem.diff(.txt)

尚、この問題について開発元に連絡したところ上記パッチを取り込んで頂けるとの感触を得ましたので、恐らく近日中に対処されるものと思われます →開発版の1.1.4.6.070305で対策された模様です(3/8追記)。または通知バーが不要なら表示をオフにしておくことでも対策することが可能です(この方が確実かも知れません)。

>>続きを読む

朝顔日記さんで知ったのですが、Firefoxのアドオンとして利用できる新しいフィードリーダー「Brief」が発表されたとのこと。一応フィードリーダーの開発(改造)に片足突っ込んだ者として興味あったのでちょっと試用してみました。

……なかなか良いですねこれ。見た目はローカルで使えるGoogle Readerといったところでしょうか。Sageの軽快さはそのままにGoogle Readerの機能性を追加したという感じです。特徴的な機能は以下の通り。

• 全フィードの未読エントリの一括表示
• 気になるエントリにはスターを付けて管理可能
• フィードはローカルデータベースに保存されるので後から検索＆閲覧可能
• 指定時間毎にバックグラウンドで更新チェックが可能

フィードがローカルに蓄積されていくのは確かに便利である反面データが増えると重くなったりディスク容量を食い潰したりする懸念もあるので(自分がSageを使う理由の1つがこれ)、個人的にはフィード毎に保存の有無や期限が設定できた方が嬉しいかな。それと現状では更新チェック周りに若干バグがあるようでたまに動作が不安定になります。というか更新チェック自体かなりのCPUパワーを食うようで、試しに普段購読している200余りのフィードをインポート(*)してみたところうちの貧弱なマシンでは30分経ってもチェックが終わらず遂にはFirefox本体ごと落ちてしまいました(しかもその後も起動する度に1分30秒ほど固まる)。この辺は今後改善されることに期待したいところです。

それと落書き part-4さんも指摘されていますが、ちょっとソースを覗いてみたところ現状BriefではテンプレートとなるHTMLファイルをローカル(fileスキーム)から読み込んでいるようです。そこにスクリプトを用いて動的にエントリを書き出す仕様なので……もうこれ以上言わなくても分かりますね。素人にはオススメできません(*)。

とにかく公開されたばかりのソフトなのでまだまだこれからといったところですが、今後の進化次第では有力な乗り換え候補になりそうです。作者の方は(これからが大変だと思いますが)是非頑張って欲しいですね。