Почему Windows показывает сообщение «Windows защитил ваш компьютер»

SmartScreen, подпись кода, сертификаты EV/OV, распространение через MSIX и Store — с практической стороны

Когда Windows-приложение начинают распространять, почти сразу встречается такое предупреждение.

Windows защитил ваш компьютер
Microsoft Defender SmartScreen предотвратил запуск неопознанного приложения.

Пользователи начинают беспокоиться. Разработчики тоже: «это же не вирус, почему его останавливают?», «код подписан, почему предупреждение всё равно есть?».

В статье разбираем предупреждение SmartScreen при распространении Windows-приложения: подпись кода, сертификаты EV/OV, MSIX, Microsoft Store, ClickOnce и внутреннее распространение.

1. Эта статья в двух словах

При распространении Windows-приложения подпись кода нужна.
Но подпись кода — не волшебство, которое гарантированно снимает предупреждение SmartScreen.

Важно смотреть на три вещи по отдельности.

Грубый ориентир для выбора такой.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 20, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. SmartScreen — это не только «проверка на вирусы»

Когда появляется предупреждение SmartScreen, пользователь думает: «это опасное приложение?»

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

Главное здесь: у только что созданного файла репутации ещё нет.

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

Проще понимать предупреждение SmartScreen так:

Это не значит, что файл признан вредоносным.
Но это значит, что Windows пока не считает его достаточно надёжным.

Если не провести эту границу, появляются заблуждения вроде «подписал — а ничего не изменилось» или «купил сертификат EV — а ничего не поменялось».

3. Что на самом деле гарантирует подпись кода

Подпись кода гарантирует в основном две вещи.

1. Файл подписан тем издателем, который отображается
2. После подписи файл не изменяли

И наоборот, напрямую она этого не гарантирует.

• Что приложение абсолютно безопасно
• Что в приложении нет дефектов
• Что предупреждение SmartScreen никогда не появится
• Что корпоративная политика его обязательно разрешит

Тем не менее подпись кода почти обязательна.

Без подписи пользователь не видит издателя. В корпоративной среде неподписанный файл могут остановить App Control, EDR, Defender, прокси и почтовый шлюз. Если вы делаете автообновление, подпись нужна и для того, чтобы проверить, что файлы обновления подлинные.

Иными словами, подпись кода нужна не только «чтобы снять предупреждение». Это основа распространения, обновлений, аудита и корпоративного внедрения.

4. «С сертификатом EV предупреждение пропадает с первого раза» — устаревшее представление

Раньше было широко распространено мнение, что сертификат EV для подписи кода даёт преимущество в SmartScreen.

Сейчас покупать сертификат EV только ради обхода SmartScreen как минимум рискованно. В документации Microsoft для разработчиков SmartScreen reputation for Windows app developers прямо сказано: «сертификаты EV больше не обходят SmartScreen» и «платить премию за EV только ради обхода предупреждений SmartScreen больше не оправдано». В таблице по типам сертификатов на той же странице OV и EV сведены в одну строку «действительный сертификат (OV/EV)», а поведение при первой загрузке описано как «предупреждение, пока не накопится репутация». Файлы с подписью EV нужно рассматривать так же, как файлы с сертификатом OV: репутация накапливается.

Это не значит, что сертификат EV совсем бессмыслен.

• При корпоративных закупках выше ценят более строгую проверку личности
• Проверка безопасности у партнёра требует EV
• Сертификат EV уже есть, и его продолжают использовать

Если такие причины есть, пользоваться им можно.

Но покупать сертификат EV только ради этой цели не стоит.

Купить сертификат EV, чтобы предупреждение SmartScreen пропало с первого дня

Если цель именно такая, сначала пересмотрите канал распространения, способ подписи, объяснение для первых пользователей, частоту обновлений и возможность выпуска через Store.

5. Варианты подписи

Разберём варианты подписи и распространения, которые чаще всего встречаются при выпуске Windows-приложения.

Microsoft Store / MSIX

Если приложение идёт обычным пользователям, первым делом стоит рассмотреть Microsoft Store.

