  |
はてなキーワード: 改竄とは
田中将大は駒大苫小牧の二年時に150kmを計測、日本代表にも選ばれており、三年時には完全に世代最強投手の扱いだった。
2006年の夏の甲子園でも、センバツ優勝の横浜と並んで圧倒的な優勝候補だった。
一方、斎藤佑樹が注目されたのはその2006年の夏の甲子園から。
それもルックスが端正でハンカチがオシャレだったことの話題が先行しており、実力だけで人気を得たわけではなかった。
それでも斎藤は決勝まで勝ち上がり、田中と対決、あの伝説的な試合を制して甲子園優勝投手となった。
ずっと注目されてきた怪物と、最後の甲子園でブレイクした新星。
要するに、今で言うと田中は早実清宮、斎藤は広陵中村だったのである。
が、その後のマスコミのフィーバーと、それに反感を覚えた天邪鬼たちのせいで、
なぜか今では「高校時は斎藤のほうが評価が高かったがプロに入って田中が逆転した」と思われていることが少なくない。
ゴルフの石川遼と松山英樹の関係を重ねているというのもあるのだろう。
もうひとつ言っておきたいのだが、斎藤佑樹や石川遼がまったく実力のない最低の選手というと絶対にそんなことはない。
そんなことを言えば、甲子園で優勝できなかった投手、プロで1勝もできなかった投手、賞金王になれないプロゴルファー、ツアーで1勝もできないプロゴルファーはどうなるんだという話になる。
マスコミの逆張りをして人気者を叩くといえば今の清宮叩きも相当なものがあり、「練習試合で本塁打を稼いだ雑魚専」だの「甲子園にも出ていないのにゴリ押しでU18主将」だのと貶されている。
プロに上がってどうなるかは分からないとはいえ、現時点で清宮が怪物と呼ばれるに相応しい成績を残していることは間違いない。
マスコミに過剰に反発するのはマスコミを盲信するのと変わらないということを意識しつつ、田中も斎藤も石川も松山も清宮も中村も応援していこうじゃないか。
http://diamond.jp/articles/-/44285
たとえばこの記事だと、斎藤を項羽、田中を劉邦にたとえて、「逆転」を強調している。
http://www.chiakiaso.com/pg68.html
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1325413568
こういうのとか。
VALUというのに興味が出たのだけど、例えばある人のVALUを私が買い占めたら、その人の人生を私が決めていいことにはなるだろうか？
金に困ってる若者のVALUを買い上げて、誰も就きたがらない仕事に売り飛ばす、まさに人身売買、個人の証券化。
それが出来たらなんと便利なことか。
しかし、それは出来ない。
例え、youtuberのVALUを買い占めたところで、売り上げのいくばくかを貰えるわけでも、youtubeで自分の宣伝をしてもらえるわけでもない。
堀江貴文氏はその辺の感覚流石で、ホリエモンカードというものを出していた。
プロ野球チップスの発行数は、公式のアナウンスを信じる以外にないが、ホリエモンカードはブロックチェーンで売買履歴が押さえられているので、水増し発行がないことが担保されている。
強みはそんなところしかない。
それは公式も言ってる。
身近なところでも、例えばそのうち、オンラインゲームのアイテムの売買に使えるんじゃないかと思う。
発行枚数や売買履歴の改竄が出来ないならば、運営も個人間取引に寛容になれる。
ブロックチェーンで発行数されたアイテムの決済もまた、ブロックチェーンの暗号通貨。
ブロックチェーンはそういうところから広まっていくしかないんじゃないかと思う。
例えば、本当にさっきの例が起きたらどうなるだろう？
youtuberのVALUが買い占めたらとして、買い占められたyoutuberが「あれはネタ、なんの強制力もないし、俺は何１つ従わない」と発言したら？
それは至極当然の発言だとしても、騒ぎになる。
課金しまくったオンラインゲームが停止するくらいの意味でしかないのだが
、VALUに群がった当人たちは投資のつもりだったりすると非常にまずいことになりそうに思うのだ。
投資は自己責任という言葉も通じなければ、そもそも投資ですらないという言葉も通じない可能性がある。
https://anond.hatelabo.jp/20170729065340#tb
読んでて鼻血が出るかと思いました。被ってるエントリーを見つけてしまいましたが、折角なので投稿します。
本件に関しては、マスコミで騒いで貰ってでも明るみに出してほしいです。これはSTAP細胞や化血研のスキャンダルと同じくらいのインパクトのある話だと思っています。
割と大ごとなのに、記事のような状況が何故発生したのか、考えてみました。
恐らくですが、報告を受けた全ての機関が、何が本質的に問題化を洗いだせず、適切な窓口に繋げなかったからかなと。
この件の本質的な問題点は、不正をしたと認める認めない、にお金が支払われる支払われないの話を持ち出したのと、病院側が不都合なデータを意図的に不採用にしようとしたかもしれない（のとあといくつかあるけど他のエントリー見てください）のようなところにあります。これは立派な法令違反です（医薬品の臨床試験の実施の基準に関する省令）。
変な話、被験者には連番で番号が振られているため、当該被験者の存在自体を完全に無かったことにするのは結構難しいです。不採用にするためにどうにかこうにか理由を付けようにも、後から適当に「薬を飲んでなかったから」とか事実でない理由を付けてしまえば、データの捏造・改竄となってしまいます。
一番ダメなのは、どうにかして都合の悪いデータが無かったことにされた場合です。この医薬品が薬事申請され、承認されてしまった後、高い確率で大問題になる。
実際のところ、漫画 フラジャイルの治験の話のように、都合の悪いデータをいじったり消したりて、無理に世に薬を出すような事は実際は割に合わなさ過ぎてできません。ただでさえ、市販後には治験と比べて色々条件の異なる患者（年齢、体質、既往歴、併用薬）が薬を使うため、どの相の治験でも明らかにおかしなことが起きれば、リアルワールドではもっと多くの事が起きると容易に想像されます。なので、多分この薬は開発中止となり世に出ないのではと思っています（甘いかな？）。
とまぁつらつら書きましたが・・
本来であれば、対応すべきは厚労省ですね、厚労省が適切な窓口に繋ぎ、企業に対して調査を行い、当該医薬品が承認申請された際にはこの被験者のデータや記録が削除されたり、不適切な形で改竄されたりしていないかを調査すべきなのだと思います。
でもされない、本当に本当に残念です。
あと、今回被験者の健康には問題がないってところも厚労省が動かなかった一因かもしれないですね。本質を考えるととてもとてもダメなんですが・・
http://anond.hatelabo.jp/20170606174324
『原発は安全』な神話も御用学者によって"作られ"てきた。そして事実は暴かれた。メルトダウンによって。
https://ja.wikipedia.org/wiki/%E5%BE%A1%E7%94%A8%E5%AD%A6%E8%80%85
現代における用法を定義することは難しいが、学術的な調査を改竄ないしは恣意的に解釈し、権力者や統治者、ないしは依頼者に都合の良い結果を導き出す者がこう呼ばれる。一方で、権力者などへの批判側が恣意的な解釈に基づき自らに都合の良い結果を導き出していることを指摘・批判する学者に対して、反権力側がレッテル張りとして用いる場合もある。
現代日本においては水俣病の例が嚆矢である。1956年（昭和31年）、熊本大学医学部の研究チームにより、有機水銀原因説が有力視されたのだが、同年11月12日には厚生省食品衛生調査会常任委員会・水俣食中毒特別部会が大学と同様の答申を出したところ、厚生省は翌13日に同部会を突如解散。1960年（昭和35年）4月、日本化学工業協会が塩化ビニール酢酸特別委員会の付属機関として、田宮猛雄・日本医学会会長を委員長とする「田宮委員会」を設置。後に熊本大学医学部研究班も加わることとなった。有機水銀説に対する異説として清浦雷作・東京工業大学教授らがアミン説を発表し、彼らの主張がそのままマスコミによって報道されたため、原因は未解明という印象を与えた[1]。
詳細はナイロンザイル事件を参照のこと。1955年（昭和30年）、日本の登山者がナイロン製のクライミングロープ（以降ロープと記述する）を原因として死亡した。ナイロンは引張りについては従来の麻のロープよりも遥かに丈夫だが、鋭利な岩角などに擦れた場合には容易に切断される。これはすぐに明らかになったが、大阪大学工学部教授で日本山岳会関西支部長の篠田軍治は、事前の実験でザイルが容易に切れることを確認した上で、公開実験ではあらかじめザイルが接触するコンクリート製のかどにヤスリがけをして十分な丸みをつけた状態で、作為的な実験を新聞記者等の前でデモンストレーションしてみせ、ロープメーカーの東京製綱および日本山岳会と共謀して、犠牲者に対する誹謗中傷運動を山岳雑誌・化学学会誌などで長期にわたって続けた。法改正で安全規格が定められ交付されたのは1975年（昭和50年）、最初の事故以降に確認されているロープの欠陥による死者（通産省の調査した範囲内での数字）は、20人を越えるとされる。なお、偽装実験をマスコミの前で実行した篠田軍治は、日本山岳会の名誉会員推薦により、1989年（平成元年）に評議委員会の全会一致で同会の名誉会員になっている。
哲学者の山脇直司東京大学教授は、安保理決議のないままブッシュ政権主導で2003年3月イラク戦争が始められたことへの日本政府の対応について、「アカデミシャンとしての私が今一番一番懸念していることは、アメリカを無邪気に支持し、フランスなどを非協力と言って批判する小泉首相や川口外相のお粗末きわまりない答弁の背後にいる『外務省お抱えの御用学者』の存在です。」「外務省お抱えの『御用学者の知的退廃』を暴く必要を今痛感しています。」[2]と書いている。また、2003年12月からの自衛隊イラク派遣を決定する過程について、政治学者でイスラーム教シーア派に詳しい松永泰行日本大学助教授は「私の知る限り、政府は研究者の実力よりも、政治家や官僚の都合で彼らが望むことを言ってくれる御用学者を起用している」と述べた[3]。
日本たばこ産業に研究費を支援してもらうかわりに、タバコを擁護する発言を行うなど、消費者の健康よりも特定企業の利益を優先するような行為をしている学者を指して使われた事例がある。[4] また、メーカーから多額の研究費を受け取っていたために、タバコと乳幼児突然死症候群との関係があるという論文が、根拠が乏しいというように書き換えられてしまったとの指摘が存在する[5]。 タバコ産業等からの研究助成については学界において問題視されており[6][7]、2003年10月22日に日本公衆衛生学会は学会員に対し「たばこ産業及びその関連機関との共同研究、及び同産業等から研究費等の助成を受けた研究を行わない。」との行動宣言を発している[8]。また、国際的にもたばこ産業による研究助成等について全面規制を求めるたばこ規制枠組条約のガイドラインが追加採択されている[9]。
今日の現実の社会の中では、例えば有力な学者が政府の公共事業などの施策に対して、自己の信念に基づく意見、思想を審議会などの場で反映させる為に、そうした機関に呼ばれる立場を確保するべく、ある種の手練手管として、権力へのおもねりと自己の真の主張を両天秤にかけながら駆け引きをする場合がある[10]。そのため御用学者か否かの線引きは困難な側面を有する。駆け引きに失敗して結果として権力へのおもねりの手練手管を権力に利用されるだけの結果となったときには、結果として御用学者呼ばわりされてやむを得ない側面がある一方、駆け引きに成功して自己の信念を政策に反映させることに成功した場合には、反骨の策士と評価される場合もありうる。また原子力発電の分野では、研究に多額の費用がかかることから権力におもねり、「安全神話」のお墨付きを与えることで電力会社等の支援[11]を受ける例があり、このもたれあいの関係を「原子力村」[12]と評される。
ごめんなさい、なんか追記とかトラバとかしようと、いろいろしてたら間違えて消しちゃいました。
一応補足すると、上流工程の人と下流工程の僕を比べたわけじゃないです。
というか、先月とか今月は開発の工程だから開発してるけど、僕は要件定義から関わってるから別に下流工程専門ってわけでもないです。
比較した人はコーディングもすこしはしてましたが、メインの仕事は「テストやる要員」で、テスト仕様書（≠テストコード）書いて、画面操作する仕事をしている人です。
いやなんか、愚痴にもほどがあるだろってぐらいの愚痴なので、マジで反省します。
反省したいけど、後日見返したときに心がざわつきそうなので、日記は改竄しちゃいました、申し訳ないです。
モチベーションが著しいレベルじゃないぐらい急降下したので、さっさと帰ってきた。
というのも原因があって、ひょんなことから、とある人の月給を知ってしまった。
わかってる、重々わかってる。
僕がどんなにコードを書いても、どんなにバグを修正しようと、どんなに仕事が便利になるツールを作ろうとも、どんなにその人にコーディングの基礎の基礎を教えようとも、
重々わかっている。
たとえ、nullと空文字の違いがわからなくても、内部結合と外部結合の違いがわからなくても、いいじゃないか。
そんなことと、その人を評価する指標にはならないに決まってるじゃないか。
ダメだダメだ、こういうことを考えるのはよくない、非常によくない、他人のその一面だけを見て、勝手に自分の方が上の存在だ、みたいな思い込みを無意識でして
そうじゃないことがわかった途端にイライラするの、非常によくない
反省しよう。
僕もよくないところはたくさんあるし、そもそも
良いとか、悪いとか、
そういう話じゃないし。
https://twitter.com/piyokango/status/844361226767380481
http://www.freezepage.com/1490165400GAZZVSXBDT
である。キャッシュの freezepage ですまんが、まあいいだろ。
これ自体はハセカラ界隈のスクリプトキディが show tables かなんかを実行する jsp 一枚仕込んだというだけの話なのだと思うが、問題は JINS の対応だ。
t_jins_gmo_brandtoken_cancel_if_rireki
t_jins_gmo_brandtoken_change_if_rireki
t_jins_gmo_brandtoken_entry_if_rireki
t_jins_gmo_brandtoken_exec_if_rireki
などといったテーブル名から、おそらく GMO ペイメントトークン決済を利用しているものと思われる。これはクレジットカード番号を一切 JINS 側のサーバーに通過させなくていいような構成になっており、今回のこの事例から JINS 側が保存していたクレジットカード情報が流出した可能性は、恐らくない。
しかしながら今回攻撃されたドメイン https://www.jins.com/ にはクレジットカードの入力ページが存在している( http://s.ssig33.com/gyazo/d09c0f5915f84eab8c8712eb0d23150d )。
この為、こうしたページも不正に改造されていた場合、攻撃を受けていた期間に入力されていたクレジットカード番号が不正に流出している可能性がある。
ところで JINS 側はこうした問題を認識して今朝未明にメンテナンスを行なっていたようである( https://www.jins.com/jp/news/2017/03/322.html )。
推測するに、調査をしたところクレジットカード番号入力ページの jsp なりなんなりが改竄されていた事実はとりあえず確認できなかったので、特になんの発表もしていないのであろう。ところで JINS は 4 年前にもサイトをクラックされクレジットカード番号を流出させた経験がある( https://www.jins.com/jp/illegal-access/info.pdf )。にも関わらずこの対応はちょっとおざなりすぎではないだろうか。
現実に可能性は低いと思うが、例えば以下のような可能性が考えられる。
1. ハセカラ関係者っぽく見せかけた低レベルのクラック ↑ を行なう。
2. その裏でクレジットカード番号入力ページに本気のクラックを仕掛ける
3. 1. でしかけたハセカラクラックが露見する前に 2. のクラックについては撤収して 1. の証拠だけを残しつつ 2. の証拠を消す
このようにすることで、クレジットカード情報を収集していたという事実を関係各位に認識させる時間を可能な限り遅らせ、不正な買い物などをする時間の余裕を稼ぐことができる、かもしれない。もちろんこんなことが行なわれた可能性はほとんどなくて、事実はバカなスクリプトキディが適当に遊んでいただけなのだと思う。しかしこの可能性を無視していいとは思えない。
こうした可能性について調査するには 7 時間では全く足りないし、あるいは一度外部に大々的に告知をしてサービスを停止するなどの対処も必要ではないか。
JINS は 4 年前のクラック被害から何も学んでおらずユーザーデータや資産を防護する基本的な姿勢が欠けているとしか思えない。
かなり正確な分析は不破雷蔵氏がされているのでリンクさせて頂く
http://www.jgnn.net/ls/2016/12/post-14336.html
Q1,「格差」は日米共に広がっているのか？ A1,広がってはいる。
Q2,どちらの方が「格差」は広がっているか？ A2,アメリカだ。
Q3,どちらの「格差」の方が深刻か？ A3,それは日本だ。下位層(90%)が下がっているから
日本の2011年以降、アベノミクスで下位90%の所得が回復している事を切り捨てている事
A5,【私】は大きな問題では無いと考えている。数値は変えれているが、等間隔だからだ。
今回は違うが、酷いグラフだと対数で表示されていたりもする。 今回のは見れば分かる。
そもそも、下位90%って、=上位10%以外の殆どの人って事だろ。
最上位1%との比較では 最初から人数では90倍の差があるわけだ。
つまり、
池上彰氏が凄い(そして厄介な)のは、異なる層に対して「同じ話」を使って「別の見解」を持たせ、しかし「結論」は一致させてしまえる事だ。
今回の件で言えば
そのまま「信じて」しまう層には『日本の格差が広がっていてピンチだ。』と「騙せ」て
「見破る層」には『より深刻な危機を意識』させる。 でも危機感、問題意識は一致させられる。
これは池上彰氏が週刊こどもニュースで解説されていた時からの特徴だ。
こども(実際の視聴者は年配者だったらしいが……)に現実のニュースを大幅に捨象して分かり易くし解説する。
要は要約なんだけども、 時に『虚構』を混ぜて焦点を絞る能力。
一例として、株式市場の説明の際。野菜の株を使って説明する等。分かり易くするために完全な嘘を大胆に混ぜる。
これが、異なる層に対して「同じ話」を使って「別の見解」を持たせ、しかし「結論」は一致させてしまう。氏の最大の特徴を強化したのだと思う。
これは、やっている事は単なる【要約】のように見えるが、実は違う！ 池上彰氏は【待って】いるのだ
実際には極めて広い見識で問題を先読みし、問題が十分に悪化して【要約】可能、≒一般人に分かり易く解説可能になったタイミングで切り取っているのだ。
話は逸れるが、
氏がバングラデシュでテロの事後取材をしていた時、まさにその時に偶然、氏の目の前で新たなテロが起きた！
池上さん躊躇無く。現場に突っ込んだからね。 普通する？そんな事。 イカれてるだろ……。あのおっさん……。
他にも池上氏の番組を見てると、さり気なくブッ飛んだ行動と取材をしているところがマレに良く見れる。
池上彰氏は単なる解説おじさん ではない。狂気を秘めた報道記者なのだ。
▽いつも思うんだけど、さ～ぁ……
だって最上位者(ビル・ゲイツとか)の所得や資産が2倍になっても、低所得者層の所得と資産が半分になっても
「格差の広がり」は「同じ」だけど、 前者より後者の方が 遥かにヤバい。
正直に貧困、階層化、貧困の再生産、階層の固定って言えんかね？
いや、確かに「格差」は構造よ。 でも問題の焦点は貧困か、それを無視しても貧困の再生産な訳じゃん。
じゃあ解法は主に2パターンで、「『構造』の改良」か、「問題≒貧困の改善」のどっちかか、両方じゃん。
小池百合子都知事の件で山本一郎はズレた発言を繰り返して随分とツッコまれている
http://b.hatena.ne.jp/entry/bylines.news.yahoo.co.jp/yamamotoichiro/20160915-00062196/
“ この件に関しては”などというコメントも見られるが、こういうのは別に今に始まったことではない。
既に指摘されているが、人権周りの分野でも非常に古い感覚を発揮して、AV女優問題なんかは記憶に新しい。
このあたりを見ると山本一郎の素の感覚はただのオッサンであることがわかるし、現代のオッサンが標準装備している“ 謝ったら死ぬ病” も当然のように持っている。
そうなれば、はてなを始めとするネット住民からは評価が低くなりそうだが、何故かネット上での評価は異様に高い。
最近山本一郎が名を上げた事件といえばAppBank元役員横領事件だ。
http://bylines.news.yahoo.co.jp/yamamotoichiro/20160206-00054186/
上場時の調査不足の罪があるものの、横領そのものはAppBankが一応は被害者ではある。そこに「暴力団関与の疑い」とブチ上げることで、AppBankを一躍ネット社会の敵に仕立て上げた。
山本一郎は散々“どうして警察に相談しないんだ”と、あたかも暴力団の関係がバレるから相談しないのだろうと詰め寄っていたが、実は既に検察に届け出ていたことが判明し、その後の調査でも暴力団の関与は報道されていない。
http://www3.nhk.or.jp/news/html/20160913/k10010683541000.html
元役員への強制捜査が7月で９月に逮捕というのは随分と慎重に証拠を固めたようだが、暴力団の情報がマスコミも検察からも出てこない。またこの件に山本一郎は急に言及しなくなってしまった。
こんな状況にも関わらず、AppBankを叩いたことを撤回する人間は本当に少ない。
さらに山本一郎の名上げを１つ遡るならグラブルガチャ事件だろうか。
http://www.4gamer.net/games/238/G023885/20160108049/
この記事で面白いところは、1度も“ グラブルは確率操作している” とは言ってない点である。後半で確率操作に対してかなり文字を割いているが、“仮に確率操作しているゲームがあるなら” 詐欺とか返金とかの問題になりますよね、という一般的な話をしている。
散々グラブルの話をした後に、そういうの付け加えるのは意図的なものだろう。
そしてよく読まない読者の中ではそれが真実になり、拡散される。
http://blog.skky.jp/entry/2016/02/25/195556
こんな事実は無かったし、もちろんこのブログも撤回はしていない。
この件は消費者庁が動いたが、結果的に問題がなかったことが確認されている。
http://this.kiji.is/111734236282963445
消費者庁が出現率の表示や設定を調査して「景品表示法違反は認められない」と結論付けたことが4日、関係者への取材で分かった。
“調査の日だけ出現率をいじってるんだろ”みたいな意見もあったが、調査員が電話でアポ取って当日会社に出向いて、サーバーをパカっと開いて、中にある“確率”とやらを、「ふむふむ、正常ですね」って見て帰ると思っているのだろうか。消費者庁ナメられすぎである。こういうのは返金騒動などに備えてログが残っているし、プラットフォームや通信社にも残っている。排出履歴は簡単にランダムサンプリングなウラが取れるから（適当なプレイヤーに直接確認するのが難しくない）、改竄するのは難しい。
数十万支払って特定キャラクターが出ないという話については、長期運用で毎月SSRを追加するせいでSSRの総数が150以上にまで増えており、3%のSSR排出設定（業界標準）では偏りが無くとも１種類のSSRあたり0.02%程度になってしまう。
人為的な操作が無くとも、１種類だけ狙うと有り得る話であった。最初に問題視されていたイベントの排出も、公表通り他のSSRより確率が高くなっていたようだ。
両事件とも、山本氏はネット民で不人気の対象を叩くことで、話に粗があってもネット民を味方につけ、検証に時間がかかることで、真相が明らかになっても１度山本氏に味方してしまった住民は、謝ったら死ぬ病のために撤回できず、続報を無視するしかない、というカラクリになっている。
逆に言えば今回は、小池百合子がそれほどネットで不人気ではなかったことと、各所からのツッコミが素早く行われてしまったという２点が山本一郎の誤算であった。
もし小池百合子が不人気で、問題のツッコミに時間がかかるものであれば、マックスむらいのごとくネット住民の叩きに乗じて“勝利”し、検証が出た頃には関係ないよという態度を取ることができただろう。
山本一郎氏は女性と社会的弱者にこの手の人気の読み違えをしやすく、それは彼の周辺がそれらを下に見る感覚のオッサンで揃っているからであろう。人権に弱いと言われるのもこの感覚のズレが原因である。（つまり、人権以外でもズレたことを言ってるがネット住民に気づかれないというだけ）
もちろん新聞各社や雑誌社が当然にやっていることではあるが、普通なら信用におけないという情報でも山本一郎は１人の感覚で信用の判断を下してしまうため、自信満々にタレコミ元の情報に乗っかる。その自信満々が人気の秘訣となり、人気が出れば出るほど、世間に自分の情報を発信したい理由のある人間が山本一郎の元に集まる。
これは非常に危うい。
雑誌社にそっぽを向かれたような怪しい情報ほど山本一郎を求めるし、山本一郎はポジショントークとなる。
AppBank事件ではタレコミ元は横領張本人の元役員のようだ。
山本一郎は彼を信じすぎたのだ。
長年スキだらけの横領を繰り返しても周囲を騙し通した元役員ならば、その説明は説得力にあふれるものだったのだろう。男泣きでもしてみせたのかもしれない。さすがに途中でヤバいと気づいたのか「関係者の証言が事実であるとするならば」と記事に追記し、マックスむらいにツッコまれているが。
グラブルガチャ事件でも、山本一郎が元々ソーシャルゲームのコンサルタントだったという点を覚えておかなければならない。
今回の件で確率表記と上限設定を行ったグラブルに対して、モンスト、白猫、パズドラという競合上位に当たる主だったタイトルは未だ確率表記をせず、消費者庁への資料提出などもした情報が無い。１人あたりの課金額がグラブルより上のタイトルだってあると思われるのだが、山本一郎は奇妙なほど言及をしない。ソシャゲを毛嫌いするネット住民達は山本一手のひらで転がされ、別のソシャゲの後押しをした形になる。
もはや感嘆に値する。
当然、全てを山本氏が意図してやっているわけではない。だが人間関係と立場があり、巨大な自信と謝ったら死ぬ病を持ち、怪情報が舞い込んでくれば自然とそういう結果になる。
山本一郎の発言のたびに、その後ろに情報元というものがあり、情報源は情報だけでなく意図を持ち、その意見を受けて山本氏が発言しているというのを意識するべきだ。
今回の小池百合子の件では、山本一郎の背後にどういった人物が居るのか想像するのは難しくはないだろう。
今後においても、注意した目で見ることは大切である。
歩きスマホにぶつかるtogetterがバズってるじゃないですか。
そういえば自分も似たようなことをやっていたんですよ。でもチンピラ臭のする人にも近づくし、ただ実際にぶつかることはしない(絶対避ける)っていうのを徹底してましたが。いやこれ威張るところではないか。
今回の件で、自分がまたコミュニケーション苦手マンであることを再認識させられてしまいました。
思えば昔から、人とどうやって接したらいいかわかりませんでした。
小学生の頃から、国語の試験などでよくある「(作者|登場人物)の気持ちを考えよ」が全くわかりませんでした。
人との会話で自分の都合のいいように記憶を改竄して話してしまい、後で話の整合性が取れなくなるとしどろもどろになる、ということがよくありました(今でもたまにやってしまいます)。
誰かに電話をするときは、たとえ相手が気の知れた人であっても、話す内容をすべて書き下して、一旦深呼吸してからでないとかけられません。
相手に2,3回以上聞き返してもよく聞き取れなくて適当に相槌を打ったり(これは普通の人でもよくあることだと思いますが……)、自分が話しているときに突然ろれつが回らなくなって、一旦会話が中断してしまう、なんてことも。
これが一番困っているのですが、「カクテルパーティー効果」がわかりません。人混みの中(……にかぎらず同じ空間に1グループでも別の話をしている人がいる場合も)で特定の人の声だけを抽出するのはとてもじゃないが無理です。ものすっごい頭を使うし、ボロボロ聞き落として話しの内容がなかなか理解できません。何より他の人達はそんな空間で平気で会話をしているので、簡単そうに会話をしている中で自分だけがいまいち輪に入れてなくて、悲しくなります。
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く 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 のような場合は期限切れがあってはならないので、パスワード等を預かる認
違うのが違う。
その管理されること、管理という庇護を分け隔てなく受けることができることを潜在的に望んでいるということ。
情報統制・究極の管理社会はSFでよくやってるようにVR世界へのフルダイブ社会だよ。
技術さえ確立すれば脳に誤解させる方が圧倒的にコスト削減になる。
例え消えても人格をAIが再現すれば誰も他人の死を実感することなく死ぬことができる。
同時に止めないといけないならメンテナンスという概念を植え付けてもいいかもな。
そういう世界を死の恐怖をガソリンにして人類の叡智の結晶であるハイテクノロジーが作り出そうとしている。
人類はAIという子どもにしてすべての人類の母となる存在を作ろうと躍起になっている理由。
そして統制する何者かというのはそのマザーこそが統制する者になる。
