水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2012年のえび日記 > 2012年3月

2012年3月

2012年3月30日(金曜日)

大東京トイボックス 8

公開: 2012年4月1日16時50分頃

8巻が出ていました。

今回も引き続き熱い展開で面白かったです。児童ポルノ法、著作権侵害の非親告罪化……といった社会的な問題もちらほら出つつ、やはり現場は熱い。ラスト付近、主人公(?)のモモが「あほらし」と言ってぶち切れてからの展開も良かったです。

ソリダスワークス側にもいろいろ動きがあり、ソーシャルゲームの課金で売り上げを伸ばしたモバイル部門が大きな動きを見せたり、かつてのコンシューマ部門設立の経緯が語られたりと、これまた肘用に面白い展開。

全体的につまらないところが見当たらない勢いで、ぶっちゃけ神回ではないでしょうか。

関連する話題: マンガ / 買い物 / 東京トイボックス

2012年3月29日(木曜日)

咲 -saki- 9

公開: 2012年4月1日13時5分頃

出ていたので。

麻雀はわりと普通でしたが、エピソードで楽しませる回という感じでしょうか。あの部長がまさかのプレッシャー負けとか。

関連する話題: マンガ / 買い物 / 咲

2012年3月28日(水曜日)

Aチャンネル 3

公開: 2012年4月1日2時45分頃

出ていたので購入。

特にこれといったイベントもないのですが、ユー子の妹が出ていますね。

入学当初のエピソードがあって、それが割と面白かったです。

関連する話題: マンガ / 買い物 / Aチャンネル

2012年3月27日(火曜日)

ゆゆ式4

公開: 2012年3月31日20時5分頃

出ていたので購入。

相変わらずのまったり感。今回はちょっと印象に残ったネタが少なかったかも。パン人間とか。

帯では海イベントがプッシュされていますが、イベントという感じでもないような……。

関連する話題: マンガ / 買い物 / ゆゆ式

OWASP Japan 1st Chapter Meeting

公開: 2012年3月30日2時10分頃

「OWASP Japan 1st Chapter Meeting (www.owasp.org)」というイベントがあったので参加してみました。

以下、ざっくりしたメモを箇条書きに。

OWASP / OWASP Japanについて

最初はOWASPとOWASP Japanの紹介。

OWASPは "The Open Web Application Security Project" ですが、最近はモバイルのセキュリティも扱っているというような話も。

5分でわかるCSP

ここからプレゼンテーション。各自持ち時間10分なのでライトニングトークに近いです。

一発目は、はせがわようすけさんの「5分でわかるCSP」。プレゼン資料が以下で公開されています。

資料を見た方が良いと思いますが、以下私のメモ。

5分でわかるCSP
  • CSP = Content Security Policy
  • Firefox4以降、Chrome18以降で実装
  • 指定された以外のリソースが読めなくなったり、インラインのスクリプトが禁止されたりする
  • evalやイベント属性を禁止することもできる
  • HTTP応答ヘッダで Content-Security-Policy: default-src 'self' のように指定する (これはFirefoxの場合。仕様は揺れている) と、同一ドメイン、同一ポートのリソースのみ読めるようになる。
  • meta要素での指定もいちおう可能だが、推奨されない。meta要素が読み込まれるまで指定が有効にならないので、metaの前に何かをインジェクションされると突破されてしまう。
  • ほかの指定の例
    • default-src 'self'; img-src *.example.com
    • script-src: 'unsafe-inline'
  • ポリシー違反があった時にレポートを送信するような指定もできる。 report-uri http://example.com/cspreport.cgi のように指定
  • 動作は禁止せずにレポートのみ送信する指定もある
5分で破るCSP
  • XSSがあるのにCSPのおかげでPoCが動かないというのは悔しい
  • CSPで最も厳しい指定をしても、自身と同一のオリジン (スキーム、ドメイン、ポートが同じ) であれば読める
  • ということは、自身は読める
  • src属性で自身を指定するようなscript要素をインジェクションすると、自身のHTMLをスクリプトとして解釈して実行しようとする
  • HTMLをJavaScriptとして実行しようとしても普通は文法エラーになるだけだが、E4Xを解釈するブラウザ (Firefox) の場合、HTMLをJavaScriptとして妥当なものにすることができる
  • XMLリテラルを二つ持ち、間にスクリプトが書いてあるような構造にする
  • ただしXML宣言や文書型宣言はE4Xとして解釈できないので、これらがあるとうまく行かない。文書型宣言をきちんと書いておくとこの攻撃を防げる
脆弱なWebサーバを作ってみた(仮)

続いて竹迫さんのお話。

  • サイボウズ社では「サイボウズ・ユニバーシティ」という活動があり、社内の勉強会を一元管理しようとしている
  • サイボウズ・ユニバーシティの企画として、セキュリティホール発見大会を実施
  • Badstore.net (www.badstore.net)という脆弱なWebアプリケーションのサンプルがあり、ISOイメージが配布されている。
  • SQLインジェクションやCSRFなど、ひととおりの脆弱性が実装されている
  • パスワードはMD5で保存されているが、MD5値をGoogleで検索すると答えが分かる場合がある。また、md5crack.com (md5crack.com)で解読可能
  • robots.txtからの情報漏洩もあり。検索エンジンよけディレクトリに機密データが置いてある
  • 課題を出して一通りの攻撃をしてもらったが、そのアクセスログを見ると非常に面白い
  • Badstore.com以外にも、IPAのAppGoat、Web Security Dojo、OWASP Web Goat Projectなどがある
ここが変だよ、グローバルスタンダードの脆弱性対策 ～入力値の考え方～

そして徳丸さん。

以下、私のメモ。

OWASP TOP 10の黒歴史
  • OWASPといえば「OWASP TOP 10」 → また上野宣か
  • PCIDSSでもOWASPのガイドラインを参照している
  • OWASP TOP 10 2004のトップに出てくるのが「入力データの未検証」
  • CWEでは「CWE-20 不適切な入力確認」として分類されているが、階層を見ると下層にインジェクション系の脆弱性、書式文字列の脆弱性などが大量にあり、範囲がやたら広い
  • そもそも入力値検証で良いのか、「バリデーション至上主義」ではないか
バリデーション至上主義の例
  • 書籍「Ajaxセキュリティ (www.amazon.co.jp)」の例
  • プリペアードステートメントよりもバリデーションを推奨している
  • ホワイトリストを作り、改良を続けることを薦めているが……。
  • そもそもホワイトリストなど作れるのか? メールアドレス「'or'1'='1'--@tokumaru.org」はRFC5322に適合する妥当なメールアドレス
  • アポストロフィをどうするのかについては著者も困ったようで、「アポストロフィの数を制限する」という方法を挙げている。しかし、アポストロフィは1つでも攻撃には十分
海外ではバリデーション重視?
  • アメリカや海外ではバリデーションが重要視されているらしい?
  • 確かにいくつかの脆弱性に効き目があるが、効き目のないものもあり、根本的な解決ではない
  • バリデーションに頼りきると、「セカンドオーダーSQLインジェクション」などという本質的でないものも出てくる → また上野宣か
  • しかし OWASP TOP10 2007や2010 からは、validationはなくなっている。CWE-20にも根本的でないという注釈があり、これを書いた人とはうまい酒が飲めそう
まとめ
  • バリデーションは普通にやりましょう
  • 「バリデーション」の「万能性」に惑わされずに、きちんと対策をすることが重要
バイナリパッチによるAndroidアプリの改竄とセキュリティチェックのバイパス