Связка MSIX и распространения через Store особенно выгодна с точки зрения управления сертификатами и предупреждений SmartScreen. Пакеты MSIX, отправленные в Store, Microsoft переподписывает у себя, поэтому разработчику меньше нужно самому покупать и продлевать сертификат.

Но не каждое Windows-приложение хорошо ложится на MSIX.

• Глубоко использует службы Windows
• Нужны драйверы
• Есть shell extension
• Есть старая регистрация COM или наследие ActiveX
• При установке нужны сложные изменения ОС

В таких случаях естественнее MSI или традиционный установщик, чем MSIX.

Azure Artifact Signing

Azure Artifact Signing — облачная служба подписи кода от Microsoft. Раньше она называлась Trusted Signing; сейчас официальное имя — Azure Artifact Signing (Artifact Signing). На странице продукта Microsoft тоже пишет «Artifact Signing (formerly Trusted Signing)». Старое имя до сих пор часто встречается в статьях и внутренних материалах, поэтому ищите по обоим названиям. Официальная документация: Microsoft Learn: What is Artifact Signing? и Azure: Artifact Signing (formerly Trusted Signing).

Плюс в том, что не нужен физический USB-токен и службу проще встроить в CI/CD. Для подписи при распространении вне Store это сильный вариант, но есть ограничения по регионам и типу учётной записи.

По материалам Microsoft на 2026 год для организаций доступны США, Канада, ЕС и Великобритания, для индивидуальных разработчиков — США и Канада. Если вы юридическое или физическое лицо в Японии, обязательно проверьте условия. Если воспользоваться нельзя, реалистичный кандидат — обычный сертификат OV для подписи кода.

Кроме того, подпись через Azure Artifact Signing не даёт доверие SmartScreen сразу. Как и с сертификатом OV, репутация накапливается по факту распространения.

Сертификат OV для подписи кода

Для разработчиков и компаний в Японии, которые распространяют Windows-приложение вне Store, сертификат OV для подписи кода и сейчас реалистичный выбор.

С сертификатом OV пользователь видит имя издателя. Это явно лучше, чем отсутствие подписи. Но у нового приложения и нового файла предупреждение SmartScreen всё же может появиться.

Если пользуетесь сертификатом OV, имеет смысл держать в уме следующее.

• Пользоваться одним и тем же именем издателя
• Каждый раз подписывать от имени того же издателя
• Не менять файл после подписи
• Ставить метку времени
• Проверять не только EXE, но и DLL, MSI, updater
• Подготовить план перехода на момент продления сертификата

Самоподписанный сертификат

Самоподписанный сертификат удобен для разработки и проверки.

Для публичного распространения он в основном непригоден. С точки зрения Windows пользователя этот сертификат не доверенный.

Самоподписанный сертификат уместен в таких средах:

• локальный ПК разработчика
• проверочная среда у тестировщика
• корпоративные машины, куда доверенный сертификат можно раздать через Intune или GPO
• изолированная сеть, где конфигурацию устройств полностью контролируют

Даже с самоподписанным сертификатом нужно вести учёт: когда его удалить, кто положил его в доверенные, не попадёт ли он в продуктивную среду.

6. Что на практике нужно подписывать

«Подписал EXE — и готово» — так это не работает.

При распространении Windows-приложения проходят весь набор объектов подписи.

Если пользуетесь SignTool, в текущем Windows SDK важны параметры /fd и /td. Обычно указывают SHA256.

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a .\MyApp.exe
signtool verify /pa /v .\MyApp.exe

Смысл параметров такой.

URL сервера меток времени берите тот, который указывает издатель сертификата. В примерах документации Microsoft по SignTool используется http://timestamp.digicert.com, в процедуре подписи Artifact Signing — https://timestamp.acs.microsoft.com. Если поставить метку времени, фиксируется, что на момент подписи сертификат был действителен, и подписью можно пользоваться после истечения срока сертификата.

Как указывать сертификат, зависит от среды.

