  |
はてなキーワード: 情報強者とは
http://togetter.com/li/1014013
http://mubou.seesaa.net/article/441178571.html
http://t-ritama.hatenablog.com/entry/2016/08/20/004354
JK または NHK の捏造・嘘という悪意が話題になっているが、実はこれは、
JK には嘘をつこうという悪意があったとは思えない。彼女は単にパソコンを安価に変えるということを知らなかっただけだ。iPhoneのために毎月１万円近くを払うことはできても、パソコンを買うために３万円を払うことができなかった。なぜ？ 金がなかったからか？ いや、知識がなかったからだ。
そもそも、「安いパソコン」で検索すれば、２万円以下で買えるとわかる。ヤフオクで買えば、5000円以下でも買える。なのに、彼女は、その知識がなかった。
ではなぜ、その知識がなかったか？ 貧困だからか？ 愚かだからか？ 違う。今の若い世代は、スマホのことばかり考えているからだ。まわりを見ても、スマホばかり。家に帰れば、少しはパソコンやキーボードを使うこともありそうだが、原則としてスマホばかり。だから、「パソコンを使う」という発想がもともとなかったのだ。
そのあと、彼女は、論理を飛躍させた。「私の家にパソコンがないのは、貧困だからだ」と。
本当はそうではないのだが、彼女はそう思い込んだ。そう思い込んで、貧困会議で発言した。それをNHKがろくに調べもしないで報道した。……こうして、あちこちで食い違いが生じて、誤報が放送された。そのあと、炎上した。
ネットの人々は、JK や NHK の悪意を見出した。しかし本当は、悪意などはなかった。あったのは、「パソコンのことなんかろくに知らない」という、現代の若者の傾向だったのだ。ただそれだけだったのだ。（一種の世代格差。）
usanosuke_n Twitterアカを幾つも使いこなしAmazonを利用出来てかながわ子どもの貧困対策会議 とやらに出るほど交際も広い彼女がそんな情報弱者とは思えないが
情報弱者じゃないです。スマホを使いこなしており、普通の情報については十分に情報強者です。ただ、パソコンについては苦手意識があって、手を出しかねている、というだけ。
たとえば、あなただって、ネイルサロンやエステのことはろくに知らないでしょ？ それはあなたが情報弱者だという意味ではない。単に関心がないだけだ。
うららも同様。スマホに関心があるだけで、パソコンには関心がない。だから情報が入ってこない。自分で自分にフィルターをかけている。それが最近の若者気質だ、という話。
kyo_ju 放送原稿がWebに上がってるから読め→http://tinyurl.com/zgsfkfr /中学でパソコンの授業があり、内容が家でパソコン触ってる事前提のものだったのでついて行けずキーボードだけでも練習した訳。スマホ世代云々とか関係ねぇ。
中学時代についてはそうだが、高校卒業間際になっても、いまだに 1000円のキーボードしか持っていない（それでいて食費やコンサート代にはさんざん浪費する）というのは、「パソコンなんか不要だ」と本人自身が思っていることを意味する。金がないのではなく、本人がパソコンを不要だと思っている証拠。「パソコンなんて、ランチ代ほどの価値もないのよ」と。
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
来年３月に東大法学部を卒業する俺から、「もっとこうすれば良かった」という話をメインで集めて、教訓を書いたので新入生に贈る。どうせこんなところに書いても誰も見ないだろうが、一人でも見てくれたら…という思いを込めて。対象は文科一類またはその他各類から法学部に進学する予定の東京大学の１年生または受験生。それ以外の人は一切対象にしていない。
まず最初に知っておくべきことは、東大法学部ではお勉強ができる順番が全てということ。成績と資格がすべて。それ以外の諸条件（コミュ力とか課外活動とか部活等）は基本的に考慮する必要が無い。勉強ができれば自分の志望する進路に行くことができるし、勉強ができなければその道は閉ざされる。経済学部等の他の文系学部とはこの点で一切異なることを肝に銘じておいてもらいたい。その上で大切なのは、できるだけ早く進路志望を確定すること。法曹なのか、公務員なのか、民間なのか。大まかに言ってこの３つは勉強のできる順番と考えてもらって構わない。勉強ができる人から順に選択肢が多い。法律の勉強がまったくできない人は民間に行くしかない。ここで言いたいのは法曹が偉くて民間が偉くないということではなく、自分の志望する進路に行くには勉強ができることが大前提だということ。
上記で強調したように、早く進路志望を設定できればそれに向けて動き出すことができる。駒場ではサークルも盛んなのでそれなりに学生生活を楽しみつつ、他の法学部進学者を出し抜くために専門科目が２年次で始まるよりも早く法律の勉強を始めることを強く勧める。そうすれば自分が法律に向いているかどうかも早めに判断できるし、３類（政治コース）を選択するとか、場合によっては進振りで法学部以外に進学することを考慮することも可能になる。どうやって勉強するか、であるが、ダブルスクールか自学自習ということになる。自学自習の場合は各予備校が出している参考書と学者の書いた教科書を、民法・憲法・刑法を中心に勉強すればよい。自律できない人はダブルスクールしかないだろう。
本郷に進学した後は勉強に集中するべき。遊びは駒場で終わりにして（その分駒場でサークルを含めて遊びたいだけ遊んでおくと良い。内向きにならず。）、本郷ではひたすら勉強の日々を過ごすことになる。
法曹志望者は、一刻も早く予備試験に合格して司法試験に合格することを目指す。早ければ早いほど良い。可能ならば東大に入学する前後の春から伊藤塾等のダブルスクールを始めることが望ましい。この場合、法科大学院進学を視野に入れつつ予備試験を受けていく、ということになるだろう。３年までに予備試験に合格すれば法科大学院に行くまでもなく卒業してそのまま司法修習に入ることができる。金銭的にも時間的にもキャリア的にもこのメリットは非常に大きい。このパターンが一番の勝ち組だと考えておけば大丈夫。駒場にいる１年次から準備を始めることが何より大事というのはとにかく知っておいてほしい。
国家公務員総合職の志望者に関して。国家公務員総合職試験は、東大に合格する学力があれば２ヶ月もまともに勉強したら合格自体はさほど難しくない。問題になるのは合格順位。教養区分や経済区分で受ける人もいるかもしれないがここでは最もオーソドックスと思われる法律区分について記す。法律区分で一桁、もしくは低くても５０番よりも上の順位で合格していれば、よほどのコミュ障でなければ「どこの省庁にも行けない…」という状況にはならないはず。もしも５大省庁に入りたいとか、省に入ってから出世コースに漏れた状態で社会人生活をスタートしたくない、というのであれば一桁合格を目指すべき。そして一桁合格を目指すならば、司法試験を目指す方針で学生生活を送ることを勧める。滑り止めとして法科大学院を受験するつもり、もしくは３年次の予備試験までに合格するつもりで法律の勉強を進めていれば、かなり有利な状況で公務員試験を受けることができるはずだし、官庁訪問で失敗しても法曹に行けばいい。
法学部進学者が最初から民間志望と言い切ってしまうことはおすすめしない。民間に行くならばわざわざ法学部に進んで大変な試験を大量に乗り越える必要があまりないため、進振りで経済学部等に進めばよい。上にも書いたように、お勉強ができる人が偉いのが法学部の鉄則であり、勉強ができる人から順に進路の選択肢を得る。法律の勉強をした上で、何か民間でやりたいことがあるのであればそちらを志望すればよい。いろいろ意見はあるだろうが、結局のところ、給与や安定性等を考慮すると法曹と公務員を除くすべての民間企業は滑り止めとしての扱いでも構わないのではないかな、と個人的には考える。
もしも予備試験に３年までに合格して４年で司法試験に合格できるほど勉強がよくできる場合は、引く手あまたで就活には困らないだろうからここでは割愛する。まず公務員志望の場合、民間企業を多くて５社程度滑り止め＆面接練習のために受けてから官庁訪問するべきであり、可能ならばこれに加えて法科大学院の受験もすべき（適性試験の受験が必要になるので遅くとも２年の時から調べて準備を始めること）。毎年のように滑り止めなしで公務員試験に突入し、官庁訪問に失敗して留年する者が続出している。民間志望の場合、法学部の中だけで過ごしているとロクなところに引っかからず、メガバンに就職する羽目に…というような例が案外よくある。経済学部の経友会に所属するとか、1年または2年の時から有名企業や外資企業のインターン説明会に参加したりOB訪問（東大は就職活動サポートは実質的に何もしてくれないが、OB名簿は本郷のキャリアサポートセンターに行けば学年に関係なく誰でも見られる）するなどの活動を積極的に行うべきではないかと思う。勉強ができる人が評価されるというのが大前提ではあるが、3類進学などでそのコースでは戦わない場合、別の戦い方が求められる。個人的にもよくわからない部分が多いのでここでは詳述しないが、民間就活に関してはネットや書籍でも情報が溢れているし、そちらを参照のこと。
まことしやかに囁かれる、法学部では３割の人が留年するというウワサだが、確かに留年者は多い。しかし、単位が取れなくて留年する者はほとんど皆無であり、進路がなくて留年する者がほぼ全員を占めることは知っておいてほしい。留年は官庁訪問の失敗か、法科大学院不合格かのどちらかだ。東大の法科大学院を既習で受験する場合、舐めていたら東大の学部生でも普通に落ちる。公務員志望の場合に滑り止めを受けるべきことは既に述べた通り。
これも本当。何もしなければ友達は増えない。だからこそ、所属コミュニティを積極的に増やす姿勢が非常に大切。まず、シケタイには必ず入ること、試験対策というのは正直者がバカを見る世界で、情報強者が勝つ。法律相談所なんかもできれば所属すべきで、入って失うものは何もないが得られるものは大きいはず。駒場のサークルで忙しいなどと言って入らないのは愚の骨頂。駒場のコミュニティと本郷のコミュニティは異なるし、進路を決める上で決定的に大切なのは本郷の方。他に緑会の懇親会や三類懇親会などには必ず顔を出すこと、法曹や公務員志望ならば自主ゼミを積極的に作ること、時間との兼ね合いではあるがゼミを２つ以上履修することなどは、心がけとしてあってもいいかなと思う。
読み返すとなんだか仰々しい感じになってしまったが、のんびりしていてもなんとかなる人もいるし、人それぞれのやり方があると思う。他にも何かまた思い出したことなどあれば加筆する予定。
なぜか。それは前提となっているコミュニケーションの型が違うからだ。
たとえばフツーのコミュニケーションにおいて大部分を占める個人（自分/他人）の体験談である。これはかなり独自性が強い。抽象化すればカテゴライズ可能かもしれないが、基本的には個別的で、「事前に共有されていないこと」が前提となる。なので体験談を話すときのフォーマットは自然「知っている人間が知らない人間に教える」形におさまる。
これがみんなの身体に刷り込まれているため、「あ、私その話知ってる」と言って情報の非対称を乱すような行動はあまり好ましくないわけだ。人は情報強者っぷりに酔えなくなるので、知ってるアピールを嫌うのではない。頭のなかにあるリズムや無意識にプランニングされた流れを崩されたからイラ立つのだ。
一方読書は流派が違う。その体験が「事前に共有されている」可能性を常にはらんでいる。なので「私知ってる」といってもコミュニケーションの型が完全崩壊することはない。むしろ、そこから分岐するのだ。
つまり、体験談とは違い、「互いに知っている状態」の先がある。
えてして体験談トークのコアタイムは体験談そのものに宿っているわけだが、読書はそうとはかぎらない。
もちろん、「知っている人間が知らない人間に教える」形も多くあるわけで、その場合はいかにあらすじをネタバレせずにおもしろおかしく語るかが重要になってくる。レビューのようなものだ。
ところが「互いに知っている状態」であれば、そのフォーマットがお互いどう読んだかの討論モードに変化する。ここでいう討論モードはかならずしも怜悧な評論・批評合戦のみを指さない。ゆるい感想の言い合いも含む。
ともかく「知っている人間-知らない人間」の場合と「知っている人間-知っている人間」の場合とでルートが分岐するのが読書コミュニケーションの特性であるといえる。別に読書でなくとも似たようなコミュニケーションが発生する流派はやまほどあるはずだけれども。
今見てる人は無くても
一応
程度や損害によるだろうけど
やってみろ！！！
夫婦ならモラハラモラハラ騒ぐけど、あれは離婚の理由に相手の落ち度として違法性あることが必要だから
相手に明らかな不貞行為による貞操保持義務違反などの不法行為があった場合でないと、裁判では別れられない
日本の離婚は裁判が約１％ 調停が1割(裁判も含む かぶるから) あとは本人同士やちょっとした法律家などを挟んだ協議離婚
一方が不倫してても、両方が別れる気になれば別れられるが、不倫(不貞)があった側からは離婚を求められない
知ってる人は知ってるだろうけど
昔は最低百万円からだったのが、もっと安く50万円程度でも普通になってるようだ【弁護士に払う費用が最低これくらいからじゃないと、弁護士が引き受けなかったという話】
不倫隠し以外にも、性格の不一致で別れたいが相手が別れたくないという場合も、何か落ち度を探したり、漠とした不満を明文化すると、【モラルハラスメント】という概念に当て嵌める事もできたりする
そういう流れがある
親の虐待も配偶者の虐待も、基本的人権侵害は、憲法は国を規定するものだから、民対民では、民法90条公序良俗違反を使う事になる
実際モラハラでは訴えられないが民法90条違反でならナントか しかし夫婦の場合でも、精神的苦痛ではそれが暴力に関するものでも1回に付き精神的慰謝料は十五万円～二十万円と、テレビ裏ネタDEEPナイトで、女性弁護士が語っていた(ややこしいが、暴力があった場合の治療費など含まない精神的慰謝料のこと)
だから弁護士は瑣末的な事として話したがらない 説明もしないが夫婦の場合と一緒
証拠を取る 録音 メモ 日記 【メモや日記は本人の証言も裁判官が認めれば証拠になるので】
実際どうするの？とか書いてた人いたけど、こういう方法もある
でも、アダルトチルドレンに論文がない事も調べてない人たちに、こんな事できるとも思えない気もしてくる
はてなは情報強者を気取るけど、一部それっぽく見せてる人がいるだけで、あとは付和雷同の酷いもの
こんなんだったのかーーーーー！！！！！
と驚かされた
それみたいなもんかなぁ
気づき自分の頭で考えられるようになれば、アダルトチルドレン脱却かもｗ
アダルトチルドレンは、もはやアダルトチルドレン教かもしれないが
あと、こういう方法はあるにはあるが、本人訴訟だと判事がいじめてくるという話もあるので、実質勝つのは難しいかもしれない
近親強姦で、証拠が取れて弁護士が付くだと、時効が10年なのとそれなりに賠償金も取れるので、やりたがる弁護士もいて、これは勝訴判例もある
ネットにはほぼ全ての情報がのっているように見えるがそれは完全に誤解だ
人の記憶、海馬から前頭葉に記憶が飛び脳に知識として定着させるようになるには物語が必要だ
例えば飲みやでも探している時にスマホで検索して一発でダイレクトに店まで行くのとコンビニの店員やキャッチの兄ちゃんに聞いて道に迷いながら行くのとでは全く違う
あの道をこういってコンビニがあって、あの時兄ちゃんに言われたことと複合して記憶されるのとネットでスマホの画面を見つめながら景色もそこそこに最短距離で行くのとでははるかに前者のほうが記憶、知識としての定着度は上回る
なんでもそうだが物事は枝葉末節があるから記憶が知識になり理解してはじめて知恵になる
ウェブページでの単発的な記事を追いブクマをつけてもそこに物語もなく単なる知識欲を瞬間的に満たすだけで永遠に知恵になどならない
たまに無駄に投資、投機関係の記事をブクマしてる人やプログラミングの始め方みたいなものがやたらブクマを集めるだあれだ。知恵にならない知識などむしろ知らないほうがましだ
知恵にならなければ実社会に反映することもできないので意味がない、自己完結のくだらないものになってしまう
自分の回りにはいないけど、情報だけは欲しいだけ入ってくる。結果、目だけは肥えて回りが色褪せて見える。だから付き合えない。結婚できない。できても、こんなものが幸せなのか？自信がない。
それでも、知った方がいいものですか？自分を不幸にする情報はシャットダウンして、あえて無知でいることは愚かでしょうか？
全部知った上で、身の丈にあったところで満足する、それが模範的回答でしょうけれど、実際にそれで満足できずに不幸になる人が多すぎませんか？
意識の高い不満足なソクラテスでいることは、プライドを満たすかも知れませんが、異性の情報においても、それは必要ですか？
際限無く無知でいる必要はありませんが、あえて必要以上の情報をシャットダウンする自律心もリテラシーではないですか？
別にヒステリー女やDV男で満足しろとか言ってる訳じゃないです。ただ、そんなん知って何になるの？と言いたいレベルまで情報収集を極めきって嘆いてる人が多すぎる。情報強者のつもりで自縄自縛に陥っている、哀れな人達。