Webアプリの話ではないのですが、と前置きしつつの加藤さんのお話。

  • 会場から5分のとこに会社がある
  • OWASPにもモバイルのプロジェクトがある
  • バイナリエディタとdexdump (AndroidのSDKに入っているツール) でバイナリの解析が可能
  • AndroidアプリのAndroid.apkファイルはZIPファイルになっていて、中のclasses.dexというバイナリファイルが本体
  • ちなみにAndroidマーケットのアプリのリバースエンジニアリングは規約で禁止されている。今回は自作のAndroidアプリを解析する
  • 何かをチェックしてアプリが起動しないようにする、というルーチンを迂回する例を紹介
  • dexdumpで解析。onCreateがエントリポイントになるので、そこから辿ってチェックしているルーチンを探す
  • 戻り値のfalseをtrueに書き換える。場合によってはルーチンを全部NOPで埋めてしまうというテクニックもある
  • バイナリエディタでclasses.dexを書き換える
  • そのままではチェックサムのエラーが出るので、CRCを再計算して書き直す。先頭の0x08から4バイトがチェックサムになっている (リトルエンディアン)
  • Webでは非常識なことが、Androidアプリでは行われてしまっている事が多い (クライアントサイドのみのチェックなど) ので、Webアプリのセキュリティの知識は役に立つ

※ちなみに、「Web専門の方はリトルエンディアンという言葉に触れる機会もないと思いますが……」というようなお話がありましたが、そうでもないと思います。UTF-16を扱おうとすると避けて通れませんし、BOMというものもありますし。

ブロークンロジック: テストサイトの誤謬

Isaac Dawsonさんのお話。スライドは以下にあります。

以下メモ。話が力強く英語だったので、正直あんまり分かっていない部分があります。

  • テストサイト = Webアプリスキャナーのテストのためのサイト。スキャナーの実力をテストすることができる
  • 問題点がいくつかある
  • クローズドソース: ソースがオープンでないため検証ができない
  • 不完全な技術: ASP + MS Access か PHP + MySQLがほとんど。ほかの言語やDBがない。
  • 非現実的なフォーム検証: フォームの入力欄を全て埋めないとSQLインジェクションが発動しないなど
  • ブロークンサイト: 普通にダウンしていたり、動作が変だったり。なぜかContent-Length: 0が返る、Set-CookieのExpiresがおかしい、など。
  • 非現実的または偽の欠陥: ひどい、まぎらわしい
    • ディレクトリ・トラバーサルの検査に対して D:\boot.ini へのアクセスを許すが、そこはシステムディレクトリではなく、システムファイルでもない。さらに、Vista以降にはboot.iniは存在しない (この脆弱性は現実的ではない)
    • システムエラーが出ているように見えるが実は静的ページ
    • root / test でログインすると何故か /etc/passwd のようなファイルが見える。意味不明
  • テストサイトがきちんと正しく動作していないと、そこでテストした結果も信頼できなくなる。このようなテストサイトで検証したスキャナーの実力も信頼できない
Rakuten-CERT ぼくらのすすむみち

楽天の軍司さんのお話。さすが楽天、資料が英語だらけでした……。

  • 楽天の利用者は1100万 / 四半期
  • 毎日88億円の取引、うち楽天市場が39億円
  • 社員数7000人、12カ国に拠点を持つ
  • English-nizationに本気で取り組んでいる。苦労している人もいるようだ
  • 開発者は約1600名
  • セキュリティの組織は外・内に分かれる
  • 楽天の各サービスのセキュリティを見る
  • ボス + ペンテスタ4名 + SOC3名 + Appscanオペレータ4名 + アシスタント3名
  • 開発プロセスは Requirement → Design Dev. → QA → Audit。"Audit" の部分は珍しいかもしれない
  • Audit のプロセスでは、Appscanによるチェックと Manual Audit の両方を実施
  • Manual Auditは原則Blackbox、Grayboxについても取組中
  • 外注以外に社内でもペンテスト実施。外・内6:4くらい。社内ペンテスタは4名 (2名は外国人)
  • 年間約250件のAuditを実施、脆弱性の発見数は公表できないが結構ある
  • 1位: XSS(6～7割)、2位: エラーコード (意図しないエラー表示)、3位: CSRF
  • アジャイルとセキュリティの融合が今後の課題
Webアプリケーションセキュリティ要件定義書の提案

「また上野宣か」でおなじみの上野さんのお話。

  • 設計以前のプロセスが最も重要。最初の不備は後のすべてに影響する。早い段階で対応する方がコストが少ない
  • 対応のコスト比は、要求仕様・設計 : 実装 : テスト : 運用開始後 = 1 : 6.5 : 15 : 60
  • 問題の発生率は、要件20%、設計38%、実装37%、配備4%、運用1%
  • 問題は、発注側が要件定義をどう書いて良いか分からないこと。「SQLインジェクションがないこと」「セキュリティに配慮して作ること」のような記述も多い
  • 要件定義の目的は、安全なものを開発することと、責任分界点を明確にすること。「●●がないこと」のような規定では責任分界点も不明瞭。
  • 攻撃の大半は対策が明確になっている。マニアックな攻撃はきわめて希なうえ、「この攻撃ははせがわさんだ」とすぐに分かる。
  • つまり、要件は明確になっている
  • Webアプリケーションセキュリティ要件定義書をクリエイティブ・コモンズのライセンスで配布しているので、活用してもらえると嬉しい
お楽しみコーナー

一通り終了後、お楽しみコーナーということでジャンパーとOWASPバッグのプレゼント。

それぞれじゃんけんで勝った人に与えられる形になりました。ジャンパーはサイズがMということでMサイズの人のみが参加するというルール。バッグの方は全員参加だったのですが、何故か勝ち続けてしまい、まさかの優勝……! 私がバッグを獲得することになりました。ありがとうございます。

関連する話題: セキュリティ

2012年3月25日(日曜日)

新・光神話パルテナの鏡 クリア

公開: 2012年3月28日13時35分頃

新・光神話パルテナの鏡 (www.amazon.co.jp)、いちおうストーリーを最後まで終わらせました。

10章くらいで終わりかと思っていたら25章まであって、けっこうなボリュームでした。さらに高ホンキ度でやり直したり、未探索部分を探索したりする必要があるので、まだまだ終わりませんが。

以下、攻略のポイントと思われるもの。

難易度を上げると儲かる代わりにテクニックが要求されるといううまいバランスになっているので、繰り返しプレイのしがいがありますね。

関連する話題: ゲーム / 任天堂 / ニンテンドー3DS

2012年3月23日(金曜日)

私のおウチはHON屋さん5

公開: 2011年10月26日1時20分頃

出ていたので購入。

みゆは相変わらずのプロフェッショナル書店員ぶりですが、怪盗とか謎の幼女発明家とか出てきて方向性が分からなくなってきたなぁ……と思ったところで、まさかのみゆ母登場、そして思わせぶりな台詞。

続きが気になる感じです。

関連する話題: マンガ / 買い物 / 私のおウチはHON屋さん

2012年3月22日(木曜日)

新・光神話パルテナの鏡

公開: 2012年3月24日13時15分頃

届きましたよ。

メニューがいきなりスマブラ (www.amazon.co.jp)風ですね。まあ作ってる人が同じなので当然ですが。

スマブラと違うのは、スマブラがメニューで「このゲームはみんなで遊ぶものです!」と力強く主張しているのに対して、パルテナは一人用も対戦も同じ重みになっていること。

以下、感想などを少し。

神器ですが、ピット君は弓だろうということでとりあえず神弓を使ってみています。弾の誘導性が高いので、へたっぴでも割と使いやすい感じ。

対戦も少しだけやってみましたが、まあ下手なので申し訳ないとしか……。

関連する話題: ゲーム / 任天堂 / ニンテンドー3DS

2012年3月21日(水曜日)

スキップリンクにまつわる議論まとめ

公開: 2012年3月22日22時0分頃

