Часто задаваемые вопросы

Почему этот сайт плохо переведен? ⎃

Извините, но нынешние авторы говорят только по-английски. Нам нужна помощь в переводе этого проекта на другие языки. В качестве простого и недорогого средства сделать эту услугу доступной для людей, не говорящих по-английски, мы используем машинный перевод. Результаты обычно приемлемы, но могут привести к странным формулировкам или даже совершенно неточной информации. Вы можете помочь нам улучшить опыт для всех - отправьте правильный перевод .

Насколько безопасна эта услуга?

Мы предприняли много шагов, чтобы сделать этот сервис безопасным для использования по назначению . Прежде чем мы перейдем к этим шагам, важно понять следующее:

Наша цель - предложить эту услугу таким образом, чтобы предлагать возможности для повышения вашей конфиденциальности и безопасности. Вот несколько шагов, которые мы предприняли для защиты вашей информации:

Почему я получил здесь ссылку с возможностью расшифровать сообщение?

Приносим извинения, если в этом переводе есть ошибки. Эта служба просто передает зашифрованное сообщение из одной точки в другую, и вы являетесь получателем. Сообщение скоро будет удалено. Операторы этой службы не имеют возможности прочитать содержимое сообщения. Обычно кто-то использует эту службу, когда не хочет, чтобы содержимое сообщения оставалось в различных базах данных / устройствах / службах / файлах / и т. Д. как обычно при отправке электронной почты / мгновенного сообщения / текста / и т. д. Если вы решите расшифровать, имейте в виду следующее:

Вы удаляете все, что размещено на этом сайте?

Верный нашему логотипу корзины ... все удаляется вскоре после его получения. Удаление всего автоматизировано - оно записывается на сервер. Подумайте об этом так - есть два класса представляемой информации:

В случае сообщений вы можете контролировать, когда мы их удаляем, указав: По умолчанию все, что связано с сообщением, удаляется после того, как оно было получено один раз или прошло 1 неделю - в зависимости от того, что произойдет раньше. Когда дело доходит до удаления всей другой информации, связанной с отправкой чего-либо в Интернете (например, ваш IP-адрес и т. Д.), Мы не даем вам никакого контроля над тем, когда и как он удаляется - мы просто удаляем все это каждые 24 часа. .

Зачем пользоваться этой услугой?

Эта услуга - инструмент, помогающий сделать сообщения, которые вы отправляете / получаете, менее постоянными. Большая часть того, что вы общаетесь в Интернете (чаты, тексты, электронные письма и т. Д.), Сохраняется и редко удаляется. Часто, когда вы что-то удаляете, это на самом деле не удаляется, а помечается как удаленное и больше не отображается для вас. Ваши совокупные сообщения накапливаются год за годом в базах данных и на устройствах, которые вы не контролируете. Неизбежно одна или несколько организаций / людей / устройств, хранящих ваши сообщения, будут взломаны, и ваша информация будет утрачена. Эта проблема настолько распространена, что в настоящее время существует множество веб-сайтов, отслеживающих организации, которые были скомпрометированы и произошла утечка пользовательских данных. Сквозные зашифрованные временные сообщения - это простое решение, которое поможет сделать некоторые из ваших сообщений менее постоянными. У каждого сообщения, отправленного на этот сайт, есть время жизни в диапазоне от 1 минуты до 2 недель - по истечении этого времени сообщение удаляется. Кроме того, по умолчанию любое сообщение удаляется после того, как получатель получит его. Кроме того, все сообщения от вашего устройства до устройства получателя шифруются. Основная цель использования сквозного шифрования - лишить нас возможности читать любые отправленные сообщения, тем самым убрав часть требований доверия. Конечным результатом является то, что теперь можно легко отправить зашифрованное сообщение по простой ссылке. Это сообщение удаляется либо вскоре после отправки, либо после получения. Вам не нужно устанавливать / настраивать специальное программное обеспечение. Вам не нужно создавать учетную запись или предоставлять какую-либо личную информацию. Получатель не обязательно должен быть в ваших контактах или даже знать об этой услуге - единственное требование, чтобы он мог щелкнуть ссылку.

