Es tut mir leid Das du gehen musstest Es tut mir Leid Das ich dich Immer wieder weggestoßen habe Und egal, wie oft du sagst Du verzeihst mir Ich kann mir nicht verzeihen Unsere Beziehung Hätte soviel mehr werden können Doch ich bin jedesmal gegangen Nur um dann immer wieder zu kommen Ja, es macht mich bis heute fertig Aber ich finde ich habe das verdient Weil ich habe dir So viel Schmerz bereitet

Du warst immer für mich da Doch ich bin jedesmal weggerannt Trotzdem warst du mir nicht böse Und hast mir jedesmal verziehen Du bist so ein toller Mensch Ich glaub nur, du weißt das nicht Und ich habe dich einfach nicht verdient Du hast dich jedesmal Wieder geöffnet Und ich habe dich jedesmal Wieder fallen gelassen Ich habe dich im Stich gelassen Obwohl wir gut zusammenpassen

Es zerfrisst mich immer noch Bis heute, muss ich ständig, dran denken Und ja ich vermisse dich Und ich liebe dich Ich weiß, man sieht es nicht Denn jedesmal Wenn es ernster wird Krieg ich Angst und flieh Das hat nichtmal was mit dir zutun Ich möchte nur nicht verletzt werden Und deswegen flüchte ich Bevor du mich verletzen könntest Ich habe das Problem bei mir herausgefunden Und möchte dran arbeiten Und wenn ich, das geschafft hab Kann ich dir auch zeigen, das ich dich liebe Und vielleicht kommen wir dann zusammen Und sind einfach glücklich Doch erstmal geht das nicht

Du warst immer für mich da Doch ich bin jedesmal weggerannt Trotzdem warst du mir nicht böse Und hast mir jedesmal verziehen Du bist so ein toller Mensch Ich glaub nur, du weißt das nicht Und ich habe dich einfach nicht verdient Du hast dich jedesmal Wieder geöffnet Und ich habe dich jedesmal Wieder fallen gelassen Ich habe dich im Stich gelassen Obwohl wir gut zusammenpassen

Ich glaube, ich werd dich nie vergessen Denn du bist so toll und so lieb Du hast schon so viel erreicht Seitdem, wir uns kennengelernt haben Du kannst stolz auf dich sein Denn du hast einiges geschafft Ich bin aufjedenfall Stolz auf dich Und ich liebe dich

Подробное объяснение уязвимости CVE-2022-20551, исправленной в Android в феврале 2023 года.

Об AppOpsManager

Отслеживаем (логирование) и контроль доступа (разрешение, запрет) к критичным API системы происходит через механизм app-opов. App-opы (давайте просто app-ops во множественном числе и app-op в единственном) покрывают большой набор функциональности — от рантайм пермишенов до монитора состояния батарейки. Управление же всеми этими фичами, внутри, происходит через AppOpsManager Что именно можно отслеживать и как этим управлять — это вы можете увидеть по ссылке выше. Здесь же нас интересуют именно режимы контроля.

Контроль доступа

Всего таких режимов четыре:

• MODE_DEFAULT — режим “поведения по умолчанию”, которое напрямую документацией не описано. Просто “может отличаться от одного app-op к другому”. Спасибо, ничего не понятно, но очень интересно.
• MODE_ALLOWED — режим, в котором доступ разрешается
• MODE_ERRORED — режим, в котором доступ не просто запрещается, а ещё бросается SecurityException при обращении
• MODE_IGNORED — режим, в котором и доступ не предоставляется, так ещё и ничего не возвращается

Разрешение и запрет с ошибкой выглядят прям очень знакомым, не так ли? Эти режимы доступны пользователю в интерфейсе Android, они позволяют понимать приложению, одобрил пользователь какой-то пермишен или отказал. Но это для пользователя. Для производителей и прошивок, и MDM решений, есть вот этот классный режим игнорирования. Если вы сами производитель какого-то MDM решения, то это разрешение ну очень полезно для вас.

В режиме игнорирования условный диктофон просто не узнает, что у него нет доступа к микрофону — ведь исключения SecurityException не вылетает. И будет считать, что запись идёт. То есть вам, как производителю MDM или защищённой прошивки, выгодно переводить app-ops приложений именно в игнор. Потому что очень наглые приложения начнут настаивать предоставить им доступ.

Кстати, пользователь тоже может управлять app-ops и у него есть полтора способа. Сначала я написал “обычный пользователь”, потому убрал это прилагательное, всё же пользователь должен быть подготовлен на столько, что способен использовать adb. Об этих способах расскажу ниже, когда опишу уязвимость.

Уязвимость CVE-2022-20551

История обнаружения

Мой коллега и руководитель обнаружил, что WhatsApp в режиме MODE_IGNORED продолжает записывать голосовые сообщения. Хоть они и выглядели как запись без звука (что было бы правильным поведением) — просто прямая линия, — но звук на самом деле записывался и голосовое можно было прослушать. Но полбеды в том, что запись выглядела как запись без звука. Индикатор Android о доступе к микрофону не включался и в истории доступа к микрофону WhatsApp не появлялся. Будто он микрофон никогда и не использовал. На меня упала задача посмотреть, что вообще не так.

