Зачем нужен SESSIONID, когда ту же задачу решает CSI-Token? Тем более cookie имеют известные проблемы с безопасностью. Особенно при передаче по HTTP (хотя HTTPS тоже вскрывается). CSI-Token не только идентифицирует пользователя, но и делает это более надежным способом: защита от компрометации, от CSRF, XSS и трекинга. Я оговорюсь, что 100% защиты не существует. Но существенное уменьшение вероятности эксплуатации известных атак — хорошее преимущество.
Кстати, обратите внимание, у меня мастер-ключ это не пароль! Это 256-битная случайная последовательность, полученная как результат работы биологического ДСЧ.
можно синхронизировать не пароли, а контейнер с паролями, зашифрованный мастер-ключом, который только в голове у человека
данный подход оставляет уязвимость к брутфорсу слабых паролей и клавиатурным шпионам. Первое ещё решаемо. Второе — сложнее.
Благодарю за столь развернутый комментарий! Вы поднимаете важные вопросы. Боюсь, что формат комментариев к статье не самый удобный вариант для ответов.
запутанные правила передачи токенов… Их трудно запомнить и при работе с ними легко допустить ошибку
Эти правила для разработчиков браузера. Сложными они кажутся лишь потому, что мне не удалось их лаконично описать. Моя вина. Я попытался не только описать эти правила, но объяснить зачем они такие, да на конкретных примерах, да с картинками. Это перегрузило и так не простую статью. Что касается сложности, если почитать стандарт CSS… Бедные разработчики браузеров!
Разработчикам веб-сайтов не нужно их запоминать. Всю низко-уровневую работу с протоколом, по задумке, должны на себя брать библиотеки, оформленные, например, как фильтр запросов.
Что касается фронтенд разработчиков. Всё что им нужно помнить — несколько простых правил: не использовать в закрытых разделах сайта скрипты, загружаемые с CDN или сторонних ресурсов (точне можно, если осторожно); осторожнее делать редиректы на сайты-партнеров. Эти рекомендации стоит включить в соответствующую главу. Но сейчас её нет. Мой косяк.
ваше решение слишком сложное. Вообще, в вашем протоколе все сложное. Это его ахиллесова пята.
Боюсь, что не без этого. Но с другой стороны, откройте любой стандарт. Тот же HTTP, SAML, OAuth, Kerberos. И там тоже всё не так просто. Я за простоту.
На мой взгляд, один из вариантов решения для борьбы с CSRF мог бы быть...
Так сейчас так и делается. И не только так. Но нередко даже самые лучшие профессионалы допускают досадные ошибки. Ибо такие «правила» тоже необходимо четко помнить и держать в голове при разработке сайта. Предлагаемый протокол может существенно затруднить эксплуатацию уязвимостей на веб-страницах «из коробки». Но 100% гарантий вам никто не даст. Это надо понимать.
Также, у вас неудачная идея вида «браузер может отправить заголовок с запросом на любую страницу».
Я даже неправильно поставил акцент: не может, а обязан. Ибо не только веб-страницы будут требовать авторизации, но и загружаемые с них ресурсы (файлы из закрытой секции, как пример). Отсюда напрашивается и вариант реализации на стороне сервера — фильтр запросов, обрабатывающий протокол.
Как, например, насчет залогинивания под двумя аккаунтами сразу?
С этим кейсом не знаком. Интересуют подробности. И как это технически реализуется сейчас. Напишите.
Или вы имеете в виду ситуации, когда вы одновременно, скажем, в яндекс.почте работаете с несколькими ящиками? Подобное реализуется. Я не стал писать, боясь и так переусложнить статью (признаюсь стоило бы выкинуть из неё несколько глав).
например может быть несколько приложений внутри одного домена
Думаю, что это плохая практика. Даже для существующей схемы на основе cookie. Но и это решаемо. Спасибо за этот юзер кейс. Буду исследовать.
Это явно фича для продвинутых, а не обычных пользователей.
Согласен. Но большинство современных фич тоже когда-то были «только для продвинутых».
Сайты, очевидно, хотят контролировать вид формы входа/регистрации и их процесс, чтобы иметь возможность сделать его лучше, чем у конкурентов, а не «как у всех». Чтобы иметь возможность сделать его простым.
Знаете, мне когда-то зацепил подход сайта drom.ru. Хочешь подать объявление о продаже авто? Да не вопрос. Подавай. На телефон приходит код твоего объявления. Ты можешь через неделю отправить платную СМС-ку, чтобы поднять свое объявление в топ. Или ничего не делать. Никаких предварительных регистраций, логинов и паролей. Это, я считаю, и просто и удобно. Не знаю как сейчас там. Но на авито или ам.ру продавать авто точно не буду.
сохранить токен с сайта в браузер и достать токен из браузера?
Центральная идея протокола — токен назначается не сайтом, а пользователем самим себе. Собственно, протокол и назван Client Self Identification.
Кроссдоменную авторизацию проще было бы делать без участия встроенных в браузер протоколов, используя протоколы вроде OAuth2. Сайты ведь всегда могут передавать друг другу какие-то токены через адресную строку.
Сейчас так и делается. Поверьте, не проще. Для пользователя — да. Но для веб-разработчиков нет. И хотя есть библиотеки, реализующие за вас не простой OAuth2, существует ещё и дополнительная работа, ложащаяся на плечи разработчиков/администраторов сайта. Например, ситуации, когда внезапно «упало». Нет доступа до сервера SSO. Закончил срок действия сертификат ключа. Да и регистрация веб-сайта на SSO-сервере тоже задача не излегких. Особенно на этапе разработки.
Ваше решение не поможет анонимности, так как сайты будут игнорировать его и принуждать пользователя к традиционной авторизации через куки, чтобы отслеживать их.
Я надеюсь настанут такие времена, когда такие сайты вымрут, как класс. Пользователи своими «визитами» (точнее их отсутствием) будут голосовать против них.
В описании протокола в пункте 2.3 вы считаете, что запросы отправляются по одному по очереди, однако браузеры шлют запросы параллельно. Запросы могут выполняться очень долго или отваливаться по таймауту. У вас это учтено?
Учтено. Первый запрос на сайт браузер посылает на сервер и ждет от него ответа. Как правило, это код HTTP-страницы. Только после получения её кода, когда DOM попадает на парсер, браузер начинает группировать запросы и слать их пачками параллельно. В этот момент браузер уже получил соль от сервера. Он пришел с кодом HTTP-страницы.
Если загружается не страница, а конкретный файл (по прямой ссылке), то тут вообще всё проще.
Чуть выше я как раз-таки и пишу: «В идеале CSI-Salt должен меняться при каждом запросе браузера к серверу. Однако это может быть затратным требованием с точки зрения вычислительных ресурсов. Кроме того, это может «убить» возможность отправки параллельных запросов на сервер.»
Также в сноске я пишу: «Время, через которое делается изменение CSI-Salt определяется браузерами самостоятельно. Это может происходить после серии запросов, после таймаута, после определенного числа запросов.»
Допустим, браузеру надо отправить параллельно 50 запросов на загрузку статики. Он к каждому будет прикреплять поле changed или только к первому?
Тоже самое касается запроса с ключем Changed-To. Браузер шлет запрос и ждет на ответа сервера. Только получив положительный (или отрицательный) ответ с заголовком CSI-Token-Action, начинает слать запросы «пачками». Запрос с ключем Change-To относительно редкая операция. Возникает в момент, когда пользователь активирует постоянный ключ (браузер должен перезагрузить страницу). Соответственно, вначале браузер дожидается ответа на этот запрос. А после, получив DOM страницы и заголовок CSI-Token-Action, начинает уже слать запросы пачками. К сожалению, я этот момент (перезагрузки браузером страницы после активации ключа) не отразил ни в тексте, ни в анимациях.
Зачем при передаче по HTTPS как-то шифровать или хешировать токен, мне непонятно.
Затем, что HTTPS-трафик тоже может быть перехвачен. У меня есть глава по этому поводу, но я не стал включать её в статью, боясь вызвать ненужный спор. Если хотите, я могу вам скинуть в её личку. Кроме того, протокол проектировался без учета среды передачи (HTTP/HTTPS). Поэтому правила защиты токена едины.
для чего шифровать токен, который к другим сайтам не подойдет?
другим не подойдет, но имея такой токен можно выполнить легитимный запрос на целевой сайт от имени жертвы пока «сессия жива». Такая модель угроз рассматривается в разделе «4.6 Компрометация токена при передаче».
Зачем нужны Sender/Receiver и правила работы с ними, если гораздо проще просто не передавать токен при кроссдоменных запросах
Затем, чтобы иметь возможность реализовывать меж-доменную идентификацию на группе взаимосвязанных доменов А, В, С. Это стандартная ситуация. Почему меж-доменная идентификация A,B,C возможна, но при этом трекинг сторонними сайтами (например, группой сайтов В, С,D) уже не возможен, рассматривается в модели угроз «4.1 Трекинг пользователя».
Ещё раз повторюсь эти правила — для разработчиков браузеров. Рядовой пользователь или веб-мастер даже не будет знать о них.
Какая выгода сайтам от интеграции вашего решения?
О я ждал этого вопроса! Этому можно посвятить отдельную статью.
Ну, например, какая выгода сайту от использования HTTPS супротив HTTTP? Безопасность пользователя? Но ведь какое дело до безопасности разработчику сайта?
Дизайнеру сайта, например, проще — нет лишних виджетов. Сейчас всё движется в сторону простоты. На мобильном экране с маленьким экраном лишний виджет — головная боль для UX-специалиста.
Веб-мастеру: минус несколько стандартных служебных страниц (регистрация, восстановления пароля, авторизации).
Ну и, наконец, простота для пользователя. Как следствие, увеличение конверсии.
Действия могут вызываться яваскриптом или мета-тегами.
Ни в коем случае в это не должен вмешиваться javascript! Красными буквами это выписать! Это потенциальная дыра!
можно использовать существующие наработки по использованию смарт-карт, которой ключ по сути и является
Я писал про плюсы и минусы смарт-карт. Протокол не налагает ограничений на источник ключевой информации. Это могут быть и аппаратные устройства с двух-факторной авторизацией.
С точки зрения протокола, она будет считаться ссылкой на внешний сайт, созданной внешним сайтом.
все верно.
Но есть ли какие-то препятствия к тому, чтобы считать её «доверенной»
Есть. site1.ru не может ручаться за действия скрипта с сайта site2.ru, который по факту может принадлежать сторонней организации. Это небезопасная операция. Если у вас есть пример ситуации, где это реально нужно, давайте конкретный пример, обсудим.
Я приведу свой. Сейчас на страницах Сбербанк-Онлайн внедрена Яндекс.Метрика. Сторонний скрипт от компании, с которой у Сбербенка нет никаких юридических договоренностей, вроде NDA. Кто видел в действии ВебВизор метрики, тот знает, что она записывает реально «все» ваши действия на сайте: движения мышкой, какой текст выделяли, что и куда вводили. Естественно туда утекает и ваш логин/пароль.
Каждый счетчик метрики имеет уникальный номер. Сотрудникам Яндекса не составляет проблем подгружать именно на страницу Сбербанк-Онлайна модифицированную версию метрики, которая делает «дополнительную» работу.
Я когда проектировал прокол, особо учитывал это случай.
Для тех, кто часто меняет телефоны, может быть подойдет решение в виде SD-смарт-карты, которая и будет хранить мастер-ключ. Меняете телефон, переставляете карту. Вот только слотов под SD-карты у телефонов не так сказать, чтобы много.
Протокол не накладывает ограничения на источник ключевой информации. Это может быть браузер, или некий security-proxy, или хардварный девайс.
то есть вот захочу на работе или в недовернном окружении
Ваше право. Но не храните все яйца в одной корзине.
Dash, OnePassword, LastPass могут использоваться совместно с описанным протоколом. Он (протокол) не отменяет других средств защиты, а органично может их дополнить.
Для классических парольных менеджеров — риски аналогичные. Для «сохраненных» паролей в браузере — тоже самое. Надо понимать, что 100% защиты не существует. В главе 3, я даю рекомендации по защите ключевой информации.
Мастер-ключ (который по факту просто случайное 256-битное число; не пароль пользователя!) может использоваться на сайтах, для которых вам не жалко потерять авторизацию (всякие одноразовые форумы, магазинчики). Мастер ключ дает вам 100% мобильности, но и повышенный риск. Я об этом в статье писал.
Для сайтов, к которым доступ чувствительный, нужно использовать только индивидуальные 256-битные ключи, хранимые на смарт-карте (на отчуждаемых носителях с двух-факторной авторизацией).
Я знаком с ЕСИА (подсистема госуслуг, часть СМЭВ) не понаслышке. Занимался интеграцией двух информационных систем в ЕСИА (по протоколам SAML и OAuth), и юридической регистрацией этих систем. В настоящее время обслуживаю одну из информационных систем, интегрированных в СМЭВ.
Сервера надежно защищены
Хотелось бы в это верить. Боюсь, что защита больше «на бумаге». Я видел, как «грамотные» сотрудники пересылали по Skype и TeamViewer секретные дистрибутивы ключей от VipNet с дефолтными паролям, дающие возможность работы с защищенными ресурсами.
Но самое главное, любое SSO делает вас зависимыми от третьей стороны. И если по каким-то причинам она недоступна вам или веб-серверу, то…
Вот такое изображение я частенько вижу:
Периодически ЕСИА проводит «профилактические работы». Из-за которых не доступны многие гос.сервисы (запись к врачу, налоговая, гос.закупки).
Вот только подключиться к ним нельзя...
Всё правильно, подключение преимущественно только для органов власти, предоставляющих государственные услуги.
Керберос (как и SAML, OAuth) — это протокол авторизации, где требуется посредник (арбитр): третья сторона (Key distribution center). Что делает вас зависимым от этой стороны. Предлагаемая схема авторизации — двусторонняя. Вы и сайт не зависите от кого либо.
Я изучал этот протокол. Возможно, несколько поверхностно. Если Вы считаете, что я «переизобрел Керберос», буду раз, если покажите в чём именно совпадение.
Центральная идея — клиент сам себя идентифицирует, присваивая себе уникальный номер. Никто, кроме клиента не знает, как он сформирован.
Сейчас идентификацией своих пользователей занимается сам сервер, назначая вам некий ID. Схема переворачивает эту идею наоборот.
Так же из протокола необходимо вырезать браузер… будет сливать все ваши токены ни чуть не хуже бесконечного множества сайтов
Золотые слова. Я думал об этом.
Только у меня правила вычисления токена сильно завязаны на DOM-модель и её состояние, к которому у прокси не будет доступа. Но кто сказал, что нельзя решить и эту проблему. Или сделать комбинированный вариант. Нужно думать.
Во первых — выделите главное. И сделайте из него верхний уровень протокола.
Вы правы, стоит использовать опыт OSI. Чётко разделить зоны ответственности.
У меня аж зуд появился на написание прокси.
У меня самого зачесались руки и я набросал концепт-код серверной части (пока на PHP; хочу ещё в виде фильтра запросов на Java под tomcat). А ещё нужен тестовый плагин для браузера.
Я уверен, что тестовая имплементация протокола (в виде рабочего концепта), — правильный (хотя и затратный) способ для оценки его сложности/легкости, удобства/неудобства. И единственный способ, чтобы прогнать все возможные сценарии.
Ух-ты, ж! Нет, конечно. Иначе бы не потратил почти 4 месяца на разработку и публикацию. Беру таймаут на изучение этого протокола. Если он лучше предложенного (а я, полагаю, что очень может быть) и нет никаких идей из данного протокола, которые можно было бы применить к WAA, то сниму публикацию с Хабра.
Мне вот, что интересно. Как, скажем, в 1983 году разработчики умудрялись создавать такой крутой пиксель-арт? Сейчас легко нарисовать нужные изображения в Corel, Photoshop, Blender, Z-Brush, Substance Painter...) пользуясь современными мышками и графическими планшетами. А затем, при помощи мощных современных программ, конвертировать их как угодно…
Но тогда? Манипулятор мышь появился в 1981 году (если судить по Вики). Цветные мониторы — ещё редкость. 16-цветный VGA появился в 1987 году. Графических планшетов для рисования не было даже в проекте. Я уже не говорю про мощный графический софт (типа упомянутых выше программ). То, что было — уровень современного MsPaint. Как они это делали? Не на бумаге же рисовали. PatientZero было бы очень интересно почитать статью про технику создания графики в то время
Issue 9
А не возникнет ли исключение IndexOutOfBoundsException в случае, когда files.Length == 0? Конкретно в инструкции: files[0]. Или в коде выше этого не допускается? Если я прав, то, возможно, стоит добавить в PVS-Studio соответствующую эвристику.
Есть ощущение, что человек, писавший код Elasticsearch (ну или конкретно данные куски приведенного кода), пришел из мира С/С++ и не совсем хорошо знал Java. Что навело на эти мысли?
Шаблоны из мира С:
1. Частое использование static
2. Предпочтение массивов использованию классов/коллекций; вообще слишком частое использование массивов.
3. Путаница == и equals.
4. Паттерн преобразования одного примитивного типа к другому (int)x.
5. Работа с текстом, не как с объектом, а как с массивом. for (; i < s.length() && (s.charAt(i) != ' ' || s.charAt(i) != '\t'); i++), или line.getBytes(StandardCharsets.UTF_8);
Вообще чувствуется дух C/C++. Процедурный подход превалирует над объектным.
Довод в пользу плохого знания Java:
1. сравнение line.startsWith("--" + boundary) c false не требуется, т.к. startsWith возвращает логическое значение.
2. игнорирование библиотечных функций Java. Например в методе withRestUriAndMethod можно было бы воспользоваться классом URL/URI, чтобы извлечь фрагмент. На автор кода решил, похоже, изобрести свой велосипед.
3. Инструкцию for (int i = 0; i < values.length; i++) можно было заменить на более понятный итератор for (Object value: values), избавившись от необходимости каждый раз писать values[i] instanceof. Вообще весь блок цикла в setSortValues, стоило вынести в отдельную функцию isPrimitiveClass и написать на неё тест.
4. Если уж используешь Objects.equals, то левая часть бессмысленна в условиях вида (frequency == null || Objects.equals(frequency, datafeed.getFrequency())
Ну и по мелочи:
1. Несколько смущает конструкция context.instanceClazz. Тоже самое: printStackTrace.
2. Похоже, что разработчик не пишет юнит-тесты, а если и пишет, то не запускает. Иначе ошибки в char64, findNextWhiteSpace всплыли бы сразу.
3. От методов findNextWhiteSpace/skipWhiteSpace стоит отказаться в пользу специализированного итератора. На такой итератор легче написать тест (чем на закрытый член private static). Плюс избавляемся от паттерна «GodObject».
4. Вообще наличие static-функций не в утилитарном библиотечном Java классе — явный сигнал к рефакторингу класса.
Ну, говоря для «каждого», я не утверждал, что нужно использовать циклы. Собственно, есть 2 варианта:
1) делать расчеты для всех нейронов одновременно (используя суперскалярность процессора)
2) делать расчеты пачками нейронов, используя цикл, в случае, если у вас дефицит «вычислителей»
Соответственно, рассуждения про 10^12 процессоров не имеют смысла.
Я думал, что это очевидно: когда вам необходимо выполнить K независимых операций, максимального ускорения вы достигнете, взяв K «вычислителей» (процессоров, блоков АЛУ, кластеров — не важно). Если вы не можете взять K вычислителей, а можете только M < K, то вы будете вынуждены выполнить расчеты в несколько (K/M + 1) подходов (читай — циклов).
Посыпаю голову пеплом: я сделал оценку 10^12, полагая, что у нас будет полносвязная НС шириной 10^4 нейронов и 10^4 слоев. А это не так. Но не отменяет того факта, что приблизительный порядок операций, которые нужно затратить на вычисление одного слоя: ~(10^4)^2 = 10^8. Умножьте это ещё на количество слоев.
Отдельные умножения распараллелить не получится!
Но разве суперскалярные процессоры этим не занимаются, когда одной инструкцией позволяют найти произведение сразу группы чисел?
Нужно бить не на отдельные операции, а не кучки в миллиард операций. И каждый миллиард выполнять независимо.
Вот здесь, прошу прощения, реально я Вас не понял. Что поменяется, например, для задачи «выполнить K независимых операций»? Можете подробнее?
но это нельзя и не нужно распараллелить за пределы одного процессора
Соглашусь. В противном случае придется передавать входные данные между процессорами от слоя к слою. Я, думаю, Вы про это.
Попытка закопаться в операции умножения мешают вам обдумать более практичные способы.
Какие?
Надеюсь, смог донести мысль...
Знаете, я прочитал Ваш комментарий, наверное, раз 40. Иногда мне казалось, что я всё понимаю. Иногда — ничего не понимал. Наверное, настоящее понимание происходит тогда, когда появляются вопросы. Их я и озвучил.
Основная мысль, которую я хотел бы донести до читателя статьи и всех верующих в силу глубоких нейронных сетей в деле построения сильного ИИ состоит в том, что ассимптотическая сложность расчетов нейронных сетей растет, минимум, квадратично и сильно обгоняет возможности роста современных процессоров и их ансамблей в виде кластеров. На существующих компьютерах построить сильный ИИ (взяв НС побольше, да кластер помощнее), боюсь, не удастся. Нужны принципиально иные технологии.
Не нужно ускорять одно перемножение, матрицы можно перемножать независимо.
Боюсь, я не правильно выразился. Речь шла не об ускорении одного только перемножения.
Речь шла о том, что мы можем параллельно перемножать матрицы (вычисляем коэффициенты в каждом слое нейронной сети), кроме этого для каждой матрицы каждый элемент тоже можем рассчитывать параллельно (каждый нейрон все сети рассчитывается независимо), и даже каждое попарное произведение (вес нейрона * вес связи), требуемое для расчета этого самого элемента матрицы, мы тоже, чтобы ускориться, можем вычислять параллельно.
Но даже такая супер-параллельность нас не спасет от необходимости выполнять часть последовательных операций. А они возникают здесь:
1) передача данных от одного слоя к другому
2) передача от блоков умножения к блокам сложения (при расчете итоговой суммы связей каждого нейрона)
данный подход оставляет уязвимость к брутфорсу слабых паролей и клавиатурным шпионам. Первое ещё решаемо. Второе — сложнее.
Эти правила для разработчиков браузера. Сложными они кажутся лишь потому, что мне не удалось их лаконично описать. Моя вина. Я попытался не только описать эти правила, но объяснить зачем они такие, да на конкретных примерах, да с картинками. Это перегрузило и так не простую статью. Что касается сложности, если почитать стандарт CSS… Бедные разработчики браузеров!
Разработчикам веб-сайтов не нужно их запоминать. Всю низко-уровневую работу с протоколом, по задумке, должны на себя брать библиотеки, оформленные, например, как фильтр запросов.
Что касается фронтенд разработчиков. Всё что им нужно помнить — несколько простых правил: не использовать в закрытых разделах сайта скрипты, загружаемые с CDN или сторонних ресурсов (точне можно, если осторожно); осторожнее делать редиректы на сайты-партнеров. Эти рекомендации стоит включить в соответствующую главу. Но сейчас её нет. Мой косяк.
Боюсь, что не без этого. Но с другой стороны, откройте любой стандарт. Тот же HTTP, SAML, OAuth, Kerberos. И там тоже всё не так просто. Я за простоту.
Так сейчас так и делается. И не только так. Но нередко даже самые лучшие профессионалы допускают досадные ошибки. Ибо такие «правила» тоже необходимо четко помнить и держать в голове при разработке сайта. Предлагаемый протокол может существенно затруднить эксплуатацию уязвимостей на веб-страницах «из коробки». Но 100% гарантий вам никто не даст. Это надо понимать.
Я даже неправильно поставил акцент: не может, а обязан. Ибо не только веб-страницы будут требовать авторизации, но и загружаемые с них ресурсы (файлы из закрытой секции, как пример). Отсюда напрашивается и вариант реализации на стороне сервера — фильтр запросов, обрабатывающий протокол.
С этим кейсом не знаком. Интересуют подробности. И как это технически реализуется сейчас. Напишите.
Или вы имеете в виду ситуации, когда вы одновременно, скажем, в яндекс.почте работаете с несколькими ящиками? Подобное реализуется. Я не стал писать, боясь и так переусложнить статью (признаюсь стоило бы выкинуть из неё несколько глав).
Думаю, что это плохая практика. Даже для существующей схемы на основе cookie. Но и это решаемо. Спасибо за этот юзер кейс. Буду исследовать.
Согласен. Но большинство современных фич тоже когда-то были «только для продвинутых».
Знаете, мне когда-то зацепил подход сайта drom.ru. Хочешь подать объявление о продаже авто? Да не вопрос. Подавай. На телефон приходит код твоего объявления. Ты можешь через неделю отправить платную СМС-ку, чтобы поднять свое объявление в топ. Или ничего не делать. Никаких предварительных регистраций, логинов и паролей. Это, я считаю, и просто и удобно. Не знаю как сейчас там. Но на авито или ам.ру продавать авто точно не буду.
Центральная идея протокола — токен назначается не сайтом, а пользователем самим себе. Собственно, протокол и назван Client Self Identification.
Сейчас так и делается. Поверьте, не проще. Для пользователя — да. Но для веб-разработчиков нет. И хотя есть библиотеки, реализующие за вас не простой OAuth2, существует ещё и дополнительная работа, ложащаяся на плечи разработчиков/администраторов сайта. Например, ситуации, когда внезапно «упало». Нет доступа до сервера SSO. Закончил срок действия сертификат ключа. Да и регистрация веб-сайта на SSO-сервере тоже задача не излегких. Особенно на этапе разработки.
Я надеюсь настанут такие времена, когда такие сайты вымрут, как класс. Пользователи своими «визитами» (точнее их отсутствием) будут голосовать против них.
Учтено. Первый запрос на сайт браузер посылает на сервер и ждет от него ответа. Как правило, это код HTTP-страницы. Только после получения её кода, когда DOM попадает на парсер, браузер начинает группировать запросы и слать их пачками параллельно. В этот момент браузер уже получил соль от сервера. Он пришел с кодом HTTP-страницы.
Если загружается не страница, а конкретный файл (по прямой ссылке), то тут вообще всё проще.
Чуть выше я как раз-таки и пишу: «В идеале CSI-Salt должен меняться при каждом запросе браузера к серверу. Однако это может быть затратным требованием с точки зрения вычислительных ресурсов. Кроме того, это может «убить» возможность отправки параллельных запросов на сервер.»
Также в сноске я пишу: «Время, через которое делается изменение CSI-Salt определяется браузерами самостоятельно. Это может происходить после серии запросов, после таймаута, после определенного числа запросов.»
Тоже самое касается запроса с ключем Changed-To. Браузер шлет запрос и ждет на ответа сервера. Только получив положительный (или отрицательный) ответ с заголовком CSI-Token-Action, начинает слать запросы «пачками». Запрос с ключем Change-To относительно редкая операция. Возникает в момент, когда пользователь активирует постоянный ключ (браузер должен перезагрузить страницу). Соответственно, вначале браузер дожидается ответа на этот запрос. А после, получив DOM страницы и заголовок CSI-Token-Action, начинает уже слать запросы пачками. К сожалению, я этот момент (перезагрузки браузером страницы после активации ключа) не отразил ни в тексте, ни в анимациях.
Затем, что HTTPS-трафик тоже может быть перехвачен. У меня есть глава по этому поводу, но я не стал включать её в статью, боясь вызвать ненужный спор. Если хотите, я могу вам скинуть в её личку. Кроме того, протокол проектировался без учета среды передачи (HTTP/HTTPS). Поэтому правила защиты токена едины.
другим не подойдет, но имея такой токен можно выполнить легитимный запрос на целевой сайт от имени жертвы пока «сессия жива». Такая модель угроз рассматривается в разделе «4.6 Компрометация токена при передаче».
Затем, чтобы иметь возможность реализовывать меж-доменную идентификацию на группе взаимосвязанных доменов А, В, С. Это стандартная ситуация. Почему меж-доменная идентификация A,B,C возможна, но при этом трекинг сторонними сайтами (например, группой сайтов В, С,D) уже не возможен, рассматривается в модели угроз «4.1 Трекинг пользователя».
Ещё раз повторюсь эти правила — для разработчиков браузеров. Рядовой пользователь или веб-мастер даже не будет знать о них.
О я ждал этого вопроса! Этому можно посвятить отдельную статью.
Ну, например, какая выгода сайту от использования HTTPS супротив HTTTP? Безопасность пользователя? Но ведь какое дело до безопасности разработчику сайта?
Дизайнеру сайта, например, проще — нет лишних виджетов. Сейчас всё движется в сторону простоты. На мобильном экране с маленьким экраном лишний виджет — головная боль для UX-специалиста.
Веб-мастеру: минус несколько стандартных служебных страниц (регистрация, восстановления пароля, авторизации).
Ну и, наконец, простота для пользователя. Как следствие, увеличение конверсии.
Ни в коем случае в это не должен вмешиваться javascript! Красными буквами это выписать! Это потенциальная дыра!
Я писал про плюсы и минусы смарт-карт. Протокол не налагает ограничений на источник ключевой информации. Это могут быть и аппаратные устройства с двух-факторной авторизацией.
Есть. site1.ru не может ручаться за действия скрипта с сайта site2.ru, который по факту может принадлежать сторонней организации. Это небезопасная операция. Если у вас есть пример ситуации, где это реально нужно, давайте конкретный пример, обсудим.
Я приведу свой. Сейчас на страницах Сбербанк-Онлайн внедрена Яндекс.Метрика. Сторонний скрипт от компании, с которой у Сбербенка нет никаких юридических договоренностей, вроде NDA. Кто видел в действии ВебВизор метрики, тот знает, что она записывает реально «все» ваши действия на сайте: движения мышкой, какой текст выделяли, что и куда вводили. Естественно туда утекает и ваш логин/пароль.
Каждый счетчик метрики имеет уникальный номер. Сотрудникам Яндекса не составляет проблем подгружать именно на страницу Сбербанк-Онлайна модифицированную версию метрики, которая делает «дополнительную» работу.
Я когда проектировал прокол, особо учитывал это случай.
Протокол не накладывает ограничения на источник ключевой информации. Это может быть браузер, или некий security-proxy, или хардварный девайс.
Dash, OnePassword, LastPass могут использоваться совместно с описанным протоколом. Он (протокол) не отменяет других средств защиты, а органично может их дополнить.
Мастер-ключ (который по факту просто случайное 256-битное число; не пароль пользователя!) может использоваться на сайтах, для которых вам не жалко потерять авторизацию (всякие одноразовые форумы, магазинчики). Мастер ключ дает вам 100% мобильности, но и повышенный риск. Я об этом в статье писал.
Для сайтов, к которым доступ чувствительный, нужно использовать только индивидуальные 256-битные ключи, хранимые на смарт-карте (на отчуждаемых носителях с двух-факторной авторизацией).
Хотелось бы в это верить. Боюсь, что защита больше «на бумаге». Я видел, как «грамотные» сотрудники пересылали по Skype и TeamViewer секретные дистрибутивы ключей от VipNet с дефолтными паролям, дающие возможность работы с защищенными ресурсами.
Но самое главное, любое SSO делает вас зависимыми от третьей стороны. И если по каким-то причинам она недоступна вам или веб-серверу, то…
Вот такое изображение я частенько вижу:
Периодически ЕСИА проводит «профилактические работы». Из-за которых не доступны многие гос.сервисы (запись к врачу, налоговая, гос.закупки).
Всё правильно, подключение преимущественно только для органов власти, предоставляющих государственные услуги.
Я изучал этот протокол. Возможно, несколько поверхностно. Если Вы считаете, что я «переизобрел Керберос», буду раз, если покажите в чём именно совпадение.
Центральная идея — клиент сам себя идентифицирует, присваивая себе уникальный номер. Никто, кроме клиента не знает, как он сформирован.
Сейчас идентификацией своих пользователей занимается сам сервер, назначая вам некий ID. Схема переворачивает эту идею наоборот.
Золотые слова. Я думал об этом.
Только у меня правила вычисления токена сильно завязаны на DOM-модель и её состояние, к которому у прокси не будет доступа. Но кто сказал, что нельзя решить и эту проблему. Или сделать комбинированный вариант. Нужно думать.
Вы правы, стоит использовать опыт OSI. Чётко разделить зоны ответственности.
У меня самого зачесались руки и я набросал концепт-код серверной части (пока на PHP; хочу ещё в виде фильтра запросов на Java под tomcat). А ещё нужен тестовый плагин для браузера.
Я уверен, что тестовая имплементация протокола (в виде рабочего концепта), — правильный (хотя и затратный) способ для оценки его сложности/легкости, удобства/неудобства. И единственный способ, чтобы прогнать все возможные сценарии.
Но тогда? Манипулятор мышь появился в 1981 году (если судить по Вики). Цветные мониторы — ещё редкость. 16-цветный VGA появился в 1987 году. Графических планшетов для рисования не было даже в проекте. Я уже не говорю про мощный графический софт (типа упомянутых выше программ). То, что было — уровень современного MsPaint. Как они это делали? Не на бумаге же рисовали.
PatientZero было бы очень интересно почитать статью про технику создания графики в то время
А не возникнет ли исключение IndexOutOfBoundsException в случае, когда files.Length == 0? Конкретно в инструкции: files[0]. Или в коде выше этого не допускается? Если я прав, то, возможно, стоит добавить в PVS-Studio соответствующую эвристику.
В последнем случае можно функции getLastFileOrNone и isNotASpecialFile вынести из класса в библиотечный helper и протестировать отдельно.
Есть ощущение, что человек, писавший код Elasticsearch (ну или конкретно данные куски приведенного кода), пришел из мира С/С++ и не совсем хорошо знал Java. Что навело на эти мысли?
Шаблоны из мира С:
1. Частое использование static
2. Предпочтение массивов использованию классов/коллекций; вообще слишком частое использование массивов.
3. Путаница == и equals.
4. Паттерн преобразования одного примитивного типа к другому (int)x.
5. Работа с текстом, не как с объектом, а как с массивом. for (; i < s.length() && (s.charAt(i) != ' ' || s.charAt(i) != '\t'); i++), или line.getBytes(StandardCharsets.UTF_8);
Вообще чувствуется дух C/C++. Процедурный подход превалирует над объектным.
Довод в пользу плохого знания Java:
1. сравнение line.startsWith("--" + boundary) c false не требуется, т.к. startsWith возвращает логическое значение.
2. игнорирование библиотечных функций Java. Например в методе withRestUriAndMethod можно было бы воспользоваться классом URL/URI, чтобы извлечь фрагмент. На автор кода решил, похоже, изобрести свой велосипед.
3. Инструкцию for (int i = 0; i < values.length; i++) можно было заменить на более понятный итератор for (Object value: values), избавившись от необходимости каждый раз писать values[i] instanceof. Вообще весь блок цикла в setSortValues, стоило вынести в отдельную функцию isPrimitiveClass и написать на неё тест.
4. Если уж используешь Objects.equals, то левая часть бессмысленна в условиях вида (frequency == null || Objects.equals(frequency, datafeed.getFrequency())
Ну и по мелочи:
1. Несколько смущает конструкция context.instanceClazz. Тоже самое: printStackTrace.
2. Похоже, что разработчик не пишет юнит-тесты, а если и пишет, то не запускает. Иначе ошибки в char64, findNextWhiteSpace всплыли бы сразу.
3. От методов findNextWhiteSpace/skipWhiteSpace стоит отказаться в пользу специализированного итератора. На такой итератор легче написать тест (чем на закрытый член private static). Плюс избавляемся от паттерна «GodObject».
4. Вообще наличие static-функций не в утилитарном библиотечном Java классе — явный сигнал к рефакторингу класса.
1) делать расчеты для всех нейронов одновременно (используя суперскалярность процессора)
2) делать расчеты пачками нейронов, используя цикл, в случае, если у вас дефицит «вычислителей»
Я думал, что это очевидно: когда вам необходимо выполнить K независимых операций, максимального ускорения вы достигнете, взяв K «вычислителей» (процессоров, блоков АЛУ, кластеров — не важно). Если вы не можете взять K вычислителей, а можете только M < K, то вы будете вынуждены выполнить расчеты в несколько (K/M + 1) подходов (читай — циклов).
Посыпаю голову пеплом: я сделал оценку 10^12, полагая, что у нас будет полносвязная НС шириной 10^4 нейронов и 10^4 слоев. А это не так. Но не отменяет того факта, что приблизительный порядок операций, которые нужно затратить на вычисление одного слоя: ~(10^4)^2 = 10^8. Умножьте это ещё на количество слоев.
Но разве суперскалярные процессоры этим не занимаются, когда одной инструкцией позволяют найти произведение сразу группы чисел?
Вот здесь, прошу прощения, реально я Вас не понял. Что поменяется, например, для задачи «выполнить K независимых операций»? Можете подробнее?
Соглашусь. В противном случае придется передавать входные данные между процессорами от слоя к слою. Я, думаю, Вы про это.
Какие?
Основная мысль, которую я хотел бы донести до читателя статьи и всех верующих в силу глубоких нейронных сетей в деле построения сильного ИИ состоит в том, что ассимптотическая сложность расчетов нейронных сетей растет, минимум, квадратично и сильно обгоняет возможности роста современных процессоров и их ансамблей в виде кластеров. На существующих компьютерах построить сильный ИИ (взяв НС побольше, да кластер помощнее), боюсь, не удастся. Нужны принципиально иные технологии.
Боюсь, я не правильно выразился. Речь шла не об ускорении одного только перемножения.
Речь шла о том, что мы можем параллельно перемножать матрицы (вычисляем коэффициенты в каждом слое нейронной сети), кроме этого для каждой матрицы каждый элемент тоже можем рассчитывать параллельно (каждый нейрон все сети рассчитывается независимо), и даже каждое попарное произведение (вес нейрона * вес связи), требуемое для расчета этого самого элемента матрицы, мы тоже, чтобы ускориться, можем вычислять параллельно.
Но даже такая супер-параллельность нас не спасет от необходимости выполнять часть последовательных операций. А они возникают здесь:
1) передача данных от одного слоя к другому
2) передача от блоков умножения к блокам сложения (при расчете итоговой суммы связей каждого нейрона)