Это служба обмена сообщениями?

Нет. Эта служба предназначена для дополнения существующих служб обмена сообщениями, таких как обмен мгновенными сообщениями, электронная почта, текстовые сообщения и т. Д. добавив возможность запретить долгое хранение отправленных сообщений. Мы не доставляем сгенерированную ссылку получателю .

Каковы предполагаемые варианты использования?

Итак, каковы сценарии использования этой услуги? Хотя у всех разные потребности и требования, когда речь идет об их конфиденциальности и безопасности, я лично нашел следующие сценарии в качестве подходящих вариантов использования:

Для чего нельзя использовать эту услугу?

Эта служба не должна использоваться для получения очень конфиденциальной информации по всем причинам, описанным в этом FAQ. Ниже приведены несколько примеров того, чего нельзя делать:

Почему бы просто не использовать PGP / Signal / OMEMO / Matrix / и т. Д.?

Если вы знаете человека, которому хотите отправлять безопасные временные сообщения, часто отправляете их, ожидаете интерфейса, похожего на чат, и / или можете ожидать, что получатель будет иметь необходимое программное обеспечение и знает, как его использовать, этот веб-сайт, вероятно, не тот лучшее решение. Есть отличные варианты с открытым исходным кодом, поддерживающие E2EE, а не веб-интерфейсы, и даже такие, как Signal, которые также поддерживают временные сообщения. Я лично использую частный сервер XMMP и OMEMO, чтобы общаться с близкими друзьями и семьей. Использование этого сайта может быть оптимальным только в том случае, если вы не знаете, какое программное обеспечение использует получатель, не знаете его номер телефона / контактный номер, не знаете их технических навыков (но предполагаете, что они могут щелкнуть ссылку), или вы просто предпочитаете хранить отправляемое сообщение вне основного коммуникационного транспорта.

Какие требования существуют?

Требуется современный и современный веб-браузер, который должным образом реализует стандарты, включая API Web Crypto. Примеры: Chrome, Firefox, Edge и Safari (примерно 2020 г. или позже).

Может ли получатель сделать копию сообщения?

Да. Несмотря на то, что сообщение может удаляться при извлечении, получатель все равно может просматривать сообщение. В любое время, когда получатель может полностью просмотреть сообщение, можно сделать копию - это относится ко всем сообщениям. Есть возможность усложнить получение копии получателем. В этом случае реализуются три препятствия для копирования:

Однако эти средства защиты от копирования слабые, потому что их можно обойти. Также получатель всегда может просто сделать снимок экрана или фотографию сообщения.

Собирается ли какая-либо личная информация?

Мы не поддерживаем учетные записи пользователей (например, имя пользователя / пароль). Мы не собираем никакой информации, которая может идентифицировать вас (например, имя / адрес / адрес электронной почты / телефон). Возможно, что в отправляемом вами сообщении может содержаться какая-то личная информация, но она зашифрована, и у нас нет возможности ее прочитать. Пожалуйста, ознакомьтесь с нашей политикой конфиденциальности для получения полной информации.

Какая информация регистрируется?

Наш веб-сервер хранит до 24 часов общего формата журнала по всей веб-активности. Это включает в себя регистрацию полного IP-адреса HTTP-клиентов. Через 24 часа эта зарегистрированная информация автоматически удаляется. Все запросы, отправленные в / api, отправляются POST, что означает, что веб-сервер никогда не регистрирует конкретную информацию о сообщении. Кроме того, любая информация, сохраненная в базе данных, эффективно регистрируется. Все записи в базе данных, включая анонимные и хешированные IP-адреса, имеют срок действия (TTL), по истечении которого они автоматически удаляются. Срок действия TTL варьируется от 1 минуты до 2 недель.