Проверка на других мессенджерах, в т.ч. Telegram, показала, что такое поведение происходит только у WhatsApp. Проверял и на приложениях-диктофонах и они тоже работали правильно. Признаюсь, мы решили, что это не совпадение, что только WhatsApp себя так вёл. И наше предположение только усиливалось со временем. И, не знаю как другие члены команды, но я по-прежнему считаю, что эта уязвимость была для кого надо уязвимость.

Выяснив, что только WhatsApp ведёт себя так странно, решили передать информацию об уязвимости в Google. А до фикса — отказаться в своём решении от режима игнорирования, заменив на исключение. Лучше пусть приложения видят, что у них нет прав и требуют их предоставить, чем втихую получат доступ. Да, разумеется проверили, что при режиме исключения запись ломалась и у WhatsApp тоже.

Проталкивание проблемы

Aug 19, 2022 08:50PM — это точное время, когда я оформил баг 243152409 в багтрекере Google. Т.к. это проблема безопасности, то оформлял через специальную форму и полученный баг не публичный, попасть туда могу я и сотрудники Google. В этом баге было описано, как WhatsApp обходит режим игнорирования. Я приложил запись видео и сценарий воспроизведения. Ну и информацию о системе, разумеется — при оформлении проблем безопасности эти поля обязательны. Даже точную версию мессенджера указал, на случай, если WhatsApp резко изменят поведение. Это была последняя доступная версия на тот момент.

Казалось бы. Вот вам приложение, вот вам инструкция воспроизведения, как выставить режим игнорирования, вот вам даже видеозапись. Однако Aug 27, 2022 12:15AM получаю ответ: Status: Won't Fix (Infeasible). И объяснение, что мы не считаем это проблемой. Цитировать переписку не буду, ну мало ли. Можете поверить мне наслово. Но там была строка “The Resolution Notes label has been set to NSBC (Not Security Bulletin Class) to reflect this assessment”. Зафиксируем, что 27 августа 22 года воспроизведение на реальном ПО посчитали “working as intended”.

Сообщил нашей команде о том, что Google положил болт на проблему. Это подкинуло дровишек в топку “это дыра – для кого надо дыра, не лезьте”. Но дожать надо. Решили предоставить им PoC, который не имеет ничего лишнего, кроме эксплуатации уязвимости. Забегая вперёд скажу, что сценарий его использования такой же, как и WhatsApp. То есть мессенджера было совершенно точно достаточно.

Наш сотрудник Артём (фамилию не скажу, но лишний раз подчеркну наше всеобщее уважение к нему) разобрал WhatsApp и провёл исследование, как же мессенджеру удаётся обходить ограничение, тогда как все другие этого сделать не могут.

12 сентября Артём всё же докопался до истины. Оказалось, что при использовании OpenSLES режим игнорирования просто не работает. Далее Артём написал PoC, основанный прям на демке самого Google по работе с OpenSLES. Ну то есть Гугл буквально зажали в углу: демонстрация использования уязвимости была сделана на их собственном примере работы с технологией.

Sep 13, 2022 04:52PM я добавляю в ишую со статусом “вонт фикс” новое сообщение. Цитирую его целиком и прикрепляю PoC, чтобы вы могли проверить свои собственные прошивки. Если у вас установлены февральские (от февраля 23 года) обновления, то проблема не будет воспроизводится. Если же не установлены — словите описанное ниже поведение. И важно, проверять нужно на Android 12 и новее, потому что в версиях ниже не было визуального индикатора, который бы показывал, что сейчас идёт прослушивание через микрофон. То есть проблема есть и на 11 и ниже, просто пользователь в принципе не мог раньше понять, что что-то происходит.

Added PoC. It uses OpenSLES

1. Install app
2. Run app
3. Tap on Record button
4. Allow access while using the app
5. Speak something during 5 seconds → We see the microphone access indicator
6. Tap Play button → We hear ourself
7. adb shell pm list packages -U | grep nativeaudio → package:com.example.nativeaudio uid:10060
8. adb shell cmd appops set 10060 RECORD_AUDIO ignore
9. Tap Record button
10. Speak something during 5 seconds → We not see indicator
11. Tap Play button

Expected: silent
Actual: we hear ourself

PoC можно скачать здесь.

Через час после этого Google отписал “спасибо за новую инфу, мы рассмотрим эти данные”.

Sep 23, 2022 01:04AM сотрудник Google написал новое сообщение, где признал проблему: “Based on our published severity assessment matrix (1) it was rated as Moderate severity”. Единичка – это ссылка на матрицу: “(1) Severity Matrix: https://source.android.com/security/overview/updates-resources#severity”.

Oct 8, 2022 06:50AM — гугловцы сообщают, что назначено такое-то вознаграждение.

Nov 10, 2022 08:48PM — гугловцы пишут, что мы всё ещё работаем над исправлением

Jan 6, 2023 09:31PM — новое обновление статуса. Уведомили, что деняк будет выплачено больше, потому что “After conducting additional review of the security issue in this report, we have revised the severity to High”. Я думаю, что у них из отпуска вернулся кто-то, у кого голова не только чтобы в неё есть. И он объяснил остальным, что вы чего вообще, это не какое-то приватное API. Это API мы даём специально для обеспечения безопасности и его используют в том числе Samsung.

