Власти определились со сроками блокировки Telegram
Власти определились со сроками блокировки мессенджера Telegram и рассматривают возможность принятия этой меры в первых числах апреля, рассказал источник, знакомый с обсуждениями в профильных ведомствах.
Два источника, близких к Кремлю, называют это окончательным решением. Среди обсуждавшихся причин блокировки они указали на то, что в последнее время участились случаи вербовки людей, в том числе несовершеннолетних, для совершения противоправных действий.
https://www.rbc.ru/technology_and_media/26/02/2026/69a059719a7947a5ece8f4e4?from=from_main_1
Власти определились со сроками блокировки мессенджера Telegram и рассматривают возможность принятия этой меры в первых числах апреля, рассказал источник, знакомый с обсуждениями в профильных ведомствах.
Два источника, близких к Кремлю, называют это окончательным решением. Среди обсуждавшихся причин блокировки они указали на то, что в последнее время участились случаи вербовки людей, в том числе несовершеннолетних, для совершения противоправных действий.
https://www.rbc.ru/technology_and_media/26/02/2026/69a059719a7947a5ece8f4e4?from=from_main_1
🤬18🤡10💔4❤3😭1
Как работают куки и сессии на примере аутентификации
(продолжение предыдущего поста)
Как работают куки на примере аутентификации
1. Первый запрос (REQUEST #1) — вход в систему (log in):
- Пользователь отправляет запрос на авторизацию (вход в систему).
- Backend-сервер проверяет учётные данные (аутентификация — *authenticate*).
- Если аутентификация успешна, сервер генерирует куки (cookie) и отправляет их обратно пользователю. Куки — это небольшой фрагмент данных, который хранится на стороне клиента (браузера).
2. Второй запрос (REQUEST #2) — просмотр страницы (view page):
- При последующем запросе (например, при попытке просмотреть страницу) браузер автоматически отправляет серверу ранее полученные куки вместе с запросом (*request + cookie*).
- Сервер проверяет полученные куки и, если они валидны, распознаёт пользователя.
- Сервер возвращает запрошенные данные с сообщением «welcome back, here’s the data» («добро пожаловать обратно, вот ваши данные»).
Суть: куки хранят состояние сессии на стороне клиента. Сервер доверяет данным, переданным в куках, и на их основе определяет, авторизован ли пользователь.
Как работают сессии на примере аутентификации
1. Первый запрос (REQUEST #1) — вход в систему (log in):
- Пользователь отправляет запрос на авторизацию.
- Backend-сервер выполняет аутентификацию (*authenticate*).
- Если аутентификация пройдена, сервер:
- создаёт сессию (уникальный сеанс работы пользователя) и сохраняет её данные в Session Store (хранилище сессий — отдельный компонент или база данных);
- генерирует куки с ID сессии (*here’s a cookie with session id*) и отправляет их клиенту. ID сессии — это ссылка на данные сессии, хранящиеся на сервере.
2. Второй запрос (REQUEST #2) — просмотр страницы (view page):
- При следующем запросе браузер отправляет кукис ID сессии (*request + cookie*).
- Сервер извлекает ID сессии из куки и обращается к Session Store для проверки существования и валидности сессии (*verify session*).
- Если сессия действительна, сервер возвращает запрошенные данные с сообщением «welcome back, here’s the data».
Суть: сессии хранят состояние на стороне сервера, а куки лишь передают ID сессии. Сервер не доверяет напрямую кукам, а каждый раз проверяет актуальность сессии в Session Store.
### Ключевые отличия
- Место хранения данных:
- Куки: данные хранятся на клиенте (браузере).
- Сессии: данные хранятся на сервере (Session Store), а на клиенте — только ID сессии.
- Безопасность:
- Куки менее безопасны, так как данные доступны на клиенте и могут быть подвержены атакам (например, CSRF).
- Сессии более безопасны, так как критичные данные не хранятся на клиенте.
- Объём данных:
- Куки имеют ограничение по размеру (обычно до 4 КБ).
- В сессиях можно хранить больше данных, так как они хранятся на сервере.
- Управление сроком действия:
- Куки могут быть постоянными или сессионными (удаляются при закрытии браузера).
- Сессии обычно имеют ограниченный срок действия и автоматически завершаются после бездействия.
(продолжение предыдущего поста)
Как работают куки на примере аутентификации
1. Первый запрос (REQUEST #1) — вход в систему (log in):
- Пользователь отправляет запрос на авторизацию (вход в систему).
- Backend-сервер проверяет учётные данные (аутентификация — *authenticate*).
- Если аутентификация успешна, сервер генерирует куки (cookie) и отправляет их обратно пользователю. Куки — это небольшой фрагмент данных, который хранится на стороне клиента (браузера).
2. Второй запрос (REQUEST #2) — просмотр страницы (view page):
- При последующем запросе (например, при попытке просмотреть страницу) браузер автоматически отправляет серверу ранее полученные куки вместе с запросом (*request + cookie*).
- Сервер проверяет полученные куки и, если они валидны, распознаёт пользователя.
- Сервер возвращает запрошенные данные с сообщением «welcome back, here’s the data» («добро пожаловать обратно, вот ваши данные»).
Суть: куки хранят состояние сессии на стороне клиента. Сервер доверяет данным, переданным в куках, и на их основе определяет, авторизован ли пользователь.
Как работают сессии на примере аутентификации
1. Первый запрос (REQUEST #1) — вход в систему (log in):
- Пользователь отправляет запрос на авторизацию.
- Backend-сервер выполняет аутентификацию (*authenticate*).
- Если аутентификация пройдена, сервер:
- создаёт сессию (уникальный сеанс работы пользователя) и сохраняет её данные в Session Store (хранилище сессий — отдельный компонент или база данных);
- генерирует куки с ID сессии (*here’s a cookie with session id*) и отправляет их клиенту. ID сессии — это ссылка на данные сессии, хранящиеся на сервере.
2. Второй запрос (REQUEST #2) — просмотр страницы (view page):
- При следующем запросе браузер отправляет кукис ID сессии (*request + cookie*).
- Сервер извлекает ID сессии из куки и обращается к Session Store для проверки существования и валидности сессии (*verify session*).
- Если сессия действительна, сервер возвращает запрошенные данные с сообщением «welcome back, here’s the data».
Суть: сессии хранят состояние на стороне сервера, а куки лишь передают ID сессии. Сервер не доверяет напрямую кукам, а каждый раз проверяет актуальность сессии в Session Store.
### Ключевые отличия
- Место хранения данных:
- Куки: данные хранятся на клиенте (браузере).
- Сессии: данные хранятся на сервере (Session Store), а на клиенте — только ID сессии.
- Безопасность:
- Куки менее безопасны, так как данные доступны на клиенте и могут быть подвержены атакам (например, CSRF).
- Сессии более безопасны, так как критичные данные не хранятся на клиенте.
- Объём данных:
- Куки имеют ограничение по размеру (обычно до 4 КБ).
- В сессиях можно хранить больше данных, так как они хранятся на сервере.
- Управление сроком действия:
- Куки могут быть постоянными или сессионными (удаляются при закрытии браузера).
- Сессии обычно имеют ограниченный срок действия и автоматически завершаются после бездействия.
Telegram
METANIT.COM
Как работают куки и сессии на примере аутентификации
(продолжение в следующем посте)
(продолжение в следующем посте)
👍11❤7🤝2
Финтех-компания Block решила уволить 40% сотрудников из-за ИИ
Технологическая компания Block основателя Twitter Джека Дорси сократит свой штат более чем на 4 тыс. сотрудников (40% от всего штата) из-за внедрения искусственного интеллекта. Об этом сам Дорси сообщил на своей странице в социальной сети.
«Сегодня мы принимаем одно из самых сложных решений в истории нашей компании: мы сокращаем штат нашей организации почти вдвое, с более чем 10 тыс. человек до немногим менее 6 тыс. Это означает, что более 4 тыс. из вас просят уйти или перейти к консультациям», — написал бизнесмен.
Дорси также отметил, что этот шаг не обусловлен проблемами в компании, и подчеркнул, что ее прибыль и рентабельность растут. По словам бизнесмена, причиной такого решения стали новые технологии, используемые в работе Block.
«Мы уже видим, что инструменты аналитики, которые мы создаем и используем, в сочетании с более компактными командами позволяют внедрять новый подход к работе, который в корне меняет представление о создании и управлении компанией», — уточнил основатель компании.
На фоне этого сообщения акции Block выросли более чем на 20%.
https://www.rbc.ru/rbcfreenews/69a121f89a79479786654dda?from=newsfeed
Технологическая компания Block основателя Twitter Джека Дорси сократит свой штат более чем на 4 тыс. сотрудников (40% от всего штата) из-за внедрения искусственного интеллекта. Об этом сам Дорси сообщил на своей странице в социальной сети.
«Сегодня мы принимаем одно из самых сложных решений в истории нашей компании: мы сокращаем штат нашей организации почти вдвое, с более чем 10 тыс. человек до немногим менее 6 тыс. Это означает, что более 4 тыс. из вас просят уйти или перейти к консультациям», — написал бизнесмен.
Дорси также отметил, что этот шаг не обусловлен проблемами в компании, и подчеркнул, что ее прибыль и рентабельность растут. По словам бизнесмена, причиной такого решения стали новые технологии, используемые в работе Block.
«Мы уже видим, что инструменты аналитики, которые мы создаем и используем, в сочетании с более компактными командами позволяют внедрять новый подход к работе, который в корне меняет представление о создании и управлении компанией», — уточнил основатель компании.
На фоне этого сообщения акции Block выросли более чем на 20%.
https://www.rbc.ru/rbcfreenews/69a121f89a79479786654dda?from=newsfeed
РБК
Финтех-компания Block решила уволить 40% сотрудников из-за ИИ
Технологическая компания Block основателя Twitter Джека Дорси сократит свой штат более чем на 4 тыс. сотрудников (40% от всего штата) из-за внедрения искусственного интеллекта. Об этом сам Дорси ...
🤡32🖕12😢3❤🔥2👎1
Вышла новая версия среды разработки NetBeans - Apache NetBeans 29 c поддержкой таких языков итехнологий программирования, как Java SE, Java EE, PHP, C/C++, JavaScript, Rust и Groovy. Готовые сборки доступны для Linux (snapcraft, flathub), Windows и macOS.
Основные изменения и дополнения в Apache NetBeans 29:
- исправлены ошибки и внесены улучшения для поддержки систем сборки Gradle, Maven и Ant
- исправлены ошибки и внесены улучшения для поддержки Java
- проведена оптимизация действий инспекции и преобразования кода
- проведена оптимизация Find Usages
- удалена поддержка Applet API
- исправлены ошибки и внесены улучшения для поддержки PHP
- добавлена возможность сворачивания heredoc и nowdoc блоков
- исправлено некорректное определение трейтов при использовании анонимных классов
- улучшения поддержки JavaScript
- добавлена проверка на дублирование приватных элементов классов
- добавлена проверка на недопустимые конструкторы
- исправлены ошибки и внесены улучшения для поддержки CSS
- добавлена поддержка image‑set
- исправлены ошибки парсинга псевдо‑элементов :host и :slotted
- исправлены ошибки и внесены улучшения для поддержки Git
- улучшено поведение диалогового окна переключения на определённую ревизию при неоднозначном идентификаторе коммита
- исправлен порядок отображения коммитов на вкладке истории для конкретного файла
- добавлена поддержка для .env файлов
- добавлена подсветка синтаксиса для jflex файлов
https://netbeans.apache.org/front/main/index.html
Основные изменения и дополнения в Apache NetBeans 29:
- исправлены ошибки и внесены улучшения для поддержки систем сборки Gradle, Maven и Ant
- исправлены ошибки и внесены улучшения для поддержки Java
- проведена оптимизация действий инспекции и преобразования кода
- проведена оптимизация Find Usages
- удалена поддержка Applet API
- исправлены ошибки и внесены улучшения для поддержки PHP
- добавлена возможность сворачивания heredoc и nowdoc блоков
- исправлено некорректное определение трейтов при использовании анонимных классов
- улучшения поддержки JavaScript
- добавлена проверка на дублирование приватных элементов классов
- добавлена проверка на недопустимые конструкторы
- исправлены ошибки и внесены улучшения для поддержки CSS
- добавлена поддержка image‑set
- исправлены ошибки парсинга псевдо‑элементов :host и :slotted
- исправлены ошибки и внесены улучшения для поддержки Git
- улучшено поведение диалогового окна переключения на определённую ревизию при неоднозначном идентификаторе коммита
- исправлен порядок отображения коммитов на вкладке истории для конкретного файла
- добавлена поддержка для .env файлов
- добавлена подсветка синтаксиса для jflex файлов
https://netbeans.apache.org/front/main/index.html
netbeans.apache.org
Welcome to Apache NetBeans
👍2👎1🥰1👏1
Добрались уже и до автомобилей: «VK Видео», «VK Музыка» и «Дзен» установлены в каждом пятом новом китайском автомобиле в России
VK устанавливает свои сервисы в мультимедийные системы автомобилей, продаваемых в России, с конца 2024 года
Медиасервисы VK интегрированы в 20% новых китайских автомобилей, официально поставляемых в Россию в 2025 году. Приложения «VK Видео», «VK Музыка» и «Дзен» доступны более чем в 120 тысячах машин брендов Chery, Omoda, Jaecoo, Changan, Exeed, GAC, Voyah, Aito Seres.
Самыми частыми сценариями потребления контента в VK Видео является фоновый просмотр шоу на том же экране, где обычно находятся картографические и другие развлекательные сервисы, просмотр видео водителем в стационарном положении автомобиля или детьми на заднем сидении. Наиболее востребованными форматами видео для просмотра в автомобиле стали шоу и детский контент.
https://vk.company/ru/press/releases/12239/
VK устанавливает свои сервисы в мультимедийные системы автомобилей, продаваемых в России, с конца 2024 года
Медиасервисы VK интегрированы в 20% новых китайских автомобилей, официально поставляемых в Россию в 2025 году. Приложения «VK Видео», «VK Музыка» и «Дзен» доступны более чем в 120 тысячах машин брендов Chery, Omoda, Jaecoo, Changan, Exeed, GAC, Voyah, Aito Seres.
Самыми частыми сценариями потребления контента в VK Видео является фоновый просмотр шоу на том же экране, где обычно находятся картографические и другие развлекательные сервисы, просмотр видео водителем в стационарном положении автомобиля или детьми на заднем сидении. Наиболее востребованными форматами видео для просмотра в автомобиле стали шоу и детский контент.
https://vk.company/ru/press/releases/12239/
vk.company
VK / Медиасервисы VK установлены в каждом пятом новом китайском автомобиле
В 2025 году медиасервисы VK были установлены на 20% новых легковых китайских автомобилей, официально продающихся в России. Приложения VK Видео, VK Музыка и Дзен появились более чем на 120 тыс. машин брендов Chery, Omoda, Jaecoo, Changan, Exeed, GAC, Voyah…
🤮29👍2🤡2🤔1
Пользователи сообщили о сбое в работе сайта Роскомнадзора
Согласно сообщениям СМИ, официальный сайт Роскомнадзора перестал открываться у части пользователей в России. Некоторые посетители сайта сообщают, что он работает, но страницы загружаются медленно.
Жалобы на сбой при доступе к сайту РКН начали появляться после 10:00 мск на профильных ресурсах, а сообщения о неполадках в работе сайта РКН поступают от пользователей из разных регионов страны.
https://www.kommersant.ru/doc/8476250
Согласно сообщениям СМИ, официальный сайт Роскомнадзора перестал открываться у части пользователей в России. Некоторые посетители сайта сообщают, что он работает, но страницы загружаются медленно.
Жалобы на сбой при доступе к сайту РКН начали появляться после 10:00 мск на профильных ресурсах, а сообщения о неполадках в работе сайта РКН поступают от пользователей из разных регионов страны.
https://www.kommersant.ru/doc/8476250
Коммерсантъ
Пользователи Рунета сообщили о сбое на сайте Роскомнадзора
Подробнее на сайте
😁32🎉14🔥8❤2👏1😱1🤡1
Хакеры атаковали ресурсы РКН и Минобороны
Как ранее сообщалось, сайт Роскомнадзора оказался недоступен. Оказалось, что информационные ресурсы Роскомнадзора и Минобороны России подверглись DDoS-атаке. Атакующие серверы расположены преимущественно в России, а также в Китае, США, Нидерландах и Великобритании, сообщила пресс-служба РКН.
В РКН сообщили, что DDoS-атака началась 27 февраля в 09:11 мск. Помимо ресурсов Минобороны и РКН, хакеры атаковали инфраструктуру Главного радиочастотного центра (ФГУП «ГРЧЦ»). Скорость атаки достигает 36,9 млн пакетов в секунду, а мощность — 33 Гбит/с.
«Осуществляется сложная мультивекторная атака на разных сетевых уровнях, в том числе с имитацией действий пользователей»,— сообщили в ведомстве
Специалисты центра мониторинга и управления сетью связи общего пользования (ЦМУ ССОП) отделили вредоносный трафик и направили на серверы очистки. Они пытаются локализовать источники атаки и места расположения ботнетов.
https://www.kommersant.ru/doc/8476580
Как ранее сообщалось, сайт Роскомнадзора оказался недоступен. Оказалось, что информационные ресурсы Роскомнадзора и Минобороны России подверглись DDoS-атаке. Атакующие серверы расположены преимущественно в России, а также в Китае, США, Нидерландах и Великобритании, сообщила пресс-служба РКН.
В РКН сообщили, что DDoS-атака началась 27 февраля в 09:11 мск. Помимо ресурсов Минобороны и РКН, хакеры атаковали инфраструктуру Главного радиочастотного центра (ФГУП «ГРЧЦ»). Скорость атаки достигает 36,9 млн пакетов в секунду, а мощность — 33 Гбит/с.
«Осуществляется сложная мультивекторная атака на разных сетевых уровнях, в том числе с имитацией действий пользователей»,— сообщили в ведомстве
Специалисты центра мониторинга и управления сетью связи общего пользования (ЦМУ ССОП) отделили вредоносный трафик и направили на серверы очистки. Они пытаются локализовать источники атаки и места расположения ботнетов.
https://www.kommersant.ru/doc/8476580
Коммерсантъ
Хакеры атаковали ресурсы РКН и Минобороны
Подробнее на сайте
❤33👍11👻5💘4🤝2
This media is not supported in your browser
VIEW IN TELEGRAM
Как работает бекап с шардингом базы данных и без шардинга
❤8🫡5👍3🔥1👾1
Ученые: мозг «портится» из-за коротких видео. Нейросети также влияют на работу мозга негативно.
Согласно одному из исследований, именно соцсети причиняют наибольший вред мозгу. Эксперты выяснили, что короткие видео негативно влияют на внимание, память и психическое здоровье. Чрезмерный просмотр такого контента ухудшает когнитивные способности с концентрацией внимания и повышает тревожность.
Также опасны нейросети. Ученые провели эксперимент и выяснили, что студенты, которые активно использовали чат-боты, не запоминали информацию, поэтому даже не могли процитировать собственные сочинения, а их мозг был наименее активным.
Эксперты дали несколько советов, как улучшить ситуацию. Так, не стоит использовать любые устройства с экранами в спальне. Кроме того, можно включать различные ограничения для приложений с бесконечной прокрутки ленты по типу TikTok. Также не рекомендуется постоянно пользоваться чат-ботами, потому что слишком большая легкость вредна для мозга. «Нам нужно немного трения, усилий, вызова. Это часть обучения», — подчеркнули специалисты.
https://www.washingtonpost.com/wellness/2026/02/20/brain-rot-social-media/
Согласно одному из исследований, именно соцсети причиняют наибольший вред мозгу. Эксперты выяснили, что короткие видео негативно влияют на внимание, память и психическое здоровье. Чрезмерный просмотр такого контента ухудшает когнитивные способности с концентрацией внимания и повышает тревожность.
Также опасны нейросети. Ученые провели эксперимент и выяснили, что студенты, которые активно использовали чат-боты, не запоминали информацию, поэтому даже не могли процитировать собственные сочинения, а их мозг был наименее активным.
Эксперты дали несколько советов, как улучшить ситуацию. Так, не стоит использовать любые устройства с экранами в спальне. Кроме того, можно включать различные ограничения для приложений с бесконечной прокрутки ленты по типу TikTok. Также не рекомендуется постоянно пользоваться чат-ботами, потому что слишком большая легкость вредна для мозга. «Нам нужно немного трения, усилий, вызова. Это часть обучения», — подчеркнули специалисты.
https://www.washingtonpost.com/wellness/2026/02/20/brain-rot-social-media/
The Washington Post
Is ‘brain rot’ real? How too much time online can affect your mind.
Research suggests that high use of social media and AI chat tools may affect your attention and memory. But there is something you can do about it.
👍24💯12❤🔥3❤1👎1
Google выпустил вторую бета-версию ОС Android 17. В Android 17 Beta 2 появились новые функции, направленные на улучшение многозадачности, безопасности, удобства разработки и взаимодействия между устройствами. Некоторые из ключевых нововведений:
1. Режим многозадачности Bubbles. Позволяет свернуть приложение в небольшое плавающее окно, которое можно перемещать по экрану. Чтобы активировать функцию, нужно долго нажимать на иконку приложения на рабочем столе. На устройствах с большим экраном (планшетах, складных смартфонах) появилась специальная панель Bubbles Bar в панели задач, где можно упорядочивать и управлять этими окнами. Пока неясно, будет ли функция доступна на обычных смартфонах с небольшим экраном.
2. Новый системный инструмент выбора контактов. При запросе доступа к контактам приложение теперь получает только те данные, которые пользователь явно выбрал (например, только email или номер телефона), и только в рамках одного сеанса. Это снижает потребность в широком разрешении READ_CONTACTS и поддерживает как личный, так и рабочий профиль.
3. API-интерфейс EyeDropper. Инструмент для разработчиков, который позволяет запрашивать цвет любого пикселя на экране без необходимости получать разрешения на захват экрана. Пользователь сам выбирает область для определения цвета через управляемый платформой интерфейс с «пипеткой», что обеспечивает безопасность.
4. API Handoff. Позволяет передать состояние приложения на находящееся поблизости другое Android-устройство (например, планшет) и продолжить работу там.
5. Новые API для навигации в помещениях:
* UWB DL-TDOA — определение позиции устройства внутри здания с помощью Wi-Fi для навигации в помещениях.
* Proximity Detection — обнаружение находящихся поблизости устройств через Wi-Fi.
6. Разрешение ACCESS_LOCAL_NETWORK. Ограничивает доступ приложений к локальной сети. Теперь для сканирования устройств в локальной сети (например, элементов умного дома) потребуется отдельное разрешение. Это защищает от скрытого отслеживания пользователей вредоносными программами.
7. Улучшенная обработка жестов тачпада в играх. Ранее тачпады передавали точные координаты касания пальцев, что вызывало проблемы в играх от первого лица. В Android 17 Beta 2 система по умолчанию распознаёт движения и прокрутку аналогично классической мыши. При этом прежний режим сохраняется, а для получения старых данных о точном положении пальцев разработчики могут явно запросить захват в «абсолютном» режиме.
8. Задержка доступа к SMS с OTP. Для сообщений с одноразовыми паролями (OTP) без форматов WebOTP или SMS Retriever доступ для большинства приложений задерживается на три часа. Исключение сделано для стандартных клиентов SMS, голосовых помощников и программ-компаньонов для подключённых устройств.
9. Объединение разделов настроек. Разделы «Аккаунты» и «Резервное копирование» объединены в единый пункт «Аккаунты и резервное копирование».
10. Визуальные изменения в шторке быстрых настроек. Индикаторы использования местоположения, камеры, микрофона, а также кнопка спутниковой связи стали более заметными.
Кроме того, в Android 17 Beta 2 были исправлены ошибки, обнаруженные в предыдущей тестовой сборке. Например, устранены проблемы с случайным перезапуском приложений, зависаниями интерфейса, ошибками в отображении списка запущенных приложений и другие.
https://android-developers.googleblog.com/2026/02/the-second-beta-of-android-17.html
1. Режим многозадачности Bubbles. Позволяет свернуть приложение в небольшое плавающее окно, которое можно перемещать по экрану. Чтобы активировать функцию, нужно долго нажимать на иконку приложения на рабочем столе. На устройствах с большим экраном (планшетах, складных смартфонах) появилась специальная панель Bubbles Bar в панели задач, где можно упорядочивать и управлять этими окнами. Пока неясно, будет ли функция доступна на обычных смартфонах с небольшим экраном.
2. Новый системный инструмент выбора контактов. При запросе доступа к контактам приложение теперь получает только те данные, которые пользователь явно выбрал (например, только email или номер телефона), и только в рамках одного сеанса. Это снижает потребность в широком разрешении READ_CONTACTS и поддерживает как личный, так и рабочий профиль.
3. API-интерфейс EyeDropper. Инструмент для разработчиков, который позволяет запрашивать цвет любого пикселя на экране без необходимости получать разрешения на захват экрана. Пользователь сам выбирает область для определения цвета через управляемый платформой интерфейс с «пипеткой», что обеспечивает безопасность.
4. API Handoff. Позволяет передать состояние приложения на находящееся поблизости другое Android-устройство (например, планшет) и продолжить работу там.
5. Новые API для навигации в помещениях:
* UWB DL-TDOA — определение позиции устройства внутри здания с помощью Wi-Fi для навигации в помещениях.
* Proximity Detection — обнаружение находящихся поблизости устройств через Wi-Fi.
6. Разрешение ACCESS_LOCAL_NETWORK. Ограничивает доступ приложений к локальной сети. Теперь для сканирования устройств в локальной сети (например, элементов умного дома) потребуется отдельное разрешение. Это защищает от скрытого отслеживания пользователей вредоносными программами.
7. Улучшенная обработка жестов тачпада в играх. Ранее тачпады передавали точные координаты касания пальцев, что вызывало проблемы в играх от первого лица. В Android 17 Beta 2 система по умолчанию распознаёт движения и прокрутку аналогично классической мыши. При этом прежний режим сохраняется, а для получения старых данных о точном положении пальцев разработчики могут явно запросить захват в «абсолютном» режиме.
8. Задержка доступа к SMS с OTP. Для сообщений с одноразовыми паролями (OTP) без форматов WebOTP или SMS Retriever доступ для большинства приложений задерживается на три часа. Исключение сделано для стандартных клиентов SMS, голосовых помощников и программ-компаньонов для подключённых устройств.
9. Объединение разделов настроек. Разделы «Аккаунты» и «Резервное копирование» объединены в единый пункт «Аккаунты и резервное копирование».
10. Визуальные изменения в шторке быстрых настроек. Индикаторы использования местоположения, камеры, микрофона, а также кнопка спутниковой связи стали более заметными.
Кроме того, в Android 17 Beta 2 были исправлены ошибки, обнаруженные в предыдущей тестовой сборке. Например, устранены проблемы с случайным перезапуском приложений, зависаниями интерфейса, ошибками в отображении списка запущенных приложений и другие.
https://android-developers.googleblog.com/2026/02/the-second-beta-of-android-17.html
Android Developers Blog
The Second Beta of Android 17
News and insights on the Android platform, developer tools, and events.
❤4👍2🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Эволюция мобильных телефонов с 1991 по 2020-е года
🔥29❤4👍4👎1
Как работает SSH
(продолжение предыдущего поста)
SSH (Secure Shell) обеспечивает безопасное удалённое управление операционной системой с использованием шифрования, обеспечивая защищённый обмен данными между клиентом и сервером благодаря:
- согласованию версий и алгоритмов;
- обмену ключами и расчёту общего сеансового ключа;
- аутентификации с использованием пар публичных и приватных ключей;
- шифрованию всех передаваемых данных с помощью сеансового ключа.
Процесс работы SSH можно разделить на несколько этапов, как показано на схеме:
1. Установление соединения (Connection Establishment)
- SSH-сервер слушает запросы на подключение (шаг 1: «Listens to connection requests»).
- SSH-клиент отправляет запрос на соединение (шаг 2: «Sends a connection request»).
- Устанавливается TCP-соединение между клиентом и сервером (шаг 3: «Establishes a TCP connection»).
2. Согласование версии (Version Negotiation)
- Сервер отправляет список поддерживаемых версий протокола SSH (шаг 4: «Sends the supported versions»).
- Клиент отвечает, указывая версию, которую будет использовать (шаг 5: «Responds with the version to be used»).
- Сервер проверяет, успешна ли negotiation версии (шаг 6: «Checks whether the version negotiation is successful»).
3. Согласование алгоритмов (Algorithm Negotiation)
- Клиент отправляет информацию о поддерживаемых алгоритмах шифрования (шаг 7: «Sends information about the supported algorithms»).
- Клиент и сервер согласовывают алгоритмы, которые будут использоваться для шифрования и аутентификации (шаг 8: «Negotiates various algorithms in sequence»).
4. Обмен ключами (Key Exchange)
- Сервер отправляет клиенту простые числа (G, P) и свой публичный ключ (y) (шаг 10: «Sends prime numbers G, P, and server public key y»).
- Клиент отправляет свой публичный ключ (x) (шаг 11: «Sends client public key x»).
5. Расчёт сеансового ключа (Session Key Calculation)
- Клиент вычисляет сеансовый ключ (K), используя:
- публичный ключ сервера (y);
- свой приватный ключ (a) (отмечено как шаг 12: «Calculates the session key K based on the server public key y and the client private key a»).
- Сервер вычисляет тот же сеансовый ключ (K), используя:
- публичный ключ клиента (x);
- свой приватный ключ (b) (отмечено как шаг 12: «Calculates the session key K based on the client public x and the server private key b»).
6. Аутентификация пользователя (User Authentication / Key Authentication)
- Клиент использует свой приватный ключ для подписи сообщений (шаг 13: «Uses the client private key for signature»).
- Клиент отправляет подписанные сообщения на сервер (шаг 14: «Sends signed messages»).
- Сервер использует публичный ключ клиента для проверки подписи (шаг 15: «Uses the client public key for signature verification»).
7. Запрос сеанса (Session Request)
- После успешной аутентификации клиент отправляет запрос на начало сеанса (шаг 16: «Sends a session request»).
- Сервер отвечает на запрос, подтверждая начало сеанса (шаг 17: «Responds to the session request»).
8. Взаимодействие в сеансе (Session Interaction)
- Клиент отправляет зашифрованный запрос команды на сервер (шаг 18: «Sends an encrypted command request»).
- Сервер расшифровывает запрос с помощью сеансового ключа (шаг 19: «Decrypts the command request using the session key»), выполняет команду и отправляет зашифрованный результат обратно клиенту (шаг 20: «Sends the encrypted execution result»).
- Клиент расшифровывает результат с помощью сеансового ключа и отображает его в терминале (шаг 21: «Uses the session key to decrypt the execution result and displays it on the terminal»).
(продолжение предыдущего поста)
SSH (Secure Shell) обеспечивает безопасное удалённое управление операционной системой с использованием шифрования, обеспечивая защищённый обмен данными между клиентом и сервером благодаря:
- согласованию версий и алгоритмов;
- обмену ключами и расчёту общего сеансового ключа;
- аутентификации с использованием пар публичных и приватных ключей;
- шифрованию всех передаваемых данных с помощью сеансового ключа.
Процесс работы SSH можно разделить на несколько этапов, как показано на схеме:
1. Установление соединения (Connection Establishment)
- SSH-сервер слушает запросы на подключение (шаг 1: «Listens to connection requests»).
- SSH-клиент отправляет запрос на соединение (шаг 2: «Sends a connection request»).
- Устанавливается TCP-соединение между клиентом и сервером (шаг 3: «Establishes a TCP connection»).
2. Согласование версии (Version Negotiation)
- Сервер отправляет список поддерживаемых версий протокола SSH (шаг 4: «Sends the supported versions»).
- Клиент отвечает, указывая версию, которую будет использовать (шаг 5: «Responds with the version to be used»).
- Сервер проверяет, успешна ли negotiation версии (шаг 6: «Checks whether the version negotiation is successful»).
3. Согласование алгоритмов (Algorithm Negotiation)
- Клиент отправляет информацию о поддерживаемых алгоритмах шифрования (шаг 7: «Sends information about the supported algorithms»).
- Клиент и сервер согласовывают алгоритмы, которые будут использоваться для шифрования и аутентификации (шаг 8: «Negotiates various algorithms in sequence»).
4. Обмен ключами (Key Exchange)
- Сервер отправляет клиенту простые числа (G, P) и свой публичный ключ (y) (шаг 10: «Sends prime numbers G, P, and server public key y»).
- Клиент отправляет свой публичный ключ (x) (шаг 11: «Sends client public key x»).
5. Расчёт сеансового ключа (Session Key Calculation)
- Клиент вычисляет сеансовый ключ (K), используя:
- публичный ключ сервера (y);
- свой приватный ключ (a) (отмечено как шаг 12: «Calculates the session key K based on the server public key y and the client private key a»).
- Сервер вычисляет тот же сеансовый ключ (K), используя:
- публичный ключ клиента (x);
- свой приватный ключ (b) (отмечено как шаг 12: «Calculates the session key K based on the client public x and the server private key b»).
6. Аутентификация пользователя (User Authentication / Key Authentication)
- Клиент использует свой приватный ключ для подписи сообщений (шаг 13: «Uses the client private key for signature»).
- Клиент отправляет подписанные сообщения на сервер (шаг 14: «Sends signed messages»).
- Сервер использует публичный ключ клиента для проверки подписи (шаг 15: «Uses the client public key for signature verification»).
7. Запрос сеанса (Session Request)
- После успешной аутентификации клиент отправляет запрос на начало сеанса (шаг 16: «Sends a session request»).
- Сервер отвечает на запрос, подтверждая начало сеанса (шаг 17: «Responds to the session request»).
8. Взаимодействие в сеансе (Session Interaction)
- Клиент отправляет зашифрованный запрос команды на сервер (шаг 18: «Sends an encrypted command request»).
- Сервер расшифровывает запрос с помощью сеансового ключа (шаг 19: «Decrypts the command request using the session key»), выполняет команду и отправляет зашифрованный результат обратно клиенту (шаг 20: «Sends the encrypted execution result»).
- Клиент расшифровывает результат с помощью сеансового ключа и отображает его в терминале (шаг 21: «Uses the session key to decrypt the execution result and displays it on the terminal»).
Telegram
METANIT.COM
Как работает SSH
(продолжение в следующем посте)
(продолжение в следующем посте)
🔥6👍4❤🔥3❤1
В Калифорнии принят закон об интеграции в ОС API для проверки возраста
Сенат штата Калифорния одобрил и губернатор затем подписал закон, который предписывает добавbnm в операционные системы возможности для указания возраста пользователя на этапе регистрации учётной записи и предоставления приложениям программного интерфейса для определения возраста текущего пользователя.
Законопроект вступит в силу 1 января 2027 года и, судя по всему, касается в том числе Windows, MacOS и Linux. Аналогичный законопроект находится на рассмотрении в штате Колорадо.
В законопроекте указано, что ответственные за разработку, лицензирование или установку операционной системы на компьютеры, мобильную технику и прочие устройства должны предоставить при создании учётной записи интерфейс для ввода данных о дате рождения и возрасте регистрируемого пользователя с целью передачи информации о категории возраста приложениям, получаемым через каталоги-магазины приложений. Под каталогом-магазином понимается любой публичный сайт, приложение, online-сервис или платформа для загрузки программ, созданных сторонними разработчиками.
Предполагается, что родители будут указывать возраст детей при регистрации их учётных записей, а приложения учитывать эту информацию при предоставлении доступа к контенту для взрослых.
Загруженные и запущенные приложения должны иметь возможность получать от операционной системы информацию о возрасте в 4 градациях: младше 13 лет, от 13 до 16 лет, от 16 до 18 лет, 18 лет и старше.
Разработчик приложения должен использовать полученную информацию о возрасте для соблюдения законодательства о защите детей в интернете.
https://news.ycombinator.com/item?id=47181208
Сенат штата Калифорния одобрил и губернатор затем подписал закон, который предписывает добавbnm в операционные системы возможности для указания возраста пользователя на этапе регистрации учётной записи и предоставления приложениям программного интерфейса для определения возраста текущего пользователя.
Законопроект вступит в силу 1 января 2027 года и, судя по всему, касается в том числе Windows, MacOS и Linux. Аналогичный законопроект находится на рассмотрении в штате Колорадо.
В законопроекте указано, что ответственные за разработку, лицензирование или установку операционной системы на компьютеры, мобильную технику и прочие устройства должны предоставить при создании учётной записи интерфейс для ввода данных о дате рождения и возрасте регистрируемого пользователя с целью передачи информации о категории возраста приложениям, получаемым через каталоги-магазины приложений. Под каталогом-магазином понимается любой публичный сайт, приложение, online-сервис или платформа для загрузки программ, созданных сторонними разработчиками.
Предполагается, что родители будут указывать возраст детей при регистрации их учётных записей, а приложения учитывать эту информацию при предоставлении доступа к контенту для взрослых.
Загруженные и запущенные приложения должны иметь возможность получать от операционной системы информацию о возрасте в 4 градациях: младше 13 лет, от 13 до 16 лет, от 16 до 18 лет, 18 лет и старше.
Разработчик приложения должен использовать полученную информацию о возрасте для соблюдения законодательства о защите детей в интернете.
https://news.ycombinator.com/item?id=47181208
🤣18🤡6❤1
Стратегии масштабирования распределённых систем
(продолжение предыдущего поста)
1. Stateless Services (сервисы без хранения состояния)
* суть: сервисы не сохраняют состояние между запросами — каждый запрос обрабатывается независимо;
* преимущества: лёгкость горизонтального масштабирования, так как экземпляры сервисов можно добавлять без влияния на работу других;
* реализация: размещение нескольких экземпляров сервисов в разных зонах доступности (AZ — Availability Zone), с сохранением состояния в отдельной базе данных;
* пример: микросервисы, обрабатывающие HTTP-запросы без сохранения сессии.
2. Horizontal Scaling (горизонтальное масштабирование)
* суть: добавление дополнительных серверов/инстансов для распределения нагрузки;
* механизм: использование группы автоматического масштабирования (Auto Scaling Group), которая добавляет/удаляет инстансы в зависимости от нагрузки;
* параметры:
* Desired Capacity (желаемая ёмкость) — целевое количество инстансов;
* Maximum Capacity (максимальная ёмкость) — лимит на количество инстансов;
* Scale out as needed (расширение по мере необходимости) — автоматическое добавление инстансов при росте нагрузки;
* примеры: веб-серверы, микросервисы в Kubernetes.
3. Load Balancing (балансировка нагрузки)
* суть: распределение входящих запросов между несколькими серверами для равномерной загрузки;
* задачи:
* предотвращение перегрузки отдельных серверов;
* повышение отказоустойчивости (при выходе из строя одного сервера нагрузка перераспределяется);
* сокращение времени отклика;
* компоненты: балансировщик нагрузки (Load Balancer), который направляет запросы на доступные серверы;
* примеры: NGINX, AWS ELB (Elastic Load Balancer), HAProxy.
4. Caching (кэширование)
* суть: хранение часто используемых данных в быстрой памяти (кэше) для ускорения доступа;
* этапы:
1. Read from Cache (чтение из кэша) — сначала система проверяет наличие данных в кэше;
2. Read from Database (чтение из базы данных) — если данных нет в кэше, они загружаются из БД;
3. Update Cache (обновление кэша) — полученные данные сохраняются в кэше для последующих запросов;
* технологии: Redis, Memcached, кэширование на уровне приложения;
* преимущества: снижение нагрузки на БД, ускорение работы приложения.
5. Database Replication (репликация базы данных)
* суть: создание копий (реплик) базы данных для распределения нагрузки и повышения доступности;
* архитектура:
* Primary (основная БД) — принимает записи (writes) и синхронизирует изменения с репликами;
* Replica (реплики) — копируют данные из Primary, обрабатывают чтения (reads);
* преимущества:
* повышение доступности (при сбое Primary запросы перенаправляются на реплики);
* распределение нагрузки (чтения распределяются между репликами);
* резервное копирование данных.
* примеры: MySQL Replication, PostgreSQL Streaming Replication.
6. Database Sharding (шардирование базы данных)
* суть: разделение базы данных на части (шарды) и размещение их на разных серверах для горизонтального масштабирования;
* механизм: данные распределяются по ключу (например, ID пользователя), чтобы запросы обрабатывались на соответствующем шарде;
* преимущества:
* масштабирование write-операций (записи распределяются по шардам);
* ускорение запросов за счёт параллельной обработки;
* управление объёмом данных (каждый шард обрабатывается отдельным сервером).
* недостатки: усложнение логики запросов (особенно для операций, затрагивающих несколько шардов).
* примеры: MongoDB Sharding, Cassandra.
(продолжение предыдущего поста)
1. Stateless Services (сервисы без хранения состояния)
* суть: сервисы не сохраняют состояние между запросами — каждый запрос обрабатывается независимо;
* преимущества: лёгкость горизонтального масштабирования, так как экземпляры сервисов можно добавлять без влияния на работу других;
* реализация: размещение нескольких экземпляров сервисов в разных зонах доступности (AZ — Availability Zone), с сохранением состояния в отдельной базе данных;
* пример: микросервисы, обрабатывающие HTTP-запросы без сохранения сессии.
2. Horizontal Scaling (горизонтальное масштабирование)
* суть: добавление дополнительных серверов/инстансов для распределения нагрузки;
* механизм: использование группы автоматического масштабирования (Auto Scaling Group), которая добавляет/удаляет инстансы в зависимости от нагрузки;
* параметры:
* Desired Capacity (желаемая ёмкость) — целевое количество инстансов;
* Maximum Capacity (максимальная ёмкость) — лимит на количество инстансов;
* Scale out as needed (расширение по мере необходимости) — автоматическое добавление инстансов при росте нагрузки;
* примеры: веб-серверы, микросервисы в Kubernetes.
3. Load Balancing (балансировка нагрузки)
* суть: распределение входящих запросов между несколькими серверами для равномерной загрузки;
* задачи:
* предотвращение перегрузки отдельных серверов;
* повышение отказоустойчивости (при выходе из строя одного сервера нагрузка перераспределяется);
* сокращение времени отклика;
* компоненты: балансировщик нагрузки (Load Balancer), который направляет запросы на доступные серверы;
* примеры: NGINX, AWS ELB (Elastic Load Balancer), HAProxy.
4. Caching (кэширование)
* суть: хранение часто используемых данных в быстрой памяти (кэше) для ускорения доступа;
* этапы:
1. Read from Cache (чтение из кэша) — сначала система проверяет наличие данных в кэше;
2. Read from Database (чтение из базы данных) — если данных нет в кэше, они загружаются из БД;
3. Update Cache (обновление кэша) — полученные данные сохраняются в кэше для последующих запросов;
* технологии: Redis, Memcached, кэширование на уровне приложения;
* преимущества: снижение нагрузки на БД, ускорение работы приложения.
5. Database Replication (репликация базы данных)
* суть: создание копий (реплик) базы данных для распределения нагрузки и повышения доступности;
* архитектура:
* Primary (основная БД) — принимает записи (writes) и синхронизирует изменения с репликами;
* Replica (реплики) — копируют данные из Primary, обрабатывают чтения (reads);
* преимущества:
* повышение доступности (при сбое Primary запросы перенаправляются на реплики);
* распределение нагрузки (чтения распределяются между репликами);
* резервное копирование данных.
* примеры: MySQL Replication, PostgreSQL Streaming Replication.
6. Database Sharding (шардирование базы данных)
* суть: разделение базы данных на части (шарды) и размещение их на разных серверах для горизонтального масштабирования;
* механизм: данные распределяются по ключу (например, ID пользователя), чтобы запросы обрабатывались на соответствующем шарде;
* преимущества:
* масштабирование write-операций (записи распределяются по шардам);
* ускорение запросов за счёт параллельной обработки;
* управление объёмом данных (каждый шард обрабатывается отдельным сервером).
* недостатки: усложнение логики запросов (особенно для операций, затрагивающих несколько шардов).
* примеры: MongoDB Sharding, Cassandra.
❤4👍2🤝2🤮1
7. Async Processing (асинхронная обработка)
* суть: отделение обработки задач от основного потока выполнения для повышения производительности и масштабируемости;
* архитектура:
* Server (сервер) — принимает запросы и помещает задачи в очередь;
* Workers (воркеры) — отдельные процессы/контейнеры, которые обрабатывают задачи из очереди;
* компоненты:
* очередь задач (Task Queue) — промежуточное хранилище для задач (например, RabbitMQ, Kafka);
* воркеры — обрабатывают задачи параллельно;
* преимущества:
* снижение нагрузки на основной сервер;
* возможность масштабирования обработки (добавление воркеров при росте нагрузки);
* устойчивость к пикам нагрузки (задачи накапливаются в очереди и обрабатываются постепенно).
* примеры: обработка платежей, отправка уведомлений, ETL-процессы.
Эти паттерны можно комбинировать для достижения оптимальной масштабируемости. Например, использовать горизонтальное масштабирование и балансировку нагрузки для сервисов, кэширование для ускорения доступа к данным, шардирование и репликацию для масштабирования базы данных, а асинхронную обработку для ресурсоёмких задач. Выбор паттерна зависит от конкретных требований системы: характера нагрузки, типа данных, требований к доступности и консистентности.
* суть: отделение обработки задач от основного потока выполнения для повышения производительности и масштабируемости;
* архитектура:
* Server (сервер) — принимает запросы и помещает задачи в очередь;
* Workers (воркеры) — отдельные процессы/контейнеры, которые обрабатывают задачи из очереди;
* компоненты:
* очередь задач (Task Queue) — промежуточное хранилище для задач (например, RabbitMQ, Kafka);
* воркеры — обрабатывают задачи параллельно;
* преимущества:
* снижение нагрузки на основной сервер;
* возможность масштабирования обработки (добавление воркеров при росте нагрузки);
* устойчивость к пикам нагрузки (задачи накапливаются в очереди и обрабатываются постепенно).
* примеры: обработка платежей, отправка уведомлений, ETL-процессы.
Эти паттерны можно комбинировать для достижения оптимальной масштабируемости. Например, использовать горизонтальное масштабирование и балансировку нагрузки для сервисов, кэширование для ускорения доступа к данным, шардирование и репликацию для масштабирования базы данных, а асинхронную обработку для ресурсоёмких задач. Выбор паттерна зависит от конкретных требований системы: характера нагрузки, типа данных, требований к доступности и консистентности.
Telegram
METANIT.COM
Стратегии масштабирования распределённых систем
(продолжение в следующем посте)
(продолжение в следующем посте)
❤5🔥3👍2🤮1