追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1602   昨日: 4913

2019年07月08日

天動説設計から地動説設計へ:7payアプリのパスワードリマインダはなぜ壊れていたのか(序章)

7payの方式はなぜ許されないのか、なぜあんな設計になってしまったのか、どう設計するのが正しいのか、急ぎ書かなくてはいけないのだが、前置きが長くなっていつ完成するかも見えない。取り急ぎ以下のツイートでエッセンスを示しておいた*1が、すでにわかりかけている人達にしか刺さらなそうだ。

同様のことは4年前にNISCのコラムに書いたが、消えてしまっているので、ひとまず、その原稿を以下に再掲しておく。


スマホ時代の「パスワード」のあり方を再考しよう 高木浩光 2015年2月26日

皆さんはパスワードの定期的変更、してますか? 私ですか? 私はしていません。でも、先日、主要なサイトのパスワードを全部変更しました。

思い起こせば、私が初めて自分用のパスワードを決めたのは、大学の研究室でUNIXマシンを使わせてもらった1988年のことでした。それ以来同じパスワードを使い続けたのですが、2000年ごろ、セキュリティを意識するようになって、複雑なパスワードに変えました。銀行など重要なサイト用のパスワードと、一般のサイト用のパスワード、お試し用の漏れてもいいパスワードの3つを主に使い分けて(本当は他に重大なものが数個あるのですが)いましたが、ずっと変更しないで使ってきました。繰り返し手で打っているので体が覚えており、長年使い続けたパスワードは、自分の分身のようであり、愛着のあるものとなっていました。

そんな慣れ親しんだパスワードを捨てて変更したのは、このところもう使わなくなっていた、あるSNSサービス*2から、「お客様のアカウントに第三者が不正ログインした可能性がございます。」という知らせのメールが来たからでした。他のサイトでは異常が見当たらないので、「ほんまかいな?」と疑問に思いつつも、一挙にあちこちのパスワードを変更しました。

昨今、こうした通知をする事業者が増えていますが、これは、「リスト型攻撃」とか「パスワードリスト攻撃」などと呼ばれる手口が横行し、あちこちのサイトで大量の不正ログイン被害が出ているためです。どこかのサイトが不正侵入され、ID・パスワードを盗まれ、盗まれたものがリスト化されて不正に売買されており、それと同じID・パスワードを使っている別のサイトのアカウントが不正ログインされているのです。

残念ながら、サイト管理者側でこの攻撃を防ぐ完全な対策はありません。せいぜい、ログインエラーの発生回数が普段より多くなった時点で管理者が詳しく調査して対処するくらいしかなく、その間に生じる少数の不正ログインは防げません。本来ならば、パスワードを漏らした元のサイトの管理者が、事故の発生事実を公表し、漏れたパスワードの本人に通知するべきですが、私の場合、そうした通知は来ていませんので、漏らしたところ*3は公表を渋っているか、漏らしたことに気づいていないのでしょう。

私はこの機会に、各サイト毎に別々のランダムに生成した12文字のパスワードを設定してみました。利用者側でこのように対処すれば万全の対策となります。こういうパスワードはもう自分で覚えることは不可能ですが、最近のOSやWebブラウザには、パスワードを記憶して自動で入力してくれる「パスワード管理機能」が標準でついていますので、今回これを使う前提でそうしてみたのです。

実際に運用してみて困ったのは、スマホアプリで使うこともあるサービスの場合です。スマホアプリは、パスワードの自動入力に対応していないので、手で入力することになります。最初の1回は、パソコンのパスワード管理機能が覚えているものを画面に表示させて、ランダムな12文字を目で確認しながら打ちました。面倒な作業ですが、1回するだけならいいでしょう。ところが、あるスマホアプリは、パスワードを覚えてくれないものでした。宅配便の到着状況を確認するアプリ*4なのですが、外出中にいざ使おうとしたとき、パスワードの入力を求められ、パソコンのパスワード管理機能を見に行かないとわからず、その場で使えませんでした。

このアプリはなぜこのような設計なのでしょう? セキュリティのため、パスワードをアプリに覚えさせておくのは危険だと考えたのでしょうか。

しかし、Twitterやfacebookといった著名アプリは、一度ログインすれば再びパスワードを入力する必要のない設計になっています。これはパスワードを覚えているのではなく、最初にログインしたときにサーバ側で発行されたアクセストークン(ランダムで長い文字列)をアプリが覚えているのです。サーバ側は、そのトークンを持っている端末を本人からのアクセスとみなしてログイン状態を保ちます。Webサイトでも、利用者がログアウトボタンを押さない限りログインしっぱなしになるサービスがありますが、それも同じ仕組みです。

