221–230 of 542 posts
For certain reasons I get a ton of dropbox space, but for my friends, data quotas kick in on even simple files shared like this.
I believe this is a primary upgrade mechanism for DB--I'd say this new firefox offer is in competish.
Earlier quoted context omitted.
Tangentially related - I've always thought it's dumb that I can't just plug my iPhone in to any PC and have it show up as a removable storage device. I'm sure people who know more than me will give me a list of great reasons why it's not straightforward to implement... But it doesn't change the fact that I have this incredible device (iPhone X) with 256gb of blindingly fast NAND flash storage, of which I am only util…
I regularly do this to offload pictures and movies. I have even used my iPhone as a large USB drive. But, they don’t let you access to full file system for some reason.
I've been building a fully featured CLI tool for Firefox Send, supporting this new release. For anyone that is interested: https://github.com/timvisee/ffsend
FWIW, I built and successfully ran it on FreeBSD-current. The only hiccup I ran into was that it puked building due to not having /usr/local/lib in its lib search path & not being able to find libxcb. I had to manually add -L/usr/local/lib to the cc args and manually link it. Not sure if that is a FreeBSD issue w/Rust, or something in your package. At any rate, the tool works! Thanks so much.
Earlier quoted context omitted.
The conspiracy theorist in me wonders if Google simply wants to maximize the use of their servers here (independent of what users want/need): 1. P2P doesn’t give Google all that juicy mineable data that they get when everything you do makes round trips through their servers. 2. This would also implicitly encourage Android users to rely more on services like Google Drive/Docs for all files, which is good for them. Edi…
In addition to NUMEROUS 3rd party tools, Google already provides a tool exactly like AirDrop for Android. It's a feature of the Files app https://play.google.com/store/apps/details?id=com.google.and... which has over 100M installs. Look at the 3rd screenshot. ENCRYPTED FILE SHARING Files’s offline file sharing is secured with WPA2 encryption, providing a more secure file transfer. Files app uses Bluetooth to set up e…
I don't understand the end-to-end encryption claim. 1. Bob uploads a file, but specifies no password. 2. ??? 3. Sue downloads the file. Best case, Bob's browser encrypts it (with javascript?) before uploading. Either Mozilla provides a key, or Bob sends the key he used. When Sue's browser downloads it, Mozilla sends the key and her browser decrypts it client side. In either case, Mozilla has the password for decrypti…
The client encrypts the file that is uploaded, along with some metadata. The key is appended to the share URL provided by the URL, in the fragment/hash, and is never sent to the remote server. Only people having the URL including the secret will be able to download and decrypt your shared file. See https://github.com/mozilla/send/blob/master/docs/encryption....
Browsers don't send the anchor tag (ie: with GET requests). FF Send takes advantage of this by using the anchor tag to store the key for decryption.
That is kinda novel. You still need to trust the upload client to not leak the key, but I see that you've written a CLI version. Interesting! Thanks for the response.
Why not "Mozilla Send"? If Firefox the browser isn't a requirement, the name is confusing.
The same reason it's Chromecast, not Googlecast.[1] Branding. [1] The protocol is named Google Cast, but all the consumer branding is Chromecast.
Earlier quoted context omitted.
The client encrypts the file that is uploaded, along with some metadata. The key is appended to the share URL provided by the URL, in the fragment/hash, and is never sent to the remote server. Only people having the URL including the secret will be able to download and decrypt your shared file. See https://github.com/mozilla/send/blob/master/docs/encryption....
Thanks for the info. Let me see if I understand this correctly. Browsers don't send the anchor tag (ie: with GET requests). FF Send takes advantage of this by using the anchor tag to store the key for decryption. That is kinda novel. You still need to trust the upload client to not leak the key, but I see that you've written a CLI version. Interesting! Thanks for the response.
Earlier quoted context omitted.
Does the link expire after a successful transfer? Curious what happens if the transfer fails mid transfer and needs a retry.
No one I've tried it with has ever had it fail on them. But to answer your question, I uploaded a 100mb+ file to FireFox Send, copied the link, RDPd into another computer, kicked off the download, and then cancelled it midway through download. The link did expire after that. So I guess they don't have an easy way of telling whether the download is successful or not. Maybe Mozilla's engineers can figure something out…
Earlier quoted context omitted.
Thanks for sharing your solution! Not sure what is causing it (maybe it's OpenSSL binding related), and am currently not really targeting FreeBSD yet. I wasn't fully ready with this tool for the Firefox Send release to be honest, would have loved to be able to provide better binaries and packages for more platforms, which are a work in progress. If you believe you can improve the README with your solution, be sure to…
It's a BSD world thing :). Local (i.e. non-system) executables and libraries go under /usr/local around here (i.e. libraries under /usr/local/lib, binaries under /usr/local/bin and so on, the hierarchy under /usr/local has the same structure as that under /usr).
cat ~/.cargo/config
[target.x86_64-unknown-freebsd]
linker = "/home/drewg123/bin/cargo-ld"
#!/bin/sh
exec /usr/bin/ld -L/usr/local/lib $*Earlier quoted context omitted.
MTP is a horrible protocol which renders the abstraction very leaky in my experience, to the extent that it's inaccurate to refer to it as "removable storage" and expect to behave in similarly sane fashion to a proper flash drive. For example, there's no support for modifying a file in-place - the entire file must be read out, modified, and then written back. These kinds of restrictions render it slow and unreliable.…
> MTP is a horrible protocol which renders the abstraction very leaky in my experience Nevertheless, it's still removable storage that can take the place of the most common use case of portable flash drives: moving files around from one computer to another. Which is explicitly what we were originally talking about. Pointing out that it doesn't work for some other use case that you yourself brought up doesn't make any…
Ultimately this is an argument about the precise semantics of "removable storage". I don't regard an MTP device as "removable storage" - it's another computer that one speaks to using a special protocol, with severe limitations. So is an iPhone - with special, protocol-speaking software, you can certainly put arbitrary files on it. I interpreted the parent to mean that they wanted to plug the phone in to "any PC" and have it Just Work. MTP isn't so great at that, especially from my perspective as a Linux user, where MTP support is no more built-in than iOS-protocol support. From this standpoint, "removable storage" == "USB mass storage".
On the other hand, it sounds like whatever Apple provides is much worse even than MTP, and less well supported in general.