Ключ должен быть одноразовый, то есть либо генерировать его каждый раз (но может быть уязвимость в алгоритме генерации), либо генерировать один раз, но очень большой, как обсуждалось выше.
Так почему бы тогда для таких топовых вузов не ввести "второй тур" с более сложными задачами? Сдаст абитуриент ЕГЭ на высокий балл — пусть соревнуется с равными себе если хочет. Не сдаст — всё равно есть возможность поступить в вуз попроще.
Один пароль от аккаунта, другой от вашего приватного ключа.
Какие ваши доказательства?
Ну вот смотрите: вы отправляете письмо через Протон на третьесторонний сервер. Протону придётся отправлять его незашифрованным. Аналогично, когда вам придёт письмо с третьестороннего сервиса, Протон примет его незашифрованным, зашифрует вашим публичным ключом и положит в облако. То есть даже у Протона существуют MITM-участки, если вы самостоятельно не озаботитесь осуществлять собственное PGP-шифрование и требовать того же от ваших корреспондентов.
Даже если сейчас Протон не читает и не сохраняет в открытом виде содержимое писем, его могут обязать устроить слежку. Тогда они смогут читать все новые письма, которые отправлены или получены с других сервисов и которые не были зашифрованы вами самостоятельно.
Насчёт писем, пересылаемых внутри Протона, сказать сложнее. С одной стороны, они скорее всего шифруются на клиенте (если нет — смотри выше), но если это их собственный клиент, то у них может быть там закладка: при команде от товарища майора клиент перешлёт письмо на сервер в открытом виде, где его зашифруют публичным ключом получателя.
All messages in your Proton Mail mailbox are stored with zero-access encryption.
А знаете что на самом деле это означает? Что они шифруют письма, когда кладут их в облако. То есть доступа к письмам не имеет облачный провайдер, а не сам Протон, который, очевидно, имеет, потому что сам их шифрует и расшифровывает.
Что-то я сомневаюсь, что email так работает. Если вы хотите отправить кому-то секретное письмо, то должны зашифровать его публичным ключом получателя. Тогда только он сможет расшифровать его своим приватным ключом. Это классическая схема.
Здесь же, предположим, вы пишете письмо, и оно зашифровано локально. Кому вы его отошлёте, если никто ваш пароль знать не должен? Обратное тоже верно: вам прислали читаемое письмо, сервер переслал вам читаемое письмо, вы на клиенте его зашифровали? Бред же.
Статья выбрана не случайно: она рекомендована для ознакомления с паттерном MVP. Причем в списке литературы значится под первым пунктом.
Рекомендована кем?
Вас смутила только дата последней редакции или есть какие-то недочеты в материале?
В 2025 году разработчикам фронтенда на JavaScript почти не требуется паттерн MVC. Если же и давать его описание, то либо на современном стеке, либо минимальным кодом на ванильном JS.
Вы, вероятно, сталкивались по крайней мере с одним из этих фреймворков, но они включают в себя такие, как Backbone, Ember.js и JavaScriptMVC.
Во-первых, качество перевода этого предложения ужасное. Грамотнее было бы перевести его как «Вы, вероятно, уже сталкивались хотя бы с одним из таких фреймворков, например с Backbone, Ember.js или JavaScriptMVC», хотя и это не лучший вариант — нужно творчески перерабатывать весь абзац.
Во-вторых, и самое важное, — сам смысл фразы устарел вместе с перечисленными фреймворками. Они стали не нужны, потому что так программировать попросту неудобно. Соответственно, новички, на которых вы позиционируете вашу статью, толком не поймут её из-за обилия нюансов о фреймворке и тяжёлого языка.
Довелось пользоваться и Skype for Business...
Не уменьшенный интервал, а уменьшенное межбуквенное расстояние. Интервал — это по-вертикали.
Так вот почему MS Teams такой глючный
Ключ должен быть одноразовый, то есть либо генерировать его каждый раз (но может быть уязвимость в алгоритме генерации), либо генерировать один раз, но очень большой, как обсуждалось выше.
Да зачем куаркоды? Правительство сразу файл ключа заберёт.
И давать возможность подсовывать приложениям пустой или изолированный набор контактов
Вдобавок, технологии и наработки в сегменте лакшери потом могут уйти в более дешёвый сегмент товаров.
Кстати у многих музыкантов обычно Мак, в котором тоже букв у дисков нет
в Дюне что ли? :)
Ну а странные квантовые эффекты типа эффекта наблюдателя, квантовой запутанности?
Так почему бы тогда для таких топовых вузов не ввести "второй тур" с более сложными задачами? Сдаст абитуриент ЕГЭ на высокий балл — пусть соревнуется с равными себе если хочет. Не сдаст — всё равно есть возможность поступить в вуз попроще.
То есть под это попадают и все юрлица с бухгалтерией на аутсорсе?
Один пароль от аккаунта, другой от вашего приватного ключа.
Ну вот смотрите: вы отправляете письмо через Протон на третьесторонний сервер. Протону придётся отправлять его незашифрованным. Аналогично, когда вам придёт письмо с третьестороннего сервиса, Протон примет его незашифрованным, зашифрует вашим публичным ключом и положит в облако. То есть даже у Протона существуют MITM-участки, если вы самостоятельно не озаботитесь осуществлять собственное PGP-шифрование и требовать того же от ваших корреспондентов.
Даже если сейчас Протон не читает и не сохраняет в открытом виде содержимое писем, его могут обязать устроить слежку. Тогда они смогут читать все новые письма, которые отправлены или получены с других сервисов и которые не были зашифрованы вами самостоятельно.
Насчёт писем, пересылаемых внутри Протона, сказать сложнее. С одной стороны, они скорее всего шифруются на клиенте (если нет — смотри выше), но если это их собственный клиент, то у них может быть там закладка: при команде от товарища майора клиент перешлёт письмо на сервер в открытом виде, где его зашифруют публичным ключом получателя.
А знаете что на самом деле это означает? Что они шифруют письма, когда кладут их в облако. То есть доступа к письмам не имеет облачный провайдер, а не сам Протон, который, очевидно, имеет, потому что сам их шифрует и расшифровывает.
Согласен, это уже что-то, но как-то так себе. Тем более, получается, оба пользователя должны через веб-интерфейс Протона работать.
Что-то я сомневаюсь, что email так работает. Если вы хотите отправить кому-то секретное письмо, то должны зашифровать его публичным ключом получателя. Тогда только он сможет расшифровать его своим приватным ключом. Это классическая схема.
Здесь же, предположим, вы пишете письмо, и оно зашифровано локально. Кому вы его отошлёте, если никто ваш пароль знать не должен? Обратное тоже верно: вам прислали читаемое письмо, сервер переслал вам читаемое письмо, вы на клиенте его зашифровали? Бред же.
Криптокодеры используют Backbone? O_o
Рекомендована кем?
В 2025 году разработчикам фронтенда на JavaScript почти не требуется паттерн MVC. Если же и давать его описание, то либо на современном стеке, либо минимальным кодом на ванильном JS.
Во-первых, качество перевода этого предложения ужасное. Грамотнее было бы перевести его как «Вы, вероятно, уже сталкивались хотя бы с одним из таких фреймворков, например с Backbone, Ember.js или JavaScriptMVC», хотя и это не лучший вариант — нужно творчески перерабатывать весь абзац.
Во-вторых, и самое важное, — сам смысл фразы устарел вместе с перечисленными фреймворками. Они стали не нужны, потому что так программировать попросту неудобно. Соответственно, новички, на которых вы позиционируете вашу статью, толком не поймут её из-за обилия нюансов о фреймворке и тяжёлого языка.
Скажите, когда вы эту статью переводили, вас не смутила первая строчка?
Ещё есть Cygwin — это вообще практически полноценный дистрибутив с кучей приложений и библиотек, нативно работающий под виндой