スマホのアプリをログインしっぱなしにしておくことは危ないのでしょうか? たしかに、スマホをどこかに置き忘れたりすると、勝手に操作される危険があります。でも、メールやメッセージも、ログインしっぱなしなアプリばかりであり、紛失時の安全性は、スマホの端末のパスワードや指紋認証、加えてリモートワイプ機能(遠隔データ消去機能)で保たれるのが前提となっているようです。

そうすると、ログインしっぱなしでよいならば、いっそのこと、サイトのパスワードなんか無くしてしまえばいいのではないでしょうか。

私のパスワードは今や、サイト毎に別々のランダムな12文字で、OSやブラウザが覚えていて自動入力です。それって、もはや、スマホアプリが自動送信している「アクセストークン」と変わらないではないですか。実際、サイト側のログイン認証のセキュリティ強度としては同等のものです。

パスワードをこのように設定している人はまだ少数派かもしれません。しかし、リスト型攻撃はいっこうに収まらず、完全な対策もないため、利用者への注意喚起として「パスワードを使いまわさないで!」と叫ばれるようになってきました。先ほどの宅配便のサイトも、「他のサイトで使用しているバスワードを設定しないでください」と利用者に求めていますが、どのサイトに行ってもそう言われるなら、もはや人力で対処するのは無理な注文です。OSやブラウザのパスワード管理機能に頼るしかありません。そして、そうするしかないのなら、パスワードはランダムなものでいいでしょう。

となると、利用者にパスワードを決めさせる必要もなく、サイト側で決めてしまえばいいはずです。サイトのアカウント作成のときに、新しい利用者にランダムな文字列(トークン)を渡し、それを設定するように渡します。初回利用時の設定はプログラムが自動的に処理するでしょう。利用者はパスワードを意識しないで使えます。パスワードなんていらなくなるのです*5。こうすれば、パスワードの使い回しを防ぐことができ、リスト型攻撃を無力化できます。

ただ、話はそう簡単ではありません。スマホの端末を買い換えたときに、トークンの引き継ぎをどうするかという問題が残ります。引き継ぎを自動でできないときのために、再設定のための仕組みがどうしても必要になってしまいます。パソコンのブラウザで使う場合には、cookieを削除するとログアウトしてしまいますから、やはり、再び設定するための仕組みが必要です。

その目的のために、これまで通りのパスワードを使ってしまうと、元の木阿弥です。なぜなら、利用者が設定するパスワードでは、使い回しされるのを防げないからです。ですので、アカウントの作成時に、ランダムな文字列のトークンを利用者に渡し、いざという再設定のときのために大切に保管しておくように促す方法が考えられます。パソコン内に保管せず、紙に印刷して金庫に保管するよう促すとよいでしょう。

では、そうしたサービス形態が将来、普通になってくると、この世から「パスワード」はなくなってしまうのでしょうか。サイト運営者から渡されるトークンは、「パスワード」と呼ぶには相応しくありません。そもそも「パスワード」とは、人が記憶して使うもののことを言うからです。今日、「他のサイトと同じにしないで」と言われて、しぶしぶランダムな文字列を自動入力させているのも、入力欄の名前こそ「パスワード」ですが、およそ「パスワード」とは呼べないものを入力しているわけです。

そういう将来でもなお使われるであろう「パスワード」は、端末の操作をロックするパスワードです。このようなパスワードは、サーバに送信しないものであり、端末上で本人認証の処理が行われます。こうしたパスワードは、一人に一つあれば足りるでしょう。複数の端末で使い回しても、今日のリスト型攻撃のような脅威はありません。こうした操作のロックは、指紋認証などの生体認証で置き換わるかもしれませんが、緊急時のために結局はパスワードも必要になるはずです。

つまり、将来、人が覚えて使うパスワードというものは、端末上の認証(ローカル認証)に限って使うものとなり、サイトのログイン認証(リモート認証)には使わないのが現実となるだろうということです。そして、そのときの「パスワード」は、原点に立ち返り、体が覚え、愛着のある、自分の分身のようなものにできるはずです。