「スキップリンクの議論: 前提まとめ」の続きです。

まず、前提をおさらいしておきます。

この前提をふまえた上で、スキップリンクにまつわるいくつかの議論をまとめていきたいと思います。

スキップリンク実装の現状

2.4.1は達成等級Aです。これは最低限の等級で、すなわちあらゆるサイトに求められる必須の要件ということになります。

また前提で述べたように、スキップリンクは見えている、もしくはフォーカス移動すると見えるようになる必要があります。ほとんどのサイトが、そのようなスキップリンクを備えなければならないということになります。

もっとも、サイトによってはナビゲーションがない、ナビゲーションがメインコンテンツより後ろにあるのでスキップが不要、というような場合もあるでしょう。しかし、大規模サイトの多くはそのような条件を満たしません。

ブロックスキップは元々WCAG1.0にはなく、WCAG2.0で追加された項目です。リハビリテーション法508条にはありましたが、ビジュアルブラウザで可視であることまでは求められていませんでした。

ですから、古くからアクセシビリティを意識して作られていたサイトであっても、要件を満たすようなスキップリンクを設けていないケースが多いです。そして、追加で設けるのもそれほど簡単なことではありません。

そのような事情もあり、この実装は等級Aであるにもかかわらず、あまり普及していない状況だと思います。

スキップ機能はWebコンテンツ側で設けるべきか

スキップリンクをWebコンテンツ側で設けるべきなのかどうか、という議論があります。

スキップリンクはキーボード、スイッチ、音声認識などのユーザーに役立つとされています。逆に言えば、それ以外の利用者にはあまり意味のないものになります。

つまり、これは多くの人に役立つユニバーサルな機能ではなく、特定の利用者を意識した機能だということです。このようなものはサイト側に求めるべきではなく、必要に応じて支援技術などで補えるようになっていれば良いのではないか、という考え方があります。

そもそも、ブロックスキップ機能をブラウザ側が実装すれば、サイト側では何も実装する必要がないはずです。

UAAG2.0のワーキングドラフトを見ると、2.3.1に「重要な要素に直接アクセスできるように」という規定があります。

2.3.1 Direct Navigation to Important Elements: (former 2.7.4):

The user can navigate directly to important (structural and operable) elements in rendered content. (Level A)

Intent of Success Criterion 2.3.1 :

It is often difficult for some people to use a pointing device (the standard method of direct navigation) to move the viewport and focus to important elements. In this case some other form of direct navigation - such as numbers or key combinations assigned to important elements - should be available which can then be accessed via the keyboard or speech control technology.

以上、Implementing Guideline 2.3 - Provide direct navigation and activation より

まさにWCAG2.0の2.4.1と同じ理由ですね。実装の例として、以下のようなケースが挙げられています。

Examples of Success Criterion 2.3.1 :◦Mary cannot use the mouse or keyboard due to a repetitive strain injury, instead she uses voice control technology with uses a mouse-less browsing plug-in to her browser. The plug-in overlays each hyperlink with a number that can then be used to directly select it (e.g. by speaking the command "select link 12"). This prevents Mary from having to say the word 'tab' numerous times to get to her desired hyperlink.

以上、Implementing Guideline 2.3 - Provide direct navigation and activation より

音声認識のソフトウェアを使っているケースで、「select link 12」と言えば12番目のリンクを選択してくれる、という動作で、これによって「tab」と何度も言わなくて済むという想定です。

スクリーンリーダーなどの支援技術では、既にこのような機能が実装されている場合が多いです。そのため、スキップリンクがなくてもあまり問題になりません。

問題は、支援技術を使っておらず、素のブラウザでキーボード操作というケースをどう考えるかです。「支援技術なしでもブロックスキップできるように、ブラウザ側で機能を設けるべき」という考え方もあると思います。

Webブラウザはスキップ機能を設けるべきか

では、実際にそのような機能をWebブラウザは設けているのでしょうか。

残念ながら、2011年時点では、ほとんどのブラウザにはそのような機能はありません。

ちなみにOperaはひっそりと対応しています。「シングルキーショートカットを有効にする」を選択すると、「S」で次の見出し、「W」で前の見出しに飛べるようになります (参考: Opera ヘルプ: キーボードショートカット (help.opera.com))。

Opera以外のブラウザがデフォルトでこの機能を持たないのは、そういうニーズがないから、というところが大きいようです。少なくともIEに関しては実装の予定がなく、このような機能が欲しいというニーズが出ていないし、もっとほかの機能に対するニーズがあって、そちらが優先されているという話を聞いています。

つまり、ブラウザがこの機能を設けていく可能性は高くありません。そして、そんな機能はそもそも必要とされていないのではないか、という疑問も出てきます。

ブロックスキップの達成等級は妥当なのか

前提では、視覚系ブラウザでもブロックスキップできないと困る利用者がいる、ということになっていしました。そしてブロックスキップは達成等級A。これは最低限の基準です。

しかしながら、現状ではブロックスキップが実装されていないサイトも多いですし、ブラウザ側でもあまり実装されていません。にもかかわらず、ブラウザに対してそのような機能を求める声はあまりないらしい、という状況であるようです。

とすると、実は利用者はそれほど困っていないのではないか、という疑問が出てきます。

大きなブロックをスキップする事ができると、キーを連打したり、音声による命令を連呼したりすることが避けられ、メインコンテンツに素早くアクセスできるとされています。しかし逆に言えば、素早いアクセスができないと言うだけで、アクセスが不可能になるわけではないはずです。

ほかの等級Aの項目は、達成しない場合、利用者によっては全くアクセスできなくなる可能性のあるものがほとんどです。それらと比較すると、この達成基準が等級Aとされているのは厳しすぎるのではないか、という印象もあります。

利用者は実際どう利用しているのか

ここまでの議論はおおむねスキップリンクに対して否定的ですが、それでも、実際にスキップリンクを便利に活用している人がいるのであれば、その人のために設けるというのも悪いことではないでしょう。邪魔にならないのであれば、つけても良いとは思います。

ただ、実際のところ利用者はスキップリンクをどう利用しているのか、という点はあまり調査が進んでいないところです。

以下のような論点があるでしょう。

  • スキップリンクは実際に役に立っているのか
  • 現状ではスキップリンクのないサイトも多いが、スキップリンクの利用が想定されるような利用者は、どのようにしてアクセスしているのか
  • メインコンテンツへ移動する機能だけで良いのか。ほかの場所に移動するリンクは必要ないのか
今後はどうなるのか

今後、すなわちHTML5が普及した場合の話です。

今までのHTMLでは、ナビゲーション部分をナビゲーションであると明示する一般的な方法はありませんでした。しかしHTML5にはおなじみのnav要素がありますし、WAI-ARIAにはnavigation (www.w3.org)やmain (www.w3.org)といったロールがあります。

WAI-ARIAはともかく、HTML5はかなり急速に普及が進んでいるように思えます。今後、こういったものが普及してくる可能性は高く、下手をすると、スキップリンクを実装したサイトよりもHTML5のnav要素を使ったサイトの方が多くなってくるかもしれません。

そうなれば、ブラウザの対応状況にも変化が出てくる可能性はあるでしょう。

以上、スキップリンクがらみの議論をざっくりとまとめてみました。

WCAG2.0 2.4.1の "Bypass Blocks" は、理論上は、可視のスキップリンクをつければ達成できる基準です。しかし、単につければ良いのか、と言われるとなかなか難しいところで、考えるべき事がかなりあります。

こういった議論があることも踏まえて、基準を少し見直した方が良いのではないか、とも思えます。

奥が深いですね。

関連する話題: Web / アクセシビリティ / スキップリンク

2012年3月20日(火曜日)

Google、かんたんログインを廃止

公開: 2012年3月21日22時40分頃

