Earlier quoted context omitted.
Which is why you don’t host it on AWS. Wrong tool for the job.
Is there a cheaper S3 alternative that you recommend or that Mozilla's likely using instead?
Firefox Send: Free encrypted file transfer service
401–410 of 542 posts
Re: Firefox Send: Free encrypted file transfer service
#402Another neat feature actually built into Firefox is Take a Screenshot. To the right of the URL field, in the three dots menu. Option to save it locally, or save in the cloud with a URL with some expiration options. Sorta like a pastebin for screenshots. It only takes screenshots within the confines of a Firefox window.
Glad you like it (I worked on it). Just a side note, the cloud service will be going away in the future, but the ability to save it locally will remain.
Re: Firefox Send: Free encrypted file transfer service
#403I had the expectation that it would use WebRTC before opening the link, disappointed on that side. But really glad of the privacy minded offer. I appreciate Mozilla's work and effort towards a more private and encrypted internet!
Re: Firefox Send: Free encrypted file transfer service
#404Re: Firefox Send: Free encrypted file transfer service
#405How does it work? Is it P2P or what?
P2P would be much better, but this isn't that.
Re: Firefox Send: Free encrypted file transfer service
#406Earlier quoted context omitted.
That's why the key is in the hash part of the URL; the server can't access that (unless it also sends client Javascript that parses it and sends it back to the server, but that could be detected).
What if I'm on a network I don't trust? Is the only option to set a passphrase? More importantly, the UI doesn't call this out explicitly, so uninformed users may think it's "secure enough" without a passphrase.
https://tools.ietf.org/html/rfc3986#section-3.5
"(...) the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme."
Ed: as for an untrusted network, tls should be able to secure that. Except if the network owner can insist on/enforce a tls stripping mitm/proxy.
Re: Firefox Send: Free encrypted file transfer service
#407I can't believe that there isn't a simple service to transfer data between my cellphone and my computer without going through the internet. iTunes is terribly bloated, MTP is a mess, and Bluetooth is slow and frustrating. Back in my hacker day I used to have an SSH server open on my cellphone and use it to transfer files back and forth with my computer. Why isn't there a mainstream service like that?
cd my/directory && python3 -m http.server 80Re: Firefox Send: Free encrypted file transfer service
#408Earlier quoted context omitted.
SubtleCrypto is a new browser-adopted spec for performing crypto operations natively. For example, instead of using Math.random() for random number generation, you can use https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR... in combination with the SubtleCrypto functions to work with keys securely Your points around a compromised JS bundle are still possible but that has more to do with a company’s deploym…
Didn't realize it had full support by every browser, even ie: https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR...
Here's a site where you can test your browser's compatibility with many combinations: https://diafygi.github.io/webcrypto-examples/
Re: Firefox Send: Free encrypted file transfer service
#409Earlier quoted context omitted.
That's why the key is in the hash part of the URL; the server can't access that (unless it also sends client Javascript that parses it and sends it back to the server, but that could be detected).
What if I'm on a network I don't trust? Is the only option to set a passphrase? More importantly, the UI doesn't call this out explicitly, so uninformed users may think it's "secure enough" without a passphrase.
Re: Firefox Send: Free encrypted file transfer service
#410Earlier quoted context omitted.
The url effectively contains the decryption key, so the web server could be set to capture the urls and decrypt files. If you want, you can also set a passphrase on the file to share via another channel
> The url effectively contains the decryption key, so the web server could be set to capture the urls and decrypt files. If that's the case, I think setting a passphrase should be mandatory. Proxy servers are extremely common at every workplace. Since they probably log all requests, they will capture all keys in the URL.