ただ、そうした将来に急に切り替わることはできませんので、過渡期には、リモート認証に使うものも一部残ることになるでしょう。このとき心配になるのは、一般の利用者の方々が、「これはリモート認証なのか、ローカル認証なのか?」を区別できるだろうかという点です。この違いを人々が意識できるような工夫が必要だと思います。例えば、「パスワード」とか「トークン」といった言葉を再整理して、言葉で区別できるようにすることはできないでしょうか。

リモート認証用の「パスワード」をなくすまでにあと5年、10年かかる*6かもしれませんが、今のうちから考え方を整理しておく必要があるな、と感じています。


*1 関連ツイートスレッド1スレッド2スレッド3スレッド4

*2 mixiのこと。

*3 Adobeの漏洩だったと後に知った。

*4 クロネコ。当時はそうだったが、その後改善されて今はログインしっぱなしになっている。

*5 2017年4月、ヤフーがパスワード不要のログイン方法を開始した。試してみると、ログインにパスワード不要なのではなく、新規アカウント作成からしてパスワード設定が不要となっていた。

*6 4年がすでに経過した。

本日のリンク元 TrackBack(0)

2019年06月25日

総務省が不正指令電磁的記録罪の典型的誤解を再生産中、原因を絶たねばならない

昨日からこれが話題になりつつある。

ソースはこれのようだ。

まず根本的に間違っているのは、「悪意があってもなくても、ウイルス作りは犯罪」*1と断罪されている点だ。言うまでもなく、悪意のないウイルス作り(作成・提供)は合法である。

こうした典型的な勘違いが出てくることが予想されていたので、刑法改正案は一旦廃案となって、民主党政権時代に修正法案が提出された際、「正当な理由がないのに」との条文が付け加えられたのだ。もっとも、何度も周知してきた*2ように、「正当な理由がないのに」は「違法に」の意味*3であり、刑法35条(正当行為)の同語反復となっていてほとんど意味がなく、確認的に規定されただけのもの*4と言われている*5。そもそも「正当な理由がないのに」との条文がなかったとしても、「人の電子計算機の実行の用に供する目的で」との条文により、「悪意のないウイルス作り」は該当しないのである。

次に、このパンフレットは、供用罪についての説明が一切ない。供用罪のことを知らないのだろう。不正指令電磁的記録に関する罪は、供用罪が中核にある。供用(168条の2 2項)を罪とすることを核として、その未遂(同条3項)も罰するものとし、その前段階であるところの作成・提供(同条1項)をも罪とし、さらにその取得・保管(168条の3)までも罪とするものである。供用する目的がないのなら、作成も提供も取得も保管も犯罪ではない。供用とは、要するに人を騙して(プログラムに対する社会の信頼を害する程度に)「意図に反する動作をさせる」プログラムを実行させることである。それがなければ罪にならない。

「多くの人に見てほしいと思って、ネットに公開」したことが「作成・提供罪になる」と書かれているが、誰かを騙して(意図に反する動作をさせるものとして)実行させる意図がなければ、供用罪を構成しないのであり、そのような騙す意図なく「多くの人に見てほしいと思って、ネットに公開」するケースもあり得る。

そもそも「ウイルス」というものが定義できるわけではないし、刑法は「ウイルス」を対象としているのではなく、あくまでも「不正指令電磁的記録」が対象である。この罪を「ウイルス」の語で語ること自体が誤解が生じやすいのであり、供用の目的がなくても作ること自体が危険行為であるとの勘違いを生みやすい*6。この刑法の罪は(偽造罪とのパラレルで構成されているように)そのような趣旨で立案されたものではない。

供用罪の理解、刑法の目的犯・偽造罪の構成の理解がないままオレオレ正義を語ると、このような勘違いパンフレットになってしまう。こういう素人的勘違いが田舎警察と田舎検事にまで達した*7のが、宮城県警のWizard Bible摘発事件であった。

そして、「いたずらウイルス」との記載がある点も見逃せない。兵庫県警のアラートループ摘発事件は、まさにこういう勘違いの蔓延によって(刑法改正から7年が経ちとうとう)起きてしまった悲劇であった。プログラムに対する社会の信頼を害するほどでもないジョークプログラムは不正指令電磁的記録たり得ないのだが、このようなパンフレットが出回れば、「いかなるジョークもプログラムによって行うことは犯罪」との誤解が広まることになるだろう。

このパンフレット「インターネットトラブル事例集」は、平成21年度版から出ていたようだが、不正指令電磁的記録についての記載が入ったのは、平成29年度版からだったようだ。

