[Перевод] Пора убить веб
Что-то происходит. Люди недовольны. Призрак гражданских беспорядков преследует наши программистские сообщества.
Впервые значимое число веб-разработчиков открыто ставят под сомнение веб-платформу. Вот характерная статья и обсуждение. Вот другая статья. И ещё одна. Я бы мог перечислить и больше, но если вы достаточно интересуетесь программированием, чтобы читать эту статью, то наверняка уже читали в этом году хотя бы одну напыщенную декламацию о современном состоянии веб-разработки. Эта статья не из таких. Я не могу соревноваться в издевательствах над существующим статусом-кво с людьми, которым приходится заниматься веб-разработкой каждый день. Это другая статья.
Это ты, хакер фронтенда
Я хочу поразмышлять о том, можно ли создать настолько хорошего конкурента вебу, что он в итоге заменит его и включит в себя, по крайней мере, для написания приложений. У веба есть ещё проблемы как у системы распространения документов, но не настолько серьёзные, чтобы о них беспокоиться.
Это первая из двух статей. В первой части рассмотрим глубокие, неразрешимые проблемы веб-платформы: я хочу убедить вас, что отказ от неё является единственным вариантом. В конце концов, невозможно решить проблему, если сначала не подвергнуть её анализу. Также кратко рассмотрим, почему сейчас стало политически приемлемо обсуждать такие вопросы, хотя они не являются чем-то новым.
Во второй части я предложу новую платформу для приложений, которую способна создать небольшая группа разработчиков за разумное время, и которая (IMHO) должна быть гораздо лучше, чем то, что мы имеем сейчас. Конечно, не все согласятся с последним. Согласиться с проблемами всегда проще, чем согласиться с решениями.
Часть 1. Поехали.
Почему веб должен умереть
Веб-приложения. На что они похожи, а? Я могу перечислить кучу их проблем, но давайте остановимся на двух.
- Веб-разработка медленно повторяет 1990-е годы.
- Веб-приложения невозможно защитить.
Вот хороший пост по Flux, последнему модному веб-фреймворку от Facebook. Автор обращает внимание, что Flux воссоздаёт модель программирования, которую использовала Windows 1.0, выпущенная в 1985 году. Microsoft использовала эту модель, потому что она подходила для медленных компьютеров, но под неё было настолько неудобно программировать, так что не прошло и десятилетия, как выросла целая экосистема продуктов (вроде OWL), позволяющих абстрагироваться над лежащей в основе системой сообщений WndProc.
Одна из причин, почему React/Flux работают таким образом — очень медленные движки веб-рендеринга. Это правда, и конечный видимый пользователю результат лишь немного более замысловатый, чем пользователь Windows мог видеть 20 лет назад:
Windows 98
Конечно, разрешение экрана стало больше. Изменились оттенки серого, которые нам нравятся. Но UI, который вы видите вверху, по сложности довольно похож на UI, который вы видите внизу:
Даже мода на иконки не изменилась! Windows 98 представила новый тренд плоских иконок в оттенках серого, в то время как предыдущие были цветными, плотно упакованными пиксельными изображениями.
Но Office 2000 вполне довольствовался CPU на 75 МГц и 32 МБ памяти, в то время как Google Docs со скриншота использует CPU на 2,5 ГГц и почти в десять раз больше памяти.
Если бы мы получили десятикратный прирост в производительности и функциональности, это было бы простительно, но мы его не получили. Платформы разработки в 1995 году по умолчанию обладали всем нижеперечисленным, только для начала:
- Визуальный редактор UI с ограничениями макета и привязкой данных.
- Продвинутая поддержка программных компонентов на многих языках. Вы могли смешивать статически типизированный нативный код и языки сценариев.
- Выпускаемые исполняемые файлы были настолько эффективны, что работали на нескольких мегабайтах RAM.
- Поддержка построения графиков, тематизации, 3D-графики, программирования сокетов, интерактивной отладки…
Многие из этих функций появились на веб-платформе только в последние несколько лет, и часто весьма поверхностно. Веб-приложения не могут использовать реальные сокеты, так что вместо этого серверы приходится переводить на поддержку «веб-сокетов». Такие базовые вещи как компоненты UI — это тихий ужас. Не существует серьёзной Web IDE, а насчёт смешивания разных языков программирования… ну, вы можете попытаться всё скомпилировать в JavaScript. Иногда.
Разработчики любят писать веб-приложения по одной причине — ожидания пользователей от таких приложений исключительно низки. От приложений для Windows 95 вы ожидаете наличия пиктограмм, перетягивания мышкой, отмены произведённых действий, ассоциаций с расширениями файлов, нормальных сочетаний «горячих клавиш», полезной деятельности в фоновом режиме… и даже работы в офлайне! Но это самые простые приложения. По настоящему крутой софт мог встраиваться в документы Office или расширять функциональность Explorer, или допускать расширение функциональности произвольными плагинами, которые изначально неизвестны автору программы. Веб-приложения обычно не делают ничего подобного.
Всё это накапливается. Я чувствую себя гораздо продуктивнее, когда пишу десктопную программу (даже с учётом разных «налогов», которые вам придётся платить, вроде изготовления пиктограмм для своих типов файлов). Использовать я тоже предпочитаю их. И из разговоров с другими знаю, что я не один такой.
Думаю, что веб стал таким, потому что HTML вышел с вполне вразумительной философией дизайна и инструментарием как платформа для документов, но в качестве платформы для приложений HTML пришлось закреплять на соплях, и ничего хорошего до сих пор не получилось. Поэтому не существует самых базовых вещей вроде ассоциаций файлов. Зато в HTML5 имеется пиринговый видеостриминг, потому что Google хотела сделать Hangouts, ну, а приоритеты Google — это главное в том, какие функции добавлять в стандарт. Чтобы избежать такой проблемы, нам нужна платформа, которая изначально спроектирована с мыслью о приложениях, а затем, может быть, добавить сверху ещё и документы, а не наоборот.
Веб-приложения невозможно защитить
В конце 1990-х ужасная реализация ЯП нависла над программной индустрией: уязвимости безопасности в программах C/C++ перестали быть редкими ошибками, которые можно исправить по отдельности. Они появились повсюду. Люди стали понимать, что если код C/C++ выставить в интернет, неизбежно появятся эксплоиты.
Можно оценить невинность того мира, если почитать отчёт SANS по сетевому червю Code Red от 2001 года:
«Представители Microsoft и агентств безопасности США провели пресс-конференцию, где инструктировали пользователей скачать патч с сайта Microsoft и назвали «гражданским долгом» скачивание этого патча. CNN и другие новостные издания после распространения Code Red предупредили пользователей о необходимости установить патчи на свои системы».
В Windows существовали автоматические обновления, но если я правильно помню, отключенные по умолчанию. Идея, что программа может изменяться без ведома пользователя, была эдаким табу.
Первые признаки заражения Blaster
Постепенно индустрия начала меняться, но с криками и протестами. В то время пользователи Linux и Mac частенько говорили, что это вообще чисто проблема Microsoft…, а их системы созданы некими сверхпрограммистами. Так что в то время как Microsoft приняла факт, что столкнулась с экзистенциальным кризисом и ввела «жизненный цикл безопасной разработки» (гигантская программа переобучения и новый процесс), её конкуренты практически бездействовали. Редмонд добавил файрвол в Windows XP и выпустил сертификаты для подписи кода. Мобильный код запретили. Когда стало ясно, что уязвимости в безопасности идут бесконечным потоком, ввели периодический выпуск патчей «Patch Tuesday». Умные хакеры продолжали делать открытия, как эксплуатировать известные ранее баги, которые казались безопасными, и как обходить защиты от эксплоитов, ранее казавшиеся надёжными. Сообщества Mac и Linux начали постепенно выходить из спячки и осознавать факт, что они не являются волшебным образом защищёнными от вирусов и эксплоитов.
Последним поворотным моментом стал 2008 год, когда Google выпустила Chrome, важный проект с той точки зрения, что они потратили массу усилий на создание сложной, но совершенно незаметной песочницы для движка рендеринга. Другими словами, лучшие в индустрии разработчики признали, что они не способны написать безопасный код C++ независимо от того, как упорно будут над ним работать. Такой тезис и изолированная архитектура стали стандартами де-факто.
Пришла очередь веб-платформы
К сожалению, веб не вывел нас на благословенную землю безопасных приложений. Хотя веб-приложения в каком-то роде изолированы от материнской ОС, и это хорошо, но сами приложения вряд ли более надёжны, чем код Windows от 2001 года. Вместо того, чтобы навсегда избавиться от доставшихся по наследству проблем, веб просто заменил один тип переполнения буфера другим. В десктопных приложениях эксплуатировались уязвимости типа двойного освобождения одной и той же памяти (double free), уязвимости целостности стека (stack smash), использования памяти после освобождения (use after free) и прочие. Веб-приложения исправили их, но представили собственные такие же ошибки: инъекции SQL, XSS, XSRF, инъекции заголовков, смешение типов MIME и так далее.
Всё это ведёт к простому тезису:
Невозможно написать безопасное веб-приложение.
Не будем педантами. Я не говорю буквально обо всех веб-приложениях. Да, можно написать безопасный HTML Hello World, флаг в руки.
Я говорю о реальных веб-приложениях пристойного размера, написанных в реалистичных условиях, и это заявление далось нелегко. Понимание пришло ко мне после восьми лет работы в Google. Там я наблюдал, как самые лучшие и талантливые веб-разработчики снова и снова выдают код с эксплуатируемыми багами.
Отдел безопасности Google — один из лучших в мире, может и лучший, и для внутренней учебной программы они выпустили это полезное руководство с перечислением самых популярных ошибок веб-разработки. Вот их совет, как безопасно отправлять данные для отображения в браузере:
Для исправления вы можете сделать несколько изменений. Любое из этих изменений предотвратит ныне возможные атаки, но если добавить несколько уровней защиты («глубокая защита»), вы защититесь от того, что какой-то из уровней не сработает в случае уязвимостей в браузере, которые найдут в будущем. Во-первых, используйте токен XSRF, как обсуждалось ранее, это гарантирует, что результаты JSON с конфиденциальными данными возвращаются только для ваших страниц. Во-вторых, ваши страницы ответа JSON должны поддерживать только запросы POST, чтобы предотвратить загрузку скрипта через тег