Googleが「かんたんログイン」を廃止したそうで。

というか、今まであったのですね。もとより、非公式サイトが実装する「かんたんログイン」にはセキュリティ上の懸念点が多く、あまりおすすめできない方式だったわけですが。

まあ、モバイルサイトはもうスマートフォンにシフトしつつありますし、いつまでもこんな事をしていても仕方ないというところでしょう。

関連する話題: Web / セキュリティ / モバイル

2012年3月19日(月曜日)

スキップリンクの議論: 前提まとめ

公開: 2012年3月21日22時20分頃

スキップリンクの話が盛り上がったので、情報を整理してみます。「キヤノンはなぜ達成等級「A」を満たせなかったのか」「スキップリンクにまつわるいくつかの議論」の続きです。

ブロックスキップの達成基準

まず前提の話から。WCAG2.0の2.4.1には "Bypass Blocks" という等級Aの基準があります。

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)

以上、WCAG2.0 2.4.1 より

JIS X 8341-3:2010 では以下のように訳されています。

7.2.4.1 ブロックスキップに関する達成基準

複数のウェブページ上で繰り返されているコンテンツのブロックをスキップできるメカニズムが利用可能でなければならない。

注記 この達成基準は，等級A の達成基準である。

以上、JIS X 8341-3:2010 7.2.4.1 より

これだけだと分かりにくいですが、以下でもう少し細かく解説されています。

スキップリンク

ブロックスキップを達成するための実装方法はいくつか提示されていますが、その筆頭に挙げられているのが以下のテクニックです。

「本文へ」などのリンクを設けて、メインコンテンツの開始位置までフォーカスを移動させられるようにするという手法です。

G123にもブロックスキップのリンクを設ける手法が挙げられています。

こちらは本文へ移動するのではなく、ナビゲーションの直前にリンクを設けてナビゲーションのすぐ後ろまで飛ぶようなタイプのものです。

さらにG124にも、G1と似たようなリンクの手法があります。

これは「本文へ」単独ではなくて、いくつかのブロックへのリンクを列挙するタイプのものですね。

これらをまとめて「スキップリンク」と呼んでいます。ただし、G123やG124のパターンは、G1と比べるとマイナーで、使われるケースはことが少なめです。断りなしに「スキップリンク」と言った場合、特にG1をイメージしている場合が多いです。

スキップリンクの目的と要件

スキップリンクの目的は、キーボードの利用者がナビゲーション部分を飛ばして、すぐにメインコンテンツにアクセスできるようにすることです。

スクリーンリーダー専用の機能ではない、という点に注意が必要です。G1の説明には以下のような注記があります。

Note: It is preferable for links to be visible at all times, since users navigating via the keyboard include switch users, those using techniques that generate keyboard strokes slowly, screen magnification software users, screen reader users working with sighted colleagues, keyboard only users and those navigating using voice recognition software.

以上、G1: Adding a link at the top of each page that goes directly to the main content area より

ここでは、以下のようなケースがあるとしています。

  • キーボードやスイッチを利用し、ストロークを遅くしている
  • 画面拡大ソフトウェアを利用している
  • スクリーンリーダーの利用者が、目の見える人と一緒に作業している
  • キーボードだけで操作している
  • 音声認識ソフトでナビゲーションしている (音声の場合、キーと違って連打が大変)

こういった場合、スキップリンクが視覚的に見えるものになっていなければ利用することができません。

従来のサイトには、透明な画像をスキップリンクにしたり、何らかの方法でスキップリンクを視覚的に隠すといった処理をしているものがあります。そのようなケースはG1の実装の要件を満たしていないことになります。

なお、この注記には続きがあります。

However, does not require that they be visible when they do not have focus, and links that are visible only when they have focus can meet this success criterion.

以上、G1: Adding a link at the top of each page that goes directly to the main content area より

フォーカスを受け取っていないときは見えていなくても良い、ということになっています。つまり、最初は見えていないが、tabキーを押してフォーカスが移るとひょっこり現れる、という実装はOKです。

※この部分は後から追記された部分で、日本語訳には追記部分がありません。

スキップリンク以外の手法

2.4.1を満たすための手法はスキップリンクだけではありません。HTML文書において、2.4.1を満たす実装方法には以下のようなものがあります。

コンテンツの各セクションに見出しをつける

見出しをつけるという方法は非常に分かりやすいと思います。現在では、ほとんどのスクリーンリーダーが何らかの見出しジャンプ機能を持っていて、見出しの一覧を出したり、次の見出しに飛んだりすることができます。

逆に、ビジュアルブラウザは見出しジャンプ機能にほとんど対応していません。スクリーンリーダーの利用者は活用できますが、そうでない人は活用することが難しい実装方法です。

map要素を使ってリンクをグループ化する

ナビゲーション部分をグループ化するという話なのですが、まさかのmap要素……。今ならnav要素が例として挙げられるかもしれません。

以前はul要素も例として挙げられていたのですが、リストをスキップできないスクリーンリーダーが多いと判断したのか、今はmap要素だけの例になっているようです。もっとも、map要素をスキップできるスクリーンリーダーも少ないのですが。

いずれも、ビジュアルブラウザはほとんど対応していません。一部のスクリーンリーダーでしか活用できない実装方法です。

フレームを使ってブロックをスキップできるようにする

まさかのframe要素。

ブラウザによってはフレームを切り替えるキーボード操作ができない場合があったりしますし、フレームのtitle属性を読み上げられるスクリーンリーダーも少ないです。そもそも、ブロックをスキップできるようにするためにframeを使う人はほとんどいないでしょう。

スクリプトで開閉するメニューを作る

メニューが開閉できるようになっていれば、閉じてスキップできるという発想。

実際にスキップできるかどうかは実装方法によりますが、アクセシビリティ目的でこのような実装をするケースは少ないだろうと思います。

スキップリンク 前提のまとめ

ここまでに見てきたことをまとめると、以下のようになります。

  • WCAG2.0 2.4.1には"Bypass Blocks"という等級Aの基準がある
  • その実装方法の一つがスキップリンク
  • ビジュアルブラウザの利用者もスキップリンクを利用できるように、見えるようになっている必要がある
  • スキップリンク以外の実装方法もあるが、ビジュアルブラウザで利用できるものはほとんどない

以上のことから、WCAG2.0の等級Aを満たすためには、スキップリンクを設けることがほぼ必須となっています。

ここまでが議論の前提となる話です。

長くなったので続きます……。

関連する話題: Web / アクセシビリティ / スキップリンク

2012年3月16日(金曜日)

マイクロアド社のオプトアウト施策

公開: 2012年3月16日23時55分頃

はてなブックマークボタンのトラッキング停止を受けてか、マイクロアド社が施策を打ち出してきています。

※ユーザーがアクションを起こすための動線をどうするかという話のはずで、「導線」は誤変換ではないかとも思いますが、マイクロアドの用語としては「導線」で統一されているようです。

前者が今回の話の直接的な対策ですね。

今後マイクロアドでは、ブログパーツや外部ボタン等、マイクロアドと直接提携関係にあるパートナー以外の第三者にあたる媒体・配信面に付与される可能性のあるものについて、それらの表示領域にマイクロアドからの行動履歴情報の蓄積を無効化するオプトアウトページへの導線設置を義務化いたします。

以上、提携パートナー企業へのユーザー告知義務強化について より

「ブログパーツや外部ボタン等、マイクロアドと直接提携関係にあるパートナー以外の第三者にあたる媒体・配信面に付与される可能性のあるもの」というのが、はてなブックマークボタンにあたります。「それらの表示領域にマイクロアドからの行動履歴情報の蓄積を無効化するオプトアウトページへの導線設置を義務化」、ということをすると。

