KDDIの携帯端末に搭載されているソフトウェアに不具合が発見され、店頭にて改修をするそうです。
今回の不具合内容は記事によれば
KDDIは、auおよびツーカーの携帯電話のうち、2003年3月～2005年8月に発売された機種において、特定の操作を行なった場合に本来送出されないはずのリファラが送出されるという事象があることを明らかにした。同社では、店頭で改修受付を開始している。
リファラは、ブラウザ使用中にサイトへアクセスするとサーバーに送信されるデータ。直前まで見ていたページのURLなどが含まれる。通常は、リンクを選択してアクセスした場合にのみ送出されるデータだが、同社の一部端末では、特定の操作を行なうとこれ以外の場合にもリファラが送出されるケースがあるという。
ということです。しかしこの記事では、「リファラ」というものが通常送出されるケースとは違うケースで送出されるのが問題だ、とだけ記述されており、当不具合が深刻なものなのかそうでないのかはあまりよくわかりません。
KDDIの説明を見てみましょう。
インターネットによるホームページの閲覧において、次に閲覧するページを「リンク選択」すると、現在閲覧中のホームページのURL (サーバ名、フォルダ名、ファイル名など) を、次に閲覧するホームページへ付加情報として送出する機能（noribo2000注 これが「リファラ」機能です）があります。これは、RFC (Request For Comment。インターネットの技術に関する一般的な仕様) にて記されており、一般的なブラウザにおいては本機能を搭載しています。
au携帯電話、TU-KA携帯電話においても同機能を搭載していますが、「リンク選択」しない場合においても、以下の特定の操作を行うと、現在閲覧中のホームページのURLが次に閲覧するホームページへ送出される事象が発見されています。
（中略）
なお、本事象は、データ通信機能に影響を与えるものでもありませんので、そのまま安心してお使いいただけますが、(中略）より安心してお使いいただくために、該当する携帯電話機については、本事象を解消するためのソフト書き換えを実施させていただきます。
最初の記事より情報量が増えた部分は以下のとおりです。
- リファラとはRFCという標準仕様で規定されている機能であり、通常のブラウザは備えているものである。従って、「リンク選択」したときにリファラが送出されるのは標準仕様に従った動作である。
- リファラの送出そのものが、データ通信機能に影響を与えない。それでも「不安」を感じるユーザに対しソフトの書き換えに応じる。
ここまで読んでもなお何が問題なのかが解りにくいですね。特に下記の点が解りにくくしている原因であろうと思います。
(疑問１）リファラが送出されることが、ユーザの「安心」「不安」とどう関わるのかがわからない。
(疑問２）仮にリファラを送出することが「不安」なのであれば、なぜリンク選択したときのリファラ送出は不安視されないのか？
ここでまず、リファラというものの性質について整理しましょう。
KDDIの説明ではリファラとはRFCに記載されている仕様であると言及されています。具体的にはRFC2616 HTTP/1.1という仕様の中に
14.36 Referer
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained ① (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.②
（中略）
If the field value is a relative URI, it SHOULD be interpreted relative to the Request-URI. The URI MUST NOT include a fragment. See section 15.1.3 for security considerations.
15.1.3 Encoding Sensitive Information in URI'sBecause the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent.③ For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information.
（以下略）
という記述があります。下線部について解説します。
① リファラとはサーバ（Webサイト）にアクセスする際、どのホームページからリンクをクリックしてそのサーバにアクセスしたのかをクライアント側（ブラウザ。今回の場合は携帯端末の中のソフトウェア）で記述することができるものである。これの仕組みはサーバ側でどこのホームページに自分のサーバへのリンクが記載されているのかを知りたい場合等に便利である。
② リファラはリンクのクリック以外でアクセスした場合（キーボードで直接アドレスを入力した場合など）は送出してはならない。
③ リファラはアクセスした人がどのホームページを見てからそのサーバにアクセスしたかがわかってしまうので、プライベートな情報ともいえる。従って、リファラを送出するかどうかは選択可能にすることを強く推奨する。
ようやく疑問１、２に対する答えが見えてきたような気がします。以下にまとめます。
（疑問１「リファラ送出と不安の関係がわからない」について）
リファラが送出されると、そのユーザがどのホームページをみてからこのサーバにアクセスしたのかがサーバの管理者が解ってしまいます。これはネットサーフィンの履歴の一部が知らぬ間に第三者であるサーバ管理者に知られてしまうことを意味しており、プライベートな情報の漏洩と感じる人もいるでしょう。従ってユーザの「不安」の要素となりえるのです。
（疑問２「リンクなら不安が無く、それ以外ならなぜ不安かがわからない」について）
疑問１の答えで述べたように、リファラが送出されることはリンクからのアクセスかどうかに関わらずプライベートな情報の漏洩と感じ不安に感じるユーザもいると思われます。従ってユーザの不安を払拭するためには、仕様に明記されているリンク以外のアクセスの場合のリファラ送出の禁止だけではなく、仕様としては推奨レベルであるが、どのようなケースにおいてもリファラの送出可否をユーザ側で選択可能にする必要があると考えます。
KDDIの対応は、仕様として「禁止」されている操作ができてしまうということについて改修を行うが、仕様に「強く推奨」されている操作の機能追加は実施しないということになります。どちらもユーザの「不安」を払拭するのに必要な対策だと思うのですが、標準には適合しているからそれ以上は実施しない、ということであれば大変残念な対応と言わざるを得ません。