Часто пропускают вот что: без /sm SignTool смотрит только личное хранилище пользователя, от имени которого запущена команда. Типичные случаи «сертификат не находится»: сертификат положили в хранилище «Локальный компьютер», а /sm не указали; сборка идёт от служебной учётной записи, а сертификат лежит в личном хранилище другого пользователя. Если подписываете в CI, сначала зафиксируйте, в каком хранилище какой учётной записи лежит сертификат.

Что подпись получилась, проверяют по трём пунктам.

• signtool verify /pa /v .\MyApp.exe завершается успешно
• код выхода этой команды равен 0 (в PowerShell сразу после неё смотрите $LASTEXITCODE)
• в свойствах файла в Проводнике на вкладке «Цифровые подписи» видны издатель и метка времени

Главное — подписывать конечный артефакт.

Если после подписи переписать EXE, подменить файл внутри ZIP или изменить встроенный файл после сборки установщика, подпись может сломаться, а результат проверки — разойтись с ожиданием.

В конвейере сборки этот порядок фиксируют.

Сборка
  ↓
Сбор зависимых файлов
  ↓
Создание установщика / пакета
  ↓
Подпись
  ↓
Проверка подписи
  ↓
Запись хешей
  ↓
Распространение

7. Подход в зависимости от способа распространения

Установщик MSI / EXE

Если распространяете установщиком MSI или EXE, обязательно подписывайте файл, который пользователь запускает первым.

Дополнительно пересмотрите как объекты подписи EXE и DLL, которые раскладываются после установки. Даже если подписан только установщик, неподписанный updater или helper после установки в корпоративной среде могут остановить.

Круг вопросов в целом один и тот же.

• Подписать сам установщик
• Подписать и вложенные EXE/DLL
• Вынести в отдельный процесс операции, которым нужно повышение через UAC
• Аудировать updater и service helper отдельно
• Держать стабильным URL страницы загрузки
• Сообщать имя издателя первым пользователям

MSIX

MSIX — способ с сильной целостностью на уровне пакета.

Если можно выпускать через Store, с предупреждениями SmartScreen и управлением сертификатами становится заметно проще. С другой стороны, при внутреннем sideload или распространении вне Store нужно отдельно спроектировать подпись пакета MSIX и доверие к сертификату.

На что смотреть:

• для разработки и проверки самоподписанный сертификат допустим
• для распространения в продуктивной среде используйте публично доверенный способ подписи
• Publisher в appxmanifest должен совпадать с Subject сертификата
• при распространении вне Store закладывайте, что предупреждение SmartScreen возможно
• заранее проверьте, нет ли интеграции с ОС, с которой MSIX плохо совместим

ClickOnce

ClickOnce удобен, когда .NET-приложение вроде WinForms/WPF нужно раздавать стандартным пользователям.

Но сам факт ClickOnce проблему SmartScreen не снимает. Имеют значение путь, по которому пользователь скачивает и запускает приложение, подпись манифеста, источник распространения и изменение файлов при обновлении.

В ClickOnce проверяют примерно следующее.

• Подпись манифеста приложения и манифеста развёртывания
• Управление URL распространения или общей папкой
• Как обрабатывается смена сертификата при обновлении
• Не останавливают ли внутренний прокси или Defender
• Объяснение пользователю при первой установке

Сильная сторона ClickOnce — «легко раздавать». Но если не спроектировать доверие к издателю и канал распространения, на местах приложение останавливается.

Распространение через xcopy / ZIP

«Просто положить папку» или «распаковать ZIP» — простой способ.

В изолированной сети или для внутреннего инструмента он иногда уместен. Но для веб-раздачи обычным пользователям это как раз тот способ, который сильнее всего задевают SmartScreen, Defender и Mark of the Web.

Mark of the Web (MOTW), о котором здесь речь, — это альтернативный поток данных Zone.Identifier, который браузер или почтовый клиент прикрепляет к скачанному файлу. Это метка «файл пришёл из интернета»; по ней работают проверка SmartScreen, блокировка макросов в Office, политика выполнения PowerShell (RemoteSigned) и другое. Метку снимают флажком «Разблокировать» в разделе «Безопасность» свойств файла в Проводнике или командлетом PowerShell Unblock-File. Переносится ли метка на файлы внутри ZIP при распаковке, зависит от программы, которой распаковывали. Подробнее — в главе «Zone.Identifier (Mark of the Web) и Unblock-File» статьи «Политика выполнения PowerShell и подпись скриптов».