上記の記述を見る限りでは、何らかの動線があれば良い、たとえば単に「オプトアウト」というボタンを置くのでも良いように読めます。しかし、それではユーザーに理解されないのではないか、という問題があります。意味の分からないボタンを意味の分からないままに押せというのは無茶な話でしょうから、少なくとも「オプトアウト」とは何なのか、何をオプトアウトするのか、といったことが伝わるようになっている必要があるはずです。

そういったことが伝わって初めて、ユーザーは「オプトアウト」を押すべきなのか、無視しても良いのかを判断できるようになります。そこまでしなければ、本当の意味でオプトアウトの機会が与えられているとは言いにくいでしょう。

具体的には……うまい具合に、徳丸さんが実装例を提示されています。

まあ、こうなりますよね。ここまでやればまあ伝わるのではないか、という感じはします。

ただ、ボタンの表示位置によっては気づかない可能性があったり (ボタンが画面上に現れなくてもページがロードされた時点で情報収集されている)、プライバシーポリシーに明確に「行動収集していません」と書いてあったらそちらを信じてしまう可能性があったりと、問題はいくつかありそうです。

関連する話題: セキュリティ / プライバシー / はてな

2012年3月15日(木曜日)

魔法少女かずみ☆マギカ 3

公開: 2012年3月16日2時0分頃

出ていたので購入。

相変わらず絵が分かりにくいですが、かずみの記憶が戻った、と思わせつつなかなかの急展開。1～2巻よりも断然面白くなってきました。ラストがまた何ともあれで続きが気になる感じです。

関連する話題: マンガ / 買い物 / 魔法少女まどか☆マギカ

2012年3月14日(水曜日)

はてなブックマークボタン トラッキングを停止

公開: 2012年3月15日20時40分頃

はてなブックマークボタン設置サイトがトラッキングをしていた問題、はてなが見解を発表しました。

ひとまずトラッキングは停止されたようです。

本日、はてなブックマークボタンが取得した行動情報の第三者への送信を停止しました。

はてな側での送信は3月13日（火）16時00分に停止しました。ただし環境によっては、変更が反映されるまでに最大24時間かかることがあります。

以上、はてなブックマークボタンが取得した行動情報の第三者への送信を停止しました - はてなブックマーク日記 より

単純に元の仕様に戻したようですね。「最大24時間かかる」と言われているのは、単にキャッシュの話だと思います (bookmark_button.js のHTTP応答ヘッダにはExpires:フィールドが含まれていて、取得から24時間はキャッシュされるように設定されています)。

経緯というか反省の弁というか、はこのあたりでしょうか……。

ブックマークボタン本来の目的は、「ブックマーク数が分かる」ことと、「簡単にブックマークできる」ことです。このボタンの表示から得た訪問者の行動情報を第三者に提供することは、ボタン本来の目的から考えて間違った情報の使い方でした。

当初はこうした行動情報の提供を行わない仕組みで提供開始したボタンを、途中から仕様を変更した点や、仕様変更の際に、事前に十分な告知を行わなかった点も間違っていました。ウェブサイトの閲覧者が、はてなブックマークボタンが設置されたページを訪問した際に、行動情報を取得されないよう設定が簡単にできるオプトアウト機能を準備しなかった点も誤りでした。

以上、はてなブックマークボタンから収集した行動情報の第三者提供をやめます - はてなの日記 より

間違っていたと判断されるのは良いと思うのですが、なぜそのような間違った事をしてしまったのか、その背景を知りたいところです。もっと具体的かつ明確に言うと、以下のような点です。

とはいえ、政治的な都合もあるでしょうから、こんな話は表には出てこないかもしれませんが。

この発表を受けて、いくつかのニュースメディアが記事にしています。興味深いのはCNET Japanの記事です。

ただし、一部のウェブメディア等のドメインについては、行動情報の取得を除外している。これについては、ボタンの設置を依頼するやりとりの中で、行動情報の取得除外を希望したサイト運営者に対して、除外設定をしていると説明している。リストにはCNET Japanも含まれるが、2011年8月下旬にはてなからその旨の連絡が届いている。

（追記：CNET Japanと姉妹紙のZDNet Japan、builderは行動情報取得に関して拒否の回答をしている）

以上、CNET Japanの「はてなブックマークボタン」、マイクロアドへの行動履歴の送信を停止 より

トラッキングが始まる前、8月下旬に事前連絡を受けていることを認めています。そして拒否の回答をし、その結果として除外設定をしてもらっていたというわけですね。

そして、対照的なのがINTRENET Watch……。

INTERNET WatchをはじめとするImpress Watchの各媒体でも、以前よりはてなブックマークボタンを各ページに表示している。Impress Watchのプライバシーポリシーのページでは、広告などの目的でCookieやウェブビーコンを使用している第三者企業を挙げているが、今回のはてなブックマークボタンについては、設置時にはトラッキングCookieは利用されておらず、その後にトラッキングCookieが導入されていたことを把握できていなかったため、プライバシーポリシーにも掲載していなかった。Impress Watchでは、事態を把握した3月11日から、はてなブックマークボタンを情報行動の取得を行わないボタンに差し替えていたが、今後はこうした第三者のスクリプトなどの利用に関してより対応を強化していく。

以上、INTERNET Watchのはてな、ブックマークボタンで周知せず行動情報取得を行なっていたことを謝罪 より

「把握できていなかった」ため、プライバシーポリシーの記載に反する状態になっていた事を認めています。Impressは事前連絡してもらえなかったみたいですね。何が明暗を分けたのか、ちょっと興味があります。

関連する話題: セキュリティ / プライバシー / はてな

2012年3月13日(火曜日)

Azure閏年問題の詳細

公開: 2012年3月15日14時0分頃

Windows Azureが閏年バグでダウンした問題、日本語の詳細情報が出ましたね……「2012 年 2 月 29 日に発生した Windows Azure 中断について、Windows Azure ブログにて公開された要約 -- Windows Azure Platform (www.microsoft.com)」

何が起きて何をしたのか、時系列順に詳しく説明されていて良いですね。おおざっぱにまとめると、最初の原因となった部分はこんな感じでしょうか。

証明書の有効期限のチェックが問題だったのではなくて、新規作成ができなかったということですね。

今後の改善点などもまとめられていて興味深いです。個人的に興味深いのはこの部分。

他の伝達経路 – かなりの数のお客様が、問題発生時にお客様に伝達するために、ブログ、Facebook ページ、Twitter アカウントをより良く使うことを求めています。また、問題発生後に、より迅速に電子メールを介した公式の情報伝達を提供することも求めています。我々は、情報伝達を全体的に改善し、これらの経路を介してより積極的に情報を提供する措置を講じてまいります。また、特定のサービスに関する問題を診断するために、お客様とサポートにより粒度の細かいツールを提供する措置も講じてまいります。

正直なところ、障害が発生しているのにクラウディアさん (twitter.com)が年齢の話しかしていないのはどうかと思いました……。いや、クラウディアさんの担当ではないのかもしれませんが。

関連する話題: セキュリティ / プログラミング / 出来事

2012年3月12日(月曜日)

はてなブックマークボタン設置サイトがトラッキングをしていた問題

公開: 2012年3月15日2時15分頃

2011年9月からとのことですが、正直申しまして、全く気づいておりませんでした……。

これは非常にまずいです。

2011年9月から、「はてなブックマークボタン」のJavaScriptに、MicroAd社の広告に利用するための行動トラッキングのコードが追加されました。これにより、はてなブックマークボタンを設置していたサイトでは、トラッキングが行われるようになりました。

これは、「はてなのサイトがトラッキングを始めた」という話ではありません。はてなのサイトではなく、はてなブックマークボタンを設置していたサイトでトラッキングが行われるようになったのです。