Что вы делаете для защиты серверов?

Безопасность сервера - очевидная проблема. Чтобы обеспечить безопасность, мы уделяем особое внимание двум основным направлениям:

Какие риски безопасности присутствуют при использовании этого сайта?

Прежде чем конкретно рассмотреть некоторые из этих рисков, я думаю, что полукруглая аналогия может помочь суммировать риски при использовании любых Интернет-коммуникаций. Визуализируйте, что безопасность любой системы определяется только самым слабым звеном в цепи. Теперь представьте сценарий, в котором два человека находятся в запечатанной комнате, и у них нет средств видеть, слышать или записывать то, что они делают. Один передаст сообщение другому, который после прочтения его сожжет. Если кто-то за пределами этой комнаты хочет получить сообщение, которое уже было передано, это будет сложно. Какое самое слабое звено для получения сообщения? Здесь не так уж много звеньев на выбор - это довольно короткая цепочка. А теперь представьте, что когда вы отправляете сообщение в Интернете, что в цепочке есть по крайней мере миллион звеньев - многие из них слабые - многие из них полностью неподконтрольны вам - и это реальность.

Использование шифрования может значительно помочь в решении указанной выше проблемы с миллионом каналов, и его легко соблазнить мыслью, что хорошо спроектированные системы E2EE предлагают окончательное решение. Однако такое мышление может доставить вам неприятности, потому что злоумышленник обычно просто преследует более слабые звенья в системе. Например, вероятно, гораздо проще захватить ваш телефон или компьютер и настроить регистратор ввода, чтобы просто читать все, что вы вводите, чем взламывать зашифрованные сообщения по проводам. Суть в том, что если бы мне было поручено передать секрет жизненно / критически важного значения, я бы использовал электронные средства связи только как крайнюю меру.

Таким образом, существуют риски безопасности при использовании любых средств связи, но вы по-прежнему используете веб-браузер для банковских операций, покупок, электронной почты и т.д. На самом деле вопрос в том ... какие риски безопасности частично специфичны для этого сайта? На ум приходят несколько:

Что вы делаете с атаками типа "злоумышленник посередине" (MITM)?

Все пользователи веб-сайтов потенциально могут стать жертвой атаки MITM - в этом отношении этот сайт ничем не отличается от всех других веб-сайтов. Атака MITM - это когда злоумышленник может перехватить и изменить обмен данными между браузером пользователя и веб-сервером сайта. Это позволяет злоумышленнику изменять любой код / контент сайта, все еще представляя конечному пользователю тот сайт, к которому они привыкли. Мы принимаем некоторые меры, чтобы усложнить MITM-атаку:

Однако атака MITM всегда возможна, особенно если злоумышленник контролирует сетевую инфраструктуру / инфраструктуру с открытым ключом, как это было бы в случае крупных / влиятельных организаций или правительств. Мы предлагаем расширения для браузера, которые могут помочь снизить некоторые риски MITM.

Какие преимущества предлагают расширения браузера?

Мы предлагаем расширения для браузеров, чтобы обеспечить дополнительное удобство и дополнительную безопасность. Проще говоря ... Расширения ускоряют и упрощают отправку временных сообщений. Некоторая безопасность также достигается за счет того, что весь код, используемый для шифрования и подготовки сообщения, хранится локально внутри расширения. Поскольку код хранится локально, это предлагает отправителю некоторую защиту от атак MITM . Однако стоит отметить, что, хотя расширения предлагают большую защиту от атаки MITM, которая скомпрометирует содержимое сообщения, атака MITM все еще может быть эффективной (то есть для определения IP-адреса отправителя, если не используется TOR / VPN / и т. Д.).

Как я могу узнать наверняка, что все отправленные данные зашифрованы из конца в конец?

В отличие от многих других популярных клиентов чата со сквозным шифрованием (E2EE), довольно просто увидеть, что именно нам отправлено, когда вы отправляете сообщение. В приведенном ниже видеоуроке показано, как подтвердить, что у нас нет возможности расшифровать сообщения, отправленные на сервер.

