Live data from Hacker News

Firefox Send: Free encrypted file transfer service

blog.mozilla.org

401–410 of 542 posts

Re: Firefox Send: Free encrypted file transfer service

#401

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?

I think Backblaze's cloud storage is the cheapest I've seen. Microsoft and Google would also be a bit cheaper than S3

Re: Firefox Send: Free encrypted file transfer service

#402
post #358
post #295

Another 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.

This service is really great and I'm sad to read it will go away - but of course, it makes no sense from a money perspective to keep it free forever. But the initial idea - saving screenshots made by the browser to the cloud is fantastic, and much more convenient than the myriads of SAAS that provide this kind of service.

Re: Firefox Send: Free encrypted file transfer service

#403

I 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!

WebRTC and privacy don't exactly go together well.

Re: Firefox Send: Free encrypted file transfer service

#404

Earlier quoted context omitted.

Why is it a necessity to store information for 90 days? Why not 10 or 30?

Legally you have to retain this type of information for at least 90 days. That sucks but it's the law.

Not in the US.

Re: Firefox Send: Free encrypted file transfer service

#406
post #114

Earlier 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.

The anchor hash/fragment (#hello) isn't sent over the network.

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

#407
post #12

I 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?

You run a simple HTTP server on your computer, then download your files over Wi-Fi using your phone's browser. Works nicely.

    cd my/directory && python3 -m http.server 80

Re: Firefox Send: Free encrypted file transfer service

#408

Earlier 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...

The problem with that table is that this only lists the entry methods, which are supported in all browsers. However, the actual work is hidden behind parameters, not all of which are supported by all browsers, and some have to be in weird combinations. One example is that Edge does not support PBKDF2 in any form, which makes many of their further support a bit weird to use.

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

#409
post #114

Earlier 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.

The browser will never send the key across the network by itself because it is in the fragment. Of course, you have to get the url with the fragment off your computer and to the intended recipient, so a MITM of this communication could intercept and download the file before the intended recipient. The intended recipient would know that this has happened, though, as the link will then be expired (assuming it was set to 1 download); if this is a fear, I would suggest adding a passphrase and sending the passphrase out of band, for example over a voice call.

Re: Firefox Send: Free encrypted file transfer service

#410
post #70

Earlier 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.

The key is in the fragment and thus is not sent to any server.
Post reply on HN