2011年9月以前にはてなブックマークボタンを設置したケースでは、広告のための行動トラッキングが行われるとは想定していなかったはずです。トラッキングはサイト側の意図に反するもののはずで、要するに、意図に反する動作のスクリプトが埋め込まれたのと同じ状態です。はてなのやったことは、他社のサイトに悪意あるスクリプトを埋め込んだに等しいと言ってしまっても過言ではないと思います。

特に困るのは、しっかりとプライバシーポリシーを掲げているサイトです。特に企業サイトの場合、Cookieの利用目的をはっきり限定しているケースが多く、たいていは広告目的のトラッキングはしないことになっています。

はてなブックマークボタンの説明によると以下のようにあり、明らかにCookieを使っています。

この行動情報は株式会社マイクロアドのプラットフォームを利用し、Cookie を用いて取得されます。

以上、はてなブックマーク > ヘルプ > はてなブックマークボタンを表示する より

企業サイトでも、はてなブックマークボタンを利用している場合はあるでしょう。特に、ブログなどでは利用しているケースがそれなりにあるはずです。ブログのプライバシーポリシーも企業サイト本体に準じる扱いになっていることが多く、そうなるとやはり広告目的のトラッキングはできません。

このようなサイトでは、2011年9月から、サイトポリシーに違反する行為を行っていたことになります。即刻ボタンを外すのはもちろんですが、それだけではなく、お詫びと経緯説明のプレスリリースを出すかどうか検討しなければならないレベルです。

そして実にひどいと思うのが、除外サイトがあったという話。問題のJavaScriptには、大手ニュースサイトを中心にいくつかのドメインが書かれていて、それらのドメインではトラッキングが機能しないように設定していたというのです。

つまり、特定の企業には事前にきちんとトラッキングの話をしているわけですね。そこで「うちのサイトではトラッキングされると困るし、ボタンの差し替え作業もしたくないので、はてな側でトラッキングしないように設定してくれ」というような要望が出て、それを飲んだのでしょう。「トラッキングされると困る」という人がいるということは、最初から十分に分かっていたはずです。

ここで、2つの疑問が出てきます。

はてなはこの疑問に答えられるのでしょうか。

この疑問に対しては、シンプルな回答がすぐに思いつきます。それは、「そんなことをしたら誰もトラッキングあり版を使わないから」というものです。

はてなブックマークボタン設置サイトの立場で考えると、トラッキングあり版を採用するメリットは何一つありません。告知した場合、大半の人がトラッキングなし版に切り替える可能性があり、そうなるとトラッキングをするメリットが大幅に低下します。

つまり、情報が正しく伝わると利用してもらえないから、サイト管理者を欺く形での設置に踏み切ったのではないか……と、そういう風に考えられるわけです。現状は、そう疑われても仕方ない状況にあると思います。

そうでないと言うなら (そうでないと言ってほしいですが)、はてなは先の疑問に対して、「なぜそういう選択をしたのか」というところまで明確にして答える必要があるでしょう。

※しかし、外部JS埋め込みで提供者が態度を翻す、というリスクが徳丸本 (www.amazon.co.jp)で既に言及されていたというのは面白いですね。隙がなさ過ぎます。

関連する話題: セキュリティ / プライバシー / はてな

2012年3月11日(日曜日)

ニンテンドー・イン・アメリカ

公開: 2012年3月14日21時45分頃

読み終わったので。

アメリカから見た任天堂とマリオの歴史、という感じの話。ちなみに原題は "Super Mario: How Nintendo Conquered America (www.amazon.co.jp)" です。

アメリカ視点なので、日本から見るのとはちょっと視点が違う部分もあったりします。スーパーマリオ2は「ザ・ロスト・レベルズ」なんですね……。

関連する話題: 本 / 任天堂

2012年3月10日(土曜日)

「ログイン攻撃」成功率4%

公開: 2012年3月14日19時10分頃

こんな話が……「不正ログイン、４％が侵入　警察庁調査、実態把握へ (www.asahi.com)」。

大量のＩＤとパスワード（ＰＷ）の組み合わせを次々に自動入力してシステムへの侵入を試みる「ログイン攻撃」の実態を、警察庁が調べたところ、１００回に４回もの頻度で侵入されていたことがわかった。

(～中略～)

調査は昨年、ゲームやショッピングなどのサイト運営企業１４社に実施した。うち８社が、１カ月間に約２６５万回の攻撃を受け、約１０万回不正侵入されていた。

「ログイン攻撃」が何を指すのかよく分かりませんが、単なるブルートフォースで4%の突破率は高すぎます。「IDとパスワードの組み合わせ」と言われていますが、これはどこかのサイトで使われていた (そして何らかの理由で漏洩した) 実在するIDとパスワードの組み合わせを指しているのではないかと思います。

つまり、どこかのサイトで使われていたIDとパスワードの組が大量に出回っていて、それを他のサイトで試すと4%は通ると。他サイトに同じパスワードを使い回しているユーザーがそれだけいる、ということなのでしょう。

関連する話題: セキュリティ

ワールドエンブリオ 9

公開: 2012年3月14日17時20分頃

出ていたので購入。

前巻が新展開と思いきや、まさかのさらなる新展開ですか。ラストは……これ、ひょっとしてネーネと対決する展開なのでしょうか?

次が気になりますよ。

関連する話題: マンガ / 買い物 / ワールドエンブリオ

賭博堕天録カイジ 和也編 8

公開: 2012年3月14日15時55分頃

出ていたので購入。

まだ友情確認ゲーム終わらず。次で終わりですかね。さっさと終わらせてほしいです。

関連する話題: マンガ / 買い物 / カイジ

2012年3月9日(金曜日)

燃料プールの「幸運」の正体は偶然の重なりだった

公開: 2012年3月14日3時35分頃

この記事には驚きました……「４号機、工事ミスに救われた　震災時の福島第一原発 (digital.asahi.com)」。

東京電力福島第一原発の事故で日米両政府が最悪の事態の引き金になると心配した４号機の使用済み核燃料の過熱・崩壊は、震災直前の工事の不手際と、意図しない仕切り壁のずれという二つの偶然もあって救われていたことが分かった。

以上、４号機、工事ミスに救われた　震災時の福島第一原発 より

なんということでしょう。

4号機の使用済み燃料プールが「最悪の事態の引き金」として懸念されていた、という話は「官邸から見た原発事故の真実 (www.amazon.co.jp)」にも出ています。

では、この冷却機能の長期喪失という最悪の状態が起こった場合、福島原発で「最も危険」であったものは何か。

実は、それは「原子炉」ではなかったのです。

意外に思われるかもしれませんが、それは、「使用済み燃料プール」だったのです。具体的には福島原発四号機の使用済み燃料プールが、最も危険な状態に陥る可能性があったのです。

以上、「官邸から見た原発事故の真実」p123 より

続く話を要約すると、こんな感じです。

そして、以下のような点が懸念されていました。

この懸念が現実のものになった場合、大量の放射性物質が拡散し、首都圏三千万人が避難を余儀なくされていた可能性があった……というのが、官邸が描いた「最悪のシナリオ」の内容です。これが起きなかった理由について、著者は「幸運」に恵まれた、と述べています。

そして、その「幸運」をもたらしたのは偶然の重なりだった、というのが今回の話です。

この水がなければ3月下旬に水がなくなる計算だったそうで。注水が開始できたのが3月20日ということなので、この水がなければ注水が間に合わなかった可能性があったわけですね。

こんな偶然の重なりに救われていたとは、なんたる幸運。

関連する話題: 原子力

2012年3月8日(木曜日)

俗に言うDNSの「浸透問題」の話

公開: 2012年3月13日22時50分頃

古い話ですがメモ: 「DNSの「浸透問題」は都市伝説――正しいサーバー引っ越し法を解説 (internet.watch.impress.co.jp)」。