Если выбираете xcopy, это лучше соблюдать.

• Подписывать EXE/DLL
• Не полагаться только на ZIP — проверять содержимое файлов
• Зафиксировать источник распространения
• Явно указывать версию, хеш, историю изменений
• Если позже добавляете автообновление, встроить в него проверку подписи

Думать стоит не «без установщика проще», а «ответственность установщика берём на себя».

Собственный updater

Свой updater удобен, но это и есть граница безопасности.

Updater получает новые файлы и подменяет существующие. Иногда он работает с правами администратора. Если здесь что-то ломается, это опаснее самого приложения.

Как минимум проверьте следующее.

• Подписывать метаданные обновления
• Включать в метаданные version, hash, size, channel, expiry
• После загрузки проверять hash и подпись
• При неудачной проверке останавливаться по принципу fail-closed
• Подготовить процедуру отката
• Определить, как обновляется сам updater
• Отделить продуктивный ключ подписи от среды разработки

Эту тему проще держать вместе со статьёй «Безопасность автообновления».

8. Для внутреннего распространения одного SmartScreen мало

Во внутренних приложениях часто встречается заблуждение:

Раз пользуемся только внутри компании, подпись не нужна

Это опасно.

Во внутренней среде задействован не только SmartScreen, а целый набор механизмов.

Особенно в среде с App Control for Business важно не только «подписан ли файл», но и «разрешён ли этот издатель», «пришёл ли файл через managed installer», «разрешены ли хеш или путь».

В руководстве Microsoft по развёртыванию тоже описан подход: изменения политики App Control сначала выкатывают в режиме аудита, проверяют, что события блокировки совпадают с ожиданиями, и только потом расширяют принудительный режим.

Для внутреннего распространения реалистично проектировать в таком порядке.

1. Разделить целевые устройства
   - разработчики
   - тестировщики
   - отдельные подразделения
   - вся компания

2. Определить канал распространения
   - Intune
   - GPO + общая папка
   - внутренний портал
   - VDI / RemoteApp
   - ручная раздача в изолированной сети

3. Определить правила доверия
   - правила по издателю
   - распространение сертификатов
   - managed installer
   - разрешение по хешу
   - разрешение по пути

4. Проверить в режиме аудита
   - что блокируется
   - какие DLL или helper пропущены
   - не воспринимается ли обновление как другой файл

5. Развернуть поэтапно
   - раздать в малом масштабе
   - смотреть журналы
   - подправить правила разрешений
   - расширять

Суть внутреннего распространения — не обойти SmartScreen, а сделать канал распространения таким, который Windows может объяснить.

9. Частые заблуждения и правильный взгляд

10. Как объяснить ситуацию пользователям при первом выпуске

У нового приложения предупреждение SmartScreen может появиться в первые недели и у первых пользователей.

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

Что стоит положить в разъяснение:

• официальный URL загрузки
• отображаемое имя издателя
• имя файла
• номер версии
• дату выпуска
• при необходимости — хеш SHA-256
• как убедиться, что файл подписан
• не запускать файлы, полученные неизвестным путём

Например, для внутренних пользователей безопасно такое разъяснение:

Это приложение распространяется только со следующей страницы внутреннего портала.
Убедитесь, что отображаемое имя издателя — «ООО ХХХ».
Не запускайте EXE, пересланные вложением в почте или в чате.
Если появилось предупреждение SmartScreen, покажите экран сотрудникам ИТ-отдела.

Для обычных пользователей либо отдайте приоритет Microsoft Store, либо разместите на странице загрузки объяснение, как проверить издателя.

Что нажимать на экране предупреждения

