Егор Хомяков рассказывает, как хакеры могут надолго внедрить в браузеры посетителей сайта вредный джаваскрипт с помощью AppCache.

AppCache — это технология для создания прогрессивных веб-приложений. В подключенном на страницу манифесте сайт перечисляет файлы (страницы, стили, скрипты, изображения), и они скачиваются на компьютер пользователя. При дальнейших запросах к сайту эти файлы будут браться уже с компьютера, а не скачиваться с сервера. Если закешировать достаточный набор файлов, сайт будет работать без интернета.

Проблема в том, что если прописать в манифесте ссылку на сам манифест, то он закешируется навсегда.

Хакеры могут использовать это. Например, они получили доступ к серверу или организовали перехват и подмену трафика между клиентом и сервером. Они меняют код страниц, чтобы добавить свои джаваскрипт и манифест. В манифесте включено кеширование этих страниц, а заодно и самого манифеста. Таким образом, вредный код останется на компьютере пользователей даже после того, как атака прекратится.

Бороться с этим владельцы сайта могут двумя способами: возвращать ошибку 404 или 410 по адресу, где был расположен манифест, или попросить каждого пользователя зайти в chrome://appcache-internals/ и очистить кеш. Больше никак его не удалить.

Еще одно описание этой атаки.

Адам Сильвер описывает свой подход к написанию поддерживаемого CSS. Основные идеи:

1. Код надо делить на модули. Модуль — это заголовок, подвал, форма поиска, текст поста. Один модуль может находиться внутри другого, но они не должны зависеть друг от друга.
2. Классы должны иметь семантические имена. Не должно быть классов red, pull-left, clearfix.
3. Вообще повторно использовать правила для разных модулей плохо. Если в двух блоках должны быть красный текст, нужно не вешать на оба класс red, а повторить нужное правило в описании каждого блока. Иначе будут появляться регрессии (изменение класса red затронет сразу все компоненты, использующие его), проблемы с состояниями (:hover, :focus) и другие проблемы. Если несколько разных компонентов всё-таки должны быть одинаковыми, селекторы можно перечислить через запятую.
4. Не нужно использовать ID для определения стилей. Их можно использовать на формах или в джаваскрипте. В CSS они не приносят пользы и только мешают, потому что правило, определенное по ID, нельзя переопределить правилом для класса.

5. Правила именования классов могут быть любыми, но они должны быть едиными. Здесь предлагают такую структуру:

   <moduleName>[-<componentName>][-<state>]

6. Имена классов для состояний и модификаторов должны содержать название модуля или компонента.

Неправильно:

<p class="myModule-title isDisabled">

Правильно:

<p class="myModule-title myModule-title-isDisabled">

Похожий подход описывают и в других местах. В стайлгайде Трелло пишут в целом то же самое, хотя есть и отличия. Например, они всё-таки дают состояниям и модификаторам имена вроде isDisabled, но при этом запрещают определять правила только для .isDisabled без указания модуля.

В веб-разработке между появлением новой технологии и превращением ее в стандарт может пройти несколько лет. Даже если польза от нее очевидна. Образование разработчиков, добавление поддержки во фреймворки, распространение новых версий браузеров — всё это требует времени. В этот промежуток интересно обращать внимание на небольшие особенности сайтов, которые уже внедрили у себя это новшество. По ним можно понять, что разработчики этого сайта любят свое дело, а заодно почувствовать вкус будущего. Стив Джобс хотел, чтобы его компьютеры выглядели изнутри не хуже, чем снаружи. Это примерно то же самое. Адриан Головатый перечисляет технологии, которые в разное время считались передовыми.

• 90-е: динамические сайты. Изначально сайты состояли из простых HTML-страниц, которые заливались на сервер через FTP. Адреса страниц вроде example.com/page.cgi?id=123 показывали, что этот сайт работает принципиально по-другому — в нем страницы динамически генерируются скриптом. Сейчас так делают уже практически все.
• 2002: верстка полностью на CSS. До этого все верстали таблицами и прозрачными гифками. CSS тогда уже был, но его обычно использовали только для оформления текста, а не для полной верстки страницы. Теперь верстка таблицами уже встречается редко, в основном, в HTML-письмах.
• 2003: красивые URL. На тот момент URL зависел от используемой технологии. На PHP адрес мог выглядеть как example.com/page.php?id=234, на ASP — как example.com/page.aspx?id=234. Благодаря файлам .htaccess и модулю mod_rewrite из них стали убирать лишнее, а потом появились серверные фреймворки с возможностью настройки URL-роутинга, и всё стало еще проще. Кстати, Адриан Головатый отмечает, что они создали Django в том числе и потому, что в python-фреймворках того времени нельзя было красиво настроить URL.
• 2005: аякс. Прежде для загрузки данных сайту требовалось полностью обновить страницу. Поэтому пользоваться некоторыми сайтами было неприятно и тяжело — например, сервисом Mapquest, где страница перезагружалась каждый раз после зума или перемещения карты. Первыми крупными сервисы на аяксе были Gmail и Гугл-карты, и они казались чудом. Те же самые карты двигались и зумились без обновления страницы. Сейчас аякс уже везде, и в нем нет ничего удивительного.
• 2009: кастомные шрифты. До CSS3 веб-разработчики могли использовать всего шесть шрифтов. Times New Roman или Georgia, если нужны шрифты с засечками. Verdana, Arial или Trebuchet, если без засечек. Или Courier, если нужен моноширинный шрифт. В CSS3 появилась возможность писать тексты на сайте любым шрифтом. Адриану Головатому потребовался год, чтобы перестать удивляться, встречая на сайте шрифт не из «большой шестерки». Но со временем кастомные шрифты стали нормой.
• 2010: адаптивные сайты. Популярность адаптивной верстки стала постепенно расти в середине нулевых. Возможность создавать «резиновые» сайты была практически всегда. Но только некоторые разработчики старались сделать свой дизайн красивым на любом экране независимо от размера. Естественно, сейчас этого тоже ожидают от всех сайтов.
• 2016 и далее. Самое интересное из последних нововведний — сервис-воркеры. Раньше для работы любого сайта требовалось соединение с интернетом. Но в 2015 производители браузеров стали реализовывать у себя возможность работы в офлайне благодаря специальному кешу и возможности перехватывать запросы из джаваскрипта. Зная историю, можно сказать, что прогрессивные веб-сайты — следующий прорыв, вероятно, самый крупный после аякса. Пока что работа без интернета поддерживается только некоторыми экспериментальными сайтами. Но со временем поддержка будет расти, и возможно, это тоже станет новым стандартом.

Хейдон Пикеринг рекомендует воздерживаться при верстке от четырех вещей:

1. Разделение на несколько CSS-файлов. В CSS важен порядок объявления правил. Поэтому если файлов будет много, придется следить, в каком порядке они подключаются.
2. Вложенность (в Sass). Файлы стилей обычно и так организованы хаотично, а вложенность даст беспорядоку еще одно измерение.
3. Размеры в пикселях. Если установить размер шрифта в пикселях, пользователь не сможет менять размер текста. Кроме того, прописать размеры элементов в em и rem проще, чем задавать разные значения в пикселях в зависимости от размера экрана.
4. Подстройка под конкретные устройства. Не надо затачивать верстку только под размеры экранов айфонов. Устройств много, у всех разные размеры, и адаптивный сайт должен хорошо отображаться везде. Точки переключения (breakpoints) должны стоять там, где этого требует контент.