パスワードを忘れた？ アカウント作成
Close
5209 story
ニュース

プライバシーポリシーには何を書いて欲しい？ 74

ストーリー by Oliver
書いたら覚悟して守れ 部門より

jbeef曰く、"例えばスラッシュドットのトップページには、「プライバシー」というリンクがある。スラッシュドットにおける個別ポリシーが書かれているのかなと思うとそうではなく、「OSDN Japan各サイトおよび関連サービスの利用により発生する個人情報の利用法」とあるように、OSDN Japan全体のポリシーだ。組織全体のポリシーをひとつの文書にすると、一般的に書かざるを得ないわけだから、「ことがあります」、「可能性があります」というように抽象的になってしまうのはやむをえない。
もし、サービス個別のポリシーを分けて書いたなら、もっと明確に書けるところもあるのではないか。例えばcookieについて、ユーザはクッキーを無効化できるがそうすると「正常に機能しなくなる可能性があります」と説明されている。ここは具体的に「ログインができなくなる」と書けるだろうし、また逆に、バナー広告業者がやるような個人追跡のためのID発行（ログインしていないときにも及ぶ）は行っていないことも明記してよいのではなかろうか。
でも、プライバシーポリシーってどういうふうに書くのが模範的なんだろう？ そこでみんなに聞きたい。（スラッシュドットに限らず）プライバシーポリシーにはどんなことを書いて欲しい？"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