俗に言う「浸透問題」の話。実際にはDNSの情報は「浸透」するわけではないので、古いキャッシュがなかなか無効にならずに使われ続けてしまうという話なのですが。

問題が起きるのはこういうケースです。

DNSキャッシュサーバが古いNSレコードをキャッシュしている場合、切り替え後にも古いDNSサーバに向けて問い合わせを行います。このとき返される情報は古いものです。しかも正常な権威サーバからの応答とみなされるので、古い情報でキャッシュが更新されてしまう場合があります。

注意点は主に以下の2点ですかね。

関連する話題: DNS

2012年3月7日(水曜日)

非実在献立

公開: 2012年2月13日22時5分頃

「米をおかずにパンを食べる給食は存在しませんでした。 (d.hatena.ne.jp)」

週刊誌の記事で「変な給食」として紹介された例に疑問を抱き、実際に取材してみたところ、実は単なる献立表の誤植だったと判明した話。

取材すれば分かるはずなので、取材していないと考えられるわけで……。

幕内秀夫氏がネット上の献立を見ながら記事を書いているとしたら、NEWSポストセブンの連載に登場する献立や変な給食や もっと変な給食に掲載された献立の中に「誤植が原因で生じた非実在献立」が他にも混じっている恐れが出てきました。

これを全部検証するのは時間的に無理があります。

どうしたものか……

まあ何というか、世にはこういうクオリティの低い話というのが結構ある、ということを踏まえて読むしかない感じがしますね。

そういえば、昔読んだ「へんなほうりつ (www.amazon.co.jp)」という本も、恣意的な引用があったり、ネットからのコピペで済ませていそうな部分があったりと、かなり厳しい本でしたが……。

※にもかかわらずAmazonの評価が結構高いのが何とも。

関連する話題: 思ったこと

2012年3月6日(火曜日)

SVGのテキストとMedia Queries

公開: 2012年2月13日16時10分頃

最近、SVGを使うことが多くなってきたのですが、テキストの処理がHTMLとは少し異なり、やや癖があります。そのあたりを少しメモしておきます。

テキストの改行

HTMLの場合は、要素内に適当にテキストを書くと、その要素の中にテキストが表示されます。要素の幅に対して長いテキストが入った場合は、テキストは自動的に改行されます。

SVG1.1の場合、テキストを置くにはtext要素を使い、text要素自体にx属性、y属性で座標を指定して配置します。この要素には幅という概念がなく、テキストが自動で折り返されることはありません。SVG1.1では「自動改行はない」という旨がはっきり書いてあります。

SVG performs no automatic line breaking or word wrapping. To achieve the effect of multiple lines of text, use one of the following methods:

以上、SVG1.1 10.1 Text Introduction より

改行するするための方法は3つ挙げられています。

  • text要素を複数使い、それぞれに良い感じの座標を指定する
  • text要素の中でtspan要素を複数使い、それぞれに良い感じの座標を指定する
  • SVG以外の手段に頼る (たとえばXHTMLを埋め込む)

text要素を複数使うと、それぞれのテキストは別々の塊とみなされます。たとえば、選択するときにひとかたまりに選択できなかったりする可能性があります。単なる折り返しの場合はtspan要素を使うのが良いでしょう。

といっても、tspanを使えば改行されるというわけではなく、個々のtspanに座標を指定する必要があるので面倒ですが。

参考: SVG Tiny 1.2の場合

……と、SVG1.1では実に面倒なのですが、SVG Tiny 1.2 (www.w3.org)にはtextArea要素 (www.w3.org)があり、テキストを流し込めば自動で折り返しできるようになっています。HTMLのbr要素に相当するtbreak要素 (www.w3.org)もあります。

以下にtextAreaのサンプル画像があります。

ここでテキストが表示されればtextArea要素が使えるということなのですが、IE9, Firefox10, Chrome17では表示されないようです。単に SVG Tiny 1.2 に対応していないのでしょう。

というわけで、SVG1.1のtspan要素で地道にやるしかなさそうです。

テキストのセンタリング

HTMLの場合、CSSのtext-alignプロパティを使えばすぐにセンタリングできます。

SVG1.1では、text-anchor (www.w3.org)を middle に設定します。ただしこの場合、指定した座標がテキストの中心になるように、座標から左右に向かってテキストが伸びる形になります。座標を変えずにtext-anchorをstartからmiddleに変えると、テキストの位置は左にずれます。

※左と書きましたが、これは書字方向がLTRの場合です。text-anchorにはleft, rightという指定はなく、start, endがあります。初期値はstartですが、これは書字方向がLTRなら座標の位置が左端に、RTLなら右端になるという指定です。left, rightという指定方法よりも格好いいと個人的には思います。

style要素を使って指定することもできます。画像内のすべてのテキストをセンタリングにする場合は、以下のように書いておくと楽です。

<style type="text/css">
text {
text-anchor: middle;
}
</style>

text-anchorは継承されますので、textに指定すると子要素のtspanにも指定が効きます。

テキストのサイズ

フォントまわりでは、HTMLと同じようにfont-sizeやfont-familyなどが使えます。ほとんどの場合、複数のテキストに同じサイズ、同じフォントを指定すると思いますので、style要素で指定するのが便利だと思います。

ブラウザによっては、SVG内のテキストにも最小フォントサイズの指定が有効なので注意が必要です。少なくともChromeでは、SVG画像を縮小しても、テキストのサイズは一定以下にならないようです。テキストの周囲の図や枠などはいくらでも小さくなりますので、テキストがはみ出したり、重なったりする可能性があります。

逆に、Chrome以外のブラウザではテキストが際限なく縮小されます。これはこれで、読めないほど小さくなってしまうおそれがあります。

Media Queries

SVG画像の中でstyle要素を使ってCSSを書くことができるのですが、このとき、Media Queries (www.w3.org)が使えます。少なくともIE9, Firefox10,Chrome17では有効でした。

SVGを使う場合、画像が拡大・縮小されることを想定しているケースが多いと思います。Media Queriesを使うと、縮小されたとき、あるいは拡大されたときにだけ異なるスタイルを適用することができるようになり、SVGの幅が広がります。

先に述べた「Chromeだけ最小フォントサイズがある」という問題についても、むしろ縮小時にフォントサイズを大きくするようなスタイルを指定することで、他のブラウザの挙動をChromeに近づけることができます。

Media Queriesは今のところフォントサイズにしか使っていませんが、うまく活用すればいろいろなことができそうで、可能性を感じています。

最大の問題は、Illustrator (www.amazon.co.jp)からの書き出しではそんな気の利いたことができないということです。このような機能を活用しようとすると、SVGのXMLをテキストエディタ等で編集する必要があります。それなりにSVGの知識を持っている人でないと編集できません。

SVGのオーサリングをどうするのか、というのは今後の課題になるかもしれません。

関連する話題: Web / HTML / SVG / CSS

2012年3月5日(月曜日)

Railsのupdate_attributesが強力な話

更新: 2012年3月12日22時15分頃

こんな話が……「github の mass assignment 脆弱性が突かれた件 (blog.sorah.jp)」。

update_attributes とは: ActiveRecord のモデルで、カラム名がキーとなった Hash を渡す事でデータを更新できるメソッド。foo.update_attributes(:title => "New Title") のように使います。 scaffold で生成されたコントローラの update アクションなどで使われていて、scaffold では update_attributes(params[:foo]) のようにパラメータが直接渡されています。

ここでのparamsは、クエリ文字列、あるいはPOSTされたクエリをそのまま格納したものです。scaffold (Railsが最初にひな形を自動生成する機能) では、外部から受け取ったクエリをそのまま渡すコードになっていて、書き換えずにそのまま使うとまずいことが起きるという話ですね。

