Kanasansoft Web Lab.

Firefoxが固まっても強制終了後にすぐ再起動したりして、OSを10日以上起動しっぱなしで使っていた。
それが原因かはわからないが、Firefoxが起動しなくなった。
OSを再起動しても無理。
で、safemodeなるものがあるので、起動してみた。

この時点でかなり焦る。
セーフモードで起動して、さっきまで弄っていたadd-onの除去やキャッシュのクリアで直ると思っていたからだ。
libxptやXPCOM、xptが何か調べたり、TypeLibを調べたりしたけどよくわからない。
とにかく切り分けが必要だと思った。
考えられる場所としては、大きくわけてSystem、Firefox、Firefoxの個人データの3つ。
Systemだとかなり厄介だし、個人データだともしかしたら取り返しのつかない事になるかもしれない。
Firefoxであればと願いながら、次の作業をした。

[~/Library/"Application Support"/Firefox]にある個人データを別の場所に移動。
Firefoxを起動してみる。
同じように落ちる。
これで、個人データの可能性は低くなった。
例えば、Firefoxと個人データが同時におかしくなっている可能性はゼロじゃないのでまだ安心できない。
新たにできた[~/Library/"Application Support"/Firefox]を削除。
[/Applications/Firefox.app]を削除。
Macでは、uninstall作業はほとんどの場合、appファイルを削除するだけで済む。
で、手元にあるFirefoxをinstall。
これも、Applicationsに直接放り込むだけ。
これまで使っていたFirefoxは3.0.3だけど、installしたのは3.0.1。
個人データとApp本体のバージョンが違って、また不具合を起こしかねないので、Firefoxを3.0.3にupdate。
Firefoxを落として、また新たにできた[~/Library/"Application Support"/Firefox]を削除。
[~/Library/"Application Support"/]に個人データを複製して戻す。
Firefoxを立ち上げなおす。
直った!

ドキドキですな。

なかなか開催までこぎ着ける事ができませんでしたが、prototype.js CodeReading#6開催します。

今回は、kanasanがなかなかまとまった時間がとれなかった事もあり、スタッフ主体で準備しています。
ありがとうみんな。
kanasanだけだったら少なくとも後半月は開催できなかったと思います。

そもそも、何ヶ月も前から移行を考えていたのですが、前回のJavaScript第5版読書会#5直後に、Google Groupsのほうでspamが相次ぎ、siteの移設が最優先になりました。
ところが、最優先にも関わらず全く作業が手つかずのままズルズルと9月になってしまい、スタッフと大急ぎで新siteを構築しました。
新siteはGoogle Sitesにあります。
前回まではGoogle Groupsとcotocotoで申込を行っていましたが、今回からはGoogle Sitesに一本化しています。

「そもそも、何ヶ月も前から移行を考えていた」と書きましたが、次のような状況にあったからです。
これまでは、テンプレートがあるにも関わらず、分散していたため申込ページをつくるのに2時間程かかっていました。
参加者の管理に使っていたcotocotoは、単発イベントの申込には非常に楽なのですが、継続したイベントでは少々煩雑になってしまいます。
しかし、Kanasan.JSではGoogle Groupsで告知、cotocotoで勉強会と懇親会の受付を行い、それぞれ相互リンクを貼る変人的な形態をとっていました。
特に辛かったのは、セッションの関係で勉強会と懇親会を同時に編集できないため、編集・更新の順番等、Bad Know Howの固まりだった事です。
非常に神経を使う作業だったため、申込開始作業が開催までの最大のボトルネックとなってしまった回もあります。
cotocotoが使いにくいとかではなくて、そんな変人的な使い方をしているKanasan.JSの運営の問題です。
cotocotoは何も悪くないです。

Stylishは、GreasemonkeyのStylesheet版って感じのもの。
GreasemonkeyはJavaScript、StylishはCSS。
UserScriptsに対してUserStylesだし、http://userscripts.org/に対してhttp://userstyles.org/だし。
とりあえず作ってみた。

