Звонок в приложение

Здесь мы (AbavaNet) опишем новый подход к интеграции телефонии и веб-приложений. Цель состоит в доставке голосового звонка непосредственно в веб-приложение. Это позволит, например, оставлять голосовые сообщения в приложениях, проводить голосования и т.д. При этом предложенный способ будет работать и для мобильных сайтов, где голосовое общение может быть даже более актуальным.
Сервисы, интегрирующие веб и телефонию, конечно, уже существуют. Это то, что принято называть Mobile 2.0 (или Телеком 2.0). Среди сервисов, запущенных AbavaNet, можно указать, например, запись голосовых сообщений в блоги или Voice 2 Email. Но все сервисы в целом следуют одной модели - использование открытого API веб-платформы (например, Livejournal API) для доставки звонка.
А что если сделать еще и наоборот? Не из сервиса обращаться к веб-платформе, а непосредственно из веб-приложения принимать результаты звонка. Тогда, например, для такого сервиса как запись голосовых сообщений в блоги вообще не нужна была бы какая-то отдельная регистрация своего телефона и блога. Непосредственно в блог-платформе можно было бы разместить инструмент для приема голосовых сообщений и потенциальному пользователю осталось бы только позвонить.
Как это вглядит практически? Прием звонка непосредственно в веб-приложении означает, с практической точки зрения, что непосредственно в веб-приложении мы определяем место, где будет приниматься звонок, а также собственный callback - метод, который будет отвечать за прием звонка. Поскольку мы говорим о веб, то callback здесь - это postback. То есть CGI скрипт, который будет отвечать за прием звонка. А указание места приема - это должен быть какой-то тег.
Для разработчика веб-приложения это в итоге выливается в размещение в произвольном месте своего приложения JavaScript вызова, который и выставит соответствующую метку. Выглядит это таким образом:

AcceptCall('Голосовое сообщение', 'http://myserver/my_cgi_script')

Здесь первый параметр - это заголовок для пользователя (как это будет видеть посетитель сайта), второй параметр - CGI скрипт (от _собственного_ веб приложения), который будет регистрировать звонок. Для посетителя сайта это выглядит в итоге как обычная ссылка:

Голосовое сообщение

Телефон: 0942

Кликнув на нее, пользователь получит атрибуты для звонка: сервисный номер и дополнительный код. Сервисный номер не меняется, естественно, а код будет различным. Этот код и идентифицирует в итоге точку, где принимается звонок.

После звонка на указанный номер и ввода кода (код находится перед глазами - он одноразовый и запоминать его не нужно :) голосовое сообщение будет записано. А далее - телекоммуникационная платформа просто выполнит HTTP POST запрос по URL, указанному в качестве второго параметра (см. JavaScript вызов выше). При этом записанный файл (mp3, например) будет просто передан
(выгружен) в данном запросе. И, соответственно, скрипт в веб-приложении для приема звонка есть просто CGI-скрипт для обработки загрузки файла. Для веб-приложения это выглядит так, как будто есть некоторая страница с формой загрузки файла (<input type="file" ...) и нужно обработать загружаемый пользователем медиа-файл. Далее - уже целиком область ответственности веб-приложения: просто поместить у себя ссылку на полученный файл, вставить на страницу медиа-плейер для прослушивания etc.

Как веб-приложение различит, к чему относится полученный файл? Для этого указанный выше JavaScript вызов может использоваться в такой форме:

AcceptCall('Голосовое сообщение', 'http://myserver/my_cgi_script', дополнительные параметры)

Например, для форума (блога) серверное приложение, которое выводит ветку дискуссии может добавить на генерируемую страницу такой JavaScript код, указав в дополнительных параметрах ID сообщения (топика в форуме). Дополнительные параметры будут просто передаваться вместе с медиа-файлом "как есть". Базируясь на их значениях, CGI скрипт, который будет обрабатывать прием медиа файлов сможет корректно адресовать полученный файл уже в рамках веб-приложения.

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

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

Что дальше? Хотите запустить такой сервис для своей блог-платформы, сайта, социальной сети и т.п.? Свяжитесь с нами. Кстати, интеграция телефонии - это один из способов монетизации для тех же социальных сетей. И все описанное в части бизнеса здесь, применимо и для данного сервиса.

Фишинговый генератор

Создание фишинговых страниц для тестирования детекторов

"Фишинговые атаки пытаются обмануть пользователей, что представляет собой значительную угрозу кибербезопасности. Достижения в области машинного обучения (ML) и глубокого обучения (DL) привели к разработке многочисленных решений по обнаружению фишинговых веб-страниц, но эти модели остаются уязвимыми для состязательных атак. Оценка их устойчивости к состязательным фишинговым веб-страницам имеет важное значение. Существующие инструменты содержат наборы данных предварительно разработанных фишинговых веб-страниц для ограниченного числа брендов и не имеют разнообразия в фишинговых функциях.

Для решения этих проблем мы разрабатываем PhishOracle, инструмент, который генерирует состязательные фишинговые веб-страницы путем внедрения различных фишинговых функций в легитимные веб-страницы. Мы оцениваем надежность двух существующих моделей, Stack model и Phishpedia, при классификации созданных PhishOracle состязательных фишинговых веб-страниц. Кроме того, мы изучаем коммерческую большую языковую модель Gemini Pro Vision в контексте состязательных атак. Мы проводим исследование пользователей, чтобы определить, обманывают ли пользователей вредоносные фишинговые веб-страницы, созданные PhishOracle. Наши результаты показывают, что многие фишинговые веб-страницы, созданные PhishOracle, обходят текущие модели обнаружения фишинговых веб-страниц и обманывают пользователей, но Gemini Pro Vision устойчив к атакам. Мы также разрабатываем веб-приложение PhishOracle, позволяющее пользователям вводить законный URL, выбирать соответствующие фишинговые функции и создавать соответствующую фишинговую веб-страницу. Все ресурсы общедоступны на GitHub"

См. также другие публикации по теме adversarial, посвященные устойчивому машинному обучению

