serenity-kit/serenity-notes-clients

Attachments/Files [RFC]

Opened this issue · 0 comments

Goal

Definition of how files are encrypted and stored.

UX goals

  • A device should be able to encrypt a file and store it remotely.
  • Other devices must be able to decrypt the file.
  • A user should be able to attach a file to a note.

Open questions

  • What happens when a note is deleted that contains an attachment?
  • What happens when access to a file is revoked?
  • What happens when access to a note with a file attached is revoked?

Proposal

Encrypt each file with AES-CTR and the key should be stored inside the note. Files can't be changed. Only a new file can be uploaded. Offline clients by default download the encrypted file and store it locally. In order to safe storage later on there could be a setting to remove files from the local device and only load them on demand.

Is it necessary to sign the files in any way (GCM mode?)? Does this help? Maybe directly returned, but not if referenced in a note?!

When a note is removed, the file also should be removed.
Encrypted files can not be referenced in other notes.

Start with a 2MB upload limit for free accounts and 5MB for paid account.

What happens when access to a note with a file attached is revoked?

Ideally when a user/device gets removed the file it should be re-encrypted and replaced with the new one. This would increase complexity and there are a lot of unclear UX questions.

One way to handle this is to revoke access to the file. This means if user doesn't have access the server could decline it which leads to the implication that the server would need to know who has access and this would reveal even more meta data of a note than necessary.

Another option would be to introduce a move mutation that moves the file and re-assigns it to a new ID and replace the ID in the note. Then the removed device/user would not be able to access it anymore.

Open question: Should the server know who created a file? It's again unnecessary meta data, but on the other hand this is the only way to allow the user to remove the content.

Storage Options

  • S3
  • Postgres binary data

In any it must be setup in a way that it is easy to move e.g. https://www.serenity-static.re/data/:id

Should the storage prevent downloading files if you don't have access? -> Wouldn't do for now.
Make sure to only accept a certain mime-type and also only serve a certain mime-type so people won't abuse the storage API.

Research

Matrix

the files are encrypted using AES-CTR

https://matrix.org/docs/spec/client_server/r0.4.0#sending-encrypted-attachments
https://matrix.org/docs/guides/end-to-end-encryption-implementation-guide#encrypted-attachments
https://github.com/matrix-org/matrix-react-sdk/pull/562/files

Signal

encryptAes256CbcPkcsPadding

https://github.com/signalapp/Signal-Server/wiki/API-Protocol#attachments (Server)
https://github.com/signalapp/Signal-Desktop/blob/984b5e2b44e88da92b6314d15c159ca80fb288cc/ts/Crypto.ts#L203

iMessage

the attachment is encrypted using AES in CTR mode with a randomly generated 256-bit key and uploaded to iCloud. The AES key for the attachment, its Uniform Resource Identifier (URI), and an SHA-1 hash of its encrypted form are then sent to the recipient as the contents of an iMessage

https://support.apple.com/en-gb/guide/security/sec70e68c949/1/web/1

TODO

No image links! It makes people trackable in a note