何かが起こっています。 人々は不幸です。 市民不安の幽霊は私たちのプログラミングコミュニティに出没します。

初めて、かなりの数のWeb開発者がWebプラットフォームに公然と疑問を呈しています。 ここに典型的な記事と議論があります。 ここに別の記事があります。 そしてもう一つ 。 もっとリストすることもできますが、この記事を読むのに十分なプログラミングに興味があるなら、おそらく今年のWeb開発の現状について少なくとも1回の朗読を既に読んでいるでしょう。 この記事はそれらの1つではありません。 私は、毎日Web開発をしなければならない人々と既存の現状をいじめることで競争することはできません。 これは別の記事です。


フロントエンドハッカーです

少なくともアプリケーションを作成するために、最終的にWebに取って代わるWebのような優れた競合他社を作成できるかどうかを検討したいと思います。 ウェブにはまだドキュメント配布システムのような問題がありますが、心配するほど深刻ではありません。

これは2つの記事の最初の記事です。 最初の部分では、Webプラットフォームの深くて不溶性の問題を検討します。それを放棄することが唯一の選択肢であることを納得させたいと思います。 最終的に、最初に分析しない限り、問題を解決することは不可能です。 また、これらの問題を議論することが政治的に受け入れられるようになった理由を簡単に検討しますが、それらは新しいものではありません。

第2部では、少数の開発者グループが妥当な時間内に作成できるアプリケーション用の新しいプラットフォームを提案します。どのプラットフォーム（IMHO）が現在のものよりもはるかに優れているはずです。 もちろん、誰もが後者に同意するわけではありません。 問題に同意することは、解決策に同意することよりも常に簡単です。

パート1。行きましょう。

---

なぜウェブは死ななければならないのか

Webアプリケーション。 彼らはどのように見えますか？ たくさんの問題をリストできますが、2つに焦点を当てましょう。

1. Web開発は1990年代をゆっくりと繰り返しています。
2. Webアプリケーションは保護できません。

Facebookの最新のトレンディなWebフレームワークであるFluxの素晴らしい投稿です 。 著者は、Fluxが1985年にリリースされたWindows 1.0で使用されているプログラミングモデルを再現していることを指摘しています。 マイクロソフトは、低速のコンピューターに適しているためこのモデルを使用しましたが、プログラミングするのは非常に不便でした。そのため、基礎となるWndProcメッセージングシステムを抽象化できる製品エコシステム（OWLなど）全体が成長するまで10年もかかりませんでした。

React / Fluxがこのように機能する理由の1つは、Webレンダリングエンジンが非常に遅いためです。 これは事実であり、ユーザーに表示される最終結果は、Windowsユーザーが20年前に見ることができたよりも少し複雑です。


Windows 98

もちろん、画面の解像度は大きくなりました。 好きなグレーの色合いが変わりました。 ただし、上に表示されるUIは、下に表示されるUIと複雑さが非常に似ています。



アイコンのファッションも変わっていません！ Windows 98はグレースケールのフラットアイコンの新しいトレンドを導入しましたが、以前のアイコンはカラーで、密集したピクセル化された画像でした。

しかし、Office 2000は75 MHzのCPUと32 MBのメモリでかなり満足でしたが、スクリーンショットのGoogleドキュメントは2.5 GHzのCPUとほぼ10倍のメモリを使用します。

パフォーマンスと機能が10倍向上した場合、それは許されますが、実現しませんでした。 1995年の開発プラットフォームには、デフォルトで次のものがすべて含まれていました。

• レイアウト制限とデータバインディングを備えたビジュアルUIエディター。
• 多くの言語での高度なソフトウェアコンポーネントのサポート。 静的に型指定されたネイティブコードとスクリプト言語を混在させることができます。
• リリースされた実行可能ファイルは非常に効果的であったため、数メガバイトのRAMで動作しました。
• グラフ作成、テーマ設定、3Dグラフィックス、ソケットプログラミング、インタラクティブデバッグのサポート...