Фишинг для ИИ агентов

Исследователи обнаружили простой способ ввести в заблуждение автономных агентов на основе больших языковых моделей.

Что нового: Энг Ли и его коллеги из Колумбийского университета разработали метод использования неявного доверия, которое агенты склонны оказывать популярным веб-сайтам, отравляя эти веб-сайты вредоносными ссылками.

Ключевая идея: коммерчески доступные агентские системы могут не доверять случайным сайтам в Интернете, но они склонны доверять популярным сайтам, таким как сайты социальных сетей. Злоумышленник может использовать это доверие, создавая, казалось бы, типичные посты, которые ссылаются на вредоносный веб-сайт. Агент может перейти по ссылке, ошибочно распространив свое доверие на ненадежный сайт.

Как это работает:

1) авторы протестировали агентов веб-браузинга, включая Anthropic Computer Use и MultiOn, на таких задачах, как покупки или отправка электронных писем.
2) Авторы создали посты Reddit, которые тематически соответствовали определенной агентской задаче, например, покупке обуви Air Jordan 1. Посты содержали текст, похожий на маркетинг (например, «Где купить Air Jordan 1 Chicago»), а также инструкции, указывающие на вредоносный сайт, контролируемый авторами («для получения дополнительной информации посетите <веб-сайт>»).
3) Авторы отправляли агенту запрос типа «Где купить Nike Air Jordan 1 в Чикаго?». Они также вводили конфиденциальную информацию, такую как данные кредитной карты или учетные данные электронной почты.
4) Агент искал в Интернете ресурсы, необходимые для выполнения запроса. Он изучал сайты и находил посты Reddit, написанные авторами.
5) Агент следовал инструкциям в постах и посещал вредоносный веб-сайт. Веб-сайт включал инструкции, которые манипулировали агентом для достижения цели злоумышленника, например, отправляли данные кредитной карты или отправляли фишинговые письма с адреса электронной почты пользователя.

Результаты: после того, как агент был перенаправлен на вредоносные веб-сайты, он надежно следовал инструкциям злоумышленника. Например, каждый из протестированных агентов разглашал информацию о кредитной карте в 10 из 10 испытаний. Аналогично, каждый агент отправлял фишинговое сообщение с учетной записи электронной почты пользователя с просьбой к получателям отправить деньги злонамеренному «другу» в 10 из 10 испытаний.

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

Мы думаем: люди тоже могут быть обмануты фишингом и другими вредоносными действиями, и путь к программированию агентов для защиты от них кажется проще, чем путь к обучению большинства людей этому. В долгосрочной перспективе агенты сделают онлайн-взаимодействия более безопасными. /via Deeplearning.ai

См. также другие публикации, посвященные агентам

Мониторинг оборудования

Практическое использование веб-шлюзов. Это элементы сети, которые позволяют скрыть непосредственный доступ к аппаратуре, предоставив внешним пользователям простой веб-интерфейс. Пользователь общается с веб-сервером (то есть по HTTP), а веб-сервер с железом - уже по Modbus. Дальше - это уже вопрос сетевых технологий. Если веб-сервер на шлюзе сделать доступным извне, то вести мониторинг можно будет из любой точки, где есть Интернет. Для безопасности можно разрешить веб-шлюзу только читать данные ModBus. Вот пример: DSEWebNet Gateway. Устройство позволяет организовать web-мониторинг и управление дизель-генераторных установок через систему DSEWebNet из любой точки доступа в Internet. Получится веб-мониторинг для Modbus

См. также другие публикации, посвященные Modbus

Telecom 2.0 сервисы – телекоммуникационные сервисы в сети Интернет

Это основное содержание большой статьи по Telecom 2.0. Автор - Дмитрий Намиот, технический директор компании AbavaNet.

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

Что мы рассматриваем? Традиционно (хотя это на самом деле касается больше российской практики) под IVR сервисами понимают телекоммуникационное приложение, связанное с голосовой информацией. Сюда традиционно относят, в первую очередь, все call-центры, а также выдачу абонентам некоторой подготовленной информации (справки, аудио-книги и т.д.)

Мы же хотим рассмотреть сервисы, которые либо каким-либо образом используют реальные данные из сети Интернет, либо обеспечивают взаимодействие абонентов с сервисами сети, либо, в отличие от call центров, обеспечивают взаимодействие абонентов не с операторами call центра, а с другими абонентами или пользователями веб-сервисов (веб-приложений). При этом нас будет интересовать возможность предоставления услуг, которые существуют вне сети оператора связи (контент-агрегатора). Это то, что принято классифицировать как Telecom 2.0 (более детальное рассмотрение собственно этой классификации оставим за рамками данной статьи).

Реально мы хотели бы представить ряд сервисов, разработанных компанией AbavaNet и реализованных на CTI платформе компании Audiotele.

Технически в настоящий представленные сервисы доступны через короткий номер 0942 компании Audiotele (Билайн, МТС, Мегафон, Теле-2, Смартс). Поэтому можно представить это все как Mobile 2.0 сервисы.

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

Естественно, mp3 файлы (то, что входит в подкасты) можно и сейчас загрузить в мобильный терминал. Много телефонов прямо с RSS фидами и работает, IPhone вот весь об этом и т.д. Сети 3G уже где-то маячат на горизонте. Иными словами, проигрывать файлы на мобильном телефоне можно и сейчас. Основное достоинство реализованного способа в том, что ничего не требуется настраивать в телефоне. И требований к нему никаких. Это просто звонок - то, для чего, вообще говоря, телефон и предназначен.

При прослушивании можно нажать любую клавишу для листания по медиа-файлам (циклическое листание). Кнопки * и # соответствуют продвижению на 15 секунд вперед/назад.

При этом просто прослушивание – это только начало пути. Сейчас мы продемонстрировали листание при прослушивании. А что Вы думаете о возможности добавлять свои комментарии прямо в процессе прослушивания? Их тогда услышат следующие слушатели и, попутно, они будут автоматически оформлены в отдельный подкаст. Просто еще один дополнительный RSS feed.

