Disappearing Messages

Timer Settings Payload:
┌─────────────────────────────────────────┐
│ Timer Mode (1 byte)                     │
│   0x00 = Disabled                       │
│   0x01 = After Send                     │
│   0x02 = After Read                     │
├─────────────────────────────────────────┤
│ Duration (4 bytes, uint32)              │
│   Value in seconds                      │
│   Range: 60 - 31536000 (1 min - 1 year) │
├─────────────────────────────────────────┤
│ Timestamp (8 bytes)                     │
│   Unix timestamp of setting change      │
└─────────────────────────────────────────┘

Timer Lifecycle:

1. Sender sets disappearing timer for conversation
   timer_setting = { mode: AFTER_READ, duration: 86400 }

2. Message created with embedded timer:
   message.timer = encrypt(timer_setting, session_key)
   message.send_timestamp = current_time()

3. Recipient receives and decrypts message:
   timer_setting = decrypt(message.timer, session_key)

4. Timer activation:
   IF timer_setting.mode == AFTER_SEND:
     expiration = message.send_timestamp + timer_setting.duration
   ELSE IF timer_setting.mode == AFTER_READ:
     expiration = read_timestamp + timer_setting.duration

5. Client schedules deletion:
   schedule_deletion(message_id, expiration)

Timer Sync Protocol:

Device A (sender):
  1. Sets timer for conversation with Bob
  2. Encrypts timer setting with self-sync key
  3. Broadcasts to Device B, Device C (own devices)

Device B receives:
  1. Decrypts timer setting
  2. Updates local conversation settings
  3. Applies to future messages
  4. Sends ACK to Device A

Conflict Resolution:
  - Latest timestamp wins
  - Vector clock prevents race conditions

Secure Deletion Process:

1. Identify target data locations:
   - IndexedDB message store
   - File system cache (media)
   - In-memory buffers
   - Search index entries

2. For each storage location:

   Database Records:
     - Overwrite content with random bytes
     - Update record with null values
     - Delete record from table
     - Trigger index rebuild

   File System:
     - Overwrite file with random data (3 passes)
     - Truncate file to zero length
     - Unlink file from filesystem
     - Request secure delete from OS (where available)

   Memory:
     - Zero memory buffers
     - Release memory to allocator
     - Request garbage collection

3. Verification:
   - Attempt to read deleted data
   - Confirm retrieval fails
   - Log deletion completion

Message Payload with Timer:
┌─────────────────────────────────────────┐
│ Header                                  │
├─────────────────────────────────────────┤
│ Encrypted Content                       │
│   ├── Message Text                      │
│   ├── Timer Settings (encrypted)        │
│   │     ├── Mode (1 byte)               │
│   │     ├── Duration (4 bytes)          │
│   │     └── Set Timestamp (8 bytes)     │
│   └── Media References                  │
├─────────────────────────────────────────┤
│ Authentication Tag (16 bytes)           │
└─────────────────────────────────────────┘

The timer settings are:
  1. Included in encrypted payload
  2. Covered by AEAD authentication
  3. Cannot be read by server
  4. Cannot be modified without detection

Timer Authentication:

1. Timer included in AEAD associated data:
   AD = message_id || sender_id || sequence_num || timer_blob

2. Encryption:
   ciphertext, tag = AES-256-GCM(
     key = session_key,
     nonce = unique_nonce,
     plaintext = message_content || timer_settings,
     associated_data = AD
   )

3. Recipient verification:
   - Decrypt with session key
   - Verify tag matches
   - Any modification invalidates tag
   - Reject message if verification fails

Offline Expiration Scenario:

Timeline:
  T+0:    Message sent to Alice (timer: 24h)
  T+1h:   Alice reads on Phone (timer starts)
  T+2h:   Alice's Tablet goes offline
  T+25h:  Timer expires on Phone
  T+25h:  Phone deletes message
  T+48h:  Tablet comes online

Tablet Reconnection:
  1. Tablet syncs with Phone
  2. Receives deletion sync record
  3. Verifies message should be deleted
  4. Performs catch-up deletion
  5. Confirms deletion to sync service

Deletion Log Entry:
┌─────────────────────────────────────────┐
│ Message ID (32 bytes)                   │
├─────────────────────────────────────────┤
│ Conversation ID (32 bytes)              │
├─────────────────────────────────────────┤
│ Deletion Timestamp (8 bytes)            │
├─────────────────────────────────────────┤
│ Deletion Reason (1 byte)                │
│   0x01 = Timer expired                  │
│   0x02 = User deleted                   │
│   0x03 = Admin deleted (groups)         │
├─────────────────────────────────────────┤
│ Signature (64 bytes)                    │
└─────────────────────────────────────────┘

