Profile picture privacy is worse than Signal

[cyanlemons]

Feature Issue

As far as I understand it, profile pictures are publicly accessible to anyone that has your chat key. This means if you ever speak once in a single public channel, your profile picture is no longer private. Furthermore, some malicious contacts of yours may post your chat key online.

In Signal, nobody can access your profile picture unless you add them as a contact, or unless you accept their incoming request. Even if someone has your phone number (analogous to someone having your chat key), they cannot see your profile picture on Signal. However, this is not the case for Status.

This matters, because it is conceivable that there could be "chat key dumps" in the future, just as there are "phone number dumps" today, where people unknowingly end up in some list – at which point their profile picture is periodically scraped by some Cambridge Analytica bot.

User Story

As a user, I expect Status to be at least as private as Signal. Despite this expectation, my profile picture is public by default.

Impact

Privacy parity with Signal is necessary to be competitive in the secure messaging market. Even Telegram has this option – although it defaults to public.

Description

There should be some sort of "Profile Picture Privacy" option in the account creation process where you can select the option of your choosing: 1) Share only with contacts (default selection) 2) Share with everyone

In addition to the changes to the account creation process, it should be possible to toggle this option in the settings.

[oskarth]

Is there a reason this wasn't caught during spec security review?

[hesterbruikman]

For clarity on the GH issue. Profile pictures are optional. Default is the existing avatar

That said, I agree we don't properly make people aware of profile pictures' current behavior and we don't include an explicit share option after adding the picture. This should be the same for ENS, as is now implemented on Desktop; First add, then share, as separate actions.

1. As a user I want to explicitly opt-in to sharing my profile after adding it, because when adding it, I'm not aware of if and how it will be visible to others
2. As a user I want to configure who sees my profile picture, because I want to choose for only people I trust to ever see my profile picture
   1. People I add as a contact (default)
   2. Everyone (Applies to onboarding and settings)

User story 2 captures your description @cyanlemons.

I would say that as the chat key is already public if you join a public chat, I see adding a profile pictures more akin to managing your public profile on Twitter. Signal does not have a concept of 'public', whereas Status does. The comparison with Signal to define features regarding identity management thereby doesn't work in all cases.

[cyanlemons]

Signal does not have a concept of 'public', whereas Status does. The comparison with Signal to define features regarding identity management thereby doesn't work in all cases.

I think the comparison in this case makes perfect sense, as Status can be used as a private messenger rather than as a Discord/Twitter-like social network. It's something we explicitly advertise as being a prominent feature of Status. It seems like the logical approach is to support the usage of profile pictures in a private context, and only a private one – given the fact that you will see someone's profile picture when chatting in DMs. Even though there is a public aspect to Status, I don't see any reason why we can't have 1:1 parity on all privacy-preserving elements that Signal provides when in the context of the private messenger.

[Samyoul]

@cyanlemons you raise a valid point, a solution would be the following:

Update the IdentityImage to have a new field decrypt_keys which holds the decryption key for the image, encrypted with each user contact's public key.

// ProfileImage represents data associated with a user's profile image
message IdentityImage {

  // payload is a context based payload for the profile image data,
  // context is determined by the `source_type`
  bytes payload = 1;

  // source_type signals the image payload source
  SourceType source_type = 2;

  // image_type signals the image type and method of parsing the payload
  ImageType image_type =3;

  // decrypt_keys holds the decryption key for the image, encrypted with each user contact's public key 
  repeated bytes decrypt_keys = 4;

  // SourceType are the predefined types of image source allowed
  enum SourceType {
    UNKNOWN_SOURCE_TYPE = 0;

    // RAW_PAYLOAD image byte data
    RAW_PAYLOAD = 1;

    // ENS_AVATAR uses the ENS record's resolver get-text-data.avatar data
    // The `payload` field will be ignored if ENS_AVATAR is selected
    // The application will read and parse the ENS avatar data as image payload data, URLs will be ignored
    // The parent `ChatMessageIdentity` must have a valid `ens_name` set
    ENS_AVATAR = 2;
  }
}

The process flows would be.

Sending

• Set profile image to private in settings (whether manually or by default)
• When a message is sent the Messenger checks the settings.
  • If set to private profile image:
  • If the chat is a public channel, do not publish the ChatIdentity with an IdentityImage
  • If the chat is private channel:
    • Get or generate image encryption key (IEK)
    • Encrypt the image data with IEK
    • Attach encrypted payload to the IdentityImage
    • Encrypt the IEK with the public key of each contact in the user's contact list
    • Attach the list of encrypted IEK to the IdentityImage.decrypt_keys field
    • Attach the IdentityImage to the ChatIdentity, send theChatIdentity`
    • Store the IEK, encrypted payload and decrypt_keys for future use.

Receiving

• Parse the IdentityImage payload
• If the IdentityImage has decrypt_keys attempt to decrypt each key
  • If no key can be decrypted ignore the IdentityImage
  • If a key can be decrypted:
  • Decrypt the image payload
  • continue to parse the IdentityImage as normal

Because we don't encrypt the image on a per recipient/contact basis and only encrypt the IEK multiple times the additional payload will be quite small and will not be a bandwidth concern, particular in the private message context.

[Samyoul]

Resolved with the merging of https://github.com/status-im/status-go/pull/2151 and https://github.com/status-im/status-react/pull/11768

[oskarth]

@Samyoul this is the type of thing which should also be updated in specs :)