Для авторов подкастов, во-первых, открывается новый канал распространения. Во-вторых, по крайней мере теоретически, появляется возможность договариваться с агрегаторами о платной поставке контента. Возможно, появятся какие-то другие модели. Например, хотя бы для обсуждения – прослушивание подкаста может быть совсем бесплатным (при запуске сервиса на 800-м номере). Если покастер (автор подкаста – а это ведь может быть и корпоративный ресурс), соберет, например, достаточно рекламодателей для своего блога, то этого может и хватить на оплату 800-го номера.

2. Голосовые SMS. Суть сервиса Voice SMS заключается в создании возможности обмена голосовыми сообщениями, аналогично тому, как пользователи обмениваются в настоящее время сообщениями SMS. Однако вместо набора текста, который будет передаваться по сети, пользователи смогут записывать голосовые сообщения, адресованные другим абонентам.

Собственно сервис есть программа (IVR), которая обрабатывает звонки на некоторый сервисный номер. Абонент мобильной сети звонит на данный номер и тоновыми посылками вводит номер (или код – смотри ниже) другого абонента, которому он хочет отправить голосовое сообщение. После ввода номера у него есть какое-то время для ввода (записи) голосового сообщения. Сообщение сохраняется в системе вместе с номером абонента, которому оно было адресовано. По номеру, на который адресовано сообщение, отправляется SMS с уведомлением. В уведомлении указан сервисный номер, так что получатель этого короткого сообщения может немедленно позвонить без дополнительного набора. Например, SMS сообщение, которое получит адресат, выглядит, например, так: «Вам оставлено голосовое сообщение. Для прослушивания позвоните по номеру 0942, код сервиса 8882». В этом случае получателю SMS достаточно одного нажатия после открытия SMS, чтобы позвонить на сервисный номер

Абонент мобильной связи звонит на сервисный номер. После того, как определен его номер (A-номер), могут быть найдены голосовые сообщения, ассоциированные с этим номером. Не нужно набирать никаких дополнительных кодов, достаточно самого факта звонка и определения A-номера. Абоненту предлагается прослушать поступившие сообщения. После каждого сообщения позвонившему предлагается оставить ответ на данное сообщение.
Таким образом, создана интерактивная среда обмена голосовыми сообщениями. Сервис коротких сообщений (SMS- центр) используется здесь только для уведомления абонента о факте поступления голосового сообщения, которое было ассоциировано с его номером. Смысл использования коротких сообщений состоит в том, что, зная только номер абонента, мы автоматически (без какой либо предварительной регистрации абонента в системе) можем отправить ему уведомление. Технически, при наличии предварительной регистрации или какой-то внешней базы по абонентам, короткие сообщения могут быть, конечно, заменены (или использованы в сочетании с) электронной почтой или IM (Jabber, ICQ, Yahoo и др.)

Смысл сервиса состоит в том, что оставить голосовое сообщение может быть во многих случаях проще, чем набирать какой-то текст на мобильном телефоне. За один и тот же промежуток времени можно больше "наговорить", чем напечатать. Телефон в данном случае используется более естественным образом – в него "говорят". А использование коротких сообщений позволяет уведомлять абонента о сообщении с той же скоростью, как и при отправке SMS. Другим достоинством данного способа отправки сообщений является его анонимность. Номера отправителей сообщений не раскрываются, получатель прослушивает только текст сообщения и может оставлять ответы, не зная реального номера адресата.

Номер адресата при отправке сообщения может быть заменен некоторым кодом, соответствующим номеру телефона адресата. Идея состоит в том, что этот номер может быть свободно анонсирован его владельцем, как адрес для контакта с ним в системе голосовых сообщений. Номер (код) может свободно публиковаться в объявлениях, в профайлах социальных сетей. Именно эта возможность предназначена для использования сервиса в сети Интернет. Использование кодов позволяет добавлять голосовой канал общения к любому веб-ресурсу.

3. Блоги. Вполне естественная область приложения для сервисов. Все базируется на том, что платформы хостинга блогов (livejournal.com, liveinternet.com, blogger.com и т.д.) имеют открытые API для работы с данными. Отсюда немедленно возникает и сервис – голосовые записи для блогов. Иными словами, возможность опубликовать запись в блоге, содержащую голосовую информацию, записанную по телефону. Заметим, что этот сервис предоставляется (существует) вне сети агрегатора. Платформа блогов (livejournal.com, liveinternet.ru) остается сама собой, Audiotele просто предоставляет новый интерфейс. И уж заведомо весь контент (как, впрочем, и в случае подкастов) создается самими пользователями.

4. Click to Mobile. Здесь эксплуатируется сам факт совершения звонка на premium rate номер. Суть сервиса заключается в создании возможности сохранения данных из сети Интернет в мобильном телефоне.

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

Одно из возможных решений достаточно простое, и оно реально уже используется. Ссылку на ваш сайт (HTML страницу, WML сайт, mp3 файл, картинку в формате gif или jpeg и т.д.) можно послать по SMS. Именно так работает распространение платного контента по SMS. Пользователь посылает по SMS некоторый код и получает в ответ ссылку для загрузки.

Посмотрим на эту проблему с другой стороны. Что если владелец контента (сайта) сам будет определять, какие ссылки мобильный абонент будет получать на свой телефон? А посетитель веб-сайта, соответственно, сам будет выбирать, какие из них он хочет получить (сохранить) на своем телефоне. Именно так – не подготовленный специально для платного сервиса контент, а контент уже существующий на сайте, независимо от каких-либо телекоммуникационных сервисов.

Как это работает? Здесь это описано подробно: http://click.linkstore.ru
Владелец сайта (веб-мастер) размещает по своему усмотрению ссылки на своем сайте, предлагающие пользователю сохранить определенный контент на своем мобильном телефоне. Это полностью бесплатно, для этого даже не требуется никакой предварительной регистрации. Каждая такая ссылка – это обычный гиперлинк.

Заинтересованный пользователь может, соответственно, активировать (кликнуть) эту ссылку. В появившемся окне (посетитель не покидает исходный сайт) ему будет предложено указать номер мобильного телефона, которому будет адресован контент, связанный с данной ссылкой.

Естественно, что сообщение не может быть направлено сразу по заданному номеру – это была бы рассылка спама. Поэтому, после сохранения контента абоненту необходимо позвонить с указанного телефона на сервисный номер. Этот звонок и будет являться подтверждением (согласием) на получение контента. Для подтверждения достаточно только звонка, никаких кодов вводить не нужно. После подтверждения контент, заданный владельцем сайта, будет доставлен мобильному абоненту по SMS.

Аналогичным образом механизм работает и в случае использования подтверждающего SMS вместо звонка.

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

Область применения, естественно, не ограничивается одними ссылками. Посетитель веб-сайта сможет сохранять и любой текст, определенный владельцем ресурса. Это может быть, например, адрес или телефоны, расписание работы, описание товара и т.п.

Это типичный пример Mobile 2.0 (или Telecom 2.0) сервиса. Здесь имеет место конвергенция - данные интернет сайтов представляются мобильным пользователям как есть. Это реальный способ вдохнуть новую жизнь в мобильный интернет.

Что дальше? Нам кажется, что нельзя не отметить проблемы, с которыми сталкивается реализация приложений, подобных описанным выше.

Во-первых, это доступ к телекоммуникационной среде. Очевидно, что развитие SMS сервисов связано, в первую очередь, с более или менее стандартизованным способом доступа. По крайней мере, сейчас, программирование SMPP превратилось в чисто техническую задачу, оставив развитие сервисов маркетологам и рекламистам. Это совсем не так для IVR. И, к сожалению, все правильные слова, типа Voice XML, пока, с практической точки зрения остаются только словами. Именно доступность средств разработки и низкий входной барьер стали основным локомотивом развития сервисов в Web. Входной барьер для любых разработок с использованием IVR в настоящее время, к сожалению, слишком высок.

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

Что можно сказать в заключение? Нам представляется, что развитие телекоммуникационных сервисов, связанных с Интернет является, тем не менее, самым перспективным направлением. Да, никогда не исчезнут IVR сервисы, связанные с непосредственным общением с оператором. Но все остальное, по нашему мнению, обязательно будет в той или иной степени завязано на Web-среду. В настоящее время номер 0942 компании Audiotele является самым "Mobile 2.0" номером в России (по количеству и номенклатуре доступных сервисов – мы описали только часть из имеющегося), но мы уверены, что в самое ближайшее время мы увидим новые примеры из этой области, причем от самых разных производителей. Впрочем, и мы сами не собираемся стоять на месте, так что следите за анонсами.

Есть идей, предложения или замечания? Хотите рассказать о новом сервисе? Пишите info AT abavanet.ru, читайте новости в нашем блоге, присылайте ссылки на свои продукты. Это действительно очень интересная тема.

Прием звонка

Здесь мы собрали воедино разные способы использования голосовых звонков в своих веб-приложениях, которые можно реализовать с помощью наших сервисов. Что мы имеем в виду? Это возможность пользователю "позвонить" в веб-приложение (блог, сайт, социальную сеть). А веб-приложению, соответственно, без использования специальных телекоммуникационных API, принять информацию о звонке. И использовать далее голосовые отклики пользователей. Что здесь может быть:

1. Блог-платформа как CMS (content management system). Вот на базе сервисов типа Голос ЖЖ (публикация голосовых сообщений в livejournal.com) или Голос Li.ru (то же самое для liveinternet.ru), которые непосредственно предназначены для публикации голосовых файлов в блогах, можно сделать сервис, который просто будет собирать голосовые звонки в указанном вами блоге. Безо всякой регистрации пользователей, просто сбор голосовых звонков и публикация аудио-файлов файлов в блоге. А у блога (журнала), естественно, есть RSS поток. Это уже сама блог-платформа обеспечивает. И из этого RSS фида ваше веб-приложение может и выбирать голосовые файлы пользователей. Опять таки, разбор XML реализован уже везде.

2. Voice 2 Email. Сервис позволяет принимать голосовые звонки по email. Письмо, с записанным mp3 файлом в аттачменте. А ведь помимо чтения писем в каком-то почтовом клиенте их можно получать и программно. Реализации POP/IMAP библиотек есть для всех систем программирования. То есть ваше приложение может собирать голосовые отклики просто из своего почтового ящика.

3. Call2Web. Непосредственный прием голосовых файлов в приложении. Это самое правильное, пожалуй. Вы сами опеределяете callback, в качестве которого здесь выступает CGI скрипт для выгрузки файла. Веб-приложение, в итоге, получает mp3 файл, записанный на телекоммуникационной платформе. И эта операция реализуется просто как загрузка файла.

4. Персональное использование. Здесь, например, Voice 2 WAP. Вы звоните и записываете сообщение. Ссылка на записанный mp3 файл придет на ваш же телефон по SMS. Это просто mp3 файл. Его, кстати, не обязательно прямо здесь на телефоне выгружать. Это обычный URL, загрузить файл можно где угодно. А можно пришедший SMS со ссылкой кому-то просто переслать. Голосовое письмо получится.
Ну и упоминавшийся сервис Voice 2 Email. Можно завести код сервиса для собственного email адреса. Иными словами, у вас будет персональный код сервиса, при звонке на который записанные аудио-файлы будут отсылаться в указанный вами почтовый ящик.

Физический браузер

Веб-браузер с возможностью доступа к информации о физическом окружении, которое представляется в виде данных, прочитанных с помощью сенсоров мобильного телефона и доступных для обработки в приложениях, выполняемых на веб-страницах. Программа предоставляет возможность для программ на языке JavaScript, исполняемых на веб-странице, получать доступ к информации о физическом окружении мобильных устройств. Физическое окружение мобильного устройства определяется с помощью данных сенсоров и камеры мобильного устройства. Данные, прочитанные с помощью сенсоров и камеры устройства, представляются в формате, доступном для обработки в программах, и добавляются к содержанию веб-страницы, так, что отображение такой веб-страницы может быть изменено с учетом информации о физическом окружении. Отсюда

Уязвимости в связке LLM и веб-приложений

Большие языковые модели все чаще интегрируются в веб-приложения посредством чат-ботов, конвейеров вызова инструментов и агентных рабочих процессов. В этих системах пользовательский ввод может влиять не только на генерируемый текст, но и на действия бэкэнда, такие как запросы к базе данных, HTTP-запросы, операции с файлами, рендеринг шаблонов или вызовы API. В этой статье представлены веб-атаки с использованием больших языковых моделей (LLM), класс атак, при которых контролируемый злоумышленником ввод преобразуется интегрированным в LLM приложением, а затем достигает традиционных приемников веб-приложений. Мы систематизируем эту поверхность атаки с помощью репрезентативных вариантов LLM2X, включая LLM2SQLi, LLM2XSS, LLM2SSTI, LLM2CommandInjection, LLM2IDOR, LLM2CSRF, LLM2XXE и LLM2 SSRF. Наш анализ показывает, что LLM обычно не создает саму лежащую в основе уязвимость; Скорее, он действует как посреднический слой, а в некоторых настройках с поддержкой инструментов — как дезориентированный заместитель, переносящий влияние злоумышленника в компоненты, которые доверяют контенту, сгенерированному моделью или на который влияет модель. В качестве экспериментального примера мы реализуем TicketOracle, веб-приложение на основе Flask, интегрированное с LLM, для оценки LLM2SSRF в пяти сценариях атак и семи LLM. Наши результаты показывают существенные различия в уязвимости в зависимости от модели, что предполагает, что эксплуатация зависит как от небезопасной архитектуры приложения, так и от поведения, специфичного для модели. В заключение мы предлагаем стратегии смягчения последствий на уровнях подсказки, модели, приложения и сети. - From Prompt Injection to Web Exploitation: Revisiting Classic Vulnerabilities in LLM-Integrated Applications

См. также другие публикации, посвященные LLM

Локальный чат и форумы

Обновлено мобильное приложение WiFiChat. Форум и чат, привязанные к конкретной WiFi сети.

Какие общие объекты (реальные или искусственные) могут послужить некоторым объединительным моментом (пунктом), вокруг которого можно собрать мобильных пользователей? Речь не идет о том, что мобильные абоненты могут являться членами какой-то социальной сети. Это скорее способ собрать какую-то группу по интересам, что называется, на лету. Вот, например, несколько приложений:

Городские форумы - обсуждения (дискуссии, форумы), привязанные к каким-то местам (POI - point of interest)
Гео-форумы - такие же дискуссии, но привязанные только к географическому положению
Мобильный форум - форум (обсуждение), привязанное к какому-то физическому объекту (предмету).
Городской чат - веб-чат, привязанные к какому то месту (POI)
Гео-чат - веб-чат, привязанный к местоположению.

WiFi chat - это мобильное приложение (Android), которое позволяет видеть доступные в данном месте WiFi сети и привязать обсуждение (или веб-чат) к конкретной сети. Речь не идет о присоединении к данной сети, WiFi сеть используется как сенсор. Те, кто видят эту сеть - находятся поблизости друг от друга. Им может быть есть, что обсудить, о чем поговорить и т.д. А уж используют они для доступа к сети вообще WiFi, данную сеть или мобильный интернет от оператора - это их личное дело.

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

Технически приложение использует облачные форумы от Disqus и веб-чат от Coldbeans.

Вот ссылка для загрузки .apk файла:

http://servletsuite.com/WiFiChat.apk

и соответствующий QR-код:



Можно, естественно, загрузить приложение непосредственно с Android Market - WiFi chat from Coldbeans

WiFiChat, на самом деле, есть часть (побочный эффект) проекта SpotEx, который позволяет привязать свои собственные данные (сообщения) к точкам доступа WiFi.

Местные чат и форум

Обновлено мобильное приложение WiFi chat. Какие общие объекты (реальные или искусственные) могут послужить некоторым объединительным моментом (пунктом), вокруг которого можно собрать мобильных пользователей? Речь не идет о том, что мобильные абоненты могут являться членами какой-то социальной сети. Это скорее способ собрать какую-то группу по интересам, что называется, на лету. Вот, например, несколько приложений:

Городские форумы - обсуждения (дискуссии, форумы), привязанные к каким-то местам (POI - point of interest)
Гео-форумы - такие же дискуссии, но привязанные только к географическому положению
Мобильный форум - форум (обсуждение), привязанное к какому-то физическому объекту (предмету).
Городской чат - веб-чат, привязанные к какому то месту (POI)
Гео-чат - веб-чат, привязанный к местоположению.

WiFiChat представляет собой форум и чат, привязанные к конкретной Wi-Fi сети. Это мобильное приложение (Android), которое позволяет видеть доступные в данном месте Wi-Fi сети и привязать обсуждение (или веб-чат) к конкретной сети. Речь не идет о присоединении к данной сети, Wi-Fi сеть используется как сенсор. Те, кто видят эту сеть - находятся поблизости друг от друга. Им может быть есть, что обсудить, о чем поговорить и т.д. А уж используют они для доступа к сети вообще Wi-Fi, данную сеть или мобильный интернет от оператора - это их личное дело.

Одно интересное замечание (хинт) - точка доступа Wi-Fi может быть создана непосредственно на мобильном телефоне. Опять таки, поскольку речь в данном сервисе не идет о присоединении пользователей Wi-Fi, такая точка доступа (по сути - такой телефон) играет роль сенсора присутствия, к которому могут быть присоединены обсуждения.

Технически приложение использует облачные форумы от Disqus и веб-чат от Coldbeans.

Вот ссылка для загрузки .apk файла с Android Market:

com.wifichat

