#google

Смотрю трансляцию конференции AMP Conf 2018 из Амстердама.

1. Анонсировали новый формат stories (ссылка на timecode в трансляции). Vox и прочие уже сделали примеры, вот прямая ссылка на один Story от них. Для этих stories будет отдельная карусель в результатах поиска. Чтобы посмотреть карусель — откройте ссылку на телефоне или симуляторе, наберите в строке поиска vox или cnn — второй строкой будет карусель.
2. Рассказывают о хороших сайтах, которые AMP-first (а не обычная версия + AMP версия для трафика). Примеры: Tasty (базфид про еду) и новый сайт BMW.
3. Пушат свои крупные компоненты вроде date-picker, gallery, lightbox и sharing-buttons. Давят на то, что эти компоненты респонсив и хорошо оттестированы на сотнях кейсов. Tasty рассказывает, что с этими компонентами на самом деле гораздо проще жить.
4. Рассказывают про amp-optimizer (внутри AMP-toolbox), который круто оптимизирует AMP-сайты.

Fun fact: на презентации были видео админок Stories от Vox и Washington Post. Обе компании были в ситуации, когда нужно запрогать что-то прямо сейчас. У Vox в результате получилась отдельная супер-красивая админка (говорят, что разработка заняла 3 дня), а у WaPo — франкенштейн из Chrome extension, который перехерачивает обычный редактор статей на лету. Очень хочется быть как Vox.

Google Chrome начнет блокировать «плохую рекламу» меньше чем через две недели. И сделает это довольно интересным способом.

Что такое плохая реклама? По определению «коалиции за более лучшую рекламу» (sic: coalition for better ads), это: попапы, автоплей видео со звуком (без звука ок), большая реклама закрывающая контент, крупная реклама с обратным отсчетом (хорошо помню крестик «закрытия» размером два на два пикселя у полноэкранной рекламы на сайте РБК). Список чуть жестче для мобил и чуть мягче для десктопа.

Как будет работать блокировка? Инженеры довольно сообразительно соединили два старых механизма.

Первый: Гугл уже много лет поддерживает список сайтов, распространяющих вирусы (это называется Safe Browsing API). При попытке зайти на сайт из этого списка с помощью Chrome, вы увидите красный экран, предупреждающий об опасности (наверняка вы сталкивались с таким, хотя бы однажды). Теперь они добавят в этот список страницы, имеющие в себе плохую рекламу; красного экрана на таких страницах не будет, chrome только заблокирует рекламу.

Во вторых, 13 лет назад Рик Пентель составил список адресов «серверов рекламы» для самого известного блокировщика рекламы — Adblock. Правнуки этого списка — EasyList и EasyPrivacy используются почти во всех современных блокировщиках рекламы. Дело в том, что технически, реклама почти никогда не скачивается напрямую с сайта, на который вы заходите — поставкой рекламы занимаются специальные выделенные серверы. Схема работы блокировщиков простая: блокируешь запросы к серверам, поставляющим рекламу → реклама не может загрузиться → страница грузится без рекламы → профит. Гугл собирается использовать эти списки как есть, включая имеющиеся в списках адреса Google AdSense (вижу в этом некоторую самоиронию). То есть на сайтах с «плохой рекламой» будет блокироваться вообще вся реклама, а не только «плохая».

Проверить, есть ли страницы вашего сайта в списке, можно вот тут. Для проверки страницы сайтов конкурентов — используйте бесплатное API. Проверить чужой сайт целиком нельзя, в списке хранятся не сами адреса, а только их «уникальные отпечатки».

Спасибо Даниэлю Александерсену за отличный разбор со ссылками на исходники хрома.

Если вы видите у себя в источниках трафика домен googleapis.com — не удивляйтесь. Посмотрите на страницу перехода — скорее всего там будет /auth/chrome-content-suggestions.

Это переходы на ваш сайт с «article suggestions» на «новой вкладке» в мобильном Google Chrome.

Пруфы: 1→2.

Помните, у издателей бомбило от того, что из результатов поиска AMP-страницы открываются не с оригинального сайта, а с адресов (и серверов) Google.com?

Дело в том, что отдавать страницы с серверов Google быстрее по двум причинам: 1) ни у кого нет так много компьютеров на всех континентах, как у Google 2) можно сделать предзагрузку результатов поиска.

Второй пункт важен — гугл в фоне предзагружает AMP-страницы первых 2-3 результатов поиска, так что при клике они открываются мгновенно. Если бы страницы предзагружались с серверов издателей — те могли бы палить, кто нашел их сайт через Google, даже если читатель не кликнул на их сайт.

И вот, Google придумал решение. Это новый формат архива, в который можно сложить всё, что нужно для открытия страницы в офлайне (картинки, стили, скрипты, etc.). Что-то типа MHTML, только для 2018 (в этом формате, например, есть поддержка цифровых подписей). Называется эта штука Web Packaging Format. Если у вас аллергия на RFC (я их обожаю), то вот explainer на гитхабе.

Для нормального использования, это должно работать во всех крупных браузерах. Google контролирует Chrome, но есть ведь Safari. В этот раз Google пошел не путем уговоров Apple, но решил сам запилить поддержку WPF в Webkit (это open source основа Safari).