これらの機能の多くは、ここ数年でWebプラットフォームにのみ登場しました。 Webアプリケーションは実際のソケットを使用できないため、代わりに「Webソケット」をサポートするためにサーバーを変換する必要があります。 UIコンポーネントのような基本的なものは静かな恐怖です。 本格的なWeb IDEはありませんが、異なるプログラミング言語を混在させることについて...まあ、JavaScriptですべてをコンパイルしてみることができます。 時々。

開発者は1つの理由でWebアプリケーションを作成することを好みます-そのようなアプリケーションからのユーザーの期待は非常に低いです。 Windows 95のアプリケーションからは、アイコン、ドラッグアンドドロップ、操作の取り消し、ファイル拡張子との関連付け、通常のキーボードショートカット、バックグラウンドでの便利なアクティビティ、さらにはオフライン作業まで期待できます。 しかし、これらは最も単純なアプリケーションです。 本当にクールなソフトウェアをOfficeドキュメントに埋め込んだり、Explorerの機能を拡張したり、プログラムの作成者が元々知らなかった任意のプラグインによって機能を拡張したりすることができます。 Webアプリケーションは通常、何もしません。

これはすべて蓄積されています。 デスクトッププログラムを作成すると、ファイルタイプのアイコンを作成するなど、支払わなければならないさまざまな「税金」を考慮しても、生産性が大幅に向上します。 私もそれらを使用することを好みます。 そして、他の人との会話から、私は私だけではないことを知っています。

HTMLはドキュメントのプラットフォームとして非常にわかりやすい設計哲学とツールキットを備えていたため、Webはそのようになったと思いますが、アプリケーションのプラットフォームとしてはHTMLを鼻に固定する必要があり、これまでのところ何も起こりませんでした。 したがって、ファイルの関連付けのような非常に基本的なものはありません。 ただし、HTML5にはピアツーピアのビデオストリーミングがあります。Googleがハングアウトを作成したかったためです。ただし、Googleの優先事項は、標準に追加する機能の主なものです。 このような問題を回避するには、アプリケーションの概念を念頭に置いて設計されたプラットフォームが必要です。そして、おそらく、上からドキュメントを追加します。

Webアプリケーションを保護できません

1990年代後半、PLのひどい実装がソフトウェア業界に影響を及ぼしました。C/ C ++プログラムのセキュリティ脆弱性は、個別に修正できる珍しいバグではなくなりました。 彼らは至る所に現れました。 人々は、C / C ++コードがインターネットに置かれた場合、悪用が必然的に現れることを理解し始めました。

Code Redネットワークワームに関する 2001年のSANSレポートを読むと、その世界の無実を理解できます。

「Microsoftおよび米国のセキュリティ機関の代表者は記者会見を開き、Microsoft Webサイトからパッチをダウンロードするようユーザーに指示し、このパッチをダウンロードするために「市民の義務」と呼びました。 Code Redを配布した後、CNNおよびその他のニュースアウトレットは、ユーザーにシステムにパッチをインストールするよう警告しました。

Windowsには自動更新がありましたが、正しく覚えていればデフォルトで無効にされていました。 ユーザーの知識がなくてもプログラムを変更できるという考えはタブーでした。


ブラスター感染の最初の兆候

徐々に、業界は変化し始めましたが、叫び声と抗議がありました。 当時、LinuxおよびMacユーザーは、これは一般にMicrosoftの純粋な問題であるとしばしば言いました...そして彼らのシステムはスーパープログラマーによって作成されました。 そのため、Microsoftは実存的な危機に直面しているという事実を受け入れ、「 安全な開発ライフサイクル 」（巨大な再トレーニングプログラムと新しいプロセス）を導入しましたが、競合他社は実質的に非アクティブでした。 レドモンドはWindows XPにファイアウォールを追加し、コードに署名するための証明書を発行しました。 モバイルコードは禁止されています。 セキュリティの脆弱性が無限のストリームにあることが明らかになったとき、「パッチ火曜日」パッチの定期的なリリースを導入しました。 スマートハッカーは、以前は安全と思われていた既知のバグを悪用する方法と、以前は信頼できると思われていたエクスプロイトからの保護を回避する方法を発見し続けました。 MacとLinuxのコミュニティは徐々に休止状態から抜け出し、ウイルスやエクスプロイトから魔法のように保護されていないという事実に気づき始めました。

最後のターニングポイントは、GoogleがChromeをリリースした2008年でした。Chromeは、レンダリングエンジン用の複雑だが完全に見えないサンドボックスの作成に多大な労力を費やしたという観点から重要なプロジェクトです。 言い換えれば、業界をリードする開発者は、 彼らがどんなに一生懸命取り組んでも安全なC ++コードを書くことができないことを認めています 。 この論文と分離されたアーキテクチャは、事実上の標準となっています。

ウェブプラットフォームが来ました

残念ながら、ウェブは私たちを安全なアプリケーションの恵まれた土地に連れて行っていません。 Webアプリケーションは何らかの方法で母OSから隔離されていますが、これは優れていますが、アプリケーション自体は2001年のWindowsコードよりも信頼性がほとんどありません。 継承された問題を永久に取り除く代わりに、Webは単にバッファオーバーフローの1つのタイプを別のタイプに置き換えました。 デスクトップアプリケーションでは、同じメモリの二重解放（二重解放）、スタック整合性の脆弱性（スタックスマッシュ）、解放後のメモリ使用量（解放後使用）などの脆弱性が悪用されました。 Webアプリケーションはそれらを修正しましたが、同じ種類の独自のエラー（SQLインジェクション、XSS、XSRF、ヘッダーインジェクション、MIMEタイプの混合など）を提示しました。

これはすべて簡単な論文につながります：

安全なWebアプリケーションを作成できません。

私たちはつまらないものではありません。 私はすべてのWebアプリケーションについて文字通り話をしているわけではありません。 はい、安全なHTML Hello World、フラグを手に書くことができます。

私は現実的な用語で書かれた実際のまともなサイズのWebアプリケーションについて話しているのですが、このステートメントは簡単ではありませんでした。 Googleで8年間働いた後、理解が得られました。 そこで、最高で最も才能のあるWeb開発者が悪用可能なバグを伴うコードを何度も発行するのを見ました。

Googleのセキュリティ部門は世界でも最高の1つであり、おそらく最高です。社内カリキュラムのために、最も人気のあるWeb開発エラーをリストした便利なガイドをリリースしています。 ブラウザに表示するデータを安全に送信する方法に関するアドバイスは次のとおりです。

. , (« »), , - , . -, XSRF, , , JSON . -, JSON POST, <script>. -, , . — - , ])}while(1);</x>. , .

: . , , . , , , /* */, . (: , - */ ?)

. , , - Google, - .

, . HEIST -, . -. .

! ! REST/JSON — , -. ( ).

, -, , , . : -, , -, - .

:

• ,
• , ,
• (same origin policy)

— C, : XSS SQL , . , , . (escaping), , .

: : . - , . , , UI .

HTTP HTML . Authy, “../sms” SMS. , - Authy , . , HTML, . API «», .

REST , XML, XML JSON — , , .

: , REST — . REST — , HTTP , , . , , . . , - , RPC.

- — . :

… .

, - , JavaScript, .

, , DNS rebinding , .

SOP (same origin policy) , Netscape . . , 10 . , Netscape , , , . 10- .

, HEIST SOP, HEIST - , , , , , . , -.

: , . , . , .

, -, , , , .

---

HTML5 — . , -, . : , , , . . , , .

. , . Flash, Shockwave Java. , . — , : , , , , . . «-» . , Macromedia Flash — .

. , : HTML5, , . W3C , Google Microsoft, - . . JavaScript .

. : ?