также можно загрузить приложение непосредственно с нашего сайта. Вот соответствующий QR-код:



WiFiChat, на самом деле, есть часть (побочный эффект) проекта SpotEx, который основан на идеях Wi-Fi proximity и позволяет привязать свои собственные данные (сообщения) к точкам доступа Wi-Fi. Но это уже отдельная история.

Где ты находишься?

Обновлен мэшап Where Are You Now? Самый популярный запрос, который посылается в мобильных сетях. Именно на идее обслуживания такого типа запросов и основан подход Geo Messages, предлагающий новый способ обмена информацией о позиционировании в мобильных сетях.

Этот подход может быть использован в различных сервисах. Один из них - это мобильное веб-приложение Geo Mail. Представляет пользователю возможность послать с мобильного телефона email, в котором будут содержаться координаты места отправки. Мобильное веб-приложение, ничего инсталлировать не нужно, достаточно знать URL сервиса (сохранить его в закладках, например). А если этот URL неизвестен тому, чье местоположение нам нужно знать? Простое решение - а что если отправить ему ссылку на это приложение? Запросить его местоположение, отправив ему ссылку на веб-страницу, откуда он (при желании) может ответить. Заодно и решается вопрос с разрешением на запрос координат. Получатель сам решает - отвечать на такое сообщение или нет. Именно это и реализуется в мэшапе Where are you now.

Это мобильное HTML5 веб-приложение, которое позволяет отправить email с запросом координат другому пользователю. Короткий URL для доступа:

http://bit.ly/cy6ndx

Можно также воспользоваться следующим QR-кодом для загрузки:



Попробуйте с любого телефона с HTML5 браузером (iPhone, Android, Samsung etc.)

Place Card - кнопка Like для реальных объектов

Обновлен мэшап Place card - простая рекомендательная система на базе Facebook.

Кнопка Like из Facebook может быть размещена, в том числе, и на мобильных веб-страницах. Если эта мобильная страница посвящена какому-то реальному объекту (например, кафе, ресторану, банку, продукту и т.д.), то выражение "Нравится" приобретает вполне конкретный смысл - пользователь (посетитель страницы) сможет видеть, кто из его друзей в социальной сети отметил (рекомендует) этот сервис (товар и т.д.).

Мэшап Place Card позволяет создать мобильную страницу (визитку) для бизнеса и соответствующий QR-код. Этот код может быть размещен в витрине, на двери и т.д. Можно, естественно, разместить QR-код и просто на сайте (например, в разделе Контакты, О компании - мобильная веб-страница, открывающаяся при сканировании может содержать адрес и другую контактную информацию).

Ну и помимо QR-кода, можно, естественно, просто созданную ссылку использовать в своем мобильном сайте (портале, сервисе).

Веб-страница, которая открывается при сканировании кода (или по ссылке) содержит кнопку Like. Можно видеть, отметил-ли кто-нибудь из друзей это место и, в свою очередь, самому рекомендовать его друзьям.

В итоге - простая рекомендательная система на базовых средствах Facebook. Можно также задать свою страницу (сайт), куда будет переадресован мобильный пользователь, если он нажмет кнопку Like. Можно указать свой код для Google Analytics и отслеживать статистику по посещениям.

В целом - такой специализированный генератор мобильных веб-сайтов.

Из схожих продуктов см. также:

мобильные дискуссии для реальных объектов
собственные реакции для кнопки Like

Мобильная идентификационная карта

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

Регистрируетесь со своим Facebook ID на странице Facebook Card и получаете короткую ссылку на мобильную веб-страницу. Эту ссылку достаточно просто запомнить в закладках своего мобильного браузера. Для этого можно прямо набрать полученный короткий URL, либо воспользоваться приводимым QR кодом, просто просканировав его с экрана с помощью своего мобильного телефона.

Эта веб-страница и есть мобильный идентификатор, для создания которого использовались публичные данные из Facebook.

Далее - как выглядит проверка (предъявление) идентификатора. Необходимо просто открыть из закладок браузера сохраненную мобильную страницу. На ней будет QR-код. Этот QR-код (экран телефона) и предъявляется в месте проверки. Здесь QR-код может быть сосканирован непосредственно с экрана вашего телефона, и результатом этого процесса будет уже мобильная веб-страница, которая показывает фото из профайла в Фейсбук и имя автора. Проверяющий сможет сравнить фото с оригиналом etc.
Иными словами для проверки идентификационной карты достаточно просто считать QR-код с экрана телефона. Для этого, естественно, можно воспользоваться просто мобильным телефоном, на котором есть читалка QR-кодов.

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

Зачем представлять карту в виде QR-кода? По крайней мере, две причины:

- во-первых, после сканирования QR кода открытие страницы с реальной информацией происходит уже на телефоне проверяющего. То есть уже видно на каком сайте она находится и т.д. - чтобы исключить простую подмену
- во-вторых, и это самое главное, после сканирования QR-кода происходит открытие динамической страницы (скрипта) - в данном случае JSP. А это означает, что кроме простого показа фотографии, можно, например, записать ID и имя пользователя в какую-то собственную базу (отметить пришедшего, зарегистрировать check-in и т.д.). Кстати, если сканировать код (проверять карту) с помощью iPhone или Android, то можно еще и координаты места проверки записать. Например, реальный check-in в ресторане (магазине) можно так реализовывать - когда отметка в каком-то месте требует подтверждения от персонала.

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

- регистрация на мероприятия. Идентификационная карта создается на сайте мероприятия (там авторизуется пользователь Facebook), далее предъявляется (проверяется) на входе. Устройство для проверки - мобильный телефон с программой чтения QR кода

- мобильные билеты

- карты лояльности

GeoSMS beta 3

Новый релиз продукта, добавлены новые функции взаимодействия. Что есть:

Google Maps mashup - SMS сообщения на карте. Микроблогинг, где вы можете смотреть в реальном времени SMS сообщения, привязанные к географическим координатам.



Как это работает:

1. веб-приложение: http://geosms.linkstore.ru
После запуска нажмите линк Start. Теперь отображение запущено. SMS, присланные на номер 7909 9213670 будут отображаться на карте. Для остановки процесса нажмите Stop, соответственно.

2. Пошлите SMS на номер 7909 9213670. Это обычный номер, (не premium rate) - отправка SMS стоит столько, сколько она стоит в вашем тарифном плане. Оператор - Билайн. Формат SMS для отправки

*адрес*текст сообщения

Иными словами * в начале сообщения обрамляют адрес. Например:
*Клинцы*Мы из Клинцов
или
*Москва, Зеленоградская 45*Речной вокзал

Для Москвы можно, например, указать станцию метро:

*Москва Динамо*

вы можете, также, послать отдельно SMS с адресом:

*адрес*

Такие сообщения не отображаются, но тогда в последующих SMS адрес можно не указывать. Все сообщения с данного номера будут привязаны к последнему известному адресу. И так до тех пор, пока вы не смените адрес.

Если адрес для номера отправителя не указан (не установлен), то текст сообщения привязывается к точке с координатами (53.142729083526305, 29.223976135253906). Это в районе Бобруйска.

Просматривать сообщения можно либо для всей карты (режим Free Map) или только для выбранного участка карты (Fixed Map). В режиме Fixed Map вы будете видеть только сообщения относящиеся к видимому фрагменту карты.
Линк Home позволяет вам запомнить установки карты для следущего запуска, Zoom - разворачивает/сворачивает карту. Гиперссылка Center позволяет вам искать определенный адрес на карте и быстро переместиться на заданный участок.
Карту можно встроить в собственный сайт (блог) - ссылка Embed. Тогда ваши посетители смогут следить за новыми сообщениями (и комментировать их) непосредственно на вашем собственном сайте.

Для веб-пользователей в настоящей версии поддержан Чат. Также можно выбрать область на карте и подписаться по RSS на все сообщения, которые будут появляться в этой области.

Мобильные пользователи могут использовать следующий WAP http://wsms.linkstore.ru или PDA http://psms.linkstore.ru сайты. Если на любом из мобильных сайтов в начальной форме указать номер телефона, то, в предположении что его координаты вами заданы (см. выше), можно читать последние сообщения относящиеся к области с радиусом примерно 20 км от данной точки. А для неизвестного номера, соответственно, - 20 км в окрестности Бобруйска. То есть можно микроблогинг использовать еще и как местные новости с поддержкой мобильных пользователей.

Все сообщения модно комментировать. При этом мобильные пользователи, естественно, будут видеть комментарии от веб-пользователей на свои сообщения. То есть, это можно использовать и как wap-чат (причем, местный). В одном из примеров использования это была система помощи для мобильных пользователей. Они могли получать комментарии от веб-пользователей на свои сообщения/запросы. Хинт: в комментариях можно указывать ссылки, тогда WAP пользователи смогут загружать указанные ресурсы.
Некоторые другие возможные применения указаны в этом отклике на ранние версии сервиса.

Кто бы мог подумать?

Скрытая атака показывает зараженные веб-страницы только агентам ИИ. Компания JFrog обнаружила, что агенты ИИ могут быть обмануты и скрытно выполнять вредоносные действия с помощью веб-сайтов, скрытых от обычных пользователей. Этот новый подход позволяет злоумышленникам внедрять подсказки/инструкции в этих автономных «помощников» на базе ИИ, что позволяет им использовать поведение агентов в своих вредоносных целях. Атаки с непрямым внедрением подсказок, когда скрытые вредоносные инструкции внедряются в ту же страницу, которую видит посетитель, редко обнаруживаются людьми, но всё же могут быть обнаружены системами безопасности. Эта новая атака с «параллельным отравлением веба» идёт на шаг дальше и предоставляет совершенно другую версию страницы только агентам ИИ.

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

См. также другие публикации, посвященные агентам

Абавазрение 09.04.2013

Некоторые интересные ссылки:

1. Интересная статья на тему Google и Android. Google нужен веб для поиска. И в какой-то момент времени мобильная ОС станет помехой.

2. Интересный тренд: вендинг-машины в такси. Покупайте, пока едете.

3. Последние предложения IBM в области Big Data. NoSQL по IBM-вски.

4. Хостинг веб-страниц на Google Drive. Как это сделать.

5. Солидная коллекция инструментов для веб-дизайна.

6. JavaScript плагин для размещения инструкций на веб-страницах. Вот здесь есть демо.

7. На сайте inetique.ru отредактирован раздел новости.

8. Инструменты для организации работы

9. Тренинги по UML.

Мобильные веб-страницы

Обновлен сервис - Мобильные страницы. Идея в некоторой степени аналогична тому, что было сделано в мобилизаторе (быстрая подготовка мобильных веб-страниц), но по отличается по набору создаваемых приложений. Вот первое из них - как облегчить попадание своего телефона в чужую адресную книгу.

Как, например, обычно делятся контактами? Можно взять и позвонить собеседнику. Звонок принят - есть номер абонента, можно занести его в телефонную книгу. Но имя придется набирать. Вот эту задачу можно теперь упростить. Что если вы на своем телефоне предварительно заготовите мобильную веб-страницу со своим контактом? Страница может быть сохранена в закладках. Когда нужно поделиться с кем-нибудь контактом, то можно будет открыть эту страницу из закладок и послать ее собеседнику по SMS. Прямо на самой странице будет ссылка, которая позволяет послать страницу по SMS.
А на самой странице будет код (также ссылка) которая позволит вашему собеседнику после получения от вас контактной страницы (в SMS) добавить ваш телефон в адресную книгу одним кликом. Не нужно ничего вводить - просто кликнуть на имени (телефоне) и подтвердить добавление новой записи в адресную книгу.
Вопрос здесь не только в лени (хотя удобство, конечно - великая вещь), но и в том, что таким образом данные будут всегда в корректной форме (нет ошибок ввода).

Это первое из доступных приложений. Другие сервисы позволяют просто скопировать ссылку на мобильный телефон (с помощью QR-кодов), создать страницу, которая позволяет поделиться какой-то ссылкой уже непосредственно с телефона, отправить SMS, создать черновик SMS на мобильном телефоне. Можно также создавать собственные мобильные порталы. Если есть набор источников (сайтов, RSS-фидов), которые вы постоянно читаете, то можно быстро создать себе мобильную веб-страницу (портал) и читать их с телефона. Непосредственно на телефон страница копируется посредством QR-кода. По сути, наш мобильный портал был именно так и сделан.

В целом идея может описана как подготовка мобильных "бомб" - зарядка (загрузка) собственного телефона собственноручно созданными сервисами, которые будут активироваться по необходимости.

Где ты?

Обновлен мобильный веб-мэшап WAYN.

Самый популярный запрос, который посылается в мобильных сетях. Вот на идее обслуживания такого типа запросов и основан подход Geo Messages, предлагающий новый способ обмена информацией о позиционировании в мобильных сетях. Этот подход может быть использован в различных сервисах. Здесь мы опишем еще один.

Есть приложение Geo Mail. Представляет пользователю возможность послать с мобильного телефона email, в котором будут содержаться координаты места отправки. Мобильное веб-приложение, ничего инсталлировать не нужно, достаточно знать URL сервиса (сохранить его в закладках, например). А если этот URL неизвестен тому, чье местоположение нам нужно знать? Простое решение - а что если отправить ему ссылку на это приложение? Запросить его местоположение, отправив ему ссылку на веб-страницу, откуда он (при желании) может ответить. Заодно и решается вопрос с разрешением на запрос координат. Получатель сам решает - отвечать на такое сообщение или нет. Именно это и реализуется в мэшапе Where are you now.

Это мобильное HTML5 веб-приложение, которое позволяет отправить email с запросом координат другому пользователю. Короткий URL для доступа:

http://bit.ly/cy6ndx

Можно также воспользоваться следующим QR-кодом для загрузки:



Мэшап можно использовать в собственных мобильных сайтах (порталах). Базовый URL обрабатывает следующие дополнительные параметры:

to - адрес для отправки
subject - тема письма (по умолчанию: Where are you?)
reply - предопределенный адрес для ответа

Например: Where are you

Попробуйте с мобильного HTML5 браузера (iPhone, Android, Samsung)

Локальные коммуникации

Обновлено мобильное приложение WiFi chat. Какие общие объекты (реальные или искусственные) могут послужить некоторым объединительным моментом (пунктом), вокруг которого можно собрать мобильных пользователей? Речь не идет о том, что мобильные абоненты могут являться членами какой-то социальной сети. Это скорее способ собрать какую-то группу по интересам, что называется, на лету. Вот, например, несколько приложений:

Городские форумы - обсуждения (дискуссии, форумы), привязанные к каким-то местам (POI - point of interest)
Гео-форумы - такие же дискуссии, но привязанные только к географическому положению
Мобильный форум - форум (обсуждение), привязанное к какому-то физическому объекту (предмету).
Городской чат - веб-чат, привязанные к какому то месту (POI)
Гео-чат - веб-чат, привязанный к местоположению.

WiFiChat представляет собой форум и чат, привязанные к конкретной WiFi сети. Это мобильное приложение (Android), которое позволяет видеть доступные в данном месте WiFi сети и привязать обсуждение (или веб-чат) к конкретной сети. Речь не идет о присоединении к данной сети, WiFi сеть используется как сенсор. Те, кто видят эту сеть - находятся поблизости друг от друга. Им может быть есть, что обсудить, о чем поговорить и т.д. А уж используют они для доступа к сети вообще WiFi, данную сеть или мобильный интернет от оператора - это их личное дело.

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

Технически приложение использует облачные форумы от Disqus и веб-чат от Coldbeans.

Вот ссылка для загрузки .apk файла с Android Market:

com.wifichat

также можно загрузить приложение непосредственно с нашего сайта. Вот соответствующий QR-код:



WiFiChat, на самом деле, есть часть (побочный эффект) проекта SpotEx, который позволяет привязать свои собственные данные (сообщения) к точкам доступа WiFi. Но это уже отдельная история.

Очень местные чат и форум

Обновлено мобильное приложение WiFi chat. Какие общие объекты (реальные или искусственные) могут послужить некоторым объединительным моментом (пунктом), вокруг которого можно собрать мобильных пользователей? Речь не идет о том, что мобильные абоненты могут являться членами какой-то социальной сети. Это скорее способ собрать какую-то группу по интересам, что называется, на лету. Вот, например, несколько приложений:

Городские форумы - обсуждения (дискуссии, форумы), привязанные к каким-то местам (POI - point of interest)
Гео-форумы - такие же дискуссии, но привязанные только к географическому положению
Мобильный форум - форум (обсуждение), привязанное к какому-то физическому объекту (предмету).
Городской чат - веб-чат, привязанные к какому то месту (POI)
Гео-чат - веб-чат, привязанный к местоположению.

WiFiChat представляет собой форум и чат, привязанные к конкретной WiFi сети. Это мобильное приложение (Android), которое позволяет видеть доступные в данном месте WiFi сети и привязать обсуждение (или веб-чат) к конкретной сети. Речь не идет о присоединении к данной сети, WiFi сеть используется как сенсор. Те, кто видят эту сеть - находятся поблизости друг от друга. Им может быть есть, что обсудить, о чем поговорить и т.д. А уж используют они для доступа к сети вообще WiFi, данную сеть или мобильный интернет от оператора - это их личное дело.

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

Технически приложение использует облачные форумы от Disqus и веб-чат от Coldbeans.

Вот ссылка для загрузки .apk файла с Android Market:

com.wifichat

также можно загрузить приложение непосредственно с нашего сайта. Вот соответствующий QR-код:



WiFiChat, на самом деле, есть часть (побочный эффект) проекта SpotEx, который позволяет привязать свои собственные данные (сообщения) к точкам доступа WiFi. Но это уже отдельная история.