Wire-ios: Backup of conversations

[ghost]

Please add a backup functionality so users could bring over their old conversations to a replacement phone.

[EgbertW]

Yesterday I found a need for this, too.

To preserve encryption, maybe you could add a way to create a encrypted, archived file that you can transfer using system share extension to anywhere, and add a need to import these backup files into a fresh Wire setup.

Alternatively, when you add a new device, maybe add a feature that allows you to transmit the entire chat history on one device to another, using E2E-encryption.

[cardassian-tailor]

this sounds good at first glance, but would be a security issue in the long term.

POINT 1) What most users want is = on a new device and first login on that device all prior communication up to that point is NOT synced. You only see new content.

When a users password is reset, the encryption keys change, meaning that all prior communication should be fully encrypted with another password and not recoverable. This is desirable, especially if you want truley secure communcations.

Any attempt to 'backup' all your communcations is a huge risk. Image if someone gained access to your account, logged in and immedietly had access to all your prior communications (this is why POINT 1 is good practice). Next, they "backup" this content and export it.

What should happen is this, new device logins sync no prior communcations. Password resets create new private keys and all prior communications are lost.

[wangkesen]

But You really don’t have to “Backup” that way PE se and if the user is backing up conversations they consider important and essential to backup they would do so at their own risk no? And instead of a formal backup option to backup conversations this could be implemented by being able to select all parts of the conversation or individual ones, similar to Whatsapp ( I hate the comparison too)

Also, users are (If they wanted to) already able to backup a conversation by this method via just long pressing a message and copying it then pasting it wherever. By being enabling selection of multiple messages at a time or select all then users could just save text copies to clients like Standard Notes which is client side encrypted as well or Cryptomator avoiding the need to store locally on their device at all. That being I said obviously it’s a vulnerability to store anything outside of the application but your not preventing users from copying messages in the first place so is really inevitable that they be prevented from “backing up” conversations unless the messages were not copyable.

[EgbertW]

You are indeed not preventing users from making backups of texts - you can always make screenshots.

Contrary to what @oscalation states I see no reason to make it so that your conversations are stored on the server - the current approach where messages are only stored on the device that received it is fine. If you log into a new device, you don't get the history right away. However, I would really like it if you have to option to generate a (encrypted / password protected) archive file of all conversations / content and send it to somewhere else manually, and load it up in another client.

As long as backups are not made automatically and are always encrypted, I see no direct vulnerability or privacy issue. If one is able to break the encryption on the container or break the password, you could just steal the phone and get the messages from there directly.

[cardassian-tailor]

Nothing I said requires storing messages on a server

With the information wangkesen @wangkesen Provided : i cannot backup a conversation on mobile. I can copy a single message by long pressing it. Can you share how you can backup a conversation? If that exists it should be removed.

Imagine someone gains access to you account without your permission. What SHOULD happen is a master key (only used when the app is installed on a new device) is required and the account password. Once you login nothing is synced by design.

What could happen if backing up conversations was possible.

Someone logs in without permission, backups all of your prior conversations, proceeds to violate your privacy, maybe steel your identity, sends it to a third party, etc.

Note that the existence of the master key and account password means that even if your private key password(the password used to decrypt your messages) was leaked, your messages could still be safe as they would need the masterkey in addition.

Has anyone given a use case why would backing up a conversation be worth the added risk?

The prior is obviously preferred. Having the ability to backup your conversations is a very dangerous tool. For users who want truely secure communications, if this was implemented we would be forced to delete every message as it occurs.

[cardassian-tailor]

A single message is able to be copied because someone may send you an address, a phone number, something you may need to copy. That's a good compromise.

[wangkesen]

Okay I’m reading what you’re saying but
1+1 equal 2.
100 pennies comprise a dollar.
Obviously you can copy and paste a message. You can screenshot that message. You could one by one copy and paste every message from iOS. On OSX you could highlight multiple messages and copy that. Timed messages is the same. There’s nothing preventative in limiting a user to copying one message on a mobile platform if they want to copy a conversation they’re going to do so. Unless you’ve got messages timed to a second or less there is always substantial “risk” that a message could be copied.

[wangkesen]

Also those are situations yes, but none of them change the fact that ultimately a message can be copied and pasted, or someone could take a screenshot. The difference is that a backup would essentially validate those messages like, they could legally be used against you or whatever. A screenshot is a screenshot and a copy and paste method is just an alternative, obviously slow way of copying an entire conversation.

