Фонд свободного программного обеспечения (Free Software Foundation, FSF) под руководством Ричарда Столлмана — одна из немногих организаций, которая свято блюдёт принципы свободного ПО и внимательно следит за чистотой программного и аппаратного обеспечения.
На днях FSF одобрил к использованию второй ноутбук, который соответствует критериям программы Respect Your Freedom. К сожалению, это ещё одна устаревшая модель Libreboot X200 с процессором образца 2008 года.
В 2013 году FSF выбрал первый лаптоп, соответствующий требованиям свободы и открытости.
Главным критерием программы сертификации FSF являются на 100% свободное ПО, включая управляющие программы аппаратных устройств, в том числе BIOS и прошивка различных компонентов. Пользователи должны иметь возможность изменять и контролировать софт на всех уровнях, на которых это только возможно. Вместе с публикацией исходных кодов производитель обязан предоставить пользователю практическую возможность установки альтернативного программного обеспечения на всех уровнях.
Не только софт, но свободными на 100% и доступными для публики должны быть инструменты для компиляции этого софта, а также ПО для установки и обслуживания устройства. В устройстве не должно быть никаких аппаратных или программных бэкдоров и шпионских модулей в любом виде, которые способны предоставить кому-либо кроме владельца идентификатор устройства, его местоположение или сведения об активности пользователя, за исключением случаев, 1) когда пользователь явно попросит об этом, 2) когда этого требуют протоколы коммуникации либо 3) законодательство. В последнем случае владельца устройства следует проинформировать заметным сообщением и ссылкой на то, где получить дополнительную информацию.
Устройства, рекомендованные FSF, могут поддерживать закрытые форматы файлов, такие как MP3, но только при условии поддержки свободных альтернатив. Форматы с DRM могут поддерживаться только при условии обработки их в свободном ПО.
Всё вышеперечисленное — список критериев, который удалось реализовать в первом «истинно свободном» ноутбуке Gluglug X60. Это модифицированная версия ноутбука IBM ThinkPad X60 (2006 года выпуска), но со свободным BIOS Coreboot, свободной ОС Trisquel GNU/Linux (на базе Ubuntu), драйверами и приложениями. В нём интегрирована сетевая карта 802.11n (Atheros Atheros AR5B195), полностью совместимая со стандартами свободного ПО. Компания-производитель предоставляет документацию и исходный код для каждого модуля.
Очевидно, что ноутбук с процессором Intel Core Duo, Intel Core Solo или Intel Core 2 Duo никак не назовёшь современным. Однако, приверженцам аскетичного стиля FSF ничего не остаётся. Это единственный вариант, который рекомендовали гуру.
Новое предложение Libreboot X200 ненамного лучше предыдущего: процессор Intel Core 2 Duo P8400, графика GMA 4500MHD, дисплей 1280×800, сетевая карта 802.11n Atheros WiFi.
Вчера газета WSJ сообщила неожиданную новость: Microsoft инвестирует $70 млн в «хакерский» стартап Cyanogen, который делает моды операционной системы Android.
У компании Cyanogen немного «озорная» репутация, ведь эта фирма осмелилась бросить вызов не кому-нибудь, а самой Google! На недавней встрече с разработчиками исполнительный директор компании Cyanogen Кирт Макмастер смело заявил: «Мы пытаемся увести Android из-под влияния Google».
В Cyanogen работают над полностью открытой версией Android, которая позволит разработчикам других программ и сервисов интегрировать свои продукты также тесно, как сегодня интегрированы сервисы Google: Gmail, Календарь, Google Now и др. По планам Макмастера, через полтора года должен быть открыт собственный магазин приложений для Android.
Как видим, Microsoft не против присоединиться к этому движению. С вкладом $70 млн она станет миноритарным инвестором, поскольку рыночная оценка Cyanogen составляет примерно $500-900 млн, считают аналитики финансового издания.
В контексте новых манёвров Microsoft следует помнить, что эта корпорация обладает самым большим портфелем патентов на ОС Android и получает огромные лицензионные отчисления от производителей Android-устройств (около $2 млрд в год). Этот доход многократно превышает прибыль от продажи мобильных устройств под Windows. Смартфоны Windows Phone занимают всего 3% рынка.
Учитывая глубокую интегрированность Microsoft в инфраструктуру Android, редмондской корпорации выгодно уменьшить контроль Google над этой инфраструктурой.
В то же время Google проводит противоположную политику и старается перевести большую часть кода Android в закрытые проприетарные модули, за использование которых она выжимает деньги у производителей Android-устройств.
Пару дней назад выпущен концептуальный эксплоит для ADSL-модема и маршрутизатора D-Link DSL-2740R. Уязвимость позволяет в удалённом режиме изменить настройки DNS и пропускать трафик через свой сервер.
Эксплоит использует уязвимость в операционной системе ZynOS, которую разработала компания ZyXEL Communications для сетевых устройств.
Взлом не требует получения учётных данных администратора, нужен только доступ к веб-панели маршрутизатора.
Таким образом, если маршрутизатор сконфигурирован для удалённого управления и «светит» в интернет веб-панелью, то риск взлома очень высок. Но даже если веб-панель открывается из локальной сети, всё равно злоумышленник может получить доступ к ней с помощью CSRF-атаки.
По информации с сайта D-Link, производство устройства DSL-2740R завершено, хотя всё равно возможен выпуск патча и исправленной прошивки.
Автор эксплоита — болгарский хакер Тодор Донев (Todor Donev), участник исследовательской группы Ethical Hacker, пишет ComputerWorld. Хакер заявил, что D-Link DSL-2740R — далеко не единственная уязвимая модель. Настройки DNS можно изменить и в других сетевых устройствах, которые работают под ZynOS: это изделия D-Link, TP-Link, ZTE и других компаний.
Меня всегда напрягало то, как навязчиво Google AdSense подсовывал контекстную рекламу в зависимости от моих старых запросов в поисковике. Вроде бы и времени с момента поиска прошло достаточно много, да и куки и кеш браузера чистились не раз, а реклама оставалась. Как же они продолжали отслеживать меня? Оказывается, способов для этого предостаточно.
Небольшое предисловие
Идентификация, отслеживание пользователя или попросту веб-трекинг подразумевает под собой расчет и установку уникального идентификатора для каждого браузера, посещающего определенный сайт. Вообще, изначально это не задумывалось каким-то вселенским злом и, как и все, имеет обратную сторону, то есть призвано приносить пользу. Например, позволить владельцам сайта отличить обычных пользователей от ботов или же предоставить возможность хранить предпочтения пользователей и применять их при последующем визите. Но в то же самое время данная возможность очень пришлась по душе рекламной индустрии. Как ты прекрасно знаешь, куки — один из самых популярных способов идентификации пользователей. И активно применяться в рекламной индустрии они начали аж с середины девяностых годов.
С тех пор многое изменилось, технологии ушли далеко вперед, и в настоящее время отслеживание пользователей одними только печеньками не ограничивается. На самом деле идентифицировать юзеров можно разными способами. Самый очевидный вариант — установить какие-либо идентификаторы, наподобие куков. Следующий вариант — воспользоваться данными об используемым юзером ПК, которые можно почерпнуть из HTTP-заголовков отправляемых запросов: адрес, тип используемой ОС, время и тому подобное. Ну и напоследок можно отличить пользователя по его поведению и привычкам (движения курсора, любимые разделы сайта и прочее).
Явные идентификаторы
Данный подход довольно очевиден, все, что требуется, — сохранить на стороне пользователя какой-то долгоживущий идентификатор, который можно запрашивать при последующем посещении ресурса. Современные браузеры предоставляют достаточно способов выполнить это прозрачно для пользователя. Прежде всего это старые добрые куки. Затем особенности некоторых плагинов, близкие по функционалу к кукам, например Local Shared Objects во флеше или Isolated Storage в силверлайте. HTML5 также включает в себя несколько механизмов хранения на стороне клиента, в том числе localStorage, File и IndexedDB API. Кроме этих мест, уникальные маркеры можно также хранить в кешированных ресурсах локальной машины или метаданных кеша (Last-Modified, ETag). Помимо этого, можно идентифицировать пользователя по отпечаткам, полученным из Origin Bound сертификатов, сгенерированных браузером для SSL-соединений, по данным, содержащимся в SDCH-словарях, и метаданным этих словарей. Одним словом — возможностей полно.
Cookies
Когда дело касается хранения какого-то небольшого объема данных на стороне клиента, куки — это первое, что обычно приходит на ум. Веб-сервер устанавливает уникальный идентификатор для нового пользователя, сохраняя его в куках, и при всех последующих запросах клиент будет отправлять его серверу. И хотя все популярные браузеры уже давно снабжены удобным интерфейсом по управлению куками, а в Сети полно сторонних утилит для управления ими и их блокировки, куки все равно продолжают активно использоваться для трекинга пользователей. Дело в том, что мало кто просматривает и чистит их (вспомни, когда ты занимался этим последний раз). Пожалуй, основная причина этого — все боятся случайно удалить нужную «печеньку», которая, например, может использоваться для авторизации. И хотя некоторые браузеры позволяют ограничивать установку сторонних куков, проблема не исчезает, так как очень часто браузеры считают «родными» куки, полученные через HTTP-редиректы или другие способы во время загрузки контента страницы. В отличие от большинства механизмов, о которых мы поговорим далее, использование куков прозрачно для конечного пользователя. Для того чтобы «пометить» юзера, необязательно даже хранить уникальный идентификатор в отдельной куке — он может собираться из значений нескольких куков или храниться в метаданных, таких как Expiration Time. Поэтому на данном этапе довольно непросто разобраться, используется ли конкретная кука для трекинга или нет.
Local Shared Objects
Для хранения данных на стороне клиента в Adobe Flash используется механизм LSO. Он является аналогом cookies в HTTP, но в отличие от последних может хранить не только короткие фрагменты текстовых данных, что, в свою очередь, усложняет анализ и проверку таких объектов. До версии 10.3 поведение флеш-куков настраивалось отдельно от настроек браузера: нужно было посетить менеджер настроек Flash, расположенный на сайте macromedia.com (кстати, он доступен и сейчас по следующей ссылке). Сегодня это можно выполнить непосредственно из контрольной панели. К тому же большинство современных браузеров обеспечивают достаточно плотную интеграцию с флеш-плеером: так, при удалении куков и других данных сайтов будут также удалены и LSO. С другой стороны, взаимодействие браузеров с плеером еще не настолько тесное, поэтому настройка в браузере политики для сторонних куков не всегда затронет флеш-куки (на сайте Adobe можно посмотреть, как вручную их отключить).
Настройка локального хранилища для Flash Player
Изолированное хранилище Silverlight
Программная платформа Silverlight имеет довольно много общего с Adobe Flash. Так, аналогом флешевого Local Shared Objects служит механизм под названием Isolated Storage. Правда, в отличие от флеша настройки приватности тут никак не завязаны с браузером, поэтому даже в случае полной очистки куков и кеша браузера данные, сохраненные в Isolated Storage, все равно останутся. Но еще интересней, что хранилище оказывается общим для всех окон браузера (кроме открытых в режиме «Инкогнито») и всех профилей, установленных на одной машине. Как и в LSO, с технической точки зрения здесь нет каких-либо препятствий для хранения идентификаторов сессии. Тем не менее, учитывая, что достучаться до этого механизма через настройки браузера пока нельзя, он не получил такого широкого распространения в качестве хранилища для уникальных идентификаторов.
Где искать изолированное хранилище Silverlight
HTML5 и хранение данных на клиенте
HTML5 представляет набор механизмов для хранения структурированных данных на клиенте. К ним относятся localStorage, File API и IndexedDB. Несмотря на различия, все они предназначены для обеспечения постоянного хранения произвольных порций бинарных данных, привязанных к конкретному ресурсу. Плюс, в отличие от HTTP- и Flash-куков, здесь нет каких-либо значительных ограничений на размер хранимых данных. В современных браузерах HTML5-хранилище располагается наряду с другими данными сайта. Однако как управлять хранилищем через настройки браузера — догадаться очень трудно. К примеру, чтобы удалить данные из localStorage в Firefox, пользователю придется выбрать offline website data или site preferences и задать временной промежуток равным everything. Еще одна неординарная фишка, присущая только IE, — данные существуют только на время жизни табов, открытых в момент их сохранения. Плюс ко всему вышеперечисленные механизмы не особо-то стараются следовать ограничениям, применимым к HTTP-кукам. Например, можно писать в localStorage и читать из него через кросс-доменные фреймы даже при отключенных сторонних куках.
Удаление данных из localStorage в Firefox
Кешированные объекты
Все хотят, чтобы браузер работал шустро и без тормозов. Поэтому ему приходится складывать в локальный кеш ресурсы посещаемых сайтов (чтобы не запрашивать их при последующем визите). И хотя данный механизм явно не предназначался для использования в качестве хранилища с произвольным доступом, его можно в таковой превратить. Например, сервер может вернуть пользователю JavaScript-документ с уникальным идентификатором внутри его тела и установить в заголовках Expires / max-age= далекое будущее. Таким образом скрипт, а с ним и уникальный идентификатор пропишется в кеше браузера. После чего к нему можно будет обратиться с любой страницы в Сети, просто запросив загрузку скрипта с известного URL’а. Конечно, браузер будет периодически спрашивать с помощью заголовка If-Modified-Since, не появилась ли новая версия скрипта. Но если сервер будет возвращать код 304 (Not modified), то закешированная копия будет использоваться вечно. Чем еще интересен кеш? Здесь нет концепции «сторонних» объектов, как, например, в случае с HTTP-куками. В то же время отключение кеширования может серьезно отразиться на производительности. А автоматическое определение хитрых ресурсов, хранящих в себе какие-то идентификаторы/метки, затруднено в связи с большим объемом и сложностью JavaScript-документов, встречающихся в Сети. Конечно, все браузеры позволяют юзеру вручную чистить кеш. Но как показывает практика (даже собственный пример), производится это не так часто, если производится вообще.
ETag и Last-Modified
Для того чтобы кеширование работало правильно, серверу необходимо каким-то образом информировать браузер о том, что доступна более новая версия документа. Стандарт HTTP/1.1 предлагает два способа для решения этой задачи. Первый основан на дате последнего изменения документа, а второй — на абстрактном идентификаторе, известном как ETag. В случае с ETag сервер изначально возвращает так называемый version tag в заголовке ответа вместе с самим документом. При последующих запросах к заданному URL клиент сообщает серверу через заголовок If-None-Match это значение, ассоциированное с его локальной копией. Если версия, указанная в этом заголовке, актуальная, то сервер отвечает HTTP-кодом 304 (Not Modified), и клиент может спокойно использовать кешированную версию. В противном случае сервер присылает новую версию документа с новым ETag. Такой подход чем-то напоминает HTTP-куки — сервер сохраняет произвольное значение на клиенте только для того, чтобы потом его считать. Другой способ, связанный с использованием заголовка Last-Modified, позволяет хранить по крайней мере 32 бита данных в строке даты, которая затем отправляется клиентом серверу в заголовке If-Modified-Since. Что интересно, большинство браузеров даже не требуют, чтобы эта строка представляла собой дату в правильном формате. Как и в случае идентификации пользователя через кешированные объекты, на ETag и Last-Modified никак не влияет удаление куков и данных сайта, избавиться от них можно только очисткой кеша.
Сервер возвращает клиенту ETag
HTML5 AppCache
Application Cache позволяет задавать, какая часть сайта должна быть сохранена на диске и быть доступна, даже если пользователь находится офлайн. Управляется все с помощью манифестов, которые задают правила для хранения и извлечения элементов кеша. Подобно традиционному механизму кеширования, AppCache тоже позволяет хранить уникальные, зависящие от пользователя данные — как внутри самого манифеста, так и внутри ресурсов, которые сохраняются на неопределенный срок (в отличие от обычного кеша, ресурсы из которого удаляются по истечении какого-то времени). AppCache занимает промежуточное значение между механизмами хранения данных в HTML5 и обычным кешем браузера. В некоторых браузерах он очищается при удалении куков и данных сайта, в других только при удалении истории просмотра и всех кешированных документов.
SDCH-словари
SDCH — это разработанный Google алгоритм компрессии, который основывается на использовании предоставляемых сервером словарей и позволяет достичь более высокого уровня сжатия, чем Gzip или deflate. Дело в том, что в обычной жизни веб-сервер отдает слишком много повторяющейся информации — хидеры/футеры страниц, встроенный JavaScript/CSS и так далее. В данном подходе клиент получает с сервера файл словаря, содержащий строки, которые могут появиться в последующих ответах (те же хидеры/футеры/JS/CSS). После чего сервер может просто ссылаться на эти элементы внутри словаря, а клиент будет самостоятельно на их основе собирать страницу. Как ты понимаешь, эти словари можно с легкостью использовать и для хранения уникальных идентификаторов, которые можно поместить как в ID словарей, возвращаемые клиентом серверу в заголовке Avail-Dictionary, так и непосредственно в сам контент. И потом использовать подобно как и в случае с обычным кешем браузера.
Прочие механизмы хранения
Но это еще не все варианты. При помощи JavaScript и его товарищей по цеху можно сохранять и запрашивать уникальный идентификатор таким образом, что он останется в живых даже после удаления всей истории просмотров и данных сайтов. Как один из вариантов, можно использовать для хранения window.name или sessionStorage. Даже если пользователь подчистит все куки и данные сайта, но не закроет вкладку, в которой был открыт отслеживающий сайт, то при последующем заходе идентифицирующий токен будет получен сервером и пользователь будет снова привязан к уже собранным о нем данным. Такое же поведение наблюдается и у JS, любой открытый JavaScript-контекст сохраняет состояние, даже если пользователь удалит данные сайта. При этом такой JavaScript может не только принадлежать отображаемому сайту, но и прятаться в iframe’ах, веб-воркерах и так далее. Например, загруженная в iframe реклама вовсе не обратит внимания на удаление истории просмотров и данных сайта и продолжит использовать идентификатор, сохраненный в локальной переменной в JS.
Протоколы
Помимо механизмов, связанных с кешированием, использованием JS и разных плагинов, в современных браузерах есть еще несколько сетевых фич, позволяющих хранить и извлекать уникальные идентификаторы.
Origin Bound Certificates (aka ChannelID) — персистентные самоподписанные сертификаты, идентифицирующие клиента HTTPS-серверу. Для каждого нового домена создается отдельный сертификат, который используется для соединений, инициируемых в дальнейшем. Сайты могут использовать OBC для трекинга пользователей, не предпринимая при этом каких-либо действий, которые будут заметны клиенту. В качестве уникального идентификатора можно взять криптографический хеш сертификата, предоставляемый клиентом как часть легитимного SSL-рукопожатия.
Подобным образом и в TLS тоже есть два механизма — session identifiers и session tickets, которые позволяют клиентам возобновлять прерванные HTTPS-соединения без выполнения полного рукопожатия. Достигается это за счет использования закешированных данных. Два этих механизма в течение небольшого промежутка времени позволяют серверам идентифицировать запросы, исходящие от одного клиента.
Практически все современные браузеры реализуют свой собственный внутренний DNS-кеш, чтобы ускорить процесс разрешения имен (и в некоторых случаях снизить риск DNS rebinding атак). Такой кеш запросто можно использовать для хранения небольших объемов информации. Например, если обладать 16 доступными IP-адресами, около 8–9 закешированных имен будет достаточно, чтобы идентифицировать каждый компьютер в Сети. Однако такой подход ограничен размером внутреннего DNS-кеша браузеров и может потенциально привести к конфликтам в разрешении имен с DNS провайдера.
Характеристики машины
Все рассмотренные до этого способы основывались на том, что пользователю устанавливался какой-то уникальный идентификатор, который отправлялся серверу при последующих запросах. Есть другой, менее очевидный подход к отслеживанию пользователей, полагающийся на запрос или измерение характеристик клиентской машины. Поодиночке каждая полученная характеристика представляет собой лишь несколько бит информации, но если объединить несколько, то они смогут уникально идентифицировать любой компьютер в интернете. Помимо того что такую слежку гораздо сложнее распознать и предотвратить, эта техника позволит идентифицировать пользователя, сидящего под разными браузерами или использующего приватный режим.
«Отпечатки» браузера
Наиболее простой подход к трекингу — это построение идентификаторов путем объединения набора параметров, доступных в среде браузера, каждый из которых по отдельности не представляет никакого интереса, но совместно они образуют уникальное для каждой машины значение:
User-Agent. Выдает версию браузера, версию ОС и некоторые из установленных аддонов. В случаях, когда User-Agent отсутствует или хочется проверить его «правдивость», можно определить версию браузера проверкой на наличие определенных фич, реализованных или измененных между релизами.
Ход часов. Если система не синхронизирует свои часы со сторонним сервером времени, то рано или поздно они начнут отставать или спешить, что породит уникальную разницу между реальным и системным временем, которую можно измерить с точностью до микросекунды с помощью JavaScript’а. На самом деле даже при синхронизации с NTP-сервером все равно будут небольшие отклонения, которые также можно будет измерить.
Информация о CPU и GPU. Можно получить как напрямую (через GL_RENDERER), так и через бенчмарки и тесты, реализованные с помощью JavaScript.
Разрешение монитора и размер окна браузера (включая параметры второго монитора в случае мультимониторной системы).
Список установленных в системе шрифтов, полученных, например, с помощью getComputedStyle API.
Список всех установленных плагинов, ActiveX-контролов, Browser Helper Object’ов, включая их версии. Можно получить перебором navigator.plugins[] (некоторые плагины выдают свое присутствие в HTTP-заголовках).
Информация об установленных расширениях и другом ПО. Такие расширения, как блокировщики рекламы, вносят определенные изменения в просматриваемые страницы, по которым можно определить, что это за расширение, и его настройки.
Сетевые «отпечатки»
Еще ряд признаков кроется в архитектуре локальной сети и настройке сетевых протоколов. Такие знаки будут характерны для всех браузеров, установленных на клиентской машине, и их нельзя просто скрыть с помощью настроек приватности или каких-то security-утилит. Они включают в себя:
Внешний IP-адрес. Для IPv6-адресов данный вектор особенно интересен, так как последние октеты в некоторых случаях могут получаться из MAC-адреса устройства и потому сохраняться даже при подключении к разным сетям.
Номера портов для исходящих TCP/IP-соединений (обычно выбираются последовательно для большинства ОС).
Локальный IP-адрес для пользователей, находящихся за NAT’ом или HTTP-прокси. Вкупе с внешним айпишником позволяет уникально идентифицировать большинство клиентов.
Информация об используемых клиентом прокси-серверах, полученная из HTTP-заголовка (X-Forwarded-For). В сочетании с реальным адресом клиента, полученным через несколько возможных способов обхода прокси, также позволяет идентифицировать пользователя.
Поведенческий анализ и привычки
Еще один вариант — взглянуть в сторону характеристик, которые привязаны не к ПК, а скорее к конечному пользователю, такие как региональные настройки и поведение. Такой способ опять же позволит идентифицировать клиентов между различными сессиями браузера, профилями и в случае приватного просмотра. Делать выводы можно на основании следующих данных, которые всегда доступны для изучения:
Предпочитаемый язык, дефолтная кодировка и часовой пояс (все это живет в HTTP-заголовках и доступно из JavaScript).
Данные в кеше клиента и его история просмотра. Элементы кеша можно обнаружить при помощи атак по времени — отслеживающий может обнаружить долгоживущие элементы кеша, относящиеся к популярным ресурсам, просто измерив время из загрузки (и отменив переход, если время превышает ожидаемое время загрузки из локального кеша). Также можно извлекать URL’ы, хранящиеся в истории просмотра браузера, хотя такая атака в современных браузерах потребует небольшого взаимодействия с пользователем.
Жесты мышью, частота и продолжительность нажатия клавиш, данные с акселерометра — все эти параметры уникальны для каждого пользователя.
Любые изменения стандартных шрифтов сайта и их размеров, уровень zoom’а, использование специальных возможностей, таких как цвет текста, размер.
Состояние определенных фич браузера, настраиваемых клиентом: блокировка сторонних куков, DNS prefetching, блокировка всплывающих окон, настройки безопасности Flash и так далее (по иронии, пользователи, меняющие дефолтные настройки, в действительности делают свой браузер значительно более легким для идентификации).
И это лишь очевидные варианты, которые лежат на поверхности. Если копнуть глубже — можно придумать еще.
Подытожим
Как видишь, на практике существует большое число различных способов для трекинга пользователя. Какие-то из них являются плодом ошибок в реализации или упущений и теоретически могут быть исправлены. Другие практически невозможно искоренить без полного изменения принципов работы компьютерных сетей, веб-приложений, браузеров. Каким-то техникам можно противодействовать — чистить кеш, куки и прочие места, где могут храниться уникальные идентификаторы. Другие работают абсолютно незаметно для пользователя, и защититься от них вряд ли получится. Поэтому самое главное — путешествуя по Сети даже в приватном режиме просмотра, помнить, что твои перемещения все равно могут отследить.
9 сентября компания Apple анонсировала смартфоны iPhone 6 и iPhone 6 Plus, одной из особенностей которых стал чип NFC и основанная на нем технология Apple Pay. В презентации основной упор был сделан на возможность бесконтактной оплаты покупок с помощью смартфона, однако на самом деле возможности NFC на этом не заканчиваются и уже давно и успешно используются в Android-смартфонах для выполнения множества разных задач, начиная от оплаты поездки в метро и заканчивая автоматизацией смартфона.
Вместо введения
NFC расшифровывается как Near Field Communication или «ближняя бесконтактная связь», если по-русски. По своей сути это небольшой чип, который может быть встроен в смартфон с целью передачи данных на очень короткие расстояния с весьма мизерной скоростью. NFC очень близка к технологии RFID, которая уже давным-давно используется для пометки продуктов в супермаркетах, но базируется на ее более позднем стандарте ISO/IEC 14443 (смарт-карты) и спроектирована для использования в переносной электронике (читай: смартфонах) и выполнения безопасных транзакций (читай: оплаты покупок).
Как и в случае со стандартом ISO/IEC 14443, дальность действия NFC всего 5–10 см, но разница в том, что чип NFC способен выполнять функцию тега и считывателя одновременно. Другими словами, оснащенный NFC смартфон может быть как смарт-картой (картой метро, например), которую достаточно поднести к считывателю, чтобы расплатиться, так и самим считывателем, что можно использовать, например, для перевода средств между картами-смартфонами и превращения реальных карт с поддержкой стандарта ISO/IEC 14443 в виртуальные.
Но это только «одно из» и наиболее очевидное применение NFC. Благодаря тому, что чип NFC способен передавать данные в обе стороны и не требует аутентификации устройств, его можно использовать как простую и более удобную замену Bluetooth. С помощью NFC, например, можно делиться ссылками, паролями, контактными и другими данными между смартфонами, просто поднеся их друг к другу.
Появившаяся в Android 4.0 технология Beam еще больше расширяет границы применения NFC, позволяя быстро переносить между устройствами целые файлы и папки, что достигается с помощью предварительной аутентификации Bluetooth-устройств по NFC и последующей установки Bluetooth-соединения и отправки файлов. Как и в предыдущем случае, все, что требуется для передачи, — просто поднести телефоны друг к другу. В прошивках Samsung эта функция носит имя S-Beam и позволяет использовать в качестве «транспортного канала» не только синезуб, но и Wi-Fi (один из смартфонов превращается в точку доступа).
Еще одна возможность — использование пассивных NFC-тегов. Такие теги в виде небольших наклеек можно приобрести за полдоллара за штуку и перепрограммировать с помощью смартфона. Каждый из них может вмещать в себя 137 байт информации (в случае самого распространенного и дешевого тега Mifire Ultralight C), для считывания которой опять же достаточно просто поднести смартфон. В тег можно записать пароль от домашнего Wi-Fi и приклеить на роутер. Или кодовое слово, на которое будет реагировать смартфон. Можно организовать автоматический запуск навигатора при установке смартфона в держатель в автомобиле или включение бесшумного и энергосберегающего режимов, когда телефон находится на прикроватной тумбочке. Небольшой список покупок в 137 байт тоже вполне вместится.
В этой статье мы поговорим обо всех возможных применениях NFC на практике, но так как в нашей стране оплата покупок с его помощью внедрена примерно нигде, то речь пойдет преимущественно об автоматизации на основе меток.
Поддержка в смартфонах
Первым телефоном с интегрированной поддержкой NFC был Nokia 6131, выпущенный еще в 2006 году. Тогда встроенный NFC-чип был всего лишь игрушкой для демонстрации возможностей созданной два года назад технологии. Смартфон был оснащен софтом для считывания NFC-меток, но ввиду их тогдашней дороговизны и почти нулевой популярности технологии ни на какое серьезное применение данная особенность смартфона не претендовала.
После некоторого затишья популяризацией NFC занялась компания Google, выпустившая в 2010 году смартфон Samsung Nexus S и приложение Google Wallet, которое позволяло расплачиваться виртуальными кредитками, используя NFC. На следующий год Google стала ведущим участником NFC Forum и представила Android 4.0 и основанный на нем смартфон Samsung Galaxy Nexus, который теперь мог похвастаться наличием той самой функции Beam. Позже появился Nexus 4, и наконец начали подтягиваться другие производители.
Сегодня NFC оснащаются почти все выпускаемые смартфоны. Соответствующий модуль есть даже в сверхбюджетных чипах Mediatek, так что большая часть новых китайских смартфонов стоимостью 5000 рублей тоже им оснащены. В любом случае присутствие чипа NFC легко проверить по наличию пункта «Беспроводные сети -> NFC» в настройках.
Играем с тегами
Где взять теги? Как я уже сказал, самый простой вариант — это просто заказать их в Китае (dx.com, tinydeal.com, aliexpress.com). Самые дешевые теги в лице Mifire Ultralight C со 137 байтами памяти обойдутся примерно в пять долларов за десять штук. Также можно обзавестись фирменными тегами от Sony (SmartTags), однако кроме внешнего вида и цены, которая будет в три-пять раз выше, они ничем не отличаются. Еще один вариант: теги TecTile от Samsung с еще более высоким ценником, но и большим объемом памяти (716 байт). Но тут нужно быть осторожным, первая версия тегов совместима только с NFC-контроллером от NXP, так что с большинством смартфонов они работать не будут.
В качестве тега вполне можно использовать жетоны и карты метро для многократных поездок. Зачастую часть памяти в них остается свободной для записи, так что туда можно поместить любую инфу. Но даже если это не так, тег все равно можно использовать в качестве триггера действий, просто настроив реакцию смартфона на уникальный ID тега.
Без дополнительного софта в мобильных ОС есть лишь ограниченная поддержка «общения» с тегами. Тот же Android вообще не предлагает никаких средств для работы с ними. Все, что можно сделать, — это просто поднести тег к смартфону, чтобы последний его прочитал. В зависимости от типа записанных в тег данных смартфон может вывести эти данные на экран (тип «текст» или не поддерживаемый), открыть веб-страницу (тип URI), запустить приложение (специальный тип android.com:pkg, поддерживаемый только в Android), открыть номеронабиратель с указанным номером (тип URI “tel://”) и выполнить некоторые другие действия.
Средств для изменения самих тегов или поведения смартфона в ответ на их обнаружение в Android нет, поэтому нам придется обзавестись дополнительным софтом. Три приложения, которые мы будем использовать:
NFC TagInfo — читалка тегов, позволяющая получить наиболее полную информацию о теге и записанных в него данных;
Trigger — позволяет самостоятельно определить реакцию на тег с возможностью передачи управления в Tasker.
NFC TagInfo
Для начала разберемся, что за теги нам достались. Китайцы обычно никаких подробностей на этот счет не сообщают, а уж о картах метро я вообще молчу. Запускаем NFC TagInfo и подносим смартфон к тегу. Далее тапаем по пункту Tag Information и смотрим (скриншот «Читаем NFC-тег»), что мы имеем:
UID — уникальный идентификатор тега;
RF Technology — стандарт, поддерживаемый тегом. В данном случае это ISO/IEC 14443 Type A, то есть обычный RFID-тег c поддержкой первой версии протокола обмена данными (Type A);
Tag Type — тип (или, лучше сказать, «модель») тега. В данном случае NTAG203 — это Mifare Ultralight C, самый дешевый на данный момент тег. Буква C означает поддержку криптозащиты данных. Еще бывает Topaz 512, который вмещает 450 байт информации, и Mifare Classic 1K (716 байт), используемый в тегах TecTile и нередко в картах метро;
Manufacturer — производитель тега. NXP Semiconductors — 90% всех NFC-тегов делают они (семейство Mifare).
Читаем NFC-тег
Теперь возвращаемся обратно и переходим в меню NDEF information. NDEF — это один из стандартов NFC, который описывает формат хранения информации в памяти тегов и ее передачи считывателю. Тег может содержать несколько NDEF-сообщений, каждое со своим идентификатором и типом, по которому смартфон может определить, как интерпретировать содержащиеся в нем данные. Тип задается в формате URI, MIME или домен:сервис, если речь идет о каком-то специфичном для считывателя типе (например, тот самый android.com:pkg).
В меню NDEF information нас в первую очередь интересуют строки Maximum message size (полезный объем тега), Is tag writable (поддержка записи) и Can tag be write-protected (поддержка защиты от записи). Последняя опция позволяет заблокировать запись тега для всех устройств, кроме нашего. Кроме того, тег можно заблокировать навечно, так, чтобы его больше никогда нельзя было записать. В этом случае в предпоследней опции будет указано no.
Что внутри тега?
С технической точки зрения NFC-тег — это микрокомпьютер наподобие тех, что находятся внутри SIM и банковских карт. Здесь есть свой процессор, оперативная и постоянная память, но нет традиционного источника питания. Электрический ток он получает посредством электромагнитной индукции, которая возникает между антеннами считывателя и метки, так же как это происходит в беспроводных зарядных устройствах и пассивных радиоприемниках. Благодаря сверхмалому уровню потребления энергии, мощности такого «трансформатора» оказывается вполне достаточно для нормального функционирования микрокомпьютера.
Антенна занимает около 99% площади метки и передает данные на частоте 13,56 МГц со скоростью 106, 212, или 424 Кбит/с. Стандарты NFC определяют несколько протоколов передачи данных, в том числе несколько реализаций протокола обмена данными (они обозначаются буквами A, B и так далее), которые могут быть дополнены производителем самой метки. Например, метки семейства Mifare реализуют ряд расширений над стандартным протоколом, из-за чего можно поймать несовместимости между приложениями и меткой (но это редкость).
Безопасность данных обеспечивается несколькими путями:
Малая дальность действия. Десять сантиметров — очень приватная зона.
Защита от клонирования с помощью уникального серийного номера.
Возможность защиты от перезаписи и защиты данных паролем.
Опциональное шифрование данных в памяти и при передаче.
Ведущий производитель NFC-тегов — компания NXP Semiconductors. Они производят теги семейства Mifare, которые стали настолько популярны, что совместимость с ними обеспечивают не только другие производители тегов, но и производители NFC-чипов для смартфонов (на уровне эмуляции тегов). Семейство включает в себя несколько разных моделей, начиная от простейших Mifare Ultralight C и заканчивая Mifare DESFire EV1, имеющих встроенную файловую систему с поддержкой криптографии и гибко настраиваемыми правами доступа.
Переходим в меню NDEF message. Если тег содержит какие-либо данные, все они будут отображены здесь с разбиением на сообщения. Остальные опции NFC TagInfo позволяют просмотреть информацию о памяти тега: фактический объем, дамп в форматах HEX и ASCII, права доступа к страницам памяти и так далее. Рекомендую вернуться к этим опциям после записи в тег данных.
Пишем данные
Для записи данных будем использовать NFC TagWriter. Пользоваться приложением довольно просто. Запускаем, тапаем по пункту Create, write and store, выбираем New, далее выбираем тип записываемых данных. Наиболее полезные типы: контакт, простой текст, телефонный номер, данные для Bluetooth-соединения, URI и приложение. В списке есть даже закладка веб-браузера и email-сообщение, но для чего они нужны, не совсем понятно.
Главный экран NFC TagWriter
Далее заполняем необходимые поля (например, адрес веб-сайта в случае с URI), нажимаем Next и попадаем на экран опций (скриншот «NFC TagWriter: опции сообщения»). Здесь можно указать приложение, которое будет запущено после прочтения метки (Add launch application) и установить защиту на перезапись сторонним устройством (Apply Soft Protection). Также приложение позаботится о том, чтобы проинформировать нас о моделях тегов, способных вместить эти данные (в данном случае все ОK, NTAG203 в списке есть).
NFC TagWriter: опции сообщения
Вновь нажимаем Next и подносим смартфон к тегу. Вуаля, наши данные в нем. Теперь их можно прочитать любым смартфоном с поддержкой NFC. Но что это в конечном итоге дает?
Сценарии использования
На самом деле сценариев использования тегов масса. Я, например, применяю теги для хранения паролей и домашней автоматизации, кто-то для автоматической разблокировки смартфона и автоматического запуска навигатора в автомобиле. Теги можно клеить на стол, на ноутбук, на брелок, внутрь книги, на визитку или вшивать под одежду. Поэтому диапазон их применения огромен, и в конечном счете все упирается только в твою фантазию.
Домашняя автоматизация
Наиболее простой и очевидный способ использования тегов — это просто расклеить их по дому с целью получить своего рода систему автоматизации. Здесь существует множество различных вариантов. Приведу наиболее интересные и полезные.
Пароль от домашнего Wi-Fi. Клеим тег на роутер и записываем в него пароль с помощью приложения InstaWifi. Пригодится не только тем, кто часто принимает гостей, но и любителям экспериментов с прошивками.
Запуск автосинхронизации или приложения для обмена данными с ПК. Тег можно приклеить на ноутбук или системник и прописать в него запуск приложения для синхронизации данных (AirDroid, WiFi ADB и другие).
Включение точки доступа. Опять же клеим тег на ноутбук, далее устанавливаем приложение Trigger. В нем добавляем новое задание, в качестве триггера выбираем NFC, пропускаем выбор ограничений, в качестве действия выбираем «Беспроводные и локальные сети -> Wifi-зона», пропускаем следующий экран (добавление переключателя) и на последнем экране подносим к NFC-тегу.
Включение режима полета на ночь. Клеим метку куда-нибудь ближе к кровати. Запускаем Trigger, новое задание -> триггер: NFC -> действие: «Экспериментальные -> Режим в самолете». Как вариант, вместо включения режима самолета можно настроить отключение передачи данных и Wi-Fi, добавив соответствующие действия в задание.
Автомобильная автоматизация
NFC-теги будут очень полезны тем, кто использует смартфон в качестве автомобильного навигатора. Достаточно наклеить тег на держатель смартфона и записать в него инструкцию для запуска навигатора — и вуаля. Все стало намного проще. Тем не менее я бы рекомендовал пойти несколько другим путем и усложнить настройку, добавив к ней автоматическое включение Bluetooth (для гарнитуры), GPS и отключение Wi-Fi.
Чтобы сделать это, нам вновь понадобится Trigger. Запускаем, добавляем задание, в качестве триггера выбираем NFC. Добавляем действие «Bluetooth -> Bluetooth Вкл/Выкл -> Включить». Добавляем еще одно действие: «Беспроводные и локальные сети -> GPS Вкл/Выкл -> Включить». И еще одно: «Беспроводные и локальные сети -> WiFi Вкл/Выкл -> Выключить». Наконец, добавляем действие «Приложение и ярлыки -> Открыть приложение -> выбираем приложение». Пропускаем экран добавления переключателей, на следующем экране подносим смартфон к тегу.
Теперь после установки смартфона в держатель мы получим полностью настроенный для использования в автомобиле смартфон.
Разблокировка смартфона
У Motorola есть довольно интересный аксессуар для смартфонов под названием Motorola Skip. Это клипса на одежду для быстрой разблокировки смартфона без необходимости введения PIN-кода или графического ключа. Аксессуар в некоторых случаях довольно полезный, но работает он только со смартфонами той же компании. К счастью, аналогичную штуковину можно собрать на коленке.
Не буду рассказывать, как сделать саму клипсу, — тут каждый волен проявить свою фантазию, NFC-тег можно и на руку наклеить, — а вместо этого скажу, как настроить разблокировку смартфона при ее касании. Есть несколько способов, но самый простой и эффективный — это Xposed-модуль NFC LockScreenOff Enabler. Модуль, как и сам Xposed, требует root, но зато кроме эффективного решения задачи включает в себя суперфункцию — активацию NFC при выключенном экране.
Дело в том, что в целях безопасности Android запрещает использовать NFC до тех пор, пока экран не будет разблокирован (не просто включен, а именно разблокирован), что сводит на нет многие эффективные приемы его использования. NFC LockScreenOff Enabler решает эту проблему.
NFC-теги можно использовать в комбинации с визитками. На рынке есть несколько компаний, которые занимаются их выпуском, однако их ценники таковы, что проще самостоятельно наклеить теги на обыкновенные визитки, и в кармане еще останется куча денег. В тег можно записать любую информацию, включая контактные данные (TagWriter поддерживает такой формат), адрес веб-сайта или даже географические координаты своего офиса (смартфон автоматически откроет карты для показа положения). А самое главное — визитку совсем не обязательно отдавать человеку, достаточно, чтобы он ее отсканировал.
Включение компа
Это своего рода развитие идеи тегов на системнике и ноутбуке. Идея в том, чтобы создать настройку, которая позволит включать комп c помощью NFC-тега без учета того, где находится сам тег. Его, например, можно приклеить в прихожей, так что включить машину можно будет еще до того, как ты снимешь обувь. Метод основан на функции WoL, позволяющей включать комп с помощью отправки пакетов на Ethernet-порт, и Android-приложении Wol Wake on Lan Wan, которое делает это через интернет.
Как настроить? Для начала открываем панель управления роутером и настраиваем проброс портов 7 и 9 (порты WoL) на нашу домашнюю машину. Очень важно указать MAC-адрес вместо IP, так как последний может быть отдан другому устройству. Далее идем на noip.com, регистрируемся и получаем бесплатный домен, который мы будем использовать, чтобы достучаться до роутера извне. В том случае, если у тебя есть статический IP, этот шаг можно пропустить.
Далее устанавливаем на смартфон Wol Wake on Lan Wan, нажимаем кнопку Add New и вбиваем в открывшемся окне произвольное имя, MAC-адрес компа и полученный ранее домен, нажимаем Save. На всякий случай проверяем настройку. Далее ставим Tasker, переходим на вкладку Tasks (задачи), создаем новую задачу, в качестве действия выбираем Plugin -> Wol Wake on Lan Wan и выбираем созданный ранее WoL-профиль. Сохраняем.
Теперь нам нужно привязать эту задачу к NFC. Для этого запускаем Trigger, добавляем задание, в качестве триггера выбираем NFC, а в качестве действия — «Планировщик -> Задание Планировщика» (разрабы перевели Tasker как «Планировщик»), далее выбираем созданную на предыдущем этапе в Tasker задачу, пропускаем создание переключателей и на последнем этапе настройки подносим смартфон к NFC-тегу.
Это все. Если все настроено правильно, то при обнаружении тега Android отдаст управление Trigger, он, в свою очередь, запустит Tasker-задачу, которая активирует нужный нам профиль в приложении Wol Wake on Lan Wan, оно отправит WoL-пакет роутеру, а тот перенаправит его на MAC-адрес компа, сетевая карта которого… Ну да ладно. В общем, все просто должно работать :).
Выводы
Технология NFC имеет массу применений, и я уверен, что уже через пять лет NFC-метки и терминалы оплаты будут повсюду, от рекламных плакатов до супермаркетов. И я надеюсь, что хоть в этот раз Россия не отстанет от всего мира на пятьдесят лет.