Далее ещё несколько переписок по формальностям чистым. Типа, заполните вот эти документы, заполните вот эти. И, наконец, Feb 13, 2023 10:35PM происходит главное: Marked as fixed.

Эта ошибка для своих

Почему я считаю, что эта ошибка была кому надо ошибка. Вы вправе считать иначе и предлагать мне шапочку из фольги — дело ваше.

• Предоставленное полное описание проблемы с демонстрацией на видео и чёткой инструкцией, но конкретно на WhatsApp они вообще не посчитали проблемой: “Based on our review, this issue has been determined to not be a security vulnerability and is working as intended”
• Как только это же самое сделали на другом приложении, они проблему признали
• Мало того, они признали, что это проблема высокой важности по их собственной системе оценок
• Можно было бы посчитать, что у них не получилось воспроизвести на WhatsApp, но это не так. Посмотрите на фикс: они прямо в нём написали, что проверять надо на WhatsApp: “Test: verify app ops work with WhatsApp”. То есть всё у них получилось воспроизвести

Возможно, конечно, я перегибаю палку. Вполне вероятно, что проверял человек, который увидел в WhatsApp прямую линию на записи и просто не прослушал запись, решив, что голосовое сообщение не записалась. А в PoC прямых линий не рисовали и они таки убедились, что всё работает. Но тогда получается, что Security Team в Google не тянули с исправлением, а просто забили болт на проверку.

Какой вариант выбираете: забили болт или тянули с фиксом, потому что уязвимость пока что нужна была?

App-opp у себя

Если вам нравится идея режима игнорирования, вам не обязательно (покупать?) и ставить MDM решение от стороннего производителя. У вас есть полтора пути. Полтора, потому что путь в итоге один, просто “второй” способ — это через GUI, но внутри тоже самое, что и “первый”.

Первый способ вы уже видели на PoC. Получаем UID приложения и выставляем ему режим через adb. Второй — использовать приложение, которому поднимете привилегии через тот же adb. Я сам проверял на Permission Manager X и что-то даже работало. Но я не ходил с ним. Просто проверил, что, прикольно, срабатывает и на этом всё.

Моя телега: https://t.me/mydaybug

Tags #Foto #Berlin

Tags #Tools #Blog #Fediverse

Matt Mullenweg hatte es angekündigt, einige haben jedoch an der konkreten Umsetzung gezweifelt. Nun wird es aber konkret: Wordpess unterstützt das Fediversum. Blog-Beiträgen werden damit im Fediverse zugänglich. Es kann ihnen gefolgt und sie können kommentiert werden usw.

Die Firma hinter Wordpress Automattic und Tumblr kauft das “ActivityPub for WordPress”, wesentlich entwickelt von Matthias Pfefferle dazu. Dieser wird zudem von Automattic direkt angestellt. Automattic gibt dies bekannt (TechCrunch).

Für das Fediverse ist diese Unterstützung wesentlich. Denn Wordpress ist das Tool, welches Blogs und News-Seiten usw. oft zugrunde liegt, ist mit über 40 Prozent Marktanteil der Marktführer.

> Kommentieren

... wäre ja im Prinzip eine feine Sache. Sehr einfach in der Bedienung, schön anzusehen, usw. Und föderieren tut es auch ins restliche Fediversum. Halt so halbwegs: Replies von anderen Systemen (wie Mastodon) werden in WriteFreely nicht angezeigt — die gehen komplett ins Leere.

Auch fehlt komplett der Support von Medien, also Bildern. Die kann man nur via Markdown einbinden, wenn die Bilder auf einer anderen Seite liegen.

Schade.

Known issues