Понятно, что Google делает это для CDN. Тем не менее, потенциально это означает, что можно будет «перекинуть страницу на флешку» / «через ватсап» (или что там у нас тогда будет в моде) и сайт нормально откроется даже без интернета. Мечты...

Возможность делать хорошие packaged web apps может подточить ультимативную власть апстора. Очень интересно, что из этого получится.

Google обновил в ноябре Firebase Cloud Messaging — одну из самых крутых систем для рассылки пуш-уведомлений в мобильные приложения и браузеры (при этом — бесплатную!).

В новой версии API можно в едином сообщении указать два разных payload; клиент получит свою версию в зависимости от платформы — iOS или Android. Ура! Ложка дёгтя: авторизация теперь богопротивным Oauth2 JWT.

P.S. Документация у Firebase — тихий ужас :(
P.P.S. Никогда не собирайте тестовые приложения с продакшен-ключами. Я сегодня таким макаром отправил в продакшен iOS Медузы тестовый пуш. Слава богу, не в канал «breaking». Слава богу, что тексты тестовых пуши — копии недавних легитимных, а не «тестовый пуш, йоу» или «alert('fuck')». Храни вас бог при тестировании пушей и почтовых рассылок. Аминь.

Гугл наконец-то опубликовал нормальный разбор «что делать», а то PR-опусы как исследователей безопасности (мы всё умрём) так и Intel (ничего не происходит) надоели.

Коротко: гугл починил у себя все три уязвимости и не заметил проседания производительности в продакшене.

Детали: CVE-2017-5753 нужно фиксить отдельно в каждом бинарнике, способном выполнять недоверенный код (читай браузеры, ОС и прочий JIT) — они не пишут, как именно это нужно делать; CVE-2017-5715 чинится обновлением CPU или перекомпиляцией важных бинарников (ОС и гипервизоры) компилятором, умеющим хитрый хак (Google назвал этот хак Retpoline и опубликовал его для GCC и LLVM); CVE-2017-5754 чинится обновлением ОС. Обратите внимание, что гугл не называет эти баги именами собственными, видимо не хочет добавлять хайпа.

На сладкое: status page проектов гугла относительно этих уязвимостей. Мы в Медузе не используем виртуальные машины (только baremetal, только хардкор) и у нас почти нет untrusted code execution, так что в этой серии я участвую только как зритель.

Продолжение истории: чуваки уже смогли эксплуатировать CVE-2017-5753 в Firefox для кражи паролей из джаваскрипта. Mozilla выпустил обновление только что. В обновлении они уменьшают точность таймеров и API получения времени до 20µs (sic, 20 микросекунд), пока не починят корень проблемы. Напомню, что атака основана на замере скорости выполнения операций процессором, так что не имея точного времени произвести её будет нельзя.

Google Prompt — очень хорошая штука для 2-факторной авторизации в гугл, гораздо человечнее всех этих totp-based решений, рекомендую https://gsuiteupdates.googleblog.com/2017/10/making-google-prompt-primary-choice-for-2sv.html

А если у вас не включена 2-факторная авторизация — самое время её включить.

Гугл представил параноидальный режим безопасности для тех, кто боится взлома своих gmail и прочих гугл-аккаунтов.

Для включения нужно купить и привязать ключи безопасности U2F. Для компьютера — знаменитая флешка за 18$. Для телефона — необычная bluetooth/nfc версия за 25$, хотя, кажется, можно обойтись приложением Google Smart Lock.

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

Хотя это и не говорится явно, кажется, всё это — ответ гугла на русских государственных хакеров, которые планомерно проводят качественные таргетированные атаки на журналистов и политиков.

Реальное отличие таких аппаратных ключей от одноразовых кодов — в защите от фишинга. Одноразовые коды можно перехватить на этапе их ввода руками на фишинговую страницу (а люди плохо определяют фишинг, это медицинский факт). Криптографический обмен ключами между сайтом и USB-устройством перехватить можно, но бессмысленно. Шах и мат, Russian hackers.

Google представил новую модель хромбука — Pixelbook.

- качественная клавиатура
- вес 1.1 кг, толщина 10мм (меньше чем эйры и чуть больше макбука)
- 12.3" 235ppi (четче, чем ретина на всех макбуках)
- 10 часов без зарядки
- полноценные процессоры Intel Core i5/i7
- 1000 USD за 8GB RAM, 128GB SSD (эйр стоит столько же, макбук 1300)
- 1650 USD за 16GB RAM, 512GB SSD (эйров таких не бывает, макбук с 16GB начинается от 1500$)

Ну и главное — у Pixelbook есть карандаш (за 99$)! С обещанным sub-10ms latency, что должно транслироваться в ощущение физического карандаша на бумаге, без какой-либо задержки, прямо как в iPad Pro. Ах да, ещё он умеет складываться в планшет.

Учитывая фокус ChromeOS на безопасности — получается почти идеальный ноутбук за 1000$ для редакторов общественно-политического медиа. Всерьез подумываю закупить пару штук вместо MacBook Air, которые вот-вот выйдут из строя.

- страница в магазине Google Store;
- анонс в блоге Google;
- обзор Verge, где можно рассмотреть крупные фото.