<?xml version="1.0" encoding="utf-8"?>
<network-security-config>

    <base-config
        cleartextTrafficPermitted="true">

        <trust-anchors>

            <certificates
                src="user" />

            <certificates
                src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

И в #Chrome, и в #Chromium для #Android вот такой конфиг. Если кому интересно, вот документация: https://developer.android.com/training/articles/security-config Самое важно для нас здесь вот это:

> <certificates src="user" />

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

Дело в том, что в Android 7 изменилось поведение по умолчанию. Теперь, если разработчик нарочно не переопределил поведение, приложение доверяет только системным сертификатам. Это означает, что даже если троян попадёт на устройство пользователя и добавит свой сертификат в доверенные для пользователя, то на Android 7+ (и таргет ещё нужен правильный, но в Маркет нельзя попасть с неправильным таргетом уже несколько лет), то MitM всё равно будет невозможен, т.к. добавить сертификат в системные может только производитель или приложение с рутовым доступом.

Но в Хромиуме и Хроме Гугл как раз явно разрешил доверие пользовательским сертификатам. Зачем — я не знаю. Это крайне странное решение, которое очень сильно бьёт по безопасности.

Приложение ebay на Android поддерживает тёмную тему, но ограниченно. Например, вот так выглядит снекбар:

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

Снято на тапок. Там написано:
"Заверит
ь"

Кажется, это Get Taxi

Я хочу немного понудеть над шуткой, но это всё-таки может быть полезно для других QA.

https://mastodon.ml/@zloygik/105603774792400273

Тестировщик заказал пиво в первую очередь. Это правильно, нужно сначала проверять типичные положительные сценарии. Я бы ещё проверил на коктейле, который требует наличия как можно большего количества разных ингредиентов плюс закусь. Мы ведь проверяем _бар_, это важно. Не здание, не бармена, а бар.

Тестировщик проверил всякие значения, тоже нормально. Я бы ещё проверил юникод (за пределами типичного для пользователя Win1251), запрещённые напитки, нормальные, но отсутствующие, ещё не расставленные, те, что были, но бутылки опустели и порцию напитка/коктейля, где сам напиток есть, но его объёма не достаточно для порции.

Есть ещё сценарии, где фильтры по полям. Например, заказ Хеннесси VS/VSOP/XO (и далее играть значениями полей), но это не проверка бара, а проверка напитков. Она делается отдельно и даже, возможно, другой командой. Ещё отдельные проверки бармена, его работы. Это снова не про бар.

Клиент выбрал туалет и случилось исключение. Виноват ли тестировщик? Если проверка здания на нём, то да. Если это делает другая команда, то нет. У многих (и у меня тоже) есть соблазн перепроверить за другими. Это не плохо, это полезно. Но когда у вас сроки и вы ещё свою работу не закончили, не надо лезть в чужую. Вы это делаете в ущерб своей.

Да вы все команда и в одной лодке. Но если лично вы будете тратить время на проверку за всеми, рискуете, что кто-то скоро начнёт находить ваши собственные пропуски. Потому что вы не успели сделать своё, или просто устали и не обратили внимание.

И не нужно думать, что "мелочи" у других можно проверить и это не дорого по времени. Казалось бы - туалет. Потратить 1 секунду в ущерб бару и всё, ерунда же. Но этих мелочей бесконечное количество. А если бы посетитель обратился к другому? А если бы сел за столик, а его нет? А если бы вошёл с собакой? А если бы это был пожарный инспектор?

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

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

Про UX. Если с компа зайти на https://twitter.com/ нажать UP вместо IN (в смысле регистрация вместо входа), то пробрасывает на страницу с запросом данных для регистрации. И в момент, когда вы поняли, что не то ткнули, хочется исправить ошибку. По привычке я нажимал Esc и кликал мимо формы ввода, но это не помогало.

Здесь нужно нажимать Back в браузере. То есть обычно, в т.ч. в Твиттере, на других страницах, нажатие Назад всё сломает, ведь веб сегодня весь такой динамический. Но вот именно здесь нужно только Назад нажимать. Ну, либо, руками править адрес в поле ввода.

