ちょっと遅くなりましたが、情報ネットワーク法学会・第19回研究大会の11/3分のメモです。
午前の個別報告のところはあまりにも意味不明なメモなので省略して、午後の分科会の部分のみになってます。
こちらも個人的なメモなので内容は無保証です。あらかじめご理解いただいた上で個人の責任でご覧ください。
○第6分科会
まず大井先生
https://www.slideshare.net/tetsuyaoi33/2019inlaw-securityoi
EC-CUBEベースのカスタムパッケージを販売していて、当該ショップ用にさらにカスタマイズ
EC-CUBE側のクレカ機能は使わず、後から自前で実装していた
金種指定詳細化後にクレカ番号等も保存するようになった
後から原告側基幹システムで請求元情報を正確に管理したいという要件が入ったため
SQL Injectionでクレカ番号情報流出
裁判所の判断
そもそもクレカ番号を持つようになる前から個人情報を保持していたのだから、当時のセキュリティ水準はちゃんと満たすべきだった
H21年時点で、既に経産省・IPAから安全管理措置に関する呼びかけが行われていた
本件についてはSQL Injectionへの適切なセキュリティ対策が行われていなかったので債務不履行にあたると言える
クレカ番号を暗号化せずに保存した件については、追加発注時点で被告側の義務があるとはいえない
被告の属性によって義務のレベルが上がる 本件については重過失が認められる
ベンダの契約スコープにも仕様にも入っていない場合でも暗黙でセキュリティについて合意していると判断すべき
続いて影島先生 その後の裁判例の話
https://www.slideshare.net/HiroyasuKageshima/2019-189808342
H26年判決は信義則・不法行為に基づく義務の話
H30年のSQL Injection問題の判決
実際の攻撃は行われていなかったが脆弱性があった このときは使用者責任で訴えている
中国の脆弱性ポータルサイトに当該サイトが掲載されていた
プロジェクトの確認書・仕様書にもSQL Injection対策の話が明記されている
2・3件目は発注者・ベンダの関係ではないが似たような事例
2件目は二段階認証が導入されていない、3件目は3DSecureが導入されていない
2件目はAPI取引を行っていたのが特殊な事例 ちなみに請求棄却
時系列としては事件が起きてからバタバタと世間が追いついてきたという感じ
約款上「一切の責任を負わない」と書かれていても、信義則上セキュリティの構築義務は存在する
問題はその義務に違反するほどの特段の事情があるか?
API取引において二段階認証はかえって不具合を起こす可能性もあるので、絶対に必須とまでは言えないというのが裁判所の判断
3件目は立て替え払いの返還請求
原告は一応の配慮はしている
被告は「3DSecureやってなかったからアウト」と言っているが、だからといって最低限の基準を満たしていないとは言えないとなった
伊藤先生
https://www.slideshare.net/masahiroito75/2019in-law-securityito
本分科会のスコープは開発ベンダの責任
まず問題になるのは契約不適合
契約不適合責任の存続期間 現行法だと「引き渡しから1年」なのに対し、改正法だと「脆弱性が明らかになってから1年」に変わった
契約で上書きすることは可能だが、デフォルトのルールが変わった
通常のソフトウェアである機能的なバグが数年経ってから見つかることはなかなかないが、脆弱性は予測しづらい
2007年の経産省モデル契約(当然ベースは現行法)
セキュリティ要件をシステム仕様に含めている場合、別途書面にて定めたものを守らない場合契約不適合責任について争いはない
脆弱性と瑕疵の区別が理解されにくい? そもそもこの2つは違うという業界の認識がある
一般ユーザ側ではそういう認識はされていない
新規の脆弱性は瑕疵・既知の脆弱性と区別したいというベンダ側の意思 それならまだわかる
IPAの調査報告書でも「後日判明した脆弱性を責任の対象とするのは妥当でない」とある
未知の脆弱性については仕様書で記載しようがないので存在しない
一方で問題なのは既知の脆弱性だが仕様書に未記載のもの
非機能要件は契約で後回しにされることが多い
ディスカッション
「既知で仕様書に記載はない」ものについてどこまで責任を負うべきか
大井:ベンダよりの考え方かもしれないが、これを発注・受注側とも認識しつつ仕様書に書かなかった場合
仕様書に書かれていないのは債務の対象外となるのが大原則
お互いに認識があるのであれば、余計に記載がないものは対象外とすべき
ユーザ側に脆弱性の知識がない場合、契約に書いてないものが債務の対象外となるかという点で議論の対象となる
影島:ユーザよりの立場 仕様書に書いてないものを作る義務
どういう書きぶりがあるのかについても影響があるが、それを覗いて考えた場合
外部的な事情を見て、当事者の合理的な解釈で見るのか信義則・不法行為なのか
機能要件については双方に義務があるが、セキュリティについては情報の非対称性があるのでベンダにより責任がある
民放483条をなくすかどうか(現状引き渡しの話)の議論で、品質・信義則等の話 契約の内容の解釈になるが、信義則・慣習で定まるものも民法上の「品質」に当たるとするのが妥当
伊藤:明示的に仕様書に「これはやりません」と書いてあればいいのだが、仕様書には書いてないがメールのやりとり・議事録が残ってた場合はどうなる?
大井:書いてある・ないは字面で決まるべき
契約文字外の内容をいかに解釈に盛り込むか
データの保持・非保持について突っ込んだメールがユーザからなされたとき、ベンダからの回答を受けて結局発注しなかったことは契約の解釈に盛り込まれるべき内容だと思う
伊藤:債務不履行が否定された(クレカ保持)件について、これが肯定されるとメールが無駄になる
影島:メールや議事録から事実認定されることはよくある 残しとくに越したことはない
伊藤:散らばってるやり取りが紛争になったときに、予期せぬところでメールが出てくることを防ぐ対策はないか?
大井:契約書に盛り込むべき内容とそうでないものを分ける 完全合意条項をそのために使う方法がある
契約書以外のRfPやメール等は全て効力を失う
しかし、完全合意条項があったとしても裁判所は事実認定でメール・議事録等を使いがち(契約外の事項を取り込みがち)
一つのソリューションではあるが完璧ではない
伊藤:メールでは議論したけれども仕様書には書かれなかった場合は、仕様の承認に関する条文で排除するということはありうる?
大井:お互い合意したものだけを仕様書化する、合意形成プロセスを定めるといったことをやっていれば、そこから漏れたものは対象外とするとしていいと思う
伊藤:仕様書を承認しましたよねとしつつ、その先で訴訟が起きてる気がする
影島:完全合意条項を入れておいたとしても、契約の時点では概括的な合意にならざるを得ない
プロジェクト始まった後に作られた文書で要件定義書・仕様書等が問題になってくる
受け入れテスト段階でユーザが文句言い出すことはよくある
セキュリティはその後で問題になることがよくある
実務的ではないが、仕様書のところで「この機能以外実装しません」と書けるのであれば完全合意になる
それが実務上できるのかどうかが問題になる
伊藤:基本設計書・要件定義書で「後で取り込めるものは努力します」とふんわりするのが良くないんだろうなと思う
大井:契約条項案で「ユーザが自分の責任で実装する」と明記するのは一つリスクヘッジとしてあると思う
ECサイトでは非保持化、もしくは保持で暗号化が常識で、その分お金くれるのであれば実装します
それをユーザに説明した上で「じゃ自分でやる」と言われれば
伊藤:そこをユーザがリスクを飲んでサインしてくれるケースはまず無いと思う
伊藤:脆弱性の原因がOSSや外部ベンダのソフトにあった場合どうするか
大井:システムの一部を構成するもの それを選定したのはベンダの責任になる
影島:既知かどうかと同じ話になるのではないか
大手ベンダだとOSS特則が設けられているのが一般的
伊藤:経産省モデル契約にも記載はあるが、「選定したのはユーザです」と責任転嫁している気がする 実態と乖離している
大井:OSSの場合、そのリスクを飲んでベンダが選定したのだからよりベンダの責任が重くなる
伊藤:新たな脆弱性・脅威を知った場合 一般的に義務を肯定するのは難しいと思うが
大井:開発契約と保守運用契約
まず保守運用契約がない場合 信義則条発生するのか? 考えます
影島:無いと思う 請負なら引き渡し・検収後の話 そのための保守契約だと思う
弁護士でも1年後に法改正した場合alert出すのかという話になるし 買い切りならそうなる
伊藤:大きなものだと年単位で時間がかかる 途中で何か見つかった場合
大井:時系列の中で幅のある契約 でも債務の内容は固定しているわけだから、基本的に義務はない
ただ開発中に気づいたなら義務はある
影島:作る義務と説明義務 少なくとも開発契約中なら後者はある 完成させる義務はケースバイケース
伊藤:ベンダからの変更提案を行う義務はあるかも
影島:提案をした上でユーザがいらないと言った場合は責任はない
大井:保守契約がある場合 保守契約の中身によるのではないか
脅威情報を収集して、組み込まれているソフトにヒットした場合 パッチ当てまでの義務が契約に入っていれば別だが
そこまで入っていなければ争いになるのでは
インシデントが発生したら動くという契約はよくある 発生しなければ何もしない
普段から動く契約は金額が跳ね上がるので
影島:ベンダから見たらなんぜこの金額で脆弱性まで全部アラートしなきゃいけないんだとなる
でもユーザからはそのための保守契約
一般論として裁判所は「ユーザは素人だからなんとかしたい」となる傾向はある
伊藤:一般的には「二重の専門性」ということがよく言われるが、セキュリティについてはベンダのみが責任を負う?
大井:発注者・受注者の属性が考慮要素になっている
ユーザがそういう専門性を持っているケースも有る 元請け・下請けの関係のケースや、発注元が大手ECサイトだったりすることもある
裁判所の枠組みに乗ると、ユーザのリテラシーがどう上がったかも関係すると思う
伊藤:セブンペイ事件 セキュリティと利便性はトレードオフとよく言われる
利便性の高さを主張することが抗弁になるのか?
影島:サービス提供者と利用者、ベンダとの関係でだいぶ違うと思う
ユーザに対しては何か補償がないと使い勝手が悪いと思うし、サービス提供会社はセキュリティ要件をきっちり詰めて開発しようとする
詳しい専門家を使ってセキュリティ要件を詰めているところが多いし、それをやらないとユーザが使わない
提供会社とベンダの関係では提供会社のほうがセキュリティ詳しいと思うので問題にならない
大井:ユーザが選択して初めて抗弁ができる ベンダからこの抗弁は成立しない
伊藤:カード不正利用のチャージバックの件 安かろう悪かろうが訴訟上の抗弁になるのか?
影島:可能だと思う 実際に裁判でもベンダの代理をするときはそういう事を言うと結構響く
割とよくある 主張して価値があるやり方だと思う
大井:理屈よりも個別事案の統制を重視するのが裁判所 この値段だったらこのぐらいしかやらないよねという価値判断が先にくる
それで後から理屈付けするのが裁判所の理論構成
伊藤:人月計算でこんだけ高い価格取ってるんだからというところで影響するのかなと思うところはある
Q&A
松尾:セキュリティについてベンダ→ユーザへの説明責任がどの程度必要なのか
一度トラブルが起きてから問題にされる事案と、今なら誰でもやる程度の話、色んな話でごっちゃになって議論されている
文言によって対応する場合は回避できるようなものは?
影島:ご指摘のとおりかなと思う
私のニュアンスとしては何もしなければベンダの責任
ベンダから提案があってそれでもなおユーザが拒否れば、さすがにベンダの責任は問いにくいと思う
大井:Amazonの場合、自社ECの場合等々でリスクの説明義務のレベルは違ってくると思う
北村:情報の属性によって過失なり契約の解釈が変わってくるのか? 個人情報の場合、単なる営業機密の場合など
大井:ご指摘の通り 情報累計で注意義務の解釈は変わってくる
カード情報は不正利用の問題もあるので、一般の個人情報とは要求水準が違う
ベンダ視点からだと若干違和感があるのは事実
小川@IKA:ベンダ側・ユーザ側どちらもちょっとなぁというところがある ふわっとした契約が問題
今度の民法改正でそこをきちんと書く方向に行くのか?
大井:民法改正関係でしゃべること 目的の趣旨・背景をはっきり書きましょう
、それが善管注意義務の解釈要素になったり、債務不履行だったり色んな所に出てくる
詳細スペックを詰めきれないところはよくある
なので契約の目的をはっきりしておけば、詳細スペックを明示してなくても自然と解釈の指針が出てくる
そういうふうに実務を持っていきましょうと思っている
○第9分科会
中澤:司会
神田:明らか要件の話 このときはヤフーに対して検索結果削除しろといった
本件訴訟では、北方ジャーナルとほぼ同じような基準で事前削除しなくていいといった→棄却
これまでやってきた名誉毀損を理由とする削除の判断基準にこの要件が入ってくる→立証困難 非常に削除しにくい
他の件でも「不特定多数の目に触れる機会を事実上失う」「事前抑制」と言われた
大阪高裁判決(5/24)は「事前差し止めには該当しない」と言っているが「重大かつ回復不能な損害」要件を持ち出している
検索結果削除は事前抑制なのか?
「重大にして回復不能な損害」要件はいるのかいらんのか?
清水:ログイン型投稿サイトの場合
プロ責法に従うと、ログインに係る通信は権利侵害そのものではない
どのプロバイダから投稿したのかがわからない(複数ログイン可の場合)
実際にはコンテンツプロバイダはほぼ争わないがISPが争ってくる
条文を素直に解釈すると開示請求は不可となってしまう 実際そういう判断される訴訟も多い
ただ認めないと誰も被害回復できないということで認容例もちょこちょこある
ログイン後の通信を持って「特定電気通信」とする、「侵害に関わる発信者情報」としてログイン時の通信も開示対象とする
投稿直前にログインしていればそれを持ってIPアドレスのISPを介してログインしていると判断できる
海外プラットフォーマー FC2の場合
音沙汰が無いので間接強制を申し立てた
海外法人への正式な送達は半年~1年かかる、そのころには既にログがない
なので米国法のdiscovery手続きを使う
日本にdiscoveryの手続きはないが、外国でそれがある場合に使うのは問題はない(潜脱する意図はない)とされる
過去に接続時のIPアドレスだけでいいんじゃないの?と言われたことはある(ログイン時IPはダメとされた)
discoveryは手続きが軽い、開示対象に制限がない
デメリットは費用が高額 だいたい100万円くらい
増田:インスタのアカウント奪取訴訟
社長がインスタアカウントを後任に引きつかずに辞めた
アカウント引き継ぎ義務の有無 取締役なので委任義務を負っている→引き継ぎ義務ありとなった
損害の算出→民訴法248条 算定は性質上困難なので
確かに個人のアカウントとして取得しているが、会社の業務として取得しているので引き継ぎ義務があるとなった
利用者たる地位は個人Yに帰属する 原審でインスタグラムはメールアドレスを持って利用者を特定しているとなった件に関係する?
普段からYは3つぐらいメールアドレスを使い分けている なのにメールアドレスで認容されるのは?
管理だけでなく地位継承までを認める パスワード開示請求にも理由があるとなった
退任からアカウントが1年3ヶ月間残ったまま、さらにその後で5ヶ月間非公開化
フォロワー数1割減少、売上も3割減った
Yは元ラグビー日本代表、会社自体もラグビー関連のアパレル会社
広告媒体としてこれを更新できなかった期間については財産権侵害として認容できる 投稿できることを財産的利益とした
非公開になると広告媒体として全く機能しなくなる→財産権侵害は明らか
ただ算定は困難なので民訴248条を適用した
裁判所は価値判断をしてから理屈を考えるところがある
現実に発生している損害をどう公平に割り振るのかなという
実損が出てない事案というのは裁判所の理解を得られにくい 1審で負けて高裁行ったとき最初棄却されそうな雰囲気がすごかった
インスタの雰囲気・空気感が伝わりにくかった
地裁では左陪席の方がインスタに詳しかったが、その方が転勤になってから誰も目を合わせてくれなくなった
正直吉本の50万話が出ていればそれ使ったww
吉井:死者のアカウントの引き継ぎ 脂肪により契約は終了する?相続できる?
契約が一身専属かどうか?サービス実態などから考えることになる
契約上相続不可となっている場合でも、譲渡性がある場合は相続が認められる?
預金口座の相続に際し、取引履歴の開示義務まで相続できるか?→できた
委任契約の典型契約だと相続されないのが普通だが、サービスの性質によってはできるものもある
利用規約に書いておけばいいのか? 51社の規約を調べてみた
譲渡禁止規定がない規約も22%あった そもそも譲渡OKのものも
相続禁止規定があるのは約14% 相続OKの規定があるのも4%あった
銀行の口座は通常譲渡禁止なんだが…
おまけ:死人にいろいろ義務を負わせているものがいっぱいある
死亡した日=契約終了とすると、サービス運営側が死亡した日を認知できるの?という話
パネル
中澤:インスタのアカウント引き渡しのときに承継・譲渡禁止が問題にならなかったか?規約上は?
吉井:比較表作ってあるので
インスタは譲渡禁止 ゴニョゴニョ書いてある
増田:規約をみて譲渡禁止となっていたのはわかるが、もともと会社のアカウントだから譲渡ではない、パスワードを教えてもらうのが
引き継ぎ義務だろう 訴訟では争点にはならなかった
もし正面から争点になってたらややこしい話
吉井:パスワードもらってアクセスしたら不正アクセスになる?
増田:これは訴訟後和解になったので、そこは問題にならなかった
吉井:所有名義を根本的に会社と認定してもらうと話が早かった
増田:そこを争点とするとどうかという話ではあった
代表者の個人アカウントはまた別に存在した メールアドレスも会社代表としてのアドレスだったのに
ただし会社ドメインではない
中澤:パスワードの開示禁止規定との関係
こういうトラブルが起きることを想定してアカウント管理するとなるとどうする?
増田:一般的には管理者を限定した上で、SNS管理のためだけのメールアドレスを新たに作成することを勧めている
私物PC・スマホからのログインも禁止にしている
中澤:ちゃんとやらないと危ない?
増田:今回は委任だったので引き継ぎを要求できたが、労務の提供と考えると労働契約が消滅したときに義務として残存するのかと
自分の中でも結論は出ていない 信義則上しか無いんじゃないか
中澤;デジタルプラットフォームが非常に重要なポイントになっている
プロ責で開示請求の場合、逆に(証拠保全のため)削除を制限する決定が出ているように思う
プラットフォーマーの立ち位置が非プラットフォーマーと差が出るのか?
神田:twitterの削除判決 犯罪報道の削除請求 たなかかずや弁護士
twitterとgoogleの違いがいろいろ分析されている
twitterは「情報流通基盤ではない」と書かれている なので明らか要件を付ける必要がないんだという話
長良川事件のような「明らか」要件を付けない基準でやった
清水:googleだと重要な基盤を担っているから削除基準がきつくなる傾向 本当にそうなのかなと
twitterももはや基盤になってるんじゃないのかなと思う
情報が流通しているという状況は基盤だろうがなかろうが変わらないので厳しく判断する必要はないと思っているが、裁判所は総判断してくれない
吉井:情報流通基盤 昔は2ch・爆サイだったりしたけど、プラットフォームとして保護しろと言われなかった
2chは代理人も本人も来なかったので強い判断になってなかった
googleは第人が来て強い主張をするので今のようになってしまっただけ
増田:プロバイダとしては情報流通基盤と直接の関係はない
そういう中間的な概念を用いるかどうかは別として、強い保護を受けるという解釈は民間同士の訴訟だから気軽に使っているだけ
国相手の訴訟にそれが使えるかというとそうはならないと思う
中澤:間接強制の話
実際そこまでやるケースってありますか?
清水:今の所人生で2、3回 ほとんどない
神田:私はgoogle相手に1回やった気がする あまり覚えてない
清水:10万とか30万とか理由つけて出すけど、だいたい1万/日まで減額されることが多い
神田:30とか50万/日が多い気がする ソフバン相手のときは10万/日で出たことがある
中澤:自分は5万/日が最高 個人相手で7000/日というのもある
壇:某社の弁護士としてネットでdisられた壇です クライアントの1社に過ぎません
間接強制のとき どういう送達になるのか?海外送達2回やらんきゃならんのか?公知送達で便利にできない?
清水:自分もそんなに詳しくないので
現状は仮処分決定の送達で止まっていてその先がどうなるかわからない状況
神田:別件でgoogle相手に間接強制だと、1個目は日本の代理人に割とする届いた
2個目は代理人に「受け取れ」と強く言って受け取ってもらったということがある
壇:原則は受け取らなきゃ本国に送るしか無い
神田:今CloudFlare相手の送達やってる知り合いがいるがかなり時間かかっている
私はcloudflareにはsappinaで開示してもらったので早い
壇:日本でsappinaのような手っ取り早い開示をやるならどうするのか良い?
神田:発信者情報をもっと広くとれるようにしてほしい
清水:民事訴訟を匿名で起こせるようになればISPへの開示請求が楽になる
中澤:補足 松戸支部でgoogleの削除やったときは、仮処分は日本の弁護士が受け取ってくれた
その後の間接強制 EMSで試しに送ってみようとなったが無視された 仕方ないのでちゃんと送達した
板倉:立法論としては国内対代理人の問題はある GAFAは登記してないから違法じゃないか?
小倉先生もう帰っちゃったっぽい?
吉井:具体的な動きをすることが重要で、長い時間はかかるかもしれないが継続的にやるのが重要
小倉:法務省には行ってない
Q&A
小倉:吉井先生との関係 契約上の地位を切られる話と、切られた後の精算が発生する話はまた別だと思う
ポイントだったりコンテンツの精算はどう考えてるのか?
清水先生 総務省の政令の作り方が悪いわけなので国賠起こすのはどうか?
神田先生 「重大にして回復困難」の件 どうバランスを取っているのか?
プライバシーの場合は重大ではないというのはわかるが、名誉毀損が「重大じゃない」「回復困難でない」と言われる理由がわからない
犯罪デマ関係で情報流されたときに重大じゃないというのは?当てはめが
吉井:精算の話 今日はアカウントの話だけなのでしなかった
結局は相続の話になる 精算部分だけが相続されるということはある 完全に相続否定の場合はどうなる?
サービスによっては規約そのものが無効化することもありうるのでは
清水:今度検討してみます
神田:認定自体は非常にあっさりしてます 不都合は主張・立証しているんですが
数字にするとこのぐらいの損害ということも言ったがあまり響いていない 家族関係にも踏み込んだのに
何を言っても「重大」と言ってくれないという状態
プライバシーのときにも同じことがあった 具体的な損害を立証しろといわれてもなかなか損害を具体的に言いにくい
主張が足りないと言われてショックを受けたこともあった
かと思えば権利不十分偽装?の場合に 無罪推定のはずなのに有罪と思われる 不利益だと書いたら削除任用してくれたこともある
裁判官がいいと思ったら書くし、削除不要と思ったら…という言い訳要素として使われているんじゃないか
中川:神田先生 事前抑止がおかしいというのが理解できない
Web上まで出続けるというところがある 以降については事前抑止になるが、事後か事前かというのはタイミングの問題
神田:紙媒体で考えると、北方ジャーナルでは事前抑制について具体的に書いてある
検索結果については既に流通している それを削除するのは出版差し止めと同じで事前抑制じゃないだろと思った
なぜ高裁が2つも事前抑制と言っているのかはまさに仰るとおり
ずーっと出ていて、既に読んだ人にとっては事前抑制じゃない まだ読んでない人には事前抑制
図書館に行ってもないじゃないですかというのが事前抑制なのかというと、紙媒体との比較で言えば違和感がある
事前・事後抑制ってインターネットではあまり意味がないのでは
松尾:増田先生 損害の軽減義務
だったら新しいアカウントを作ってガンガン宣伝すればいいのではという考え方もある
増田:実際その主張はあった
インスタの仕組み上、アカウント名が先に取られてるとちょっと後発側が間抜けになる
なぜ2つアカウントが並び立っているのか それ自体がマイナスイメージになる
フォロワーは一から築き直しだし、会社の宣伝効果ではなくある程度価値があるアカウント自体を更新できなかった
それを損害として捉えているので、そこを軽減するのは無理じゃないかと思っている
○第11分科会
藤村:このセッションは写真撮影自体NGで
板倉:総論として
情報法制研究で連載しているもの 総務省資料のダイジェスト
プライバシーに関する契約 いろいろあります クオリティも様々
明らかにライバル企業のものをパクっているものもあるが、内容はだんだん良くなっては来ている
理論的分析は連載でやってます
例えば楽天 一定の水準にはなっている(BCR取ってるので)
利用規約と保護方針、セキュリティ(国外への移転の話)
BCRは取ってるものの、他の国に移転するかもしれないので包括的に同意を取っている
その文字を読んでいるとは思っていないので、たくさん図を作って実効性のある同意を取れるようにしているんだと思う
保護法上の同意ってなんなのか
閣議決定で記載がある 事業者が直接縛られるわけではない
総務省の電気通信ガイドラインの中に条項がある プライバシーポリシー等で本人が容易に知りうる場所に置く必要がある
今度PPCのガイドラインに戻ってきて TOPページから1Hop程度でアクセスできる場所に置け
通知・公表はわかるが、できれば同意も取っちゃいたい
楽天の場合は保護方針が利用規約にincludeされている
医療関係のガイダンスではプライバシーポリシー内で第三者提供について書いていいんじゃないかと言っている
ヤフーもプライバシーポリシーに第三者提供入れている
総務省ガイドラインでは約款に置いて個人情報の第三者提供について同意を得ることができるとしている
有効じゃなと行けないので詐欺・錯誤・消費者契約法違反の場合はアウト
個人情報保護法上の同意は公法 契約の同意は民法
意思表示とはなにか、同意ってのは意思表示? 委員会がそう言ってるからそうだとする
公法上の意思表示に民法の意思表示が適用できるのか?→だいたい準用されるというのがふつう
海賀:ヤフー 永田町・霞が関対策部 政策企画部
プライバシーポリシーの改定(10/1)について
2018/1/24 ヤフーの社長交代「データの会社を目指す」
データソリューション事業の話 大前提としてプライバシー保護は第一
CDO/DD体制、アドバイザリーボード、
Chief Data Officer、Data Director体制 CISOとセキュリティ責任者もいる
プライバシーポリシー改正、グループ企業のデータ連携強化
グループ連携はデフォルトoff、専用のコントロール機能も設けた プライバシーセンター
動画を作成してそちらで説明している
同意とコントロール 明示的な同意 アプリでモーダルウィンドウ出している
プライバシーに配慮した設計 グループ連携にあたって各社にもCDOを置いている
個人データよりも広いパーソナルデータの保護を行うように、氏名や住所は直接取り扱わない
グループ企業から別グループ企業へのデータ提供は禁止(2hop規制)
加藤:NTTドコモ デジタルマーケティング推進部
社内でデータガバナンスとよんでいるもの
会員基盤をベースとした企業戦略 dポイントクラブ
プライバシーポリシー 12/1から新しいものを適用開始予定
事業分野ごとのポリシーを個別に制定していた ユーザにとってわかりにくいし運用も難しいので一本化した
プライバシーポリシーの上位規定としてパーソナルデータ憲章というものを作った
6つの行動原則
パーソナルデータダッシュボード作りました
情報処理学会に連名で論文出してます
社内でサグラダファミリアとよんでいる 継続的に改善をこなっていくもの
2018/5から社内PIA制度を設けた プライバシー影響を評価するために助言を事業無にfeedbackする
個人的な問題意識
notice and concent(通知・同意)のメカニズムは壊れているのではないか?
4年前から実質一人プロジェクトで動いていたのが出発点
同意(consent)の反対は不同意(dissent)ではなく驚き(surprise)ではないか
予測可能性を超えた範囲での利用になると怒り・不安に変わり顧客満足度を低下させる
必要なことはこのような驚きを低減させるためのUI/UX
利用規約を延々読ませて同意させるのをドコモでは「マニ車」と呼んでいるww
顧客ごとに同意の範囲が異なると、当然提供できるサービスもユーザごとに異なる
それを仕組みとして作り込んでいかないといけない
選択の自由度と手軽さはどうしてもトレードオフになる
複雑に制御できるようにしてもそれを使いこなせるようになるのは難しい
AI/IoTは人間には想像もつかない驚きを与える存在、そことどう向き合っていくか
data protectionからdata empowermentへ ユーザテストを繰り返しPDCAを回していくことが必要
関原:LINE プライバシーカウンシル 社内コンサルの仕事してます
プライバシーポリシーを最近変えたというところはない
サービス・機能を追加する場合はPIAを行っている サービス開発開始前の企画段階でPIAをすることになっている
法律上適法だからといってプライバシー上問題がないとは言い切れないのでそのあたりも確認する
開発が始まった後にlegalチームから指摘が入ると手戻りが発生したりする、リリース直前だと対応自体が難しいことも
どんなに適法だったとしてもユーザが気持ち悪いと思うサービスは受け入れられないので、それもPIAで指摘する
利用者同意 通信の秘密もクリアしないといけないのでその同意も取得する 基本オプトインだしいつでもオプトアウトできる
行政関係・警察関係の開示請求についてはtransparency reportを出している
藤村:施策を始めるに当たってのトリガ それは何だったか?
海賀:保護法の3年ごと見直し、あとGDPR/CCPAは大きかった
全く影響なかったということはない ただyahooスコアの教訓、パーソナルデータを使う際にユーザへの説明責任は果たさないといけない
不足した情報しか公開しなかったことが炎上した原因
設計自体はいろいろな不合理な差別とは別に、新たな指標をユーザのメリットとなるように使っていただきたい
企業を契約でそういうように拘束するつもりだった
ユーザにとって不利益になることがないように作り込むことをやっていたのにlean系のプレスリリースだけを打ってしまったので、ユーザに不安を与えてしまった
当たり前のことをしっかり説明する 何度も説明責任を果たすことで有言実行でやっていきたい
藤村:スコアで炎上した後、プライバシーポリシー改定までフットワークの軽さがあるように見える
前々から予定していたのか、それとも急遽改定したのか?
海賀:もともと考えていたものはあったので、批判を受けて対策したところもある
炎上は色々経験しているのでfiremanは多い 対応は軽かった
加藤:きっかけは外的要因はあまりない 4年前にデータ活用の取り組みをやっていたとき ビッグデータ流行り
どの範囲でデータを活用できるのか 利用目的は読めるのかとか、同意は有効なのかとか
社内でもこれちゃんと運用できるのかとか 運用が回らなくなるという危機感を持ったのがきっかけ
あっちこっちの部署でこれできる?できない?が詰まってしまってスピード感がなくなる
社内でこれを理解してもらうのが大変
データを活用する事業部だけでなく管理部門から「寝た子を起こすな」と言われる
正直なんかあったときのほうが早く進むww
ここまで持ってくるには相当時間がかかった ぶっちゃけヤフーにはあっさり抜き去られた
藤村:どういう部署とどういう調整が大変だったか?
加藤:活用したい人たちからは「今までできてたことができなくならないよね」と詰められた
法務・セキュリティからは、規約等の文書に書かれてたことが本当に理解されていたかわからない
グレーなものがすごく大きかった 結局萎縮することにつながるがそれだとジリ貧になる
利用目的がユーザに読まれているのか グレーなことに向き合わないといけないのでPIAやろうぜと言ってきた
そこは自問自答しながらやっている
関原:ユーザに対してわかりやすく変えるというのが要因ではないかと思う
ある程度包括的な定めになっているときに、新サービスが入ってきた場合、より具体化するために変更してるんじゃないかと思う
通知公表義務との関係できっちり書く必要はあるが、対ユーザ関係ではそこだけ書いても足りないとは思う
自分もほとんどポリシーは見ない人間なので
UI/UXはすごく大切だなとは思っている ユーザ側の視点を認識することは大切だなと思っている
藤村:現場との意識のギャップ そういう観点があれば
関原:うちも結構炎上したので
開発の人たちもセキュリティがこういうのが必要というと理解はしてもらえる
違法なのか分かりづらいケース 名前やクレカ番号はある意味わかりやすいからやばいとすぐわかる
例えば識別子とか裏側のメタ情報も内容によっては保護法や通信の秘密に引っかかってくる
社内から「こんなんも個人情報なんですか」と言われるケース
通信の秘密だと若干スコープがずれるのでメタ情報なんかが引っかかるケースも有る
海賀:プライバシーに関する よそのデータを扱う会社 どうやってマネージメントに理解してもらえたのか
あとどうやって全社に周知していったのか
加藤:数年前から叫び続けていたがほぼ相手にされなかった 重要性はわかってくれるが「ほんとにやれんの?」と言われた
役員に打ち込んで社長からやれとトップダウンでおろした それがなければここまで来なかった
関原:私は入社したのが最近で、既に体制ができていたのでよくわからない
体制をしっかり作るのが大事かなと
PIAレビューしないとリリースできないとルールを決めて、それをマネージャー単位で下に共有してもらう
必ず研修でリテラシーを上げていくことが大事
板倉:GDPRのDDOは「あらゆる社内のデータの動きを把握しろ」と言っている
日本だと委員会でやったりしている
ある会社だとそこが完ぺきにできていて驚いたら「ここまで15年かかりました」
これどうやって横展開する? IIJはプライバシーコンサルやってる
弁護士が見れるのは全体ではない 他大丈夫かなというところがある
トップマネジメントや全体の仕組みづくりはできないので
加藤:PIAをやったりするノウハウをどうやって積み上げ・継承していくか
最初手探りで始めた部分もある
ドコモも何度か批判を浴びたことはあるので、過去に経験した人はPIAである程度考慮して持ってくる
PIAのボードメンバー いろんな部署が入ってやるが、その人達がきちんと情報を共有しているかというとまだこれから
バランス良く社内の業務を理解してないといけないが
海賀:我々もそこの課題に直面している 業務が属人化してしまって、温度感が伝わっていかない
ノウハウを継承できる仕組みを作っていかないといけない
CDO/DD体制もその一つだが、さらに法務、政策企画部、CS、広報が集まって諮問機関を作って議論している
PIAというほどではないが知見を集めて共有するような体制にしている
関原:ノウハウ的なところ 考えられるのは専門部署を作ること
legalで全部法律を見ていると、細かいところまでは見れない
知識に濃淡がどうしても出てくるところはあるので、フローチャート作ったりチェックリストとかは一つの手法
藤村:横展開は各社共通の悩み 社内展開と組織を超えた共有問題の2つがある
関原:プライバシー的に各社がどう検討しているのか
もともとは弁護士だったが、どうしても適法か違法かに目が行きがちで、それ以外のプライバシーまで検討したことがない
インハウスになるとプライバシーはかなり悩ましい
あまり法律に詳しすぎても感覚が麻痺してくるし一般人とずれてくる
ガイドラインがないところで各社がどう評価しているのか
加藤:一番難しいところかなと思っている
適法なのは当たり前として、だからといって真っ白ではない どうしてもイノベーションなところはわからない
法律すれすれを狙うとかじゃなくて、事例の蓄積がまだまだ必要なのかなと思っている
本音を言うと会社を超えてシェアしたい
ドコモのユーザも当然ヤフーやLINEのサービスは使っているので協調領域だと思っている
ユーザ視点から見るとなんか共通的なところじゃないかなと
オープンな議論ができるところを増やしたい
海賀:法務が判断すると炎上するというところはある それだけだと片手落ち
ただ自分も企業内弁護士なので法務の立場では「適法だけどやめてください」とは言えない
なかなかケースバイケースというところはある
最近の問題意識としては、個人情報保護とプライバシーがずれてきている
これまでは個人情報を適切に取り扱っていれば適法で問題なかったが
適法だったとしてもプライバシー上問題なところ PPCから勧告受けたところなんかがいい例では
ユーザの同意に依存していくのが限界に近いところに来ているのではないかと思っている
ユーザはプライバシーの保護のためにうちのサイトに来てるわけではない 同意疲れ問題というものもある
サービスの手軽さも重要
藤村:3人とも法務の部署じゃないんですね プライバシーが法務じゃないところでびっくりした
Q&A
ながい:プライバシーポリシー改定、体系見直しの件
普通の事業と金融・クレジットなど特殊分野
まだ官庁系のがいどらいんとかで調整苦労したりしたところはあるか?
海賀:横出しの部分は苦労する 特に通信の秘密と金融
通信の秘密は絶対守る部分なのでデータ連携にも入れていない
金融庁の別個の温度感があるので基本的に除外している
加藤:そこは一番苦労したところ
そもそも3つポリシーがあったのは主務大臣制時代の名残 ?・通信・クレジット
今でも凸凹しているところはある 相当エネルギーをかけて専門家に意見を聞いて今の形にした
これだけで数ヶ月かかっている
板倉:UI/UXを作るのがすごく大変だと思うがその手順は?
facebookは急にUI変わるので多分実験していると思う
ベンチャーの場合は「お母さんに見てもらって」と言っているww
加藤:手近でNDA範囲内の方に試してもらうぐらいはやっているが、PDCA回すには何かつくらないといけない
一般ユーザ・専門家含めて回していくには、googleだとプライバシーエンジニアってのがあるが、ああいう体制を作らないと
海賀:きちっとした体制はできていないし、いきなりABテストは難しい
アドバイザリーボードで意見を伺うこともしている
社内だと感覚が麻痺してくるので、漏洩しない範囲でやはり「母親に聞け」はやっている そこは同じ
関原:アプリチームがプライバシーのエンジニアリング的なところを見ているので、legalとは違った観点の意見を聞ける