最近，我看了
一篇有关
WhatsApp Messenger中
自毁消息的介绍
的文章 。 它将具有与Telegram类似的功能，但如果在Durov的Messenger中，删除操作适用于普通消息（秘密聊天），则它们也可以用于常规聊天中的照片。 也就是说，在发送了假设的照片之后，对话者将能够在有限的时间内查看照片，并且从理论上讲，它将从两个对话者中删除（最好也从服务器中删除），然后WhatsApp计划引入删除常规消息的操作（到目前为止已完成） 。
但是今天我们不是在谈论WhatsApp（因为我根本不使用它），而是在谈论Telegram。 自毁消息的想法几乎没有什么需求，但是有一些用户在使用它们，例如，在发送只能看到一次的文档或照片时（哎呀）。
对于那些懒得阅读的人，
Telegram上的自毁消息既不安全也不保密。 不要以为如果您以这种方式向与您交谈的人发送重要文档，他将无法保存该文档（我不是在谈论快速屏幕截图或电话屏幕的照片，上帝禁止，）-为此请使用秘密聊天。 对于那些对这些消息的真正实现感兴趣的人，您可以继续阅读。
我也使用了它们，虽然不经常使用，但它们只是“娱乐”，我并没有特别注意它们。 今年6月，在研究
UserAPI Telegram时 ，我测试了发送和接收照片的过程。 我玩得开心，没有更多了。 人们对查看发送消息的“视图”及其在响应中的一般显示方式感兴趣。 我想知道如何“从内部”实现此功能，是从电报服务器中删除文件还是以某种方式对其进行加密。
令我惊讶的是，这些消息实际上与通常的消息没有什么不同。 直直的。 它们具有与普通照片相同的
file_id ，您可以使用该文件本身获取文件。 即使您查看了该消息并在聊天中消失了，
也可以安全地保存/发送/转发该消息，并执行与处理普通照片/视频相同的操作。 也就是说，它不会从电报服务器本身中删除。
我再说一遍，此类消息不适用于秘密聊天，因为该通信在两个设备上进行，而我无法从另一个客户端访问它们。 此功能是为定期聊天而设计的，似乎被认为是“安全的”。 但这很有趣，我在任何地方都没有找到关于这些自毁消息的详细描述。 也就是说，Telegram似乎没有告诉我们这些消息在访问（如果您可以访问帐户本身）方面如此安全，例如相同的秘密聊天。 我唯一看到的是Telegram自己说，没有消息，甚至是秘密聊天，都没有100％的安全性，每个人都应对他发送的消息负责，但是...
我承认，它将在某种WhatsApp / Viber / VK中实现，我什至不会关注它，但是Telegram是一个非常方便的Messenger，我非常喜欢它，但我讨厌它的支持是志愿者的支持。
在六月的同一个月，我写信给support@telegram.org，在那儿我用两种语言写了整封信。 它不仅说到了自毁消息，还说了普通消息，Telegram没有对转发设置任何限制，但稍后会更多。
两个月后，他们没有回答我，所以我不得不写信给非常“支持”的电报，以解释在发现这种“漏洞”时该做什么和在哪里写。
在三个小时后，他们在那里令人惊讶地回答了我，他们告诉我您应该在security@telegram.org上写有关该协议中的严重漏洞的信息，或在此处分享详细信息。 我附上了支持人员提供的原始回复文本：
7月5日，支持回复你好 如果我们真的在谈论我们的应用程序或协议中的某种漏洞，则可以在此处共享详细信息或写信至security@telegram.org。
我决定将有关漏洞“细节”的信息写给支持人员，应用视频，脚本本身以及问题的解决方案（下面是我的消息），但直到现在，我还是没有收到邮件或支持人员的答复。 显然到目前为止，这还没有打扰他们。
最好让我们制作单个表情符号的动画。除了带有自毁消息的选项外，我还注意到，任何删除的消息（例如在私人聊天，群组，频道中）也很容易被拦截。 例如，使用
所有消息的
常规转发来完成此操作，例如，在单独的组中，并
使用已删除消息的ID获取
消息之后 （现在，库中具有处理程序）。
我还在我的信中描述了整个过程（尽管实际上很简单），并通过限制消息本身的转发来解决该问题。 并且，如果您没有完全限制，则禁止所有消息不断转发。 我认为开发团队将能够从前进行一些防洪工作。
对于自毁对象，只需将其从服务器中删除即可。 这不能解决问题，仍然可以在收到消息时准确地拦截消息。 为了完全消除，应该重新设计读取它们的整个算法。 例如，要为每条消息设置访问密钥，并且在使用此密钥时，图像/视频将仅在特定时间内可用。 我承认，对于开发团队来说，我很难想出整个算法，我自己也无法全面考虑所有方面，而且无论如何，都有一种方法可以拦截它们。 但是目前，它们的实现非常糟糕，从事此功能的开发人员应该对这种功能的开发负责。 好吧，或者在极端情况下，只需用红色粗体字母写出自毁消息很容易被拦截，这无非是玩具。
我将向您介绍一下自己，一个15岁的学生，最近喜欢用Python进行开发，涉足了User API，并发现了这种“缺陷/漏洞”。 更令人生气的是，我不得不在这写下所有这些–这是Telegram支持的糟糕实现，在4个月内，我无视了3次。
对于某些人来说，此功能将无用，不会在此类消息的不良实现中发现任何坏处，但我认为，由于Telegram本身对改进当前功能不感兴趣，因此仅考虑此功能对其他人将很有用。
我是第一次写文章，我可能会将错误留在某处，但我希望它们能在评论中纠正我，并指出。 或者，总的来说，他们会告诉我一切都错了，而忽略支持是一个好的解决方案，我最终会冷静下来。 我也附上我的信息：
没有收到回复的支持消息您好，我叫Khamidov Amal。
最近，我为我的项目写了一个用户体验。 在某个时候，我注意到我的朋友是如何给我发送一张自动删除的照片的。 我在Android客户端上查看了它，并在10秒后将其删除了。
但我想知道如何加密此类消息以及如何将它们存储在旅途中。 毕竟，事实证明，电报客户端首先将照片上传到手机，阅读后必须将其删除。
我使用Pyrogram库编写了一个小的python脚本，想了解它们是如何到达客户端的。
当我看到这些“自动删除的照片”看起来像普通照片（什么？）时，我感到很惊讶。
也就是说，如果我发送常规照片，则与“自嘲”没有什么不同。
之后，我编写了一个脚本，将该文件发送到文件中，然后，照片像普通照片一样进入了我的测试频道。 在我发送这张最“自解压”照片的电话上，它甚至没有被阅读。
它还使我可以在桌面客户端上查看照片。 也就是说，此脚本绕过了“自解压”照片的最重要要素。
我认为这是一个漏洞，并且我认为这是一种重新考虑发送“自删除”消息并在服务器而不是在设备上处理它们的方法的解决方案。
另外，我发现了第二个（几乎是一个漏洞），它是使用API的电报本身创建的，完全没有被禁止。
因此，我们正在谈论普通消息。
我还编写了一个常规脚本，该脚本将聊天中的所有消息发送（转发）到我的群组，并通过其ID进行标记。
我在此脚本中添加了一个处理程序，该处理程序可响应所有已删除的消息并提供这些已删除消息的ID（Hello Pyogram）。
之后，我添加了一个脚本，现在，当处理程序响应所有已删除的消息时，它将使用来自该组的消息（包含所有消息）检查它们，并按ID查找此消息。
一方面，这没有违反任何内容，因为电报具有开放代码，每个人都可以编写其用户机器人。 但是另一方面（俄语很好），在最近的一次更新中，您添加了为了安全起见删除自己和他人的消息的功能，但是由15岁的小学生编写的这种简单脚本似乎绕过了这一点。非常安全。
我了解每个人都会回应他发送的回复，但是一个人可以将重要文件错误地发送给不必要的人，此刻他将删除该消息（尽管对话者未读），而又不知道所有这些消息都可能受到危害最重要的是，该消息未标记为已读。
我认为，此决定是要限制转发消息并审查“读取”消息的方式。
在第二个视频中，我附加了如何保存所有已删除的邮件而不阅读它们。
我附上我编写的视频和脚本，以清楚地显示其工作原理。
以及它在代码中的外观（使用Telethon库，在Pyrogram上几乎相同）：
代码中最重要的部分。 其余只是帐户，电话号码等的指示。@client.on(events.NewMessage(func=lambda e: e.is_private and getattr(e, 'photo'))) async def handler(event: message.Message): # event.input_chat may be None, use event.get_input_chat() chat: InputPeerUser = await event.get_input_chat() sender: User = await event.get_sender() photo: Photo = event.photo await client.send_message(img_channel, file=MessageMediaPhoto(photo), message=f'<code>{chat.user_id}</code>\n' f'<code>{sender.first_name}</code>\n', parse_mode='HTML')