Re: Easy, encrypted transfer of larger files over third party server
- Date: Wed, 04 Oct 2017 01:58:43 +0200
- From: Sandro Knauß <sknauss@xxxxxxx>
- Subject: Re: Easy, encrypted transfer of larger files over third party server
why using a third-party server if you can directly share a file form your
computer securely without any size limit? OnionShare creates a tor hidden
service and this you can share and the other can download the file directly
via tor for your computer.
At least for many usecases it is also a nice solution, where you don't need a
server to upload the file. The person who is receiving the files doesn't need
OnionShare. All they need is to open the URL you send them in Tor Browser to
be able to download the file.
On Dienstag, 3. Oktober 2017 23:45:53 CEST Albert Astals Cid wrote:
> El dimarts, 3 d’octubre de 2017, a les 13:36:47 CEST, gregor.mi.sw va
> > Hello,
> > since the day I started to use email, every now and then I would like to
> > send someone a large file (big or several images, large presentation,
> > audio
> > or video file) that does not fit in an email or vice-versa.
> > Nowadays, there are plenty of free online storages and transfer services
> > (e.g. https://wetransfer.com/, DropBox etc.). If I don't know the owner of
> > those services, from a privacy standpoint they all cannot be trusted.
> > I would like to hear your opinion on the following idea:
> > Why not having a local program for the sender and receiver that
> > automatically does local encryption before uploading to a storage server
> > and decryption upon receiving and then deleting from the remote storage
> > server? The idea is to have a stable local user interface while the
> > storage
> > server (let's call it "exchange point") can be easily replaced when
> > needed.
> > The assumed exchange point capabilities should be minimal (list files,
> > upload file, download file, delete file).
> > (The exchange point could even be an IMAP email server (with shared
> > credentials) which means the local program should know about maximum email
> > attachment file sizes and split the file accordingly without bothering the
> > user. Or a local network drive.)
> > The basic workflow for two new users A and B would be:
> > User A: Installs the program, setups an exchange point, sends B the
> > configuration to the exchange point, uploads the file
> > User B: Installs the program, imports the configuration, downloads the
> > file.
> > Once the exchange point configuration is shared, sending further files is
> > only a matter of selecting the user and dropping the file. Since the
> > program would have a CLI it could be integrated in other chat or email
> > programs.
> > About two years ago, I started to develop a program that should do exactly
> > that. It's called "asr - async send receive" (Code:
> > https://cgit.kde.org/scratch/gregormi/asr.git/tree/, some thoughts about
> > it:
> > https://github.com/feinstaub/feinstaub.github.io/blob/master/asr/index.md,
> > "async" because sender and receiver should not be required to be online at
> > the same time). Due to lack of dedicated time the development also came to
> > a stop two years ago before I could refine the CLI and add a usable GUI.
> > I am aware of this good new feature in NextCloud:
> > https://nextcloud.com/blog/nextcloud-introducing-native-integrated-end-to-> > en d-encryption/. But this would restrict online storage servers to those
> > which have NextCloud installed.
> > From the server side's perspective, this could be a security nightmare
> > because one way of using a service like Dropbox as exchange point is to
> > share the account credentials between sender and receiver. From the user's
> > perspective, in case the used account is shut off, one can switch easily
> > to
> > another exchange point.
> > Target users: users who want to securely exchange files but without the
> > knowledge or resources of how to setup an own online server.
> > I wonder if it makes sense to you to further pursue this idea. Are or were
> > there maybe similar approaches?
> Not sure if https://send.firefox.com/ may be something you may be interested
> in? Maybe a command line client for it?
> > Or existing online services that also do
> > encryption in trustable fashion and have a CLI?
> > Thanks for your feedback.
> > Gregor