• Speedtest not yet implemented
• Metrics not yet implemented (affects you in the sense of: to see whether it's annoying to you if i restart the service)
• Protocol PDF export only works from within the pad
• Recordings can't be made available yet (waiting for upstream), the menuentry will not work
• no proper Email support yet
• phone calls feature not addressed yet, but planned

Login / signup

OpenTalks authentication service (Keycloak) is connected to our authentication server (Zitadel). Please use the button mentioning Zitadel and go from there. The loginform above that button will NOT work. That's because having two independant auth providers feels ... wrong and Keycloak is required for OpenTalk.

About this instance

Due to the complexity of OpenTalk, this instance derivates off of their official “lite” Docker example. It adds a number of services, trying to reach an as complete as possible experience. As of the time of writing, this is still in progress and a few more restarts are to be expected in order to apply new settings and stuff.

Maintenance window: because it doesn't make sense to restart all the time while you are trying to give it a fair test, I will try to apply new settings only between 5-9pm CET. (see below)

This instance is categorized as “playground mode”. Its purpose is to evaluate whether it is feasable to keep it long-term. This also means that you still are more than welcome to use and test it, because software that is not used by anybody can't be tested/evaluated properly.

Playground mode window: This service will be evaluated until mid of June 2023

About OpenTalk

tba (irrational happy “Rust” noises)

#tchncs #opentalk #playground

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

Изменения, касающиеся всех приложений

Здесь собраны изменения, которые задевают приложения, даже если их таргет ниже 14. Называется новая версия, если что, Android Upside-down cake — “перевёрнутый” пирог или “вверх ногами” или “наизнанку” — как угодно. В общем, суть в том, что после выпекания этот пирог переворачивают и то, что раньше было верхом пирога становится его дном.

Core функциональность

Разрешение SCHEDULE_EXACT_ALARM больше не выдаётся автоматически

Exact alarms — это когда нужно выполнить задачу в строго заданное время, ни раньше, ни позже. К примеру — напомнить о встрече. Начиная с Android 14 для большинства устанавливаемых приложений (очевидно, не касается уже установленных), таргет которых начинается с 13, пермишен SCHEDULE_EXACT_ALARM автоматически выдаваться больше не будет. В общем, теперь нужно спрашивать его явно.

О чём речь

• SCHEDULE_EXACT_ALARM появилось в API level 31 (это S, он же 12)
• без этого разрешения запланированные задачи будут выполняться не в строго заданное время, а когда ОС разрешит
• его нужно (теперь, когда представили – не нужно было) запрашивать. Сценарий будет не как с runtime permission — диалог — а как разрешение на установку приложений, когда пользователь на отдельном экране дёргает переключатель
• этого экрана может не быть вовсе. Вообще все экраны “специальных разрешений” имеют пометку, что производитель прошивки может его убирать. Имейте в виду.
• и пользователь, и ОС могут переключатель выставить в отключенное состояние, отозвав разрешение
  • отзыв разрешения автоматически удаляет все запланированные задачи
• в API level 33 (это TIRAMISU, он же 13) у этого разрешения появилась альтернатива USE_EXACT_ALARM
  • это разрешение выдаётся автоматически
  • пользователь не может его отозвать
  • вас выбросят из Google Play за использование этого разрешения, если приложение не является будильником или чем-то подобным, чему реально нужно срабатывать секунда в секунду. Я смотрел весь сериал только из-за этой гифки

---

Контекстно-зарегистрированные бродкасты ставятся в очередь для кешированных приложений

Если приложение перешло в состояние “кешировано” (то есть оно не на переднем плане и не убито системой и становится кандидатом на отстрел), то контекстные бродкасты складываются в очередь. Если приложение не будет отстрелено системой и пользователь снова к нему обратиться, то лежащие в очереди бродкасты будут доставлены, если контекст позволяет.

О чём речь

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

---

Приложения могут убить только собственные фоновые процессы

Метод killBackgroundProcesses() может убить теперь только фоновые процессы того приложения, из которого был вызван. Наконец сдохнет большинство “оптимизаторов батареи”. К сожалению, во-первых только сторонние, во-вторых не все. Вендорский шлак так и будет существовать, а разработчики стороннего ПО то и дело будут ссылаться на https://dontkillmyapp.com/

О чём речь

• это древняя апишка, которая защищена разрешением KILL_BACKGROUND_PROCESSES. Само её существование для сторонних приложений — бред какой-то
• эта апишка не позволяла убивать системные приложения, только сторонние
• патч безопасности от 1 декабря 2022 уже ограничил работу пермишена KILL_BACKGROUND_PROCESSES — стало нельзя убивать сторонние процессы
• теперь это ограничение, которое раньше было только фиксом безопасности, затащили в ОС. Другими словами, изменение произошло в конце прошлого года на всех актуальных версиях ОС
• некоторые оптимизаторы использовали не эту апишку, а работали хитрее через Accessibility Service. Так что готовьтесь к тому, что шлак массово будет переходить на это, очень опасное, API

---

Безопасность

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

Приложения с targetSdkVersion ниже 23 (это Android 6) больше не могут быть установлены. То есть в Android 14 теперь все приложения будут поддерживать runtime permission, либо не будут работать вовсе. Если приложение с более низким таргетом было установлено, когда на ваше устройство прилетел Android 14, то для него будет сделано исключение и оно продолжит работать. Но вот переустановить его уже нельзя будет.

---

Поле Media owner package name может быть изменено

К хранилищу медиа можно делать запросы поля OWNER_PACKAGE_NAME, в котором будет (или не будет — может быть NULL) указано имя пакета, который сохранил определённый медиа файл. Начиная с Android 14 значение этого поля будет подменяться для всех приложений кроме (должно быть выполнено хоть одно условие):

• приложение, которое сохранило этот файл, входит в список приложений, которые всегда видимы другим
• приложение, которое запросило это поле, имеет разрешение QUERY_ALL_PACKAGES

О чём речь

Ничего не понятно, правда?

• запросы к медиа хранилищам делаются как запросы к БД. Пусть они и обёрнуты в некое API, сути это не меняет
• запросить можно в том числе “а кто создал этот файл”: OWNER_PACKAGE_NAME. В ответ придёт или имя пакета приложения, или NULL
• Google решили, что через такие запросы можно понять, какие приложения установлены на устройстве. И это, надо сказать, разумно. Вполне себе тянет на утечку по сторонним каналам. А ведь уже давно запрос списка установленных приложений защищается пермишеном QUERY_ALL_PACKAGES
• сложив два и два, Google сделали так. Если приложение, которое пытается узнать владельца файла через эту апишку, не владеет разрешением QUERY_ALL_PACKAGES, то проверяется, является ли владелец файла всегда видимым приложением
  • это всякие системные приложения — они ведь всегда есть, чего их скрывать
  • приложения, которые установило ваше собственное приложение. Оно и так знает, что установило, чего скрывать
  • приложение, которое вызывало ваше через startActivityForResult(). Это ведь оно вас позвало, оно и так уже призналось в своём существовании
  • всякое другое, типа контент провайдеров, клавиатур. Подробнее тут, если надо
• в итоге, если владелец не входит в список всегда видимых && запрашивающий не владеет QUERY_ALL_PACKAGES, то он не сможет узнать владельца. Как именно подменяется владелец я не смотрел. Да и не важно, хоть там будет просто android написано, хоть там будет NULL. Главное, что нельзя таким образом составить список установленных приложений

---

User experience

Давайте уже согласимся, что говорить “юикс” нормально, а говорить “пользовательский опыт” — это ментальное заболевание. Впрочем, лично мне нравится говорить “привычки”, хотя в реальной речи стараюсь не использовать это слово. Оно нравится мне, но другие как-то так не говорят и боюсь, что буду сбивать с толку других

Взаимодействие с несмахиваемыми уведомлениями

В Android 14 пользователь может смахивать уведомления, которые ранее были не смахиваемыми, но в конкретных случаях. Если уведомление сделано не смахиваемым установкой флага FLAG_ONGOING_EVENT, то пользователь теперь может всё-таки его смахнуть. Флаг выставляется, например, через NotificationCompat.Builder#setOngoing(boolean).

Такие уведомления всё равно не будут смахиваться, если:

• телефон заблокирован. Ну то есть на экране блокировки
• пользователь нажал кнопку очистки уведомлений. То есть случайно потерять не получится

Поведение не меняется, если:

• уведомление создано с использованием MediaStyle API — то есть явно для плееров
• политики запрещают это действие

О чём речь

Подавляющее большинство моих знакомых (и я сам) в первую очередь подумали — касается ли это foreground service? Если вы знаете ответ заранее — снимаю шляпу.

• мы привыкли, что уведомления фореграунд сервисов не смахивались, в общем-то
• в Android 13 поведение изменилось. Уведомления от фореграундов стало можно смахивать
• чтобы всё же закрепить уведомление, нужно ручками выставлять флаг Notification#FLAG_ONGOING_EVENT, о котором говорилось выше. По умолчанию билдер за вас его не выставит
• в Android 14 уже пошли дальше и флаг тоже почикали

---

Предоставление частичного доступа к фото и видео

Если вам достаточно фото пикера, то можно пропускать.

В Android 13 появились пермишены доступа к изображениям (READ_MEDIA_IMAGES) и видео (READ_MEDIA_VIDEO). В Android 14 диалог запроса разрешения изменился:

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

Ну и видно, что разрешение READ_MEDIA_AUDIO не задето.

О чём речь

• в Android 13 добавились новые разрешения на доступ к медиа, которые нужно использовать вместо READ_EXTERNAL_STORAGE: READ_MEDIA_IMAGES, READ_MEDIA_VIDEO и READ_MEDIA_AUDIO
• если приложение, которое работает с этими разрешениями, будет установлено в Android 14, то диалог запроса разрешений изменится — добавится новая кнопка
  • то есть мы понимаем, что минимально возможный таргет будет Android 13. Ведь до этого таких разрешений не было
• теперь пользователь может нажать новую кнопку и дать доступ не ко всем картинкам, а к конкретным
• если пользователь сделает выбор конкретных, то это разрешение сработает примерно как one time permission — то есть будет выдано на текущую жизнь прилаги. После отстрела и нового запроса разрешения диалог появится вновь
• разрешение всего и запрет всего работают как раньше
• это поведение можно сделать немного прозрачнее в первую очередь для себя самого, благодаря новому пермишену READ_MEDIA_VISUAL_USER_SELECTED, но оно доступно только для target 14. Впрочем, в этом случае лучше использовать именно пикер, а не изобретать свой велосипед

---

Специальные возможности

Масштабирование шрифта до 200%

Система позволит задавать масштабирование шрифта до 200%. Будьте добры убедиться, что ваше приложение к этому готово.

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

---

Изменения, стреляющие для target на 14 и выше

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

Core функциональность

Для foreground services требуется указание типа

Для приложений с targetSdkVersion на Android 14 для каждого foreground service нужно указывать его тип из заранее предопределённого списка. Если для приложения нельзя выбрать логичный тип из списка, то нужно переехать на WorkManager или специально созданный user-initiated data transfer job. Не уверен, что это нужно переводить. Вроде понятно, что речь идёт о задачах, которые инициировал сам пользователь.

О чём речь

• для таргета на Android 10 для сервисов в манифесте стало нужно указывать тип android:foregroundServiceType для некоторых задач: камеры, геолокации. Если сервис не использовался для этих целей, то и тип не нужен
• для таргета на Android 14 тип указать обязан и никак иначе. На выбор даётся более десятка типов (звонки, камера, локация, здоровье, микрофон и другое). Фореграунд сервиса без типа быть теперь не может
• если для какого-то сервиса не подходит ни один тип, то у вас два пути:
  • переход на WorkManager. С этим, думаю, всё понятно, ему лет сто уже. Если не знакомы — ознакомьтесь, сбросьте часть рутины. Но добавите новую зависимость. А мы знаем, что Google делает со своими либами каждые несколько лет
  • переход на “задачи передачи данных, инициированных пользователем”: user-initiated data transfer jobs
• пользовательские задачи — это всякие длинные задачи, которые пользователь инициировал явно, но которые не подходят по списку типов. К примеру, скачивание файла с удалённого ресурса или копирование файлов на внешний носитель
  • трансфер джобы обязывают объявить пермишен RUN_LONG_JOBS. Читайте так: в следующей версии или через пару тоже начнут ограничивать. Да и Google Play может начать делать кислые щи
• есть некоторая защита от того, что вы впишете тип хоть какой-нибудь, чтобы от вас отстали. Для этого каждому типу сопоставлено разрешение, которое нужно объявить в манифесте. А лепить разрешения “чтобы отстали” уже не хочется
• есть отдельный тип Short service, который может быть полезен для реально коротких задач. Он не требует отдельного разрешения. Однако жизнь этого сервиса ограничена ~3 минутами, которые начинают тикать с вызова startForeground() и заканчивают в момент остановки сервиса (можно selfStop(), можно stopForeground(). Если не уложились в 3 минуты и не остановили сервис, ловите ANR. Кроме того одновременно может работать только один короткоживущий сервис. Попытка запустить ещё один приведёт к исключению ForegroundServiceStartNotAllowedException

---

Безопасность

Ограничения неявных и отложенных интентов

Мы все говорим “интент”. А вот говорите вы “отложенный” или “пендинг”?

Приложения с таргетом на Android 14 получают изменённое поведение взаимодействия со своими собственными компонентами:

• больше нельзя послать неявный интент не экспортированному компоненту — поймаешь исключение
• при попытке создать отложенный мутабельный интент, не указав компонент или хотя бы пакет явно, снова словите исключение

О чём речь

Вроде и понятно, а вроде не очень, да?

• компонентам приложения (активити, сервисы, вот это всё) в манифесте нужно выставлять флаг экспорта android:exported
• документация нам говорила, что экспортированные (android:exported="true") компоненты доступны всем приложениями на подёргать. Если хотите экспортированный, но защищённый, для вас есть специальный механизм разрешений
• если компонент не экспортированный, то дёргать его можно только изнутри этого же приложения (более широко — от этого же UID). И привилегированные системные компоненты ещё могли войти в этот сарай (отсылка для поехавших). Если же левое приложение попытается дёрнуть такой компонент, то получит исключение, что нет такого

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

• многие разработчики делали не экспортированные, например, активити и для него создавали фильтр вида my.mega.app.action.NAME. Ну и далее из кода context.startActivity(my.mega.app.action.NAME)
• однако (это частный пример) авторы вредоносных приложений стали создавать экраны, которые выглядят точно также, как те, на которые они нацелились. И создавали такие же фильтры. Теперь система не знает, кому послать интент, он же не явный. Выбор из настоящего экрана и поддельного перекладывается на пользователя и тот может сделать неправильный выбор. То есть внешние приложения по-прежнему не могут вызвать не экспортированные компоненты, но могли прикинуться теми приложениями
• теперь, если таргет Android 14, для вызова своего собственного не экспортированного компонента нужно создавать явный интент. Что не позволит уже уйти этому интенту не в те ворота

---

Бродкаст ресиверы, зарегистрированные в рантайме, должны явно указать эспортированность

Контекстные ресиверы (о них было выше) в приложениях с таргетом на Android 14 обязаны явно указать, экспортированы они (RECEIVER_EXPORTED) или нет (RECEIVER_NOT_EXPORTED). При регистрации слушателя системных бродкастов (к примеру переход в режим полёта или установка приложения) это указание не требуется. Всё равно системные послать кто угодно не может — считается, что защита уже есть.

---

Более безопасная динамическая загрузка кода

Если приложение имеет таргет Android 14 и использует динамическую загрузку кода, то есть буквально передаёт внешнюю либу загрузчику, то теперь нужно помечать файл с этим кодом доступным только для чтения: File#setReadOnly()

Ну и отдельно Google просит (но не проверяет) явно пересоздавать эти файлы. Не проверять, что раз файл есть, то не перекачивать. А прям удалять и качать его снова. Видимо идея в том, чтобы вам не подложили левый файл и вы не приняли его за свой собственный. Ну и просят проверять подпись файла.

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

---

Новые ограничения запуска активити из фона

Для приложений с таргетом на Android 14, система накладывает ограничения на запуск активити из фона:

• отправитель, посылающий PendingIntent другому приложению, должен явно указать, позволяет ли он запускать себя из фона
• когда видимое приложение использует метод bindService() и, собственно, биндится к сервису другого приложения, которое сейчас в фоне, оно должно сообщить, можно ли теперь тому фоновому сервису запускать активити инициатора. Для этого есть флаг BIND_ALLOW_ACTIVITY_STARTS

О чём речь

Запутанно из-за всех этих “оно”, “его”. Кто, кому, чего? Признаюсь, перечитывал описание раз 10 и каждый раз понимал по-разному.

Сначала с PendingIntent

• это такой вид интента, который можно передать другому приложению так, будто ты его внутри себя перебрасываешь. И получатель теперь может дёргать твои компоненты от твоего имени. То есть создаёшь интент на запуск экрана. Оборачиваешь его в пендинг интент и передаёшь этот пендинг внешнему приложению. Теперь внешнее приложение может запустить твой экран от твоего же имени
• при создании объекта отложенного интента нужно заранее решить, позволяем ли получателю поднимать наши экраны из фона. Можем разрешить, запретить или оставить на усмотрение системы
• метод пришёл на смену setPendingIntentBackgroundActivityLaunchAllowed, который появился в 13 и сдох в 14. Впрочем, его нигде и не афишировали. И судя по исходникам, он вообще скрыт. Видимо планировали, но не доделали

Теперь с биндингом к сервису

• наше приложение видимо пользователю
• есть другое приложение, которое предоставляет сервис и сейчас в фоне где-то
• наше приложение биндится к сервису второго приложения
• раньше это второе приложение получало возможность запускать активити из фона. Типа, ко мне же подключилось видимое приложение
• теперь поведение изменилось. Разрешение на запуск активити не предоставляется. Приложение, которое биндится, должно явно передать BIND_ALLOW_ACTIVITY_STARTS

---

Обновлены ограничения не SDK интерфейсов

Начиная с Android 9 урезают доступ к разным API. Часть держат в белом списке, часть в сером (типа, готовьтесь, можем отрезать), к части доступ заблокировали. Каждый релиз список пополняется. Вот, снова пополнили. Сейчас он весит больше 50 Мегабайт в csv формате.

Пример одной строки, как эти ограничения описаны:

Landroid/Manifest$permission ->BIND_COMPANION_DEVICE_SERVICE:Ljava/lang/String public-api sdk system-api test-api

В этих ограничениях меня забавляет то, что куча либ самого Google, из джет пака, обращаются к серым API.

---

Не знаю как вам, а мне изучение было полезным. А то я уже несколько релизов пропустил.

Say hi to a new and exciting service at tchncs.de – well – for now. :)

Due to previous mistakes, I have decided to declare testing-periodes for new services, before they will be added to the portfolio long-term. In this case i went with one month, meaning until April 6th '23.

BookWyrm makes a good first impression and was highly voted for in our new survey. You can track, rate, discuss and share books you are reading. It even is possible to link sources of books. All this while being part of the fediverse like Mastodon!

Sounds great? Wonderful:

---

I have requested an invite but received no email!?

Please give me some time to review requests and send invites. BookWyrm does not send an email until the actual invite. If it takes multiple days, please contact me directly or check your spam. 😇

How final is this setup?

Well it looks fine so far but is fairly fresh and since it is not a simple Docker install, it is possible that there are small mistakes that still need fixing. Note that bookwyrm.social appears to be very slow right now, which causes book imports to fail (if you use this domain as a source. there are more options!).

What if it does not qualify during testing?

In that case, I will give users enough time to look for a new instance and publish an announcement on the instance, as well as on this article.

What if it does qualify?

In that case ... well ... it will just continue running and descriptions will be updated accordingly.

#tchncs #bookwyrm #playground

Tags #Medienpädagogik #Bildung #Lehre #Wissenschaft

In dieser Woche unterrichte ich wieder im Lehrgang Medienpädagogik (CAS, Fachhochschule). Seit rund zehn Jahren bin ich im Dozierendenteam dabei. Im Rahmen meines Seminars führe ich in drei grundlegende medienpädagogische Positionen ein, Jugendliche und Medien, um aktuelle Debatten einordnen zu können:

• Position 1: Schutzräume errichten
• Position 2: Resilienz stärken und mit Eigenentwicklung rechnen
• Position 3: Medienentwicklungen und -ereignisse als pädagogische Anlässe nutzen: dialogisch-mediensensitive Pädagogik.

In politischen Debatten wird oft Position 1 vertreten. Es soll gefiltert werden, wo immer möglich. Diese Position ist deshalb politisch ergiebig, weil sie 1) alltagslogisch umstandslos einzuleuchten scheint und 2) stets “die anderen” adressiert: Plattformen, Messenger-Anbieter usw. Zwei Kriterien, welche den politischen Diskurs als solchen ausweisen. Es soll simpel sein und die anderen mit Handlungserwartungen adressieren.