Кроме того, если вы подумаете об этом, если мы не являемся каким-то секретным агентством, пытающимся собирать конфиденциальные сообщения, для нас нет никакой пользы от возможности расшифровывать сообщения, поскольку наличие этой способности создает для нас проблемы. Мы даже не хотим хранить сообщения - однако доставлять их - необходимое зло.

Как работает сквозное шифрование на этом сайте?

В настоящее время мы используем симметричное шифрование (AES-GCM 256bit) с ключами, полученными из паролей (минимум 150 000 итераций PBKDF2 / SHA-256). Асимметричное шифрование не используется, потому что существуют требования к 1) отправителю, инициирующему обмен данными 2) отправителю и получателю, не подключенным одновременно, и 3) отсутствию информации о получателе и 4) мы пытаемся сделать вещи максимально простыми и управление ключами сложный. Стандартный Web Crypto API используется для всех криптографических функций, включая RNG. В основном вот что происходит:

  1. Конечный пользователь выбирает пароль, или он создается автоматически.
  2. Выполняется вызов API для получения необходимого количества итераций PBKDF2 / SHA-256 ( этот шаг необходим для контроля спама )
  3. Создается 32-байтовая соль
  4. Ключ получается из соли и пароля.
  5. Создается 12-байтовый вектор инициализации (IV).
  6. Сообщение зашифровано с помощью ключа + IV
  7. Счетчик итераций, соль, IV и зашифрованный текст отправляются на сервер (вместе с некоторой другой информацией, такой как TTL, RTL и т. Д.)
  8. Сервер возвращает случайный идентификатор со ссылкой на сообщение.
  9. Затем браузер представляет конечному пользователю ссылку, содержащую возвращенный идентификатор и пароль, или ссылку без пароля (в этом случае получатель должен знать и ввести пароль).
  10. Если пароль является частью ссылки, он находится в хэше URL-адреса и, следовательно, никогда не отправляется на сервер, когда получатель делает запрос GET.
  11. Получателю будет предложено расшифровать и просмотреть сообщение.
  12. Браузер делает запрос с указанием ID сообщения.
  13. Если отправитель требует, чтобы CAPTCHA была заполнена, получатель перенаправляется на другой URL-адрес, чтобы доказать, что он человек (после прохождения они перенаправляются обратно)
  14. Сервер отправляет зашифрованное сообщение и по умолчанию удаляет сообщение на этом этапе, если значение reads-to-live (RTL) равно единице.
  15. Получатель расшифрует сообщение с паролем (и ему будет предложено ввести пароль, если его нет в URL-адресе)
Эта настройка чрезвычайно проста и предлагает шифрование сообщения от устройства отправителя к устройству получателя, но, конечно, не имеет гарантии, которую может предложить асимметричное шифрование с точки зрения знания, что только кто-то, владеющий закрытым ключом получателя, может расшифровать сообщение. Любой, у кого есть ссылка, может открыть сообщение в сценарии по умолчанию, когда пароль является частью URL-адреса - это подчеркивает важность использования соответствующего транспорта для ссылки (например, электронная почта / чат / текст / и т. Д.) - решение остается за отправитель. Мы можем, если есть интерес, также развернуть поддержку очень простой асимметричной схемы, при которой получатель инициирует запрос сообщения и отправляет эту ссылку запроса отправителю сообщения. Такая настройка устранит необходимость указывать пароль в URL-адресе, но также исключает возможность инициирования отправителем.

Пароль для расшифровки может быть в URL?