プライバシーポリシーには何を書いて欲しい？ More

  • スラッシュドットに関して言えば (スコア:4, 興味深い)

    by witch (3127) on 2003年03月10日 13時23分 (#275853) 日記
    今回の「スラッシュドットに聞け」は、スラッシュドット自身も含んだ話だと思うので、コメントしてみます。

    スラッシュドットの場合、サイトに関わる人間が
    ・システム管理者
    ・システム運営者
    ・編集者
    ・ユーザ(アカウント保持者)
    ・ACユーザ(アカウント保持者)
    ・AC(非アカウント保持者)
    と多岐に渡っているので、大変だと思いますが

    ユーザ情報に対する管理者、運営者、編集者それぞれのアクセス権限、
    および例外発生時のアクセス手順(AC発言の本人情報開示など)を明確にして欲しいと思います。

    また、システム的にどこまでユーザをトラッキングできるようになっているのかなどの開示も欲しいです。
    ( これは開示されている Slashcode のソースを読めばできるのだと思いますが )

    ここで言う「ユーザ情報」として思い付くのは
    ・アカウント保持者の個人情報(非開示のメールアドレスなど)
    ・アカウント保持者のアクセス履歴(時刻、IPアドレスなど)
    ・AC発言がアカウント保持者か非アカウント保持者かの情報
    ・アカウント保持者が行ったモデレートの結果
    ・アカウント保持者が行ったメタモデレートの結果
    ・削除された日記エントリ
    などです。

    現状では、これらの情報へのアクセス権限がどうなっているか判らず、個々人の憶測や不確かな情報が錯綜していると思っています。

    できれば、ここに挙げた項目のいくつかだけでも、開示して欲しいと思っています。

    • 詳細にリストアップしていただいたのでお答えします。全部リストアップしろ、といわれたら必ず抜けがでますが、具体的にこれっ、と聞かれるととても答えやすいです。その前にひとつだけ意見を：

      セキュリティ「ポリシー」。他のコメントで言われている様に、まさしく「憲法」みたいなものです。自戒もこめ、やるつもり、絶対にやらないつもりの事を書きます。なので、軽々しく変えていいものではないと考えています。個人情報取り扱いの現状報告でも履歴でもなく、指針なのです。例としてはクッキーはユーザの利便に関係する機能の実装にのみ使われており、そこでユーザ追跡を行っていないことが明らかになればよい、と私は考えています。具体的になにが使えなくなるのか、は少なくともポリシーの範囲ではないはず。

      では、肝心の答えを。/.-Jにおける個人情報には保存およびアクセス方法によって、3種類あります。

      • ウェブサーバのログを見ないと載っていないもの。生IPやReferer、使用ブラウザ。システム担当は物理的に見ることができ、デバッグ等に使うこともある。私もサーバ上で格納場所探せば見られるはずではあるが、見たことないな。一般的に参照されるものではない。統計として一般的な要約ツールを使ってすごく要約した資料は存在する。
      • DBに溜っているもの。コメント等で特筆すべきは投稿者のIPをハッッシュ関数に通したもの(IPID)が記録されることかと。IPIDから生IPは総当たりでないと復元不可。モデレータが投稿した際にそのモデレーションを取り消したり、時間単位あたりの投稿数制限などに使われる。その他はSlashcodeのDBスキーマ [slashcode.com]を参照。システム担当だけが物理的にみられる。自分が理由あって要求すればDBを直に叩くための認証情報をもらえるでしょう。が、その必要を感じたことはない。
      • ウェブのUIから参照できるもの。DBに含まれる情報の一部。全ユーザが見れるもの、本人だけが見れるもの、全編集者が見れるもの、管理者(基本的には私およびシステム担当)のみが見れるもの、とさまざま。

      通常は一番下のアクセス方法しか使われず、メンテや自動で集計されない統計を処理するのにしかDBは直接は触られていない。ログも直に見ることはない。物理的に可能だからといって、するわけではない。では、上で懸念の点について個別回答を。：

      • アカウント保持者の個人情報(非開示のメールアドレスなど) ：非常時の連絡手段ということもあり、管理者はユーザが見る自分の設定ページと同じものが見える。メールアドレスをtypoしたという連絡の対処もここで行う。
      • アカウント保持者のアクセス履歴(時刻、IPアドレスなど)：たしかDBにはクッキーと認証情報の保存と関係して、期限管理の為に最終アクセス時刻が保存されているはず。管理者むけのインタフェースにはそのユーザが最後に使ったIPID数個(生IPはよほどの手間をかけないと復元不可)が表示される。本当に必要ならば、特定のIPIDをバンする仕組みはあるが、使おうと思ったことはない。
      • AC発言がアカウント保持者か非アカウント保持者かの情報：DBには保存されない。ApacheのログとDBの情報をつきあわせるべくがんばったり、記録されたIPIDで行われた他のコメントを探せば推測は不可能ではないかもしれないが、動的IPやプロキシーは排除できない。そこまで手間かけるんだったら、ほぼなんでもできてしまうし、そこまでする理由はない。
      • アカウント保持者が行ったモデレートの結果：タイムスタンプ、対象コメント、値とモデレータが記録されている。M2や結果通知等に使われる。普通、コメントを単体表示(スレッドやネストではなく、コメント番号をクリックして一個だけ表示)した時にモデレーションの内訳が表示される所に編集者だとモデレータのアカウント名も表示される。アクティブに監視してはいないが、異常であると連絡があった時や不自然に感じた時にマイナス荒しや複数アカウントによる自己モデレーションのチェックができる。普通にコメントを読むぶんには表示されない。というか、必要以上にそんなこと知りたくない。
      • アカウント保持者が行ったメタモデレートの結果：DBにはタイムスタンプと対象M1とモデレータが記録されるが、UIを通じてはアクセスできない。せいぜい、毎夜の統計メールでM2が何回おこなわれたか知らされる程度である
      • 削除された日記エントリ：[調べるのにコードひっくりかえした] Journal.pmでたしかにDBからも削除されてます。巨大なバックアップ用のダンプで、たまたまそのエントリが含まれているものがある可能性は否定はできません。

      ACでの発言に関しての開示要求があった場合に、開示できるのはIPIDと、苦労すればもしかしてApacheのログと組み合わせて生IPが復元できるかもしれません

      シェア
      親コメント
    • 過去のOliverさんの発言によると、

      ・AC発言がアカウント保持者か非アカウント保持者かの情報

      「IPアドレスのハッシュ値がIPIDとして記録されている。…身元情報の再構築は不可能ではない [srad.jp]」が、面倒くさいのでとてもやれないらしい。

      ・アカウント保持者が行ったモデレートの結果

      「 モデレーションは無記名式だが、決して匿名ではない。俺がみると、誰がモデレーションしたのかはっきり表示される。 [srad.jp]」

      あと、yourCatさんの発言によると

      ・アカウント保持者の個人情報(非開示のメールアドレスなど)

      「わたしにはユーザーのIPアドレスはおろか、登録メール・アドレスだって公開されていなければ分かりません。 [srad.jp]」

      このほかに編集側からの情報はみつかりませんでした。
      シェア
      親コメント
      • superdimension A K さんがリンクされた発言で網羅されていると思います。

        …が、
        これが、運営者や編集者の日記に書かれるのではなく、プライバシーポリシーに書かれているべきではないか

        と思うわけです。

        「非営利のシステムだし、嫌なら使わなければいいんだから、どうでもいいじゃん」

        と、言われればそのとおりですけどね。
        シェア
        親コメント

  • シンプルで明解なものが望ましい (スコア:2, すばらしい洞察)

    by SS1 (6823) on 2003年03月10日 13時07分 (#275846) ホームページ 日記
    シンプルで明解なものが望ましいのは当然のことだが，それを部門別，サービス別に分けると，結果として，ポリシーを守ることが困難になるんじゃないかと思う。

    守るべきことをたくさん書くよりは，守れる限界を正しく提示することが，利用者が利用法を考えさせる材料になる。すくなくともできない約束をしちゃいけません。
    --
    斜点是不是先進的先端的鉄道部長的…有信心
    • あれはごちゃごちゃ書いてるのは運営側に都合の良い事をこっそり書いておいてそれが目立たないように沢山色々長ったらしく書くものだと思うのですが、いや、本当に必要な事を必要なだけ書いてる企業様もいらっしゃるのでしょうが、大体がそうなのではないかと思うのは私の偏見かも。

      そしてま
    • サービス別に全く違うポリシーなら守るのは困難だろうけど
      タレコミ文の通りサービス特有のポリシーを個別に設定するのは分かりやすいと思う

      要はポリシーもOOPの継承やら仮想関数を駆使してプログラミングできるのではないだろうか
      プログラマにとっては難解な条文風な記述よりも理解しやすいだろうし

  • 順序として (スコア:2, すばらしい洞察)

    by harux (9573) on 2003年03月10日 13時35分 (#275859) ホームページ 日記
    理想的には、プライバシーポリシーが先にあって、後に個別のサービスがあるのだと思います。
    各個別サービスごとに「クッキーなしではログインできない」とか詳細なポリシー項目を決めるというのはできないのじゃないのかな。
    サービスのシステムが変わったら、ともなってすぐ変更されるようになってしまいますしね。

    たしかに、技術的詳細は欲しい気はしますが、あくまでも技術的詳細であって、ポリシーではないでしょう。

    • Re:順序として (スコア:1, 参考になる)

      by Anonymous Coward on 2003年03月10日 17時12分 (#275955)
      同意

      実装に合わせてポリシー（方針）を変えるという発想がおかしい。
      プライバシーポリシーなんてのは、そのサイトの憲法のようなもので、変えてはいけないとは言わないが、そう軽々しく変えるべきじゃないと思う。
      （システムの実装に合わせて）軽々しく変えられるという事は、「個人情報は一切第三者に開示しません」というポリシーを、ある日突然「個人情報は全部金に換えます」というポリシーに変えちゃうってのもアリでしょ？
      プライバシーポリシーなんて、そう毎回アクセスする毎に確認するようなもんじゃないんだから、簡単に変わってしまうようなものだと存在意義が無い。

      シェア
      親コメント

  • 収集した個人情報をどのように利用するのか、というのを明示してあれば解りやすいと思います。

    たとえば/.jのプライバシーポリシーには

    マーケット分析やサービス評価、計画および他の目的で使用する可能性があります。

    とありますが、「可能性がある」というだけでは使うのか使わないのか判りません。

    OSDN Japan全体としてのポリシーであるなら、各種サービスのうちどれか一つでも使用しているのであれば「他の目的で使用します。」と断定して書いていただきたい。

    同様に「～することがあります」というのも、どのような条件を満たすと「～される」のかが判りません。条件も記載していただければ、と思います。

    • するつもりであっても実現の機会がない場合はしてないわけで、文字通り"可能性"にすぎない。
      "する"と断定する場合は義務になりますんで。しなかった場合に問題が生じるかどうかは別として。
      だからこの場合はこれで適切なんじゃないでしょうか。

      それよか、"および他の目的"が怪しい。
      いいかえれば、何でもアリってことで。
      --


      # ACなのでAC
      シェア
      親コメント

      • Re:可能性は可能性 (スコア:1, 参考になる)

        by Anonymous Coward on 2003年03月10日 18時15分 (#276002)
        > するつもりであっても実現の機会がない場合はしてないわけで、
        > 文字通り"可能性"にすぎない。

        もっとごちゃごちゃ書けばいいんですよ。

        「したいです。（XX年XX月現在はまだしてませんが、）」
        「します。（XX年XX月頃を目標に、）」
        「していました。（XX年XX月に一時的にやめています。）」
        「するかも。（予定はありますが実施時期の目処が立ちません。）」

        多少文章量は増えても、ユーザには伝わりやすい、かな？

        > それよか、"および他の目的"が怪しい。
        > いいかえれば、何でもアリってことで。

        「ユーザの不利益になる可能性を否定しきれない他の目的」
        と書き換えるのが実態に即しているんじゃないかと。
        シェア
        親コメント

        • Re:可能性は可能性 (スコア:0)

          by Anonymous Coward
          「ユーザの不利益になる可能性を否定しきれない他の目的」
          「不利益」と感じるかどうかが人それぞれですからねえ。運営者側がそう言っても、何のことを言っているのかわからないのでは。。。

    • いっその事 (スコア:0)

      by Anonymous Coward
      「/.j に登録されているすべてのデータは、必要に応じた様々な利用を行う可能性があります」 と書けば一行で済む？
    • > 「可能性がある」というだけでは使うのか使わないのか判りません。

      分かりますよ。
      使うんです。今のところ予定が無いだけ。

      > 同様に「～することがあります」というのも、

      するんです。今のところ予定が無いだけ。

      # 多分な

      • 私の表現が悪うございました。

        「可能性がある」というだけでは、使っているのか使っていないのか判りません。

        #275921 [srad.jp]のコメントで書かれたような記述では結局「可能性がある」というだけでどういう時に情報が利用されるのか判りません。

        そもそも「することがある」「可能性がある」と、曖昧に記述する必要があるのでしょうか。

        シェア
        親コメント

        • Re:何をして、何をしないのか (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2003年03月10日 17時50分 (#275983)
          ＞そもそも「することがある」「可能性がある」と、曖昧に記述する必要があるのでしょうか。

          もしも、はっきりと「この情報は使っている」「これは使っていない」
          と書いてあった場合、サービスを追加するたびに、
          あるいはサービスとして見えなくても内部的な処理が変更されるたびに
          セキュリティーポリシーが書き換わるんですか？
          bee さんが欲しいのはポリシーではなくて個人情報利用状況なのでは。

          ユーザの許可無しに、セキュリティポリシーを書き換えるような
          サービスを追加するな、ということであれば、
          今後のサービスの展開にかなり重大な影響を及ぼしますよね。
          普通の企業なら、そこにはある程度の自由度が欲しいものでしょうね。
          シェア
          親コメント
        • 確かに曖昧に記述する必要はないですね。むしろ、曖昧に記述しない方がいいと思います。

          現段階で収集した個人情報どの用途に使っているか明記しちゃって、他の用途で使う予定がないのであれば「他の用途では使わない」と明記しちゃった方がいいと思います。

          もっとも、将来なんかの都合で使いたくなったときは事前に告知した上でプライバシーポリシーを変更すればよろしいかと

          まぁ いろいろと面倒ではあると思いますけどね
          シェア
          親コメント

          • Re:何をして、何をしないのか (スコア:1, すばらしい洞察)

            by Anonymous Coward on 2003年03月10日 18時17分 (#276004)
            同感です。

            プライバシーポリシーは免罪符としてではなく、
            ユーザの信頼を得るための約束として設定して欲しい。
            シェア
            親コメント

  • 長けりゃ良いってモンじゃない（激しくオフトピ-30の (スコア:1, 興味深い)

    by Anonymous Coward on 2003年03月10日 16時24分 (#275936)
    長くて良いのはテロメア [nikkei.co.jp]だけだ（1000年分あったら困るけど）

    端的に「私達は誰が見に来てるかなんて気にしません・調べもしません」と書いてあるのを見てみたい気がします
    というより10行も書いてあったら、７割は拾い読みばかりで最後まで読まずに済ませ、
    50行もあったら、9割以上は最初の3行も読まないような気が…

    ＃「読んでますか？読んでませんとも」

  • クッキーの説明には変なのが多い (スコア:1, 興味深い)

    by Anonymous Coward on 2003年03月10日 18時13分 (#276001)
    「クッキー 小さなテキスト」で検索 [google.co.jp]とかしてみると、変な説明が多いよなあと思う。

    あと、日本企業ではこういうのが多い。 NTT東日本 プライバシーポリシー [ntt-east.co.jp]:

    クッキー（Cookies）は、お客様が東日本電信電話株式会社公式ホームページに再度訪問された際、より便利に当サイトを閲覧していただくためのものであり、お客様のプライバシーを侵害するものではなく、またお客様のコンピューターへ悪影響を及ぼすことはありません。 インターネット閲覧ソフト（ブラウザー）の設定により、クッキー（Cookies）の受け取りを拒否することも可能ですが、その場合でも当サイトの閲覧に支障を来すことはありません。
    「クッキーには悪い噂があるけど、とにかくクッキーはそういうものじゃないから俺を信じて安心しろ」ってこどだよね。
    これ書いた人がクッキーがどういう働きするか理解しているかすら疑問。

    「クッキー お客様のプライバシーを」で検索 [google.co.jp]

    • Re:クッキーの説明には変なのが多い (スコア:1, 参考になる)

      by Anonymous Coward on 2003年03月10日 19時03分 (#276027)
      これ [asahi.com]なんかマシなほうかな？
      ちょっと長すぎて読まないよ、ってひともいるかも。
      シェア
      親コメント
      • なかなかいいですね。特に以下のあたり。
        技術的には、クッキーと会員登録情報との組み合わせにより、個人別の閲覧履歴を把握することも可能になりますが、asahi.comでは、会員の皆様にお断りなく、そのような使用をすることはありません。
    • 「クッキーには悪い噂があるけど、とにかくクッキーはそういうものじゃないから俺を信じて安心しろ」ってこどだよね。

      ええ、書かれている内容が充分であるかとか、内容を世間の常識と照らし合わせたときの問題の有無とか、表現は紛らわしくないかとかいったこととは関係なく、プライバシーポリシーって「（信用していただきたいので明示しますが）うちは何々をこのようにしてます」というものだと思いますよ。

      で、あのNTT東日本のプライバシーポリシー（親コメントを参照）の文章って、「クッキーとはなんなのか」を説明しているわけではなくて、「東日本電信電話株式会社公式ホームページにおけるクッキー（Cookies）の使用目的は...」とかなんとか書くのが適当なところを「クッキー（Cookies）は...」と書いてしまっただけじゃないですかね。ですよね。で、思ったんですけど、

      これ書いた人がクッキーがどういう働きするか理解しているかすら疑問。

      この疑問って、「クッキーという技術を理解している人が書いたかどうか」「NTT東日本のサイトでのクッキーの用途を把握している人が書いたかどうか」「好ましくないクッキーの使用法の実態と、それゆえに多くの利用者がもつ不安、それらを理解している人が書いたかどうか」...のいずれなのかよくわかりません。それとも、それぞれを踏まえてあの文章を書くべき、ということでしょうか。

      シェア
      親コメント
  • というのはダメですか。

    正直言って普通はあまり読まれないと思うので、いっそおもしろおかしく。

    だからと言ってFlashだWMP9だと特定環境に依存したページになると困るけど。

    「クッキーなんてのは飾りです。」
    「セキュリティって言いだいだけちゃうんかと。」
    「中の個人情報も大変だな。」

    ...やっぱり、嫌かも。
    --
    Just a whisper. I hear it in my ghost.

  • 意外と (スコア:1)

    by ill (3048) on 2003年03月12日 14時11分 (#276970)

    「私どもを信用しないで下さい」というのが良かったりして;)

    --
    っと・・・。

  • タテマエとホンネ (スコア:0)

    by Anonymous Coward on 2003年03月10日 12時49分 (#275837)
    ＜s＞＜/s＞や＜!-- --＞でいいから本音のプライバシーポリシーをそっと教えて -> システム担当者

    # 実務が伴わない政治判断で形式だけのプライバシーポリシーを立てている企業を知っているのでAC

    • Re:タテマエとホンネ (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2003年03月10日 14時36分 (#275895)
      客が増えてカスタマサービスの工数が減るならどんなポリシーでも…

      サイト運営者から見たセキュリティポリシーなんて、ほとんどの場合
      • 客がポリシーを読んで引かないこと（いきなり「完全に無保証」とかでは…）
      • ポカをやってもなるべく訴訟にならないこと、または訴訟時に有利になること
      がその目的になるんだろう。

      例えば、裏の解釈ができるような、抜け道のあるセキュリティポリシーを作っておく。
      最初は客を安心させておいて、ある程度ユーザが増えたら急にユーザの個人情報を…
      なんてことは、ある程度の規模を持ったサイトではありえないだろう。
      シェア
      親コメント
    • タグがテキスト化して出ていたページなんてありましたね。

      ># 実務が伴わない政治判断で形式だけのプライバシーポリシーを立てている企業を知っているのでAC

      プライバシーポリシーの方が修正されるだけでしょう。
      その時はここにタレコミすればプライバシーポリシーが修正されるかもしれませんよ。

  • 真面目にやるなら免責条項はしっかりと (スコア:0)

    by Anonymous Coward on 2003年03月10日 13時57分 (#275879)
    真面目に不特定多数を相手にするのであれば、免責条項はしっかりと解りやすく明示しておいた方が良いかと思われます。
    トラブル避けになりますから。

    それでもまあ、トップページに堂々と書いてあったとしてもこの頃多発気味の俺様ユーザーにはどの程度効果があるかは疑問ですが、真っ当な不適応ユーザーは避けてくれる筈なんで。

  • サービス個別のポリシー？ (スコア:0)

    by Anonymous Coward on 2003年03月10日 14時43分 (#275900)
    それはすでにスタンダードなんじゃないのか？

  • なかなか守られないけど必須だと思う一言 (スコア:0)

    by Anonymous Coward on 2003年03月10日 18時00分 (#275993)
    「嘘をつきません」
    という記述が欲しい。
typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人