Железки и софт (будут) прибиты к резолверам вендора, тогда как адреса обычных DNS обычно ISP или админ локалки раздает через DHCP.
Это ведет к нескольким проблемам:
Зависимость от сервисов вендора, которые имеют свойство ложиться
Зависимость от отключения данных сервисов т. е. еще одна точка программного устаревания
Дополнительная утечка данных к вендору (что может быть хуже, чем к VPN провайдеру/хостеру или ISP). И телеметрия не нужна.
И ладно бы это было как-то нормально конфигурируемо, в хорошем случае это будет что-то уровня "очевидного" ключа network.trr.uri в about:config или реестре, в худшем вхардкожено в прошивку.
В большинстве случаев предусмотрен fallback на обычный DNS. А в некоторых регионах DoH вообще включать не будут потому, как там это приведёт к проблемам.
Хороший пример — Великобритания, где и правительство очень расположено к цензуре, и провайдерам интереснее зарубить эту инициативу на корню, чтобы оттянуть "роскомнадзоровский" сценарий блокировок по IP на годы
Позвольте нагнести:
Все эти "программисты на C++ за 21 час" и даже выпускники курсов "приличных" курсов "приличных" компаний обычно совершенно никакие. Это просаживает уровень среднего, что в свою очередь всерьез приводит к понижению ожиданий считающих себя средним хороших специалистов с синдромом самозванца. А чтобы в такой ситуации раскрыть глаза, надо набить очень много шишек.
Ситуация вообще довольно печальная с этим всем.
Еще во времена 4.x (и отчасти даже раньше) было несколько типов хранилища:
/data/data/<package_name> (0)
/sdcard/Android/data/<package_name> как External...Dirs (1)
/sdcard/Android/obb/<package_name> как ObbDirs (2)
/sdcard/ (и до 4.4 внешние носители) как внешнее хранилище (3)
В сущности правильным поведением было хранить данные в (0), допустимым в (1) и нежелательным (кроме как для медиафайлов и всего, что необходимо выставлять пользователю) в (3).
Но почему-то многие разработчики упорно не следуют этому и хранят кэши в /sdcard/.appname или даже /sdcard/Appname/...Cache, что отчасти и вызывает описанные уязвимости.
В 4.4 из (3) убрали внешние карточки и флешки, переведя доступ к ним на запись с линуксового на уродливый SAF, так что разработчикам всяких галерей и файловых менеджеров пришлось добавлять прямо в приложения инструкции по разрешению доступа к карточкам памяти.
В Q Google пытаются расширить эту модель и на /sdcard, что, пожалуй, имеет плюсы в том, что лишний мусор из /sdcard/ исчезнет, да и разруливать доступ к чувствительным файлам (не из числа фото/видео/аудио) станет проще.
Однако часть проблем с MitD решить не удастся: для работы с любыми другими файлами (pdf, книги, специфичные форматы в т.ч. сертификаты, ЭП) приложения будут обоснованно требовать доступ к /sdcard через SAF, а значит загрузки (те же упомянутые ЭП и сертификаты) все равно останутся под риском перезаписи.
Гораздо печальнее, что это ещё больше удаляет Android от человека, желающего действительно владеть собственным устройством.
Потеряется:
Доступ без рута к ряду служебных файлов приложений (может быть полезен)
Отвалятся приложения с работой с файлами на системных вызовах
Как подмножество предыдущего отвалятся CLI-инструменты, работающие под эмулятором терминала или Termux
Могут появиться прецеденты хранения документов в /data/data на манер iOS, что очень больно.
Возможно, это только мои проблемы, но в последнее время Гугл регулярно ломает те мелочи, которые важны лишь небольшим группам пользователей, в числе которых часто оказываюсь и я.
Мне кажется, что это возникло из заведомо опасного предположения, что наличие вредоносного ПО на устройстве это совершенно естественно, и любые урезания прав и возможностей пользователя быть владельцем своего устройства абсолютно оправданы.
И, похоже, исходя из этого же функции слива данных пользователя, присутствующие в большей части популярных "официальных" приложений, почти всегда принимается нормально.
С использованием URL Scheme, обработчики которой зарегистрированы в системе. У Telegram это tg
Скриншот
Chrome/Chromium схожим образом показывает диалог подтверждения открытия ссылки в "Telegram Desktop" на Windows и в "xdg-open" в Иксах (Linux).
Далее этот URL в качестве параметра передается приложению, которое решает, что дальше делать.
Помню, одной из претензий Qualcomm к Apple было занижение параметров их модемов до уровня аналогичных от Intel, когда и те и другие ставились в одну модель айфона.
А это было года 2 назад, во времена LTE.
Так что модемы Qualcomm просто все ещё лучше аналогов.
Остальной код — это Chromium. Так что доступность просмотра кода не зависит от лицензии.
Но никаких аргументов в пользу того, что конкретно ваш Chromium в открытую не сливает данные в "одну известную компанию", как это делают оригинальные сборки чистого Chromium, а может и какую-нибудь другую, менее известную компанию, нет никаких.
\end {zanuda mode}
Если говорить о контроле, честным вариантом было бы обеспечение вменяемой воспроизводимости сборок из вашего патченного Chromium и проприетарных HTML, CSS и JS (в идеале не обфусцированного)
В какой-то момент полосатый оператор, у которого бан адресов гуглом — хроническое, начал выдавать белую динамику, уже находящуюся в списке на момент раздачи на роутер.
Для работы с основным контентом сайта эта задача решается элементарно.
В современных Firefox (особенно с патчами Tor Browser) это решается сравнительно несложно. Необходимо только вынести код вывода режима чтения наружу и не применять к нему ограничения по разрешению.
А вот со всяким сопутствующим контентом проблема. Отваливаются поиски, отваливаются комментарии, карты, интерактивности и всё такое. И происходит это потому, что каждый сам велосипедировал всё это на различных фреймворках из чего только можно без малейших попыток стандартизации хотя бы даже того, как это будет в итоге рендериться. Где-то из-за непонимания того, как это работает, где-то из желания сделать всё "удобным" (чего стоит переопределение ctrl+f на одном из форумных движков), а где-то чтобы запихнуть побольше рекламы или осложнить автоматизированное копирование "сверхценного контента"
Железки и софт (будут) прибиты к резолверам вендора, тогда как адреса обычных DNS обычно ISP или админ локалки раздает через DHCP.
Это ведет к нескольким проблемам:
И ладно бы это было как-то нормально конфигурируемо, в хорошем случае это будет что-то уровня "очевидного" ключа
network.trr.uriвabout:configили реестре, в худшем вхардкожено в прошивку.В большинстве случаев предусмотрен fallback на обычный DNS. А в некоторых регионах DoH вообще включать не будут потому, как там это приведёт к проблемам.
Хороший пример — Великобритания, где и правительство очень расположено к цензуре, и провайдерам интереснее зарубить эту инициативу на корню, чтобы оттянуть "роскомнадзоровский" сценарий блокировок по IP на годы
В некоторой степени. Из репозитория, но пока ещё не в дефолтном варианте развертывания
Позвольте нагнести:
Все эти "программисты на C++ за 21 час" и даже выпускники курсов "приличных" курсов "приличных" компаний обычно совершенно никакие. Это просаживает уровень среднего, что в свою очередь всерьез приводит к понижению ожиданий считающих себя средним хороших специалистов с синдромом самозванца. А чтобы в такой ситуации раскрыть глаза, надо набить очень много шишек.
Qt LGPLv3 or GPLv3 для всего, а этого, кажется, для личного пользования более чем достаточно
Ситуация вообще довольно печальная с этим всем.
Еще во времена 4.x (и отчасти даже раньше) было несколько типов хранилища:
В сущности правильным поведением было хранить данные в (0), допустимым в (1) и нежелательным (кроме как для медиафайлов и всего, что необходимо выставлять пользователю) в (3).
Но почему-то многие разработчики упорно не следуют этому и хранят кэши в /sdcard/.appname или даже /sdcard/Appname/...Cache, что отчасти и вызывает описанные уязвимости.
В 4.4 из (3) убрали внешние карточки и флешки, переведя доступ к ним на запись с линуксового на уродливый SAF, так что разработчикам всяких галерей и файловых менеджеров пришлось добавлять прямо в приложения инструкции по разрешению доступа к карточкам памяти.
В Q Google пытаются расширить эту модель и на /sdcard, что, пожалуй, имеет плюсы в том, что лишний мусор из /sdcard/ исчезнет, да и разруливать доступ к чувствительным файлам (не из числа фото/видео/аудио) станет проще.
Однако часть проблем с MitD решить не удастся: для работы с любыми другими файлами (pdf, книги, специфичные форматы в т.ч. сертификаты, ЭП) приложения будут обоснованно требовать доступ к /sdcard через SAF, а значит загрузки (те же упомянутые ЭП и сертификаты) все равно останутся под риском перезаписи.
Гораздо печальнее, что это ещё больше удаляет Android от человека, желающего действительно владеть собственным устройством.
Потеряется:
Возможно, это только мои проблемы, но в последнее время Гугл регулярно ломает те мелочи, которые важны лишь небольшим группам пользователей, в числе которых часто оказываюсь и я.
Неоправданное потребление ресурсов.
Они медленнее даже тормозных приложений на React Native. Они жрут батарею и оперативку т.к. это. Chromium.
Только не хватало всем перейти на централизованный MITM с капчей от гугла.
Например, через модуль Magisk, который выполняет банальнейший код.
Представляю, как же будет радостно операторам и властям от того, что у пользователей, сделавших все "как надо" все равно не начнут работать относительно современные Android приложения (target API >= 24), не начнут работать.
https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html?m=1
Мне кажется, что это возникло из заведомо опасного предположения, что наличие вредоносного ПО на устройстве это совершенно естественно, и любые урезания прав и возможностей пользователя быть владельцем своего устройства абсолютно оправданы.
И, похоже, исходя из этого же функции слива данных пользователя, присутствующие в большей части популярных "официальных" приложений, почти всегда принимается нормально.
С использованием URL Scheme, обработчики которой зарегистрированы в системе. У Telegram это
tgChrome/Chromium схожим образом показывает диалог подтверждения открытия ссылки в "Telegram Desktop" на Windows и в "xdg-open" в Иксах (Linux).
Далее этот URL в качестве параметра передается приложению, которое решает, что дальше делать.
Помню, одной из претензий Qualcomm к Apple было занижение параметров их модемов до уровня аналогичных от Intel, когда и те и другие ставились в одну модель айфона.
А это было года 2 назад, во времена LTE.
Так что модемы Qualcomm просто все ещё лучше аналогов.
Не во всех Linux. В официальных сборках не работает, в некоторых дистрибутивах (те, которые собирают "правильно", например, Arch) то же самое.
\begin{zanuda mode}
Но никаких аргументов в пользу того, что конкретно ваш Chromium в открытую не сливает данные в "одну известную компанию", как это делают оригинальные сборки чистого Chromium, а может и какую-нибудь другую, менее известную компанию, нет никаких.
\end {zanuda mode}
Если говорить о контроле, честным вариантом было бы обеспечение вменяемой воспроизводимости сборок из вашего патченного Chromium и проприетарных HTML, CSS и JS (в идеале не обфусцированного)
Тут есть пример того, как это можно делать с помощью фильтров UBlock Origin (поиск по доменам google):
https://hg.adblockplus.org/ruadlist/rev/f62fc1aac494
Ссылка на исходный коммент esc с упоминанием этого в несколько ином контексте:
https://m.habr.com/ru/post/454468/comments/#comment_20233682
В какой-то момент полосатый оператор, у которого бан адресов гуглом — хроническое, начал выдавать белую динамику, уже находящуюся в списке на момент раздачи на роутер.
В районе 5-6 часов МСК мобильная версия стабильно отдавала 502
Любой фингерпринтинг, основанный на особенностях железа должен работать. Разве что с айфонами сложнее, хотя и там тоже зоопарк моделей порядочный уже
Для работы с основным контентом сайта эта задача решается элементарно.
В современных Firefox (особенно с патчами Tor Browser) это решается сравнительно несложно. Необходимо только вынести код вывода режима чтения наружу и не применять к нему ограничения по разрешению.
А вот со всяким сопутствующим контентом проблема. Отваливаются поиски, отваливаются комментарии, карты, интерактивности и всё такое. И происходит это потому, что каждый сам велосипедировал всё это на различных фреймворках из чего только можно без малейших попыток стандартизации хотя бы даже того, как это будет в итоге рендериться. Где-то из-за непонимания того, как это работает, где-то из желания сделать всё "удобным" (чего стоит переопределение ctrl+f на одном из форумных движков), а где-то чтобы запихнуть побольше рекламы или осложнить автоматизированное копирование "сверхценного контента"