Да. Это, очевидно, влияет на безопасность, потому что, если метод, используемый для отправки ссылки, небезопасен, сообщение небезопасно по ассоциации. Все обходные пути для устранения этой проблемы включают дополнительные шаги и сложности, которые влияют на взаимодействие с пользователем (т. Е. Перед отправкой сообщения необходимо настроить параметры на обоих концах). Асимметричная схема, при которой получатель инициирует запрос сообщения и отправляет эту ссылку запроса, может работать с нашим ключевым требованием «все эфемерно» - это может быть реализовано. В конечном итоге, если две стороны будут часто отправлять сообщения друг другу, существуют лучшие решения, предполагающие, что обе стороны могут справиться с использованием этих решений.

Но пароль для расшифровки не обязательно должен быть в URL?

Верный. Если пароль для расшифровки не указан в ссылке, то получателю будет предложено ввести пароль. Если пароль надежно передан получателю (или он уже знает его), это обеспечивает защиту от перехвата. Однако недостатком является то, что получатель должен знать и правильно вводить пароль. Вот один из способов отправить пароль получателю, который предлагает некоторую защиту от перехвата:

  1. Зашифруйте пароль в сообщении с настройками по умолчанию и отправьте эту ссылку получателю.
  2. Когда получатель щелкает ссылку и расшифровывает сообщение, он знает, что никто другой не получил пароль до него, потому что сообщение, содержащее пароль, удаляется при получении. Однако, если есть активная атака MITM или если ваше устройство или устройство получателя были скомпрометированы, то все еще возможно, что другая сторона может получить пароль.
  3. Подтвердите получателю, что он успешно получил пароль. Например, если получатель сообщает вам, что, когда они отправились за паролем, сообщение уже было удалено, значит, вы знаете, что кто-то другой получил пароль раньше получателя, и поэтому пароль скомпрометирован и не должен использоваться.
  4. Используя пароль, который получатель подтвердил, теперь вы можете отправить сообщение, используя тот же пароль для шифрования - просто поделитесь версией ссылки, которая не содержит пароля.

Это правильно - мы генерируем ссылку и оставляем отправителю, как лучше всего доставить ее получателю. Цель этой службы - предоставить вариант, предлагающий меньшую постоянство в существующих механизмах передачи сообщений, таких как электронная почта / чат / текст / и т. Д. Следовательно, ожидается, что созданная нами ссылка на временное сообщение будет отправлена через существующий транспорт сообщений. Это имеет последствия для безопасности, которые пользователи должны понимать. В качестве примера возьмем текстовое SMS-сообщение, поскольку это довольно небезопасный способ связи. Когда вы используете эту службу для отправки временной ссылки сообщения через текстовое сообщение, если вы используете режим по умолчанию, в котором пароль включен в ссылку, любой, у кого есть ссылка, может прочитать сообщение, и защита от перехвата не предлагается. Эта служба по-прежнему обеспечивает более временную связь, которая может повысить конфиденциальность и безопасность. Кроме того, вы можете отправить ссылку без пароля, и это обеспечит защиту от перехвата.

Как я могу максимально защитить свою конфиденциальность при использовании этой услуги?

Как уже говорилось в этом разделе часто задаваемых вопросов, несмотря на то, что мы уже много делаем для защиты вашей конфиденциальности и не собираем никакой личной информации, некоторая информация, относящаяся к журналам , отправляется и собирается нами и другими лицами в силу того, что вы используете веб-браузер. Однако есть несколько способов еще больше защитить вашу конфиденциальность. Один из способов, который можно использовать бесплатно, основан на программном обеспечении с открытым исходным кодом и который работает достаточно хорошо, - это использовать браузер Tor . Этот браузер предназначен для защиты вашей конфиденциальности на нескольких уровнях, включая использование сети Tor . Наш сайт уже доступен через луковую сеть Tor, что означает, что для доступа к нашему сайту через Tor не требуется использование выходного узла, что исключает возможность подслушивания трафика выходного узла . Однако имейте в виду, что даже в этом сценарии ваш интернет-провайдер может видеть, что вы используете Tor - хотя и не для чего. Вы даже можете подключиться к VPN, а затем запустить браузер Tor для двух уровней анонимности; однако имейте в виду, что ваш интернет-провайдер все еще может видеть, что вы используете VPN в этом сценарии - хотя и не для чего. Если вы не хотите, чтобы ваш интернет-провайдер знал, какие протоколы вы используете, вы можете подключиться к большой общедоступной сети Wi-Fi, такой как библиотека, школа и т. Д., А затем использовать браузер Tor.

