Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 949 сообщений
Cообщения с меткой

стандарты - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Удивительный компьютер: История ENIAC

Пятница, 27 Мая 2016 г. 10:01 (ссылка)






/ фото terren in Virginia CC



Мы в 1cloud пишем не только про свой опыт разработки, но рассказываем о технологиях, связанных с различными аспектами функционирования облачных сервисов. Сегодня мы обратимся к истории и поговорим об ENIAC.



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

https://habrahabr.ru/post/301918/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Мой URL — это не ваш URL

Понедельник, 23 Мая 2016 г. 20:16 (ссылка)






Когда давным-давно в 1996 году я приступил к работе над программой httpget, предшественницей проекта Curl, я написал свой первый синтаксический анализатор URL. Как раз тогда этот универсальный адрес получил название URL: Uniform Resource Locator (единый указатель ресурсов). Его спецификация была опубликована IETF в 1994 году. Аббревиатура «URL» была затем использована как источник вдохновения для названия инструмента и проекта Curl.



Термин «URL» был позднее изменён; его стали называть URI (Uniform Resource Identifier — единый идентификатор ресурсов), согласно спецификации, опубликованной в 2005 году, однако основное сохранилось: синтаксис для строки, задающей онлайн-ресурс и указывающей протокол для получения этого ресурса. Мы требуем, чтобы curl принимал указатели URL, как определено данной спецификацией RFC 3986. Ниже я расскажу, почему на самом деле это не совсем так.

Читать дальше →

https://habrahabr.ru/post/301516/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
anob

Алкогольно-эротические фантазии Порошенко: мы остановили армию России Политикус InfoPolk.ru

Суббота, 14 Мая 2016 г. 21:18 (ссылка)
infopolk.ru/1/U/events/7634...5c6ab90332

Алкогольно-эротические фантазии Порошенко: мы остановили армию России


Бывало ли такое, что смех доводил Вас до изнеможения? Со мной – да! Если быть точным, то сегодня, после прочтения заявления Порошенко о великой украинской армии, остановившей российского агр ...

Комментарии (0)КомментироватьВ цитатник или сообщество
ivapet

Алкогольно-эротические фантазии Порошенко: мы остановили армию России

Суббота, 14 Мая 2016 г. 18:24 (ссылка)
infopolk.ru/1/U/events/7634...9efd14bb02

Алкогольно-эротические фантазии Порошенко: мы остановили армию России


Бывало ли такое, что смех доводил Вас до изнеможения? Со мной – да! Если быть точным, то сегодня, после прочтения заявления Порошенко о великой украинской армии, остановившей российского агр ...

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Спасём Firefox

Четверг, 12 Мая 2016 г. 18:37 (ссылка)





Автор — Кори Доктороу, от имени Фонда электронных рубежей. Это воззвание адресовано в первую очередь американским пользователям интернета, но важно не только для них, а для всех, потому что решается наша общая судьба. Сейчас определяется будущее свободного Веба.



Давным-давно было два браузера, которыми пользовались почти все: Netscape и Internet Explorer, связанные в смертельной битве за будущее Интернета. Они сильно разошлись друг от друга, чтобы склонить веб-издателей оптимизировать свои сайты каждый под свой браузер в надежде, что пользователи последуют за ними.



Затем произошёл перелом: открытый, некоммерческий браузер Mozilla выделился из Netscape и поставил перед собой другую задачу: служить не издателям, а самим пользователям. Mozilla по умолчанию блокировала всплывающие окна с рекламой, бич раннего интернета. Это был шаг, который не мог позволить себе ни один из основных браузеров, потому что издатели были уверены, что не выживут без такой рекламы, и любой браузер со встроенной блокировкой отвернул бы от себя издателей, что многое значило в конкурентной борьбе.



Прошло суть более десяти лет, и мир браузеров изменился до неузнаваемости: Mozilla превратилась в Firefox; Internet Explorer превратился в Edge, Apple выпустила Safari, а Google выпустил Chrome. Все они блокировали всплывающие окна по умолчанию!



И нельзя сказать, что сейчас нет конкуренции. Она есть, и как никогда сильная. Как и раньше, это стратегическая борьба, чтобы угодить и издателям, и пользователям, чьи интересы не всегда совпадают. Издатели желают собирать больше информации о пользователях, а люди хотят сохранить свои данные в секрете. Издатели стремятся контролировать подачу контента и просмотр сайтов пользователями, а люди хотят оставить контроль за собой.



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



Нам нужно больше файрфоксеров.



Нужно больше браузеров, разработчики которых думают прежде всего о пользователях, а не об издателях. Это естественный цикл концентрации-разрушения-обновления, который поддерживал энергию в Интернете почти 20 лет (целые эпохи, по меркам Сети).



Консорциум World Wide Web (W3C) раньше продвигал открытые стандарты, которые не давали привязать издателей к проприетарным функциям конкретных браузеров, но с тех пор W3C изменил своей миссии. С 2013 года организация превратилась в форум, на котором собираются компании-разработчики главных браузеров и компании, доминирующие в медиаиндустрии. Они совместно создают систему, чтобы браузер мог контролировать наше поведение, а не наоборот.



Такая система под названием Encrypted Media Extensions (EME) использует установленный стандартом код, чтобы поместить видео внутрь проприетарного контейнера — Content Decryption Module (CDM). Чтобы новый браузер поддерживал этот новый стандарт потокового видео — который продвигают крупные студии и кабельные операторы — ему нужно убедить эти медиакомпании или одного из их партнёров предоставить CDM, иначе эта часть «открытого» веба не будет отображаться в новом браузере.



Это противоречит всем прежним стандартам W3C и всей идее открытого веба. Раньше единственным требованием для рендеринга контента, который прислал сервер, было соблюдение стандартов, а не получение разрешения. Если бы браузеры нуждались в разрешении издателя на рендеринг страницы в те времена, когда вышла первая Mozilla, то издатели просто задавили бы этого выскочку, блокирующего всплывающую рекламу. Другими словами, можете попрощаться с Firefox.



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



Это потому что система EME спроектирована таким образом, чтобы задействовать правила раздела 1201 закона Digital Millennium Copyright Act (DMCA). Они говорят, что удаление без разрешения цифрового замка, который охраняет защищённый копирайтом контент, — это преступление, даже при наличии права на доступ к этому контенту. Другими словами, как только видео начинают транслировать через систему EME, любая компания, которая станет разблокировать контент для своих пользователей, может быть привлечена к ответственности в суде, даже если пользователи не сделали ничего незаконного.



Мы предложили W3C выход из положения: защитить новые браузеры. Члены W3C должны пообещать не использовать DMCA для атаки на новичков, эту идею поддержала большая группа участников W3C, но руководство консорциума W3C отвергло предложение и решило продолжать работу над стандартом без всякой защиты для конкуренции в будущем.



Это даже хуже, чем выглядит на первый взгляд, ведь DMCA действует не только в США: по инициативе Управления торгового представителя США (US Trade Representative) DMCA-подобное законодательство принято практически в каждой стране, которая имеет торговые отношения с Соединёнными Штатами. И ещё хуже: DMCA также постоянно используется компаниями, чтобы запугать и заставить молчать исследователей в области информационной безопасности, которые находят вопиющие дефекты в их продуктах. Консорциум W3C также отказался потребовать от своих членов защитить исследователей ИБ, которые найдут уязвимости в EME. Это ставит под угрозу всех пользователей интернета, поскольку оставляет им компьютерные системы с открытыми багами. Раскрытие уязвимостей с разрешения компании только повысило бы безопасность.



В консорциуме W3C должны выступить вперёд люди, которые заботятся об открытом вебе и инновациях, сохраняющим его жизнеспособность. Они чувствительны к критике такого рода. Мы понимаем их. Там работает много хороших людей, которые искренне, горячо желают, чтобы веб оставался открытым для всех и безопасным для пользователей. Но организация сделала ужасное решение, приняв EME, и ещё более ужасное, когда отвергла мнение своих членов и отменила защиту для исследователей информационной безопасности и новых конкурентов.



Нужен ваш голос. Пожалуйста, распространите этот пост и расскажите о нём. Помогите сделать W3C таким, каким он должен быть.













Original source: habrahabr.ru.

https://habrahabr.ru/post/283456/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
lenov_ru