こうした誤解させるパンフレット作成の再発を防止するにはいったいどうしたらいいのだろう。原因を究明しなければならない。どうしてこんな内容で出してしまったのか。いったいどこの業者がこの原稿を書いたのか。消費者行政一課は法務省刑事局と協議しなかったのか。NISC総合対策グループに意見を求めるくらいしたら防がれたかもしれず、残念でならない。可及的速やかに訂正されることが求められる。*8

*1 パンフレットには、「不正アクセスや」とある。確かに、不正アクセス禁止法の不正アクセス行為(他人のID・パスワードでアクセスする行為)は(このパンフレットが言うところの)「悪意があってもなくても」違法行為である。それは、不正アクセス禁止法が「禁止法」と言う名の通り、典型的な法定犯だからである。これに対して、刑法典に追加された不正指令電磁的記録に関する罪は自然犯と言うべきもので、「悪意があってもなくても」犯罪とするような趣旨のものではない(保護法益である「コンピュータプログラムに対する社会の信頼」は(このパンフレットが言うところの)「悪意があって」初めて害されるもの)と言うべきである。やはりこのように、不正アクセス禁止法の法定犯感覚が不正指令電磁的記録の罪に混同され、誤解が広まっているようだ。

*2 例えば、2011年7月28日の日記など。その他、この日記の目次「不正指令電磁的記録」参照のこと。

*3 法務省「いわゆるコンピュータ・ウイルスに関する罪について」8頁。

*4 前掲注3は「一層明確にする趣旨で」(8頁)としている。

*5 実際、Coinhive事件の裁判でも、Androidアナライザー事件の裁判でも、「正当な理由がないのに」については全く争点にされていない。

*6 作ること自体が危険視されるウイルス(ワームなど)を作ること自体を処罰対象とするのも選択肢としてアリだったが、刑法のこの罪はそういうものではなく、騙して使うことで(法益侵害の)危険が生じるものは何でも対象とした上で、その目的での作成・提供・取得・保管をも対象としたものだ。ここで、前者の発想で「ウイルス」を捉えて絶対的危険視しながら、後者の法の規定をつまみ食いして、これらを合体させると、このパンフレットや宮城県警のような誤った理解に陥ってしまう。

*7 3月16日の日記「しそうけいさつ化する田舎サイバー警察の驕りを誰が諌めるのか」参照。

*8 スマホにまずウイルス対策ソフトが必要とかパスワードは定期的変更が必要とかWi-FiにはMACアドレス制限が必要といったインチキリテラシーもこういったパンフレットに安直に記載されがちなのだが、これまでに相当数が防がれてきている。

本日のリンク元 TrackBack(0)

2019年06月09日

ヤフーの信用スコアはなぜ知恵袋スコアになってしまったのか

毎度ここぞという絶好のタイミングで反面教師となってくださるヤフーさん、7月から「Yahoo!スコア」の提供を開始すると発表したことで、情報銀行界隈の識者の方々の怒りを買っているようだ。「ヤフーが情報銀行はやらないって言ってたのはこのことか」とのコメントがあるが、ヤフーからすれば、オプトインなんかじゃ誰も使わねえよそんなもん(ワナにひっかけて承諾*1とらねえとなとな)ということなのだろう。つぶしあえーという感じだが、ここで悲しいかな笑われてしまっているのは、ヤフーが信用スコアの「信用行動」に「知恵袋での活躍度」*2を投入してきたところだ。

  • Yahoo!スコアで利用しているデータ, Yahoo! JAPANヘルプセンター
    ■カテゴリーと利用データ

    カテゴリー 利用データ
    本人確認 Yahoo! JAPAN IDにひもづく住所・氏名・電話番号・メールアドレスなどの情報の登録率、登録された電話番号およびメールアドレスの有効性、Yahoo! JAPANが提供するサービスにおける住所確認や本人確認の有無等
    信用行動 ヤフオク!における取引実績や評価ショッピングでのレビュー回数知恵袋での活躍度、Yahoo! JAPANへの支払い滞納の有無および回数、利用規約・ガイドライン違反の有無および回数、宿泊・飲食店等の予約キャンセル率、キャンセル連絡有無などの行動実績等
    消費行動 Yahoo! JAPANが提供するEコマースサービス、Yahoo!ウォレット、Yahoo! JAPANカードなどの利用金額等
    Yahoo! JAPANサービス利用 Yahoo! JAPANが提供するサービスの利用頻度などの実績等

    Yahoo!スコアの作成および利用は、お客様のプライバシーの保護に十分に配慮したうえで実施しております。

    算出元データには、通信の秘密にあたる情報、スコア化することで不当な差別につながる可能性がある情報(要配慮個人情報、性別や職業等)は使用しません。