Log entries are:
  - Encrypted with device sync key
  - Retained for 30 days
  - Used for offline device catch-up
  - Pruned after all devices confirm

Group Timer Change Protocol:

1. Admin initiates timer change:
   new_timer = { mode: AFTER_READ, duration: 86400 }

2. Create setting update message:
   update = {
     type: GROUP_SETTING_CHANGE,
     setting: DISAPPEARING_TIMER,
     value: new_timer,
     admin_signature: sign(admin_key, update_payload)
   }

3. Distribute via Sender Keys:
   - Encrypt with admin's Sender Key
   - Broadcast to group
   - All members receive and verify

4. Member verification:
   - Verify admin signature
   - Verify admin has permission
   - Apply new setting locally
   - Future messages use new timer

New Member Timer Handling:

1. New member receives group state:
   group_state = {
     members: [...],
     settings: {
       disappearing_timer: { mode: AFTER_READ, duration: 3600 }
     },
     sender_keys: [...]
   }

2. Member stores timer setting locally

3. For each new message received:
   - Extract timer from encrypted payload
   - Verify matches group setting
   - Schedule deletion accordingly

4. For messages sent:
   - Embed group timer in message
   - Encrypt with Sender Key
   - Other members honor sender's timer

Media Disappearing Flow:

1. Original upload:
   - Media chunked and encrypted
   - Chunks distributed to mesh nodes
   - Chunk IDs stored in message

2. Timer expires:
   - Delete local cached copy
   - Send deletion request to mesh
   - Request propagates to storage nodes
   - Nodes mark chunks for deletion

3. Mesh deletion:
   - Storage nodes receive deletion request
   - Verify request signature (from sender)
   - Mark chunks as deleted
   - Actual deletion on next garbage collection

4. Verification:
   - Attempt to fetch chunks fails
   - 404 response from mesh nodes
   - Deletion confirmed

Preview Cleanup Process:

1. Identify all cached previews:
   - Image thumbnails (various sizes)
   - Video thumbnails (first frame)
   - Audio waveforms
   - Document previews
   - Link previews with images

2. For each preview type:
   - Locate cache directory
   - Find files matching message ID
   - Secure delete each file
   - Update cache index

3. Platform-specific cleanup:
   - iOS: Clear NSCache entries
   - Android: Clear Glide/Picasso cache
   - Desktop: Clear Electron cache directory
   - Web: Clear Cache API entries

Backup and Disappearing Messages:

Scenario 1: Message expires before backup
  T+0:    Message received (timer: 1h)
  T+1h:   Message expires, deleted
  T+24h:  Daily backup runs
  Result: Message not in backup (correct)

Scenario 2: Message expires after backup
  T+0:    Message received (timer: 48h)
  T+24h:  Daily backup runs
  T+48h:  Message expires, deleted
  Result: Message in backup (problematic)

Mitigation:
  - Backup process checks timer expiration
  - Messages with timer ≤ backup_interval excluded
  - Backup metadata includes "disappearing excluded" flag

Recovery Behavior:

1. User loses device
2. Restores from backup
3. Recovery includes:
   - Non-disappearing messages: Restored
   - Disappearing message content: Not restored
   - Conversation exists: Yes
   - Timer settings: Restored
   - Message history gap: Visible

4. Recipient's perspective:
   - Their copy also expired
   - No authoritative record exists
   - Message effectively erased

Screenshot Handling:

Detection (where available):
  - iOS: UIApplicationUserDidTakeScreenshotNotification
  - Android: FileObserver on screenshot directory
  - Desktop: Limited detection capability
  - Web: No reliable detection

Response options:
  1. Notify sender of screenshot
  2. Display warning to recipient
  3. No prevention possible

User should understand:
  - Screenshots cannot be prevented
  - Notifications are best-effort
  - Privacy depends on recipient trust

Forensic Recovery Difficulty:

High Difficulty (secure):
  - Encrypted message content
  - Overwritten file content
  - Zeroed memory buffers

Medium Difficulty:
  - File system metadata
  - Database transaction logs
  - OS-level caches

Low Difficulty (vulnerable):
  - Unencrypted backups
  - Screenshots in photo library
  - Notification content logs
  - Third-party keyboard logs

Assessment:
  Disappearing messages provide privacy against:
    - Casual inspection
    - Relationship partners
    - Stolen device (if locked)

  Disappearing messages do NOT provide protection against:
    - Determined forensic analysis
    - Nation-state adversaries
    - Recipient with intent to save
    - Malicious app modifications