Gods of Rome Мод (Instant Skill) » Русский Google Play - игры Android без вирусов и регистрации

Суббота, 07 Мая 2016 г. 15:30 (ссылка)
mod-hak.ru/game/rpg/3582-go...skill.html


Gods of Rome или же Боги Арены - новый онлайн файтинг от студии Gameloft. Действия игры развиваются по альтернативной сюжетной линии, боги сошлись в бесконечной битве, превратив как вершину Олимпа,

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Расширенная MVC архитектура программы

Пятница, 07 Мая 2016 г. 02:49 (ссылка)

MVC паттерн давно уже на рынке, но многие его используют по разному.



С опытом разработки мы увидели, что очень удобно разделить MVC таким образом:



M = SOA

V = templating, head, footer-scripts, parts

C = Routing + easy code and business logic




Почему Model — это SOA. По сути модель многие понимают как работу с данными и получается каждая обработка данных — это некий внутренний сервис. Желательно, что бы они были НЕ связаны сильно и код можно было легко расширять.



View в веб-разработке часто несёт в себе заголовки head и скрипты, которые не являются уже внешним видом, а несут отдельный смысл. Лучше их переносить в отдельные файлы. Также View-ки должны легко делится на части для простоты масштабирования проекта



Controller — это основной элемент всей связки. В нем происходит распределение реакций на запросы клиента. И часто на первом этапе это распределение выполняет Rotuting, а уже потом в методе контроллера собираются все нужные данные и помещаются во View.



Мы считаем такую архитектуру оптимальной. Каждое направление может использовать ООП, наследовать абстрактные классы и усложнятся, но важно соблюдать границы, что бы код легко расширялся и был удобный для коллективной работы.



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



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



Спасибо за внимание.



Если кто знает другие хорошие варианты архитектуры, напишите пожалуйста в комментах ваши мнения, спасибо.



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/283096/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод - recovery mode ] Нужен ли стандарт разработки?

Пятница, 06 Мая 2016 г. 17:08 (ссылка)

Вольный перевод статьи «Should we use a coding standard?» из блога «Virtuous Code» Avdi Grimm. Мнение автора оригинальной статьи может не совпадать с мнением редакции.

Примечание переводчика: лично я согласен с автором.







Avdi, должны ли мы использовать стандарт разработки?



Да.



Какой стандарт нам использовать?



Не думаю, что есть какой-то один «правильный» стандарт. Каждый проект должен выработать свой стандарт на основе своих нужд и предпочтений разработчиков.



Думаю, что разнообразие стилей в сообществе хорошо. Это хорошо даже для большой организации.



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



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



Как нам выбрать стандарт разработки?



Многие сообщества языков программирования уже выработали общие стандарты. К примеру, если вы пишете код на C, вы можете выбрать стандарт разработки GNU. Или если вы разрабатываете на Ruby, вы можете использовать стандарт сообщества, поддерживаемый Божидаром Бацовым: Bozhidar Batsov’s community-influenced standard.



Эти стандарты — плод мыслей и дебатов сообщества. Поскольку соглашения, входящие в эти стандарты, основаны на решении большинства, это хорошая точка отсчета.



Но некоторые решения в этих стандартах — глупые и неправильные!







Истина. Поэтому я и говорю, что стандарты сообщества — хорошая отправная точка. Когда у вашей команды есть четкие возражения по определенным соглашениям в стандартах — наступает время для модификации стандарта под свои нужды.



Наша команда разделилась пополам в выборе определенного пути! Как я могу убедить другую половину?



Будем честны: очень маловероятно, что команда действительно разделилась пополам. Обычно есть один-два человека с одной стороны и примерно столько же с другой, остальная же команда не выбирает ни одну сторону.



Хорошо, так как мне убедить этих людей по другую сторону баррикад?



Уверенность другой стороны могут поколебать хорошо обоснованные, реальные примеры того, что ваш вариант изящнее раскрывает суть кода, лаконичнее пишется или лучше показывает опасные места.



Это не так, просто мой стиль красивее. В любом случае, это более идиоматичный подход.



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



Например, когда я начинал разрабатывать на C++, я выравнивал фигурные скобки так, чтобы можно было посмотреть выше и сразу увидеть открывающую скобку в той же колонке:



int main(int argc, char** argv)
{
std::cout << "Hello, world!";
}




Позже я встретился с кодом в стиле GNU/GNOME, где открывающая скобка стоит на строке с объявлением метода. Аргх!



int main(int argc, char** argv) {
std::cout << "Hello, world!";
}





Я пожал плечами и продолжил. Вариант в GNU-стиле даже показался мне предпочтительнее.



Мне встречалось множество примеров кода вроде «А против Б», где вариант Б представляли объективно красивее варианта А. Большую часть времени мне было сложно увидеть разницу, которую автор полагал очевидной.



В Ruby популяризованное Rails соглашение о выборе между фигурными скобками и do...end, основанное на количестве строк кода внутри блока, немного глупо. Мне говорили, что одна из причин такого соглашения в том, что do...end на одной строке объективно выглядит ужасно:



h.fetch(:some_key) do raise ":some_key is required" end




Лично я не вижу ничего плохого в этой строке. Объективные эстетические суждения плохи в качестве правил.



Стоит помнить, что «стандартный» синтаксис языка обычно немного странный в начале. Например, в каждом основанном на C языке мы обозначаем «сообщение» или «аттрибут» примерно так:



farm_boy.fetch_me_that_pitcher()




Так как это слова на английском, давайте рассмотрим это с точки зрения английского языка.



Точка обычно указывает конец предложения, или разделитель между целой и дробной частью числа. Здесь она стоит на том месте, где обычно мы ставим запятую:



"Farm boy, fetch me that pitcher"




Или двоеточие:



"Farm boy: Fetch me that pitcher!"




Тем временем слова отделяются друг от друга символом, которого новички вообще не знают. Я уже даже не хочу думать о кавычках.



Окей, хорошо, стиль субъективен. Но некоторые вещи действительно делают код проще, или ошибки заметнее!



Да, думаю это так.



И мой тимлид делает неверный выбор!!



Возможно, что у вас действительно есть хорошие, целостные, ориентированные на качество кода аргументы в пользу определенного стиля. И вопрос выбора стандарта действительно может развести вас и вашу команду по разные стороны баррикад.



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



Как дорого проекту обойдется ваша правота?





Давайте посмотрим: вы полностью правы насчет выбора стиля или практики разработки. Ваши оппоненты неправы и глупы.



Но спросите себя, сэкономит ли ваша правота достаточно, чтобы компенсировать:


  • Потраченные часы всей команды на совещания касательно стиля, которые не заканчиваются ничем толковым?

  • Потерю хороших отношений как результат столкновений лбами на этих совещаниях?

  • Цену огромных цепочек в почте с обсуждениями плюсов и минусов разных стандартов?

  • Злость и гнев вашей команды, когда они будут вынуждены следовать стилю, который им не нравится, но который им в итоге навязали?





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



Стандарты разработки предохраняют от дурных привычек, но в чем их главный плюс?



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



Сравним два блока кода на Ruby:



# Block #1
output = []
while word = input.shift
unless STOP_WORDS.include?(word.downcase)
output << word
end
end




# Block #2
output = input.map(&:downcase) - STOP_WORDS




Очевидно ли на первый взгляд, что оба блока делают одно и то же? Более важно: очевидно ли, что несмотря на аналогичную функциональность, блоки имеют мелкое, но важное различие?



Реальная ценность стандарта разработки в том, что он делает похожие вещи похожими, а разные — разными. Такая последовательность помогает команде быстрее понимать суть написанного кода. В свою очередь это означает, что они могут работать на более высоком уровне абстракции большую часть времени.



Как это понимать для легаси-кода? Должны ли мы обновлять каждый файл в проекте под новый стандарт?



Одним словом — нет. Не вижу никакой пользы в том, чтобы потратить часы на обновление каждого файла в проекте строчка за строчкой согласно новому стандарту разработки. Это не стоит тех затрат времени и усилий, и может принести новые баги в легаси-код.



Что, если я вношу изменение в легаси-код? Должен ли я обновить весь файл, раз уж я за него взялся?



Мой ответ отличается от общепринятого мнения и порой удивляет людей.