で、実際にGitHubがやってしまっていたと。

ひとまずはプログラマが気をつければ良いという話ではあるのですが、scaffoldのままだと駄目というのはなんとも……。要注意ですね。

関連する話題: Web / セキュリティ / Ruby

2012年3月2日(金曜日)

PASMO履歴照会サービス停止

公開: 2012年3月12日16時50分頃

話題になっていたPASMO履歴照会サービスですが、停止したようですね。

ＰＡＳＭＯホームページにおきまして、ＰＡＳＭＯをお持ちのお客さまへのサービスとして、過去の残額履歴をお客さまに提供するためのサービス「マイページ・ＰＡＳＭＯ履歴照会サービス（以下、「マイページ」といいます。）」を提供してまいりしたが、システムリスク調査のため「マイページ」のご利用を一時停止いたしましたので、お知らせいたします。

実は最初に出たプレスリリースでは「システム環境調査」というふわっとした言葉が使われていたのですが、「システムリスク調査」と言い換えられています。

経緯の説明は以下のようになっていますね。

マイページの残額履歴の閲覧に際しては、「ＰＡＳＭＯカード番号」およびＰＡＳＭＯ購入時にご登録いただいている「氏名」「生年月日」「電話番号」を照会画面にご入力いただくことにより、ＰＡＤＭＯ記名人であることの本人確認を行っております。

当初、「ＰＡＳＭＯカード番号」は、第三者が容易に知り得るものではないという認識のもと、サービスを開始し運用してまいりました。

しかしながら、何らかの事情により、第三者が「ＰＡＳＭＯカード番号」、登録情報を知り得た場合、これまでの仕様履歴等の残額履歴が第三者に漏洩する可能性があることを考慮し、システムリスクについて改めて調査するため、サービスを一時停止することといたしました。

当初はカード番号を第三者が容易に知り得るものではないと認識していた、とのことですが、だったらどうして「マイページ停止センター」なるものが用意されていたのでしょうか。

高木さんは以下のようなやりとりをされているわけで……。

パ： お客様大変お待たせいたしました。マイページ停止センター、こちらを開設させて頂いたのは、パスモが利用開始となりました2007年3月18日となっております。

私： え？ つまり最初からあったということですか？

パ： はいさようでございます。

私： どうして最初っからこれがあるんですかね？ 最初からわかってたということですか？ さっきの説明だと、そういうふうな問い合わせがあって、勝手に閲覧されるのは困るから、それでこういうセンターを設けたとおっしゃってましたけども、

パ： はい、申し訳ございません。私の案内に誤りがありました。マイページ停止というのは、パスモの発足当時からサービスとしてございまして、ま、こちらのサービスをご提供させて頂くときに、第三者から見られる、ま、可能性として、ま、考えられましたので、マイページ停止というものも合わせて作らせて頂いたという状況でございます。

以上、ID番号が秘密なのか、それとも氏名・生年月日が秘密なのか より

第三者から見られる可能性があることは最初から承知していて、だからサービス開始当初から「マイページ停止センター」が存在していた、というふうにしか思えないわけです。

少なくとも、開始前から問題に気づいている人がいたことは間違いないと思うのですが、どうしてこうなってしまったのか。このあたりには根深い何かがあるのかもしれませんね。

関連する話題: セキュリティ / プライバシー / PASMO

2012年3月1日(木曜日)

meta refreshの解釈の差異によって発生する問題

更新: 2012年3月12日15時10分頃

このお話は興味深いですね……「Googleのmetaリダイレクトに存在した問題 (masatokinugawa.l0.cm)」。

meta refreshのcontent属性の中身を動的生成している場合、ここに外部から値を入れられるとき、リダイレクト先を変更できてしまう場合があるという話です。

Internet Explorer 6/7では、以下のようなmetaタグの指定で、http://evil/へリダイレクトします。

<meta http-equiv="refresh" content="0;url='http://good/'url='http://evil/'">

ちなみにHTML5では、ご丁寧にmeta refreshのcontent属性のパース方法が決められていて、「4.2.5.3 Pragma directives - Refresh state (www.w3.org)」に細かく書かれています。

url=の後ろの値の読み取り部分だけを見ると、以下のような感じになります。

20. の処理でquote文字列の後ろはすべて切り落とされることになっているので、問題のケースでは http://good/ がURLとみなされるのが正しいです。IE6/7の処理はHTML5の仕様とは異なっています。

とはいえ、そういう残念な処理をするブラウザが存在するというのは事実なので、注意が必要になるということですね。

以下も似たような話です。

こちらも、IE6/7の解釈がHTML5仕様と異なっているという問題です。HTML5の仕様上は、;url= は単にURLの一部とみなされるのですが、IE6/7はそうは解釈しないということですね。

ちなみに、content属性の値はまずHTMLの属性として解釈されるので、数値文字参照や名前つき文字参照は、url=を解釈する前の時点で展開されています。つまり、URL中の単引用符を &#39; や &#x27; と書いてエスケープしようと思っても無駄です。

%27にエスケープするなら意味がありますが、URIの意味が変わってくる場合があります。' はRFC3986で sub-delims に含まれている文字なので、生でURIの中に出現することがあり得ます。

※2012-03-12追記: 上記部分部分、生「'」は普通出現しないと書いていましたが、ご指摘を受けて訂正しました。ありがとうございます。

そんなわけで、レガシーなブラウザを考慮するとmeta refreshの動的生成は注意が必要、という話ではあります。

※しかし、そもそもmeta refreshなどというものを使う必要があるのでしょうか。時間指定のリダイレクトにはアクセシビリティ上の問題がありますし、「ページの自動読み込み」を無効にしたIEなどではmeta refreshは全く機能しないわけですから、必ず代替手段を用意しておく必要がありますし。

関連する話題: セキュリティ / プログラミング / HTML / Internet Explorer

Windows Azure, 閏年問題でダウン

更新: 2012年3月15日14時0分頃

こんなニュースが……「Microsoftの「Windows Azure」、閏年関連バグでダウン (www.itmedia.co.jp)」。

実はうちの会社でもWindows Azureを使った案件をいくつか持っていて、思いっきり影響を受けました。日本時間の朝10時頃からサービスがダウンし、管理画面からの再起動も受け付けない状態に。しかも、社内で最も詳しい人は「2012 MVP Global Summit (www.2012mvpsummit.com)」に呼ばれていて、日本にいないという厳しい事態。

幸いメールで連絡がついて、しかもすぐそばにAzureのMVPの方がいたらしく、むしろ通常よりも強力なサポートが得られる結果になりました……が、結論としては「Azure全体の障害なのでどうしようもない」という話で、座して待つ形に。

※日本時間で夜の21時頃には復旧していたようです。

……というようなことが起きたのですが、それがまさかの閏年問題だったようで。正式な障害報告書はまだ見ていませんが、Microsoftの方からの簡単な報告によると、証明書関係の処理で問題が起き、障害の範囲拡大を防ぐためにサービスを停止したということらしいです。

証明書の有効期限チェックの処理で閏年問題が発生したのだとすると、それはまあ動かなくなるでしょう。Azureの内部ではいろいろなところで証明書を使っているようですし、証明書のチェックは一見するとカレンダーとは関係なさそうに見えるところで、盲点になっていたのかもしれません。

Azureに限らず、証明書や鍵の有効期限をチェックするシチュエーションは増えていると思います。そこで問題が出ると影響が大きいので、注意する必要がありそうですね。

※2012-03-15追記: 有効期限のチェックで問題が起きたのではなく、証明書の新規作成に失敗したということのようです……「Azure閏年問題の詳細」。

関連する話題: セキュリティ / プログラミング / 出来事

最近の日記

関わった本など