KDE представив власний ультрабук
{full-post-img}
KDE презентував перший ультрабук під власним брендом - KDE Slimbook. Пристрій поставляється зі встановленим робочим столом Plasma і додатками з набору програм KDE. Системне оточення засновано на пакетній базі Ubuntu 16.04 в збірці від проекту KDE neon.
Якщо зазвичай розробники KDE не мають змоги в процесі розробки контролювати сумісність і працездатність створюваного програмного забезпечення на конкретному обладнанні споживача, то у випадку з KDE Slimbook, всі пропоновані програми та оновлення досконально тестуються розробниками KDE для забезпечення високого рівня стабільності оточення і сумісності з обладнанням. Подібний підхід дозволяє вирішувати виникаючі проблеми не на основі скарг користувачів, а на стадії до отримання оновлень користувачем.
Вартість пристрою становить 729 € для моделі з процесором Intel i5-6200U і 849 € для моделі з процесором Intel i7-6500U. Основні характеристики:
-
GPU: Intel Graphics HD 520;
-
ОЗП: 4, 8 або 16 Гбайт;
-
SSD: Samsung / Crucial mSata 120, 250 або 500 Гбайт;
-
Екран: 13,3 "Full HD 1920 × 1080;
-
Гарантія: два роки;
-
Алюмінієвий корпус;
-
Bluetooth 4.0 з Intel 3160 або 7265 AC;
-
Wi-Fi: Intel Dual Band: 3160 або 7265 N або 7265 AC;
-
Веб-камера;
-
Два порти USB 3.0;
-
RJ45;
-
Mini HDMI;
-
Card Reader SD/MMC;
-
Розмір: 33 × 22 × 1,8 см (корпус і клавіатура дуже схожі на MacBook Air);
-
Вага: 1,36 кг;
-
Акумулятор: 6800 мА · год.
Facebook запропонував новий метод відновлення паролів
{full-post-img}
Інженери з компанії Facebook розробили новий протокол DelegatedRecovery, призначений для відновлення паролів. Протокол надає сайтам можливість делегування функцій відновлення облікового запису через робочий обліковий запис, контрольований тим же користувачем, але розміщений в іншому сервісі. В якості експерименту в обмеженому вигляді даний протокол випробувано в GitHub для організації відновлення доступу при наявності робочого облікового запису в Facebook, і може стати в нагоді в разі втрати телефону або токена, що використовуються під час двофакторної аутентифікації на GitHub.
Протокол націлений на усунення додаткових загроз, що виникають при використанні традиційних схем відновлення паролів, що маніпулюють відомими для конкретного користувача фактами з розряду "марка першого автомобіля" або використовують відправку коду відновлення через email/SMS. DelegatedRecovery дозволяє обійтися без прив'язки до email або номеру телефону, застосовуючи в якості фактора для відновлення контролю над обліковими даними наявність доступу до іншого довіреного сервісу. Наприклад, для відновлення входу в GitHub може використовуватися обліковий запис в Facebook.
Суть методу полягає в попередній генерації і збереженні на стороні іншої системи спеціального токена, що містить крипто-відбиток параметрів аутентифікації (в розглянутому прикладі GitHub за запитом користувача може створити зліпок облікових даних, після чого цей зліпок необхідно зберегти в акаунті цього ж користувача в Facebook). Всі дані в токені зашифровані і сторонній сервіс (в прикладі Facebook) не може отримати доступ до інформації. На стороні, що згенерувала токен системи (в прикладі GitHub) в прив'язці до користувача зберігається ідентифікатор токена і його стан. У разі якщо користувач втратить контроль над обліковим записом в GitHub він може скористатися раніше згенерованим токеном для підтвердження своїх прав на обліковий запис.
При необхідності відновлення втраченого доступу, користувач може увійти в Facebook і відправити в GitHub токен, який має фіксований невеликий час життя і обмежений за кількістю можливих спроб відновлення. Крім вмісту раніше збереженого токента, ключ відновлення також забезпечується цифровим підписом сервісу, яка підтверджує, що дані відправлені тим же користувачем, який колись зберіг токен. Інтенсивність застосування операції відновлення обмежена - якщо у випадку з отриманням контролю над email або смартфоном атакуючий може відразу атакувати всі інші облікові записи користувача, то отримавши контроль за аккаунтом в Facebook, він зможе формувати запити на відновлення, наприклад, не частіше одного разу на день.
В даний час для вивчення і обговорення доступний чорновий варіант специфікації протоколу, який поставляється під ліцензією Creative Commons Attribution 4.0. Найближчим часом планується опублікувати код еталонної реалізації протоколу для різних мов програмування, яка дозволить запровадити новий метод відновлення доступу на власному сайті.
Kernel.org припиняє підтримку FTP
Адміністратори інфраструктури kernel.org повідомили про рішення припинити підтримку протоколу FTP для доступу до основного архіву і FTP-дзеркал. Робота сервісу ftp://ftp.kernel.org/ буде припинена з 1 березня 2017 року, а сервіс ftp://mirrors.kernel.org/ з FTP-дзеркалами багатьох відомих проектів буде закрито 1 грудня 2017 року. Після цього часу доступ до ресурсів буде здійснюватися тільки по HTTP/HTTPS.
Як причини припинення підтримки FTP зазначається:
-
Неефективність протоколу і пов'язана з цим необхідність застосування обхідних шляхів в налаштуванні міжмережевих екранів і балансувальників навантаження;
-
Відсутність підтримки кешування і застосування акселераторів доступу. Наприклад, при доступі до архіву по HTTP застосовується мережа доставки контенту cdn.kernel.org, для FTP розробка подібної системи неможлива, що створює проблеми у розподілі навантаження на інфраструктуру;
-
Стагнація розробки додатків з реалізацією FTP і відсутність регулярних оновлень. Припинення використання FTP дозволить підвищити безпеку інфраструктури за рахунок скорочення публічно доступних сервісів.
Більшість VPN-додатків для Android не заслуговують на довіру
{full-post-img}
Опубліковано підсумки дослідження захищеності 283 мобільних додатків з реалізацією функцій VPN, представлених в каталозі Google Play. Відбір додатків був здійснений за запитом повноважень BIND_VPN_SERVICE. Результати перевершили всі очікування і дозволили зробити висновок, що в більшості випадків замість очікуваної захисту свого трафіку і посилення конфіденційності, користувач отримує неявні проблеми з безпекою, сумнівні гарантії збереження анонімності або навіть явні шкідливі дії і злив інформації зацікавленим третім особам.
Деякі факти:
-
У 18% вивчених VPN-додатків взагалі не використовується шифрування і весь трафік передається у відкритому вигляді. При використанні публічних або мереж, що не заслуговують довіри, користувач не захищений від MITM-атак;
-
16% VPN-додатків застосовують техніку прозорого проксінгу для модифікації транзитного HTTP-трафіку користувача, підставляючи або видаляючи заголовки або виконуючи перекодування зображень для прискорення їх завантаження за рахунок скорочення розміру.
-
У двох додатках здійснювалася підстановка в трафік JavaScript-коду для показу реклами на чужих сайтах і відстеження поведінки користувача;
-
Один з додатків (Hotspot-Shield) дублює запити до інтернет-магазинів на кілька партнерських рекламних сервісів;
-
Чотири додатки встановлювали в систему свої кореневі сертифікати, що застосовуються для організації перехоплення і дешифрування HTTPS-з'єднань;
-
84% додатків пропускають IPv6-трафік в обхід створюваного тунелю, а 66% безпосередньо відправляють запити до DNS, що дає зловмисникам можливість моніторингу або маніпуляції подібними запитами;
-
В описі 67% додатків в якості їх переваг було зазначено підвищення захисту приватних даних, при цьому обіцянки не завадили розробникам 75% з цих додатків задіяти сторонні бібліотеки для відстеження активності користувача в online, а 82% випадків запросити при установці додатка права доступу до ресурсів, що містить конфіденційні дані, такі як параметри облікового запису або текстові повідомлення;
-
37% додатків налічують понад 500 тисяч установок, а 25% мають рейтинг як мінімум 4 зірки. При цьому 38% з цих додатків містять код, який віднесений сканером безпеки Google VirusTotal до розряду шкідливого;
-
16% додатків використовують системи користувачів в якості точок виходу трафіку, перенаправляючи запити одних користувачів через системи інших користувачів, замість створення вихідних вузлів на окремих серверах;
-
4% додатків перехоплюють і перевіряють трафік на внутрішньому інтерфейсі (localhost proxy);
-
Два додатки містили недокументовані функції (не були зазначені в описі програми) блокування лічильників і коду рекламних мереж, при тому, що дане блокування приводило до побічних ефектів, таких як неможливість переглянути відеоматеріали на деяких сайтах.
Arch Linux припиняє підтримку 32-розрядної архітектури x86
Розробники дистрибутива Arch Linux попередили користувачів про швидке припинення формування збірок для архітектури i686. Лютневе оновлення iso-образів стане останнім, що дозволяє провести установку на 32-розрядних системах. Надалі збірки будуть формуватися тільки для 64-розрядних систем, але пакети для архітектури i686 будуть збиратися ще 9 місяців. Починаючи з листопада 2017-го офіційна підтримка 32-розрядних систем x86 буде припинена і супроводжуючі більше не будуть зобов'язані збирати свої пакети для даних систем.
Зацікавленим в архітектурі i686 представникам спільноти, які готові взяти на себе продовження формування 32-розрядних збірок, пропонується обговорити таку можливість в списку розсилки arch-ports.
Релізи
-
Інструментарій для формування збірок qbs 1.7
-
CentOS 7.3 для 32-розрядних систем x86
-
Дистрибутив Bodhi Linux 4.1
Ще немає коментарів