Ответ — нет. Обновление стиля легаси-кода потребует времени, создаст большой diff и увеличит шанс случайной регрессии.



Значит ли это, что я должен использовать новый стиль только в новых или измененных участках кода?



Давайте конкретизируем вопрос. Представьте, что это кусок легаси-кода:



STOP_WORDS = [

'i',

'we',

'if',

'and',

'the'

]





Предположим, ваша задача — добавить слово «they» в список. И по новому стандарту разработки все строки должны обрамляться двойными кавычками.



Нужно ли обновить весь список в процессе добавления нового слова?



STOP_WORDS = [

"i",

"we",

"if",

"and",

"the",

"they"

]





Или применить новый стандарт только для добавленной строки?



STOP_WORDS = [

'i',

'we',

'if',

'and',

'the',

"they"

]





Как я говорил раньше, для меня ценность стандарта — сохранение последовательности. Последовательность важна на уровне проекта, но она важна и на уровне файла. Поэтому я не думаю, что стоит следовать новому стандарту, когда вы обновляете файл, написанный по старому стандарту. Напротив, если в файле уже есть последовательный стиль оформления, вам стоит постараться выдержать его.



Это значит, что если слова в списке обрамлены одиночными кавычками, вы должны добавить новое слово в одиночных кавычках.



STOP_WORDS = [

'i',

'we',

'if',

'and',

'the',

'they'

]





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



___



Что думаете о стандартах разработки? Какие стандарты применяете? Рассказывайте.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/283080/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

О выработке неперебираемых ключей на основе перебираемых паролей

Четверг, 28 Апреля 2016 г. 17:52 (ссылка)

Криптографические протоколы — фундамент безопасного сетевого соединения и конфиденциального обмена информацией. На сегодняшний день существует большое количество самых разных протоколов для самых разных целей. Многие из этих протоколов (например, TLS, Kerberos) на слуху даже у людей, тесно не связанных с криптографией. Они распространены повсеместно и зачастую уже давно являются частью популярных информационных систем.



Однако существует тип протоколов, который последнее время набирает все большую популярность, но все еще не является широко известным — протоколы выработки общего ключа с аутентификацией на основе пароля. К таким протоколам относится российский протокол SESPAKE (Security Evaluated Standardized Password Authenticated Key Exchange), с появлением которого в России и возникла необходимость в рассмотрении особенностей протоколов подобного типа. Целью данной статьи является скорее не дать очередное формальное описание нового протокола, а помочь читателю уловить его основную идею и особенности и понять, почему в нём присутствуют те или иные шаги, почему они важны и чем подобный класс протоколов отличается от всего, что было известно ранее.





Немного истории



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



Здесь E – некоторая конечная мультипликативная группа, q – ее порядок, g – порождающий элемент данной группы. Значения M = g^a и N = g^b – открытые ключи, передающиеся по открытому каналу связи, K = g^{ab} – ключ, выработанный в ходе выполнения протокола.



Стойкость этого протокола по отношению к пассивному противнику основывается на так называемой задаче CDH, которая считается вычислительно «сложной» (если говорить неформально, то для такой задачи не существует эффективных алгоритмов решения). Формулировка этой задачи выглядит следующим образом: зная значения g^a, g^b, вычислить значение g^{ab}.



К сожалению, протокол Диффи-Хеллмана имеет один фундаментальный недостаток: он не является безопасным, если в канале передачи присутствует активный противник (см. атаку «Человек посередине» ). Причина этой уязвимости кроется в отсутствии механизма осуществления аутентификации, т.е. стороны не имеют возможности в ходе протокола каким-либо образом удостовериться, что общий ключ выработан совместно с честным абонентом.



На сегодняшний день предложено несколько решений данной проблемы, вот некоторые из них: использование сертификатов и УЦ, введение третьего доверенного участника в протокол или использование предварительно согласованного секрета. Последний подход является самым простым решением с точки зрения реализации. Однако если протокол подразумевает использование секрета, являющегося длинной битовой строкой, запомнить которую человеку трудно, то появляется проблема безопасного хранения этого секрета.



Возникает вопрос, можем ли мы использовать в качестве секрета короткий и легко запоминающийся пароль? Как только возникает слово «пароль», многим чуть ли не рефлекторно хочется сказать, что высокой стойкости априори добиться нельзя, т.к. пароль можно быстро восстановить простым перебором или по словарю. Ниже будет показано, что это не всегда так.



Для начала, рассмотрим следующую схему выработки ключа, в которой к протоколу Диффи-Хеллмана добавляется этап аутентификации с использованием секретной величины:



Здесь H — некоторая хэш-функция, S – секретная предварительно согласованная величина, T_A, T_B — информация, используемая для аутентификации. Легко заметить, что секрет S никак не используется на этапе выработки общего ключа.



Чем же плох этот пример в случае, когда величина S является обычным паролем? Как правило, пароль — величина малоэнтропийная (т.е. состоит из 4–6 символов, например, PIN), следовательно, перебор всех возможных значений пароля является вполне выполнимой задачей для противника. Поэтому фундаментальным требованием к протоколам, использующим короткий пароль, является стойкость к так называемой offline dictionary атаке. Это свойство должно достигаться за счет того, что информация, которую может получить как пассивный, так и активный противник в ходе выполнения протокола, не дает критерия для отбраковки неверных паролей в режиме offline, т.е. для нас идеален вариант, когда противник не может найти пароль с помощью перебора всех возможных значений, количество которых невелико, без взаимодействия с пользователем. Возвращаясь к примеру, зададимся вопросом: решая проблему аутентификации, не даем ли мы противнику критерий отбраковки пароля? Чтобы на него ответить, рассмотрим следующую атаку:



В данном примере противник действует следующим образом: он подменяет собой сторону B и взаимодействует со стороной A, честно следуя протоколу. Противник вырабатывает общий с A ключ \bar{K_A}. Далее он получает от субъекта A аутентификационную информацию \bar{T_A}=H(S||\bar{K_A}||1), которая зависит всего лишь от одного неизвестного параметра — малоэнтропийного пароля S. Следовательно, противник получает критерий для отбраковки неправильных паролей.



Однако, если бы использование пароля было напрямую встроено в выработку ключа (представляло собою неотделимый от его выработки процесс) и противник смог бы получать общий с A ключ \bar{K_A}, только угадывая пароль в ходе взаимодействия, то данная атака была бы неприменима, так как ему бы пришлось перебирать не только пароль, но и длинный ключ.



Эта идея легла в основу нового подхода, а именно протоколов выработки общего ключа с аутентификацией на основе пароля (PAKE).



Протоколы PAKE



Первый протокол типа PAKE был предложен еще в 1992 году Стивеном Белловином и Майклом Мерритом. Этот протокол предполагал, что для решения проблемы аутентификации субъекты, желающие выработать общий ключ, используют некоторый легко запоминающийся пароль, известный только им. Главным отличием протоколов типа PAKE от рассматриваемого выше примера является тот факт, что пароль используется уже на этапе выработки общего ключа.



При этом основными требованиями, которые предъявляются к такому протоколу, являются:


  • обеспечение аутентификации для участников протокола;


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




Попробуем понять, сложно ли построить подобный протокол и какими особенностями он должен обладать. Для этого рассмотрим простейший пример-прототип протокола PAKE:





Голубым цветом здесь выделены отличия от протокола Диффи-Хеллмана, h — еще один порождающий элемент группы E.



Посмотрим, уязвима ли подобная схема к offline dictionary атаке. Пассивному противнику, прослушивающему канал передачи, доступны значения M и N – открытые ключи Диффи-Хеллмана, замаскированные значением h^{PW}, и аутентификационная информация T_A и T_B. Перебирая пароли, он может «снимать» маски со значений M и N, получая при этом предполагаемые значения g^\tilde{a} и g^\tilde{b}. Но противник может получить критерий для перебора паролей, только если он умеет решать вычислительно «сложную» задачу CDH для демаскированных значений M и N, то есть по значениям g^\tilde{a} и g^\tilde{b} получать ключ g^{\tilde a\tilde b} = \tilde{K_A} (критерием правильности пароля при этом будет получение верной аутентификационной информации T_A=H(K_A||1) на опробуемом ключе \tilde{K_A}).