Lingrの発言をフキダシにする。
試しに作ってみただけなので、大した事はしていない。

電脳コイルを見たので作ってみた。
ネタバレを避けるためにタイトルは少々わかりづらく書いた。
例のごとくFirefoxでしか検証していない。
このBookmarkletを実行すると、画面内の全ての画像が電脳コイル現象をおこして電脳体が分離する。
全ての言っても、positionがfixedの画像は適応外。
大きく分離した時に元の画像を濃くしてNO DATAって表示させようかと思ったけど、filter関連が面倒なのでやめた。
今思ったけど、NO DATAにならないと電脳コイル現象って言わないんだっけ?
まあいいや。

JS界のプリンスがこんなサービスを公開した。

複数のソーシャルブックマークを時系列に並べるサービス。
で、せっかくなので自分のblogでブックマークが一番多くついたentryを試してみた。

上記entryのチャートマニアックスがこれ。

そしたらこんなの見つけた。

同じ事考えてた人がいたんだw
それを実装したのがこれ。

もしかしてこっちもブックマークされてる?

採用も何も今日はじめて知りましたw

関係ないけど、複数のソーシャルブックマークに一度に登録するいい方法ないかなと...。
単純にpostするんじゃなくて、落ちているソーシャルブックマークがあったら後でpostしなおして同期してくれる機能が欲しい。

関西にもJavaScriptの勉強会が欲しいとはじめたKanasan.JS、初回はprototype.jsのCodeReadingでした。
初回の余りのレベルの高さからサイ本の読書会を併設して、以後交互に実施してきました。
prototype.js CodeReadingは今回で6回目、とうとうprototype.jsを全て読み終わりました。
サイ本がまだ途中なのであまりやり終えた感はありませんが、とりあえず少しは安堵しています。
サイ本読書会もあと数回で終わりそうなため、しばらくは読書会が続く予定です。
ただ、その後のKanasan.JSの方向性もまだ決まっていません。

prototype.jsの次はjQueryという意見もありますが、Roppongi.JSとかぶってしまします。
開催スタイルが違うのでべつにかぶっても良いと言えば良いのですが...。
一番現実的な案です。

オライリーのJavaScript & DHTMLクックブックも考えていますが、どんな内容かあまり把握していません。
今年改訂されたので向いていると言えば向いているとは思います。

Greasemonkeyがありますが、その特性上あまり深く追う事はできなさそうです。
GreasemonkeyのAPIはそれほど多くはないですから、それを一通り学んで後半は各自でuser scriptを作成、良い案だとは思っているのですが多分一回で終わるでしょう。
ソースは「Dive Into Greasemonkey」の日本語訳が最有力です。

同じ方向性として、Google Gears等のクライアントストレージもありますが、こちらもあっというまに終わりそう...。

FirefoxのAdd-on(またはXUL)の作成も考えたのですが、JavaScriptというよりはFirefoxに偏り過ぎている感じがします。
Greasemonkeyの延長上にあるとも考えられますし、中ではJavaScriptが多用されるので関係ないとは言えないのですが...。

他の勉強会のように講義形式も考えたのですが、参加者の人数的に講師が集まるかどうか...。
CodeReadingや読書会でなければ参加しますという人が多ければ考えても良いと思いますが、その人数が未知数で踏み切る事ができません。

何かいい案があったら教えて下さい。

勉強会に関する情報が恐ろしい勢いでネット上に充実してきています。

はなずきんさんの今年の始め頃から兆候はあったと思っているのですが、IT 勉強会カレンダーが知られるようになり更に加速しています。

ITカレンダーが一般に取り上げられるようになったきっかけがnitoyonさんのこちらのentry。

以後、あちらこちらで取り上げられるようになりました。

そして、IT 勉強会カレンダーを活用した色々な事が起きています。

「IT 勉強会カレンダー for Mobile」はQRコードを作成したのではっておきます。

勉強会っていっても参加者向けの情報だけではありません。
主催者側の情報もちらほら出てきています。
主催者・講師向けの情報爆発がいつおきるのか期待しています。

はなずきんさんへの情報提供の窓口はこちら。

ただ、危惧していることを何点か。
開催が多すぎて参加者の取り合いになってしまわないかという事。
活発になるのは良いのですが、活発になり過ぎてコミュニティ全体が疲労してしまわないかという事。
主催する事の敷居が下がる事で勉強会の乱立、そして勉強会の質が平均して下がり、結果として参加者が減っていかないかという事。

参加者層を考慮した日程の調整は、勉強会主催者同士のMLで行なってはいますが...。

特定の誰かを示しているのではなく、諸処で色々あったので書きます。
XSSを放置するという事がどういう事なのか説明してみます。
まずは、以下のリンク先をご覧ください。

どうですか?
ちょっと気持ち悪くないですか?
新聞社のサイトで確認すると、その人の思想もある程度確認できます。
特定のニュースを読んだ事も確認できます。
詳しく書くと悪用されるので詳細は書きませんが、やろうと思えば特定のサービスのidやハンドルネームも取得できます。
色々なサービスのidやハンドルネームを結びつけることもできます。
そしてそれらの情報を別の場所に送信することもできます。
これって、JavaScriptだけでできるんですよ。
XSSは使っていませんが、JavaScriptを使うとこんな事もできるんです。
JavaScriptでできる事はこれ以外にも沢山あります。
数ある実行例の一例を示したに過ぎません。
XSSと何が関係あるのかって?
XSSはhtmlにJavaScriptを埋め込む行為ですよね。
言いかえると、XSSの脆弱性のあるサイトは、『見にきた人のブラウザ上で、第三者が自由にJavaScriptを実行できる状態』にあるってことなんです。
その上、XSSはXSS以外の脆弱性を利用するために利用できます。
これがどれだけ危険な事かとご理解いただけますか?

あなたを、あなたの作ったサービスを信用して訪問してくれた人全員をこのような危険にさらしているんです。
悪質なサイトに寄りつかなくても、あなたのサイトに訪問しただけでです。
それでもXSSを放置するのですか?
それって訪問者に裏切り行為だとは思いませんか?

社内システムだから大丈夫?
この方法はLANかどうかなんて関係ありません。
アクセス制限をかけてるから大丈夫?
全部のサイトにですか?
非現実的ですね。
ログを取っているから大丈夫?
それって抑制力になるだけですよね。
ログがあれば犯人を特定できるから大丈夫?
実行された後の対処策にしかならないですよね。

簡単です。
今すぐ修正してください。
バグのないシステムを作るのは不可能ですが、バグを修正することはすぐにできます。
XSSが発生した経緯や周囲の状態等関係ありません。
今すぐ対処してください。
それが、そのサービスやシステムを使う人のためであり、あなたのためであるからです。

個人的にはXSSは『JavaScriptインジェクション』と呼称した方がいいのではと思っています。
SQLインジェクション等、他のインジェクション系不具合と対処の考え方は同じだと思うので、こう呼んだ方が統合的な対応ができるんじゃないかと...。

今読み返すと、あちこちに変な日本語が混じっていますね。
訂正するのも嫌らしいのでそのままにしておきます。

はてなブックマークというサービスで、当エントリーに対してついたコメントに返信していきます。
このエントリーには、「XSSの危険性をわかっていない人に理解してもらう」というのが前提としてありました。
そして、「技術の疎い人にも理解して動いてもらう」という願いもありました。
このために、「多少の誤解を与えたとしてもなんとなく理解してもらう」事を重要視しています。

これを踏まえて以下記述します。
「#」ではじまるのがはてなブックマークのコメントです。