知恵袋での行動が知恵袋内での信用評価として使われるのは普通(そういうサービスだということ)だが、それが、知恵袋の外で、お金を借りるときとか、飲食店を予約するときに信用として必要になってしまう、そんな社会はまっぴらごめんだ。(だれにもわかりやすくてたいへんよい。)

ヤフーが信用スコアの作成をオプトアウト方式で全アカウント強制で行うとしていることから、どこが「お客様のプライバシーの保護に十分に配慮したうえで実施」だよと、識者の怒りを買っているわけである。

しかし私には見える。ヤフーがなぜこれで「プライバシーの保護に十分に配慮した」と言っているのかが。

実は、ヤフーの信用スコアは、昨年10月に実証実験を開始すると発表した際には、「購買履歴」「検索履歴」「ニュースの閲覧」が利用されるとされていた。

それが今回の正式スタートでは、購買履歴も検索履歴もニュースの閲覧履歴も含まないとしているのだ。GPS位置情報といったものも含まれていない。そこがヤフーの言う「プライバシーの保護に十分に配慮」なのだろう。

つまり、ヤフーは、「プライバシー」を(憲法学者などがよく言うように)個人の秘密に限られると捉えたのではないか。「知恵袋での活躍度」は公開されている情報なのだからプライバシーじゃないと言うのだろう。同様に、今回の「利用データ」で明かされた「ヤフオク!における取引実績や評価」も「ショッピングでのレビュー回数」もいずれも公開されている情報である。*3

だが、個人データ保護とはそういうことじゃない。EUにおけるGDPRは(その前身のデータ保護指令のときから)明確にしているように、秘密を守ることが個人データ保護なわけではなく、たとえ公開情報であってもそれを用いて個人を自動処理で選別することが問題(同意が必要など)とされるのである。

日本法はどうかというと、公開されている情報でも個人情報であるとされている*4ものの、その趣旨は必ずしも明らかでなく、前記のように「個人を選別することが問題」とされているかははっきりしない。逐条解説書で「個人情報のコンピュータ処理等に伴う個人の権利利益侵害の危険性、本人の不安等の社会問題に対応しようというもの」*5と、ぼんやりした説明がなされている程度である。ただ、昭和63年法(行政機関の保有する電子計算機処理に係る個人情報の保護に関する法律)の法案立案時の資料に目を通すと、そういったことが当然の前提として想定されていたよう*6である。

日本法について、法目的に「プライバシー」保護であることを明記せよという意見は以前からあり、平成15年法の立案時にもそのような意見があったが、法制局審査資料を見ると、「プライバシー」が何であるかはっきりしないという理由だけでなく、それに限られないから、限定すべきでないという理由であえてそこの目的を明記しなかったという経緯がある*7ようである。

1980年のOECDガイドラインが「privacy」の語を用いたのが誤解を生むことになったのではなかろうか。「個人をデータで選別することの問題」もプライバシー問題の一種だという意見は昔からあったが、そこは、誤解させないために、「データプライバシー」などと呼んで意義を明確にするのがよい。EUでは、データ保護指令のときは「privacy」の語を用いていたのを、GDPRでは「privacy」の語を完全に排除*8しており、PIA(プライバシー影響評価)のことさえ、DPIA(data protection impact assessment)と言い換えて徹底しているのは、そういう誤解を排除することが意識されているものと思われる。

今回のヤフーの知恵袋スコアが「プライバシーの保護に十分に配慮」と称しているのは、この誤解がまたしても露わになったものと言えよう。(つまり、日本法もそのような誤解を避けるべく法目的を明確化する必要があるということ。)

ところで、Yahoo!スコアがオプトアウト方式でスコアの作成を既に開始してしまっているのは、個人データの目的外利用に当たり、個人情報保護法16条違反ではなかろうか。ヤフーとしては、スコアの他社への提供時に本人の同意を得るとして、それで適法だと勘違いしているようだが、スコア作成に知恵袋での行動が同意なく利用されているのは、個人データの目的外利用に当たる疑いがある。