В случае активного противника данная схема всё-таки имеет определенные уязвимости. Рассмотрим следующую атаку на схему, где дискретные логарифмы одного порождающего элемента относительно другого известны. Для простоты рассмотрим случай, когда h=g.



Как и в предыдущей атаке, здесь противник просто подменяет собой сторону B. Так как ему известна функция выработки ключа, зависящая всего лишь от одного неизвестного параметра – малоэнтропийного пароля PW, он получает возможность найти пароль простым перебором, подставив опробуемый ключ в функцию генерации аутентификационной информации T.



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



Если же использовать разные порождающие элементы, такие что дискретные логарифмы одного относительно другого не известны, мы не сможем получить ключ как функцию только от неизвестного пароля. Действительно, K_A =(M*h^{-PW})^e/(h^{PW})^a, где a — высокоэнтропийная неизвестная величина.



Вывод №1: При формировании эфемерного открытого ключа и парольной «маски» необходимо использовать разные порождающие элементы, причем дискретные логарифмы одного по основанию другого должны быть неизвестны.


Для получения таких элементов необходимо не просто генерировать их случайным образом, но и иметь возможность убедить всех остальных в том, что при их генерации все было чисто случайным. Этого можно достичь, если выбирать порождающие элементы согласно принципу доказуемой псевдослучайности. Так, для мультипликативной группы конечного поля GF(p) можно привести следующий алгоритм генерации порождающих:


  1. Сгенерировать случайную строку .


  2. Положить g=H(s)\ mod\ p.


  3. Проверить, что g – порождающий элемент, иначе вернуться к шагу 1.




Казалось бы, теперь мы рассмотрели все потенциально опасные ситуации, однако при создании протокола необходимо учитывать и более сложные моменты. Любой специалист, который разрабатывает новый протокол, знает, что одним из важнейших требований к подобным протоколам является обеспечение ими так называемой неявной аутентификации вырабатываемого ключа.

Явная и неявная аутентификация ключа
Неявная аутентификация ключа (implicit key authentication) — свойство протокола, при котором участник протокола может быть уверен, что никакая другая сторона, кроме специально идентифицированного (легитимного) участника протокола, не может получить доступ к секретному ключу, выработанному в протоколе. При этом нет никаких гарантий, что второй участник протокола действительно получил доступ к ключу, но точно известно, что никто другой, кроме него, не мог его получить.



Явная аутентификация ключа (explicit key authentication) — свойство, которое выполняется, когда имеют место неявная аутентификация ключа и подтверждение ключа (свойство, посредством которого один участник протокола убеждается, что другой участник действительно обладает ключом, выработанным в протоколе) одновременно. В этом случае известно, что легитимная сторона, и никто другой, реально обладает выработанным ключом.



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



Рассмотрим атаку в такой модели противника, где:


  • во взаимодействии участвуют обе стороны;

  • противнику известны ключи K_A и K_B (к примеру, из-за несанкционированного доступа, использования их в уязвимых криптоалгоритмах и пр. ).





Несмотря на то, что мы используем разные порождающие элементы, если противнику известны K_A и K_B, то, зная N и r, он сможет найти значение пароля PW, воспользовавшись критерием (K_B/K_A)^{-r} =N/h^{PW}. Таким образом, перехватив и подменив сообщение, он фактически сможет получить критерий нахождения пароля.



От этой уязвимости можно избавиться, если использовать в протоколе хэш-функцию:





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



Вывод №2: Хэшируем вырабатываемый ключ.


Итак, нам удалось построить простейший прототип протокола выработки неперебираемых ключей на основе перебираемых паролей. Конечно, рассмотрение конкретных атак и применение известных методов защиты от них не гарантируют, что разрабатываемый протокол будет стойким, так как не представляется возможным учесть все существующие, но пока неизвестные атаки. В этом случае на помощь приходят методы математической криптографии, которые позволяют получать оценки стойкости протоколов в определенных моделях безопасности. Если рассуждать неформально, для протоколов типа PAKE данные оценки должны строго доказывать, что самой лучшей тактикой для противника является опробование пароля в ходе попытки установить соединение, честно следуя протоколу. Подобные оценки и были получены для протокола SESPAKE.



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



На практике



Итак, мы узнали, какими свойствами должен обладать протокол выработки общего ключа на основе пароля с последующей аутентификацией. Мы также познакомились с примером одного из таких протоколов — протоколом SESPAKE. Попробуем теперь разобраться, так ли нужен этот протокол на практике и нельзя ли обойтись уже давно существующими решениями.



Протоколы данного семейства предоставляют широкие возможности для их использования в самых разнообразных информационных системах. Для того, чтобы «прочувствовать» работу протокола, давайте обратимся к наиболее популярной области его применения и одному из наиболее важных вопросов для защиты информации — задаче безопасного хранения криптографических ключей.



Можно выделить два основных вида ключевых носителей, использующих пароль: пассивное хранилище и активный токен.



Пассивный носитель умеет только хранить ключ и передавать его приложению (обычно криптопровайдеру), работающему в операционной системе на стороне пользователя, которое уже решает, что с ним делать. Неотъемлемым свойством пассивного хранилища является принципиальная извлекаемость ключа: все операции, зависящие от ключа, производятся приложением, работающим на машине пользователя, поэтому ключ неизбежно присутствует в оперативной памяти. Конечно же, извлечь ключ при этом может лишь тот, кто знает пароль.



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

Схема работы ключевых носителей
Носитель-хранилище:





Активный токен:





Свойства ключевых носителей обоих описанных выше типов имеют достаточно строгие условия их применения, так как оба этих ключевых носителя нестойки, если злоумышленник находится в канале связи. В случае использования носителя-хранилища злоумышленник просто видит ключ, в случае же активного носителя он не сможет получить доступ к ключу, но сможет узнать пароль, а значит стать для носителя легитимным субъектом – кто знает пароль, тот и прав! В таком случае при краже устройства злоумышленник сможет воспользоваться токеном для совершения необходимых ему операций с ключом. В криптографии такая угроза называется селективной подделкой: злоумышленник может подписать нужные ему данные, не зная ключ.



ФКН или в игру вступает SESPAKE



Таким образом, возникает задача создания такого типа ключевых носителей, который был бы стойким по отношению к противнику в канале связи между машиной и носителем и угрозе селективной подделки, то есть фактически решал бы проблему аутентификации. И благодаря появлению протоколов семейства PAKE мы можем создать такой носитель.

Подобный тип токенов, отвечающий данным требованиям, называют функциональными ключевыми носителями (сокращенно, ФКН).

Схема работы функционального ключевого носителя (ФКН)
Общая схема их работы ФКН выглядит так:





Эти носители, как и активные носители, рассмотренные выше, предоставляют пользователю возможность получить лишь результат вычислений, в которых участвует ключ. Однако их отличие состоит в том, что пароль при этом не передается напрямую по каналу связи, а устанавливается защищенное соединение по протоколу PAKE, то есть по каналу связи передаются лишь те данные, по которым на практике нельзя сделать никаких выводов ни о пароле, ни о ключе.



Вот здесь на сцену и выходит протокол SESPAKE, который, по сути, и обеспечивает возможность подобного сценария взаимодействия. Использование этого протокола позволяет математически строго обеспечить защиту от противника в канале. Таким образом, злоумышленник, имеющий возможность читать и подменять сообщения в канале, не сможет ни узнать пароль, ни даже получить возможность перебирать пароли неинтерактивно, то есть без контроля со стороны токена.



Протокол SESPAKE



Протокол SESPAKE был разработан с учетом всех описанных выше требований. Обычно, обоснование стойкости протокола типа PAKE приводится в модели, в которой учитывается стандартная угроза выведывания противником хоть какой-то информации о вырабатываемом ключе. Однако данная модель является не совсем естественной, так как рассматривается вне контекста применения протокола. Действительно, вырабатываемые ключи после завершения работы протокола будут в дальнейшем использоваться для защиты данных, что незамедлительно даст возможность нарушителю реализовать угрозу. Проще говоря, стойкость этих протоколов анализируется в некоторой упрощенной модели их использования, что зачастую приводит к ситуациям, когда после введения расширений, позволяющих использовать протокол в конкретных случаях на практике, он оказывается нестойким. Поэтому обоснование стойкости протокола SESPAKE приводится в модели противника, которая учитывает другую более сильную угрозу — угрозу ложной аутентификации.