#2008年10月24日 g616blackheart ガードが堅いと言われた……どうしてだろう？
#2008年10月24日 anigoka なんかガードが堅いて言われちゃったんだけど、なに,オレが非コミュだって言いたいの！？

申し訳ないです。実行結果を見たときの気持ち悪さを優先したため、非常にわかりにくくなってしまいました。
調査結果は日本語で書くようにしています。
一覧等の無機質な情報を表示するのではなく、得られた情報から第三者がどのように推測するかを想定していました。
ガードが堅いというのは、何も情報が得られなかった時に表示されます。

#2008年10月24日 hasegawayosuke XSSでJavaScriptが動くのはその脆弱なサイト上なので、特定サービスのidやハンドルネーム云々は関係ないぢゃん。visited調査は攻撃者が自分でサイト用意しても一緒ぢゃん。…という反論にはどう対応する?

id/ハンドルネームを取得できてしまうサービスには、「脆弱性等、本来意図していない挙動によりid/ハンドルネームが取得されてしまう」場合と、「管理者サイドではid/ハンドルネームの取得を(本当の理由がどうであれ)仕様と見なしている」場合があると思います。
今回は後者を前提としており、脆弱性のない普通のシステム/サービスにおいても、id/ハンドルネームは取得できる場合を指していました。
後半で他の脆弱性を利用するためにXSSが使われると書きましたが、先にid/ハンドルネームの話を持ってきたのはこれが理由です。
visited調査に関してですが、危険なサイトを訪問しなくてもXSSのあるサイトでも起こりえるというのが重要なので充分に反論できると思います。

#2008年10月24日 hiroyukiegami 非常にいいまとめ

非常にいいまとめではありません。
XSSを理解している人からすると非常に歯痒いエントリーだと思います。

#2008年10月24日 showyou ちょっと気になるとこあったのでエントリ書きました。http://d.hatena.ne.jp/showyou/20081024#1224846631
#2008年10月25日 Kanatoko JavaScriptインジェクションとXSSは違うのでつよ
#2008年10月26日 kicchomu3 XSSはJavascript以外でもできるでしょ。

その通りですね。XSSはJavaScriptのみではありませんでした。
a要素・img要素・iframe要素のようなhtmlもありますし、CSSでも表示を変更する事ができます。
VBScriptもありました。
object要素を含めるとなんでもありますね。
「個人的にはXSSは『JavaScriptインジェクション』と呼称した方がいいのではと思っています。」は訂正します。
そもそも『JavaScriptインジェクション』という言葉は既にあったようです。
個人的には『インジェクション』という言葉を使った方が対策が進むのではないかと思っているので、こう書いてしまいました。
意図しないような反論をまた受ける可能性を恐れずに書くと、『クライアントコードインジェクション』はどうでしょうか。

#2008年10月24日 Kenta_K 検索はGoogleしか使わないのに、Yahooって言うニュースサイトで検索してるって言われたんだけど…？

これはcheck_visited.htmlの精度の問題です。
対象は、このblogを見に来られる人やはてなを使っている人がするようなリンクを使った画面遷移ではなく、「技術に疎い人」がブックマーク(お気に入り)で画面を表示する場合を想定しています。
あと、ニュースサイト限定ではなく、『全般』の話です。
ここでは詳細を避けます。
詳しく知りたい方はコードを読んで頂くか直接ご連絡下さい。

#2008年10月24日 sippu おお怖い。こういう手法もあるのか。ってかこれってよく使う方法も良くあるよね？（お勧め表示とか）

よくあります。
ただ、道徳的に問題はないのかという話もあります。
まだこの方法の評価が固まっていないのでどうなるかはわかりませんが、道徳的に問題があるという認識になるのではないかと思っています。

#2008年10月25日 into_the_blue 悪質なサイトじゃなくても、実はやっていること。わざわざ脆弱なサイト見つけてまでこれをやるより、どーせならCookie盗んで（ｒｙとかキーロガーしかけて（ｒｙのほうがいいな（自分が攻撃者だったとしたら）

