Utilize POST and GET requests

[alexanderepstein]

Would love to be able to use this with curl or httpie from the command line
Uploading files would look something like:

curl -A curl -X POST @myFilePath "https://api.send.firefox.com" # with curl
wget --post-file=myFilePath "https://api.send.firefox.com" # with wget
http -f "myFilePath" POST "https://api.send.firefox.com" # with httpie

It should return the download url to be sent out to others.

Downloading files would look something like:

curl -A curl -X GET -o downloadFilePath "https://api.send.firefox.com/id1/id2" # with curl
wget -O downloadFilePath "https://api.send.firefox.com/id1/id2" # with wget

Anyways this project looks awesome 👍

[abdulhannanali]

@alexanderepstein Seems like this uses some browser specific functions such as getting the data and converting this to a blob and that hash part at end of the url like this one https://send.firefox.com/download/eb15ba98f5/#jvSuPGAVMY2914X_dC__sg is important for the link to be decrypted properly. This is not going to be possible using curl, however a specific node utility can be used to give a shot at it.

[abdulhannanali]

By passing a link like the one you are demonstrating here, you are implying that the file is encrypted at the server side and decrypted there too, but that's not the case every thing is done on the client side, and the data travels in an encrypted state on the wire. This is what makes this project cool 😄

[HLFH]

transfer.sh has the curl feature btw.
It would be great for Mozilla Send to support command line use cases.

[ehuggett]

The comments up to this point do seem to have missed the point about the data being encrypted by the client, but "non-hosted clients" would be a very significant improvement to the security of the file transfer if both parties used it and they are possible.

I would like to think if a 3rd party service such as Pocket can end up integrated into my browser then a Send client would have a fighting chance (biased personal opinion of course, as I have no interest in pocket and would actually rather use Send in this way, but I think the point is still valid).

For fun, I did try to write a python client the other day. I wanted files uploaded by my client to be retrievable with the web client so I started with downloading files (uploaded by the web client). I got as far as fetching the encrypted files and attempting to decrypt them (dev snapshot of pycrypto required to get aes-gcm), but I'm clearly not decoding the key and IV correctly yet. Uploading files would just be a case of doing the opposite and posting it to the server and printing the download url (although I would have to include the potentially superfluous SHA256 checksum, due to gcm mode, for the web client not to error out).

If the receiver does not have a client (they may have one without knowing it with Firefox integration) or know what send is, they would just load in in their browser and use the hosted client as normal.

Without a stable interface, this could obviously brake at any time and if it happens in such a way as it appears to upload successfully (ie change of key length) the receiver would probably blame the Send service, not knowing the sender used an unofficial client.

edit: No idea how git-hub behaves when commenting on closed issues, I would appreciate a refusal to re-open the issue if its still considered undesirable so I don't wait a fortnight . Thanks 😄

[abdulhannanali]

@ehuggett Yeah! I am up for writing a client for node.js users, in order to decrypt the files. I was looking at the Open Sourced Code for Mega.nz which is a cloud storage platform with end to end encryption. It's web client seems a lot similar as it's also utilizing javascript, to decrypt the applications over the web. So it's possible but since the issue opener's point was to just curl it that isn't possible. I did mention that there can be a CLI tool to decrypt these.

[ehuggett]

If you know how they encrypted data AND filenames, if they did that, I would be really grateful if you could leave a comment with some links or hints about how they went about it in #417 or #69 . Doing something like TAR inside the encrypted data would make it impossible for the client to display the filename before it starts to download it (and the service deletes the file), so it looks necessary to store it separately but perhaps it could still be encrypted and decrypted only by the client by re-using the file encryption key, a new IV can be used as I think its safe to expose them(!?) and one is already stored by the server for the data. Some prior art would be great!

Sorry I inadvertently suggested you had missed the issue with curl/wget! (although a shell script client using them should also be possible, presumably using openssl?)

[JayBrown]

Needs something like what megatools is for mega.nz.

[ehuggett]

I have a working collection of python scripts for download/decrypt/encrypt/upload, compatible with the browser/js send client (browser can download python uploads and vice versa), but I am very hesitant to share it at this stage as it does many dangerous things (such as not sanitizing inputs, from the user or the server/uploader).

However, for the time being, The following should be of help to anyone attempting this themselves

• The key is JWK. In this case specific case, an unpadded urlsafe base64 string (fix padding and use urlsafe_b64decode to get the raw key/ strip padding after encoding)
• the "id" from the X-File-Metadata header is the hex encoded IV (i.e. use bytes.fromhex() )
• The last 16 bytes of the encrypted file is the gcm 'tag' needed to verify the decrypted data, make sure you use it (and strip it off of the data before decrypting).

[ehuggett]

I've made it available at https://github.com/ehuggett/send-cli

Watch out, it still has sharp edges such as

• overwriting any existing file without additional warning if you accept one as the download name
• uses a huge amount of memory when handling large files (much like the official client!)
• your probably going to need to install at least pycryptodomex with pip3, sorry, i don't think its avoidable at the moment? (pycrypto only has AES GCM in a preview release, which i was using initially)
• No error handling, not even http status codes.
• not an exhaustive list, expect serious issues (such as data loss) if precautions are not taken

And plenty of missing features

• no ability to delete uploaded files (just need to print the delete token and add an option to send it)
• no progress information for encryption/transfer
• send urls MUST be quoted at the moment if the key contains "-" characters
• can't read from standard input nor write to standard output
• and more

Issues for bugs/features/using classes are very welcome, but pull requests more so 😄

edit: Its a lot more usable now, temp files have massive reduced memory consumption for large files (and progress bars have been added)