Разработка протокола SESPAKE берет свое начало не от абстрактной математической модели, в которой уже давно существуют известные механизмы обоснования стойкости, а связана с конкретным практическим случаем: необходимостью защитить канал между ключевым носителем и провайдером. Таким образом, введенная его разработчиками новая модель противника позволила одновременно и в протоколе, и в его обосновании учесть все важные для практики технические аспекты (например, работу со счетчиками). Познакомиться подробнее с его обоснованием можно в отдельной статье, мы же попробуем понять суть работы протокола.



Конечно, схема такого «боевого» протокола существенно сложнее, чем рассматриваемые нами примеры, а сам протокол основывается уже на группах точек эллиптических кривых, которые при той же длине ключа позволяют добиваться большей криптографической стойкости в сравнении с конечными полями. Однако теперь даже неопытный читатель сможет уловить его суть, ведь базовые принципы, на которых он основан, остаются прежними.







В представленной выше схеме работы протокола тремя цветами выделены его ключевые и уже знакомые нам моменты, аналогичные тем, что описаны в построенном выше прототипе:


  1. Величины u_1 и u_2 аналогичны M и N,Q_{PW} и Q_{PW}^{A} выступают в роли «маски» (h^{PW}), величины \alpha*P, \beta*P аналогичны значениям g^a, g^b.

  2. В протоколе SESPAKE учитывается вывод №2, поэтому вырабатываемый общий ключ хэшируется.

  3. Точно так же, как и в нашем прототипе, протокол состоит из двух этапов: выработки общего ключа и аутентификации. Здесь вместо хэширования ключа H(K||1) на этапе его подтверждения сторонами вычисляется код аутентификации сообщения HMAC на вырабатываемом ключе от сформированной определенным образом строки.



Требование о наличии разных порождающих элементов, сформулированное нами в выводе 1, также не обходится здесь стороной. Однако теперь оно формулируется следующим образом: кратность любой точки из набора Q_1,...,Q_l (набора точек, которые могут использоваться в протоколе для формирования маски, индекс (ind) которых выбирается до начала этапа выработки ключа) относительно порождающего элемента P и относительно друг друга является неизвестной. Причем задача вычисления этой кратности неосуществима на практике, т.е. ее трудоемкость сравнима с трудоемкостью решения сложной задачи дискретного логарифмирования в группе точек используемой эллиптической кривой.



Выбор точки эллиптической кривой, заданной в форме Вейерштрасса (y^2=x^3+ax+b), может быть осуществлен следующим образом:


  1. Сгенерировать случайную строку s.


  2. Положить x=H(s).


  3. Если значение x^3+ax+b не является квадратичным вычетом по модулю p, перейти к пункту 1.


  4. Положить y=\sqrt{x^3+ax+b}\ mod\ p.




Здесь p — порядок поля, над которым строится группа точек эллиптической кривой, а в качестве H может быть использована, например, хэш-функция ГОСТ Р 34.11-2012.



Заметим, что протокол SESPAKE является одним из самых эффективных, так как предполагает минимально возможное количество пересылок между сторонами.



Заключение



В конце 2015 года техническим комитетом по стандартизации TK26 в качестве методических рекомендаций был принят протокол выработки общего ключа с аутентификацией на основе пароля — протокол SESPAKE. Примерно в то же время протокол начали рассматривать в исследовательской рабочей группе по криптографии CFRG (Crypto Forum Research Group), входящей в состав организации IETF/IRTF, занимающейся вопросами международной стандартизации. На данный момент в CFRG ведется обсуждение по стандартизации требований к протоколам типа PAKE, а также выбору протокола в качестве международной рекомендации по использованию. В числе трех основных кандидатов рассматривается протокол SESPAKE, драфт RFC которого сейчас активно разрабатывается российскими специалистами. Познакомившись с такими протоколами, теперь и вы можете предложить свои идеи, поучаствовав в подобных обсуждениях.



Original source: habrahabr.ru.

https://habrahabr.ru/post/282043/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] О координации изменений во временных зонах

Среда, 27 Апреля 2016 г. 09:45 (ссылка)

tz map



Знаете, что общего у Турции, Чили, России, Венесуэлы, Азербайджана, Северной Кореи и Гаити? Хаос в управлении временными зонами.



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



Во-первых, с глобальной точки зрения может показаться, что временные зоны должны бы управляться каким-нибудь относительно нейтральным международным органом, таким как ITU (Международный союз электросвязи, подразделение ООН) или, возможно, IAU (Международный астрономический союз). Однако в действительности каждая временная зона в мире управляется локально.



Само по себе это не проблема. Я полностью согласен с тем, что страны в пределах своих границ должны иметь возможность делать со временем что угодно. Но дело в том, что уже который раз мы сталкиваемся с одной и той же проблемой: зоны изменяются без должного уведомления. Все те страны, перечисленные ранее, наряду с многими прочими недавно поступили именно так.



Очень важно, чтобы перед внесением изменений в свои временные зоны или правила перехода на летнее время правительства государств оставляли достаточное количество времени на обновления для IT индустрии. Они должны учитывать тот объём работы, которую люди должны при этом выполнить, чтобы проверить изменения, создать обновление, протестировать его, а затем опубликовать и распространить. Кроме этого нужно иметь в виду, что конечные пользователи не всегда обновляют свои системы сразу же. Обычное дело, когда пользователь получает обновление временной зоны через недели, а то и месяцы после публикации.



Конкретный пример — Турция



В качестве примера взглянем на Турцию. В 2015 году правительство решило, что было бы неплохо отложить конец летнего времени на две недели, чтобы дать людям больше светлого времени для голосования в период выборов. Они перенесли окончание летнего времени с 25 октября на 8 ноября.



Первые слухи об этом появились в неофициальной новостной статье 8 сентября, примерно за 6 недель до предполагаемого изменения. Эта статья не была замечена TZ коммьюнити (прим. пер.: имеется в виду сообщество, занимающееся временными зонами; это просто люди, волонтёры, объединённые интересом; далее будет использоваться этот термин, иного хорошего перевода я не придумал), вплоть до 19 сентября. Сложно отталкиваться от одних лишь новостей, ибо они часто содержат неверную информацию или путаются в деталях. Несколько слов чиновника журналисту — этого просто недостаточно.



29 сентября правительственное новостное агентство также сообщило об изменении. Это всё ещё не было полностью официальным, ибо не сопровождалось ссылкой на какой-либо указ или закон. Но этого было достаточно, чтобы убедить TZ коммьюнити, что это действительно может случиться, после чего было инициировано изменение в базу данных временных зон IANA, а несколькими днями позже, 1 октября, было выпущено обновление.



Наконец 4 октября в правительственном бюллетене было выпущено официальное объявление. Примерно за три недели до вступления изменения в силу.



Многие представители IT индустрии, включая крупнейших игроков типа Apple, Google и Oracle, забрали данные из IANA и опубликовали их через свои собственные каналы. Например, Apple выпустила обновление с изменением зоны для iPhone и iPad вместе с обновлением iOS 9.1 21 октября, оставив пользователям лишь три дня, чтобы установить это обновление и избежать путаницы со временем.



Для Microsoft Windows, которая обновляет временные зоны несколько иначе и требует более высокого уровня подтверждения изменений, объявление было сделано 9 октября, а 20 октября было выпущено обновление.



В некоторых случаях день изменения был пропущен. Например, так случилось с pytz — популярной библиотекой временных зон для Python, обновление 2015.7 которой было опубликовано лишь 26 октября.



И что же в итоге случилось? Цитата BBC:



Сбитые с толку турки спрашивают «который час?» после того, как часы на электронных устройствах проигнорировали решение правительства отложить сезонное изменение времени.


Или вот из сообщений IBT:



Миллионы турок проснулись утром в замешательстве, так как смартфоны, планшеты и компьютеры автоматически перевели часы как и прочие страны в зоне восточноевропейского времени, несмотря на то, что Турция на две недели отложила перевод часов на час назад.


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



По соощениям IBNA в 2014-ом:



Невероятной путаницей для 52.9 миллионов турецких избирателей обернулось решение властей отложить на день перевод часов на час вперёд. Причиной, по которой переход на летнее время был отложен, по словам правительства Эрдогана было желание улучшить процесс выборов, но никто не подумал про фактор «новых технологий». Все смартфоны турецких граждан автоматически изменили время, и в итоге тысячи избирателей пришли на участки слишком рано и ждали ещё целый час, чтобы проголосовать.

То же самое произошло и с компьютерами, которые не загрузили новую версию ПО. Проблемы также возникли в системе доставки багажа в аэропорту Стамбула: система автоматически перевела время, игнорируя планы правительства, что в итоге привело к огромной задержке в выдаче багажа пассажирам. Кроме этого были проблемы со многими рейсами из-за того, что пассажиры путали время вылета.


А что насчёт остального мира?



Не только Турция не учится на своих ошибках, другие страны мира наступали на те же самые грабли не раз. Помните список в начале поста? Давайте чуть подробнее:




  • В Чили в 2015 году использовали постоянное летнее время, но 13 марта 2016 года правительство анонсировало переход на поясное время начиная с 15 мая (уведомление за два месяца).




  • В России 11 различных смещений во временных зонах, от UTC+02 до UTC+12, с их сложной историей изменений.

    27 марта 2016 года 6 регионов сменили временные зоны. Каждый из этих регионов выпустил свой собственный закон, задающий это изменение. Один из этих законов был подписан 30 декабря (уведомление за 12 недель), что вполне допустимо. Однако другие были подписаны 15 февраля (уведомление за шесть недель) или 9 марта (уведомление за две недели).

    Ещё два других региона ожидали подписания указов в течение всего этого периода, один из этих указов был подписан лишь 5 апреля с датой перехода 24 апреля (прим. пер.: речь о Магаданской области) (уведомление за три недели). Другой до сих пор ожидает подписания президентом. Ожидается, что это произойдёт в течение ближайших дней, а датой перехода будет 29 мая (уведомление за четыре недели) (прим. пер.: речь о Томской области; кстати, мы уже накатили апдейт).




  • Венесуэла была на UTC-4:30 с 2007 года, но недавно власти решили вернуться на UTC-4 с 1 мая 2016. О переходе впервые было объявлено 15 апреля, официально — 18 апреля с публикацией в правительственном бюллетене (уведомление за две недели).




  • Азербайджан в 2016 году отменил переход на летнее время. Изменение было запланировано на 27 марта, но никаких сообщений об этом не было вплоть до 17 марта (уведомление за десять дней).




  • Северная Корея переехала из UTC-9 в UTC-8:30 15 августа 2015. Об этом было объявлено 7 августа (уведомление за восемь дней).




  • В Гаити отменили переход на летнее время в 2016 году. Это должно было произойти 13 марта, но 12 марта (уведомление за один день!) правительство выпустило пресс-релиз, отменяющий изменение.



Прочие проблемы координации



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



Одно из таких мест — Фиджи. Переход на летнее время выполняется там с 2009 года. Однако каждый год правительство делает объявление о том, когда летнее время начнётся и когда оно закончится. Каждый год эти даты разные, и каждый раз до последнего момента не ясно, когда власти примут решение или что делать в случае, если они о нём не объявят. Было бы гораздо проще, если бы они приняли постоянное расписание, а объявление делали только в случае отклонений от этого расписания.



Другое такое место — Морокко, где расписание начала и конца летнего времени нормально определено, но каждый год начиная с 2012 там применяется «период приостановки летнего времени», когда летнее время заканчивается перед началом Рамадана и снова начинается чуть позднее. Это означает не только перевод часов четыре раза в течение календарного года, но также и то, что никто понятия не имеет, когда произойдут второй и третий переходы, пока власти не сделают объявление. Отчасти это обосновано тем, что даты Рамадана привязаны к наблюдаемому новолунию. Тем не менее, лично я считаю, что они должны зафиксировать переход на летнее время, пусть даже оно начинается до Рамадана и заканчивается после. Непредсказуемость дат приводит к тому, что становится слишком сложно узнать время в Морокко, если ты не в Морокко. (Кстати, Египет практиковал то же самое, но только в 2010 и 2014.)



Рекомендации правительствам стран



Прежде всего, я должен подчеркнуть, что это мои личные рекомендации. Я не говорю ни от лица своего правительства, ни своего работодателя, ни TZ коммьюнити. Эти рекомендации основаны на многолетнем опыте работы с временными зонами и наблюдениях происходящего.



Если вы собираетесь внести изменение в свою временную зону или зоны, — будь это изменение смещения от UTC, или же принятие или отмена летнего времени, или изменение дат начала и конца летнего времени, — пожалуйста, сделайте следующее:




  • Сделайте заблаговременное уведомление, хотя бы за шесть месяцев до изменения. Ещё лучше — за год или больше.

  • Оформите это уведомление в виде официального правительственного указа или принятием закона. Опубликуйте текст закона на официальном правительственном сайте.

  • Не забудьте указать все детали изменения, включая дату и время вступления изменения в силу. Например, «1 апреля 2017 год в 01:00 часы будут переведены вперёд на 30 минут». Не говорите просто «в апреле состоится перевод времени». Также, если изменение затрагивает только некоторые регионы страны, пожалуйста укажите точные области.

  • Уведомите своих граждан и весь мир через пресс-релиз и СМИ, но не полагайтесь исключительно на этот способ анонсирования. Каждое такое уведомление должно быть подкреплено официальным указом или законом.

  • Отправьте уведомление TZ коммьюнити. Для этого нужно просто послать письмо на tz@iana.org — адрес дискуссионного листа базы временных зон. Письмо должно содержать ссылку на опубликованный анонс на официальном сайте правительства.

  • Если предложенное изменение отменяется — также сделайте заблаговременное уведомление.



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



Рекомендации разработчикам ПО




  • Не пытайтесь изобрести свои собственные временные зоны или хардкодить список временных зон в приложении.

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

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

  • Вовремя обновляйте базу временных зон. Ознакомьтесь с механизмами вашей платформы или библиотеки, позволяющими делать это.

  • Подпишитесь на рассылку TZ Announcements, чтобы быть в курсе обновлений.

  • Если вы узнали о грядущем изменении во временной зоне в каком-то месте, или же у вас есть другие вопросы относительно временных зон в IT, присоединяйтесь к рассылке TZ Discussion.

  • Используйте timeanddate.com для проверки любых предположений касательно временных зон какого-то региона. Точность данных этого сайта проверена временем, а его владельцы — члены TZ коммьюнити.

  • Для Windows, .NET и прочих продуктов Microsoft следите за новостным каналом на этом сайте, чтобы узнавать, когда появляются обновления для платформы. (Тем не менее, используйте базу временных зон IANA везде, где возможно, даже если это означает использование сторонних библиотек.)







Испытываете ли вы проблемы (в плане поддержки кода и инфраструктуры) в связи с изменениями во временных зонах?


























































Проголосовало 4 человека. Воздержался 1 человек.




Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282550/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Идеальная производительность протокола HTTP

Вторник, 26 Апреля 2016 г. 14:48 (ссылка)

Один из аспектов понятия «производительность Web» заключается в том, чтобы уменьшить наблюдаемые пользователем задержки; получить готовую к работе страницу как можно быстрее. В отношении протокола HTTP это подразумевает, что идеальный протокол связи выглядит как-то так:







Клиент шлёт минимально необходимое количество данных, чтобы описать свой запрос, а сервер отдаёт ему минимально необходимое количество данных для отображения страницы и всё это происходит за минимально возможное количество раундов связи. Лишние данные, пересылаемые на сервер или получаемые с сервера, означают увеличение времени загрузки и повышение шансов потери пакетов, перегруженность канала связи. Лишние циклы отправки\приёма данных из-за «болтливости» протокола и задержки (особенно в мобильных сетях, где 100ms — лучшее возможное время отклика) тоже ухудшают ситуацию.



Итак, если мы описали идеальный случай — соответствует ли ему протокол HTTP? И можем ли мы ещё как-нибудь улучшить его?



HTTP/1.1

HTTP/1.1 это хороший протокол по целому ряду причин, но, к сожалению, производительность не одна из них по причине того, как современные веб-приложения его используют. А используют они его сегодня вот так:







Не очень-то хорошо.



