Всё верно, и это сознательное архитектурное решение, а не баг. Шифрование защищает от одной конкретной угрозы — компрометации нашего сервера. Если завтра нас взломают и сольют всю БД, атакующий получит набор шифротекстов без ключей, потому что ключи физически никогда у нас не были (по HTTP-спецификации часть URL после # на сервер не отправляется, она живёт только в браузере получателя). Так же это работает в PrivateBin, Bitwarden Send и бывшем Firefox Send. От второй угрозы — что получатель сам перешлёт ссылку дальше — ни мы, ни любая другая система защититься в принципе не может. Если ты отправил человеку кусок кода, он его получил и волен делать с ним что угодно. Это ровно та же модель, что у обычного TG-сообщения, GitHub Gist или скрина в Slack: пересылается = расшарено. Поэтому формулировка “end-to-end” тут означает буквально то, что означает — код доступен только на эндпоинтах, отправитель и получатель. Если получателю доверять нельзя — проблема не в транспорте, а в выборе получателя, и никакой инструмент это не лечит. Что мы можем сверху дать (и планируется в следующих версиях): TTL на ссылку, лимит просмотров, отзыв ссылки одной кнопкой из IDE. Это не решает фундаментальную проблему “получатель сделал скриншот”, но сильно сужает окно злоупотребления при случайной пересылке.
Всё верно, и это сознательное архитектурное решение, а не баг. Шифрование защищает от одной конкретной угрозы — компрометации нашего сервера. Если завтра нас взломают и сольют всю БД, атакующий получит набор шифротекстов без ключей, потому что ключи физически никогда у нас не были (по HTTP-спецификации часть URL после # на сервер не отправляется, она живёт только в браузере получателя). Так же это работает в PrivateBin, Bitwarden Send и бывшем Firefox Send. От второй угрозы — что получатель сам перешлёт ссылку дальше — ни мы, ни любая другая система защититься в принципе не может. Если ты отправил человеку кусок кода, он его получил и волен делать с ним что угодно. Это ровно та же модель, что у обычного TG-сообщения, GitHub Gist или скрина в Slack: пересылается = расшарено. Поэтому формулировка “end-to-end” тут означает буквально то, что означает — код доступен только на эндпоинтах, отправитель и получатель. Если получателю доверять нельзя — проблема не в транспорте, а в выборе получателя, и никакой инструмент это не лечит. Что мы можем сверху дать (и планируется в следующих версиях): TTL на ссылку, лимит просмотров, отзыв ссылки одной кнопкой из IDE. Это не решает фундаментальную проблему “получатель сделал скриншот”, но сильно сужает окно злоупотребления при случайной пересылке.