Doch das Konzept des “Schutzraums” ist allein deshalb oft problematisch, weil es kaum zu verwirklichen ist und den Anforderungen, die sich an Pädagogik stellen, nicht gerecht werden kann. Dabei stehen nicht primär technische Probleme im Vordergrund, obwohl sie nicht zu unterschätzen sind, sondern soziale. In der Schule beispielsweise wird die Unterschiedlichkeit der elterlichen Zugangsregelungen “zum Problem”, sobald versucht wird, Position 1 zu realisieren. Oder wie meine Kollegin sagt, die als Lehrerin tätig ist: Einer/eine in der Klasse hat immer den “Schlüssel” zur Türe in den “Abgrund”.

Dies bedeutet: Es bräuchte eine mediensensitive Pädagogik, die mit Medienmilieus rechnet und mit Kompetenzsymmetrien zwischen Jugendlichen und pädagogischen Akteuren. Vom politischen Personal kann selten Unterstützung erwartet werden, dies zeigen konkrete Erfahrungen der letzten Jahre. Das Anliegen muss meines Erachtens sein, Kompetenzen hin zu einer mediensensitiven Pädagogik zu entwickeln (nicht bloss zu einer “Medienpädagogik”) , die zu mehr fähig ist als zu: “Ich filtere, also bin ich”.

