Цензура в PS5

<?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.

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