Командная строка Windows вместо интерфейса выдачи посылок появилась на экране одного из ирландских локеров OOHPod. Клиент смог развернуть окно касанием, однако ввести команды не удалось: экранная клавиатура не появилась, а следующий тап вернул штатный интерфейс. Для операторов киосков, терминалов и устройств самообслуживания это маленький, но очень наглядный инцидент: публичный экран не должен давать пользователю даже намёка на доступ к рабочей среде ОС.
Об этом сообщает The Register со ссылкой на читателя, приехавшего за посылкой. Сервис OOHPod использует ячейки для приёма и выдачи отправлений: пользователь сканирует идентификатор либо вводит данные на сенсорном дисплее, после чего открывается нужная дверца. В этот раз вместо привычного экрана посетитель увидел пустое поле и свёрнутое окно, похожее на консоль. После нажатия на него на дисплее появилась командная строка Windows.
Сценарий мог оказаться заметно неприятнее. Открытая консоль на терминале, доступном прохожим, обычно воспринимается как приглашение проверить права текущей учётной записи, конфигурацию сети и файловую систему. В данном случае читатель не смог вызвать клавиатуру и не увидел разъёма, к которому можно было бы подключить периферию. Это ограничило последствия неловким визуальным сбоем. Но сам факт появления системного окна означает, что приложение выдачи посылок либо его окружение не удержали пользовательский интерфейс в заданных границах.
Для Windows-устройств в режиме киоска это базовое требование. Пользователь должен быть заперт в одном разрешённом приложении, а системные сочетания клавиш, панели, проводник, диспетчер задач, сообщения об ошибках и оболочка командной строки — отключены или недоступны. Иначе сбой прикладной программы быстро превращается из проблемы UX в потенциальный инцидент безопасности. Особенно если терминал подключён к корпоративной сети, работает с API, хранит журналы или использует сервисную учётную запись с избыточными правами.
Судя по описанию, клиент не пытался использовать консоль и просто восстановил штатный экран повторным касанием. Это ответственная реакция, хотя техническое любопытство в такой ситуации почти гарантировано: многие администраторы и разработчики первым делом захотят узнать, под какой учётной записью запущен процесс и можно ли выбраться из ограниченного режима. Оператору сервиса повезло, что интерфейс не предоставил способа ввода. Полагаться на это как на защиту нельзя: физический доступ к публичному терминалу всегда нужно считать враждебной средой.
У истории есть и практический урок для команд, которые внедряют самообслуживание. Тестирование киоска нельзя ограничивать успешным сценарием «отсканировал код — открыл дверцу». Нужны проверки перезапуска приложения, потери сети, обновления ОС, зависания интерфейса, всплывающих системных диалогов и поведения после непредвиденного касания. Отдельно стоит проверить, не остаётся ли доступным проводник, контекстные меню, экранная клавиатура в неожиданных режимах, USB-порты и горячие клавиши. Ключевой вопрос не в том, умеет ли приложение работать, а в том, что увидит пользователь, когда оно перестанет работать.
Командная строка Windows на экране локера не стала взломом и не сорвала выдачу посылок, но хорошо показывает цену мелкой недоработки в публичном устройстве. Чем больше бизнес переносит операции в постаматы, терминалы, цифровые витрины и киоски, тем важнее проектировать отказ так же тщательно, как основной пользовательский путь. Пользователь не обязан знать, что такое cmd.exe; он должен видеть только понятное сообщение о проблеме — и никогда не получать шанс выяснить, что находится за ним.