ヤフーは今回のプレスリリースで、「「Yahoo!スコア」の利用目的を、ユーザーへの特典等の付与、審査プロセスの簡略化、コンテンツ最適化、サービスの改善、広告の配信等としました(※4)」としているが、スコアの利用目的の話ではない。スコアに投入する元データの利用目的が問題である。

「※4」のところを見ると、「詳細はプライバシーセンターをご確認ください。」とあって、リンク先を見にいくと、「パーソナルデータの活用」とあって、「Yahoo!スコア」のことは書かれているものの、知恵袋のことは書かれていない。知恵袋の利用規約等で知恵袋の利用目的について書かれている必要があるが、「Yahoo!知恵袋ヘルプ - Yahoo!知恵袋の利用には利用規約への同意が必要です」を見ると、スコアのことは書かれていない。

昨年10月のプレスリリースには、「IDに紐づくさまざまなビッグデータを基に機械的に算出したスコアを統計情報として提供し」と、「統計情報」と書かれていた点が気になる。個人情報保護法ガイドラインQ&Aでは、Q2-5で、「統計データへの加工を行うこと自体を利用目的とする必要はありません。」としているので、ヤフーはこれを根拠に知恵袋データの目的外利用に当たらないと勘違いしたのではなかろうか。

ここで言う「統計データ」というのは、Q1-14で「統計情報(略)は、特定の個人との対応関係が排斥されている限りにおいては、『個人に関する情報』に該当するものではないため、『個人情報』にも該当しないと考えられます。」とあるように、ある個人について属性情報が統計量になっている(ヤフーの言っていることはこれ)という意味ではなく、複数の個人についての個人データが集計されて統計量になったものを言うのであって、もはや一人ひとりの個人データではなくなったもののことを言っている(Yahoo!スコアが一人ひとりの個人データであるのは明らか)のである。

ヤフーが実際にどう勘違いしたのかははっきりしないが、目的外利用禁止違反*9の事例として個人情報保護委員会にはぜひ執行して実績としていただきたいものである。

今からでも、知恵袋やヤフオク!等の利用目的を変更して通知・公表すれば、それ以降に取得したそれらの個人データについては、個別の同意なくその目的で利用することはできる。(変更前に取得したものを用いることはできない。)*10

*1 ワナにひっかけた承諾の例としてこういうのをヤフーはずっと続けている。

*2 Yahoo!知恵袋といえば、私もかつて「影響力のあるブログ、facebook、twitter、もしくは、ヤフー知恵袋などに執筆いただき、弊社製品のポジティブな評判形成にご協力いただけないか」とのご相談メールをキングソフト広報から頂いた場所として懐かしい。

*3 その他の利用データは、「支払い滞納の有無および回数」、「利用規約・ガイドライン違反の有無および回数」、「予約キャンセル率」、「キャンセル連絡有無」といったように、何かの違反行為の事実のみに抑えられている様子がある。

*4 ガイドライン通則編は、2-1で、「『個人に関する情報』とは……公刊物等によって公にされている情報や……も含まれ」とし、事例7としてSNSで公にされている情報も挙げている。

*5 園部編『個人情報保護法の解説《第二次改訂版》(ぎょうせい、2018年)51頁

*6 しかし、当時の立案では、民間部門を対象とせず公的部門のみ対象となり、行政機関ではそもそも所掌事務の範囲でしか電子計算機処理を行わないから、それについて本人同意を要するとするわけにはいかないので、自動処理に係る規定は入らず、開示・訂正とファイル簿、安全管理の制度になっていた。その結果、十数年後、民間部門まで対象を広げる基本法の立案時に、その趣旨が忘れられてしまっていたように見受けられる。

*7 法制局審査資料に目を通していると、このようなパターンは多い。つまり、目的や理由を明確にする必要があるところ、時間が限られている中で明確化できず、広めにふわっとした書き方にしておいて、後で明確化することにするというパターン。しかし結局、後から明確化されることはない。役人だけで勝手に決めるわけにもいかないからであろうか。

*8 ePrivacy指令を参照する注に出てくるのみとなっている。

*9 確認していないが、「ヤフオク!における取引実績」、「ショッピングでのレビュー回数」、「Yahoo! JAPANへの支払い滞納の有無」、「利用規約・ガイドライン違反の有無」、「宿泊・飲食店等の予約キャンセル」についても同様ではないか。

*10 2015年3月8日の日記の図4参照。ただし、利用目的の変更時に公表だけでいいのかという日本法の根本的な問題はある。

本日のリンク元 TrackBack(0)

追記

最近のタイトル

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|
追記