Life on the Kernel

大学のアカウントが使えなくなるので停止しました。 いくつかのパッケージに関しては、作者に連絡を取って保管場所を確保していただきました。

某スレの書き込み を見て作ってみた。

  http://xeres.s55.xrea.com/services/google-homepage-api/japanese-weather.xml

これを、[コンテンツの追加]→[セクションの作成]から追加する。

見た目はこんな感じ。

セクションの高さの設定がうまくいかん。とりあえず 128px にしておいたけど、 ユーザがどんなフォントサイズを使っていても綺麗な高さになるようには どうすればいいんだろう。

あぁ、やっと unstable に来たか、という感じ。

ほとんどの日本語 TrueType フォントには太字(bold)に関する情報が含まれていないため、 Firefox なんかで太字が表示できなかったりする。それを可能にする方法は、 これが詳しい。 で、必要なパッケージが unstable に来た、ということらしい。

「言及なしトラックバック」はなぜ問題になるのかという記事を見付けた。

トラックバックの問題について考えてる人は他にも色々いるし、関連する 記事を何度も読んだが、どうも事の本質を捉えてないように感じる。

トラックバックスパムや挨拶トラックバックが問題になってる一番の理由は、 外部の人間が他人のコンテンツ(のリンク)を勝手に追加できる、という点じゃ ないのか。

逆に言うと、ブログ所有者が受け入れるトラックバックのポリシーをブログの 所有者自身が決めることができない。これ。同じような問題が電子メールにもある。

かつて SMTP が RFC になった時、セキュリティに関する考察は皆無だった。 RFC 821 に security や authorization、authentication なんて単語は皆無。 メール転送のメカニズムに認証や相互正当性の証明を組み込まなかったために、 20 年以上経った今でも、スパムメールに頭を悩ませてる。

トラックバックスパムをスパムフィルタで防いで「問題ない」なんて 言っているのは、ベイジアンフィルタがあるから SMTP には「問題ない」と 言っているのと同じなわけで、アホ丸出しなこと極まりない。 言及なしトラックバックをハネるのも一緒。そうじゃねーだろと。

なので、メールなんかだと後付けで SenderID とか色々やってるわけだ。

でもセキュリティは後付けのシステムでは駄目で(古いシステムを捨てることになってしまう)、 メカニズムのレベルで保証しなくてはいけない。強固で、かつ拡張性が高ければなお良し。

今、新たに勧告される RFC のほとんどに Security Consideration の章がある。 インターネットの世界では、セキュリティをメカニズム(多くの場合は プロトコル)で保証する必要があるということを、皆が経験的に分かっているから。

根本的な解決策を見付けない限り、トラックバックもスパムも、無くなることはないだろうな…。

TK-BLOG で 日本語リソース が 公開された。使ってみたらバッチリ。

早く公式に取り込まれたら良いのだが…。