Fileber

Appearance

Trust issue ​

Trust is one of the biggest challenge for Fileber: How can the users trust that their files remain secured and private when being sent via Fileber?

Context ​

As mentioned in WebSocket for now, Fileber is using a WebSocket server to relay the file transfers. But even when not using WebSocket, any 2 devices that are under Symmetric NAT can only communicate through a relay server.

So how can users trust that:

  1. Their file data cannot be obtained by external parties?
  2. The relay server does not store their file data?

TLS ​

Assuming the relay server is faithful and does not store any user's file, TLS is a solid measure to ensure that no parties other than Fileber and the receivers can read your data.

Currently, Fileber is already using TLS to secure the connection between your browser and Fileber:

  • Fileber is being served via HTTPS
  • File transfer is done via WSS (Secure Web Socket)

So the first concern is not much of an issue with Fileber.

However, it is hard for users to trust that Fileber is faithful, and this (the second concern) remains a big challenge.

"Trust me bro" ​

Fileber does not store any data into its persistent storage (SSD). It only holds a few chunks of your file data before those chunks are delivered to their destinations.

It would otherwise be really costly for me to store your data.

Right now I'm only using a single VPS with 1GB of RAM and 25GB of Storage.

End-to-end encryption ​

In Roadmap

End-to-end encryption is not implemented yet, but it is a feature in the Roadmap.

One way to make sure the server cannot read the data is to have an end-to-end (E2E) encryption, and it can be implemented this way:

  1. The host generates an encryption key and put it in the hash fragment of the room's URL.
  • Example: https://fileber.com/ZFcUnHqGwrFnHrdBEbNZnG#iMG4MqvWi8zVfvkfKabyEr, where
    • ZFcUnHqGwrFnHrdBEbNZnG is the room ID
    • iMG4MqvWi8zVfvkfKabyEr is the encryption key
  1. The host shares the full URL with peers.
  2. Host and peers encrypt their data using the encryption key before sending, and decrypt the data upon receiving.

By putting the encryption key in the hash fragment, the encryption key is not sent to Fileber server, and hence Fileber cannot decrypt the data being transferred.

However, users still need to trust that the Fileber app never sends the encryption key to the server.
One could technically investigate the network payloads or frontend code to check, but

  • Checking is not straightforward.
  • And even if the app is checked to be faithful right now, there is no guarantee that the app stays faithful forever.

Nevertheless, E2E encryption is still a good security measure and I'm planning to implement it soon.

Open Source ​

When an app is open source, users can inspect the source code to check whether the app is faithful or not.

However, there is no guarantee that the app that is deployed and served to users uses the same source code as the open-sourced code. One could try to compare the builds, but it gets tricky when dynamic stuff like environment variables are involved.

Nevertheless, even if not 100%, open source code can still gain a lot of trust, so I'm still considering this option.

Security Vendor ​

Another option is to pay for Security Vendors to audit the app. Though I'm not planning to make such investment any time soon.