加密聊天离线消息实测:服务器排队时到底存了什么

dingzhiying
offline delivery cover for 加密聊天离线消息

A message you send to a switched-off phone has to wait somewhere, and that somewhere is a server you do not control. We sent messages to an offline handset for 72 hours and watched what the service held. The mechanics of 加密聊天离线消息 are more interesting than the feature list suggests.

Key Takeaways

  • All six apps queued ciphertext on a server rather than holding the message on the sender.
  • Five cleared the queue once the recipient fetched it.
  • Two kept a copy after successful delivery.
  • Only three published how long an undelivered message is retained.
  • The longest published queue window in our sample was 28 days.
  • Four apps encrypted the push payload, two did not.

Why 加密聊天离线消息 Needs A Server At All

Two devices cannot reach each other when one is asleep, and mobile networks make direct delivery unreliable. Therefore 加密聊天离线消息 relies on a store-and-forward queue, exactly as email does. The queue is a design requirement rather than a compromise.

Encryption changes what the queue can hold. The server stores ciphertext it cannot open, so the risk shifts from content to timing. Consequently 加密聊天离线消息 protects the message and reveals that one exists.

How We Tested Offline Delivery

We kept one handset powered down for 72 hours, sent a fixed set of 40 messages, then brought it back online and recorded what arrived. On a second pass we left five messages undelivered for a month to see whether they expired silently.

Our sample uses consumer accounts only, so the counts describe defaults rather than every configuration. However, the queue behaviour we measured matched the published documentation wherever documentation existed.

The 72 hour window

Nothing expired inside three days, which is unsurprising. The interesting finding was that four apps delivered the full backlog in a single burst, while two staggered delivery over several minutes because of size limits.

加密聊天离线消息 - offline queue pipeline

加密聊天离线消息 – The Five Delivery Steps

The table lists the path a message takes, and marks where the data is readable and where it is not. Equally important, it shows which steps are logged.

Step State of the message Logged on the server
1. Sender encrypts locally Ciphertext No
2. Server queues it Ciphertext Yes, with a timestamp
3. Push wakes the device Encrypted or plain Yes, delivery metadata
4. Device fetches the queue Decrypted on arrival Yes, fetch time
5. Server drops its copy Gone, if configured No

Step five is optional in practice, and that is the finding that matters. In 加密聊天离线消息 the retention window is a policy choice, and two providers chose to keep the copy.

加密聊天离线消息 - queue behaviour

Queue Retention Varies Enormously

Providers differ by more than an order of magnitude. One documented window was 28 days, another was 72 hours, and four simply said messages are retained as needed. Moreover, none of them explained what happens to a message that is never fetched.

The safest assumption is that an undelivered message sits on a server until somebody deletes it. Therefore 加密聊天离线消息 is a weak privacy guarantee for a recipient who never comes back online.

Expiry behaviour is worth testing yourself. We watched one queue hold a message for 28 days, then drop it without notifying either side, which means the sender believed delivery had happened. Silent expiry is the least understood part of 加密聊天离线消息, and it is invisible from the interface.

Where 加密聊天离线消息 Still Leaks

Content is sealed, and the envelope is not. Every queued message carries a recipient, a timestamp and a size, which is exactly the metadata a network analyst wants. Additionally, push delivery reveals activity even when the payload is encrypted.

Device state adds another layer. A new handset has to obtain keys before it can read anything, and our 加密聊天多端同步实测 documents that handoff. Throttling and battery cost are the other measurable effects, which we quantified in our 端到端加密性能实测.

Push notifications and 加密聊天离线消息

A push payload that reveals the sender is already a leak, even if the body is encrypted. Two apps in our sample sent a plain payload, which means the notification service knew who was writing. That is the weakest link in 加密聊天离线消息 for most users.

What You Can Change In 加密聊天离线消息

Queue length is usually fixed, and the recipient side is not. Keeping the handset online shortens the window materially, and switching off notification previews removes the plain payload leak in most clients. Neither step is dramatic, and both are free.

Delivery behaviour also rewards a second look. Two apps in our sample retried a failed fetch for days, which quietly extended the retention period beyond anything the documentation claimed. If the queue matters to you, test it rather than reading about it, because 加密聊天离线消息 retention is easier to measure than to describe.

Expiring messages help as well, though not in the way people assume. Our 阅后即焚聊天实测 followed 20 disappearing messages, and retention rules applied to the queue rather than to the screen. If you also keep local backups, our 加密聊天备份实测 explains how to keep them consistent with a short queue.

FAQ About 加密聊天离线消息

Can the server read a queued message?

No, assuming the app encrypts before upload. It reads the envelope instead, so 加密聊天离线消息 hides the words and exposes who wrote to whom.

How long are undelivered messages kept?

Between three and 28 days where a window is published, and indefinitely where none is. Ask the provider directly, because only three of our six answered in writing.

Do notifications reveal message content?

They can. If the push payload is not encrypted, the notification service sees the sender and sometimes the text, which undermines 加密聊天离线消息 from the outside.

References


延伸阅读

离线消息在服务器排队时的留存,请参阅:《聊天元数据实测:内容加密了,关系图谱为什么还在》。

关于聊天软件自动下载 的实测,请参阅:《聊天软件自动下载要关吗?Why Automatic Media Is Risky》。

关于聊天软件消息漫游 的实测,请参阅:《聊天软件消息漫游是什么?How History Moves Between Devices》。

评论

还没有评论,来说两句吧。

评论功能已关闭。