Использование веб-приложениями протокола HTTP/1 достаточно «болтливо», поскольку клиент обращается к серверу снова и снова для загрузки необходимых ему файлов; сначала загружается HTML, затем CSS и Javascript. Загрузка каждого следующего файла добавляем в наш «разговор» с сервером новую главу, увеличивает общую задержку загрузки страницы, нарушая наше правило «минимальности необходимых раундов связи».



Более того, даже сами запросы к ресурсам уже добавляют много лишних данных, нарушая правило «минимальности необходимых данных». Это происходит из-за наличия заголовков вроде Referer, User-Agent и, конечно же, Cookie, которые повторяются в каждом запросе, умножаясь иногда в сотню раз от минимально необходимого их количества (по количеству ресурсов, необходимых средней страницей современного Веба).



Ну и наконец, из-за присущего протоколу HTTP/1 явлению HOL-блокировки, стало общей практикой помещать несколько отдельных ресурсов в один (например, CSS spriting). Все эти изящные хаки протокола HTTP/1, тем не менее, имеют свою цену; они вынуждают клиента загружать больше данных, чем ему необходимо в данный момент для показа конкретной страницы, что нарушает описанный нами идеальный случай, а значит мы не покажем страницу так быстро, как это только возможно.



Несмотря на всё сказанное, HTTP/1.1 всё же не так плох, даже в плане производительности. Например, в нём есть кеширование, что избавляет вас от повторной загрузки неизменённых ресурсов, а также условные запросы, что позволяет вам понять, нужно ли загружать новую версию файла.



HTTP/2



Протокол HTTP/2 пытается решать проблемы 1.1 несколькими путями:




  1. Полное мультиплексирование означает решение проблемы HOL-блокировки. Вы можете загружать все ресурсы своей страницы по одному HTTP-соединению и не волноваться о том, сколько для этого понадобится сделать запросов. «Оптимизации» со склеиванием файлов в один можно оставить в прошлом.

  2. Сжатие заголовков решает проблему их избыточности. Теперь вы можете вместить десятки (или даже сотни) запросов в буквально несколько IP-пакетов. Это серьёзно приближает нас к «минимально необходимому набору данных» нашего идеального протокола.

  3. HTTP/2 позволяет серверу отправлять данные клиенту ещё до их запроса клиентом, исходя из предположения, что они ему скоро понадобятся. Это уменьшает количество раундов связи клиента и сервера.





Таким образом, сеанс связи с использованием протокола HTTP/2 выглядит как-то так:







Здесь вы можете увидеть, как сервер начинает пересылку CSS и Javascript клиенту ещё до того, как клиент об этом попросил. Сервер знает, что клиент, запросивший HTML, с большой вероятностью запросит и относящиеся к нему CSS и Javascript файлы, а значит можно отправить их, не дожидаясь самого запроса. Таким образом, мы теряем меньше времени на ожидание, используем сеть более рационально.



Следует отметить, всё это работает не так уж просто. До сих пор в HTTP/2 есть открытые вопросы, касающиеся того, что и когда сервер должен считать необходимым к отправке без запроса клиента.



HTTP/2 + дайджесты кеша

Хороший вопрос, касающийся инициированной сервером пересылки файлов: «А что, если у клиента уже есть его копия в кеше?». Действительно, было бы глупо насильно отправлять клиенту что-то, что у него уже есть.



HTTP/2 позволяет клиенту в этом случае досрочно завершить загрузку такого ресурса, с помощью сообщения RESET_STREAM. Но даже в этом случае у нас гоняются лишние данные, добавляется ещё один раунд связи, чего хотелось бы избежать. Вы помните правило из первого абзаца статьи: «пересылать лишь минимально необходимое количество данных для отображения страницы».



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







Поскольку дайджесты кеша используют коды Голомба, реально предположить, что для среднего размера страницы браузеру понадобится менее 1000 байт, чтобы объяснить серверу, какие ресурсы есть у него в кеше.



Теперь мы действительно избегаем лишних циклов связи клиента и сервера, передачи лишних данных, склейки нескольких файлов в один и похожих хаков, а также неэффективной пересылки ненужных нам данных. Это очень существенно приближает нас к идеалу!



Дайджесты кеша пока только предложение к расширению протокола, но к ним существует большой интерес у HTTP-сообщества. Мы обязательно увидим и оценим их использование уже в самом ближайшем будущем.



TCP

Давайте поговорим о влиянии на общую производительность других протоколов, используемых браузером для загрузки страниц. А оно тоже может быть существенным: TCP использует троекратное рукопожатие ещё до того, как первый байт стоящего выше HTTP будет переслан:







Это добавляет «болтливости» каждому сеансу связи. TCP Fast Open позволяет приложениям отправлять данные прямо в SYN и SYN+ACK пакетах. К сожалению, это в данный момент поддерживается только в Linux и OSX, и более того, есть некоторые особенности применения TCP Fast Open именно с протоколом HTTP, над которыми сейчас работает сообщество. Например, не гарантируется, что данные, прикреплённые к SYN-пакету, будут пересланы лишь один раз. Это открывает уязвимость с потенциальными повторными запросами, которая может быть использована для атак. Таким образом, запрос POST — не лучший кандидат для применения TCP Fast Open. Более того, некоторые GET-запросы тоже имеют заметные побочные эффекты, а браузеры не имеют никаких средств, чтобы отличить такие запросы от тех, которые таких эффектов не имеют.



TLS

TLS добавляет ещё один уровень взаимодействия клиента и сервера, уже после того, как TCP соединение было установлено. Это выглядит вот так:







Это два полных цикла обмена сообщениями перед тем, как протокол HTTP отправит свой первый запрос; достаточно разговорчиво, не правда ли? Если клиент и сервер уже общались раньше, мы можем несколько сократить общение:







Вскоре TLS 1.3 позволит достичь «нулевого» рукопожатия для случая, когда клиент и сервер уже общались ранее — иными словами протокол HTTP получить возможность добавить полезную нагрузку уже в первый отправленный на сервер пакет данных. Но так же, как и с TCP Fast Open, понадобиться некоторое решение для избегания дублирования запросов.



HTTP/next

TCP Fast Open и TLS 1.3 уменьшают количество циклов связи клиента и сервера при открытии соединения. Другой способ достичь того же — переиспользовать уже ранее открытое соединение. Сейчас идёт дискуссия о том, как объединять соединения HTTP/2 более агрессивно; это позволит не только избежать затрат на открытие новых соединений, но и более эффективно использовать уже имеющиеся — протокол TCP наиболее хорош именно в долгоживущих, плотно заполненных данными соединениях. Это включает в себя отправку клиенту сертификатов, доказывающих, что соединение может быть безопасно переиспользовано для работы с другими источниками.



Сейчас обсуждаются даже более кардинальные эксперименты: замена TCP на UDP, навроде QUIC. Есть много спорных моментов, но сама перспектива свести начальный обмен данным фактически до нуля — очень привлекательна. Более того, возможность получить доступ к данным не в том порядке, как они были отправлены, тоже может быть очень полезна. Это ещё один способ избежать HOL-блокировок в TCP (протоколе с упорядоченной доставкой пакетов). Мы можем выбрать из потока пакетов нужные нам, понять, что какие-то были потеряны, запросить их повторно — и продолжить обработку следующих, не дожидаясь результатов повторного запроса.



QUIC только начинает свой путь, так что мы ещё не увидим хорошей его реализации какое-то время (а может быть и никогда вообще). Один из возможных вариантов — изучить на примере QUIC все плюсы и минусы подхода, чтобы понять, как мы можем улучшить производительность TCP, не ударяясь в столь кардинальные изменения архитектуры Web.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282517/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Манифест грядущих перемен сквозь призму рынка

Пятница, 15 Апреля 2016 г. 20:45 (ссылка)





Всем, привет! Вокруг мессенджеров наблюдается невероятный ажиотаж. Если раньше о том, что боты становятся основным технологическим трендом, говорили невнятно, то сейчас об этом пестрят заголовки крупнейших технологических СМИ. Но по прежнему многие к данной тенденции относятся с определенной долей скепсиса и я осмелюсь попробовать доказать почему боты и разговорный интерфейс в частности станут революцией.



Формация и конъюнктура



Как сказал бывший продакт менеджер Google Hangouts Бен Эйдельсон: “Обмен сообщениями — это форм-фактор, целая парадигма и самое главное — набор ожиданий пользователя, применяемый в разных рынках, сценариях и подходах”.



Главное преимущество сервисов мгновенных сообщений в том, что любая коммуникация асинхронная по умолчанию и синхронная при необходимости. Мессенджеры символизирует в себе историю отношений между людьми. Обработка сообщений происходит в контексте долговременных диалогов, где обсуждаемые темы меняются на протяжении всей беседы. Для сравнения старые SMS-клиенты не умели объединять сообщения от одного и того же отправителя, а в электронной почте диалоги формируются вокруг определенной темы.



За последние несколько лет сильно эволюционировал и сам формат сообщения. Наблюдается переход от текстовых форм коммуникации к мультимедийным. Пользователи все чаще отправляют разные фотографии, видео, голосовые сообщения, стикеры и многое другое.



В основе современного общения лежит передача эмоций, а не данных. Этому высказыванию свидетельствует огромная популярность смайлов и стикеров. Они взяли на себя функцию «языка тела», выражая сложные эмоции в одной картинке. Смайлы и стикеры в определенном смысле являются универсальным языком общения. Вне зависимости от своей национальности, каждый при их помощи может поделиться своими мыслями и чувствами.





Источник — Business Insider



Сочетание всех этих свойств и ожиданий позволило мессенджерам стать основной средой для связи. Мгновенные сообщения демонстрируют наибольший уровень вовлеченности пользователей, по сравнению со всеми остальными приложениями других категорий. Их большая популярность по сравнению с социальными сетями, объясняется двумя факторами:




  • Соцсети подразумевают элемент самоидентификации, сохраняя персональное электронное наследие. Информация в мессенджерах растворяется во времени, что не требует концентрации внимания на самовыражении. Ценность имеет сегодня и только сегодня.

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





Гегемония в цифрах





Источник — QZ



Whatsapp

Мировой лидер среди мессенджеров. В начале февраля WhatsApp достиг отметки в 1 млрд. активных пользователей. Открытия полноценного API, которое запланировано на середину 2016 года, ожидают тысячи разработчиков.



Facebook Messanger







900 млн. ежемесячных пользователей. На недавней конференции F8 от Facebook, социальная сеть анонсировала Messenger Platform. Эксперты называют это событие наиболее важным в технологической индустрии с момента появления App Store. В яблочной экосистеме к тому времени было всего 6 миллионов пользователей, но это ей непомешало стать предвестником новой эры «мобайл». А нынешняя база пользователей Messenger превышает общее количество когда-либо проданных iPhone.



WeChat

Лидер в Китае с MAU в 650 млн. Мессенджер представляет собой целую платформу с видеозвонками, новостной лентой, электронным кошельком, функцией «Избранные», схожей Evernote, играми, похожим на Shazaam сервисом, позволяющим искать музыку и даже почтовым клиентом. В WeChat зарегистрировано свыше 10 миллионов официальных аккаунтов компаний, большинство из которых уже научились обращать человеческий труд и ботов в синергию.



Skype







300 млн. ежемесячных пользователей. 30 марта 2016 года на ежегодной конференции Build от Microsoft была анонсирована платформа Skype Bot, которая позволит создавать текстовых и видеоботов для мессенджера. Также был представлен Microsoft Bot Framework для разработки ботов для Slack, Office 365, Skype и др.



Line

Еще один азиатский продукт, который покорил Японию, Тайланд и Тайвань обладает 210 миллионами ежемесячных пользователей. Line также является целой платформой для создания игр и маркетплейсом по продаже стикеров, который только за первый год существования сгенерировал сумму в $75 млн. Ежедневно пользователи Line отправляют и получают более 2 млрд стикеров.



Telegram

База активных пользователей свыше 100 млн в месяц. Ежедневно сервис пополняют еще 350 тысяч новых пользователей, а серверы доставляют около 15 миллиардов сообщений — в декабре 2014 года этот показатель достигал 1 миллиарда. Telegram удалось выбиться на 1 место в App Store более чем в 45 странах мира. На этой неделе вышло обновление Bot Platform 2.0. По оценкам Forbes в Telegram около 100 тысяч ботов. Одним из самых популярных среди них является TinaBot c почти 3 млн. пользователей.



Slack





Источник — Business Insider



Не могу не упомянуть в этом перечне Slack, который меняет принципы корпоративного общения. Его называют операционной системой. В Slack 2.3 миллиона пользователей и каждый из них в среднем проводит в день по 10 часов залогиненым в нем. 700 000 платных аккаунтвов, 60 000 команд. Состоявшемуся запуску Slack App Directory сопутствовало открытие фонда в $80 млн., средства которого предназначены на стимулирование разработки интеграций и ботов для этой платформы.



Snapchat

Вероятно, один из самых оригинальных мессенджеров. Благодаря самоуничтожающимся сообщениями и фокусом на графический контент Snapchat покорил тинейджеров США. Его ежедневная аудитория превышает 100 млн., которая отправляет более 700 млн. “снапов” и просматривает более 8 млрд. видео в сутки.



И другие

Также не стоит забывать про родоночальника мобильных мессенджеров iMessage с сотнями миллионов пользователей, канадский Kik вбирающий в себя все лучшее от WeChat, многочисленный QQ, Viber, KakaoTalk, Hangouts, ICQ и даже Instagram со своими Direct Messages. Еще есть SMS, приложения мгновенных сообщений от социальных сетей и отдельный сегмент рынка — платформы вроде Voximplant, Smooch, Layer и Twilio IP Messaging, которые позволяют встраивать мессенджер в приложение.



Смена эпохи



Золотой век мобильных приложений, счет которых идет на миллионы уже закончился. Большинство пользователей смартфонов скачивают 0 новый приложений в день, поскольку уже имеют необходимый набор, чаще всего состоящий из нескольких мессенджеров и клиентов для социальных сетей.







По данным SimilarWeb, через первые три дня после установки среднестатистическое приложение теряет 77% ежедневно активных пользователей, а через три месяца показатель удержания пользователей падает до 9%. Аналогичные цифры подтверждает исследование от Statista, но выборка сугубо по мессенджерам демонстрирует совершенно другой показатель удержания пользователей:





Источник — Statista



Обладая высоким уровнем вовлеченности и огромной аудиторией, которая мимимальным расчетам превышает 3 млрд. человек, месенджеры стали полноценной платформой. И на этой платформе возрождается новый этап технологической эволюции — боты.



Боты становятся конкурентами для других мобильных приложений. Они помогают узнать новости, курсы валют, книгу, музыку, забронировать отель, заказать товар, перевести слово и даже найти пару. Сложившаяся ситуация вам не напоминает 2008 год? А 1995? Только сегодня чат является браузером, а бот сайтом и выгода от этого явления очевидна как бизнесу, так и пользователям.



Каждая компания призывает клиента установить отдельное приложение, но вполне вероятно, что пользователь воспользуется им единожды. Несмотря на это, ему необходимо выполнить целый ряд действий: зайти в магазин приложений, найти его, ввести пароль, дождаться загрузки, создать учётную запись. Боты обладают другим уровнем интерактивности и открывают возможность мгновенного взаимодействия с окружающим миром.



Боты априори являются кроссплатформенным продуктом, дизайн которого заключается в подборе правильных слов. В связи с этим, их разработка значительно дешевле и проще по отношению к мобильным приложениям, которые помимо присутствия на iOS, Android и Windows Phone, требуют четкого соответствия стайлгайдам для каждой из платформ.



Любая революционная технология отличительна тем, что она расширяет горизонты и открывает новые возможности для человека. Появления персональных компьютеров ознаменовало пришествие века информации, интернет стал квинтэссенцией всех знаний человечества, смартфоны открыли доступ к этим знания с любой точки нашей планеты. Что такого могут дать нам боты? Они позволяют мгновенно получать любую необходимую информацию. “Кажется, что всё это слишком просто, чтобы называться революцией. В этом и заключается прелесть ботов” (Тед Ливингстон). Боты — начало нового интернета.



Большое спасибо всем за внимание.








Пользуетесь ли вы ботами?




























Проголосовало 60 человек. Воздержалось 16 человек.








Планируете ли создать своего бота?






































Проголосовало 54 человека. Воздержалось 23 человека.




Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/281731/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<стандарты - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda