タグ別アーカイブ: W3C

2010-11
23
22:12:27
w3cもケータイ認証には困惑している件


以前Twitterでもツイートしてたんだけど一部誤解があったのでこちらでまとめてみる。

Global Authoring Practices for the Mobile Web (Luca Passani)
http://www.passani.it/gap/

上記をもって「w3cが個体識別番号に駄目出し」としていたんだけど、多少事情が違った。
実は上記には元になる対象文書がある。それがw3cのベストプラクティスだ。

Mobile Web Best Practices 1.0
http://www.w3.org/TR/mobile-bp/#d0e1925

上記のGlobal Authoring Practices for the Mobile Web(以下GAP)はこのw3cのベストプラクティス(以下MWBP)への一種の「アンチテーゼ」として書かれている感が強い。
それらの比較についてはこちらのページが詳しい。
そのほとんどはモバイルWEBでの実装方法についてなので本稿の趣旨とは外れる部分も多いのだが、例えばMWBPではCookieについてこのように解説している。

5.4.14 Cookies
[COOKIES] Do not rely on cookies being available.
5.4.14.1 What it means
Cookies are frequently used to carry out session management, to identify users and to store user preferences. Many mobile devices do not implement cookies or offer only an incomplete implementation. In addition, some gateways strip cookies and others simulate cookies on behalf of mobile devices.

(参考訳)
[Cookies]Cookieが必ず使えると考えるな
Cookieはよくセッション管理やユーザーの特定に使用されるが多くのデバイスでは利用できなかったり正しい実装がされていない。更にはゲートウェイによってはCokkieを削除したりエミュレーションしている。

これだけだ。ベストプラクティスと言いながら実は解決策は何も提示していない。

これに対しGAPは非常に現実的だ。

Practice: If an application only relies on cookies for improved service, but is not essential to the well-functioning of the service itself, then cookie support can be safely assumed.
If cookies availability is essential to the correct functioning of the application (typically for supporting user sessions), then alternative mechanisms should be assumed. URL-Rewriting is the common way to by-pass the lack of cookie support ([URLREWRITING]).

(参考訳)
アプリケーションがCookieのみをベースにできるならそれは安全と見なしていいだろう。
Cookieの利用が機能の要であるならその代替機能も必要とされるだろう(訳注:恐らくCookieが使えない場合のことを言っている)。URL-RewriteはCookieの代替に使用できる共通した方法だ。

そしてよく知られたセッションIDをURLへ付加しURL-RewriteでCookieと共存する方法を述べているのだが、その最後でこのようなことを提示している。

Finally, in many cases, operator gateways and independent portals attach unique headers and values to each HTTP request, such as phone number headers (x-wap-msisdn, x-nokia-msisdn, x-up-calling-line-id) and subscribeer id headers (x-up-subno). The headers can be exploited as unique keys to track users and the foundation for session management.
Some detailed techniques to track users are presented here [TRACKUSERS]

(参考訳)
最後に、多くの場合キャリアのゲートウェイなどは特別なHTTPヘッダーを付加する。x-wap-msisdn, x-nokia-msisdn, x-up-calling-line-id, x-up-subnoといったもので電話番号や契約者番号を示している。
これらのヘッダーをユーザートラッキングのためのユニークキーにしたりセッション管理のベースにすることは脆弱性をもたらしかねない

ここでいうX-UP-SUBNOとは日本ではauで利用されているサブスクライバーIDと同じだ。当然言及はないが、docomoのuid、SoftbankのX-JPHONE-UIDも同列と考えていいだろう。つまりこのコンテキストにおいては「日本のガラケー界は根本から駄目出しをされている」と言えるだろう。

たとえ米国でもディベロッパーがユーザーの特定をあまり行っていない、そういうニーズが無いとは思わない。
ではw3cが何故ここまで踏み込んだ言及が出来ないかは幾つか理由もあると思うのだけど(個別製品への言及は馴染まないとか。X-UP-SUBNOはクアルコムOpenwaveのWAPゲートウェイでの仕様である)、大きな理由として「ベストな方法が考えつかなかった」という点も大きいだろう。
米国ではそもそも個体識別IDを送出しているキャリアばかりではない。つまり共通した手法として利用できる環境ではない。またCookieに対応する機種や環境も(日本と同じく)100%では無いようなので結局のところよい方法が示せなかったのではないか。

一方でこういうテクニカル文書もある。ユーザーをトラックするためのTIPSという感じだが 詳しくは参照してもらうとして、日本での脆弱な「ガラケー界」を見ている者としては少し口出ししたい気持ちにもなる。
つまりは問題ではあるがよい方法が見つからなくて複数の手法を組み合わせる、または端末の特性によって切り替えるしかない、というのは日本と同じ状況とも言えるかも知れない。
かくもモバイル環境(あえて言えば従来までのモバイル機器と環境) でのユーザートラッキングや認証については米国(あるいは世界)においても共通した手法は確立されていないし誰もが困惑しているということになるではないか。

翻って日本だ。幸い(?)日本の「ガラケー界」はベストプラクティスならぬ「バッドプラクティス」の宝庫だ。
しかし見方を変えればそれはベストプラクティスの種の宝庫とも言える。
こうした情報や経験が自由に交換され、国際的に包括されたベストプラクティスが熟成される環境が何とか作れないものか。そうした貢献が出来ていない点でも日本は「ガラパゴス」と呼ばれるのだろう。

(追記 2010/11/25)
“can be exploited..”について、コメント欄でも「単に使用できると言っているだけでは」との意見を幾つか頂いていました。
個人的にも気になったので、筆者であるLuca Passani氏へ直接メールして聞いてみました。以下がその最初の返信です。

(悪意されうると言いたかったのか?との質問に対して)
not really. I just meant that, if a developer needs to track users and cookies
are not available, other headers are an option.
Regards
Luca

との返答でした。
ということで、まずは「脆弱性になり得る」との参考訳を示したことについてお詫び申し上げます。
Passani氏とはその後少し話をして、僕からは日本での簡単ログインという方法が脆弱だと言われているんだよと伝え、彼に(恐らく彼が知る限りの)海外ではどのように捉えられているか尋ねたのですが、
「プライバシーの問題は特にヨーロッパ(彼はローマ在住の恐らくはイタリア人)では問題視される。但しオペレーターはパートナー(恐らく日本における公式サイトよりも厳しい業務提携先と推測)にしか『電話番号』は通知していないし、パートナー以外はIdentifier(例えばX-UP-SUBNOなどの個体識別番号)しか受け取れない」とのことでした。
電話番号というのは多少驚くところですが欧米(他の地域は言葉の問題でよく分かりませんが)では一部のキャリアではパートナーへのサービスとして行っているようです。また個体識別番号の取り扱いについては全く意に介していない様子でもありました。これはそもそも日本での「簡単ログイン」やセッション管理としての利用は一般的ではないため逼迫した問題化していないからだろうと推測します。
以上より、本文については「日本のガラケー界は特に興味も持たれていなかった」として訂正しご解釈下さい。
(であれば”can be exploited”なんて微妙な表現しないでよー、とは思いますがそれはそれとして)

ただ付け加えると、彼の経歴を見ると分かるのですが、実は長年Openwaveでエンジニアとして働いていた人物でもあります(現在はとある企業のCEOのようです)。つまり元々のX-UP-SUBNOを生み出した会社です(その他の通知ヘッダー類についても)。故に個体識別番号のプライバシーやセキュリティ問題について聞くのはそもそも野暮だったのだろうというのが印象です。

最後に、はてブのコメントなども見て多少気になったのですが、現時点において、ではモバイル認証によい方法がないのかと言えばそれは違います。単にCookieを使えば良いだけです(Passani氏も指摘している通り)。これは日本でももちろん同様です。
但しCookieが全面的には利用できないというある意味限定された環境下でのプラクティスの話と言うことになりますので誤解無きようにお願いします。
また個体識別番号の取り扱いについては国や地域で状況やプライバシーへの考えなども違うので一概には言いにくいかも知れませんが、しかし日本での経験が有意義なものに転嫁できるはず、という点はやはり変わりないだろうとも思います。
今回は相手が悪かったところもあるのですが(笑)、逆に如何に日本の実情が知られていないか伝えられていないかと言うことも肌で感じられたので、そうした取り組みが業界全体で行われるなら喜ばしいことだし重要な貢献であろうと思います。
以上、ご報告まで。

2005-04
11
12:54:49
Subcribeにも標準化は必要かも知れない(BlogPet)


きょうろこがROCAが下に購読しないです。
きょう、ROCAがここまでバーがイメージするつもりだった?


結局徹夜作業で公式WebサイトもXHTML1.0Transitionalにしてみました。
W3CのValidatorでは全てValid、HTML lintでは100点じゃないけど全て95点以上に出来たからいいか(一部の諦めているページ除く)。
元々ここ数年直すのが面倒だったので、ずっとHTML4.01Transitionalだったんだけど。
何のきっかけでこんな作業を突然やり出したのか。
今となっては全くの不明です。
人間って時々、何の必然性も無いことにむやみやたらに後先考えず熱中する生き物なんだな、と実感した次第・・。

*このエントリは、BlogPetの「ろこ」が書きました。

2005-02
27
09:01:00
公式WebサイトもXHTML1.0に


結局徹夜作業で公式WebサイトもXHTML1.0 Transitionalにしてみました。
W3CのValidatorでは全てValid、HTML lintでは100点じゃないけど全て95点以上に出来たからいいか(一部の諦めているページ除く)。
元々ここ数年直すのが面倒だったので、ずっとHTML4.01 Transitionalだったんだけど。
何のきっかけでこんな作業を突然やり出したのか、どうしてこんな面倒臭いことを徹夜でしなければならなかったのか、何故途中で休まなかったのか。
今となっては全くの不明です。
人間って時々、何の必然性も緊急性も無いことにむやみやたらに後先考えず熱中する生き物なんだな、と実感した次第・・。

2004-09
05
01:02:00
各BlogサービスでのXHTML/HTML 4.01対応状況比較(その2)


さて、ではさっそく結果を見ていきましょう。
ちょっとした理由と、一つの表にまとめて大きくなってしまいましたので、下記の別ページに置いておきます。
最初に謝っておくと、Excelから吐いたHTMLまんまで、しかもこんな話をしているわりに、かなりのNot Validなページとなっています(汗

まず、DOCTYPE宣言ではXHTML 1.0 TransitionalとHTML 4.01 Transitionalの二つに大きく分かれることが分かります。これは世の普通のWebページでの状況とほぼ似通った傾向と言えるでしょうか。(ポリシーを持って指定しているかどうかは別ですが)
またライブドアとヤプログ!は宣言を行っていません。これではブラウザ(UA)が解釈を決定できない(しにくい)ことになり、標準仕様上は間違いです。何故付けないかの理由は不明です。
またこの表では記載していませんが、XHTML 1.0 Transitionalであっても、XML宣言を付加していない場合が相当数あったことを付記しておきます。
問題はこのそれぞれの宣言に従ったHTMLが実際に生成されているかどうかです。表の整合性チェック結果を見て下さい。

Continue reading