search

timvisee / send

:mailbox_with_mail: Simple, private file sharing. Mirror of https://gitlab.com/timvisee/send
https://send.vis.ee
Mozilla Public License 2.0
4.78k stars 276 forks source link

Shlink integration suggestion (link shortening) #46

Open widestorm opened 3 years ago

widestorm commented 3 years ago

Tracking issue: https://gitlab.com/timvisee/send/-/issues/21

An integration with shlink (https://shlink.io/documentation/api-docs/) would be very useful. It would be helpful for automatically shortening links for input on a client computer where QR-codes aren't easily readable.

As I don't have much programming experience myself at all I don't know if it would be reasonably doable, although the api seems to be pretty well documented.

Feel free to close this again if there's no plan to add this or something similar.

timvisee commented 3 years ago

Thanks for the idea.

It is however not a good thing to implement this, simply because it breaks end-to-end encryption. The encryption key is stored in the share URL. When shortening the URL, you're giving the secret key to the link shortener which is not desirable.

There's a catch though, ffsend (a CLI for Send) does have this feature implemented with the --shorten flag.

I hope you understand why I won't be implementing this.

widestorm commented 3 years ago

Thanks for the quick answer, although giving the key to a link shortener that is self hosted on my end doesn't seem like such a big problem. Thanks for the hint about the ffsend flag! 👍

timvisee commented 3 years ago

Even if you self-host, it still breaks end-to-end encryption. But yes that may be a risk you can accept.

How do you imagine this feature to look like? A shorten button when a file is uploaded, or shorten all share URLs by default based on a configuration property? I assume you'd like to see this for a self hosted Send instance as well.

widestorm commented 3 years ago

Since it would just redirect to the original URL wouldn't it work just like it did before?

That would probably be the easiest option, after you're presented with the link adding an additional button to shorten it through the link shortener. And then you're presented with the shortened version below. The link shortener then manages the redirection and the original send link stays the same.

In this case it won't break the original url with the decryption key and the shortened version still would be quite difficult to guess since this and most other link shortener services are case sensitive.

widestorm commented 3 years ago

See this as an example: https://link.*****.ch/MA6X

I manually shortened it after I got the original send link. image

timvisee commented 3 years ago

Oh yes, this is definitely something that works. I meant to say that this breaks end-to-end encryption from a security standpoint.

To better describe why this is the case: You want the uploading and the downloading user to be an 'end', with no possibility for a third party in between to read your files. When using a link shortener, the shortener gets to know the secret key, essentially breaking this concept. Yet again, even though this breaks end-to-end encryption from a security standpoint, it does still work and it might be a risk you can accept.

In any case, I'd be fine with it to get it implemented behind a configuration property. I'm quite busy the upcoming weeks though, so I'm not sure when I have time to implement this. You mentioned that you don't have much programming experience, feel free to give implementing part of it a try and ask for help here. If there's anybody else who'd like to give it a go, please do!

timvisee commented 3 years ago

I've added an implementation issue for this over on GitLab: https://gitlab.com/timvisee/send/-/issues/21

t3dium commented 1 year ago

The encryption key is stored in the share URL. When shortening the URL, you're giving the secret key to the link shortener which is not desirable.

Would this still be still be an issue if putting a password on the send?