ブラウザ別フィッシングサイト報告手順

もしあなたの所に Twitter の DM経由などでユーザー名・パスワード ペアを盗む怪しいフィッシングサイトへ誘い込むリンクが届き、そのサイトがまだブロックされていないことを見つけた場合、以下の手順でレポートすると速やかに (数時間以内程度) ブロックされるようになるようです。

Google Chrome
Google Chromeの設定 (右上のレンチ) > ツール > 問題の報告
> 問題が発生した箇所(フィッシング)
スクリーンショット付きを推薦

Internet Explorer 9
ツール (右上の歯車ボタン) > セーフティ > 安全でないWebサイトを報告する

Opera 11.61
メニュー (左上Opera) > ページ > 開発者ツール > セキュリティ情報
> フィッシング・マルウエア防止機能

Firefox 9
調査中
こちらのフォームに入力: フィッシング サイトの報告
ただし、Googleのデータを使っているのでChromeでレポートすれば不要

[twitter] Snowflake で生成された ID をデコードする

Snowflake とは Twitter の新しいStatus ID生成アルゴリズムの名前です。これはID生成サービスをスケーラブルなものにするために、生成サーバーのID(workerId, datacenterId)と時刻(timestamp)と、それらが重なった場合に増加させるカウンタ(sequence)に基づいて生成される64bit符号なし整数です。

したがって、このSnowflake IDをくっつける前の状態に戻すと元の要素に分解することができるので、それを作ってみました。JavaScriptではSnowflake IDは大きすぎて数値として扱えないので、BigNumber という多倍長整数演算ライブラリを使っています。

snowflake decoder
textareaを書き換えるとIDらしきものを抽出して詳細が表示されます。

リンク
Twitter Engineering: Announcing Snowflake
Twitter IDs, JSON and Snowflake
src/main/scala/com/twitter/service/snowflake/IdWorker.scala at master from twitter/snowflake - GitHub
はてな匿名ダイアリー - snowflakeの実際
mofigan's tumblr. - Twitterのstatus_idの生成アルゴリズムはsnowflakeなので、ビット演算をすれば投稿...

_nomapによるGoogle位置情報からの削除が完了しました

ポータブルWi-FiルーターにAndroid端末を繋いで使っていると、頻繁に自宅に連れ戻される症状に大変困っていました。これは周辺に他のアクセスポイントがない場合に、Wi-Fi位置情報によりポータブルルーターの位置を引いてしまい、普段ずっと使っている自宅を現在位置と認識するためです。

ブラウザ用Google位置情報APIではアクセスポイント1個の場合は測位不能になるのに、Androidからは1個で測位可能なのでこのような動作になるようです。

2011/11にGoogleにより発表された Wi-Fi位置情報システムからのオプトアウト方法 に従って、SSIDの変更を2011/11/16に行い、オプトアウトの完了を2012/1/8に確認しました。位置情報データのアップデートは月に1回ほどのようです。

SSIDの末尾に_nomapを付ける変更後、電波出力を100%にして、より多くのAndroid端末に捕捉されるようにしてみました。オプトアウト完了後はGoogle Mapを使っても頻繁に現在地が自宅に戻る不愉快な動作もなく快適に利用できています。そもそも、移動ノードはすべて出荷時デフォルトで_nomapで良いと思います。

Google側の更新を待てないお急ぎの方は、アクセスポイントをSSIDステルス設定にして使うと、Wi-Fi位置情報クライアントがそれを認識し、近隣のアクセスポイントとして送信されなくなり、_nomapによるオプトアウト完了後相当の測位結果になるのでお試しください。

リンク
Google Map ヘルプ - 位置情報サービス
高木浩光＠自宅の日記 - Wi-FiのMACアドレスはもはや住所と考えるしかない

メモリ増設後のテストはMemtest86+では不十分

先日メモリを増設したら、Memtest86+は一晩中回してもパスするものの、実用するとランダムなプロセス(主な用途はネットを見ることだからか、Chromeのプロセスがよく落ちた)が落ち、30分ほどでブルースクリーン PAGE_FAULT_IN_NONPAGED_AREA, IRQL_­NOT_­LESS_­OR_­EQUAL などが出る困ったマシンが出来てしまいました。

状況から推測するにメモリの欠陥の可能性が大なのですが、Memtest86+のテストにパスすることで大いに困惑しました。Memtest86+がよくテストしてくれるのは落ち着いたメモリアクセスでも発覚するメモリの物理構造上の欠陥であって、負荷がかかったときのアクセスタイミングの誤差のような微妙なところ?はカバーしないテストのようです。

結局のところオーバークロッカー御用達のメルセンヌ素数を素数判定することでメモリとCPU全コアにストレスをかける Prime95 を走らせたところ、1秒で不合格になるので、Transcend の不良受付係に新しいのと交換してもらい、正常動作しました。

リンク
Memtest86+
Prime95

Google Spreadsheets API の list-based-feeds でのカラム名正規化について

ドキュメントにはいまいち書かれていないようですが、1行を1レコードとして、それぞれの列の第1行のカラム名が付いた名前付きのレコードとして扱う list-based-feeds において、カラム名は以下のように正規化されます。hoge-foo-bar のようなハイフン区切りのカラム名もしくは camelCase にすると良さそうです。

foo123 -> foo123
123bar -> bar
foo_bar -> foobar
foo bar(間にスペース) -> foobar
foo-bar -> foo-bar (変化なし)
fooBar -> fooBar (変化なし)
foobar(2回目) -> foobar_2

参照
Google Spreadsheets API
- Developer's Guide (v3.0) - Working with list-based feeds
OAuth 2.0 Playground