そうですね。Cookieやキーロガーの方が対効果比が非常に高いと思います。
ただ、それらを見せられるよりも今回の方法の方が『一般的な人は気持ち悪いと感じる』と考えてこのようにしています。
それに、Cookieを盗んだりをここですると私が訴えられる可能性もゼロではなくなるのでご了承下さい。

#2008年10月25日 m-_-m 勤勉なNoScriptのお陰で「訪問先確認」が真っ白ﾜﾛﾀ

NoScriptを入れられるとJavaScriptでは手も足もでません。

#2008年10月25日 fuktommy "あなたの作ったサービスを信用して訪問してくれた人"←もちろんkanasansoft.comなんぞ信用してないので無問題。

どう反応していいのか悩んだのでのですが...。
冗談なのかネガティブコメントなのか判断がつきません。
(とある人にはネガコメと断言されました。)
とりあえず、そのまま受け止めて返事しますが、当ブログ上では信用されない事はしていないつもりです。
その辺りかなり気をつけて書いていますのでこう書かれるのは非常に残念です。
特にfuktommyさんとはこれまで一度も接触がなかったために、なんとも言えない気持ちです。
(もしこれが初接触でなければごめんなさい。)

iPhone/iPod touchではBookmarkletが使えたはずと思い、登録してみようと思った。
だけど、右クリックができないので登録できない。
Safariとの同期ならできるけど、iPhone/iPod touch側で完結したい場合はどうするんだろうと。
そうしたら、nanki氏にこんな方法を教えてもらった。

なるほど。
賢い方法。
でも、これだとBookmarkletを作成した人が準備しておかないと、結局登録できない。
準備されていなくてもBookmarkletをBookmarkするためのBookmarkletを作成した。
「iPhone/iPod touchでBookmarkletのBookmarkを補助するBookmarklet」のアルファベットの頭をとって数字で省略、iB3という名前にした。
命名は37to氏。
かっこいい名前をありがとう。
もう少しで「iPhoneBookmarkingBookmarkletSupporter」なんていうとんでもなく長い名前になっていた。

インストール作業がほとんど使い方と同じになる。
まずは、iPhone/iPod touchで次のURLを開く。

このように表示される。

指示に従いアイコンをクリックすると次のような画面になる。

この状態でBookmarkに登録。

で、登録したBookmarkを編集する。

URLの先頭に「http://www.kanasansoft.com/Kanasansoft/Bookmarklet/iB3/iB3.html?iB3&-----&」という文字列があるのでこれを消す。

そうすると、先頭部分が「javascript:~~~」となりBookmarklet化が完了。

seven stars waverを例にする。

ここでiB3を実行するとこのようになる。

表示されたアイコンをクリックするとこんな感じ。

で、インストールの時と同じようにBookmarkする。

最後に、Bookmarkを編集し、Bookmarklet化が完了。

a要素のhref属性が「javascript:」で始まるかどうかを判定してアイコンを挿入している。
このため、Bookmarkletだけではなく他の物にも反応してしまう。
つまり、iB3がアイコンを追加したもの全てがBookmarkletとは限らない。

nankiさんがもの凄く面白い物を作った。
例えばこんな画像。

URLに命令を入れるとこんな感じに。

か、かっこいい!!!
詳細は以下のURLへ。

apple-touch-iconを動的に生成したり色々面白い事ができそう。
ただ、自分はcairoとかよくわからないのが非常に残念。
誰か、MacのAutomatorみたいなGUIを作ってくれないかなぁ。

iB3をバージョンアップしました。
画像にはられたBookmarkletの場合、タイトルが取得できなかったため、DOM Treeをたぐってtextを取得しつつ、画像のtitleまたはaltを取得するようにしました。
iB3の詳細は以下のURLを参照してください。

というわけで、「id:Ubuntu のブックマークにコメントを追加する Greasemonkey スクリプト」を作成しました。