What you’re saying basically doesn’t really make any difference because A) It can already be done. At a slower and more frustrating pace for someone for sure but can still be done. B) There is no prevention of copying and pasting messages. C) Even the most secure, private messaging with the strongest encryption is not going to guarantee trust with another individual or that that person won’t “betray” you. You could tell someone something in confidence and it be completely encrypted and secure. If that person decides to tell a third party either via message or in person whatever, what is encryption going to do at that point? Nothing really. If your communicating wigh someone there has to be some basic element of trust involved. Otherwise it’s not just security, but also anonymity that you also need to implement and if then really messages copied or otherwise wouldn’t be associated with you. But bottom line there is no prevention of copying messages, it comes down to being able to select one or multiple at a time.

Unless we arrive at a point where someone can not implement any means of copying a message whether that be in the messenger, screen shots, using another phone or camera to capture the screen, or heck even recording the whole conversation as your typing which as I’m aware is not blocked currently, correct?
And iOS 11 brings screen recording in natively with superior ease. So really I think that feature addition of multiple selection for messages is hardly a security risk if your threat model is so high you can’t even risk a copied message.

[cardassian-tailor]

The impedance and inability to backup all messages at once IS a feature. That's intentional. It's desirable.

Just because people can copy one message at a time, or screen shot three doesn't mean we should provide them the means to backup/copy all with a few clicks.

[ghost]

As long as the Wire developers are aware of the fact that this "feature"
will be a big show stopper for business users, then that's no real problem.
Business users want to have an archive of their conversations, even if one
of their devices may die one day. If Wire is unable to offer them such an
archive, then they will use other services like Slack.

On Sun, Jun 25, 2017 at 3:16 PM Nathan Heafner [e-mail]
wrote:

The impedance and inability to backup all messages at once IS a feature.
That's intentional. It's desirable.

Just because people can copy one message at a time, or screen shot three
doesn't mean we should provide them the means to backup/copy all with a few
clicks.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/wireapp/wire-ios/issues/877#issuecomment-310902068,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOhn3BXb8ktmvWgmrn3yC71j55pDscARks5sHl2lgaJpZM4MqrRt
.

[wangkesen]

Pretty sure that’s not a feature And was never marketed as one. I really fail to see what relevance anything your saying is beneficial to the conversation. This isn’t even a big deal for me I was just observing what the other user had suggested. But backup and copying messages are two different things and with current setup copying messages to form a backup is not impossible just takes time really. But the fact remains that it can be done regardless. Like your argument is pretty weak I feel.

[cardassian-tailor]

The relevancy is that what you are suggesting would place users in a less secure state for the sake of feature creap and "usability".

Copying a single message, or screen shooting three messages over and over and over again is in no way comparable to clicking a few times to export an entire chat or all of a users chat.

I have a single chat open with 80 users in the group chat with close to 10k messages on wire ... let's pretend that you gain unauthorized access to any of those 80 users wire account (increased odds). Now, according to you, that account you have obtained could export all of those users private conversations within that chat with about three clicks. That's not a feature, it's a recipe for disaster and is in direct opposition to normal security measures.

You've yet to provide any use case for why a user would need to backup or export their chats.

If me and you are chating and i don't wish for you to export my content, what option would I have?

If an export feature existed, for users who didn't like this feature we would have to 1) delete all messages immediately 2) discontinue using wire. Which would you suggest?

Which would you consider more of a feature (this is subjective), the ability to export OR the peice of mind knowing another user can't easily export thousands of your messages?

[ghost]

I heard that Wire is open source. How can you be so sure that nobody is
able to export/backup chats, if someone develops a non-official Wire client
which is able to export/backup?

On Sun, Jun 25, 2017 at 5:58 PM Nathan Heafner [e-mail]
wrote:

The relevancy is that what you are suggesting would place users in a less
secure state for the sake of feature creap and "usability".

Copying a single message, or screen shooting three messages over and over
and over again is in no way comparable to clicking a few times to export an
entire chat or all of a users chat.

I have a single chat open with 80 users in the group chat with close to
10k messages on wire ... let's pretend that you gain unauthorized access to
any of those 80 users wire account (increased odds). Now, according to you,
that account you have obtained could export all of those users private
conversations within that chat with about three clicks. That's not a
feature, it's a recipe for disaster and is in direct opposition to normal
security measures.

You've yet to provide any use case for why a user would need to backup or
export their chats.

If me and you are chating and i don't wish for you to export my content,
what option would I have?

If an export feature existed, for users who didn't like this feature we
would have to 1) delete all messages immediately 2) discontinue using wire.
Which would you suggest?

Which would you consider more of a feature (this is subjective), the
ability to export OR the peice of mind knowing another user can't easily
export thousands of your messages?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/wireapp/wire-ios/issues/877#issuecomment-310911119,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOhn3Fgc2gVDdbuopexA-9NMBzfhpbTVks5sHoO9gaJpZM4MqrRt
.

[wangkesen]

@oscalation . Again, what is the relevance it’s getting repetitive at this point. If you actually were that paranoid you would realize that there is a certain risk either way. It’s actually inevitable. Are you blocking copying of messages or disabling screenshots? No. And would be more then dead easy on OSX with automation so like you can quit making it out to be such a huge feat. Also, repetitive but if someone betrays your trust, they have that ability regardless of what you do unless you engage in voice conversations but then still, they can be recorded . There is no such thing as one hundred percent confidence. I’d your under that impression then you honestly have a lot more to learn. And the message they need could be a single sentence or a a couple, doubt 10,000 would be needed. But a whole conversation could be recorded. Incoming notifications with preview enabled could be recorded. What your saying provides no relevance and the ability to select multiple messages provides no more of an elevated threat model if other loopholes and functionality are in fact more of a vulnerability. Also this is for selecting multiple messages not for backups. There’s a difference but still programs like Cryptomator are able to client side encrypt. And moreover, at the end of the day your trusting a closed source iOS. So if your threat model is actually that high then you should be taking many more precautions then thinking you can tell users not to copy messages. Next.

[EgbertW]

Having this 'leak' means that someone gains access to your device that already has all the messages. Nothing is synced, and that shouldn't change. This person could then, after stealing your device and cracking your password, make an export and send it off to him/herself. In my opinion, if someone has already stolen your device and cracked your password, having an export function is the least of your concerns.

What Wire guarantees is that the message cannot be decrypted in transit to the recipients. It cannot give any guarantees on what happens after the recipients receive your message. To some extent, like @herrpoerner already mentioned, because Wire is open source. Additionaly, the recipient can do anything they want with it. Take screenshots, write it down, read it out and record it, make pictures with a camera and whatnot. You can't limit this at all, and Wire shouldn't attempt to do that because it will fail. Even more so, failed attempts to do so shouldn't stand in the way of useful features being added.

Now the use case why you would want this feature: you buy a new phone. You install Wire on your new phone, and you have an empty conversation list. All the nice features such as the media collection browser and searching chat history are quite pointless if you have no way of keeping your message history when you switch devices. Several of my contacts were very bummed out to find out that they lost their chat history when they got a new phone and had no way to restore it.

[cardassian-tailor]

We shouldn't introduce features to make data exfiltrations easier. That's a regression.

Prior chats don't sync on purpose. That's a feature. There's a wire notification telling you such.

Other clients have introduced features to make screencapping less successful and in some cases impossible (from the same device). Signal on android for example. To view images you have to press and hold the image - and if you are tapping the screen you are unable to capture a screenshot (not physical limitation rather an intentional code limitation).

If you want to sync or backup all your prior chats at the cost of privacy and security my suggestion would be to switch to other clients that already do as much. Facebook messenger, telegram, etc.

Wire had internal checks that determine if a modified client is being used to prevent malicious use and flags the client with possible imposed restrictions.

Lastly, users are typically upset when features that aid in preserving privacy are less understood. Try explaining to them these prior talking points.

[EgbertW]

Not syncing chats is not a feature, it's a consequence of E2E-encryption where messages are decrypted on the client - without having a key it's impossible to decrypt the message on a new device that gets its own encryption key. Even if messages were stored on the server, the new client wouldn't be able to decrypt them. An acceptable consequence.

What you are proposing is security through obscurity, which is no security at all. You cannot prevent someone from sharing the messages you send them. Ever. Accept that. If that is not acceptable, then don't send it in the first place.

Not having a way to (manually!) transfer your messages to a new device is not a privacy preserving deficit. It is a limiting factor that annoys people that generally already have a tendency to think 'I have nothing to hide'. With sufficient patience and explanation from my side I can maybe convince them that maybe they actually do have something to hide, but I cannot expect them to hand in severe usability features that other competing clients messengers have.

End-to-end-encryption and open source client (and hopefully server in the near future) are very strong assets of Wire. Lacking features due to unrealistic attempts to hide messages aren't.

Same thing for the timed messages, for example. Absolutely useless. If you don't want someone to share your information, don't give it to them at all. A self-destructing message achieves nothing else than confusion when it is unintentionally activated and messages start disappearing. For me, it is a peronall habit to make a screenshot when I encounter information on my phone that I would like to keep for future reference. Timed messages don't prevent me from doing that. Neither does having to tap'n'hold before showing them. I can still make the screenshot.

You can refer me to Telegram of Facebook messenger, but I might just as well refer you to Signal. If you make a scale between usability on the left and security on the right, you have Telegram on the far left and Signal on the far right. Wire has several other features where the trade-off between usability and security is not completely secure. Website previews, giphy-search, those kind of things. In my opinion, the balance is quite good in Wire.

And again: not having this feature is a lacking feature which does not give any added security - people can still share what you send them.

[wangkesen]

@MadEgg Thank you. Seems this is a hard concept to grasp.

[BellAppLab]

I think we're talking about two different concepts here: backup and archive.

Archiving content is about storing it somewhere for later use. A backup is about restoring a system to a previous state. An archive can be searchable and readable. A backup doesn't have to be.

Copying messages and pasting them somewhere else, or taking screenshots, can be used to archive messages for later use. But neither of those actions would allow you to put those messages back on Wire. They're outside of it now.

A backup would restore Wire to a certain state, to a certain snapshot. A newly installed instance of Wire would then be re-populated with messages.

One can easily take a screenshot of a conversation on Wire. But one can just as easily fabricate that screenshot on Photoshop or something. One can copy and paste messages, but then how can you prove those messages were produced by the original sender if they're somewhere else now?

Conversely, a backup of Wire would carry all that information with it.

So preventing messages from leaking out of Wire is one thing. Backups are another.

I don't know Wire's E2EE strategy well enough yet, but I'd assume it it uses asymmetric encryption as a minimum. This means that when Alice wants to send a message to Bob, Alice encrypts it with a key whose pair only Bob has, so only Bob can decrypt it. I'd also assume that only Alice has that key, so if John wants to send a message to Bob, he'd have to get his own key (in other words, messages are authenticated and it's harder for someone to impersonate Alice when communicating with Bob). Finally those keys should be refreshed every now and then so that even if a key is compromised, an attacker wouldn't be able to decrypt future message between Alice and Bob (forward secrecy).

All this, however, goes out the window if you back the whole conversation up and encrypt it with a password. Now Bob's conversations with Alice and John are both encrypted with the same key. Plus, they are now symmetrically encrypted (the same password encrypts and decrypts the backup), which is far less secure than asymmetric encryption. Once you know the key, you get all of Bob's conversations.

Mathematically speaking, you're far more likely to be able to brute force a symmetrically encrypted blob of data than an asymmetrically encrypted one, however well you encrypt it. So if someone gains access to your backup (because you exported it to Dropbox or something), all the effort to make conversations secure is useless.

[EgbertW]

Brute forcing is not relevant - the key lengths are sufficiently large to make that completely unfeasible, one way or the other.

You do realize that the data on your phone is, at best, symmetrically encrypted, right? My iPhone is encrypted using the passphrase I enter when I unlock my phone. If someone has that key, they can decrypt my data and that has the exact same consequence as decrypting a backup.

Wire could even enforce a generated, long and strong password when generating backups - there are plenty ways of making sure a transfer and storage is completely safe - as long as the key doesn't leak. For a backup, the risk is no larger than for your phone - assuming you don't store the key next to in in a text file named 'Backup decryption key.txt'.

In all circumstances the human factor is the biggest risk - if someone doesn't protect their data well enough, wherever it is stored, it may leak.

Should this stand in the way of the majorly useful feature of being able to transfer your chat history to a new device when your phone dies or is simply outdated? I don't think so.

I don't see any realistic attack path where having a encrypted backup poses an additional security risk as long as you don't share your key with anyone. The same holds for your phone where Wire is already installed on.

[BellAppLab]

@EgbertW As per your previous suggestion:

However, I would really like it if you have to option to generate a (encrypted / password protected) archive file of all conversations [...]

And:

Brute forcing is not relevant - the key lengths are sufficiently large to make that completely unfeasible, one way or the other.

If backups are to be encrypted with a user generated password, then key lengths won't be as large. Even if you generate a large key from a short user-generated key, you still only have the short key to crack once you know the key generation algorithm.

You do realize that the data on your phone is, at best, symmetrically encrypted, right? My iPhone is encrypted using the passphrase I enter when I unlock my phone. If someone has that key, they can decrypt my data and that has the exact same consequence as decrypting a backup.

This is true. So true that iOS employs strategies to avoid brute forcing the passphrase (limited number of attempts, increasing the retry interval and so on). A backup/archive stored in Dropbox or somewhere else is not bound by any rules. If an attacker has access to the backup, they can brute force it to their heart's content.

Even worse: once an attacker figures out the algorithm Wire uses to generate the backup encryption key, they can now apply the same logic to any other backups they find in the wild (no forward secrecy).

I don't see any realistic attack path where having a encrypted backup poses an additional security risk as long as you don't share your key with anyone. The same holds for your phone where Wire is already installed on.

This is not true. The power of an E2EE system is that messages between Alice and Bob are only accessible by Alice and Bob. If Alice archives Bob's messages, now there's a third entity that can read those messages: the archiver/unarchiver. If the archiving process employs less secure ways to encrypt content, then the system becomes less secure as a whole. All an attacker needs is to find the weakest link in the chain.

[EgbertW]

The main reason for iOS blocking after several attempts is that iOS by default asks you to provide a numeric pin of 4 digits. This is quite easy to brute force. I've taken additional measures against this by using a 13 character password.