УДОБНО.

Неожиданно

Ошибка документации: https://developer.android.com/reference/android/content/Intent#ACTION_AUTO_REVOKE_PERMISSIONS

> Activity action: Launch UI to manage auto-revoke state. This is equivalent to Intent#ACTION_APPLICATION_DETAILS_SETTINGS


На самом деле этот экшен живёт не в Intent, а в Settings: https://developer.android.com/reference/android/provider/Settings#ACTION_APPLICATION_DETAILS_SETTINGS

Альфабанк такой "мои утечки — это ваши проблемы"

С персданными вообще пушка, конечно. Реклама, местонахождение, 10 лет после закрытия отношений — всё разрешать должен

Прошу прощения, удалил сообщение с описанием ошибки Твиттера. Мне подсказали, что это уязвимость и стоит их уведомить. Ну что же, записал видос с воспроизведением. Будет переопубликовано, когда Твиттер ответит, что это чепуха или что это исправлено.

Что-то замотался и забыл. В общем, суть такова.

1. Алиса использует 2FA в Twitter, чтобы защитить свою учётную запись
2. Боб знает её логин и пароль, но не может попасть в её учётку, т.к. она защищена 2FA. Он ведь для этого и нужен, не так ли?
3. Алиса деактивирует свою учётную запись по любой причине — это её дело
4. Боб обнаруживает это
5. Боб заходит под её логином и паролем, активирует учётную запись обратно и выкачивает все её данные (есть такая фича у Твиттера — выгрузка данных)

Твиттер принудительно отключает 2FA при деактивации учётной записи, что даёт атакующему целый месяц на то, чтобы обнаружить это и утащить данные. Твиттер пишет письмо, если учётка была активирована снова, но:
1. Атакуемый может не проверять почту долгое время
2. Атакующий может сделать это, когда атакуемый заведомо не может использовать почту, например он спит
3. Как бы вообще пофиг на уведомительное письмо, когда данные уже скачали

Это поведение Твиттер не считает ошибкой, о чём мне ответили на hackerone. Так что пишу об этом с чистой совестью.

We appreciate your suggestion and may look into making this change in the future, but at the moment, we consider this to be a Defense-In-Depth measure. This behavior's security risk is largely mitigated by the fact that the attacker must know the victim's password or have access to the victim's registered email and specifically target their account during its deactivation period. For these reasons, we will be closing this report as Informative. We do appreciate your efforts here, and we hope you continue reporting security issues to us in the future.

Яндекс Маркет, дамы и господа

СЯУ, как мой роутер понимает, что телефоны используют рандомизацию МАК адреса.

Делает он это элементарно. Можете проверить на своих устройствах. На моих (iPhone, iWatch, Pixel 4 XL, Pixel 4a, Pixel 5, Samsung M20) всё так и оказалось

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

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

Также полагали и владельцы смартфонов немецкой компании GigaSet, которая ранее работала под брендами Siemens Mobile и BenQ-Siemens и была одним из крупнейших производителей мобильных телефонов в начале 2000-х годов до эры смартфонов.

В минувшую пятницу пользователи девайсов на базе Android забросали форумы поддержки Google сообщениями о сбоях работы и дистанционной установке на устройствах приложении без ведома их владельцев. Упоминалось, что телефоны превращались в своего рода «скайнет» и начинали производить различные манипуляции с браузерной рекламой, сервисом SMS и сообщений WhatsApp. Более глубокий анализ инцидентов свидетельствует о краже личной информации и компрометации пользовательских аккаунтов Facebook.

Как выяснили Gigaset хакеры получили доступ к серверу обновлений и развернули вредоносное ПО. И несмотря на доводы компании о том, что инцидент затронул не всех пользователей, а только тех, кто получил обновления прошивки с одного конкретного сервера, владельцам устройств все же следует задуматься об безопасности личных данных, хранившихся в памяти скомпрометированных устройств.

Владельцам моделей GS110, GS185, GS190, GS195, GS195LS, GS280, GS290, GX290, GX290 plus, GX290 PRO, GS3 и GS4 можно не переживать - им удалось избежать атаки.

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