ランダムにコメントさせても人間味がなく飽きてしまうので、「他人のコメントを略奪するGreasemonkeyスクリプト」となっています。
かならず、略奪に成功するわけではありませんのであしからず。
略奪された人のコメントは薄い赤で「sacked」となります。

ネタはネタとして消化してください。
m(_ _)m

SQLiteのDBは、肥大化し易いらしい。
一度大きくなったファイルが勝手には小さくならないとかなんとか。
つまり一度大きなデータを入れた後に、DeleteやDropを実行しても容量は変わらないという事らしい。
で、それを整理するのがvacuumという処理。
SQLiteのmanを見ても--helpを見てもよくわからなかったのでGUIのあるtoolを探してみた。
で、あちこちで言及されているのがTkSQLiteというやつ。

でも、ほとんどがWindows版の説明でMacで使う方法が書かれていない。
よくわからないままDLして実行してみたけどPackageが足りないとかでErrorが発生。

tkだかtclだかもうわけが分からないが、依存関係のようだ。
じゃあ、MacPortsで。
こいつなら依存関係があってもなんとかしてくれる。

え、ないの?
で、しばらくネットを探しているとこんなものを見つけた。

Add-onでDB Manager?
マジで?
入れてみた。
すごい!
Tableを見られるだけじゃなく、IndexやTriggerも見られる!
SQLも実行できる!
XULからSQLって無茶しすぎで笑った。
どうやってるんだ?
で、vacuumの実行方法を探したけど見当たらない。
また、ネットで調べる。

え、ちょっと待って。
じゃあ、Unix/Linuxの場合は、「sqlite3 [DB_Path] vacuum」でできるってこと?
試してみたら、できた。
Add-on入れた意味ないし...。
まあ、今度から使うから良いけど...。
SQLite Managerでのやりかたは、「[メニュー]=>[Database]=>[Compact Database]」っぽい。
試してないから詳細はわからない。
結果的には、54.3MBあったファイルが40.3MBまで減った。
で、アプリケーションにDBファイルを戻してみた。
気のせいか、若干はやくなっている。
もしかしてIndexを構築しなおした?

Google ChartでQRコードが生成できるらしい。

これは便利。

で、このblogのURLで試してみた。

おお、できた。
これは色々応用がききそうだ。

そういえば、本文を全部QRコードで配信しているblogがあったなぁ。

あれ?
更新終了してる。

チョコレートのネタとか好きだったのに...。

QRコードって画像や着メロも埋め込めるんだよね。
やり方はすっかり忘れたけど...。

タイトルの通り。
現時点での情報をとりあえず書き出す。

ネット環境が貧弱な会場での配信は、通信が細切れになっていたため、flvが86個に分割されてしまっている。
Ustreamは配信者はflvをDownloadできるが、他の人はdownloadできない。
Downloadできたとしても、audioがNellymoserというとてもマイナーなcodecなため再生環境構築が面倒。
Downloadしたflvを会ごとに無劣化で結合したい。
できれば、沈黙部分を削除したい。
audioをNellymoserから他のcodecへの変換の仕方がよくわからない。
変換後のflvもしくはmpeg4等をUpしておくだけの十分なServerのストレージ容量が確保できない。
沈黙部分を削除できれば、もしかすると容量はそんなに必要ないかもしれないが、会ごとに4~5時間は当たり前なので手動では到底無理。
Podcast化できればいいが、PodcastのRSS(atom?)の仕様がよくわからない。
贅沢をいうと、発言を文字データ化したい。

未整理の情報のため、トラックバックはしない。

Geek(はてなonly?)の間ではustreamが大勢を占めるが、一般的にはStickam.jpなのかもと言う話。

Podcastのみの模様。

ffmpegの最新versionではNellymoserに対応したと、どこかのsiteで見た覚えが...。
このため、ffmpegに依存している(はずの)VLCやPerianでもcodecの変換が可能になったらしい。