Feel free to prove me wrong. Decrypt the following AES-256 encrypted base64 encoded piece of text, with 13 character password. Take as many attempts as you want. Brute force it to your heart's content.

U2FsdGVkX1/kxwRmFu89ssIZBXmJf8xmRYOaf0BJQWE=

In my opinion, the power of a E2EE system is that messages are encrypted all along the way from Alice to Bob, so that all the servers in between do not know the contents. After the message from Alice has reached Bob, both Bob and Alice know the contents and can do with that whatever they see fit. This may include forwarding (parts of) the conversation to someone else, making screen shots, taking pictures with their camera, writing it down in with a pencil in a notebook or whatever. Additionally, either Bob or Alice may well be using a PC or laptop to use Wire, which makes it even easier to copy the entire conversation.

There is absolutely no way at all to prevent either one from doing that. Even with the current state of things. So the only reason for not implementing a way to transfer chat history from one Wire device to another is to annoy users and make it less attractive for newcomers who've grown to use and love the backup feature included in other messengers, giving them another reason to not use Wire.

To make matters "worse": the Wire client and the crypto implementation is open source. Bob can just build his own version of the Wire client that sends all incoming messages in plain text using e-mail without SSL, and Alice may never know.

Wire should (and does) only make guarantees about the transport from Alice to Bob, and not about what Alice and Bob may or may not do afterwards.

[jullit31]

This feature has also been discussed in wireapp/wire-webapp#626 and apparently it "is in the plans and on a longer term roadmap".

[lbriais]

Many people already commented about the possibility to cut/paste, make screenshots, or even to build its own custom client that would automatically save everything on the fly...
There are many way to disclose the information contained in a conversation including for ephemeral ones. One point nevertheless needs to be emphasized. A screen-shot or a text log could never be a legal proof of anything, as anyone could easily forge it. Although it worth mentioning that probably a message copy doesn't have to be legally valid to potentially generate troubles...

As such I would say that the problem can be split into two with very different requirements:

• The export, which would then be a simple text (or pdf or whatever) export only used to keep track of old messages, that cannot be re-imported into Wire any more, and that cannot be used as a legal proof of something. Many people could probably easily accommodate with that, be it encrypted or not, to keep track of things they don't want personally to lose.
• The backup, which goal is to be eventually reloaded into another Wire device is more sensitive as containing maybe some keys or signatures validating its content, meaning it should be encrypted for "transport". This is most probably something like that people expect to address the use case of the new device (which I may very soon face due to the age of all my devices...).

Correct me if I'm wrong but without either this export or backup/reload feature, I can potentially lose my full history and my own messages while all the people, I ever discussed with, still have them...

There is a security trade-off clearly there, but it sounds acceptable because it is in the hands of the user. And losing all my history just because changing for a new device is definitely a show-stopper for real long-term use.

[assemhakmeh]

Hello,

I've read all the comments on this thread and the other. Everyone brings valid points. However, what we as users need is neither backup nor archive features. We need a transfer feature.

Basically allow the user to sign into a new device and then from a the old device perform a transfer messages to a specific device already on the account. This would in turn prompt and email confirmation of the request, and the confirmation would require you authenticate. Once the user confirms, the old device then encodes all messages with new device's public key and your wire password then send the blob to the new device. The new device can simply then import the messages and destroy the blob. Since the blob is transfer via the wire servers and encrypted E2E it is a safe as any other.

The only way this would broken is if an attacker had your old device with your sim, the new device, your wire credentials and access to your mailbox. If this is the case you've got much bigger problems. However, just having the old device and a new one would not compromise security.

This feature would enhance continuity for users as almost everyone today swaps phones every one to two years.

I would love to hear some comments on this or the up coming planned feature.

[gapop]

As one guy interested in this thread, I am very much interested in a backup feature, an archival solution that would enable me to keep my conversations in a format like HTML, completely independent of the Wire service and software. WhatsApp has this feature.

[mikeger]

Hey, we are working on the basic version of the back up creation and restoration, this should work in the following way:

1. Back up saves your database (text messages, chats, users) to the ZIP file.
2. When you log in you have an option to restore the database from the back up.

Known limitations: the database format is platform-specific. I hope this would help you folks to fix the basic issue of the device to device migration. If you have any questions or suggestions for this first implementation feel free to shoot them here.

[gapop]

@mikeger If the database could be something like unencrypted SQLite, that would at least allow me to write my own program to export to HTML.

[mikeger]

Yes, this should be possible. Don't forget to share it on GitHub, so others can benefit from it ⚡️

[aWeinzierl]

I really hope that a feature which enables keeping the history for new devices finds its way to wire.
It would be really disappointing if not, since for me it has big value.

