Metadata Protection

[PowerPress]

Hi,

I was advised to post my issue to this repo since it effects all versions. Your Privacy whitepaper listed here https://wire-docs.wire.com/download/Wire+Privacy+Whitepaper.pdf shows that the following metadata is kept on the server:

3.2 Metadata
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 conversation
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.
The above metadata is encrypted using transport encryption between the clients
and the server.

Considering it is know known that Agencies kill people based on Metadata this isn't the best practice. Since each phone creates there own public keys couldn't the server encrypt all the above metadata information with each conversation participants public key so the the phones could decrypt the data and the server cant?

[baimafeima]

I'm not sure why there hasn't been a reply to a post like this. I've requested to reduce meta data over a year ago. Each time you sign up with a device - either for the first time or a new one - an automatic email is sent out in the open to my registered email address. This generates far more meta data and data and hasn't been fixed. See #103

[baimafeima]

Articles like this are also very misleading. Wire certainly does not guarantee anonymity. What can be on the road map, however, is privacy by eliminating meta data.

[youcefl]

It would be nice to have something done to address this issue. As can be read in this May 2017 article :
<< "Keeping all conversation metadata in a database forever does not seem like a great plan," Matthew Green, assistant professor at Johns Hopkins University, told Motherboard. >>
Is there a (public) roadmap where the fix of this issue appears?

[raphaelrobert]

@PowerPress @baimafeima @youcefl We wrote about this in the past: https://medium.com/@wireapp/product-design-decisions-for-secure-messengers-e8a5e7d1a373

The bottom line is: Doing robust group conversations, while allowing multi-device mode (and therefore not depend on a phone number) is a tough problem and you have to make some choices. We made ours and we have received good feedback about it.

However that is not to say things cannot change. We are now focusing on contributing to MLS (https://datatracker.ietf.org/wg/mls/about/) to create a better and more secure group conversation mechanism and keep on working to allow Wire to run in federated environments.

[PowerPress]

@raphaelrobert please check out some of the innovation here to see if this can be incorporated into wire: https://signal.org/blog/sealed-sender/

[raphaelrobert]

If anything, this would conceptually fit in with the MLS delivery service (DS).

[PowerPress]

@raphaelrobert Any rough idea when this could be implemented? Though it does look like a good service how does MLS help in the metadata mitigation? There is no references to metadata in the documents in the MLS link. Remember Metadata is enough for people to get killed over by just having a record of a conversation with the wrong person. All the encryption in the world will not have any effect if metadata can show that. We are talking about the envelope here and not the letter.

[raphaelrobert]

The architecture document does talk about metadata a bit, but I agree that it is maybe not very obvious at first sight. With MLS the group membership is primarily handled on clients. It is superior to existing solutions, because it gives every member of a group cryptographic guarantees of who is part of the group.
The server does not need to store group membership long-term as such, it only needs to know who to fan-out messages to (so ephemeral knowledge is enough). Whether this is a sustainable strategy for very large groups remains to be seen, but it should certainly work for smaller groups.
At IETF 103 we discussed options how to encrypt handshake messages (those are messages between clients that are sent as people are added to or removed from a group). This is still work in progress and not everything is figured out yet.

[Filbuntu]

I just stumbled upon this issue while searching for something else and found it interesting. Here is an update on Messaging Layer Security (MLS) :
https://wire.com/en/blog/wire_at_blackhat2019/
https://www.darkreading.com/perimeter/inside-mls-the-new-protocol-for-secure-enterprise-messaging/d/d-id/1335075

[PowerPress]

Does not discuss metadata. People get killed based on Metadata.

…

On Wed, Oct 2, 2019 at 6:50 AM Filbuntu ***@***.***> wrote: I just stumbled upon this issue while searching for something else and found it interesting. Here is an update on Messaging Layer Security (MLS) : https://wire.com/en/blog/wire_at_blackhat2019/ https://www.darkreading.com/perimeter/inside-mls-the-new-protocol-for-secure-enterprise-messaging/d/d-id/1335075 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#214?email_source=notifications&email_token=ABQHJ32I5SXMOUSBQKXVKVLQMSDIPA5CNFSM4FPBV6F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAEO7NI#issuecomment-537456565>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQHJ32LXQUFSIQCBUY7EDDQMSDIPANCNFSM4FPBV6FQ> .

[Filbuntu]

I don't know the details and I am just a simple user. But @raphaelrobert mentioned in his previous post that MLS has something to do with metadata and the quoted pages are regarding the work on MLS. @raphaelrobert may comment if this is still the case. I surely hope so. Cheers!

[raphaelrobert]

Metadata protection is indeed something we discuss actively within the MLS working group and it remains a goal as such.

[PowerPress]

Please take a page from Signal on this. They get metadata right. Even when legally compelled it is close to nothing they can provide. Personally I see that as the main reason there is less adoption of your service. Once you solve this a large signal userbase will move over since you do not require a phone number but can use userids to login.

[raphaelrobert]

Here is some background on the choices we took:
https://wire.com/en/blog/secure-messenger-product-design-decisions/

The hope is that with MLS we can have a Signal-like metadata situation while keeping the ease of use of Wire's group management.

[PowerPress]

Already messed up here: This data includes things like profile name, username, and profile picture, but also things like user’s list of connections and conversations. If your goal is to be slightly better than Whatsapp/Facebook keep following this direction.

Read this https://signal.org/blog/sealed-sender/

https://kieranhealy.org/blog/archives/2013/06/09/using-metadata-to-find-paul-revere/

Keep the data full encrypted on your server and the encryption key only on the device. Follow Signals lead and get Metadata possible collection points.

[raphaelrobert]

There seems to be some confusion. I'll try to address the different points:

• The low amount of metadata Signal has is a desirable property and a goal for Wire. MLS will be the technological foundation to move closer to this goal.
• The properties you can get from the sealed sender concept are already part of MLS (see "Message Framing" in the protocol on page 27).
• It is important to note that Signal doesn't let you manage groups like other applications. You cannot remove people from a group. Furthermore Signal doesn't support a standalone multi-device experience (devices are linked and the private identity key is copied from one device to another). In our view, this is not good enough for modern business messaging.

[hazcod]

Were there any updates on this matter?

[jcklpe]

Also curious about updates. Signal now allows for administration of groups in their newest update.