В материалах для пользователей стоит расписать, куда они будут нажимать. В диалоге SmartScreen в исходном состоянии доступна только кнопка «Не выполнять». Чтобы запустить приложение, действуют так.

Диалог «Windows защитил ваш компьютер»
  → выбрать «Подробнее»
  → отображаются имя приложения (имя файла) и издатель
  → нажать кнопку «Выполнить»

В документации Microsoft для разработчиков тоже сказано, что для неподписанного файла «чтобы запустить приложение, нужно выбрать „Выполнить“». В разъяснении важно не только описать эти два шага, но и попросить сверить имя издателя, которое показывается по пути, со своим. Если издатель — «Неизвестный издатель», файл либо не подписан, либо подпись сломана.

Кроме того, корпоративная политика иногда отключает само «Выполнить», и дальше пройти нельзя. Во внутреннем разъяснении к этому случаю добавляйте контакт.

Ориентир, когда предупреждение пропадёт

«Сколько нужно раздать, чтобы предупреждение пропало» спрашивают часто, но Microsoft конкретный порог не публикует. В документации для разработчиков сказано: «точного порога нет, но иногда нужны недели и сотни чистых установок у широкой аудитории». Там же прямо указано следующее.

• На устройствах обычных пользователей нет механизма вручную подать файл на репутационный разбор; репутация накапливается по факту загрузок
• Корпоративный ИТ-администратор может подать файл через портал Microsoft Security Intelligence. Во внутреннем распространении и на управляемых устройствах это иногда ускоряет получение доверия
• Если продолжать подписывать одним и тем же сертификатом, растёт репутация сертификата, и у новой версии предупреждение появляется реже. Неподписанный файл при каждом обновлении начинается с нуля

Иными словами, реалистично готовить разъяснение к первому выпуску из расчёта «какое-то время предупреждение будет» и продолжать распространение, не меняя сертификат и имя издателя.

11. Схема принятия решения

Когда выбираете способ распространения, меньше путаницы, если идти в таком порядке.

flowchart TD
    A[Распространить Windows-приложение] --> B{Для обычных пользователей?}
    B -->|Да| C{Можно ли выпустить в Microsoft Store?}
    C -->|Да| D[Отдать приоритет Store / MSIX]
    C -->|Нет| E[Подписать сертификатом OV или через Artifact Signing]
    B -->|Нет, для внутреннего использования| F{Есть управление устройствами?}
    F -->|Есть Intune/GPO| G[Подпись + распространение сертификатов + аудит App Control]
    F -->|Управления нет| H[Фиксированный источник + подпись + разъяснение пользователям]
    E --> I[Закладывать начальные предупреждения SmartScreen]
    G --> J[Поэтапное развёртывание начиная с режима аудита]
    H --> J

Первый практический кандидат можно свести так.

12. Минимальный чек-лист

Что проверить перед публикацией и распространением Windows-приложения.

Подпись

• EXE подписан
• DLL подписаны
• MSI или EXE установщика подписан
• updater подписан
• поставлена метка времени
• файл не переписывали после подписи
• проверено через signtool verify

Распространение

• определён официальный URL распространения
• на странице загрузки указано имя издателя
• указаны номер версии и дата выпуска
• заложена вероятность начальных предупреждений SmartScreen
• рассмотрена возможность выпуска в Microsoft Store
• при распространении вне Store рассмотрены сертификат OV или Artifact Signing

Обновления

• файлы обновления тоже подписаны
• в своём updater метаданные подписаны
• проверяются hash, size, version
• при ошибке остановка по принципу fail-closed
• есть процедура отката

Внутреннее распространение

• проверено наличие Intune / GPO / App Control
• определён способ распространения сертификатов
• в режиме аудита смотрели события блокировки
• развёртывание идёт поэтапно по подразделениям
• проверено, что обновление не блокируется повторно

13. Итог

Windows-приложение нельзя «сделать и забыть»: распространяемые файлы должны быть в виде, которому могут доверять Windows, пользователи и корпоративная политика.

Что стоит держать в уме:

• SmartScreen смотрит на репутацию файлов и издателей
• подпись кода нужна, но нулевое число предупреждений не обещает
• сертификат EV не выбирают ради мгновенного обхода SmartScreen
• для массового распространения сначала рассматривайте Microsoft Store / MSIX
• вне Store используйте сертификат OV или Artifact Signing и закладывайте начальные предупреждения
• при внутреннем распространении смотрите не только SmartScreen, но и Intune, GPO, App Control
• updater проектируйте не как функцию распространения, а как границу безопасности продукта

Одной фразой:

Распространение Windows-приложения — это не вопрос «куда положить», а проектирование того, как добиться доверия со стороны Windows.

Также рекомендуем прочитать

• Как выбрать способ распространения Windows-приложения — MSI/MSIX/ClickOnce/xcopy/свой updater
• Что такое ClickOnce — как устроен, как обновляется, где подходит и где нет
• Безопасность автообновления: почему одного HTTPS недостаточно
• Минимальный чек-лист безопасности при разработке Windows-приложений
• Когда в Windows нужны права администратора — UAC, защищённые области и как это отличить на этапе проектирования
• Распространение Windows-приложения одним файлом — single binary и пределы зависимости от ОС

Справочные ссылки

• Microsoft Learn: SmartScreen reputation for Windows app developers
• Microsoft Learn: Code signing options for Windows app developers
• Microsoft Learn: What is Artifact Signing? — обзор Azure Artifact Signing (прежний Trusted Signing) и действующее официальное имя.
• Microsoft Learn: Sign your MSIX package - end-to-end guide
• Microsoft Learn: SignTool.exe
• Microsoft Learn: Deploying App Control for Business policies
• Microsoft Learn: Manage approved apps for Windows devices with App Control for Business policy and Managed Installers in Microsoft Intune

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему появляется предупреждение «Windows защитил ваш компьютер»?

Потому что Microsoft Defender SmartScreen ещё не считает этот файл достаточно надёжным. SmartScreen — это не простая проверка на вирусы: он смотрит на репутацию издателя, репутацию хеша файла, наличие подписи и канал распространения. С точки зрения Windows только что созданный файл — «файл, который система видит впервые», поэтому даже подписанный файл может вызывать предупреждение, пока не накопится репутация. Это не значит, что файл признан вредоносным. Это значит, что Windows пока не считает его достаточно надёжным.

Исчезнет ли предупреждение SmartScreen, если подписать код?

Не обязательно. Подпись кода гарантирует только две вещи: файл подписан тем издателем, который отображается, и после подписи файл не изменяли. Нулевое число предупреждений она не обещает. Даже при подписи предупреждение может появляться, пока репутация файла или издателя недостаточна. Тем не менее подпись кода почти обязательна как основа распространения, обновлений, аудита и корпоративного внедрения. Без подписи в корпоративной среде файл могут остановить App Control, EDR или Defender.

Если купить сертификат EV, предупреждение SmartScreen пропадёт с первого запуска?

Это устаревшее представление. По текущим материалам Microsoft сертификат EV больше не обходит предупреждение SmartScreen при первой загрузке автоматически; файлы с подписью EV, как и файлы с сертификатом OV, должны накапливать репутацию. Смысл в EV есть, если его требуют закупочные процедуры или проверка безопасности у партнёра. Покупать сертификат EV только ради обхода SmartScreen не стоит. Для этой цели сначала пересмотрите канал распространения, способ подписи и возможность выпуска через Store.

Как распространять приложение, чтобы предупреждений SmartScreen было меньше?

Если приложение идёт широкой аудитории обычных пользователей, сначала рассмотрите Microsoft Store / MSIX. Пакет MSIX, отправленный в Store, Microsoft переподписывает у себя, и с точки зрения SmartScreen это обычно самый стабильный канал. Если Store недоступен, подписывайте сертификатом OV или через Azure Artifact Signing, закладывайте, что на старте предупреждения возможны, и сообщайте пользователям официальный URL загрузки, имя издателя, версию и хеш. Для внутреннего распространения одной подписи мало: канал нужно проектировать вместе с Intune / GPO / App Control.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.