Furthermore, I strongly agree with the following statement of @lbriais. Even with the backup and export solutions the risk of losing all messages is still there and a huge drawback. Also, I do not think one should pass the responsibility of maintaining a proper backup to the user. This would neither be a real solution nor reasonable, because it would never be on the most recent state and also quite a effort.

Correct me if I'm wrong but without either this export or backup/reload feature, I can potentially lose my full history and my own messages while all the people, I ever discussed with, still have them...
There is a security trade-off clearly there, but it sounds acceptable because it is in the hands of the user. And losing all my history just because changing for a new device is definitely a show-stopper for real long-term use.

[cardassian-tailor]

let’s clarify.

Messages are delivered to devices and not stored on wires servers.

When you export your chat details - your exporting only what has been delivered to that specific device.

This is probably a good assumption if you understand how wires infrastructure works.

Someone tell me this. Let’s assume both sides. Your account is compromised with both standings. The current setup and the backup/export option.

With the current standing - I have probably 50 thousand messages. If one message contains some information I don’t want public the intruder would have to spend weeks sorting through it all - giving me time to react.

The new export side - they export everything in minutes and sift through it on their own time.

Without proposing some preventive steps to prevent intrusion (we are assuming the intrusion here is a constant) how do you offer backup / export without the aforementioned problem.

Hint: you can’t.

The point is you can’t introduce backup / export without trade offs. This is a big big trade off.

@mikeger can you confirm if my assumption about message deliver and how backups will be structured above is accurate?

I would suggest seriously considering not incorporating backup/export - it comes with some really large risks.

However if it is implemented it should include the following:

• u2f hardware token support to further bolster account security. Backup requires u2f, import requires it too.

• When a backup/export is initiated - it IS NOT immediate. It starts a process. The first step when the backup/export process is started is it sends a message to all devices on the account stating an account backup/export has started. This is then delayed for 48 hours to give the owner of the account enough time to act if needed. This way if someone accesses your account and initiates a backup - you will see it occurring and have time to react.

• Backup/export should be documented on the users devices. You should be able to see in your account settings every time a backup/restore occurred.

@mikeger Lets assume I work for the government and every message I send is highly confidential. I want to OPT out entirely of account backup/export. Lets assume my account is compromised. How do i fully opt out? What is the functionality like?

[mikeger]

@cardassian-tailor your assumption about the message delivery is correct. The backup is going to persist only the messages that user has on their device. Furthermore, the necessity of the backup feature is coming from this: there is no way to migrate users history to the new device currently.

On your argument about the trade off: I agree that this is a strong argument, however having your device unlocked in the hands of third parties is already a big security risk. I would suggest using the ephemeral messages for the sensitive chats in this case.

We also considered re-authenticating the user using the pass code, touch or face ID when the back up must be created.

[cardassian-tailor]

@EgbertW @BellAppLab

Why have the developers gave so much effort to build a messaging platform that utilizes public key encryption with forward secrecy - and then add features that would make such encryption pointless?

@EgbertW If your assumption is that "we cant secure or control the end users you chat with, so theres no point in attempting to further control the message that have been delivered" ... why are we even attempting to use a secure messaging platform to begin with? From your assumptions - lets ask this:

• Why have ephemeral messaging at all? They can just write down the self deleting message, or screen shot it.

• If the messages can be hypothetically auto exported by the recipient, and we cant know the true state of either end once delivery has occurred - why go to so much trouble to utilize asymmetric encryption from the git go?

Some have said that the we should implement backup/export because users could screenshot messages or write them down anyways. Why then, do we trust ephemeral messaging?

Maybe stopping screen caps isn't possible, but there are other solutions to this - like notifying users when another user is utilizing screenshooting (there's a few apps that do this now) ... or rate limiting screen caps.

Backup/export features bring into play a lot of risk for users. When and if this "feature" is introduced - there will be users who will have to re-evaluate their current risk appetite and act accordingly. Have each of you given adequate consideration for those users who make strong use of the platform?

Lots of other platforms have taken steps to safeguard against account compromises - there's no reason why wire couldn't do the same. Rate limiting is one such step. An account password reset and backup/export request should not occur immediately (wait time of 48 hours) and when the process is initiated it should notify the crap out of the user so if the request is malicious the user has time to act.

u2f would be a huge improvement to account security.
Master key password (a second password that is required when wire is installed on any new device)
Steps taken to discourage the overuse of screen capping (like notifying the other users that your screen capping)

@mikeger I'm also assuming that this backup feature would totally negate forward secrecy... right?

[EgbertW]

@cardassian-tailor You are completely right about ephemeral messaging - it is pointless. I don't trust it and I don't use it. If I have some message that I want the other person not to retain, I don't send it. Period.

Use cases may vary. The reason for me to want a E2E encrypted service is because I don't want the service itself to have any knowledge about the contents. I don't want to be tracked or profiled based on this information. The recipients of my messages are people I trust with what I tell them, and I trust them to take responsible decisions about sharing copying or relaying the information I send them.