Что, если я не доверяю Соединенным Штатам?

Наши серверы расположены в США. Кроме того, наш поставщик CDN, Cloudflare, является компанией из США. Мы попытались избавиться от необходимости доверять нам или стране, в которой находятся наши серверы, просто потому, что мы не собираем личную информацию, не можем расшифровать какие-либо сообщения, и все удаляется вскоре после получения. Тем не менее, мы можем понять некоторое недоверие, поскольку оно основано на Интернете, особенно если вы живете в определенных странах. У нас есть планы предложить варианты в Исландии и Швейцарии для людей, которым сложно доверять США. Пожалуйста, дайте нам знать, относится ли это к вам, поскольку мы не будем мотивированы предлагать альтернативы, если на них нет реального спроса.

Что вы делаете для предотвращения спама?

Каждый раз, когда вы позволяете кому-то опубликовать сообщение, которое может быть передано по ссылке, вы приглашаете спамеров. Обуздать эту проблему не совсем просто. Мы не хотим загружать стороннюю CAPTCHA как часть процесса отправки сообщения по нескольким причинам:

Мы могли бы обойти проблему API, используя какую-нибудь систему ключей API, но тогда нам нужно собрать информацию о пользователях, чего мы не хотим делать. Кроме того, что может помешать спамерам получить много ключей API? Мы не можем исследовать сообщения, чтобы сделать вывод об их спамности (что в лучшем случае очень проблематично), поскольку, помимо шифрования сообщений, у нас есть политика невмешательства в отношении содержимого сообщений. Учитывая эти требования, мы используем два метода предотвращения спама: Если вам известно, что спамеры злоупотребляют этой службой, отправьте отчет о нарушении .

Почему есть возможность потребовать от получателя ввести CAPTCHA?

Хотя это правда, что нам не нравятся CAPTCHA, мы признаем, что они служат определенной цели и имеют время и место (по крайней мере, на данный момент). Это простой способ для отправителя получить некоторую уверенность в том, что получатель - человек и что автоматизированные процессы не получают доступ к сообщению.

Кто использует этот сервис и почему он бесплатный?

Мы всего лишь пара парней, которые иногда сталкивались с затруднительным положением из-за отсутствия хороших вариантов защиты нашей конфиденциальности. Часто это происходило из-за общения с друзьями и членами семьи, которые не очень осторожно обращались со своими устройствами и информацией. В других случаях это происходило при использовании веб-форумов, таких как Reddit, или при использовании веб-систем поддержки. Мы нашли несколько веб-решений для временных сообщений, но ни одно из них не предлагало E2EE, что означало, что мы не могли им доверять. Поэтому мы просто создали собственное решение и решили раздать его, чтобы другие могли извлечь из него пользу.

Как я могу доверять ответам на поставленные выше вопросы?

На самом деле вы не должны доверять никакому веб-сайту только потому, что он говорит определенные вещи - обычно хорошая идея проверить любые утверждения. Мы попытались убрать требование максимально доверять нам, применив сквозное шифрование. Например, довольно легко проверить, что мы не можем читать какие-либо сообщения, поскольку они зашифрованы . Мы также сделали код javascript, запускающий этот сайт, очень простым, чтобы его было легко читать и понимать. Открытие исходного кода всего кода позволяет людям проверять, что работает; однако имейте в виду, что нет никакого способа по-настоящему проверить, на чем работает сервер. Хотя это правда, что большая часть требований к доверию удаляется с помощью сквозного шифрования, это все же фактор, который наши пользователи имеют большое значение при принятии решения использовать эту услугу или нет.