Shlink integration suggestion (link shortening) about send

[timvisee]

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]

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]

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]

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]

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

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

[timvisee]

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]

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

[t3dium]

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?