I use Wire as a personal messaging service to communicate with friends and relatives. I don't use it (or any other service) to leak information, plan terrorist attacks or coups to the government, transmit military intel or any other highly sensitive data. I understand that if you happen to be in a position where you do desire to use a service for this kind of messages, your requirements of security may be much higher than mine.

This also strongly relates to the desire for a backup / restore function. Personally, I don't care about my messages. I trash them all every now and then. My contacts however seem to have a bigger interest in maintaining a large load of text and media that aren't that interesting months after they've been sent. And an awful lot of other people seem to do the same, given the popularity of this feature in WhatsApp for example.

There already seems to be a tiered approach to security when you look at verification of your contacts - as long as you don't verify any of your contacts, you can communicate freely with them, even if they start using new devices. It's only when you verified them, communication with them is blocked in these situation.

Due to the varying use cases, maybe it would be a suitable solution to use a similar tiered approach here as well. It could be opt-in or opt-out on a conversation, contact or account level to only communicate with people that have compatible settings. So that if you really require that high level of certainty (which I personally still wouldn't trust given the possibility to create screenshots and such), you can enforce these settings when communicating with others. This would force your contacts to be unable to back up conversations with you, assuming they are using the app from the store, and not a custom built one. But that last part could be part of your personal verification process, of course.

[mikeger]

@cardassian-tailor
I agree to the argument that before it was not possible to extract the client database even having the full access to the device. However this is already not the case on any other platform. However I think that the forward secrecy does not apply in this context, since the backup is not the part of the messaging protocol. The contents of the backup would be just the plain text messages that the client has in it's database. It would not contain any cryptography-related information (no keys, no device verification information). Moreover, the backup can only be initiated by the app user. The user then is free to choose where to store the resulting archive. This definitely makes it possible to accidentally upload all your history to the insecure location, but this is up to the user.

[jullit31]

This definitely makes it possible to accidentally upload all your history to the insecure location, but this is up to the user.

Couldn't this be prevented by encrypting the backup and storing the key on the Wire servers? And when someone tries to restore a backup, the key gets requested and the user notified of that request. If no action is taken by the user within some delay period (i.e. 48 h), the key is then sent to the device.

[mikeger]

@jullit31 we cannot really store the passphrase on Wire server, since this would erase the benefits of the end to end encryption: Wire, if asked legally, can then recover the password for your backup.

[cardassian-tailor]

@jullit31 You never ever want to store keys on the service providers equipment. Who ever has the keys, has the kingdom. Plus, it would place them in a position to be legally required to hand over those keys and your data.

@EgbertW Remember that some users live in places where what you consider as normal is a crime worthy of capital punishment. Also, you may not be preforming acts of secrecy, but someone attacking you may be able to correlate just enough damage from your missteps to cause you harm from such features. Also, political climates shift with the wind. Actions and message details dont have to be legally questionable - they could merely cause damage to your character to which you cant recover.

I would also point out that the backup isn't entirely segregated to the device. Here is a scenario: you create an account, the account is compromised and the intruder adds a new device (so he receives constant updates of all messages). Months down the road from his device he creates a backup/export. There is some opportunity here for usability improvements. When a new device is added, a secret key is needed. Some password managers use this approach, another path with the same idea is simply to use u2f. When you install a new device to the account, the secret key / u2f is needed. This helps to ward off this attack scenario.

@mikeger I have a few thoughts/questions.

1) Do you know if the iOS API and swift have the ability to notify applications when a screen cap has occurred? If the wire application is open, and you are within a wire group chat called "_homework_" and the application notices a screen capture takes place - wouldn't it be common courtesy to send a message automatically from the device taking the screenshot to the active channel (homework) that a screen capture has occurred? Has this discussion occurred within the wire group already?

2) U2f would greatly improve user account security. Any plans to implement this? Secret key use for new device additions?

3) Will a user have any ability to fully opt out of backup/exports (including the ability to fully remove and never re-enable backup/export) ?

4) There should be an account notification that a new device has been added. Any plans for this? I dont think this already occurs ... maybe im wrong.

[jullit31]

@mikeger @cardassian-tailor Sorry, maybe what I wrote was a bit confusing. What I mean is to store _only_ the encryption key for the backup on the servers, not the backup itself, wich would still stay on the device (or rather, wherever the user chooses to store it). If the alternative is having an unencrypted backup, I can think of no situation where a key on the servers would be worse for security. Of course, as you already pointed out, in some cases it might not help either.
And if you don't trust Wire's encryption of the backup, there's nothing stopping you from encrypting it again with your own method.

[mikeger]

