{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Блог Ильи Бирмана: заметки с тегом безопасность", "_rss_description": "Блог Ильи Бирмана о дизайне, городах, музыке и жизни.", "_rss_language": "ru", "_itunes_email": "ilyabirman@ilyabirman.ru", "_itunes_categories_xml": "<\/itunes:category>\r\n<\/itunes:category>\r\n\r\n", "_itunes_image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic-square@2x.jpg?1573933764", "_itunes_explicit": "no", "home_page_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/bezopasnost\/", "feed_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/bezopasnost\/json\/", "icon": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764", "authors": [ { "name": "Илья Бирман", "url": "https:\/\/ilyabirman.ru\/meanwhile\/", "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764" } ], "items": [ { "id": "6657", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/standard-permissions-ui\/", "title": "Стандартное место для прав сайта или приложения", "content_html": "

Сайты и приложения бесят своими просьбами дать права на то и сё. В идеале бы запретить им это спрашивать вообще: если я захочу, я сам дам в настройке, а по умолчанию — нет, тебе нельзя знать моё положение, слать мне уведомления, использовать камеру и всё остальное. Проблема в том, что если так постановить, то большинство пользователей никогда не разберутся, как это включить, когда им это нужно, и они будут думать, что программа не работает.<\/p>\n

В результате используется такое решение. Когда сайт или приложение первый раз пытаются получить доступ к чему-то запретному, система спрашивает разрешения у пользователя. Таким образом, пользователю не приходится самому искать, где это включить. С другой стороны, если пользователь отказал, то второго шанса не будет, дальше уже если передумал — придётся искать. Таким образом, пользователю не приходится терпеть многочисленные переспрашивания.<\/p>\n

Конфликт в том, что мы с одной стороны хотим, чтобы пользователю было легко настроить то, что он сам хочет, а с другой — не бесить пользователя назойливостью сайта или приложения. Решение, которое используется — компромисс. Мы выбираем немножко бесить пользователя (один раз) и через это сделать настройку немножко проще (делаем её удобной тоже один раз).<\/p>\n

Предлагаю перейти от компромисса к нормальному решению. Для этого нужно обострить конфликт: никаких немножко и иногда; вместо этого мы хотим никогда<\/i> не бесить пользователя и чтобы настройка всегда<\/i> была лёгкой.<\/p>\n

Для этого вводим стандартное обозначения прав сайтов и приложений. Допустим, это будет щит, но это не важно. Вставляем его рядом с названием сайта в адресную строку всех браузеров:<\/p>\n

\n\"\"\n<\/div>\n

И куда-нибудь сюда во всех приложениях, но можно ещё дать способ показать внутри своего интерфейса тоже:<\/p>\n

\n\"\"\n<\/div>\n

Даём АПИ, чтобы подписать в окне настройки разрешений каждое разрешение объяснением того, зачем оно нужно. Всё, теперь сайт или приложение могут и в своём интерфейсе сколько угодно говорить, мол, чтобы работали видеозвонки, мне нужно доступ к камере; и в самом интерфейсе настройки под разрешением уведомлений уверять, что спамить не будут. Но не могут сами ничего попросить!<\/p>\n", "summary": "Сайты и приложения бесят своими просьбами дать права на то и сё. В идеале бы запретить им это спрашивать вообще", "date_published": "2026-02-14T12:10:45+05:00", "date_modified": "2026-02-14T12:12:30+05:00", "tags": [ "безопасность", "пользовательский интерфейс" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/site-rights@2x.jpg", "_date_published_rfc2822": "Sat, 14 Feb 2026 12:10:45 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6657", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/site-rights@2x.jpg", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/app-rights@2x.jpg" ] } }, { "id": "6350", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/volshebnye-ssylki-v-pismah-i-bezopasnost\/", "title": "Волшебные ссылки в письмах и безопасность", "content_html": "

Я разбирал интерфейс тупейшей регистрации Аэрофлота<\/a>. Человеку приходит письмо с напоминанием о регистрации, а переходя по ссылке он вынужден указывать почту для получения посадочного. Зачем? Аэрофлот знает мою почту — он же сам на неё только что письмо прислал, с которого я перешёл!<\/p>\n

Студентка школы бюро пишет (сокращаю):<\/p>\n

\n

В работе я сталкиваюсь с кейсами взаимодействия с пользователями через письма. При переходе на сайт для безопасности мы не подставляем данные пользователя, т. к. пользователь мог переслать письмо другим, не догадываясь, что его данные будут раскрыты при переходе по определённым ссылкам. Мы не одобряем автоматический вход в акаунты из писем, если это только не сценарий «Забыли пароль?». Нужно ли учитывать безопасность данных клиента или ею можно пренебречь, если утеря данных минимальна?<\/p>\n<\/blockquote>\n

Учитывать безопасность нужно, конечно. Но практика показывает, что чаще всего безопасность учитывается бездумно (отключается всё полезное, как бы чего не вышло) или вообще используется в качестве оправдания (забыли подумать, а когда попались — оправдались безопасностью).<\/p>\n

В данном случае перед нами пример второго: по ссылке из письма я уже могу зарегистрироваться на рейс безо всякой дополнительной аутентификации. Если я действительно перешлю это письмо, то другой человек сможет зарегистрировать меня без моего ведома, да ещё и прислать об этом письмо себе вместо меня. Где тут безопасность?<\/p>\n", "summary": "Я разбирал интерфейс тупейшей регистрации Аэрофлота. Человеку приходит письмо с напоминанием о регистрации, а переходя по ссылке он вынужден указывать почту для получения посадочного", "date_published": "2024-09-18T20:45:43+05:00", "date_modified": "2024-09-18T20:45:34+05:00", "tags": [ "безопасность", "пользовательский интерфейс" ], "_date_published_rfc2822": "Wed, 18 Sep 2024 20:45:43 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6350", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6078", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/plohoy-interfeys-v-ugodu-bezopasnosti\/", "title": "Плохой интерфейс в угоду «безопасности»", "content_html": "

Многие интерфейсные тупости объясняют требованиями безопасности. Иногда в этом есть смысл, а часто — нет. Например, нет смысла заставлять человека постоянно перелогиниваться<\/a>. В Эгее вот если вы залогинились, то вас никогда не разлогинит.<\/p>\n

Единственная потенциальная польза от разлогина — необходимость вспомнить пароль. Ведь если годами не логиниться, его забудешь. Если в вашем продукте важно не забыть пароль, об этом стоит подумать. Тут снова Телеграм молодец: он просто периодически предлагает тебе убедиться, что ты помнишь пароль, не разлогинивая тебя.<\/p>\n

А самое тупое требование «безопасности» — это требование периодически менять пароль. Это не только не повышает уровень безопасности, это его снижает, так как вынуждает человека придумывать очень предсказуемый пароль, чтобы самому с ума не сойти, пытаясь его вспомнить.<\/p>\n", "summary": "Многие интерфейсные тупости объясняют требованиями безопасности. Иногда в этом есть смысл, а часто — нет", "date_published": "2023-08-24T12:51:47+05:00", "date_modified": "2023-08-24T12:51:40+05:00", "tags": [ "безопасность", "пользовательский интерфейс" ], "_date_published_rfc2822": "Thu, 24 Aug 2023 12:51:47 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6078", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } } ], "_e2_version": 4269, "_e2_ua_string": "Aegea 12.0a (v4269e)" }