ウエストワールドは新しいシーズン3の予告編で私たちにまったく新しい世界(または2つ)に紹介する準備ができています。前に公開されたティーザーはほとんど完全にアーロン・ポールの新しいキャラクターに焦点を当てていましたが、この予告は大量のおなじみの顔を思い出させます。しかし、ウエストワールドの伝統とですが、出来事はかなりミステリアスです。下記のウエストワールドシーズン3の予告の分析の中で、新しいシーズンのパズルのいくつかを解決しようとしています。
ウエストワールドシーズン3で実際のウエストワールドにあまりにも多くの時間を費やすことを期待しないで下さい。シーズン2は多かれ少なかれ西部をテーマにしたロボットパークを時代遅れなものにする形で終わり、シーズン3は現実の世界で起こることをほのめかしました。案の定、ウエストワールドのシーズン3の予告編はまさにそのショットで始まります - (未来的な)現実の世界。「私たち全員が果たすべき役割を担っています」とドロレス(エヴァン・レイチェル・ウッド)は言うのが聞こえます。「この世界にはマシンがありますが、...私たちとは違います。」
「あなたと私には母親も父親もいません」とドロレスの声は続きます。彼女は誰と話しているのでしょうか? さて、私たちが最初に見掛けるのは、テッサ・トンプソンのシャーロット・ヘイルで、空飛ぶ自動車で散歩しています。彼女は実ににクールなケープジャケットを着ていて、タバコに火を点けます。もちろん、シャーロット・ヘイルは死んでいるので、これは本物のシャーロット・ヘイルではありません。ドロレスはシーズン2で彼女を殺害した後、彼女をシャーロット・ヘイルのロボット本体の中に入れ、公園外に連れ出しました。それから、さらに混乱させるために、シャーロット-ドロレスはドロレスの古いボディを再構築しました。しかし、彼はシャーロット・ボットをキープしました。それで今、誰がシャーロットの内側にいますか? まだ分かりません。
「私たちは一人です」とドロレスは続けます。ここでは、ドロレスはいくつかの球体(オーブ)を指で触れます。しかし、これらは単なる球体ではありません。ロボブレインです。ドロレスがウエストワールドを脱出した時、彼女はハンドバッグにいくつかのブレインオーブで詰め込みました。しかし、私たちはまだ彼らの身元の多くを知りません。明らかにこれらの1つがシャーロット内部にあります。また、ドロレスがバーナード(ジェフリー・ライト)のブレインオーブを密輸したことも知っています。しかし、私たちは後で彼を取り上げます。
ドロレス:「私たちは彼らより賢くなければなりません。さもなければ、彼らは私たちを見つけるでしょう。そして、彼らは私たちを殺すでしょう。」彼女が語っている「彼ら」は、デロスの人々、ドロレスの出身であるロボットパークを所有し運営している非常に裕福な企業だと思われます。「私たちを殺す」部分を強調するために、私たちは誰かが背中に銃を持ってゆっくり歩いているのを垣間見ます。注: この予告には、急いでどこかを歩いている人の背中のショットがたくさんあります。
次に、アーロン・ポールの新しいキャラクターが、引き渡されたドロレスを握りしめている様子の雰囲気のあるショットを得ます。彼の裏取引は何ですか? シリーズにおける彼の役割は何ですか? 彼は「サイエンス、ビッチ!」と言うでしょうか? なるほど。「私はこの世界を本当の意味で示すつもりです」とドロレスはナレータの声で言います。
草が茂った丘の中腹のショットは、あらゆる配線を引き抜いて、誰かが腕を引っ張り出しいるのを見事に捉えています。これは明らかにホストロボットです。しかし、それは誰ですか? 「なぜ、彼女はあなたを連れ戻すのですか?」私たちがこの腕が誰のものであるかの良いショットを得る前に声が尋ねます…
...それはバーナードで、今ではいつもよりずっと大きなひげをたくわえています。「フォードは、ある理由で私たち一人一人を作った、ドロレスでさえも。」とバーナードは言います。シーズン2の結論は、バーナードとドロレスを正反対として設定しました。 バーナードが反対するのに対し、ドロレスはあらゆる方法であらゆる人間を殺害しようとしています。「私は、私を助けることができる誰かを見つけるために戻ってきた。それに関しては、彼女を阻止するのに十分強い誰かが…」とバーナードは言います。
少なくともこの予告の編集に基づいている人は、メイヴ(タンディ・ニュートン)です。 シーズン2の終わりには、メイヴはほとんど死んでいるように見えました。しかし、それはオタクのデロス技術者フェリックスとシルベスターが彼女を連れ戻すことを意味しました。そして、彼らはおそらくそうします。そして今、彼女は別の世界にいます…
その世界は正式に「Warworld」と呼ばれており、第二次世界大戦のシナリオの真っ只中に見えます。過去2シーズンを過ごしたとしたら、次のように考えるでしょう。「このショーが何を必要としているか分かりますか? ナチス!」あなたは運がいいですよ。ウエストワールドは本当にメイヴとドロレスを対抗させるシーズンを設定しているのでしょうか? 心のどこかで、これは偽物だと思っていますが、誰が分かりますか。
予告の残りの部分は、「We'll Meet Again (また会いましょう)」- スタンリー・キューブリックの博士の異常な愛情によって有名になった歌 - を歌うヴェラ・リンに設定されています。傍注: この曲はストレンジャー・シングスの最新シーズンにもフィーチャーされていたので、今はちょっとした時間があるはずです。曲が再生されると、ドロレスがシャーロットをベッドでいちゃつくこの人目を引く瞬間を含め、モンタージュのショットが得られます。繰り返しますが、どのロボットの頭脳がシャーロットの体内にあるのかはまだ分かりません。そのため、誰がいちゃついているのか分からないのです。それがテディ(ジェームズ・マースデン)かもしれないと思っているなら、ドロレスの愛は前のシーズンに興味を持っていますが、そうではありません。シーズン2が終了した後、ショーランナーのリサ・ジョイは、ブレインオーブのどれもテディに属していないことを認めました。
もう一つの不思議な瞬間: ドロレス、アーロン・ポールのキャラクター、そして他の人たちは公園のたくさんの地下トンネルの一つのように見えるものを歩いています。彼らは戻ったのですか? もしそうなら、なぜ?
この世界で人間がロボットに向かっているのはどういうことなのかを思い出させるために、何人かの武装した男が無力なボットを撃墜しているのが見えます。「私はあなたの世界は、私のとはかなり違うだろうと思いました」とドロレスは言います。「まったく違いはありません、ありますか?」そうじゃない! カウボーイは少ないですが。
シャーロットが巨大なRiot Controlロボットのところを歩み寄るので、「すべてを壊すのにはそれほど時間がかかりません」とドロレスは言います。ここで邪悪な計画は何ですか? 本格的なロボットの黙示録? もしそうなら、私は全面的に支持します。私たちを破壊しなさい、ロボットの支配者!
おぉ、素晴らしい、この男が帰ってきました。小さいヘムズワース。
バーナードは気が狂い、デロスで働いていると思っている男を攻撃します。彼らは何らかの理由で血のりでいっぱいになったトレイを動き回っています。
かわいそうなアーロン・ポールのキャラクターは、このショットで建設中の超高層ビルで殺されそうになっています。アーロン・ポールは恐ろしい感情的苦痛ではないキャラクターを演じることができますか? 私たちは決して分からないと思います。
謎に包まれた人物が汚い部屋を撃ちまります。この銃撃兵はだれですか?
なぜ、それは黒服の男としてのエド・ハリス、別名ウィリアムです。彼は昨シーズン、自分が見つけたどんなひどいループにもとどまっていて、明らかに良き時代を見ています。彼は逃げるのでしょうか? ロボット形式で、彼は退屈な娘と再び対話するのでしょうか? 気になりますか?
アーロン・ポールのキャラクターは...バーナードを追い求めて来た? おそらく? それは明らかにジェフリー・ライトです、しかし、彼のあごひげはより短くて、そして彼は予告の他の場所よりはるかに良い服を着ています。これは別のロボットでしょうか? バーナードに影響を与えた実生活の男、アーノルドへの逆襲? 憶測して下さい。
やぁ! ヴァンサン・カッセルがいます。彼は誰を演じていますか? 多分、強力なデロスの人間。そして、彼もおそらく邪悪です。なぜなら、彼を見て下さい。カッセルが最初にキャストされたとき、Deadlineは彼が「新しい悪役」であるとレポートしました。しかし、他の詳細は秘密にされていました。
シャーロット(または彼女の中にいるボットブレイン)が誰かに向かって撃っています。全体として、これは効果的な予告です。今シーズンは、昨シーズンに起こったことの継続としても、まったく新しいものへの拡大としても納得させられます。ウエストワールドシーズン2はしばらく私をすり減らしましたが、これは大きな改善に思えます。
ウエストワールドシーズン3は2020年に封切りです。
7/24/2019
「ウエストワールド」シーズン3の予告の分析
7/23/2019
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
なぜ、OOPから移行する時なのか
Ilya Suzdalnitski
OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました…
それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。
非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今やOOPの有名な批判者です!
すべてのソフトウェア開発者の最終的な目標は、信頼できるコードを書くことです。コードにバグがあり信頼性が低いなら、何も問題はありません。そして、信頼できるコードを書くための最善の方法とはどんなものですか? 単純さです。単純さとは、複雑さの反対です。従って、ソフトウェア開発者としての私たちの最優先の責任は、コードの複雑さを減らすことです。
免責事項
正直なところ、私はオブジェクト指向の熱狂的ファンではありません。もちろん、この記事には偏りがあります。しかし、私にはOOPを嫌う理由があります。
私は、OOPに対する批判は非常に敏感な話題であると理解しています - おそらく多くの読者を怒らせるでしょう。しかし、私は正しいと思うことをやっています。 私の目標は、怒らせることではなく、OOPがもたらす問題についての意識を高めることです。私はアラン・ケイのOOPを批判しているのではありません - 彼は天才です。OOPが彼の設計通りに実装されていることを願っています。私は、OOPに対する最新のJava/C#のアプローチを批判しているのです。
私が怒っていることも認めます。非常に怒っています。私は、OOPが非常に上級の技術的立場にある人たちを含む多くの人々によってコード構成の事実上の標準と見なされているのは明らかに間違っていると思います。多くの主流の言語がOOP以外のコード構成に代わる他の方法を提供していないのもまた間違っています。
くそ、私がOOPプロジェクトに取り組んでいる間、私自身、多くの事に格闘していました。そして、なぜ私がこれほど苦労していたのか、私にはまったく分かりません。もしかして、私が優秀ではなかったのか? いや、私はもう少しデザインパターンを学ぶ必要があったのです(私は思った)! 結局、私は完全に燃え尽きました。
この記事では、オブジェクト指向から関数型プログラミングへの10年に渡る私自分の経験に基づく旅を要約します。全部見ました。残念ながら、私がどれほど努力しても、OOPのユースケースは見つかりません。個人的にも、OOPプロジェクトが維持するには余りにも複雑になったため、失敗するのを見た事があります。
TLDR
オブジェクト指向プログラムは正しいものに代わりとして提供されています...
-- コンピュータサイエンスのパイオニア、エドガー・ダイクストラオブジェクト指向プログラミングは、手続き型コードベースの複雑さを管理することを念頭に置いて作成されました。言い換えれば、それはコード構成を改善することになっていました。OOPが単なる手続き型プログラミングより優れているという客観的でオープンな証拠はありません。
残念ながら、OOPは対処しようとしていた唯一のタスクで失敗します。それは理論上は良さそうです - 私たちは動物、犬、人間などのきれいな階層構造を持っています。しかし、アプリケーションの複雑さが増し始めると、それは全くうまくいかなくなります。複雑さを軽減する代わりに、ミュータブル状態を無差別に共有することを奨励するため、その多数の設計パターンでさらなる複雑さをもたらします。OOPは、リファクタリングやテストなどの一般的な開発方法を不必要に困難にします。
私に賛成できない人もいるかも知れませんが、実際のところ、今のOOPは正しく設計されていません(Haskell/FPとは対照的に)。それは適切な研究機関から出たことはありません。私はゼロックスや他の企業を「適切な研究機関」とは見なしません。OOPには、それを裏付けるための何十年もの厳密な科学的研究がありません。一方、ラムダ計算には、関数型プログラミングのための完全な理論的基礎を提供します。OOPはそれに匹敵するものは何もありません。OOPは主として「起こった事(just happened)」です。
OOPを使用することは、特に更地の(greenfield)プロジェクトでは、短期的には無害のようです。しかし、OOPを使用することによる長期的な影響は何ですか? OOPは時限爆弾であり、将来的にコードベースが十分に大きくなったときに爆発するように設定されています。
プロジェクトが遅れ、締め切りが間に合わず、開発者が燃え尽きて、新しい機能を追加することが不可能に近づくようになります。組織はコードベースを「レガシーコードベース」として分類し、開発チームは書き直しを計画します。
OOPは人間の脳にとって自然なものではありません。私たちの思考プロセスは物事を「実行する(doing)」ことを中心としています - 散歩に出かけたり、友達と話したり、ピザを食べたりします。 私たちの脳は、世界を抽象オブジェクトの複雑な階層に組織化するのではなく、物事を行うために進化しました。
OOPコードは非決定的です - 関数型プログラミングとは異なり、同じ入力に対して同じ出力が得られることは保証されていません。これはプログラムについての推論を非常に困難にします。単純化しすぎた例として、2+2またはcalculator.Add(2,2)の出力はほぼ4ですが、3、5、さらには1004になる可能性もあります。微妙な、しかし深遠な方法での計算の結果、Calculatorオブジェクトの依存関係が変わる可能性があります。
弾力性のあるフレームワークの必要性
これは奇妙に思えるかも知れませんが、プログラマとしては、信頼できるコードを書くことに自分自身を信頼するべきではありません。個人的には、私は自分の仕事の基礎となる強力なフレームワークなしでは良いコードを書くことができません。はい、いくつかの非常に特別な問題(例えばAngularやASP.Net)に関係するフレームワークがあります。
ソフトウェアフレームワークについては話しているのではありません。私は、フレームワークのより抽象的な辞書定義について話しています。「不可欠なサポート構造」 - コード構成やコードの複雑さへの取り組みなど、より抽象的なものに関心を持つフレームワークです。オブジェクト指向プログラミングと関数型プログラミングはどちらもプログラミングのパラダイムですが、どちらも非常に高度なフレームワークです。
選択を制限する
C++は恐ろしい[オブジェクト指向]言語だ... そして、プロジェクトをCに限定すれば、理想主義的なクソの「オブジェクトモデル」でモノをぶち壊したりしないという意味だ。
-- Linuxの開発者、リーナス・トーバルズリーナス・トーバルズは、C++とOOPに対する率直な批判で広く知られています。彼が100％正しいことは、プログラマが選択できる選択肢を制限することです。実際、プログラマが選択する選択肢が少なければ少ないほど、コードはより弾力的になります。上記の引用で、リーナス・トーバルズは、コードの基礎となる良いフレームワークを持つことを強く推奨しています。
多くの人は道路の制限速度を嫌いますが、人々が急死して死亡するのを防ぐためには不可欠です。同様に、良いプログラミングフレームワークは私たちがばかげたことをするのを妨げるメカニズムを提供すべきです。
良いプログラミングフレームワークは、信頼できるコードを書くのに役立ちます。まず第一に、それは以下のことを提供することによって複雑さを減らすのを助けるべきです:
- モジュール性と再利用性
- 適切な状態分離
- 高いSN比
残念なことに、OOPは、正しい種類の制限を課すことなく、開発者にあまりにも多くのツールと選択肢を提供します。OOPはモジュール性を扱い再利用性を改善することを約束していますが、その約束を守ることはできません(詳細は後で説明します)。OOPコードは共有されたミュータブル状態の使用を奨励しています。これは安全ではないことが証明されています。 OOPは一般的に多くの定型的コード(低いSN比)を必要とします。
関数型プログラミング
関数型プログラミングとは正確には何ですか? 一部の人は、学界でしか適用できず、「現実の世界」には適さない、非常に複雑なプログラミングパラダイムと考える人もいます。これは事実とはまるでかけ離れています!
はい、関数型プログラミングは強力な数学的基礎を持ち、その基礎をラムダ計算に取り入れています。 しかし、そのアイデアのほとんどは、より主流のプログラミング言語の弱点への対応として浮上してきました。関数は関数型プログラミングの中心的な抽象概念です。適切に使用されると、関数はOOPには見られないレベルのコードのモジュール性と再利用性を提供します。nullabilityの問題に対処する設計パターンを特徴とし、エラー処理の優れた方法を提供します。
関数型プログラミングが本当にうまくいく1つのことは、信頼できるソフトウェアを書くのに役立つということです。デバッガの必要性はほぼ完全に消えます。うん、あなたのコードをステップスルーして変数を見る必要はありません。私は個人的には、デバッガには長い間触れていません。
一番良いところ? 関数の使い方をすでに知っていれば、あなたはすでに機能的なプログラマーです。これらの機能を最大限に活用する方法を学ぶ必要があります!
OOPがすべて間違っています
私はずっと以前にこの話題に向け「オブジェクト」という用語を作り出したことを残念に思います。大きなアイデアはメッセージングです。
-- OOPの発明者、アラン・ケイErlangは通常、オブジェクト指向言語とは考えられていません。しかし、おそらくErlangが唯一の主流のオブジェクト指向言語です。はい、もちろんSmalltalkは適切なOOP言語です - しかし、広く使われているわけではありません。SmalltalkとErlangはどちらも、その発明者であるアラン・ケイが当初意図した方法でOOPを利用します。
メッセージング
アラン・ケイは1960年代に「オブジェクト指向プログラミング」という用語を作りました。彼は生物学のバックグラウンドを持っていて、生きている細胞がするのと同じ方法でコンピュータプログラムを通信させることを試みていました。
アラン・ケイの大きなアイデアは、独立したプログラム(セル)が互いにメッセージを送信して通信することでした。独立したプログラムの状態は外の世界とは決して共有されません(カプセル化)。
それでおしまい。OOPは、継承、ポリモーフィズム、newキーワード、そして無数のデザインパターンといったものを持つことを意図したものではありませんでした。
純粋な形式のOOP
Erlangは最も純粋な形でOOPです。より主流の言語とは異なり、OOPの中心となる概念、つまりメッセージングに焦点を当てています。Erlangでは、オブジェクトはイミュータブルなメッセージをオブジェクト間で受け渡すことによって通信します。
イミュータブルメッセージがメソッド呼び出しに比べて優れたアプローチであるという証拠はありますか?
もちろんです! Erlangはおそらく世界で最も信頼できる言語です。これは、世界のほとんどのテレコム(そしてインターネット)基盤にパワーを供給します。Erlangで書かれたシステムの中には99.9999999％の信頼性を持っているものがあります(あなたはそのとおりに読みます - ナインナイン)。
コードの複雑さ
OOPに活用されたプログラミング言語では、コンピュータソフトウェアはより冗長になり、読みにくくなり、説明が少なくなり、変更や保守が難しくなります。
-- リチャード・マンスフィールドソフトウェア開発の最も重要な側面は、コードの複雑さを抑えることです。以上。コードベースを維持することが不可能になっても、手の込んだ機能はどれも重要ではありません。コードベースが複雑になり保守できなくなると、100％のテスト範囲でさえも価値がありません。
コードベースが複雑になるとはどういうことですか? 考慮すべきことはたくさんありますが、私の意見では、最大の違反者は次のとおりです。共有されたミュータブル状態、誤った抽象化、および低いSN比(多くの場合、定型コードによって引き起こされる)。それらのすべてがOOPで蔓延しています。
状態の問題
状態とは? 簡単に言えば、状態はメモリに格納された一時的データです。OOPで変数やフィールド/プロパティを考えて下さい。命令型プログラミング(OOPを含む)は、プログラム状態とその状態への変更という観点から計算を記述します。宣言型(関数型)プログラミングでは代わりに目的の結果を記述し、状態への変更を明示的に指定しないで下さい。
ミュータブル状態 - メンタル・ジャグリングの行為
ミュータブルオブジェクトの大きなオブジェクトグラフを作成すると、大規模なオブジェクト指向プログラムは複雑さを増すことに苦労すると思います。ご存知でしょうが、あなたがメソッドを呼び出すときに何が起こるのか、そして副作用が何になるのかを理解し、頭の中で心に留めようとしています。
—- Clojureの作成者であるリッチ・ヒッキー状態自体はまったく無害です。しかし、ミュータブル状態は大きな犯罪者です。それが共有されている場合は特にそうです。ミュータブル状態とは何ですか? 変化する可能性のある状態です。OOPで変数やフィールドを考えて下さい。
現実世界の例をどうぞ!
白紙の紙があり、その上にメモを書きます。そして、同じ紙切れになってしまいます(テキスト)。あなたは、事実上、その紙切れの状態を変えました。
他の誰もその紙片を気にかけていないので、それは現実の世界では全く問題ありません。この紙がモナリザ絵画のオリジナルの絵でない限り。
人間の脳の限界
ミュータブル状態はなぜそれほど大きな問題なのでしょうか? 人間の脳は既知の宇宙で最も強力なマシンです。しかし、私たちの頭脳は、私たちのワーキングメモリーに一度に約5つのアイテムしか保持できないため、状態を扱うのが実際に苦手です。コードベースの前後でどのような変数が変わるのかではなく、あなたがコードが何をするのかについて考えるだけであれば、コードの一部について推論する方がはるかに簡単です。
ミュータブル状態を使ったプログラミングは、メンタル・ジャグリングの行為です。私はあなたのことを知りませんが、おそらく2つのボールを組み合わせることができます。私に3つ以上のボールを下さい、そして私はそれらのすべてを確実に落とします。それでは、なぜ私たちは仕事で毎日このメンタル・ジャグリングの行為を実行しようとするのですか?
残念ながら、ミュータブル状態のメンタル・ジャグリングは、OOPの中核を成すものです。オブジェクトにメソッドが存在する唯一の目的は、その同じオブジェクトを変更することです。
散乱状態
OOPは、プログラム全体に状態を分散させることによって、コード構成の問題をさらに悪化させます。散乱状態は、様々なオブジェクト間で無差別に共有されます。
現実世界の例をどうぞ!
私たち全員が大人になったことをちょっと忘れて、クールなレゴのトラックを組み立てようとしているふりをしましょう。
しかし、罠があります - すべてのトラックの部品はあなたの他のレゴのおもちゃからの部品とランダムに混在しています。そして、それらは50個の異なる箱に再びランダムに入れられました。トラックの部品をまとめることはできません。様々なトラックの部品が置かれている場所に頭の中で保管する必要があり、それらを1つずつ取り出すことしかできません。
はい、あなたは最終的にそのトラックを組み立てるつもりですが、それはどのくらい掛かりますか?
これはプログラミングとどのように関係していますか?
関数型プログラミングでは、状態は通常分離されています。 あなたはいつも何らかの状態がどこから来ているのか分かっています。状態はあなたの様々な機能に分散されることはありません。OOPでは、すべてのオブジェクトには独自の状態があり、プログラムを作成するときには、現在作業しているすべてのオブジェクトの状態に注意する必要があります。
私たちがもっと楽になるためには、コードベースのごくわずかな部分だけが状態を扱うようにするのが最善です。アプリケーションの中核部分をステートレスで純粋なものにします。これが実際にフロントエンド(別名Redux)でのFluxパターンの大成功の主な理由です。
乱雑な共有状態
ミュータブル状態が分散しているために、私たちの生活がまだ十分に困難ではない場合と同様に、OOPはさらに一歩進みます!
現実世界の例をどうぞ!
物事は非公開に保たれて共有されることはないので、現実の世界におけるミュータブル状態はほとんど問題になりません。これは「適切なカプセル化」です。 次のモナリザの絵に取り組んでいる画家を想像してみて下さい。彼は一人で絵に取り組んでいて、描き上げ、そして彼の傑作を数百万ドルで売却します。
今、彼はそのすべてのお金に飽きて、物事を少し違ったやり方でやろうと決心しました。彼は絵画パーティーをするのは良い考えだと思いました。彼は友人のエルフ、ガンダルフ、警官、そしてゾンビを助けてくれるように誘います。チームワーク! 彼ら全員が同時に同じキャンバスに絵を描き始めます。もちろん、そこから良いことは何も出て来ません - この絵は完全に大失敗!
共有されたミュータブル状態は現実の世界では意味がありません。それでも、これはまさにOOPプログラムで起こることです - 状態は無差別に様々なオブジェクトの間で共有されています。そして、彼らはそれらが適当と思う方法でそれを変化させます。その結果、コードベースが拡大し続けるにつれて、プログラムについての推論がますます難しくなります。
並行性の問題
OOPコードでミュータブル状態を無差別に共有すると、そのようなコードの並列化はほとんど不可能になります。この問題に対処するために複雑なメカニズムが発明されました。スレッドロック、ミューテックス(Mutex)、および他の多くのメカニズムが発明されました。もちろん、そのような複雑なアプローチには、デッドロック、合成性の欠如、マルチスレッドコードのデバッグが非常に困難で時間がかかるという、それぞれ独自の欠点があります。このような並行処理メカニズムを利用することによって引き起こされる複雑さの増大については話すことすらしません。
すべての状態が悪ではない
すべての状態が悪ですか? いいえ、アラン・ケイの状態は悪ではありません! 状態のミュテーションは、それが真に分離されていればおそらくおそらく問題ありません(OOPのやり方の分離ではありません)。
イミュータブルなdata-transfer-objectsを持つことも全く問題ありません。ここでの鍵は「イミュータブル」です。そのようなオブジェクトは、関数間でデータを渡すために使用されます。
しかし、そのようなオブジェクトはOOPメソッドとプロパティを完全に冗長にします。変更できない場合、オブジェクトにメソッドとプロパティを設定することで何が使用されますか?
カプセル化のトロイの木馬
カプセル化はOOPの最大の利点の1つであると言われています。オブジェクトの内部状態を外部からのアクセスから保護することになっています。これには小さな問題があります。うまくいきません。
カプセル化は、OOPのトロイの木馬です。それは安全に見えるようにすることによって共有されたミュータブル状態という考えを良いと思い込ませます。カプセル化により(推奨されています)、危険なコードがコードベースに潜入し、コードベースが内部から腐敗する可能性があります。
グローバル状態の問題
グローバル状態がすべての悪の根源だと言われました。それは絶対に避けなければなりません。私たちがこれまで一度も言われたことがないのは、カプセル化は実際には見せ掛けのグローバル状態であるということです。
コードをより効率的にするために、オブジェクトは値ではなく参照によって渡されます。これが「依存性注入(dependency injection)」が完全に失敗するところです。
説明させて下さい。OOPでオブジェクトを作成するたびに、その依存関係への参照をコンストラクタに渡します。それらの依存関係にも独自の内部状態があります。新しく作成されたオブジェクトはそれらの依存関係への参照をその内部状態で喜んで格納しています。そして、それはまたそれらの参照をそれが使用することになるかもしれない他のに渡します。
これにより、無差別に共有されたオブジェクトの複雑なグラフが作成され、それらすべてが互いの状態を変更してしまいます。これは、プログラムの状態が変化した原因を確認することがほとんど不可能になるため、大きな問題を引き起こします。そのような状態変化をデバッグしようとして、無駄な日数が掛かるかも知れません。並行性に対処する必要がない場合は、ラッキーです(これについては後で詳しく説明します)。
メソッド/プロパティ
特定のフィールドへのアクセスを提供するメソッドやプロパティは、フィールドの値を直接変更する以上のものです。派手なプロパティやメソッドを使用してオブジェクトの状態を変更するかどうかは問題ではありません - 結果は同じです: ミュータブル状態。
実世界モデリングの問題
OOPが現実の世界をモデル化しようとしていると言う人もいます。これは単純に真実ではありません - OOPは実社会とは関係ありません。プログラムをオブジェクトとしてモデル化しようとするのは、おそらくOOPの最大の間違いの1つです。
現実の世界は階層的ではありません
OOPは、すべてをオブジェクトの階層としてモデル化しようとします。残念ながら、それは現実の世界で物事がどのように機能するかではありません。現実世界のオブジェクトはメッセージを使用して互いに対話しますが、それらはほとんど互いに独立しています。
実社会での継承
OOPの継承は現実の世界をモデルにしていません。実世界の親オブジェクトは、実行時に子オブジェクトの動作を変更することはできません。あなたがあなたのDNAをあなたの両親から受け継いでも、彼らはあなたのDNAを彼らが望むように変更することができません。あなたは両親から「行動」を受け継がず、自分の行動を発達させます。そして、あなたは両親の行動を「無効にする」ことができません。
現実の世界には方法がありません
あなたが書いている紙切れには「書き込み」方法がありますか? いいえ! あなたは空の紙切れを取り、ペンを持ち上げ、そしてテキストを書きます。あなたは、個人として、「書く」方法も持っていません - あなたは、外部の出来事やあなたの内的な考えに基づいてテキストを書くという決断をします。
名詞の王国(The Kingdom of Nouns)
オブジェクトは、分割できない単位で関数とデータ構造を結び付けます。関数とデータ構造はまったく異なる世界に属しているので、これは根本的な誤りだと思います。
-- ジョー・アームストロング、Erlangの作成者オブジェクト(または名詞)は、OOPの中核を成すものです。OOPの根本的な制限は、それがすべてを名詞にすることです。そして、すべてが名詞としてモデル化されるべきではありません。操作(機能)をオブジェクトとしてモデル化しないで下さい。2つの数を乗算する関数だけが必要なときに、なぜMultiplierクラスを作成しなければならないのでしょうか? 単に乗算機能を持ち、データをデータにし、機能を機能にしましょう。
OOP以外の言語では、データをファイルに保存するなどの簡単なことを行うのは簡単です - 普通の英語でアクションを記述する方法と非常によく似ています。
現実世界の例をどうぞ!
画家の例に戻ると、画家はPaintingFactoryを所有しています。彼は、専用のBrushManager、ColorManager、CanvasManager、およびMonaLisaProviderを採用しました。彼の親友のゾンビはBrainConsumingStrategyを利用します。これらのオブジェクトは、CreatePainting、FindBrush、PickColor、CallMonaLisa、およびConsumeBrainzの各メソッドを定義します。
もちろん、これは明らに愚かであり、現実の世界では起こり得なかったことです。絵を描くという単純な行為のために、どれほど不必要な複雑さが生まれたでしょうか?
オブジェクトとは別に存在することが許可されている場合は、機能を保持するために奇妙な概念を考案する必要はありません。
単体テスト
自動テストは開発プロセスの重要な部分であり、後退を防ぐのに非常に役立ちます(つまり、既存のコードにバグが入り込む)。単体テストは自動テストのプロセスにおいて大きな役割を果たします。
そうでない人もいるかもしれませんが、OOPコードを単体テストするのは難しいことで有名です。単体テストでは、物事を個別にテストし、メソッドを単体テスト可能にすることを前提としています。
- その依存関係は別のクラスに抽出する必要があります。
- 新しく作成したクラスのインターフェースを作成します。
- 新しく作成したクラスのインスタンスを保持するためにフィールドを宣言します。
- 依存関係をモックするため、モックフレームワークを利用します。
- 依存性を注入するため、依存性注入フレームワークを利用します。
コードの一部をテスト可能にするためだけに、さらに複雑な部分を作成する必要がありますか? コードをテスト可能にするためにどれだけの時間が浪費されましたか?
>PS また、私たちはシングルメソッドをテストするためにクラス全体をインスタンス化する必要があります。これにより、その親クラスすべてからのコードも取り込まれます。
OOPでは、レガシーコードのテストを書くことはさらに困難です - ほとんど不可能です。従来のOOPコードをテストする問題を中心に、全体が作成されました(TypeMock)。
定型コード
信号対雑音比に関しては、定型コードがおそらく最大の違反者となります。定型コードは、プログラムをコンパイルするために必要な「ノイズ」です。定型コードは記述に時間が掛かり、ノイズが増えるためにコードベースが読みにくくなります。
OOPでは「implementationではなくinterfaceにプログラムする」ことをお勧めしますが、全てがinterfaceになるべきではありません。テストの容易さのためだけに、コードベース全体でinterfaceを使用することに頼らなければなりません。私たちはおそらく依存性注入を利用しなければならないでしょう。そして、それはさらに不必要な複雑さをもたらします。
プライベートメソッドのテスト
プライベートメソッドはテストするべきではないと言う人もいます… 私はどちらかといえば賛成できません。単体テストは理由から「ユニット」と呼ばれます - 小さなコード単位を単独でテストします。それでも、OOPでプライベートメソッドをテストすることはほぼ不可能です。テストしやすさのためだけにプライベートメソッドを内部に作成するべきではありません。
プライベートメソッドのテスト容易性を達成するためには、それらは通常別々のオブジェクトに抽出されなければなりません。これにより、不要な複雑さと定型コードが導入されます。
リファクタリング
リファクタリングは開発者の日常業務の重要な部分です。皮肉なことに、OOPコードはリファクタリングが難しいことで有名です。リファクタリングは、コードをそれほど複雑でなく、より保守しやすくするためのものです。反対に、リファクタリングされたOOPコードはかなり複雑になります。コードをテスト可能にするには、依存性注入を利用し、リファクタリングされたクラス用のインタフェースを作成する必要があります。 それでも、OOPコードをリファクタリングすることは、Resharperのような専用のツールがなければ、現実には困難です。
// before refactoring: public class CalculatorForm { private string aText, bText; private bool IsValidInput(string text) => true; private void btnAddClick(object sender, EventArgs e) { if ( !IsValidInput(bText) || !IsValidInput(aText) ) { return; } } } // after refactoring: public class CalculatorForm { private string aText, bText; private readonly IInputValidator _inputValidator; public CalculatorForm(IInputValidator inputValidator) { _inputValidator = inputValidator; } private void btnAddClick(object sender, EventArgs e) { if ( !_inputValidator.IsValidInput(bText) || !_inputValidator.IsValidInput(aText) ) { return; } } } public interface IInputValidator { bool IsValidInput(string text); } public class InputValidator : IInputValidator { public bool IsValidInput(string text) => true; } public class InputValidatorFactory { public IInputValidator CreateInputValidator() => new InputValidator(); }上記の簡単な例では、1つのメソッドを抽出するためだけに行数が2倍以上増えました。 そもそも複雑さを減らすためにコードがリファクタリングされているときに、なぜリファクタリングがさらに複雑さを増すのでしょうか?
これをJavaScriptの非OOPコードの同様のリファクタリングと比較して下さい。
// before refactoring: // calculator.js: const isValidInput = text => true; const btnAddClick = (aText, bText) => { if (!isValidInput(aText) || !isValidInput(bText)) { return; } } // after refactoring: // inputValidator.js: export const isValidInput = text => true; // calculator.js: import { isValidInput } from './inputValidator'; const btnAddClick = (aText, bText, _isValidInput = isValidInput) => { if (!_isValidInput(aText) || !_isValidInput(bText)) { return; } }コードは文字通り同じままです。単にisValidInput関数を別のファイルに移動し、その関数をインポートするための単一行を追加しました。テストの容易さのために、\_isValidInputを関数シグネチャに追加しました。
これは簡単な例ですが、実際にはコードベースが大きくなるにつれて複雑さは急激に増大します。
それだけではありません。 OOPコードのリファクタリングは非常に危険です。複雑な依存関係グラフと状態がOOPコードベース全体に散らばっているため、人間の頭ですべての潜在的な問題を考慮することは不可能です。
一時しのぎ (バンドエイド)
何かがうまくいかないとき、私たちは何をしますか? それは簡単です、私たちには2つの選択肢しかありません - それを捨てるかそれを修正してみて下さい。OOPは簡単に捨てられることができないものです、何百万もの開発者がOOPで訓練されます。そして、世界中の何百万という組織がOOPを使用しています。
あなたはおそらくOOPが実際にはうまくいかないことに気付くでしょう。それは、私たちのコードを複雑で信頼できないものにします。そしてあなたは一人じゃありません! OOPコードでよく見られる問題に対処しようとする人々は何十年もの間懸命に考えてきました。彼らは無数のデザインパターンを思い付きました。
デザインパターン
OOPは理論的に開発者がますます大規模なシステムを段階的に構築することを可能にする一連のガイドラインを提供します: SOLID原則、依存性注入、デザインパターン、その他諸々。
残念ながら、デザインパターンは一時しのぎに他なりません。それらは、OOPの欠点に対処するためだけに存在します。このトピックについては、無数の本が書かれています。私たちのコードベースに非常に複雑なものを導入することに対して責任がなかったのであれば、それらはそれほど悪くはなかったでしょう。
問題のあるFactory
実際に、保守可能な優れたオブジェクト指向コードを書くことは不可能です。
一方では、一貫性がなく、どの標準にも準拠していないようなOOPコードベースがあります。それとは反対側に、私たちは過剰に設計されたコードの塔、誤った抽象の束が互いの上に積み重なっています。デザインパターンはそのような抽象化の塔を作るのにとても役に立ちます。
すぐに、新しい機能を追加すること、そしてすべての複雑さを理解することさえ難しくなります。コードベースはSimpleBeanFactoryAwareAspectInstanceFactory、AbstractInterceptorDrivenBeanDefinitionDecorator、TransactionAwarePersistenceManagerFactoryProxyorRequestProcessorFactoryFactoryのようなものでいっぱいになります。
開発者自身が作成した抽象化の塔を理解しようとすると、貴重な頭脳を無駄にしなければなりません。構造がないことは、多くの場合、悪い構造を持つよりも優れています(あなたが私に尋ねるならば)。
さらに読む：FizzBuzzEnterpriseEdition
4つのOOP支柱の崩壊
OOPの4つの柱は、抽象化、継承、カプセル化、およびポリモーフィズムです。
実際に何があるのかを1つずつ見ていきましょう。
継承
再利用性の欠如は、関数型言語ではなく、オブジェクト指向言語にあると思います。オブジェクト指向言語の問題はそれらが暗黙のうちに持ち歩く環境をすべて持っているからです。あなたはバナナを望んでいましたが、あなたが得たのはバナナを持ったゴリラとジャングル全体でした。
— ジョー・アームストロング、Erlangの作成者OOPの継承は現実の世界とは関係ありません。実際、継承はコードの再利用性を実現するための劣った方法です。ギャング・オブ・フォーは、継承よりも合成を好むことを明示的に推奨しています。最近のプログラミング言語の中には、継承を完全に回避するものがあります。
継承にはいくつか問題があります。
- クラスが必要としないほど多くのコードを取り込む(バナナとジャングルの問題)。
- クラスの一部を別の場所に定義していると、特に複数レベルの継承があるため、コードを推論するのが難しくなります。
- ほとんどのプログラミング言語では、多重継承は不可能です。これは主に継承をコード共有メカニズムとして役に立たなくします。
OOPポリモーフィズム
ポリモーフィズムは素晴らしいです、それは私たちが実行時にプログラムの振る舞いを変えることを可能にします。しかし、それはコンピュータプログラミングにおける非常に基本的な概念です。なぜOOPがポリモーフィズムに重点を置いているのか、私はよく分かりません。OOPポリモーフィズムは仕事を終わらせますが、ここでもまたmental jugglingという行為をもたらします。それはコードベースをかなり複雑にします。そして、呼び出されている具体的な方法についての推論は本当に困難になります。
一方、関数型プログラミングでは、目的の実行時動作を定義する関数を渡すだけで、はるかにエレガントな方法で同じポリモーフィズムを実現できます。それより簡単なことは何でしょうか。 複数のファイル(およびインタフェース)で、多数のオーバーロードされた抽象仮想メソッドを定義する必要はありません。
カプセル化
前述したように、カプセル化はOOPのトロイの木馬です。それは実際には賛美されたグローバルなミュータブル状態であり、安全でないコードを安全に見せます。安全でないコーディング慣行は、OOPプログラマが日常業務で頼る支柱です…
抽象化
OOPの抽象化は、プログラマから不要な詳細を隠すことによって複雑さに取り組もうとします。理論的には、隠された複雑さについて考える必要なしに、開発者がコードベースについて推論することを可能にするはずです。
私は何を言うべきかさえ分かりません… 単純な概念のための空想的な言葉。手続き型/関数型言語では、実装の詳細を隣接ファイルに単に「隠す」ことができます。この基本的な行為を「抽象化」と呼ぶ必要はありません。
OOPの支柱の崩壊についての詳細は、「さようなら、オブジェクト指向プログラミング」を読んで下さい。
なぜ、OOPが業界を支配するのか?
答えは簡単です、ヒト型爬虫類の異星人種はNSA(とロシア人)と共謀して私たちプログラマーを死ぬまで虐待しました…
しかし冗談抜きに、Javaがおそらく答えです。
Javaは、MS-DOS以降のコンピューティングで起きたことで最も苦しめています。
— オブジェクト指向プログラミングの発明者であるアラン・ケイJavaはシンプルだった
1995年に最初に導入されたとき、Javaは他のものと比較して非常にシンプルなプログラミング言語でした。当時、デスクトップアプリケーションを書くためのエントリの障壁は高かった。デスクトップアプリケーションの開発には、低レベルのwin32 APIをC言語で記述する必要がありました。また、開発者は手動でメモリ管理にも関心を持つ必要がありました。もう1つの選択肢はVisual Basicでしたが、多くの人はMicrosoftエコシステムに縛られることを望みませんでした。
Javaが導入されたとき、それは無料だったので多くの開発者にとって非常に簡単であり、そしてすべてのプラットフォームで使用できました。組み込みのガベージコレクション、わかりやすい名前のAPI(謎めいたwin32 APIと比較して)、適切な名前空間、おなじみのCのような構文などにより、Javaはさらに親しみやすくなりました。
GUIプログラミングも一般的になりつつあり、様々なUIコンポーネントがクラスにうまくマッピングされているように見えました。IDEでのメソッドの自動補完も、OOP APIのほうが使いやすいと人々に主張させました。
おそらく、Javaが開発者にOOPを強制しない限り、Javaはそれほど悪くはなかったでしょう。Javaに関する他のすべてはかなり良さそうでした。他の主流のプログラミング言語が欠けていたそのガベージコレクション、移植性、例外処理機能は、1995年に本当に素晴らしかったです。
次に、C#が来た
当初、MicrosoftはJavaに大きく依存していました。 事態が悪くなり始めたとき(そしてSun MicrosystemsとJavaライセンスをめぐる長い合法的な戦いの後)、Microsoftは自身のバージョンのJavaに投資することにしました。それがC# 1.0が生まれたときです。言語としてのC#は、常に「より良いJava」と考えられてきました。しかし、大きな問題が1つあります。それは、同じ欠陥のある同じOOP言語であり、わずかに改善された構文の中に隠されていたことです。
Microsoftは.NETエコシステムに多大な投資をしてきました。これには優れた開発者ツールも含まれていました。何年もの間、Visual Studioはおそらく利用可能な最高のIDEの1つでした。その結果、特に企業では.NETフレームワークが広く採用されるようになりました。
ごく最近まで、MicrosoftはTypeScriptを推進することによって、ブラウザのエコシステムに多額の投資をしてきました。TypeScriptは、純粋なJavaScriptをコンパイルでき、静的型チェックなどを追加できるという点で優れています。それについては、それほど素晴らしいことではありません。機能的な構成要素を適切にサポートしていないということです - 組み込みのイミュータブルなデータ構造、関数の合成、適切なパターンマッチングがありません。TypeScriptはOOP優先で、ほとんどがブラウザのC#です。アンダース・ヘルスバーグは、C#とTypeScriptの両方の設計を担当していました。
関数型言語
一方、関数型言語は、マイクロソフトほどの規模の大きな企業に支えられたことは一度もありません。 投資がごくわずかだったのでF#は数えません。関数型言語の開発は、主にコミュニティ主導です。これはおそらく、OOP言語とFP言語の人気の違いを説明しています。
進むべき時か?
OOPは失敗した実験であることが分かりました。次に進むべき時です。私たちは、コミュニティとして、この考えが私たちを失敗させたことを認め、そして私たちはそれをあきらめなければなりません。
-- Lawrence Krubner根本的にプログラムを編成するのに最適ではない方法を使用しているのはなぜですか? これは無知なのでしょうか? 私はそれを疑います、ソフトウェア工学で働いている人々は愚かではありません。「デザインパターン」、「抽象化」、「カプセル化」、「ポリモーフィズム」、「インターフェースの分離」などの派手なOOP用語を使用することで、同僚を前にして「スマートに見える」ことについて、おそらくもっと心配していますか? おそらくそうではありません。
私たちが何十年も使ってきたものを使い続けるのは本当に簡単だと思います。ほとんどの人は、関数型プログラミングを実際に試したことがありません。 (私のように)使っている人はOOPコードを書くことに戻ることはできません。
ヘンリー・フォードはかつてよく知られてあるように次のように言いました - 「私が人々に彼らが欲しいものを尋ねたならば、彼らはより速い馬を言ったであろう」。ソフトウェアの世界では、ほとんどの人はおそらく「より良いOOP言語」を望んでいるでしょう。人は自分が抱えている問題を簡単に説明することができますが(コードベースの整理と複雑さの軽減)、最良の解決策ではありません。
代替案は何ですか?
ネタバレ警報: 関数型プログラミング
ファンクターやモナドのような言葉があなたを少し不安にさせるのであれば、あなただけではありません! 彼らがその概念のいくつかにもっと直感的な名前を与えたならば、関数型プログラミングはそれほど恐ろしくなかったでしょう。ファンクタ? それは単に関数で変換できるものです、list.mapを考えて下さい。モナド? 連鎖できる単純な計算!
関数型プログラミングを試してみると、より良い開発者になるでしょう。ほとんどの時間を抽象化やデザインパターンについて考える必要はなく、現実世界の問題を解決する実際のコードを書く時間ができます。
あなたはこれに気付かないかも知れませんが、あなたはすでに機能的なプログラマーです。日常業務で関数を使っていますか? はい? それで、あなたはすでに機能的なプログラマーです! これらの機能を最大限に活用する方法を学ぶ必要があります。
非常に穏やかな学習曲線を持つ2つの優れた関数型言語はElixirとElmです。それらは開発者に最も重要なことに集中させます - より伝統的な関数型言語が持っている複雑さのすべてを取り除きながら信頼できるソフトウェアを書くことです。
他の選択肢は何ですか? あなたの組織はすでにC#を使っていますか? F#を試してみて下さい。これは素晴らしい関数型言語であり、既存の.NETコードとの優れた相互運用性を提供します。Javaを使っている? それならScalaかClojureを使うことは本当に良い選択です。JavaScriptを使っている? 適切なガイダンスと構文チェックがあれば、JavaScriptは優れた関数型言語になり得ます。
OOPの擁護者
私はOOPの擁護者からある種の反応を期待しています。彼らは、この記事は不正確さに満ちていると言うでしょう。中には名前を呼んでいる人もいます。 実際のOOP経験のない「ジュニア」開発者とさえ呼ぶかも知れません。私の仮定は誤っていると言う人もいるかも知れませんし、例は役に立たないのです。する事なんでも。
彼らは自分の意見に対する権利を持っています。しかし、OOPの防衛に関する彼らの主張は通常非常に弱いものです。皮肉なことに、ほとんどの人が実際には関数型言語でプログラムしたことがない可能性があります。あなたが実際に両方を試したことがない場合、どうすれば2つのことの間の比較を誰かが引き出すことができますか? このような比較はあまり役に立ちません。
デメテルの法則はあまり有用ではありません。共有されたミュータブル状態は、その状態にアクセスしたり変更したりする方法に関わらず、依然として共有されるミュータブル状態です。それは単に敷物の下の問題を一掃します。ドメイン駆動設計? これは便利な設計方法論であり、複雑さには少々役立ちます。しかし、それでも共有ミュータブル状態の基本的な問題に対処するためには何もしません。
ツールボックス内の単なるツール...
私は、OOPはツールボックス内の他のツールに過ぎないと人々が言うのをよく耳にします。はい、それは馬と車が両方とも輸送のための道具であるのと同じくらい道具箱の中の道具です... 結局のところ、それらはすべて同じ目的を果たします。古き良き馬に乗り続けることができるのに、なぜ車を使うのでしょうか?
歴史は繰り返す
これは実際に私に何かを思い出させます。20世紀の初めに、自動車が馬に取って代わり始めました。1900年ニューヨークでは道路に車が数台しかありませんでしたが、人々は交通機関として馬を使っていました。1917年には、これ以上馬が道路に残っていませんでした。巨大な産業は、馬の輸送を中心としていました。厩肥の清掃などの事業を中心に、企業全体が生まれています。
そして人々は変化に抵抗しました。彼らは自動車を別の「流行」と呼び、やがてそれが通過します。結局のところ、馬は何世紀もの間ここにいました! 政府に介入を要求する人さえいました。
これはどのような意味がありますか? ソフトウェア業界はOOPを中心としています。何百万人もの人々がOOPの訓練を受けており、何百万もの企業がコードでOOPを利用しています。もちろん、彼らは自分の生活(bread-and-butter)を脅かすものは何でも嘘だとはねつけます。それが常識です。
私たちは、歴史がそれ自身を繰り返しているのをはっきりと見ています - 20世紀にはそれは馬対自動車でした、21世紀にはそれはオブジェクト指向vs関数型プログラミングです。
次は何ですか?
- Charles Scalfaniによる、さようならオブジェクト指向プログラミング
- オブジェクト指向プログラミングを買い被りすぎ
- Eric ElliottによるOOPの忘れられた歴史
- Erlangの作成者であるジョー・アームストロングによる、OOがひどいる理由
- Brian Willによるオブジェクト指向プログラミングは問題だ
- スティーブ・イエギによる名詞王国での執行
- オブジェクト指向プログラミングは失敗したのか?
7/22/2019
開発者とセキュリティ専門家の間に緊張はあるか?
「セキュリティが開発ライフサイクルに組み込まれる必要があることは誰もが分かっていますが、そうであるとは限りません。」ZDNetは、セキュリティチームと開発チームの間の長年の摩擦が残っていることを示した新しい調査について報告していると、ZDNetを書いている。
結果はGitLabの4,000人以上のソフトウェア専門家に対する「2019年グローバル開発者レポート: DevSecOps」の調査から得られたものである。
調査対象となったセキュリティ専門家の半数近く(49％)は、開発者に脆弱性の修正を優先させることに苦労していると述べた。それどころか、セキュリティの専門家の68％は、ライフサイクルの後半でセキュリティの脆弱性を発見できる開発者の半数未満が感じている。セキュリティ専門家の約半数が、コードがテスト環境にマージされた後に最も頻繁にバグを発見したと述べた。
同時に、開発者の70％近くが、安全なコードを書くことを期待されているが、彼らはほとんど手引きも手助けも得られないと述べた。1人の不機嫌そうなプログラマーは言った、「これはめちゃくちゃで、標準化されていません、私の仕事の大部分はセキュリティスキャンを受けたことがありません」。もう1つの問題は、多くの企業がセキュリティを十分に重視していないことだ。調査対象者の約44％が、セキュリティの脆弱性について判断していないと回答している。
ZDNetはまた、リーナス・トーバルズによる2017年のLinuxカーネルメーリングリストの発言を引用し、コードが無効なアクセスに対して強化されたても、セキュリティピープルがどのように称賛するかについて不満を述べている。「開発者の立場からすれば、実際には行われません。全然違います。開発者の立場から見ると、不正アクセスは単なる症状であり、バグを実際に修正するためには、報告、デバッグ、および修正が必要です。そのため、開発者の観点から言えば、強化の終点は単なる出発点にすぎません。そして、あなたが終わったと思うとき、私たちは本当に始まったばかりなのです。」
トーバルズは、ユーザーコミュニティにもまったく異なる期待の第3のセットがあると指摘し、「カーネル開発の一番のルールは『ユーザーを壊さない』ということです。ユーザーがいなければプログラムは無意味です。 何十年もかけて行った開発作業は無意味です…そしてセキュリティも無意味です。」ユーザーと開発者の興味をうまく調整して、トーバルズはセキュリティピープルが彼らの信念として「害を及ぼさない」を採用するべきであると提案し、そして「強化機能を追加するとき、最初のステップは常に『ただ報告する』べきです。物事を始末したり、アクセスを止めたりしないで下さい。それを報告する。他に何もありません。」
7/21/2019
44/8の一部が分割売却(Amazonへ)
NANOGメーリングリストより。アマチュア無線向けネットワーク(AMPRNet)に割り当てられていた44/8の一部がアマゾンに売却された。routeviewsで確認すると、44.0.0.0 - 44.191.255.255の範囲でしか経路は広報されていない。
どうやら、もはや44/8ではありません:NetRange: 44.192.0.0 - 44.255.255.255 CIDR: 44.192.0.0/10 NetName: AT-88-Z NetHandle: NET-44-192-0-0-1 Parent: NET44 (NET-44-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Amazon Technologies Inc. (AT-88-Z) RegDate: 2019-07-18 Updated: 2019-07-18 Ref: https://rdap.arin.net/registry/ip/44.192.0.0いくつかの追加の色があります:
これについて興味深いのは、ARINの割り当てではなく、ARDCの人々が最初の登録者ではないということです。このIANAの/8は当初、組織ではなくコミュニティに委任されました。
私が以下に抜粋した、ブログの中でリストアップされた個人に、これについて何かありますか?
Brian Kantor
kc claffy
Phil Karn
Paul Vixie[私がNANOGの親しい仲間であることを知らないそれらを省略しました。]
ARINもここで役割を果たしているようです。ARINの皆さん、コメントはありますか?
--msa
追伸: 私は1992年にARDCが組織される前からアマチュア無線にライセンスされています -- チェックはどうなっていますか?
NISTによるBGP経路起点検証の技術文書 (NIST-SP-1800-14)
NIST(米国立標準技術研究所)がRPKIを使ったBGP経路起点検証(ROV)に関する技術文書(NIST-SP-1800-14)を公開しています[超訳PDF (目次、付録はありません)]。
7/20/2019
COBOLが世界経済をいまだ動かしている
By PAUL FLAHIVE/MAY 23, 2019
60歳のコンピューター言語が世界経済を動かしている。
金融取引の80％もの見積もりで、一般的なビジネス指向のプログラミング言語、つまりCOBOLが使用されている。今ではプログラマーが定年退職し、彼らの後を継ぐ人が減っているため、言語の将来は不確実である。しかし、COBOL終焉の噂は目新しいことではない。
その死は何度も予測されてきた。実際、COBOLの歴史の中に定数が1つあるとすれば、それはプログラミング言語の死の予測かも知れない。
COBOLは1959年に業界と政府のプログラマーによって作られたが、それでもその将来は不確かだった。
「1年足らずで、COBOLが死にかけているという業界全体の噂がありました。」1981年の講義で、言語の設計を手伝った准将でプログラマーのグレース・ホッパーは言う。
ニックネームGrandma Cobolは、コードが彼女の初期の仕事の基づいていたからだ。彼女は、共同研究者の一人がその噂を聞いた後、花崗岩の墓石を買ったと言った。
「彼は、その前の切り通しにCOBOLという単語があります。それから彼はそれをペンタゴンのフィリップスにエクスプレスコレクトで送りました。」
国防総省のプロジェクトのリーダーであるチャールズ・フィリップスへのいたずらは、その権力の注目を集め、転機となったと彼女は言った。COBOLは、歴史上、最も広く使用されている最も長持ちするコンピュータ言語となった。
COBOLは、衣装ダンスサイズの大型メインフレームコンピューターで稼働し始めた。それが採用されると、今でも多くの病院、保険、小売業で使用されている。2016年には、会計総局が米国の司法省、退役軍人局、国土安全保障局などが言語をまだ使用していることを注意した。
それほど普及した理由は、これまでビジネスには本当に何もなかったからである。COBOLは過去の数学的に重い1と0のプログラミング言語を変えた。
フロスト銀行の最高執行責任者(CEO)を務めるマイク・ラッセルは、次のように述べている。「今、古い言語を見れば、まったく異なる言語を学ぶようなものです。しかも、ロシア語や中国語のように、文字さえも異なり、それは文字の数式です。」
フロスト銀行は、まだ約30のアプリケーションがCOBOLに依存している。2017年には、IBMは、上位100行のうち92行が、依然として中核事業にメインフレームを使用していたと報告した。
それは速く、効率的で回復力があるため、金融サービスプロバイダーはいまだCOBOLを使っていふ。
それらはまだモバイルバンキング、電話アプリ、そしてより良いウェブサイトを受け入れることができる。メインフレームとインターフェースをとるために必要なものはそれらだけである。
ラッセルはそれを古い車を所有することと比較した。ボディに傷があり、座席がすり減っていることを確認して、店に持って行って下さい。
「ユーザーとしての私には表面上の問題はすべて、大部分は変更できます。」と彼は言った。「でも、エンジンや他のもののは、私には簡単には理解できません。走っている限り、変更する必要はないかも知れません。」
言い換えれば、それが壊れていなければ、修正する必要はない、である。
一部の銀行は、システムの移行に数億ドルと数年を費やした。
ラッセルによると、その投資に対する収益は必ずしも明確ではないが、ビジネスの変化する性質 — リアルタイムで最新の取引を必要とするモバイルバンキング、および引退した人たちに対する後任プログラマの欠如は、その方程式を変えるかも知れない。
プログラマーの需要が高まるにつれて、トレーニンググループやコンサルタントが参入してきた。COBOL Cowboysは、経験豊富な、時には引退したCOBOLプログラマーと企業を組むノーステキサスのコンサルティングプログラムである。
サンアントニオのCodeupのようなコーディングブートキャンプは、需要はそれほど高くなければ、持続することはできない。Codeupの共同設立者であるJason Straughanは、猛烈なニーズと6桁のCOBOLプログラミング作業について長年話題になっていると語りました。
「しかし、需要が都市伝説を満たす限りでは、これら2つが一致することは私の経験ではありませんでした。」とStraughanは述べた。
人々はRobert Vinajaに、COBOLがあと20年間死んでいたと言っている。それが提供される時、テキサスA&Mサンアントニオ教授はそれを教える。
「COBOLは死にそうだと人々は言い続けています。そして、おそらくCOBOLが死ぬ前に死ぬことになるでしょう」と彼は言った。
大学便覧に掲載されていても、学校がサイバーセキュリティとより一般的な言語に移行するにつれて、コースは昨年開催されませんでした。
JAVA、PHPなどは、グラフィカルインタフェースを使用している。
「COBOLの外観は退屈で、何も魅力はありません」とVinajaは言う。「私がそのクラスを教えるとき、私たちは派手なアプリを友人を見せることを誇りに思うであろう何かを作成するつもりはないことを、まず学生に警告します。」
COBOLは1ダースの他の偽善者を克服し、少数の学生がこの分野に参入しました。
「私は26歳です。私以外に、一番若い同僚は私より40歳年上です」金融サービス会社で働いているSergio Montejanoは言った。彼は複数のコースを提供しているノーステキサス大学でCOBOLを学んだ。
彼は必要性を利用したいと言った。たとえ彼が開発コミュニティの他の人からの彼の費用で笑いに耐えていたとしても、今や彼は雇用安定、良い賃金と成長する余地を得ている。
Montejanoは自宅用のメインフレームを購入した。それは彼のガレージにある。彼の仕事は彼が勤めている会社の中心にある。「ミッションクリティカル」と彼が言った。
「私はそれについて誤解があると思います。それが古くなるまでそれについての誤解です。通常、テクノロジーは、古くなっているため無関係だと考えています」と彼は述べた。「しかし、それでもまだ最速の処理言語です。」
問題は、プログラマ不足が業界のニーズの変化によって、近い将来COBOLは終焉を迎えることになるのだろうか? ほとんどはノーと言う。RussellとMontejanoはどちらも、今後数十年のうちに舞台を去ると考えている。
そのため、COBOLはホスピスケアにはいない。それは生活支援のようなものである。
7/19/2019
PGPの問題
Latacoraのブログより。
Jul 16, 2019
(文字通り)何十年もの間、暗号技術者はPGPの欠陥を克服してきました。他の種類のエンジニアがこれを嗅ぎ付けると、彼らはショックを受けます。PGPはひどいですか? なぜ、人々は私にPGPを使うように言い続けているのですか? その答えは、PGPはひどいく、やめる必要があるからです。
あなたが今見ているように、PGPにはたくさんの問題があります。幸いにも、もしあなたが病的に好奇心が強くないのであれば、それに関する単純なメタ問題があります。それは、1990年代に、深刻な現代の暗号化の前に設計されました。有能な暗号技術者は、今日のPGPのように見えるシステムを設計することも、他の設計におけるその欠陥の大部分を許容することもしません。真面目な暗号技術者たちは、PGPをほとんどあきらめて、もうPGPを公開するのに多くの時間を費やす必要はありません(注目すべき例外はありますが)。このため、PGPのよく理解されている問題は、10年以上前から解決されていません。
2つの簡単なメモ: まず、これを弁護士や活動家ではなく技術者のために書きました。 第2に:「PGP」とは、OpenPGP標準からGnuPGでのリファレンス実装まで、多くを意味します。これらすべてをカバーするために「PGP」という用語を使用します。
問題
不合理な複雑さ
将来的にも誰も理解できない理由で、PGPはパケットベースの構造をしています。PGPメッセージ(「.asc」ファイル内)は、型指定されたパケットのアーカイブです。新フォーマットパケットと旧フォーマットパケットのどちらを使用しているかに応じて、パケットの長さをエンコードする方法は少なくとも8つあります。新フォーマットのパケットは、BERのように可変長の長さを持っています(PGPの実装を書いてみて下さい、あなたはASN.1の優しいリリースを望むかも知れません)。パケットはサブパケットを持つことができます。一部のパケットには重複する種類があります。最新の鍵サーバ攻撃は、GnuPGが誤って鍵の解析で2次式になったためにも発生しました。これもこの狂ったフォーマットに従ったためです。
それはただのエンコーディングです。実際のシステムは単純にはなりません。鍵と副鍵があります。 鍵IDと鍵サーバーおよび鍵署名。署名のみと暗号化のみ。複数のキーホルダー。失効証明書。3つの異なる圧縮フォーマット。これが、スマートカードのサポートを受ける前のすべてです。
万能ナイフ設計
あなたが森の中で立ち往生していて、私が知らないで、あなたのジーンズの袖口を修理する必要があるならば、それはあなたの万能ナイフが一対のはさみを持っているなら便利です。しかし、本気で仕事をする人は、誰も自分たちのマルチツールはさみを普通は使用しません。
万能ナイフはたくさんのことをしますが、それらのすべてが不十分です。PGPは物事に署名するという平凡な仕事、パスワードでそれらを暗号化するという比較的貧弱な仕事、そして公開鍵でそれらを暗号化するというかなりひどい仕事をします。PGPはファイルを安全に転送するための特に良い方法ではありません。パッケージに署名するのは不恰好で重い方法です。バックアップを保護するのは得意ではありません。安全なメッセージをやり取りするのは実に危険な方法です。
PGPが生まれたMCハマー時代には、「暗号化」はそれ自体が特別なものでした。ファイルを送信したりディレクトリをバックアップしたりするツールと、ファイルを暗号化して署名するツールがありました。現代の暗号化はこのようには機能しません。それはある目的専用です。セキュアメッセージングは、セキュアバックアップやパッケージ署名とは異なる暗号化を望んでいます。
下位互換性から抜け出せずにいる
PGPは現代暗号学に先んじています。年を経たハンソンのアルバムがあります。運がよければ、ローカルのGnuPGのデフォルトは2048ビットのRSA、CFBの64ビットブロックのCAST5暗号、そしてOpenPGP MDCチェックサムです(これについては後ほど)。公開鍵ではなくパスワードで暗号化する場合、OpenPGPプロトコルはPGPのS2KパスワードKDFを指定します。穏やかに言えば、これらは暗号技術者が現代のシステムにとって選択する基本要素ではありません。
スティーブ・アーケルがABCのTGIFの間にテレビ放送を飾って以来、私たちは多くのことを学びました。あなたの暗号文を認証する(そしてCFBモードを避ける)ことは明らかな例ですが、それは64ビットブロック暗号は良くないこと、RSAよりもはるかに良いことができること、圧縮と暗号化を混在させることは危険であること、そしてKDFは時間とメモリの両方を必要とすることです。
OpenPGPのRFCが何を言っても、PGPを使っているのであれば、おそらくこれらのことをしていないでしょうし、またいつ使うのか予測することもできません。AEAD暗号を取ります: Rust言語のSequoia PGPはデフォルトでAES-EAX AEADモードに設定されています。ほとんどのPGPインストールではEAXモードが何であるか分からないため、これらのメッセージを読むことができません。よく知られているすべての悪い暗号システムは、結局曲線またはAEADをサポートするRFC拡張を出現させるので、その支持者は彼らが現代の暗号化をサポートしていることをメッセージボードで主張することができます。RFCは関係なく、インストールされた基礎だけです。認証された暗号化は20年間にわたって理解されてきました。PGPは私に飲み物を買うのに十分古いもので、十分な言い訳です
あなたは1990年代との後方互換性を持つことができるか、健全な暗号化を持つことができるかです。両方を持つことはできません。
不快なUX
これはTed Unangst以上にそのことを言えません。
数年前にPGPの使いやすさの調査が行われ、そこであるグループの技術者がコンピュータのある部屋に入れられ、PGPの設定を依頼されました。2時間後、彼らは二度と見ることも聞くこともなかった。これを裏付けるためにあなた自身の経験的なデータが欲しいなら、ここにあなたが実行することができる実験があります: 入国管理弁護士を見つけて、そしてSignalが彼らの電話で働くのをプロセスを通して話し合います。あなたはたぶん、焦げたトーストのにおいはしないでしょう。それではPGPでやってみて下さい。
長期のシークレット
PGPは、実質的に永遠のルート鍵を彼らのアイデンティティと結びつけるようにユーザーに頼みます。これは、鍵の生成と交換を面倒にすること、「鍵署名当事者」を奨励すること、そして鍵が他の鍵に依存する「信頼の輪(web of trust)」を作り出すことによって実現します。
長期の鍵はあなたが望むものではほとんどありません。鍵を使い続けると、やがて漏洩することになります。 情報漏洩の範囲をできるだけ小さくすること、そして現在の鍵の安全性について何か懸念がある場合は、新しい鍵をロールすることをユーザーが少しも躊躇しないようにする必要があります。
PGP応援団はすぐに「だからこそ、鍵をYubikeyに保管しているのです」と答えます。まともな概算では、全世界で誰もこれを行うために高価なYubikeysを使用していません、そしてあなたはそれが変化する未来を想像することはできません(私たちはU2Fをロールアウトすることはほとんどできず、それらの鍵は使い捨てになります)。私たちは、UNIXオタクが自分のおもちゃについて気分を良くするためだけに、ひどい暗号システムを受け入れることはできません。
認証切れ
さらに、PGPの古風なプリミティブについて: 2000年の頃、OpenPGPワーキンググループは彼らが暗号文を認証する必要があること、そしてPGPの署名はそれを達成していないことに気付きました。そこでOpenPGPはMDCシステムを発明しました: MDCを使ったPGPメッセージはプレーンテキストのSHA-1をプレーンテキストに添付し、それはCFBモードで(通常通り)暗号化されます。
現代のシステムが比較的複雑なAEADモードを使用しているときにPGPがどのようにこの問題を解決しているのか疑問に思われるなら(なぜSHA-1を平文に貼り付けることができないのか)、あなただけではありません。このRube Goldbergの珍妙な仕掛けのどこから始めるべきですか? PGP MDCはメッセージを取り除くことができます - 暗号化テキストの最後の22バイトを切り取ることができるようにエンコードされています。安全でない古いメッセージとの後方互換性を保つために、PGPはMDCを検証する必要があることを知らせる新しいパケットタイプを導入しました。間違ったタイプを使用した場合、MDCはチェックされません。たとえあなたがそうしたとしても、新しいSEIPパケットフォーマットは安全でないSEフォーマットに十分に近いので、読者をダウングレードさせる可能性があります。Trevor Perrinは、SEIPを16ビットセキュリティ全体に適用しました。
そして最後に、たとえすべてがうまくいったとしても、リファレンスPGP実装は、MDCが一致しないとしても、認証されていない平文を発信者に解放するでしょう。
支離滅裂のアイデンティティ
PGPはアプリケーションです。 他のアプリケーションとの一連の統合です。それは、ファイルフォーマットです。ソーシャルネットワークでもあり、サブカルチャーでもあります。
PGPは暗号化アイデンティティの概念を推進しています。鍵を生成してキーホルダーに保存し、その指紋を名刺に印刷して鍵サーバに公開します。あなたは他の人の鍵に署名します。順番に他の鍵を検証するために、彼らはあなたの署名に頼るかも知れませんし、しないかも知れません。一部の人は、他のPGPユーザーと直接会って鍵を交換したり、この「信頼のウェブ」にもっと安全に接続したりするために邪魔をする人もいます。他の人々が「キー署名パーティー」を組織しています。 頭の中で想像しているイメージは、PGPの信奉者が新しいものに切り替えるのがどれほど難しいかを正確に説明しています。
このアイデンティティグープのどれも動作しません。 鍵署名の信頼のあるウェブではなく、鍵サーバではなく、パーティーではありません。どこから来たのかに関わらず、PGP鍵のように見えるものは何でも信頼できるでしょう。専門家でさえ鍵の評価方法を明確に表現するのに苦労するのであれば、どうすればよいでしょうか? 専門家は、彼らが個人的に交換していない鍵を信用しません。他の誰もが鍵を配布するために中央当局に頼っています。PGPの主要な配布メカニズムはシアターです。
メタデータの漏洩
電子メールの大失敗をちょっと忘れて下さい(後で詳しく説明します)。PGPはそれ自身でメタデータを漏らします。メッセージは(通常の使用方法では)鍵の識別子に直接リンクされています。鍵の識別子は、PGPの信頼のクモの巣(cobweb)全体でユーザーIDにリンクされています。さらに、かなり多くのPGPユーザーが鍵サーバを利用しています。鍵サーバは、PGPユーザーが互いに通信しているアイデンティティをネットワークに漏洩させる可能性があります。
前方秘匿性(Forward Secrecy)がない
その最後の問題の良い例は、セキュアメッセージング暗号化が前方秘匿性を要求することです。 前方秘匿性とは、今日あなたが攻撃者への鍵を失ったとしても、戻ってきて昨日のメッセージを読むことができないということです。彼らはそれらを読むために昨日の鍵を持っていなければなりませんでした。現代の暗号学では、敵対者がすべてを無限の記憶域に記録していると想定しています。PGPの主張する敵対者は世界政府を含み、その多くは確かにそうしています。重大な敵対者に対して、そして前方秘匿性がなければ、違反は「if」ではなく「when」の問題です。
実際に秘密を守るために、通常は2つの秘密鍵を保管します。短期セッション鍵と長期信頼鍵です。セッション鍵は短命(通常はDH交換の産物)であり、信頼できる鍵がそれに署名するので、中間者は自分の鍵をスワップすることができません。理論的には、PGPが提供するツールを使用して、前方秘匿性の複製を達成することは可能です。もちろん、ほとんど誰もそんな事をしません。
不器用な鍵
OpenBSDのsignify(1)公開鍵は、電子メールの文章の途中に収まるほど短いBase64文字列です。 交換フォーマットではない秘密鍵は、単なる1行またはそれ以上の長さです。PGP公開鍵は、非常に巨大なBase64文書です。頻繁に使用する場合は、メッセージに貼り付けるのではなく添付するのが習慣になっているため、破損することはありません。Signifyの鍵は最先端のEd25519鍵です。PGPは弱いRSA鍵です。
あなたはこのことは重要ではないと思うかもしれませんが、とても重要です。PGPを使用するよりもはるかに多くの人々がSSHを使用してSSH鍵を管理しています。SSH鍵は扱いが簡単です。PGPは違います。
ネゴシエーション
PGPはElGamalをサポートしています。PGPはRSAをサポートしています。PGPはNIST P-Curvesをサポートしています。PGPはBrainpoolをサポートしています。PGPはCurve25519をサポートしています。PGPはSHA-1をサポートしています。PGPはSHA-2をサポートしています。PGPはRIPEMD 160をサポートします。PGPはIDEAをサポートしています。PGPは3DESをサポートしています。PGPはCAST5をサポートしています。PGPはAESをサポートしています。これがPGPがサポートするものの完全なリストであるという方法はありません。
過去20年間に暗号化設計について3つの重要なことを学んだとしたら、そのうち少なくとも2つはネゴシエーションと互換性が悪いということです。暗号システムの欠陥は木材ではなく建具類に見られる傾向があり、拡張的な暗号互換性は建具類の量を増やします。TLS 1.3のような現代のプロトコルはRSAのようなものとの後方互換性を放棄しています、それを追加していません。新しいシステムは、単一のプリミティブのスイートと単純なバージョン番号だけをサポートします。それらのプリミティブのうちの1つが失敗した場合、あなたはバージョンをぶつけて一度に古いプロトコルを捨て去ります。
私たちが不幸で、20年後に人々がまだPGPを使っているのであれば、どこのコードにもCAST 5が含まれる唯一の理由はPGPになるでしょう。これをもっとはっきりと言うことはできませんし、十分な頻度で言い換えることもできません。あなたは1990年代との後方互換性を持つことができます、あるいは、健全な暗号化を持つことができます。両方を持つことはできません。
ジャンキーコード
PGPの事実上の標準実装はGnuPGです。GnuPGは慎重に構築されていません。これは、メモリ破損から暗号化サイドチャネルに至るまでのCVEの長い実績を持つ、重複する機能(例えば、最新のSKSキー解析サービス拒否攻撃の記録、複数のキーパーサーがあることが記されています)を含む広大なC言語コードベースです。GnuPGに気付かれずにメッセージから認証コードを取り除くことは時々可能でした。気づかないうちに正しくフィンガープリントを入力できない鍵を入力することは可能でした。2018年のEfail脆弱性は、認証されていない平文を発信者に公開することによるものです。GnuPGは良くありません。
GnuPGは、事実上PGPのリファレンス実装でもあり、PGP暗号化を統合する他のほとんどのツールの基盤でもあります。どこにも行けません。PGPに頼ることはGPGに頼ることです。
解決策
人々にPGPの使用をやめるよう説得することの修辞的な課題の1つは、PGPを置き換えることができるものはありません。また、あるべきではありません。代わりに何を使うべきかは、あなたがしていることによります。
人と会話する場合
Signalを使用して下さい。あるいは、Wire、WhatsApp、その他のSignalプロトコルベースのセキュアメッセンジャーを使って下さい。
現代の安全なメッセンジャーは、メッセージングを中心に構築されています。それらは、プライバシーを保護する認証ハンドシェイク、否認可能なメッセージ、すべてのメッセージ交換をやり直す暗号ラチェット、そしてもちろん現代の暗号化プリミティブを使います。メッセンジャーは簡単に使用でき、鍵や副鍵に煩わされることはありません。Signalを使用すると、それ以上の効果が得られます。トラフィック分析攻撃を回避するためにGiphy検索をトンネリングし、比較的最近までユーザープロファイルをサポートすることさえできなかったため、プライベートメタデータをサーバーから排除することに偏執狂的なシステムになります。
電子メールの暗号化
しないでください。
電子メールは安全ではありません。PGPでも、デフォルト平文です。つまり、たとえあなたが正しいことをしたとしても、あなたがメールし、まったく理にかなったことをしている誰かが、暗号化されたメッセージの平文を他の人にCCすることは間違いありません(これが起きたことを見たことがないPGP Eメールユーザーは知らない)。PGP Eメールは前方秘匿性がありません。件名(文字通りメッセージの内容)を含む電子メールのメタデータは常に平文です。
別の理由が必要な場合は、Efailの論文を読んで下さい。Efailの開示を誤って扱ったGnuPGコミュニティは、この調査について多くのことを語っていますが、Usenix Security(トップの学術的なソフトウェアセキュリティの場の一つ)とBlack Hat USA(業界でトップのソフトウェアセキュリティの場)で受け入れられました。過去5年間で最も優れた暗号化攻撃の数々、そしてPGPエコシステムのかなり破壊的な欠陥を示すものです。論文からわかるように、S/MIMEは良くありません。
これは修正されていません。実際に安全なEメールを作成するには、Eメールを介して別のプロトコルをトンネリングする必要があります(それでもトラフィック分析攻撃が起こる可能性があります)。その時点で、なぜわざわざそんな事をするのですか?
電子メールを暗号化することは災難を求めています。危険にさらされているユーザーに電子メールの暗号化を推奨するのは過誤です。PGPで暗号化された電子メールを介して通信するのが安全であるとあなたに言う人はだれでも、あなたの安全よりも彼らの変わった好みを優先しています。
ファイルの送信
Magic Wormholeを使って下さい。Wormholeクライアントは、ワンタイムパスワード認証キー交換(PAKE)を使用してファイルを受信者に暗号化します。これは簡単で(少なくともオタクにとっては)、安全で、そして楽しいです: 私たちがしたように大胆にワームホーリングを始めなかった人にWormholeを紹介することはありません。
誰かがすぐにMagic WormholeのGoまたはRustの実装にWindowsインストーラーを固執します。誰にとっても必要ないのは素晴らしいことです。
技術者ではなく弁護士と仕事をしているのであれば、Signalはファイル転送を安全に保護するという非常に問題のない(cromulent)仕事をします。PGP鍵ではなく、バグ報奨金報告を受け取るためにあなたのセキュリティページにSignal番号を入れてください。
暗号化バックアップ
Tarsnapを使って下さい。Colinは、Tarsnapがバックアップを保護するためにどのように最適化されているかについて、皆さんにお伝えします。あるいは、他の多くの人が使用している他の暗号化バックアップツールを使用して下さい。それらはTarsnapほど良くはないが、それら全てはPGPよりも良い仕事をします。
オフラインバックアップが必要ですか? 暗号化されたディスクイメージを使用して下さい。最新のWindows、Linux、およびmacOSに組み込まれています。フルディスク暗号化は素晴らしいものではありませんが、この使用例ではうまく機能します。PGPよりも簡単で安全です。
パッケージに署名する
Signify/Minisignを使用して下さい。Ted Unangstはそれについてあなた全員に話します。OpenBSDがパッケージの署名に使うものです。それは非常にシンプルでモダンな署名を使用しています。libsodiumの男であるFrank DenisのMinisignが、同じ設計をWindowsとmacOSにもたらしました。Go、Rust、Python、Javascript、および.NET用のバインディングがあります。それはSignifyとも互換性があります。
アプリケーションデータの暗号化
libsodiumを使えば、どこにでも構築でき、誤用しにくいように設計されたインターフェースを持っています、そしてそれを使うためにバイナリに大金を払う必要はありません。
ファイルの暗号化
これは本当に問題です。もしあなたがバックアップを作成する/しないのであれば、長期保存のためにオフラインで何かをアーカイブする/しない、他の人にファイルを安全に送るために暗号化する/しない、作業を完了させるために必要に応じてマウント/アンマウントする仮想ドライブを暗号化する/しない、今すぐこれを実行できる優れたツールはありません。 Filippo Valsordaは、これらのユースケースの「上げ(age)」に取り組んでいます。私はそれについて非常に楽観的ですが、まだありません。
うまくいけば、これがかなり狭い使用例であることは明らかです。私たちはソフトウェアセキュリティの分野で働いており、バグ報奨金報告を含む機密データを取り扱います(もう1つの一般的な「PGPが必要です!」というユースケース)。PGPに触れる必要はほとんどありません。
7/18/2019
DNS TXTレコードを分析する
ISC Diaryより。日本のサイトを対象に調べてみたい...
Xavier Mertens
Internet Storm Centerでは、ドメインネームシステムが脅威の探索やOSINTの最重要課題であることをすでに何度も述べました。DNSレコードの独特のタイプはTXTレコード(またはテキストレコード)です。これは、フリーテキストをホストまたは他の名前に関連付ける機能を提供するために使用されるリソースレコードの一種です。TXTレコードには通常次のものが含まれます。
- 連絡先情報など、ドメインに関連するすべてのフリーテキスト
- 他のレコード(SPFおよびDMARKレコード)に保存できない技術データ
- 検証レコード
- 疑わしいデータ(あなたは何を期待しましたか?)
- 暗号化されたパケットまたはファイル(データの流出のDNSトンネリング)
- <関連するデータを入れる>
TXTレコードは一般に公開されており、機密データを含むべきではありません。それらはdigのようなDNSサーバーと相互作用するどんなツールによっても要求することができます:
$ dig sans.edu txt ; <<>> DiG 9.10.6 <<>> sans.edu txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11178 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;sans.edu. IN TXT ;; ANSWER SECTION: sans.edu. 7200 IN TXT "MS=ms72131568" sans.edu. 7200 IN TXT "v=spf1 mx ip4:72.55.140.81 ip4:66.35.59.0/24 ip4:66.35.60.0/24 ip4:204.51.94.0/24" " ip4:160.109.234.213 include:stspg-customer.com" " include:cust-spf.exacttarget.com include:spf.clearslide.com" " include:amazonses.com include:spf.protection.outlook.com include:_spf.salesforce.com ~all" sans.edu. 7200 IN TXT "JI6UZuSsLXHEjD7PIBR1rWcPOqRkKRV2VwWAdhXZnLfbjhmfHHOwjMPizS78hfcgbTtjG1TaPTcdVqzgvUbyaw==" ;; AUTHORITY SECTION: sans.edu. 171976 IN NS dns21a.sans.org. sans.edu. 171976 IN NS dns21b.sans.org. sans.edu. 171976 IN NS dns31b.sans.org. sans.edu. 171976 IN NS dns31a.sans.org. ;; Query time: 131 msec ;; SERVER: 192.168.254.8#53(192.168.254.8) ;; WHEN: Tue Jul 16 14:18:20 CEST 2019 ;; MSG SIZE rcvd: 550RFC1464[1]はTXTレコードについて議論しています。それらは、印字可能文字を含まなければならないので、多くのTXTレコードはBase64エンコードデータを含みます(上記の例を参照)。しかし、TXTレコードには何がありますか? 私は、様々なDNSサーバーのログと悪質なドメインのリストからドメイン名の長いリストを抽出しました。それから、私はそれぞれについてTXTレコードを問い合わせました。いくつかの興味をそそるものを検索するために、結果をSplunkインスタンスに取り込みました。私は何を見つけたでしょうか?
注: 収集された一連のドメイン名は、組織のログソースの業務/活動に直接関係しています。私は様々な情報源を混在させようとしましたが、それらは完全なインターネットをカバーしていません。
30万以上のTXTレコードのうち、18万6千はSPFフィルタに関連していました[2]。トップのEメールプロバイダーはどこでしょうか?
- Microsoft (Outlook.com) (9.9%)
- Google (7.8%)
- OVH (1.5%)
3千を超えるドメインには、「v=spf1 -all」というフィルタがあります。これは、基本的に「これらのドメインへの電子メール送信を許可されているホストはない」という意味です。
DKIM TXTレコードがあるのはたったの389(!)ドメインです("v=DKIM1; k=rsa; p=…”)。
TXTレコードのもう1つの一般的な使用法は、あなたが特定のドメインを所有していることを証明するための制御を提供することです。そのため、多くのプロバイダが検証レコードの作成を求めています。上位20の検証レコードタイプは次のとおりです。
google-site-verification facebook-domain-verification _globalsign-domain-verification adobe-idp-site-verification atlassian-domain-verification globalsign-domain-verification ciscocidomainverification status-page-domain-verification zoho-verification keybase-site-verification protonmail-verification have-i-been-pwned-verification dropbox-domain-verification workplace-domain-verification brave-ledger-verification webexdomainverification. citrix-verification-code adobe-sign-verification detectify-verification logmein-verification-code sophos-domain-verification3万4千のドメインにはOffice365レコード「MS=msXXXXXXXX」がありました。
CloudFlareを使用しているドメインには、「ca3-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX」のようなTXTレコードがあります(5千以上のレコード)
疑わしい/悪意のある活動についてはどうですか?
私は5つほど発見しました:
window.location.replace(\"hxxp://www[.]28955bfg36abp[.]maintenirfa[.]icu/50968.html\”);いくつかのSQLインジェクションの試み:
';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//\""; alert(String.fromCharCode(88,83,83))//\インジェクション:
'\"">><marquee><img src=x onerror=confirm(1)></marquee>\""></plaintext></,><plaintext/onmouseover=prompt(1)> <script>prompt(1)</script>@gmail.com<isindex formaction=javascript:alert(/XSS/) type=submit>'-->\""></script><script>alert(document.cookie)</script>\"">"" ""<img/id=\""confirm(1)\""/alt=\""/\""src=\""/\""onerror=eval(id)>'\""><img src=\""hxxp://www[.]shellypalmer[.]com/wp-content/images/2015/07/hacked-compressor.jpg\”">最後に、Base64でエンコードされた文字列を見ました。すべてのTXTレコードをフラットファイルに抽出し、Didierのbase64dumpツールを使用しました(16バイト以上のデータ文字列のみ)。
$ base64dump.py -n 16 txt-records.csv1万8千の文字列は、主に未知のデータでデコードされています。復号化データの最小サイズを制限すると、他の種類のレコードを見つけることができます。
$ base64dump.py -n 128 1563290719_434556 | grep Salted__ 433: 172 U2FsdGVkX18ImyXI Salted__.?%?'|j bf4a8022560a0eaa5410421803f3f36a 4836: 172 U2FsdGVkX18UR6BW Salted__.G?V?~?+ 1b6cb31ff37707a5234411b0d2946d92 5020: 128 U2FsdGVkX18LDhF1 Salted__...u??&{ be5a0c41bd9113f59d105fe52b0d600b 10480: 172 U2FsdGVkX18Gx+Qk Salted__.??$??.? 8f3c2fb8cb65bf83deb319040cfa0431 10858: 172 U2FsdGVkX19uUZCc Salted__nQ??E?Q? d1518d4dd745cf21549881477e1f0663 10859: 172 U2FsdGVkX18swQke Salted__,?..?.?j d59604b22066693a2fe1020a9230cee2 10860: 172 U2FsdGVkX18kqxHK Salted__$?.? ? ? ad198d777d6535e735e011a1962da767 10863: 172 U2FsdGVkX182vS1/ Salted__6?- /.?? 79b98e60256204b1496672bf534d798f 11111: 192 U2FsdGVkX19gXMHT Salted__`\??.R?* 9e3c2eb4248b8a9f19669b95733f6b42 11112: 172 U2FsdGVkX19eP/Xr Salted__^???+?? 62fec6ab31abf469714ed644f874dfe5 11989: 192 U2FsdGVkX19Lx8yU Salted__K??f?P9 bae75f0621aac882fe0d6437148eb6e2 12188: 172 U2FsdGVkX18fgi6U Salted__.?.??=?. d2f075147f0ecfd6dbd5decb5ab539a8 12189: 172 U2FsdGVkX1/bj0+w Salted__?O??J?- 57c4fab20a1d00ae6ab9421adb14db7d 12236: 128 U2FsdGVkX19eQQU7 Salted__^A.;?..? fe5ddee71702e557f2223b5dbf638521 12283: 172 U2FsdGVkX18oCMgi Salted__(.?"W??? 2340a1f6293d5094fbb1bfc7b0477ea9 12284: 172 U2FsdGVkX19TxBC7 Salted__S?.??Q7. 7023090b4b45d80468d73ccf1fd76f75 12292: 192 U2FsdGVkX19LqH/h Salted__K? ?h.?? f64d90db45cab9227c593fe99ee19ae6 12363: 152 U2FsdGVkX19AaKCa Salted__@h??.U0/ a9f3b2548d3a5571b75510c392ceea70 12573: 172 U2FsdGVkX19vmD8m Salted__o??&??./ 94b8e7d4c933bd1fc6c3dd381fea9b95 15550: 128 U2FsdGVkX18YmIhE Salted__.??D?}?7 61421ac7e9463408085cf67ee525c2a0 15551: 152 U2FsdGVkX18N9H+R Salted__.? ????o 0eda0cc8c4d2667032ce27d0a389f2a9 16629: 152 U2FsdGVkX194reUj Salted__x??#?J? c098589181b03e2a78f34ef3e08c7b09接頭辞「Salted__」は、これが「openssl enc」コマンドの出力か、またはそのようなものであることを意味します。
ご覧のとおり、TXTレコードにはたくさんの興味深いデータがあります。TXTレコードのデータを検索するための一連の正規表現を含む興味深いブログ記事[3]も見つかりました。あなたはそれらに目を光らせておくべきです。私は自分のBroインスタンスからその場でそれらを収集し、ある種の「passivetxt」サービスを構築するための恒久的なスクリプトを検討しています。
[1] https://www.rfc-editor.org/rfc/rfc1464.txt
[2] https://en.wikipedia.org/wiki/Sender_Policy_Framework
[3] https://www.tide-project.nl/blog/ccr2019/
イーロン・マスクが、Neuralinkの脳読み取りスレッドと挿入ロボットを発表
ブレイン・マシーン・インターフェースを開発している秘密主義の会社Neuralinkは本日記者会見を開催し、初めて公に開発されている技術の一部を明らかにしました。最初の大きな進歩は柔軟性のある「スレッド」です。これは、ブレイン・マシン・インターフェースで現在使用されている材料よりも脳を損傷する可能性が少なく、大量のデータを転送する可能性を生み出します。
「スレッドの幅は4〜6マイクロメートルで、人間の髪の毛よりもかなり細くなっています」とThe Vergeは報告しています。Neuralinkが明らかにしたもう1つの大きな進歩は、スレッドを自動的に脳に埋め込むロボットです。レポートより:
将来的には、Neuralinkの科学者たちは、穴を開けるのではなく、レーザービームを使って頭蓋骨を通過させることを望んでいる、とニューヨークタイムズとのインタビューで語った。その報告によれば、初期の実験はスタンフォード大学の神経科学者によって行われます。ニューヨークタイムズによると、同社は来年の第2四半期にはすぐに臨床試験を目指しているという。今日提示されているシステムは、それが実用的であれば、古い技術に比べてかなり進歩しているかも知れません。BrainGateは、最大128の電極チャンネルを可能にする一連の硬い針であるUtah Arrayに依存していました。単にNeuralinkが約束しているより少ないチャンネルということだけでなく - 脳から得られるデータが少ないことを意味する - Neuralinkのスレッドよりも硬く折り曲げにくい。それは長期的な機能にとって問題です。脳は頭蓋骨の中を移動しますが、アレイの針は移動しないため、損傷を引き起こします。Neuralinkが使用している薄いポリマーはその問題を解決するかも知れません。
しかし、Neuralinkのテクノロジーは、Utah Arrayよりも埋め込みが難しいという点で、それは非常にフレキシブルで精密だからです。ホワイトペーパーによると、この問題に対処するために、同社は「毎分6本のスレッド(192本の電極)を自動的に挿入できる脳神経外科ロボット」を開発しました。写真では、顕微鏡とミシンを足して2で割ったような物に見えます。論文によると、それは脳内の炎症反応を少なくする可能性がある血管を避けます。最後に、この論文は、Neuralinkが脳からの信号を読み、きれいにし、そして増幅することができるカスタムチップを開発したと述べています。今のところ、それは有線接続(USB-Cを使用)を介してのみデータを送信することができますが、最終的に目標は無線で働くことができるよりシステムを開発することです。
現在、同社はラットでロボットとスレッドをテストしていますが、実際には来年の早い時期に人間の被験者との共同作業を開始することを望んでいます。
7/17/2019
薬は過大評価されている?
薬のずさんな記録を考えると、医師は、患者にはるかに少ない薬を摂取するよう処方すべきである、と新しい本は主張する。
By John Horgan
私は何年もの間、特にそれが精神病やガンに関しては医学の欠陥について悩んできました。しかし、私の不満はケンブリッジ大学の科学の哲学者であるJacob Stegengaのそれに比べて軽度です。
Oxford University Press発行の医学のニヒリズム(Medical Nihilism)では、Stegengaが辛辣な医学批判を提示しています。彼の主張によれば、ほとんどの治療法はあまりうまく機能せず、そして多くの治療法が善よりも害を及ぼします。従って、私たちは「医学的介入にほとんど自信を持たず、もっと控えめにそれらに頼るべきです。これはStegengaによると医学的な無責任という意味です。私は最近人気のあるポッドキャストEconTalkでStegengaにインタビューした経済学者のRuss Robertsから医療ニヒリズムについて学びました。
医学に対する懐疑論は「治療のニヒリズム」と呼ばれることもあり、医師の間でさえもかつては広まっていた、とStegengaは述べています。1860年に、ハーバード大学医学部の学部長、Oliver Wendell Holmesは次のように書いています。「現在使用されているように、もし全医薬品が海底に沈められれば、それは人類にとってはいっそう良くなり、魚類にとってはいっそう悪くなるでしょう。」
そのような皮肉は、麻酔、無菌手術技術、ワクチン、そして真に効果的な治療法、特に感染症に対する抗生物質、そして糖尿病に対するインスリンの出現で薄れていきました。Stegengaはこれら2つの後者を「魔法の弾丸」と呼び、体の健康的な機能を損なうことなく疾患の原因を標的とする治療法を説明するために、医師/化学者Paul Ehrlichによって造られました。
研究者たちはより多くの魔法の弾丸を見つけるために力を尽くして努力してきましたが、それらはまれなままです。例えば、イマチニブ(商品名Gleevec)は、あるタイプの白血病に対して「特に効果的な治療法」です、とStegengaは言います。しかし、グリーベックは「悪心、頭痛、重度の心不全、および子供の成長の遅れを含む深刻な悪影響」があります。
パーキンソン病、アルツハイマー病、関節炎、統合失調症、双極性障害など、他のほとんどの種類の癌には信頼できる治療法がありません。Stegengaは、「広く摂取されている」薬の多くは「ほとんど効果がなく、多くの有害な副作用があります」と書いています。例としては、高コレステロール、高血圧、2型糖尿病、うつ病などがあります。
Stegengaは読者に医学的監督なしに処方された薬の服用を中止しないように警告しています。Stegengaは、治療をあまり頻繁に行わないのであれば、健康状態は改善し、費用は減少すると主張しています。ヒポクラテスがかつて言ったように、「何もしないことも良い解決策です」。
この論文に対する異議を予想して、Stegengaは彼が反科学または反医学ではないことを強調します。全く反対です。 彼の目標は、厳密な研究が治療の長所と短所について実際に明らかにしているものと一致させることで、医学を改善することです。彼の論文は、主流よりも経験的立場がさらに低い「代替」医療の支持者を鼓舞すべきではありません。彼は次のように書きます:
私はむしろ集中治療室ほど深刻な事故の後になる場所はないと思います。頭痛のためのアスピリン、多くの感染症では抗生物質、一部の糖尿病患者にとってはインスリン - ほんの一握りの本当に素晴らしい医学的介入があり、その多くは70〜90年前に発見されました。しかし、ほとんどの医療消費の尺度(患者数、金額、処方数)によって、最も一般的に採用されている介入、特に最近の数十年間に導入された介入は、医療のニヒリズムに対する説得力のある根拠を提供します。
ここに重要なポイントがあります:
医学研究は肯定的な結果に向かって傾いています。Stegengaの本の核心は、臨床試験に対する彼の批判です。誰もが良い結果を望んでいます。患者さんは治癒することを切望しており、プラセボ効果を起こしやすいのです。ジャーナルはそれを公表するために良い医学ニュース、ジャーナルおよびマスメディアを公表し、それを読むために大衆に熱心です。研究者は治療が有効であることを示すことによって助成金、栄光、そして任期を得ることができます。
最も重要なことに、研究の大部分を後援している生物医学会社は、Prozacのような単一の承認された薬から数十億ドルを稼ぐことができます。科学文献に欠陥があり、Stegengaが繰り返し引用しているスタンフォード統計学者のJohn Ioannidisは、医学研究には「利益相反がたくさんある」と主張しています。 ほとんどの臨床研究、Ioannidisは、2016年にはっきりと「有用ではありません」と主張しました、それは「健康と病気の結果に影響を与えない」ことを意味します。
医学研究のゴールドスタンダードであるランダム化比較試験は、偏りを最小限に抑えると考えられています。典型的には、被験者は無作為に2つのグループに分け、その一方は潜在的な治療を受け、もう一方はプラセボを受ける。研究者と被験者は「盲目」です。つまり、誰がその薬やプラセボを服用しているのか分からないということです。
しかし、Stegengaが指摘しているように、研究者たちは試験を計画し、実施しそして解釈する際に多くの判断を呼びかけなければならない。ランダム化比較試験は、このように彼らが思うよりもはるかに厳格で客観的で、より「影響されやすい(malleable)」か、または操作を受けやすいのです。 同じことが複数の試験からのデータを評価するメタ分析にも当てはまります。
この影響の受けやすさは、なぜ異なる試験の結果が大きく異なるのか、そして業界が後援する研究が独立した調査よりもはるかに利益を示す可能性が高いのを説明します。業界関係のある研究者によって実施された抗うつ薬のメタ分析は、独立した分析よりもネガティブな効果について言及する可能性が22倍少ないです。別の分析によると、高血圧治療の会社主催の比較は、他の選択肢よりもスポンサーの治療を支持する可能性が35倍高いのです。
より厳密な研究はより少ない利点を示しています。 肯定的な結果に熱心な研究者はp値ハッキングに従事することができます。 p値ハッキングはチェリーピッキング(いいものだけを選ぶ)の一種であり、研究者はランダム相関と思われるものに重要性を帰属させることができます。p値ハッキングを防止する1つの方法は、研究者に研究を事前登録させ、仮説と方法を事前に説明させることです。
2015年の研究では、連邦政府が資金を提供している心臓病治療の試験に対する事前登録の効果を比較しました。事前登録が実施された2000年以前に実施された試験のうち、57％が介入による恩恵を受けましたが、後の試験の8％は業界からのインプットが少なく、独立した研究者からの投入も多くなっています。Stegengaは、2000年以降の平均的な介入は「役に立たなかった」と述べています。
証拠の基準が高い独立した研究者のグループであるコクラン共同計画によるメタ分析は、他のグループによるメタ分析と比較して肯定的な発見を報告する可能性が半分あります。Stegengaによると、これらの研究の厄介な意味は「医学におけるより良い研究方法はより低い有効性の評価につながる」ということです。一般的に、そしてこれは強調する価値があります、治療の研究の厳しさはそれが見つける利点に反比例します 。
薬の有害な影響は過少報告されています。Stegengaは、業界と密接に関係しているFDAが、医薬品の承認において基準を低く設定しすぎていると非難しています。彼は、FDAの上級疫学者が、同局は「承認した薬物の利点を一貫して過大評価し、安全性の問題を軽視し、または無視した」と訴えたことを引用します。
研究は一般に悪影響を過少報告しています。予備的な「安全性」試験はほとんどの場合、未発表のままになりますが、後の多くの試験では主に悪影響を示します。さらに、公表されている研究では、薬物に対する有害な反応のために研究から離脱した患者に関するデータは提供されていないことが多いです。薬の有害な影響は、規制当局による承認を得て初めて明らかになります。ある調査によると、承認後の監視では、害は94％過小評価されています。
承認後に最近中止された医薬品には、バルデコキシブ、フェンフルラミン、ガチフロキサシン、ロフェコキシブが含まれます(これらは一般名、Googleはブランド名です)。安全性の懸念が高まっているにも関わらず、市場に出回っているものには、セレコキシブ、アレンドロン酸、リスペリドン、オランザピンおよびロシグリタゾンが含まれます。
2型糖尿病治療薬としてアバンディアとして発売されたこの最新の薬は、初期の研究で心臓病や死亡のリスクを高めました。Stegengaによれば、製造業者は、新しい試験ははるかに低いリスクを示したと主張したが、試験は最も有害に反応する可能性がある被験者を除外した。
医療提供者は、「病気の危険を冒す」ことに取り組んでいます。Stegengaは、障害を発明し、一般的な病状を病理学的に調べることによって、医師や製薬会社の市場を拡大しています。彼はこの慣行を「病気を危険にさらす」と呼んでいます。疑わしい障害には、落ち着きのない足症候群、勃起不全、月経前不快気分障害、口臭、男性脱毛症、注意欠陥多動性障害、骨粗鬆症および社会不安障害があります。
Stegengaは、FDAは最近、「Even the Score」という患者擁護団体による積極的なロビー活動の後、フリバンセリンを「女性の性的機能不全」として承認したと指摘しています。同グループは、FDAが「勃起不全のための薬を承認したが、女性の性的欲求のための薬をまだ承認していなかった」ため、「ジェンダーバイアス」を非難しました。このロビー活動はフリバンセリンの製造業者によって組織され資金提供されたと伝えられており、メタ分析では限界的な利益と重大な悪影響があることが示されています。
同様に、医師は新しい集団で障害を「発見」し続けます。特に厄介な例は、乳児の精神病の診断です。ニューヨークタイムズは、2014年に医師は、抗うつ薬の処方箋を83,000、2歳以下の乳児に抗精神病薬の処方箋を約2万書いたと報じました。
スクリーニングは命を救うものではありません。彼は治療に焦点を当てていますが、Stegengaもテストを嫌います。予防的ケアの基本は、無症候性の人々を病気についてスクリーニングすることによって、早期の診断とより良い結果がもたらされることです。残念なことに、Stegengaは、スクリーニングは「偽陽性診断、過剰診断および過剰治療」につながる可能性があると書いています(過剰診断は、検査が、放置しても害を及ぼすことは決して無い小さな腫瘍または他の異常を検出したときに行われます)。
スクリーニングのほとんどの評価では、前立腺癌のマンモグラム検査やPSA検査など、疾患の検査が検査を受けていない対照と比較してその疾患による死亡を減らすかどうかを調べます。疾患特異的方法は合理的に思えますが、それは疾患、治療または試験(結腸鏡検査により引き起こされる穿孔結腸のような)から生じる死亡を誤って除外することによって試験を過度に好むかもしれません。それ故に何人かの研究者はテストがスクリーンされたそしてスクリーンされていないグループにおいて、指定された原因に関係なくすべての死を数えることによって評価されるべきであると主張しました。
2015年のレビューでは、癌、心臓病、糖尿病、呼吸器疾患の4つの主要な殺人者に対する一般的なテストが調べられました。この研究では、疾患特異的死亡率を低下させるスクリーニング方法はほとんどなく、全原因死亡率を低下させるものはないことが分かりました。著者らは、「スクリーニングによる死亡率の大きな利点への期待は慎重に緩和される必要がある」と結論を出しています。
現代医学は過大評価されています。Stegengaによれば、現代医学は平均寿命を伸ばすことに対してあまりにも多くの信用を得ています。彼は1970年代に学者/医師Thomas McKeownによってまとめられた、寿命の延長は生活水準、栄養、水処理および衛生の改善された基準よりも少ないワクチン、抗生物質および他の医学的進歩によってもたらされるという証拠を挙げています。
McKeownの研究は批判にも関わらず影響力を持ち続けています。さらに、医療提供者は日常的にヒポクラテスの法令に違反して害を及ぼすことはありません。2013年の研究によると、米国では毎年400,000人を超える「予防可能な院内死」が発生し、800万人もの患者が「深刻な害」を被っていると推定されています。
Stegengaは、「医学のニヒリズム」は厳しく聞こえることを認めています。読者の中には、鎮痛剤を含む治療法の重視とケアへの重点を軽くすることを求めている、より穏やかな薬を好むかもしれません(現在のオピオイド流行は疼痛管理も危険をもたらすことを示している)。治療の減少を支持する何人かの医者は彼ら自身を「医学の保守派」と呼びます。
しかし、私は「医学のニヒリズム」が好きです。それはヘルスケア提供者と消費者の顔を越えて非常に必要とされる平手打ちを提供します。私たちが最悪の現状の受け入れから私たちを喚起する必要がある平手打ちです。私たちの多くが薬の制限を受け入れ、それに従って行動すれば、私たちの健康は確実に向上し、私たちのコストは急落します。
Stegengaの本は完璧ではありません。彼は少し反復的で、ベイズの分析が大好きです。(私の考えでは、彼のベイジアン計算は単に失敗の長い歴史を持つ分野での突破口とされることに警戒すべきであるという常識的な結論を単に肯定しているだけです。) 彼は、特定の進歩、特にワクチンに関して医学的信用を与えることに少し棘があります。
EconTalkのRuss Robertsのように、Stegengaが最近私が費やしている癌治療にもっと考えてくれることを願っています。Stegengaは、乳がんや前立腺がんと診断された友人に治療を中止するよう勧めますか? 彼は自分でそれを諦めますか? (私はこれらの質問や他の質問に対する彼の回答を次の投稿で発表するつもりです。)
それでも、私はStegengaが彼の重要でタイムリーな勇敢な本に拍手を送ります。Gilbert WelchのLess Medicine、More Health、Marcia AngellのThe Truth about Drug Companies、Elisabeth RosenthalのAn American Sickness、Robert WhitakerのAnatomy of an Andeomyなど、その他の厳しい医学批判を補完するものです。メディカルニヒリズムが広く読まれ、議論されていること、そしてそれが医療行為、研究とコミュニケーション、私たちが必要としている改革の改革をもたらすのに役立つことを私は願っています。
Further Reading:
医療専門家による治療の客観的な評価については、コクラン共同計画(最近論争に巻き込まれた)、NNT(「治療に必要な数」、つまり、1人の人が治療を受けるために治療を受けなければならない人の数を表す)やRxisk.org(薬の効果についての患者のレポートを提供する)のWebサイトを参照して下さい。