  |
はてなキーワード: ホワイトリストとは
http://anond.hatelabo.jp/20131106001822
社会制度を維持するために、緩慢な自殺とみなせされる行為が全て禁止された国家。
浪費は経済的自殺につながるとされ、ホワイトリストで許可された品を規定の量以下でしか買う事ができない。
ストレスを過度に貯める事も許されず、適度な運動や睡眠、日光浴が義務。
それでも自殺しようと思うものは、投薬によりその意志を奪われる。
息苦しい社会から逃げ出す唯一のチャンスが、国立安楽死センターの利用券。
年間３万毎発行されるが希望者の方が多く、公平を期すために入札制になっている。
遅くなりましたが、広告を消す方法の情報をありがとうございました。
いろいろ試しましたが、Adblockは、固定サイト巡回でホワイトリスト方式で使う目的なら実用に耐える気がしました。
が、海外サーバをネットサーフするような使い方だと、すべての広告を消すのは結構難しいということもわかりました。
一番消えてほしいアマゾンとグーグルが最後まで残る、というのが残念なところです。
たぶんAdblockの「受け入れ可能な広告」とやらにアマゾンとグーグルが入っているからだろうと思うのですが。
アマゾンとグーグルが気にならない人は良いのでしょうが、気になりはじめると気になってしまいます。
Adblockにカネを出しているんだから我慢しろということはわかってます。
広告があるというだけでなく、コンテンツがみんなアマゾンやグーグルといったグローバル企業に集中しているというのが、なんだかキモチワルイのです。
というようなことをつぶやいてたら、「だったらProxomitron使え」と言われて、使ってみたら当たりでした。
広告問題の抜本的解決というのはこういうのを言うのかなと思いました。
ブラックリストやホワイトリストを併用して、なおかつうまくスクリプトを書けないと誤爆を避けられない。
スクリプトを書くことに慣れている人は良いのでしょうが、素人だと難しそうです。
どちらを選ぶかという判断で、いまは悩んでいます。
「陵辱セックス」だのそういうサイトが人気エントリーになってトップページに掲載
それだけならまあたまにあるけれども今回はサイト内画像を引用してしまって、SEX中の写真がデカデカとトップページに掲載される始末
エロサイトがこうやってトップに上がってくるのって防ぎようが無いのかもしれないけど画像についてはもっと敏感になって欲しいなあ
俺はオッサンだがはてブを見る時はそういう性的なコンテンツを一切求めていない 多くの人がそうだろう
だからむしろそういう性的コンテンツをはてブで目の当たりにすると結構ショックを受ける
性的コンテンツってそれを本人が「求めていない時」に見ちゃうと結構げんなり来るんだよね 人間ってそういう風にできてるらしい
まあそれはともかくとして、日本のwebサービスを代表するサイトのトップページにそういう画像がわりとデカデカと表示されちゃう今の仕様はよくない
画像引用するサイトはホワイトリストにするとかしないとマズいよ
http://anond.hatelabo.jp/20110907193725
を書いた増田だけど久しぶりに増田にログインしたらトラバがついてたんでお返事。
http://anond.hatelabo.jp/20111005112736
見てるかわかんないけど。
これはそのつもりで書いてます。ブラックリストホワイトリストという言い方ではなくて、オプトイン、オプトアウトという考え方で。元記事にも書いてあるんだけど、日本の法律ではオプトアウト方式は認められていないので、合法にやるにはオプトイン方式でないと無理だと思っています。
オプトアウト方式が認められていないのに、著作権違反はいくら大規模にやろうと親告罪であると言うゆがみがあると思っているんで、個人的にはそこは改善されるべきだと思っているけど。フェアユース導入なり、大規模著作権違反の事案は摘発が可能なようにするとかバランスを取るべきだと思う。
例えば自炊依頼のために許諾を求める業者は、その結果に責任取れるんだろうか？
その責任の所在を、自炊業者に求めるなら、法的リスクと収益で割が合わないだろうし、事故として上限免責されてしまうなら、許諾するのが馬鹿らしい。
これはそもそも自炊業者には責任は発生しないと考えます。許諾を得ていればもちろんのこと、許諾を得ていない真っ黒な現状でも。
電子書籍でもDRMフリーで販売されているものがありますが、そのDRMフリーの電子書籍が違法に流通して実害が出たとしても、DRMフリーの電子書籍を正規に許諾を受けて販売した業者は責任を問われないのと同じです。違う言い方をすればコピー機を有料で貸し出しているコンビニや、ドキュメントスキャナ、コピー機を製造している業者が違法性を問われないのと一緒です。もちろん違法流通のために特別な何かをしている場合は別だし、幇助レベルではない別の違法行為があれば違います。
実際に裁判で訴えられるとしても訴える側が自炊業者側に違法性を予見して未必の故意があった等と言う事を証明しなきゃならない事になるわけだけれど、そんなことはまず無理だと思う。
証拠（因果関係）が希薄だから自炊業者無罪なら、余計悪い方向だ。
ちなみに。
電子透かしを求めようが、何をしようが、業者が故意に行うデータ流出は防げないし、アフィリ等で流出の方が儲かる事情があれば簡単に崩壊する。
これは信頼関係を築いていくしかないと思います。と言うのはこれ電子書籍に必ずついて回る問題だし、昔は書籍についても同じ問題がついて回っていたから。と言うのは、販売量は業者しか分からないと言う事だからです。
最近の本でも伝統がある出版社の本なら奥付に「検印廃止」って書かれているのを見る事ができると思いますが、これは何かと言えば昔は出版社が作者に内緒でたくさんすって売っているのではないか（いわゆる偽版）を防ぐために、著者が検印を押した紙で確認するという事が行われていた名残です。同じ版をつかって作者に内緒で刷って裏流通させているんじゃないかと言う疑惑があったんですね。また電子書籍でもDRMがあろうがなかろうが、電子書籍販売業者が横流ししていると言う疑惑は当然ついて回ります。
もちろん、「状況が同じだからって自炊業者が問題無いわけじゃないだろ」って話は当然あって、だからベンチャーなんかがぽっと出でやるのは難しくて、信頼のある印刷業者やら取次やらが既存の自炊業者をノウハウごと買収してやるのがいいんじゃないかと言う〆にしてあるわけです。
実は元記事では触れてなかったけど、ここにある需要があって商売になるかってのが最大の問題としてある。でこれについてはなかなか難しい。
今後電子書籍は黎明期を脱してくるだろう思う。Amazonが来るぞとか言う印象論ではなく、
などが主な理由で、つまりは大手出版社が本気になりつつあるからと言う事なのだけれど、だけどこれは新刊や比較的近年に発行されたものに限ると思うんだよ。
一方今自炊したいという人の話を聞くと、だいたい2種類需要があって
と言う所なんだけど、電子書籍が普及してくると前者の需要は尻すぼみになると思う。と言うかむしろ成りつつある。わざわざ同価で販売されている電子書籍をDRMがあるからといってわざわざ自炊する人間がどれだけいるのかというとそんなにいるとは思えない。
一方後者の需要なんだが、こちらはむしろ電子書籍が普及すれば普及するほど増加してくるんじゃないか。今でも切実にスペースが足りない人は多い。たとえば私もそう。で、電子書籍の環境がだんだん使い物になるようになってくると、その欲求はどんどん膨らんでいくと思う。
また電子書籍で本を読むことが当たり前になってくると、古い蔵書を読みたいという時、紙じゃなくて電子化して読みたいという需要もどんどん増えてくると思っています。
しかし、新刊書籍については需要もあるし、DTPデータも丸ごと保存された状態から発刊と同時に業務フローの一環で電子データを作る事ができるからコストは安くすむし、どんどん電子書籍が出るだろう。
一方、古い書籍はどうだろう？DTPデータが消えてしまっている、あるいはそもそもDTPで作られていないとかで電子書籍を作るコストも新刊書籍より高い。しかも需要はニッチだから作成コストがとれない。だから全ての書籍をカバーすることなんてとうてい無理だ。ただこう言った事情から電子書籍が出ないのであって、権利問題がある訳ではなかったりするのも多いでしょう。電子化するコストは多くの人が言うほど安くはありませんし。
そこに、自炊業者と言うのは存在していけるのではないかと思うのだけれどどうだろう。確かに今の違法でありつづけることで必要なコストを払わない対価ではとても無理だが、たとえば引っ越し業者などと提携して、貴方の蔵書丸ごと電子書籍化しますといったサービスとしてはありえるのではないか、許諾があるものは自炊し、許諾がないものは既存の電子書籍がある場合はそれを案内しつつ、どうしても許諾がなく電子書籍化もできないものは返却する。（希望に応じて裁断だけ手がける）電子書籍化の要望が強いが権利者不明などの理由によってできないものは裁定制度を利用するといった電子ライブラリ構築エージェント的になれないかと思うわけです。
こちらの記事は知識のある人がずいぶん考えて書いているみたいだ
スカスカだと思うぞ。
自炊の可否が圧力になるくらいなら、そもそも電子書籍市場が先にできる。
電子書籍市場が必要ない位のニッチなら、そもそも圧力になんかならない。
んで、許諾に関してだけど、業者はまずホワイトリスト制にすべきだよね。ブラックリスト制じゃなく。
その上で、例えば自炊依頼のために許諾を求める業者は、その結果に責任取れるんだろうか？
その責任の所在を、自炊業者に求めるなら、法的リスクと収益で割が合わないだろうし、事故として上限免責されてしまうなら、許諾するのが馬鹿らしい。
証拠（因果関係）が希薄だから自炊業者無罪なら、余計悪い方向だ。
ちなみに。
電子透かしを求めようが、何をしようが、業者が故意に行うデータ流出は防げないし、アフィリ等で流出の方が儲かる事情があれば簡単に崩壊する。
既に今までの流れで出てきてるだろうが。
○○への差別語として××が使われつつあるという時点で、アイテム名を差し替えるとか、ストーリーを進めてキーワードを消すとか幾らでも出来る。
ウルティマオンラインでは「ヘイブン」がシステム的に問題があって吹っ飛んだ。で、「ニューヘイブン」になった。
「味噌煮込みうどん」みたいに突然に普段使ってる言葉が差別語になるとかありえないので、それと同じことをするのに十分な時間が用意されている。
だから、やばそうだと思ったら、前もって徐々に使うのを止めるわけ？
それも結局、「単語を使わない」選択だよね。
「単語を使う」選択が何処にあるんだよ。
業界の会合で、差別語認定されてから対処しても余裕があるんだよ。
違うよ。
それまで「バカチョン」「ニグロ」で通じてた会話が出来なくなるんだよ。
できるだろうが。
「バカチョンカメラ」って言葉は使われなくなって、その理由として「バカチョン」が差別語だったんじゃないのかって出てきただけじゃねーか。
「ニグロ」もしかり。
普通、日常会話での自粛によって差別語は自然消滅するだろうが。
何度言わせれば気が済むんだ？
面白いからもう少し書くけれど。
んで、このシステムだと「ニグロ」町はどうやってホワイトリストに載せるの？
結局、「ニグロ」と言う単語を使わないようにしないとダメなんじゃないの？
だから、やばそうだと思ったら、前もって徐々に使うのを止めるわけ？
それも結局、「単語を使わない」選択だよね。
だからさ、「ニグロ」って単語を使わないようになったらユーザーが混乱するのは技術的な問題で言葉狩りがどうとかは関係ないって言ってんの。
違うよ。
それまで「バカチョン」「ニグロ」で通じてた会話が出来なくなるんだよ。
そういう話だと、何を主張したいのか見えないんだが。
○○への差別語として××が使われつつあるという時点で、アイテム名を差し替えるとか、ストーリーを進めてキーワードを消すとか幾らでも出来る。
という、「その例えだと、伏字システムの不備って技術論で終わる可能性がある」って流れにいきなり、
そういう「差し替え」をするかどうかが問題なんだけどね。ｗ
って、原論持ち出してドヤ顔してるお前の自意識過剰さに気づけ。
それがどうした。
その結果が起きたとして、「道具の名称に単語が含まれている場合に道具の名称まで伏字になるのは如何か？」という問題は「伏字システムの不備って技術論で終わる可能性が高い」という話なんだよ。
同じIT関係勤務の40代子持ちのおっさんから言わせてもらう。
極端な話、コンビニにけん銃は置いてないけどエロ本は置いてあるし、毒薬は簡単には手に入らないけど同人ロリスカトロものはネットですぐに見つかる。
コンビニや本屋のエログロコンテンツはちゃんと遮断してある。問題はネットだが、素のPCを子供にさわらせるなよー。
手を抜くな。ちゃんと自分で管理しろ。そのための手段は世にあふれている。何のためのIT知識だ？
うちは小学校入学前からPCさわらせてWebを見せているが、子供用のアカウントはフィルタリングProxyを通すようにしてある。アクセス先はホワイトリストで管理していて、見たいページがエラーが出て見れないときは父ちゃんにいえ、といってある。親が見て問題なければホワイトリストに加える。
これ自分が子供の時分にはインターネットが、PCが、ゲーム機が、で似たようなことを言われてた記憶があるが
ぶっちゃけBLとかまああと二次でも男子のエロでも感染経路の大多数は友人知人姉妹兄弟だろ
ケータイでもじゃあまず手始めにどこから出入りするかっていったら友達経由で友達のお気に入りサイトだろ
どうしてもコントロールしたければホワイトリストのフィルタリング、ってなるかもしれないけれど、お友達がいる限り保護者基準でけしからんものを完全にシャットアウトするのは無理。諸氏にお心当たりがあるように。
じゃあ有効なのは妙なお友達とお付き合いなんかするんじゃありませんの一言かっていうと、お付き合いしたいからお友達なのよね。グループってやっぱり興味や話の合う似た者同士で構成されてるし。女の子なら多分なおさら。
まあ月並みですけれども親御さんが目を光らせて度が過ぎるようなら諭す、よりも有効な手段なんかないんじゃないかな
http://anond.hatelabo.jp/20081218152326
携帯のフィルタリングは２００５年から一応あるにはあったんだよね。
NTTドコモ、iモードに子供向けのフィルタリングサービスを提供 2005年06月24日
http://k-tai.ascii24.com/k-tai/news/2005/06/24/656606-000.html
(株)エヌ・ティ・ティ・ドコモとNTTドコモグループ8社は24日、iモードによるウェブサイトへのアクセスを制限できるフィルタリングサービス “Kid's iモードプラス”の提供を発表した。ネットスター(株)のデータベースを基に、出会い系サイトやギャンブル系サイトなどへのアクセスを禁止する。
同種のサービスとしてはすでに提供中の“Kid's iモード”があるが、これはiメニューの“公式サイトのみ”アクセスが可能で、一般サイトへのアクセスを制限するというもの。一方、新たに提供される “Kid's iモードプラス”では、一般サイトへアクセスを可能とした上で、出会い系サイトやギャンブル系サイトなどの特定カテゴリーのサイトへのアクセスを制限する。
制限されるカテゴリーは、“不法”“主張”“アダルト”“セキュリティ”“ギャンブル”“出会い”“グロテスク”“オカルト”“コミュニケーション”“ライフスタイル”“宗教”“政治活動・政党”“成人嗜好”。
だけど、結局申込者が少なかったのか、あまり有効ではなかったみたい。
学校裏サイトとかの問題が出て、携帯フィルタリングすべき、という流れが出てきた。
２００７年の１２月から各キャリアは自分たちの基準でフィルタリングをやってた。
携帯フィルタリング「利用者が選択を」 総務省が改善策 2008.4.2 19:37
http://sankei.jp.msn.com/economy/business/080402/biz0804021939015-n1.htm
携帯のフィルタリングは増田寛也総務相が昨年１２月、未成年者に原則適用するよう携帯電話各社に要請、本格導入された。現状は、（１）携帯会社が認定した「公式サイト」から有害性のないサイトだけ閲覧を認める「ホワイトリスト」（２）無数のサイトから有害情報を排除する「ブラックリスト」〓の２方式があり、ＮＴＴドコモとＫＤＤＩはホワイトリストを適用中。
フィルタリングは何らかの形でされているものの、効を奏していないって事なんだろうね。
プロフとかmixiとかよくわかんないけど、場所を変えて、いじめとかがどこかでおこってるのか。
キャリアが悪いのか、子供が悪いのか、親が悪いのか、フィルタリングの効果を認めないで規制を推し進める人が悪いのかはわからない。
結局、携帯を持たせないようにしようっていうのが今回の流れかな。
＜教育再生懇＞携帯電話の小中学校持ち込み、原則禁止 12月18日12時17分
http://headlines.yahoo.co.jp/hl?a=20081218-00000044-mai-soci
政府の教育再生懇談会（座長、安西祐一郎・慶応義塾塾長）は、子どもの携帯電話利用に関する提言の素案をまとめた。「小中学生が携帯電話を持たないよう保護者や学校が協力する」とし、通話機能に限った携帯電話の促進や、小中学校への原則持ち込み禁止を促している。
だけど、画一的に持たせないようにする事で、貧富の差により携帯を持っている子と持ってない子の間で生じるトラブルは、減らせるかもとは思う。
8月1日からDoCoMoの未成年向けの有害サイトフィルタリングが
このブラックリスト形式って、ネットスター社が作成してるサイトのカテゴリ分けを元に
DoCoMoがそのカテゴリに対してOKかNGかを決めてるのね。
簡単に言うと、
DoCoMoがネットスター社の「ギャンブル」というカテゴリをNGとしてフィルタリングの対象にしている場合
一般サイトがネットスター社によって「ギャンブル」にカテゴライズされたらフィルタリングの対象になるわけ。
今回、ネットスター社がそのカテゴリ登録を確認できるサイトを公開したんだけど
http://category.netstar-inc.com/
これでモバゲーを検索すると「ゲーム」のカテゴリに登録されてるって出る。
「コミュニケーション」にカテゴリされるのが当然じゃない？でも「ゲーム」なの。
なぜ「ゲーム」にカテゴリ登録されたのかは知らないけど、「コミュニケーション」のカテゴリは
DoCoMoによって有害サイトのフィルタリングの対象になっているけど、「ゲーム」のカテゴリは対象じゃない。
おかげでモバゲーは、未成年のフィルタリングからめでたく外れた。
モバゲーで出会って殺人まで起きてしまったから生まれてきた問題じゃないの？
http://kirik.tea-nifty.com/diary/2007/11/post_671c.html
エロ画像や競馬情報なんかを未成年に見れないようにしたところで
コンビニに行けばそんなもんいくらでも見れるでしょう。
まあ、どのくらいの数の脆弱性オタがそういう彼女をゲットできるかは別にして、
「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、
その上で全く知らない脆弱性の世界とはなんなのか、ちょっとだけ好奇心持ってる」
ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、Webアプリ脆弱性のことを紹介するために
（要は「脱オタクファッションガイド」の正反対版だな。彼女に脆弱性を布教するのではなく
相互のコミュニケーションの入口として）
あくまで「入口」なので、時間的に過大な負担を伴うような図解などは避けたい。
できれば、秋葉原とか筑波とかから突っ込みがはいるような微妙な奴も避けたいのだけれど、つい選んでしまうかもしれない。
あと、いくら脆弱性的に基礎といっても古びを感じすぎるものは避けたい。
プログラム言語オタがCOBOLは外せないと言っても(いましたね)、それはちょっとさすがになあ、と思う。
そういう感じ。
彼女の設定は
セキュリティは専門でもなんでもないが、クロスサイトなんちゃらとか、SQLなんとかくらいは聞いたことがある。
サブカル度も低いが、頭はけっこう良い
という条件で。
まあ、なんで一番がSQLインジェクションじゃないんだよとも思うけれど、たいていのWebアプリに必ずあるという普遍性(日本語変か?)とか、文字コードネタのバリエーションとか、DOMが絡んでわくわくするとか、Same Origin Polic何じゃそりゃという点では外せないんだよなあ。長さも3文字だし。
ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。
この情報過多な脆弱性について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に
伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
アレって典型的な「オタクが考える一般人に受け入れられそうな脆弱性（そうオタクが思い込んでいるだけ。実際は全然受け入れられない）」そのもの
という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには
一番よさそうな素材なんじゃないのかな。
「Webアプリの専門家からいえば、この二つはアプリネタじゃないと思うんだけど、率直に言ってどう？」って。
侵入先のファイルが見えてしまうというハッカー的なものへの憧憬と、これによる逮捕者がいるという法的な考証へのこだわりを
彼女に紹介するという意味ではいいなと思うのと、それに加えていかにもマニアックな
「よく眼にするけどあまり実害の思いつかない」/etc/passwd
「滅多に見られないけど、見つけたらゾクゾクする」/etc/shadow
の2ファイルをはじめてとして、オタ好きのするファイルを世界に公開(流出?うわ、日本語間違いが怖い)しているのが、紹介してみたい理由。
たぶん秋のDK収穫祭を見た彼女は「これCSRFだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
そして、われらがアイドルはまちちゃんの紹介のおかげで、この脆弱性が日本で大人気になったこと、
「やっぱりWebアプリの脆弱性は個人情報DBなんかがあるサイトのものだよね」という話になったときに、そこで選ぶのは「SSIインジェクション」
でもいいのだけれど、そこでこっちを選んだのは、この脆弱性がふつーのホームページなどでも本当によく見つかるくせに、意外に問題視されていないレアっぽさが好きだから。
断腸の思いでJavaMailのAPIがTo欄やFrom欄に改行チェックいれているのに、なぜかSubject欄だけチェックがされてなくて脆弱性の原因になるかもって中途半端さが、どうしても俺の心をつかんでしまうのは、
その「チェックする」ということへの躊躇がいかにもオタ的だなあと思えてしまうから。
ほかのメールAPIでもチェックが不十分なものはあるし、そもそもsendmail呼び出すときはチェックはアプリ側でやるしかないとは思うけれど、一方でこれが
Microsoftだったら意外にきっちりセキュアに仕上げてしまうだろうとも思う。
なのに、安全なAPIを使わずに(知らずに?)脆弱性を混入してしまうというあたり、どうしても
「自分の過去から知っている書き方でないと書けないプログラマ」としては、たとえ脆弱性混入した奴がそういうキャラでなかったとしても、
親近感を禁じ得ない。脆弱性の高危険度と合わせて、そんなことを彼女に話してみたい。
今の若年層でディレクトリリスティングによる個人情報漏洩事件をリアルタイムで見聞きしている人はそんなにいないと思うのだけれど、だから紹介してみたい。
SQLインジェクションよりも前の段階で、個人情報の漏洩規模とかはこの脆弱性で頂点に達していたとも言えて、
こういう危険の高さが経産省あたりの個人情報保護ガイドラインにのっていたり、というのは、
別に俺自身がなんらそこに貢献してなくとも、なんとなく脆弱性好きとしては不思議に誇らしいし、
いわゆるインジェクション系でしか脆弱性を知らない彼女には見せてあげたいなと思う。
UNIXシェルの「セミコロン」あるいは「バッククォート」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。
「ホワイトリストで対策すると安全なんだけど敢えてエスケープを究めたいマニア」的な感覚がオタには共通してあるのかなということを感じていて、
だからこそ佐名木版『セキュアWebプログラミングTips集』は20ページ以上もかけてOSコマンドインジェクション対策の説明しているのは、エスケープ手法以外ではあり得なかったとも思う。
「侵入先のコンピュータでコードが動いてこそなんぼ」というクラッカーの感覚が今日さらに強まっているとするなら、その「クラッカーの気分」の
源はOSコマンドインジェクションにあったんじゃないか、という、そんな理屈はかけらも口にせずに、
単純に楽しんでもらえるかどうかを見てみたい。
これは地雷だよなあ。昔だったら筑波方面、今だったら秋葉原方面から火のような「hiddenは危険脳」ブクマがつくか否か、そこのスリルを味わってみたいなあ。
こういう昔のIPA風味の解説をこういうかたちでブログ化して、それが非オタに受け入れられるか
突っ込みを誘発するか、というのを見てみたい。
9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にSQLインジェクションを選んだ。
XSSから始まってSQLインジェクションで終わるのもそれなりに収まりはいいだろうし、カカクコム以降のWebアプリ脆弱性時代の原動力と
なった脆弱性でもあるし、紹介する価値はあるのだろうけど、もっと他にいい脆弱性パターンがありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい10パターン目はこんなのどうよ、というのがあったら
教えてください。
「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。
Inspired by アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本
##はじめに
→OpenIDが仮に広まった未来には、サービス事業者がユーザの個人情報をどれだけ持つのが適正なのかを考えられるようになりたいよ
##OpenIDを利用したサービスは、将来オープンにOpenIDプロバイダを受け入れることができる？
OpenIDを受け入れる、ということは「特定ではないIDプロバイダによって認証」されたユーザをサービス事業者は受け入れるということになるよ。
※以下サービス事業者の例を、わかりやすくするために京都発のWebサービス提供会社、はてなさん（以下はてな）にするよ
ここでいう「特定ではないIDプロバイダによって認証」というカッコ書きについて整理しておくね。
これ、逆に言うとこれまでのサービスって、はてなも勿論そうだけど「特定されるIDプロバイダによって認証」が行われていたんだということになるよね。
例えば、はてなというサービスにエンドユーザの増田が、はてなのIDとパスワードでもってログインを行う場合は、
増田・はてなサービス・はてな会員管理システム（これもはてなの一部だけど）の３者関係で考えると、
増田がはてなのサービスを利用するためにログインすると、はてなサービスは、はてなの会員管理システムに僕が僕であるためのID・パスワードを問い合わせして
はてな側に僕だよ、っていうことを認証、そしてサービス利用の許可（認可）していたわけだよね。
これまでの
はてなのサービス→はてなの会員管理システムで認証する、というお決まりのやり方を
はてなのサービス→「特定ではないIDプロバイダによって認証」もOKにしちゃう！
っていうのがOpenIDの基本的な考えだと思ってるよ。
つまり、はてなに対してみんな大好きなmixi（渋谷区）のゆるふわIDパスワードでOpenID認証しちゃえ！ていう感じ。
OpenIDと呼ばれるもののコアなところって、この自分じゃない余所様でログインをさせるにあたっての
通信の決まり・振る舞い方についての仕組みとかのことなんだね。
認証機能の委譲、なんて難しい言葉で言われてもバカな僕にはわかんなかったから、とりあえずこんな感じで整理してみたよ。
でもね。増田自身がはてなの立場になって考えてみるとこう思うよきっと。
他所のプロバイダさんに認証をお願いしたら、、、
「コノ人確カニ○○○君！ザッツヒム！イッツOK!!」ていう怪しげな応答があったとしてもさ
「うちは京都のサービスさかいに、妙ちくりんな英語まじりのプロバイダさんの言うことなんか信用できまへんなー」
て自然と思ってしまうよきっと。これがひいてはOpenIDプロバイダの評判問題ってやつにつながる話だね。
あと、じゃあOpenIDプロバイダの認証結果は信じることにしたとしてでも今度は
「まーmixiさんところが認証OKてゆなら確実でっしゃろう？遠いところからよくきはりました。
どれ、アンタうちでもサービス使わせてやるさかい...あれれ？君、うちでいうところのid:誰くんでしたっけ？」
てなっちゃうねーやっぱり。。これが認証と認可（属性情報交換）に関わる問題てやつだよ。
うーん、ちょっと自分自身にとってもムツカシくなってきたなぁ。もう少しわかりやすく書くね。
上の話ははてな子ちゃんが自分の会員管理システムでログインさせない（外の会員管理システムでログインする）ことにより、
自社のサービス提供では当たり前にできていたことができない、という問題が２つ出てきたねーということだよね。
１． 「あなた（Openプロバイダ）の認証、あ、あたし。信じていいの？ゴクリ・・・」
という信頼関係について。
２． 「あなた（エンドユーザ）は彼（OpenIDプロバイダ）に認められた人だから、アタシも、が、がんばって信じる！…けど、○○○君（エンドユーザ）のことをもっと知る必要があるの。。。」
という（エンドユーザの）認可・（OpenIDプロバイダからの）属性情報の受入（交換）について。
うー、あれ？
はてなスターではこの２つの問題をどうしているの？って思う人は多いよね。
たぶんはてなスターがOpenID対応しているっていうのを聞いたことがあっても、実際にやったことある人は少数派じゃないかなまだ。。
じゃあこっからははてなスターを例にとって説明するよ！
詳しくは下のリンクの説明通りなんだけど、
http://www.hatena.ne.jp/info/openid
今回増田が問題としている２つについてはてなスターの機能はどーなってるの？ていうのを整理すると
１．「OpenIDプロバイダとの信頼関係について」＝「フレンドプロバイダのみ認証OK！」（いわゆるホワイトリスト）
２．「（エンドユーザ）認可・（OPとの）属性情報交換」＝OpenIDのユーザ名でスターがつく
という対応をしているみたい。
※ちなみにこの記事書くにあたって増田ははじめてOpenID経由ででスターつけてみたよ！！
つまり、
１．の信頼関係については、Livedoorなど数社のOpenIDプロバイダのみを受入OKにしているし、
２．の属性情報については、OpenID認証を行う際に必要なOpenIDプロバイダ側の「ユーザ名＠OP名」でスターがつくだけ
→なので属性情報交換などはほぼゼロだよね、って感じだったよ。
１．は、
「なーんだ。Open何とか言っておきながら内輪でのID連携かよ。うちも一応OpenIDプロバイダたててんだよ？え？無理？うちみたいなチンケなプロバイダは無視ですかそーですか」
みたいな中小企業のボヤキが聞こえてくるくらい全然Openじゃなくすることで一方での
はてな子ちゃんにとっての問題＝「あなた（Openプロバイダ）の認証、あ、あたし。信じていいの？ゴクリ・・・」問題を回避しているということになるよね。
２．についてははてなスターはほぼガン無視を決め込んでいるのが今回よくわかりました！
今回増田がためしにOpenID認証経由でスターをつけてみたんだけど、
あのー、、増田も一応こうして増田をやっているので一応はてな市民であって、「あいでぃー:xxx」みたいな立場ではあるじゃないですか。
なのに、LivedoorのIDでスターつけちゃったら「あいでぃー:xxx」でスターつけたことにならない＞＜！(※)ので、
うーん、、ちょっとこれは深刻な機能不足だなーと思った次第ですー。いや？いいのかこれでOpenIDとしては。微妙だなぁ・・
(※)
だって、増田のidhttp://s.hatena.ne.jp/xxx/starsでスターが反映されない
あと<増田のLivedooeのアカウント名>@livedoor のスターのカウント（上のhatena/user/starsに相当するページね）はどこにいったのだろう？？
でもさぁ、
はてな子ちゃんの立場はそれはそれでよくわかるのよね。
いまいまのOpenIDのセキュリティレベルでは、どこの馬の骨ともわからん奴にあなたのことについて
※ほんとは、はてなの「あいでぃー:xxx」とLivedoorのidがSocialに結びついてくれて、
自動的にhatenaのidでスターをAddしたことになればいいんだけどねー。でもそれじゃあはてなIDでログインしろってことと変わらんかー。
とも思うし難しいなぁこの辺。
こういう問題があるOpenID界隈では、でもこれらの問題について色々知恵を出し合って解決しようとしている
人もいるみたい。サイボウズのzigorouさんとか、他にもいっぱいいらっしゃるけど、皆さんすごいがんばってるみたい！すごい！
増田個人は、
１．については各OpenIDプロバイダとIDを利用するサービス側(Ryling Party)それぞれのホワイトリストが
Socialに連携/公開されてグラフになってエンドユーザが利用できる・できないの仕組みになるのがいいのかなー、
と思っていたりするよ。DNSみたいな公開されて相互利用できるよな仕組みがあればいいのかなー。
２．については属性情報の仕組みとしてはAXとかsregとかあるけど、要は使い方でリバティ・アライアンスの頃からしきりと言われているらしい
「串刺しにした」サービスの連携のためにどう属性情報を流通させるのか？SSO連携が肝だよねー。とか。
また属性情報流通させるにあたってのその情報粒度は？っていう話を詰めなきゃいけないんだろうなー、というレベルでぼんやり中です。
もう少し↑について知識・考えついてきたら、またまとめてみたいです。じゃあまたね！！
「あまりに急」「検閲では」――携帯フィルタリングに事業者から不満続出 - ITmedia News
http://www.itmedia.co.jp/news/articles/0801/22/news123.html
----
どこの会社がフィルタリングを提供してもいいけど、そのベースになるホワイトリストの構築に関してひと言。
SNSのように、すでにホワイトリストに載っている優良サイトが新規サイトを推薦してリストに載せるようにすればイインジャネ？ で、その推薦というか招待というか、推薦したサイトと推薦されたサイトの繋がりをSNSのお友達リストだと考えて、それをネット上に公開する、と。
何か問題が起きたときに、そのサイトを推薦したサイトも巻き添え食らうよう（例えば○○日間アクセス不可とか）にしておく。フィルタリングを利用するユーザーは推薦している数・されている数を目安に----例えば双方20以上あるサイトだけ許可とか----フィルタをかけられるようにする、と。
もうそろそろ締め切りだよね。がんばれMiAU!
というわけで、私も送りました。ここで自分のダイアリーに貼るとお役人の中の人にIDと実名がリンクしちゃうので増田にはるよ。
1から4は個人情報（めっちゃ実名入り）なので5からはるね。
5. 該当ページおよび項目名：
全2件
104ページの a i 第３０条の適用範囲からの除外 の項目
105ページの a ii 第３０条の適用範囲から除外する場合の条件 の項目
6. 意見：
私が意見を述べるのは、以下の2件です。
■意見を述べる項目(1)
104ページの a i 第３０条の適用範囲からの除外 の項目について
☆意見(1)
違法録音録画物、違法サイトからの私的録音録画を第３０条の適用範囲から除外することに反対します。
挙げられた理由ウ、エには全く妥当性がありません。著作権者は既に違法サイトを叩き潰すのに十分な「送信可能化権」という武器を持っており、適切にコストをかけて対処すれば利用者への啓蒙やモラールに頼ったコストばかりかかって脆弱な対策は全く必要ではありません。
また、理由イに違法サイトからの録音録画、海賊版からの録音録画が違法であることは利用者に受け入れられやすいこととあります。なるほど個別の利用者に質問すればそう答えるかもしれませんが、現在横行するフィッシング詐欺を鑑みれば一般の利用者にとっては「それが普段利用している銀行のサイトであるかどうか」の見分けすらつけるのが難しいことがはっきりしています。適法な音楽・映像配信サイトであると利用者が判断することを期待するのは無理な相談でしょう。また、今後の一億総クリエイター時代においては違法サイトであるかの判断はさらに難しいものになります。実際にアマチュアバンドの創作した音楽ビデオを動画配信サイトが誤って削除した上バンドのアカウントを長時間ロックアウトした事件が発生してしまっています。
http://www.itmedia.co.jp/news/articles/0710/22/news109.html
大量の動画を見慣れている配信サイト側ですら難しい判断を個々のネット利用者に強制することとなり、とても現実的とはいえません。
また、ブラウザでインターネットに接する一般のユーザにとってダウンロードはリンクを触ったら勝手に行われてしまうものであるため、リンク先に飛んだら自分が違法行為をしてしまうかもしれないという懸念を常に抱いて行動せねばならないことになります。
これはリンクによって情報をつなぎ生態系を作るWWWという仕組みを真っ向から破壊する行為であり、明らかに文化の破壊です。
■意見を述べる項目(2)
105ページの a ii 第３０条の適用範囲から除外する場合の条件 の項目について
☆意見(2)
この条件のうち、アの条件は極めて運用が困難であり、第３０条の適用範囲除外自体が有名無実化するか、適用除外が大きな悪影響を生むことが考えられるため大きな問題があり、実施に反対します。
「利用者が明確に違法サイトと適法サイトを識別できるよう、適法サイトに関する情報の提供方法について運用上の工夫が必要」
とあるが、これは通常の考え方ではホワイトリスト方式またはブラックリスト方式の2方式のどちらかでしょう。
まず、ブラックリスト方式ですが、違法サイトのリストを作成して「ネット利用者のみなさん参考に見てくださいね」という行為自体が馬鹿馬鹿しいものです。
権利者がそのサイトの存在を認知し、違法サイトであると確認できた段階で、現状の手続きであってもサイトを潰すことが可能です。また、違法サイトのリストというものはむしろ利用者を誘導する道しるべになってしまいます。
明らかな違法録音録画物で物理的な実体を持つものからの複製に対しては、ブラックリスト方式によって情を知ってなお複製することをとがめることができるかもしれませんが、インターネット上のサイトに関しては同じ条件は当てはまりません。従来の手続きに従って粛々と潰せば良いだけです。
次に、ホワイトリスト方式ですが、創作者が企業に丸抱えで創作活動を行うしかなかった時代ならともかく、現代のインターネットは誰もが創作者になる可能性があり、そのための情報発信の敷居が極めて下がっている場所です。そこに「ホワイトリストに登録しないと正規の配信者になれない」つまり「気軽に公表したら違法配信者扱いされる」という負のインセンティブを全ての表現者に課すということは、せっかく育ち始めた音楽創作や動画創作の芽を端から摘んで回るというあからさまな文化の破壊行為ですし、無方式主義であるはずの著作権法を登録制にしてしまうという大変革も実行してしまうことになります。
このように通常とりうるどちらの方法も大きな問題を抱えています。このような対策は実施すべきではありません。
まあ私はこんな感じ。実はいろんなところに私にとって都合の良い変な論理が入ってるけどね。
他のところはよんでて「まあいいかあ」って思っちゃったから、2点だけにしました。