@jullit31 @cardassian-tailor we are looking into the backup encryption right now, the user must have the choice to provide the passphrase that would be used to encrypt the backup file. Then the same passphrase must be used to restore. Additionally if user has the app locking enabled, the iOS passcode, touch or face ID must be successfully re-authenticated before the backup can be created.

@cardassian-tailor on your points:

1. It is possible on iOS to know that the screenshot is taken, I am not sure if this can protect the device, since user can also rewrite the homework from that chat, or use another device to capture the screen of this one with the camera. We have no plans currently to implement the screenshot detection.

2. We have no plans of implementing the U2F, we are however looking into authenticating the new devices from the old ones (building the chain of authentication). This partially answers your question number 4.

3. There would be no way to do it with the first release, however with the next coming ones if this would be something that would be requested frequently (I cannot really strictly define this, most likely if the paying customers would be requesting this) we can implement it, however it is also pretty tricky, since to toggle such a flag the authentication would be necessary.

4. There is a notification about the new device: the account icon gets the dot and if you open the account screen you should see the alert suggesting to proceed with the verification process for the new device.

I hope my answers are addressing your concerns.

[espadrine]

This thread reminds me of the Pavel Durov article Why Isn’t Telegram End-to-End Encrypted by Default? http://telegra.ph/Why-Isnt-Telegram-End-to-End-Encrypted-by-Default-08-14

Messaging apps that ignore backups… never reach 1M DAU and remain niche.

I dislike Telegram’s solution to have two systems.

I also disfavour manual backups, which is what you are suggesting IIUC.

What is desirable:

• Seamless streaming server-side storage,
• Inability for the server to read content.

It requires content to be encrypted on servers and the key to be shared between devices. That in turn can be achieved in two possible ways, the latter being the clear winner:

1. Using the user’s password. It is flawed, as it requires asking for it when opening the app, and keeping it in memory in some form. Also, it forces the device to reencrypt everything upon password change.
2. Adding a pairing step upon device addition which transmits a secret generated on the first device from an old device to the new. It does have the drawback that the loss of all devices cause the loss of the backup, but that occurrence is uncommon. Device revocation, on the other hand, would however require resetting the secret and reencrypting everything. To communicate the new secret to other devices asynchronously, you can encrypt it asymmetrically with the other devices' public keys and store that in the server. When other devices log back in, they'll get and decrypt the new secret.

[electrofloat]

Unfortunately this will never be implemented:
https://medium.com/@wireapp/history-backup-comes-to-wire-cd79e02ec66e

[mikeger]

@mydexterid this is not necessary the conclusion, current implementation may be potentially changed in the future. We are considering all the proposals received from the variety of channels, also from the GitHub.

[EgbertW]

@mikeger a question about the current backup: the post at medium.com states it does not include media but only the links to these media. Does that mean that media is stored indefinitely on Wire servers? I was under the impression that messages and media were only stored for 30 days on Wire servers, or until fetched by all recipients.

[mikeger]

It's slightly more complicated than just messages, let me try to explain.

• When we send the normal message we are using the end-to-end encryption, so each message is encrypted with the new key that is generated either using the HKDF or with the Diffie-Hellman mechanism.
• The end to end encrypted messages are stored for the 30 days.
• This messages (decryprted) are included in the backup.
• When we send the assets (images, files, longer text messages) we generate the random (symmetric) encryption key and encrypt the asset with it, then upload it to the backend.
• The symmetrically encrypted asset blobs are stored on the Wire backend for the longer time, more than 1 year currently.

So your client can clear the caches, but if it still maintain the reference to the blob and the symmetric key it's possible to re-fetch the assets. For the moment there is no mechanism in place to fetch all those assets and back them up, therefore we most likely are not going to be deleting those assets until the mechanism is in place.

[Sigmun]

For many reasons described in #626 and #770, please consider a cross-platform backup, at least for non-encrypted backups, even from/to iOS (users are responsible of there own backups).

[metal450]

Do we have any idea on the progress/ETA for being able to do complete backups (including media/assets)? This is the one thing blocking me from getting started with Wire. For (hopefully) obvious reasons, I need to be sure it's actually possible to keep backups of complete chat data, not just partial (i.e. full context including assets) before I can really feel comfortable moving over all my communications.

[tredondo]

@cardassian-tailor

You've yet to provide any use case for why a user would need to backup or export their chats.

I want to be able to search among my chats, which I store in an encrypted container (e.g. VeraCrypt). I've used Pidgin-OTR for years, and have amassed large quantities of chats. Pidgin logs them in HTML, and searching is painless. I understand why a messaging client would not log by default, but I'm a power user, and if I want to log chats into an encrypted location, please let me do so.

@Sigmun - on Linux, the backup from Wire desktop is a ZIP archive containing three unencrpyted .JSON files. Is the backup format different on other platforms?