Моё описание очень упрощено, рекомендую всё-таки почитать документы от авторов Siacoin. Если подсказка содержит значение функции, которую дёшево считать в одну, но дорого считать в обратную сторону, то хранителю будет выгоднее по ресурсам честно хранить данные, чем обращать функцию на каждую проверку. Например, пусть в блокчейне записаны sha1 от миллиона килобайтных сообщений M[i], а я (проверяющий) прошу вас (хранителя) выдать мне M[123]. Вам будет легче честно сохранить все M[i], чем вытаскивать из блокчейна sha1(M[123]) и обращать хеш.
Защититься от недобросовестного проверяющего можно, например, так — брать с проверяющего плату за вступление в клуб, а свою долю штрафа позволить потратить только в случае предъявления подписанного доказательства неверного ответа. Сложнее будет ситуация в случае неответа хранителя на запрос проверяющего, но такая ситуация разрешима правом проверяющего (за некоторую плату) собрать комиссию из других проверяющих и попросить их отправить запрос с тем же значением параметра.
Как раз именно эти проблемы и пытаются решить упомянутые выше системы.
Разработчики могут выполнить некое начальное распределение средств, а создатели контента будут сначала зарабатывать на хостинге чего-нибудь чужого (например, бекапов), чтобы потом на заработанные средства захостить своё.
От накруток защищаются примерно следующим образом: в контракте на хранение данных участвует три стороны — заливающий, хранящий и проверяющий. Заливающий платит хранящему и передаёт данные, записывая результат применения g(f(data)) в блокчейн. Хранящий убеждается в соответствии передаваемых ему данных этому значению. Проверяющий периодически присылает хранящему задачи, параметризированные заранее непредсказуемым образом, а хранящий обязан за разумное время отвечать правильным решением. Задача требует вычислить функцию f от некоторого подмножества хранимых данных. Проверяющий вычисляет g, и в случае неответа/несовпадения получает право оштрафовать хранящего в пользу (в основном) заливающего и чуть-чуть в свою. Сговор участников затруднём тем, что выбор того, кто кого проверяет, делается заранее непредсказуемым образом, а некоторая малая часть монет, на которые заключается контракт, сгорает (или замораживается, или возвращается авторам системы).
Даже если программисты научатся писать код без ошибок, всё равно будет экономически невыгодно держать ОС в необновляемом ПЗУ — конкуренты выпустят машину чуть позже, но с более расширенной по возможностям версией ОС в ПЗУ, и тогда вся партия машин станет неконкуретноспособной.
Когда браузер использует https, то пара публичный/секретный ключ может находится либо только на сервере (обычно именно так и происходит), либо и на клиенте тоже — тогда не только клиент может проверить подлинность сервера, но и сервер может проверить подлинность клиента (в этом случае у каждого клиента есть своя пара ключей и свой сертификат).
Эти пары ключей используются только в самом начале установки соединения. Затем стороны договариваются об используемом шифронаборе и передают друг другу случайные числа, позволяющие им сформировать сеансовый (симметричный) ключ, которым и будут зашифрованы «полезные» данные.
Как правило не имеет смысла реализовывать сервер таким образом, чтобы ключи и сертификаты генерировались на сервере для каждого пользователя. Ведь для шифрования пользовательских данных всё равно используется сеансовый ключ, который случайный. Системы перехвата/проксирования трафика могут хотеть генерировать сертификаты «на лету» — ведь они не знают заранее, куда захочет пойти пользователь.
Протокол шифрования может быть устроен таким образом, что имея полную запись всего соединения и секреные ключи будет невозможно восстановить сеансовый ключ (если, конечно, одна из сторон не записала его или те случайные числа, с помощью которых он был сгенерирован). Поэтому для расшифровки трафика при MiTM приходится не только слушать обе стороны, но и активно вмешиваться — MiTM для клиента выглядит, как сервер, для сервера, как клиент, и занимается перешифровкой трафика. В этом случае перехватчик знает все случайные числа и сеансовый ключ, так как сам активно участвовал в их генерации.
Когда пользователь открывает в своём браузере facebook.com, то сервер facebook.com при создании защищённого канала между собой и пользователем предоставляет публичный ключ и сертификат, подписанный удостоверяющим центром, которому доверяет браузер пользователя. Если третья сторона (например, провайдер или работодатель) вмешается в соединение, заставив свой (перехватывающий) сервер отвечать на запросы вместо facebook.com, то возможны следующие сценарии:
1) перехватывающий сервер содержит копию сертификата, но его публичный ключ не совпадает с ключом facebook.com — браузер обнаружит несоответствие сертификата и ключа, заблокирует доступ;
2) перехватывающий сервер содержит копию и сертификата, и публичного ключа с facebook.com — браузер ничего не заметит, но и перехватчик не сможет расшифровывать трафик, ведь у него нет секретного ключа;
3) перехватывающий сервер содержит свою пару (публичный+секретный) ключей и свой (самоподписанный) сертификат — браузер не будет доверять удостоверяющему центру, выпустившему сертификат, поэтому доступ будет заблокирован.
Чтобы сценарий №3 устроил браузер, он должен доверять УЦ. Если пользователь скачает сертификат самого УЦ, и вручную добавит его в ОС и/или в браузер, то соединение будет установлено, а перехватчик сможет просматривать и даже модифицировать проходящий через него трафик. Такой приём используется системами предотвращения утечек информации, антивирусами, некоторыми инструментами для аудита безопасности.
Раз есть некая сущность, которая делает MiTM, значит происходит обработка информации какой-то программой. Допустим, пользователь установил себе сертификат, установил соединение с удалённым севером и отправил туда запрос, на который удалённый сервер ответил.
Пусть в процессе обработки ответа от удалённого сервера, программная реализация MiTM начала вести себя не так, как задумали её авторы — например, банально упала (или, хуже того, начала исполнять код, копирующий весь транзитный трафик куда-то).
Будет ли такое поведение нарушать закон, если ситуация не была результатом злого умысла и/или сговора между сторонами? Кто будет виноват с точки зрения закона — разработчик MiTM, оператор клиента, оператор сервера? Как изменится ситуация, если будет доказано, что ситуация возникает только из-за недостаточно совершенной «прозрачности» MiTM?
Мне кажется, что ситуации можно было бы считать равными в случае, если бы Яндекс заставлял разработчика сделать выбор — либо разработчик полагается только на сервисы Яндекса (а сервисы конкуретнов использовать нельзя), либо все продукты разработчика лишаются доступа.
Всё-таки текущая ситуация это совсем не ровно то же самое. У разработчика по-прежнему есть возможность купить рекламу. Например, у меня Яндекс по запросу [самый быстрый браузер] показывает справа большой блок с Opera, а в результатах я вижу:
(реклама) Загрузите новый браузер Opera / opera.com
1. Лучшие браузеры 2019 года. Рейтинг и обзор самых…
2. Какой браузер самый быстрый?
3. Самый быстрый браузер – результаты тестирования.
(Яндекс.Новости) Самый быстрый браузер — новости
4. 1. Яндекс – самый лучший и быстрый браузер для…
5. ТОП луших браузеров 2019 года, сравнение, плюсы…
Продукт Яндекса далеко не на первом месте. Аналогично с [аренда виртуального сервера] (bootdet) и [сервис облачного хранения данных] (idealsvdr), [слушать музыку бесплатно] (megapesni), [создать электронную почту] (mail.ru), [электронный кошелек] (qiwi), [виртуальный кошелек] (banki.ru) — специально искал по запросам, которые релевантны тем сервисам Яндекса, которые я сам использую, и каждый раз получал в качестве самой верхней (возможно рекламной) ссылки сервис конкурента.
В законе упоминаются понятия «организатор сервиса обмена мгновенными сообщениями» и «пользователь сервиса обмена мгновенными сообщенями».
Я нашёл следующие фрагменты в 149-ФЗ.
Организатором распространения информации в сети «Интернет» является лицо, осуществляющее деятельность по обеспечению функционирования информационных систем и (или) программ для электронных вычислительных машин, которые предназначены и (или) используются для приема, передачи, доставки и (или) обработки электронных сообщений пользователей сети «Интернет».
Организатор распространения информации в сети «Интернет» в случае осуществления деятельности по обеспечению функционирования информационных систем и (или) программ для электронных вычислительных машин, которые предназначены и (или) используются для обмена электронными сообщениями исключительно между пользователями этих информационных систем и (или) программ для электронных вычислительных машин, при котором отправитель электронного сообщения определяет получателя или получателей электронного сообщения, не предусматриваются размещение пользователями сети «Интернет» общедоступной информации в сети «Интернет» и передача электронных сообщений неопределенному кругу лиц (далее — организатор сервиса обмена мгновенными сообщениями)…
… пользователей сети «Интернет», передачу электронных сообщений которых осуществляет организатор сервиса обмена мгновенными сообщениями (далее — пользователи сервиса обмена мгновенными сообщениями)
Когда я использую какой-нибудь мессенджер, чтобы написать сообщение другу, то в передаче сообщения участвуют не только машины, находящиеся под управлением компании-разработчика мессенджера, но и машины операторов связи, а также моя машина и моего друга, на поведение которых повлиять значительно сложнее.
Возникают очевидные вопросы:
1) Если я прямо сейчас придумаю свой централизованный мессенджер и буду поддерживать его сервера, то означает ли это то, что несмотря на низкую популярность моего решения, мобильные операторы всё равно будут обязаны налаживать со мной обмен для получения телефонных номеров моих абонентов и хранить у себя всю эту информацию?
2) Что будет, если я и мой друг будем использовать в качестве мессенджера систему, которая не предназначена для этого?
3) А если я не буду определять, кому доставить сообщение понятным системе образом, а вместо этого буду броадкастить сообщение, а фильтр на стороне моего друга уже будет принимать решение, что сообщение предназначается для него?
И чуть менее очевидные вопросы:
4) Что такое «сеть Интернет»? Действует ли закон на сети, из которых нельзя попасть в интернет? А если фрагменты этих сетей используют интернет в качестве траспорта?
5) Что если мессенджер является лишь спецификацией, описывающей, как именно взаимодействовать пользователям, и никакой инфраструктуры, никаких программ для этого не предоставляет, а перекладывает эту часть работы на самих пользователей?
6) Как быть в случае, когда каждый пользователь сам написал для себя мессенджер, зарегистрировал его везде, где надо, слил единственный номер телефона мобильному оператору, а затем использует этот мессенджер для общения с друзьями, которые поступили так же?
Intel vPro включает в себя технологию Intel AMT, которой нужна видеокарточка от Intel для захвата картинки. С TSX-NI и TXT непонятно, ведь эти фичи есть у некоторых серверных Xeon без видеоядра.
Защититься от недобросовестного проверяющего можно, например, так — брать с проверяющего плату за вступление в клуб, а свою долю штрафа позволить потратить только в случае предъявления подписанного доказательства неверного ответа. Сложнее будет ситуация в случае неответа хранителя на запрос проверяющего, но такая ситуация разрешима правом проверяющего (за некоторую плату) собрать комиссию из других проверяющих и попросить их отправить запрос с тем же значением параметра.
Разработчики могут выполнить некое начальное распределение средств, а создатели контента будут сначала зарабатывать на хостинге чего-нибудь чужого (например, бекапов), чтобы потом на заработанные средства захостить своё.
От накруток защищаются примерно следующим образом: в контракте на хранение данных участвует три стороны — заливающий, хранящий и проверяющий. Заливающий платит хранящему и передаёт данные, записывая результат применения g(f(data)) в блокчейн. Хранящий убеждается в соответствии передаваемых ему данных этому значению. Проверяющий периодически присылает хранящему задачи, параметризированные заранее непредсказуемым образом, а хранящий обязан за разумное время отвечать правильным решением. Задача требует вычислить функцию f от некоторого подмножества хранимых данных. Проверяющий вычисляет g, и в случае неответа/несовпадения получает право оштрафовать хранящего в пользу (в основном) заливающего и чуть-чуть в свою. Сговор участников затруднём тем, что выбор того, кто кого проверяет, делается заранее непредсказуемым образом, а некоторая малая часть монет, на которые заключается контракт, сгорает (или замораживается, или возвращается авторам системы).
Интересно, а кто и сколько сделал этих машин из 55?
Что помешает квалифицированному сотруднику найти нового работодателя?
> Поступиться частью прибыли взамен на возможность собственного существования, путём повышения зарплат недовольных.
Тогда недовольными станут другие, у которых зарплату не повысили.
Когда браузер использует https, то пара публичный/секретный ключ может находится либо только на сервере (обычно именно так и происходит), либо и на клиенте тоже — тогда не только клиент может проверить подлинность сервера, но и сервер может проверить подлинность клиента (в этом случае у каждого клиента есть своя пара ключей и свой сертификат).
Эти пары ключей используются только в самом начале установки соединения. Затем стороны договариваются об используемом шифронаборе и передают друг другу случайные числа, позволяющие им сформировать сеансовый (симметричный) ключ, которым и будут зашифрованы «полезные» данные.
Как правило не имеет смысла реализовывать сервер таким образом, чтобы ключи и сертификаты генерировались на сервере для каждого пользователя. Ведь для шифрования пользовательских данных всё равно используется сеансовый ключ, который случайный. Системы перехвата/проксирования трафика могут хотеть генерировать сертификаты «на лету» — ведь они не знают заранее, куда захочет пойти пользователь.
Протокол шифрования может быть устроен таким образом, что имея полную запись всего соединения и секреные ключи будет невозможно восстановить сеансовый ключ (если, конечно, одна из сторон не записала его или те случайные числа, с помощью которых он был сгенерирован). Поэтому для расшифровки трафика при MiTM приходится не только слушать обе стороны, но и активно вмешиваться — MiTM для клиента выглядит, как сервер, для сервера, как клиент, и занимается перешифровкой трафика. В этом случае перехватчик знает все случайные числа и сеансовый ключ, так как сам активно участвовал в их генерации.
1) перехватывающий сервер содержит копию сертификата, но его публичный ключ не совпадает с ключом facebook.com — браузер обнаружит несоответствие сертификата и ключа, заблокирует доступ;
2) перехватывающий сервер содержит копию и сертификата, и публичного ключа с facebook.com — браузер ничего не заметит, но и перехватчик не сможет расшифровывать трафик, ведь у него нет секретного ключа;
3) перехватывающий сервер содержит свою пару (публичный+секретный) ключей и свой (самоподписанный) сертификат — браузер не будет доверять удостоверяющему центру, выпустившему сертификат, поэтому доступ будет заблокирован.
Чтобы сценарий №3 устроил браузер, он должен доверять УЦ. Если пользователь скачает сертификат самого УЦ, и вручную добавит его в ОС и/или в браузер, то соединение будет установлено, а перехватчик сможет просматривать и даже модифицировать проходящий через него трафик. Такой приём используется системами предотвращения утечек информации, антивирусами, некоторыми инструментами для аудита безопасности.
Пусть в процессе обработки ответа от удалённого сервера, программная реализация MiTM начала вести себя не так, как задумали её авторы — например, банально упала (или, хуже того, начала исполнять код, копирующий весь транзитный трафик куда-то).
Будет ли такое поведение нарушать закон, если ситуация не была результатом злого умысла и/или сговора между сторонами? Кто будет виноват с точки зрения закона — разработчик MiTM, оператор клиента, оператор сервера? Как изменится ситуация, если будет доказано, что ситуация возникает только из-за недостаточно совершенной «прозрачности» MiTM?
Всё-таки текущая ситуация это совсем не ровно то же самое. У разработчика по-прежнему есть возможность купить рекламу. Например, у меня Яндекс по запросу [самый быстрый браузер] показывает справа большой блок с Opera, а в результатах я вижу:
(реклама) Загрузите новый браузер Opera / opera.com
1. Лучшие браузеры 2019 года. Рейтинг и обзор самых…
2. Какой браузер самый быстрый?
3. Самый быстрый браузер – результаты тестирования.
(Яндекс.Новости) Самый быстрый браузер — новости
4. 1. Яндекс – самый лучший и быстрый браузер для…
5. ТОП луших браузеров 2019 года, сравнение, плюсы…
Продукт Яндекса далеко не на первом месте. Аналогично с [аренда виртуального сервера] (bootdet) и [сервис облачного хранения данных] (idealsvdr), [слушать музыку бесплатно] (megapesni), [создать электронную почту] (mail.ru), [электронный кошелек] (qiwi), [виртуальный кошелек] (banki.ru) — специально искал по запросам, которые релевантны тем сервисам Яндекса, которые я сам использую, и каждый раз получал в качестве самой верхней (возможно рекламной) ссылки сервис конкурента.
В законе упоминаются понятия «организатор сервиса обмена мгновенными сообщениями» и «пользователь сервиса обмена мгновенными сообщенями».
Когда я использую какой-нибудь мессенджер, чтобы написать сообщение другу, то в передаче сообщения участвуют не только машины, находящиеся под управлением компании-разработчика мессенджера, но и машины операторов связи, а также моя машина и моего друга, на поведение которых повлиять значительно сложнее.
Возникают очевидные вопросы:
1) Если я прямо сейчас придумаю свой централизованный мессенджер и буду поддерживать его сервера, то означает ли это то, что несмотря на низкую популярность моего решения, мобильные операторы всё равно будут обязаны налаживать со мной обмен для получения телефонных номеров моих абонентов и хранить у себя всю эту информацию?
2) Что будет, если я и мой друг будем использовать в качестве мессенджера систему, которая не предназначена для этого?
3) А если я не буду определять, кому доставить сообщение понятным системе образом, а вместо этого буду броадкастить сообщение, а фильтр на стороне моего друга уже будет принимать решение, что сообщение предназначается для него?
И чуть менее очевидные вопросы:
4) Что такое «сеть Интернет»? Действует ли закон на сети, из которых нельзя попасть в интернет? А если фрагменты этих сетей используют интернет в качестве траспорта?
5) Что если мессенджер является лишь спецификацией, описывающей, как именно взаимодействовать пользователям, и никакой инфраструктуры, никаких программ для этого не предоставляет, а перекладывает эту часть работы на самих пользователей?
6) Как быть в случае, когда каждый пользователь сам написал для себя мессенджер, зарегистрировал его везде, где надо, слил единственный номер телефона мобильному оператору, а затем использует этот мессенджер для общения с друзьями, которые поступили так же?
Программа? Протокол?