> Kommentieren

Tags #Tools #Blog #OpenSource #Wordpress

Eine Erfolgsgeschichte geht so: Matt Mullenweg, der Mann hinter Wordpress, wird 40 Jahre alt. Wordpress ist Open Source und wird dieses Jahr 20. Mullenweg hat Wordpress als Fork von b2 gestartet. Inzwischen wird das Tool weltweit für 42%* der Webseiten genutzt und ist damit Marktführer.

Das Unternehmen, das um Wordpress entstanden ist, Automattic, umfasst aktuell rund 2000 Mitarbeitende in 98 Ländern. Tumblr, von David Karp gegründet, gehört seit 2019 ebenfalls zur Automattic-Familie. Und nicht zu vergessen: Die Blog-Plattform wordpress.com wächst seit Jahren kontinuierlich an.

Ich erinnere mich an die ersten, schlichten Wordpress-Versionen. Damals bin ich von Movabletype (aktuell bei Version 7 angekommen) zu Wordpress umgestiegen, was der engere Freundeskreis der Blogosphäre nicht nachvollziehen konnte.

(*) Quelle: Automattic

> Kommentieren

Tags #OpenSource #Datenschutz #Tools

Wie können Daten in der Cloud, auf dem Desktop oder dem Smartphone sicher verschlüsselt werden? Das funktioniert mit Cryptomator. Boxcryptor, das andere bekannte Tool für solche Aufgaben, wurde inzwischen von Dropbox übernommen. Doch gerade die Unabhängigkeit von einem Cloud-Anbieter kann hier ein entscheidendes Kriterium sein.

