Desktop as secondary device without camera

Mutual Help
1

General Description
I want to add my desktop that does not have a camera no WiFi, and it is on an isolated cable-only network, as the secondary device to my mobile DeltaChat client. It seems both camera and WiFi are hard requirement, but majority of the desktop computers I have encountered during the past 38 years do not have a webcam nor wifi interface.

I think it is natural to want to have the desktop as the secondary of the mobile rather than the mobile as the secondary of the desktop.

This is somewhat distantly related to the following threads:

Delta Chat version

Android Delta Chat: 2.22.0 (F-droid)
Delta Chat Desktop: 2.22.0 (git: flathub)

Expected behavior

Having a way to add the desktop client as secondary without needing to scan QR code (e.g., by copy-pasting the QR code sring, or OTP, or some other secure method.

Actual behavior

My computer does not have a camera (and no WiFi either, which is another requirement here). so I get the error in the screenshot section.

Steps to reproduce the problem

  1. install DeltaChat on the phone
  2. create an account on a Chatmail relay
  3. install DeltaChat on desktop (using Flatpak)
  4. try to add the desktop client as secondary to the mobile client

Screen snapshots

image
image992Ă—859 83.9 KB

Debug logs
– not applicable –

1 Like
2

It seems both camera and WiFi are hard requirement

no, they are not hard requirements.

setting up second device without a camera and without wifi is described at FAQ - Delta Chat (linked via “Troubleshooting” button)

if you have wifi, but no camera, you can also try to copy+paste the QR code

1 Like
3

Thanks, I had a hunch that I have to rely on such messy work-around. It is extremely inconvenient and insecure approach though, because the sqlite is saved without any encryption and password. I did it that way, but I had to do some manual work to securely transfer the backup file to the destination machine.

If you don’t mind me saying, imho, this does not sound like a solution, but rather a relatively messy work-around. A proper solution would be something akin to transferring the information that QR code is suppose to convey rather than relying on taking a backup and transferring it. As you might already know, generating and transferring backup can get problematic [example].

I don’t know where is the best place to propose this, but I believe the short-term best approach is to encrypt the tar backup file based on symmetric encryption. For example:

  1. Delta Chat client can ask for a password
  2. generate tar file
  3. symmetrically encrypt it 
    tar czf - file1.txt file2.pdf file3.jpg \
 | gpg --symmetric --cipher-algo aes256 -o backup-file.tar.gz
  4. tell the user where to find the backup file
  5. user transfers it to the other computer (e.g., via email or a messenger or magic-wormhole)
  6. on Desktop client user give the backup file to the client
  7. Desktop client asks for the encryption password
  8. the Desktop client open the backup, do what it is supposed to do to set things up
  9. upon success, inform user to delete the backup from their phone and their computer and their messenger

This is how Signal also handles transferring the backup as far as I can remember.

Of course it would extra good if the Delta Chat can internally handle uploading to magic wormhole, but that’s a discussion for another day.

4

Chatmail core already supports setting a password for backup encryption, but it is not implemented in the UIs yet. https://js.jsonrpc.delta.chat/classes/RawClient.html#importbackup-1

QR code contains information that is used by https://www.iroh.computer to establish the encrypted peer to peer connection between devices to transfer the backup.

Iroh can do networked transfers, but we only enabled local network transfers - and AFAIK there are no plans of changing it, since networked second device setup were used in an attack against signal users, so we didn’t want to repeat that vulnerability. But maybe there are new arguments or facts that could change the decision to restrict backup transfer to local network.

5

Thanks for the clarification and link to RawClient. I am actually thinking about feasibility of writing a DeltaChat client for Emacs, and this link can be very handy.

Regarding encryption, I would argue that it is a vulnerability, not from coding perspective, but from the work-flow perspective. User is left in charge of transferring clear-text backup from one device to another, and most users don’t know good security and privacy practices. @r10s Would it be possible to re-open/re-visit this issue?

6

if you don’t even trust your phone when creating a backup to its Download folder, what is the point then??? at that point your keyboard could be logging keys, your whole screen could be recorded/tracked, etc.

I don’t recommend you to upload the file over some random internet service even if it has some password, you don’t know how easy it will be to break that password with brute force in some future, just copy it to some USB stick or connect your phone to the computer via USB cable and transfer the backup to the computer offline then, given the constrained situation of your PC not being in the same local network than the phone

7

Thanks for your comment. I think I failed to convey what I had in mind. I’ll try to explain my point by breaking your comment into parts and elaborate on each of them separately:

You completely misunderstood my point and my comment. I didn’t said I don’t trust my phone, but why not entertain the idea: quite many apps have access to the Download folder, from browser to banking apps, office and note taking tools, and etc. So saving anything in clear-text in any of this publicly accessible directories is already a bad and risky move.

And that’s exactly what currently the user is forced/left to do. If DeltaChat does not provide a safe way for the user to transfer the file, then 99% of users will use “some random internet service”, being email, cloud storage, other messenger apps, or etc. to transfer the files. On top of that, the current backup file is not encrypted in any shape or form, meaning all those users are practically in a vulnerable state if they are not themselves managing the encryption and taking care of their own OpSec.

imho, ideally DeltaChat should:

  1. encrypt the backup from the get-go (even the weakest symmetric encryption is way better than clear-text)
  2. facilitate the backup transfer through a throw-away adhoc account from a trusted relay, as they are relay and don’t store the files for long (or at least provide the option to the user)
  3. Give the option to the user to create a “lean backup”, meaning that it only contain the session information and do not contain any messages or pictures. This would make the entire transfer work-flow faster and easier and reduce the possibility of data leakage.

I’m not a tin-foil-hat person, but I for one never connect any two devices via normal USB cable. I always have the assumption that either device could have been already compromised, and USB connection can transmit the infection. I even don’t use normal USB cable to connect my phone to the charger, and I exclusively use datablocker cables. IMO good security practices generally doesn’t hurt :nerd_face:

Regardless, thank you for your kind comment and investing some time to provide your insights.

8

apps can’t randomly access the download folder since several Android versions, file managers apps need a special permission you have to grant, bank apps don’t need full storage access permission like file managers, others will have more constrained permissions, and use another API for allowing importing/exporting files into the app via user explicitly selecting the file they want to feed to the app etc., even for apps that you granted full access to the download folder, you can go and revoke the permission

for more info about shared storage read: