Information
- Rating
- 11,645-th
- Registered
- Activity
Specialization
Software Architect, Low level system programming
Lead
From 5,000 $
Git
English
Research work
Software development
Programming microcontrollers
Assembler
C
C++
Specialists recruitment
Interview
Карты же векторные, почему бы не сделать цвета разных элементов (таких как дороги те же) настраиваемыми. Для дневной и ночной темы разумеется. И еще размеры шрифтов тоже настраивамемыми - было бы вообще хорошо.
А чего ограничиваться только драйвером wifi? Когда уже запихнут простенький линух наконец? Очень бы помогло и при установке любых систем и тем более при восстановлении разных сбоев. Объем уже позволяет вроде. Простые сборки тоже есть.
Ситуацию с iOS не знаю, но в android штатного нет, а из предложений - только фильтр на базе vpn, что выглядит коряво, хотя бы потому что нельзя запустить второй vpn (кто-то решил, что подключенный vpn может быть только один). Поставить более полноценный сторонний firewall можно только на рутованный аппарат.
Трекеры они такие, да. Собирают всё до чего можно дотянуться, включая местоположение, серийники, имена точек подключений и даже список софта, если дадут. Вот поэтому в телефоне просто обязан быть firewall, и многим приложениям, кому это не жизненно важно, надо просто запрещать выход в сеть. К сожалению, firewall по умолчанию отсутствует и это только провоцирует подобные проблемы с утечкой данных.
Какая-то сомнительная функция, надеюсь ее можно будет отключить, если нет - придется не обновляться. Почему сомнительная: как правильно уже заметили сами безопасники рекомендуют ставить пин-код на симку, так что после перезагрузки не будет сети и не будет работать "поиск устройства" и удаленное стирание данных, не говоря уже о звонках, т. е. нашедший телефон банально не сможет взять трубку. Да и некоторые нужные приложения не смогут заработать после рестарта, т. е. прощай использование телефона как системы видеонаблюдения например.
Лучше бы вместо таких "костылей" чинили бы фатальный изъян в безопасности связанный с наличием BFU. Например используя множественные ключи для каждого приложения, этакое FBEv3 (ведь прошлые FDE и FBEv1 уже признаны плохими), а менеджмент ключей и саму расшифровку можно вести в трастзоне, чтобы ключ нигде не светился в самой системе.
Надеюсь не путем выпуска сим-карт всем клиентам банка в "добровольном" порядке, как это было у банка на букву Т, чтобы потом не надо было их искать и блокировать.
То экран смерти переделывают зачем-то, то в соседней статье борются с bypassnro (локальными аккаунтами при установке) - там у них реальные баги уже давно закончились что-ли? Или у них прямо статистика есть что пользователи массово недовольны и станут счастливее от этой "перестановки кроватей"?
Можно сделать еще шаг вперед и наконец-то использовать схему с нулевой передачей знаний.
Как раз наоборот, база менеджера паролей - единая точка отказа: при ее компрометации вы рискуете большим числом паролей и другой информации. Базу может быть сложно взломать явно, но ничто не мешает подсмотреть (сдампить активную) или еще как-то получить доступ к ней. Можно не хранить в базе готовые пароли, а добавлять символы или как-то модифицировать их перед использованием - это не так удобно, но немного повышает безопасность.
p.s. в идеале вместо паролей нужно внедрять системы доказательства с нулевым разглашением, это бы еще сильнее подняло безопасность, но увы
Ну если прямо вместо СМС, то конечно да, а так сомнительный выбор при наличии открытых децентрализованных решений с таким же сквозным шифрованием
Это здорово конечно, но многие другие почтовые сервисы и сайты блокируют почту в/от протона, и поэтому тут надо выбирать под конкретные условия применения.
Странно, что при этом не упомянуты расширения типа ublock origin и подобные, одного DNS уже давно мало для блокировки рекламы.
э... какие-то дяди помимо вас читают всю вашу почту и это прямо конфиденциально и безопасно?
Спец-ядро - это звучит круто, но что если телефон даже разблокировать нельзя, какое уж там ядро прошивать? Остается рискованная замена всего soc, но это не то чтобы простая и дешевая операция и получается что телефон проще выбросить.
p.s. отдельные лучи известно чего всем компаниям запрещающим разблокировку
А вариант вернуть удаленку для желающих в принципе не рассматривается?
Вот у меня есть несколько старых смартфонов. Первая проблема - у большинства вздулись аккумуляторы и заменить их нельзя (не производят больше), от зарядки они не включаются и надо колхозить что-то не всегда тривиальное чтобы они включились, тем более каждый смартфон уникален. Еще один например есть - у него подыхает встроенная emmc, выглядит это как жуткие тормоза при работе, грузится он вообще минут 30. Еще один - после 3 лет работы проявился заводской брак: спонтанные перезагрузки раз в полчаса (в сервисе сказали "это не лечится" и надо менять плату, а их тоже больше не выпускают) - в остальном все очень шустро. И вот какое применение этим старым телефонам можно придумать?
А чтобы не надо было колхозить что-нибудь уникальное каждый раз надо повышать ремонтопригодность аппаратов - вот это реально помогло бы для переиспользования. Но пока рынок телефонов не насытился - этого не будет, как не будет и никакой массовой унификации комплектующих.
Я имел ввиду подключаемые диски, флешки, карточки и другие носители для которых есть вариант записи, чтобы было что защищать и переключать защиту. Устройства имеющие изначально только read-only разделы понятное дело нельзя сделать read/write поэтому и проблемы с ними нет никакой.
Современные windows / macos по умолчанию монтируют все подключаемое как read/write, и не всегда тривиально поставить носитель в read-only на уровне ФС, особенно в windows. А если бы это было сделано просто и понятно для пользователей - было бы удобно, и специальные флешки/диски не нужны были бы.
Аккум в 33Ah выглядит конечно круто (интересно в самолет с таким пустят?), но по мне лучше таскать с собой powerbank потому что он будет независим от телефона и кроме того можно найти powerbank с цилиндрическими 18650/22650 а они не вздуваются со временем в отличии от плоских телефонных. А так лучше бы сделали съемные аккумуляторы - было бы больше пользы для походных условий.
Да, из-за потерь емкость банка будет ниже фактической на 10-15%, зато банки можно иметь разные по емкости и весу в зависимости от ситуации, а тут всегда надо таскать кирпич, даже если это не нужно.
Горшочек, не вари.
Уже столько раз эту тему поднимали, причем большая часть статей - банальное нытьё со стороны работодателей. "Денег нет, но вы работайте, у нас еще печеньки есть и HR-бренд."
Никакого дефицита кадров нет, их переизбыток (отсюда и увольнения). Надежный индикатор дефицита - рост зарплат сильно выше инфляции. Еще надежный показатель дефицита - большая сговорчивость работодателей. Но ничего из этого не наблюдается. Причем, если нет денег, можно было бы мотивировать чем-то еще, той же удаленкой, например, но нет - сейчас модно всех слать в офис. И вот эта упертость и приносит часть проблем с "дефицитом кадров".
Несколько дополнений, хотя про это можно отдельную статью писать.
На примере экзотичных режимов моделей памяти в x86 легко понять почему указатель на код (функцию) может не совпадать размером с указателем на данные и их нельзя преобразовать один в другой.
Модели памяти используются до сих пор даже при разработке 64-битных программ на x86. Только смысл немного поменялся. Проблема в том, что в x86 нет прямой адресации всего доступного 64-битного (точнее 48-битного или сколько там сейчас тянут по максимуму?) адресного пространства ни для кода (прыжки, вызовы), ни для данных, а значит для генерации эффективного кода надо знать как далеко может "полезть" код и данные. Но обычно все компиляторы настроены на small модель в 64-битах (доступ в пределах 4Гб), редко кому нужна бывает полная адресация, но людям пишущим некоторые виды программ она бывает нужна и вот тогда начинается интересная возня.
Да на деле никто не борется с массовыми утечками. Ну или борется в стиле "утечки стой! раз два!". Наоборот сколько за последние годы было новых инициатив по сборку ПД в разные другие компиляции и базы? Причем на 99.9999% все эти базы бессмысленны с технической точки зрения и только увеличивают поверхность атак, утечек и всяких пробивов. Из того что реально происходит, можно сделать вывод, что задача стоит - собрать всё до чего можно дотянуться, не важно нужно оно или нет, а там глядишь и пригодится, а утечёт - плевать, всё равно всё что можно уже утекло не по одному разу.
Само по себе сканирование кода (фактически открытие страницы в интернете) это еще не приговор. Проблемы начинаются при вводе данных, паролей, и тем более всяких кодов из смс или уведомлений на телефоне - вот этого делать нельзя! А людям надо объяснить как выглядит подписка на канал, это не требует ввода никаких кодов.
С точки зрения развития безопасности, я все жду когда ввод устаревших паролей для аутентификации заменят на протоколы с нулевой передачей знаний, тогда исчезнет целый вектор атак связанных с кражей и вводом паролей на всяких фишинговых сайтах. Схема с нулевой передачей несложная в реализации и на порядок безопаснее паролей, но вот почему-то пароли применяются в 99.9% случаев, увы.
Проблема приватности намного глубже и шире, и ИИ тут вобщем ничего принципиально не меняет. Вы и сейчас без какого-либо ИИ вряд ли полностью можете быть уверены в том что происходит на телефоне. Один только софт разросся до неприличных размеров: прошивки могут занимать десятки гигабайт и провести даже банальный аудит такого объема довольно сложно. А пользователь может еще поставить несколько гигабайт софта дополнительно к системному. Но и железки не отстают, в телефонах уже около десятка специализированных процессоров (помимо основного) и некоторые из них вполне могут влиять на приватность данных, например модуль связи. Так что ИИ в этой части выглядит просто как еще один ингридиент в этот острый суп.