Cryptomator, das freie Software-Tool aus Deutschland, wurde bereits vor Jahren ausgezeichnet und hat sich inzwischen in verschiedenen Anwendungsszenarien bewährt. 2014 ging die erste Beta-Version online, entwickelt von Sebastian Stenzel. Cryptomator ist zu einem wesentlichen Teil spendenfinanziert. Kostenpflichtig sind die Mobiles. Gerade eben ist das Tool bei der Version 1.7 angekommen.

Cryptomator bietet eine “cloud-optimierte verschlüsselte Speicherung von Dateien. Diese können ... mit einem Cloud-Anbieter wie Dropbox synchronisiert werden, ohne dass der Anbieter die Daten im Klartext lesen kann.” (Wikipedia, 27.11.2022)

Cryptomator ist lauffähig mit den Systemen Windows, macOS, Linux, Android und iOS.

Wir können die Zeit aus unserer Erfahrung nicht wegdenken und auch nicht erkennen, ob sie einer – wie auch immer gearteten – Welt an sich zukommt.

Immanuel Kant

Zeit ohne Raum

Wenn man die Augen schliesst und ganz ruhig ist, kann man den Fluss des Universums hören, so ein buddhistisches Sprichwort. Einstein glaubte, dass das gesamte Universum aber statisch sei und dass alles bereits existiere: die Zukunft, Vergangenheit und Gegenwart. Ein gefrorener Fluss sozusagen. Sie wurden mit dem Urknall erschaffen und exitieren seit einigen milliarden Jahren. Wobei “Jahren” nicht korrekt zu sein scheint, etwas zu bemessen, dass die Zeit ja erschaffen hat. Frage: Was ist Zeit? Was ist Raum? Und was ist Zeit ohne Raum?

George 01

Seit zwei Wochen ist dieses Mädchen bei ihnen und hat immer noch kein Wort gesagt. Sie schläft lange und isst sehr viel. Seit ein paar Tagen kommt sie mit aufs Feld. Die Kartoffelernte steht an und sie hilft mit. George und Bill, die Bauernhelfer, die manchmal dem in die Jahre gekommenem Erik bei der Arbeit helfen, konnten nicht glauben, dass eine Frau so viel tragen und ziehen konnte. Eine seltsame Frau oder doch ein Mädchen? Erik war sich da nicht so sicher. Da sie keine Dokumente bei sich hatte, war das schwer zu beurteilen. Sie wirkte zwar jung aber irgendwie glaubte Erik, dass sie schon seit Ewigkeiten auf dieser Welt weilte. Wenn man in ihre Augen blickte, wurde man von ihnen eingesaugt. All seine Fragen lösten sich dort in Luft auf. Er schien alle Antworten zu kennen und das weit daruber hinaus. Zwei Mal ist ihm das wiederfahren. Obwohl das nur einige Sekunden dauerte, kam es ihm vor wie Wochen.

Der Anfang vom Ende

a

Irgendwas ist unruhig. Es schreit danach etwas in bewegung zu versetzen. Zeit und Raum zum tanzen zu bringen. Tatendrang, Panik und Freude. Viele Ideen warten auf ihre Enthüllung – vergebens. Die Panik lässt es nicht zu. Lässt es tiefer fallen und hinterlässt nur Einsamkeit. Alleine mit den Gedanken die sich weiter verstricken und bald zu ersticken drohen. Doch scheint es nicht aller Hoffnung verloren. Bei Ruhe zeigt Zeit Gesicht. Nicht so mächtig – nur ein Rädchen.