Wire-android: questions about metadata exposed to and retained by server

[Be-ing]

This does not just apply to the Android client, but I did not find any more appropriate place to discuss this.

The privacy whitepaper is lacking in detail in some areas. For all information made available to Wire's servers, I would like to know if it is stored on the server and if so, why it needs to be stored and how long it is kept.

Address books are uploaded to backend servers if users grant client applications
access to their contacts. Each address book entry is first normalized, i.e. phone
numbers are ensured to be in E.164 form. Entries are then hashed (using SHA-
256) and base-64 encoded before being transmitted to the server.

Does the server log the uploaded contact information? If so, is it stored in a way that associates it with the uploader?

Also, according to a blog post from Moxie, SHA256 is not very helpful when the possible inputs are so few. Are you doing anything differently than what he discusses there that makes the hashing more secure?

Wire maintains the following metadata about conversations on the backend
servers:
• Creator: The user who created the conversation.
• Timestamp: The UTC timestamp when the conversation was created.
• Participants list: The list of users who are participants of that conver-
sation and their devices. This information is used by clients to display
participants of the group and to perform end-to-end encryption between
clients (see Wire Security Whitepaper for further details).
• Conversation name: Every user can name or rename a group conversation.
Conversation names are not encrypted.

In what form does this data exist on the Wire server? How are the conversation creator and participants identified? Why does this need to be on the server at all? According to another blog post from Moxie it is possible to have private groups without the server having to even know that the group exists. If there is a risk of someone finding what groups a user is a part of, that in itself could be dangerous, especially with plain text group names.

Additionally, I'm questioning why users must set a display name for themselves. My mom was reluctant to provide this to your server, and rightly so. As long as others rely on this display name to know who they are talking to, it must be a name that people are actually known by; it cannot be set to nonsense to evade identifying one's name to the Wire server. If users could only find each other by phone number or email address, I don't think it would be necessary to have users reveal their name to the Wire server. When discovering contacts, the default name shown could be the name associated with the found phone number or email address in the user's address book. This is related to issues #310 and #214.

Is there any technological guarantee that a message set to autodelete will actually do so on recipients' devices? Couldn't the recipient's client be modified to ignore that?

[h-2]

Does the server log the uploaded contact information? If so, is it stored in a way that associates it with the uploader?

These information should never be store, only looked up once to inform the user about contacts that use wire. I hope this is the case. → ?

Also, according to a blog post from Moxie, SHA256 is not very helpful when the possible inputs are so few. Are you doing anything differently than what he discusses there that makes the hashing more secure?

There is not much you can do about this, it is the trade-off of having phone number associated contact discovery. I have sketched something that would be entirely p2p, but it only discovers contacts under certain conditions:
https://github.com/siacs/Conversations/issues/1978
This is likely not suitable for wire, because it won't have the same usability as WhatsApp.

A different thing you could do to strengthen the anonymity of the hash a little bit:

• generate a different salt every day on the server
• every n days the client updates its entry in the hash→useraccount database by renewing the hash with the new salt
• upon contact discovery, instead of hashing the phone numbers and uploading, instead iteratively hash in combination with the last m days' salt
• good values for n and m could be 5 and 50

→ you only discover contacs that were online in the last 45 days
→ by including salts, the hash→useraccount database cannot be "reverse hashed"
→ by not storing the date a hash was updated, the time to rehash all phone numbers rises by factor of m

This still means, that if an attacker has access to the database and copmuting power, they can find out the phone numbers, but it sure gives wire as a company the possibility to claim that they don't know them and that it's not feasible for them to find out.

According to another blog post from Moxie it is possible to have private groups without the server having to even know that the group exists.

Yes, please don't store group names and participants on the server :pray:

Additionally, I'm questioning why users must set a display name for themselves.

:pray: :pray: Please do not ask for names! Since there is association with address book entries, you can always deduce the name locally.

Is there any technological guarantee that a message set to autodelete will actually do so on recipients' devices? Couldn't the recipient's client be modified to ignore that?

It is never safe to assume that a message was actually deleted. Suggesting this is fooling your users. But it wouldn't even be desirable, because it would mean that you are handing control of your device over to some software that does things against your wishes, it's called digital restrictions management (DRM).
The feature in itself is ok, but it should rather be advertised as a polite delete intent for benevolent chat partners.

[someoneEsle]

I will say a few things:

1. Yes, it is possible to have group chats without storing participants on the servers. However, that is a bit harder than normal. If you've used Signal for a while and had a group chat where one of the participants reinstalled/got a new phone, you know what kind of pain in the butt it is to try to add them back/remove them/fix decryption issues. (This is not to say that the only solution is to have the server store everything, I'm just saying that it is not trivial. And honestly, I'm willing to wait until they come up with a real solution rather than do it Signal-like and break everything, but that's just my opinion).
2. They ask users to provide a name because on Wire you can connect to anyone you want by looking up their name (kind of like in facebook), or even simply by having their emails: in both cases you need them to have their own name. Name policy is something that is probably going to change, there are a couple of issues on github (too lazy to link them).
3. Let's not forget that Wire hasn't always been a privacy-focused messenger. It started out as a "normal" messenger that had its focus on usability/design. Only less than a year ago did they join the list of encrypted messengers. This means that while a lot has been done to improve privacy, a lot is yet to be done too. They've stated on twitter many times that they are going to update their approach to metadata soon (https://twitter.com/wire/status/795632701030207488). Some of your concerns are legit and I feel like they're already aware of most of them, they just need more developer time to get around to all the issues (consider that there's new features to be added, old bugs to be fixed, etc..).

[Be-ing]

They ask users to provide a name because on Wire you can connect to anyone you want by looking up their name (kind of like in facebook)

A problem with this is that many people are only using their first name, so it isn't that useful for discovering contacts anyway.

[someoneEsle]

A problem with this is that many people are only using their first name, so it isn't that useful for discovering contacts anyway.

Agreed. Trust me I have been pushing for a different policy in contact names since I installed Wire. I think that was kind of the reason behind prompting the users to provide "full name" on first install, so that they would include their last names. Not sure if people kept that intention when translating the app, but I agree that most people only use their first name.

[Be-ing]

@h-2 : Your ideas of adding salts to the hashes is interesting. I'll let someone who knows more about hashes comment on how much it would actually increase security.

It is never safe to assume that a message was actually deleted. Suggesting this is fooling your users. But it wouldn't even be desirable, because it would mean that you are handing control of your device over to some software that does things against your wishes, it's called digital restrictions management (DRM).
The feature in itself is ok, but it should rather be advertised as a polite delete intent for benevolent chat partners.

Thanks for clarifying, this is how I thought it worked. I think it would be good for Wire to clarify that this feature should not be relied upon if there could be serious consequences if the message does not delete.

[darkbluelight]

IMO: Do it like the threema.ch messenger and start with an anonymous handle automatically created by the Wire software on the first start, no need for the real name. Ask the user at the first start if the user wishes to upload its phone number, its (full) name and / or email to find its friends and probably even default the shown switches to "yes". Andvanced users will know what to do or what this option means and on the other side the "mainstream / Whatsapp users" will probably just click yes, yes, yes... and with that get the Whatsapp bahavior.

[someoneEsle]

:pray: :pray: Please do not ask for names! Since there is association with address book entries, you can always deduce the name locally.

Looks like they started working on usernames: https://github.com/wireapp/wire-android-sync-engine/commit/c3c4463cf4e23aa976a21c856c8e8fb68e4bbb11, but if I understand correctly, these will be usernames the users can choose for themselves (so that you can add them by searching for the username). To be honest I don't like this, it only adds more confusion to the app, since now I also have to remember who has what username in order to recognize them in my chats :expressionless: I just wish they'd raid my contacts list the way Signal does and use those names.

[Be-ing]

I don't think we should make assumptions about stub code that doesn't do anything without hearing from the people working on it. @JPonte , what are the plans for what the new username functionality will do?

[JPonte]

Implementation details are still being discussed but the usernames will ease the contact discovery since they're unique. The usual names will still be the ones that appear on your chats, so you won't need to remember people's usernames.

[h-2]

Let's not forget that Wire hasn't always been a privacy-focused messenger. It started out as a "normal" messenger that had its focus on usability/design. Only less than a year ago did they join the list of encrypted messengers. This means that while a lot has been done to improve privacy, a lot is yet to be done too.

Yes, of course. My intention of using this bug tracker is not "demanding immediate change" or calling them out for not doing something, instead I just like to add suggestions to the discussion and ask for opinions from the project.

[someoneEsle]

@JPonte what I meant by "I have to remember my friends' usernames" is that if they sign up using only their first name, then I have to remember their usernames to tell who is who. (But I don't want to go off topic too much)

[teller]

@Be-ing

Does the server log the uploaded contact information?

No. We hash, upload, look for matches, delete.

And yes, usernames are coming together with displaying name from phone address book if available.

So you could have a stiation of

username: @anakin
display name: Darth Vader
from address book: Dad

[grinapo]

@teller would you annotate it with where the info originates?
As far as I see username is given by the friend and address book name (which name? which parts?) is by me, but where does display name originates from?

As I guess everyone would like to have a display name for themselves, and also probably most of the people would like to be able to assign display name to given contacts. Same may go with comments. It may be a way to get it done by assign a phone book entry without any data but the name... but what to display? Nickname? Name? Both? Else?

(Like I have a friend called John Doe, he's using the username @william_the_notgreat and I know him by the alias QueenElisabeth4; I don't want to see neither John Doe [which there's aplenty] nor william_the_notgreat [since I've never have used it].)

[teller]

@grinapo

From address book: We look for first and last name.
@username: Automatically assigned to all users, they can change as many times as they want.
Display name: User selected upon account creation.

You can't currently change display name of others. It's a fairly frequently requested feature though. So might tackle this at some point. Currently not on active roadmap.

[grinapo]

@teller that would be #248 ;) seems like a really popular feature not on the roadmap...

[marcoconti83]

Hi everyone,
I'm cleaning up old Android tickets and would like to close or move this one to the appropriate repository.

Are there still any open questions about the metadata? If that's the case, I would suggest:

• read the updated privacy whitepaper
• if you still have concerns, open an issue on the main repository as this is not android specific