Comments 19
Если ФСБ требует от эппл изготовить вредоносную прошивку для айфона, что мешает местной спецслужбе потребовать у компании подменить js на сайте, где пользователь вводит пароль?
Идея "шифруем в бразуере" хороша до тех пор, пока у злоумышленника не появляется временного контроля над веб-сервером. После этого понять, кому ты там куда пароль вводишь уже нельзя.
Идея "шифруем в бразуере" хороша до тех пор, пока у злоумышленника не появляется временного контроля над веб-сервером. После этого понять, кому ты там куда пароль вводишь уже нельзя.
В Швейцарии одно из самых строгих в Европе законодательств о перс. данных и там это невозможно сделать тайно под соусом "мы запрещаем вам об этом говорить".
Так что, пользователи будут, минимум, предупреждены.
Вдобавок, NoScript. если не ошибаюсь позволяет подменять "на лету" обращение к удалённым скриптам на обращения к их локальным копиям. Так что, можно хранить у себя гарантированно "незабэкдоренный" скрипт.
Так что, пользователи будут, минимум, предупреждены.
Вдобавок, NoScript. если не ошибаюсь позволяет подменять "на лету" обращение к удалённым скриптам на обращения к их локальным копиям. Так что, можно хранить у себя гарантированно "незабэкдоренный" скрипт.
Во-первых, сейчас оно "самое строгое", а завтра начинают бороться с суицидальными экстремистскими нарушителями авторских прав на наркотическую детскую порнографию в интересах национальной безопасности — и всё, судебный ордер готов.
Кроме того, сертификатик для ssl выкатить левый и mitm сделать — как нефиг делать. noscript ничем не поможет, потому что формочку логина могут и статикой нарисовать.
Я к чему: "пароль в браузере" не является "end to end шифрованием" в условиях умеренной паранойи. Десктопный клиент — является, потому что его код просто так не меняется.
Кроме того, сертификатик для ssl выкатить левый и mitm сделать — как нефиг делать. noscript ничем не поможет, потому что формочку логина могут и статикой нарисовать.
Я к чему: "пароль в браузере" не является "end to end шифрованием" в условиях умеренной паранойи. Десктопный клиент — является, потому что его код просто так не меняется.
В браузере тоже можно, но нужно, чтобы для части, которая работает с незашифрованными данными можно было
В таком случае, это будет полноценное приложение, а расширение, которое я описываю будет своеобразным пакетным менеджером.
А ещё аудит можно сделать публичным через crowdsourcing, но это совсем другая история.
Оффлайн-приложения в Хроме работают похожим образом, кстати.
- закрепить версию (отключить автообновление, то есть, чтобы она хранилась в кеше/local storage), и контроль за этой версией осуществляло бы отдельное дополнение в браузере.
- провести полный аудит кода (данные можно доверять только опенсорсу, а вы как думали?)
В таком случае, это будет полноценное приложение, а расширение, которое я описываю будет своеобразным пакетным менеджером.
А ещё аудит можно сделать публичным через crowdsourcing, но это совсем другая история.
Оффлайн-приложения в Хроме работают похожим образом, кстати.
Надо хранить четные зашифрованные байты в одной стране, а нечетные — в другой. Получить санкциии сразу двух судов сложнее.
Требовать? Ничего не мешает тербовать.
Только не ФСБ, а ФБР.
Очень не хватает десктопного клиента. Мобильные они недавно выкатили в паблик.
Чем это лучше, чем стандартный POP3/IMAP и _произвольный_ (а не предопределённый, предоставляемый сервисом) почтовый клиент с модулем PGP шифрования? Почтовый сервис — это _протокол доступа_, а не набор клиентских приложений. У меня единый настроенный на несколько аккаунтов почтовый клиент, а тут, получается, мне надо ставить ещё один, у которого, как выясняется, ещё и проблемы с кроссплатформенностью…
> Есть возможность отправить защищенное сообщение и пользователю стороннего сервиса… При шифровании используется алгоритм AES-256 с паролем, который должен быть известен как адресату, так и отправителю.
Очень странный подход, почему не использовать классическое шифрование с асимметричным ключом?
> Есть возможность отправить защищенное сообщение и пользователю стороннего сервиса… При шифровании используется алгоритм AES-256 с паролем, который должен быть известен как адресату, так и отправителю.
Очень странный подход, почему не использовать классическое шифрование с асимметричным ключом?
Жаль конечно, что поиска по телу письма нет. У меня обычно переписка не очень богатая и поиска по теме вполне хватает обычно, а вот людям для которых почта — основной инструмент может быть тяжко.
А кто-нибудь уже попробовал как оно работает? Кто-нибудь получал зашифрованные сообщения от второго юзера ПротонМэила?
Они пишут, что шифрование конец-в-конец осуществляется всегда, но кроме этого можно поставить индивидуальный пароль на сообщение.
А как оно тогда работает без индивидуального пароля на сообщение? У меня пароли к ящику одни, у другого юзера совсем другие. Как его сообщение ко мне дойдет и каким паролем оно будет зашифровано?
Они пишут, что шифрование конец-в-конец осуществляется всегда, но кроме этого можно поставить индивидуальный пароль на сообщение.
А как оно тогда работает без индивидуального пароля на сообщение? У меня пароли к ящику одни, у другого юзера совсем другие. Как его сообщение ко мне дойдет и каким паролем оно будет зашифровано?
А после хабраеффекта им, снова придётся ввести инвайты)
Какой в этом смысл для простого обывателя, когда все письма если не с мейлрушечки к нему приходят, то по крайней мере с гмыла. На той стороне и так всё в свободном виде.
вся информация шифруется еще на стороне клиента, а все серверы сервиса располагаются на территории Швейцарии. В этой стране очень сложно, если вообще возможно, получить доступ к чьей-либо частной информации
Однако, если информация шифруется еще на стороне клиента, то какая разница где располагаются сервера? Странно это.
И, вообще, Thunderbird c Enigmail работает с любым почтовым сервером, какой смысл в этом ProtonMail ?
Sign up to leave a comment.
Защищенный анонимный сервис ProtonMail от разработчиков из ЦЕРН стал публичным