Making file share links shorter

[DisboxApp]

We would probably want the server to keep a shortened form, but that would require it to have access to the files.
Maybe this could be okay because shared files are already kind of public.

We could also solve this with automatic URL shortening using a 3rd party.

Which solution do you think is better?

[pinkosushi]

Automatic URL shortening would be good.

[GraderGamer2]

Using a 3rd party to make it shorter is a good idea, I'm guessing it also has access to the files but only for the identifiers and metadata(?).

[DisboxApp]

(Getting the identifiers means it can access the files themselves)

[shadpers]

Hello there! I've been using your awesome code and this is the only critical negative point about, i'm agree with the server acessing the files to keep the url short as long a pop up warns the user about it when sharing, and as you said, sharing the file kinda make it public, the automatic 3rd party shortening ideia is good too, i'm on it.

Here some info i've got after some research and tests, github maximum link lenght is 8201 characters, please note that most browsers doesn't support such long link's, i've tested with Opera/Chrome and they work fine, using 7zip to split files in 1600MB (1677721600 bytes) parts you get links with around 8000 characters. I'm using this workaround until the devs comes up with something, much luv u all.

[DisboxApp]

I've thought about this for a while and I want to dump some ideas here, no complete solution yet, but open to suggestions:

• Using a URL shortener doesn't really solve the issue. It won't raise an error when sharing, but when the shortened URL is accessed and "resolved" to the full URL, it will still be too long. The actual attachment URLs (which are needed to access the file) just can't be stored on the URL.
• This means the attachment URLs for shared files will need to be stored in a separate table in the Disbox server. This, however gives access to the server to shared files.

Here are the options I've thought of so far:
Option 1: Show a pop up when sharing that it makes your file less secure and you can read about it more here (with a link to this discussion).
Option 2:

1. Encrypt the attachment URLs with a an AES key generated on the client. Then send the encrypted result to be stored in the server.
2. Make the sharing URL contain a shared_file_id and a file_key (which will be the AES key). Then, when the shared file is downloaded, the encrypted attachment URLs will be sent to the client and decrypted on the client side.

Option 2 solves the issue better, but has a problem.
Storing the AES key in a URL query param makes it so the server can access it (even if it doesn't use it) - so we would have to put in the fragment section of the URL (after the #) which isn't sent to the server and can only be used in the client.
However, I'm still not sure it's secure. It was asked here but I'm still looking for more sources: https://stackoverflow.com/questions/20757583/how-secure-is-it-to-use-fragment-identifiers-to-hold-private-data-in-urls

[tris203]

I think I have a even better solution, what if we use Gzip encryption to shorten the array of URLs.

I have also combined this with removing the params from the returned URLs, as they dont seem to do anything? Will bow to your better judgement as you know the Discord API better than I do.

But in my tests on a 1GB file (21 chunks)

We reduce the URL length by a almost a factor of 10

The effect isn't as good for lower number files but it still works:

1 chunk file:

3 chunk file:

So savings all across the board

CodeSandbox here:
https://codesandbox.io/p/sandbox/competent-williamson-c284mz

Depending on feedback, I will build into the repo and submit a PR

[DisboxApp]

Sounds like a good idea.
This doesn't completely solve the problem but it has no downsides.

Will continue discussion in #60.

[tris203]

Submited in #60

[tris203]

https://discord.com/channels/613425648685547541/697138785317814292/1157372186160537750

potentially an issue further down the line, we may need to keep the params, but it will work for now