Интересно выглядит. Даже если сам фрэймворк не взлетит, то концепты, выпиливающие как можно больше сущностей (не в ущерб функциональности) из нынешнего зоопарка, должны развиваться.
То, что в любой момент, для определенного айпи или иной метки, которыми браузер нашпигован по самое нехочу, сервер может выдавать самый разный код ;)
Вот решили вы проверить исходники, отследили запрос, проверили на гитхабе — все нормально, начали применять в своих делах.
А вот уже вас решили «проверить». На сервере приняли запрос на js-файл, сняли с него метрики, чтоб подтвердить что это именно вы, (есть куча разных способов это сделать), и отправили вам «правильный» js)))
К чему это? Если прятать некритичную инфу, а так — фото из окон соседнего дома, то сервис подойдет. Для чего-то более менее серьезного — весьма так себе способ.
Функции шифрования работают только когда они загруженны оффлайн, проверенны хэшсуммами, скомпилированны и загружаются только со стороны клиента.
Все таки поправка. К каналу связи между машиной и нодой. Когда рут под контролем, считается что ничего не спасет. Но даже тут, замечу, с помощью криптотехнологии и бч есть очень стабильное решение на оснвове дополнительного железа (цена вопроса 50$). Напишу про этот кейс в отдельной статье.
Но даже все равно остается прошивка в код браузера некоторых нод и тогда хакеру придется модифицировать память браузера только это уже адрессная атака и не все просто с ней.
И поэтому смысла менять шило на мыло нет никакого.
Ну всевозможные аргументы я изложил, дальше каждый сам решает)
но они должны быть валидны и для сегодняшнего блокчейна. А это значит, форкните его вчерашним днём, добавьте в форк новые поддельные данные и скормите форк браузеру на атакуемой машине. Он ничего не догадается.
Merkle tree. Нет никакой проблемы скачать его на каждое устройство. Там размеры — мегабайты в год. Скачал и опрашиваешь преиодически n количество случайных нод на предмет целостности по базы по хэшу.
Это, конечно, потребует больше телодвижений, нежели подсаживание корневого сертификата, но в целом задачи одного порядка сложности.
Да гораздо больше мягко говоря. Опроси клиент хэш дерева с количества нод больше 1-3-10-50, то вероятность атаки снижается значительно.
Упс, извиняюсь. Я слегка не туда зарулил. Перефразирую. Контрольная сумма позволяет проверить целостность данных, но они должны быть в наличии у вас. А если нет? Если есть только кусок и надо быстро? Тогда поможет что-то типа дерева меркла или цепочки хэшей. Тут сеть имеет значение как и количество независимых нод.
А в чём отличие от разворачивания самому себе центра сертификации?
В том, что данные связанны консенсусом и поэтому для каждого пользователя они будут одинаковы, если он скачает себе бч. Скачав бч, посчитав его хэш и запросив проверку хэша на множестве других нод, вы получите довольно дешевую и приемлемую валидацию данных. поддержка собственного центра требует гораздо более сложных процессов.
Браузер не поверит рутовому сертификату, потому, что я то ли боб, то ли ева?
В браузер можно вшить по дефолту некоторые ключи, которые хранятся в бч и тогда браузер никто обмануть не сможет. Дальше уже дело техники.
Ну так в блокчейне тоже не ясно, кто ножу поднял.
Да это и не важно. В блокчеине ясно точно, что данные внесены в него строго с соблюдением консенсуса. Перепроверка осуществляется по хэшу. Чем больше нод предоставит аналогичный хэш, те «валиднее» данные.
Если в общем изложить, схема такая.
Ключ запрашивается у одной или более нод. Если есть причины не доверять какой-то ноде (нодам), скачивается весь бч и там уже точно данные будут валидны.
Возможно но не обязательно. Уже есть реализации консенсусной бд без применения бч.
неизменность и доверие строится тупо на голосовании большинства независимых участников
Неизменность и доверие строится на механизме консенсуса. К большинству это имеет опосредованное отношение, хотя зависит от механизма консенсуса. Это же основы бч)
А для валидации данных достаточно иметь копию дерева меркла бч на каждом устройстве. Весь бч копировать вовсе необязательно.
На мой взгляд конкурентное преимущество бч только одно — обеспечение среды в которой решен вопрос доверия к данным из базы. В остальном он дороже, медленнее, сложнее, и во всех смыслах хуже чем обычная бд.
Прочитал. В целом согласен.
Только я не пойму, зачем так жестко противопоставлять блокчеин как дб блокчеину как действующее лицо?
В случае хранения и предоставления доступа к публичным ключам мы также имеем и конфликт и интересов и потенциальную нечестность и риски централизации процесса. И дублирование данных видится вполне решением.
В вашем случае (навскидку оцениваю) можно обойтись одной лишь копией блокчеина. Ну так это потому, что всем участникам вашего бч нет причин вам не доверять. Вы заинтересованы чтобы правила бч соблюдались.
В случае же публичного кейчена владелец ноды сам является источником риска и конфликт интересов в иной плоскости.
А так да, мне нравится ваша точка зрения на бч. Но как дополняющая имеющиеся, но не исключающая.
Блокчеин — это распределенная бд в принципе. Я даже и не знаю, чем это еще может быть :)
А вот вопросам безопасности распределенность как раз не помешала бы.
Большинство — да (и для него такая возможность учтена), но это не значит, что всех асболютно надо под большинство усреднять.
Или значит? Мне видится настораживающим такой подход.
2. Решение на блокчейне либо имеет неприемлемый побочный эффект, либо не решает проблему.
Решает проблему рисков централизованного хранения всех сертификатов. Рисков там не мало мягко говоря. Остальное там как минимум не хуже чем сейчас.
«пару уровней сверху наворотим. „
Уровни не сверху а на стороне сервиса. Бч просто дает запись с публичным ключом и поле с меняющимися метаданными. Больше на нем ничего городить не надо.
Мы делаем публичный кейчэин на основе блокчеина. А уж как его применять — зависит от сервиса. Можно как обычный ssl, можно как ДХ с KYC, можно ДХ с предварительным обменом ключей. Главное что мы имеем возможность обменяться через блокчеин с кем угодно верифицированным пабликом, или производным пабликом от публичного как в биткоине. Это дает гибкую, но связную систему с широкими возможностями.
Есть и такой вариант, что для особых случаев возможно установить сессию через транзакцию блокчеина — там куча возможностей открывается для анонимности, ограниченной анонимности и ее отсутствия.
Вот решили вы проверить исходники, отследили запрос, проверили на гитхабе — все нормально, начали применять в своих делах.
А вот уже вас решили «проверить». На сервере приняли запрос на js-файл, сняли с него метрики, чтоб подтвердить что это именно вы, (есть куча разных способов это сделать), и отправили вам «правильный» js)))
К чему это? Если прятать некритичную инфу, а так — фото из окон соседнего дома, то сервис подойдет. Для чего-то более менее серьезного — весьма так себе способ.
Функции шифрования работают только когда они загруженны оффлайн, проверенны хэшсуммами, скомпилированны и загружаются только со стороны клиента.
Все таки поправка. К каналу связи между машиной и нодой. Когда рут под контролем, считается что ничего не спасет. Но даже тут, замечу, с помощью криптотехнологии и бч есть очень стабильное решение на оснвове дополнительного железа (цена вопроса 50$). Напишу про этот кейс в отдельной статье.
Но даже все равно остается прошивка в код браузера некоторых нод и тогда хакеру придется модифицировать память браузера только это уже адрессная атака и не все просто с ней.
Ну всевозможные аргументы я изложил, дальше каждый сам решает)
Merkle tree. Нет никакой проблемы скачать его на каждое устройство. Там размеры — мегабайты в год. Скачал и опрашиваешь преиодически n количество случайных нод на предмет целостности по базы по хэшу.
Да гораздо больше мягко говоря. Опроси клиент хэш дерева с количества нод больше 1-3-10-50, то вероятность атаки снижается значительно.
В том, что данные связанны консенсусом и поэтому для каждого пользователя они будут одинаковы, если он скачает себе бч. Скачав бч, посчитав его хэш и запросив проверку хэша на множестве других нод, вы получите довольно дешевую и приемлемую валидацию данных. поддержка собственного центра требует гораздо более сложных процессов.
В браузер можно вшить по дефолту некоторые ключи, которые хранятся в бч и тогда браузер никто обмануть не сможет. Дальше уже дело техники.
Да это и не важно. В блокчеине ясно точно, что данные внесены в него строго с соблюдением консенсуса. Перепроверка осуществляется по хэшу. Чем больше нод предоставит аналогичный хэш, те «валиднее» данные.
Если в общем изложить, схема такая.
Ключ запрашивается у одной или более нод. Если есть причины не доверять какой-то ноде (нодам), скачивается весь бч и там уже точно данные будут валидны.
Возможно но не обязательно. Уже есть реализации консенсусной бд без применения бч.
Неизменность и доверие строится на механизме консенсуса. К большинству это имеет опосредованное отношение, хотя зависит от механизма консенсуса. Это же основы бч)
А для валидации данных достаточно иметь копию дерева меркла бч на каждом устройстве. Весь бч копировать вовсе необязательно.
Но с поправкой на вынужденную и дефолтовую прозрачность процесса и возможностью альтернативы для каждого из этого большинства.
Грубо говоря: «мы тут все друг другу доверяем, но ты, если не доверяешь — ставь ноду и давай в консенсус.» И это улучшит в итоге общий уровень доверия
Только я не пойму, зачем так жестко противопоставлять блокчеин как дб блокчеину как действующее лицо?
В случае хранения и предоставления доступа к публичным ключам мы также имеем и конфликт и интересов и потенциальную нечестность и риски централизации процесса. И дублирование данных видится вполне решением.
В вашем случае (навскидку оцениваю) можно обойтись одной лишь копией блокчеина. Ну так это потому, что всем участникам вашего бч нет причин вам не доверять. Вы заинтересованы чтобы правила бч соблюдались.
В случае же публичного кейчена владелец ноды сам является источником риска и конфликт интересов в иной плоскости.
А так да, мне нравится ваша точка зрения на бч. Но как дополняющая имеющиеся, но не исключающая.
А вот вопросам безопасности распределенность как раз не помешала бы.
Или значит? Мне видится настораживающим такой подход.
Решает проблему рисков централизованного хранения всех сертификатов. Рисков там не мало мягко говоря. Остальное там как минимум не хуже чем сейчас.
Уровни не сверху а на стороне сервиса. Бч просто дает запись с публичным ключом и поле с меняющимися метаданными. Больше на нем ничего городить не надо.
Есть и такой вариант, что для особых случаев возможно установить сессию через транзакцию блокчеина — там куча возможностей открывается для анонимности, ограниченной анонимности и ее отсутствия.