Live data from Hacker News

Firefox Send: Free encrypted file transfer service

blog.mozilla.org

451–460 of 542 posts

Re: Firefox Send: Free encrypted file transfer service

#451
post #398

Earlier quoted context omitted.

You came up with a web service that lets anyone upload something and then download it via /uploads/123? That's basically a hello world project. As you found out, the hard part is everything else, like funding it.

Funding it wasn't a problem. It took a weekend to build and was dirt-cheap to host. If people started using it enough to increase the server costs I would've stuck an ad at the bottom. Honestly half of why I took it down is nobody was really using it. I didn't work terribly hard to market it, as I had no aspirations of getting rich and it would've been tenuous to monetize at all. I just told friends about it, etc. I…

I have a few sites like this, but very few people use them. These days, box and related sites have absorbed all the file uploads.

About 15 years ago, my sites were pushing 400-600mb/s non stop. Nowadays, I barely hit 1% of my network cap at each VPS location.

Re: Firefox Send: Free encrypted file transfer service

#452
post #189

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

> the hierarchy under /usr/local has the same structure as that under /usr

So I can have /usr/local/local/local/local...? :)

Re: Firefox Send: Free encrypted file transfer service

#453
post #432

Earlier quoted context omitted.

Wasn't it initially P2P and based on the WebRTC protocol?

Not as far as I can tell. Mozilla also has (or had, I forget whether it's still a thing or not) a built-in WebRTC client they called "Hello", but that was a different thing.

What's the reason it's not made this way or doesn't include WebRTC-based P2P transfer as an option?

Re: Firefox Send: Free encrypted file transfer service

#454

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

This is great, thanks :) Mind if I port this to JS?

You don't have to ask for permission to fork open source projects.

You are free to port the project to JS as long as you follow the applicable licenses: https://github.com/timvisee/ffsend/blob/master/LICENSE

Re: Firefox Send: Free encrypted file transfer service

#455
post #226

Earlier quoted context omitted.

The same reason it's Chromecast, not Googlecast.[1] Branding. [1] The protocol is named Google Cast, but all the consumer branding is Chromecast.

I was thinking the same thing but in Google's case, Chrome is the dominate browser and most people recognize it as something they already have. In the case of Firefox, it's more likely they'll recognize the name specifically as the browser they don't have and will think they can't use it.

They'll recognize it as the browser they don't have any maybe should get because it's now positively associated with cool new features like this. :)

Re: Firefox Send: Free encrypted file transfer service

#457

a bit off topic but here it goes... This is how i think Mozilla can capture more users back to Firefox. By providing "extra" services attached to the Mozilla and Firefox brand will make them a superior product to the end user. Sure it's hard to compete with Chrome but if you offer useful features and services integrated in your Browser i see that Mozilla actually has a chance to compete with Google for the browser sp…

You may be right, but I hate it. There is no reason I can think of to have all these tools integrated into a web browser, and the idea of having the Internet broken into silos based on your choice of browsers scares me.

We don't need another AOL Chrome.

Re: Firefox Send: Free encrypted file transfer service

#458
post #170

Earlier quoted context omitted.

Do you ever run into a problem when an overzealous email service or virus scanner pre-fetches the link and invalidates it before an actual person clicks on it? This used to happen with all sorts of links in emails, though I haven't heard about it in a while.

To my knowledge, the link is only invalidated if the person actually downloads the file. Simply viewing the link does not invalidate it. I can recall a couple of times emailing a Send link to my brother, then checking it in the morning to see if he had grabbed him or not. It was still viewable, so I deduced that he hadn't grabbed it yet, sent him a follow-up e-mail ("Hey you lazy bastard, grab the damn file before it…

What if the download was interrupted because, e.g. the other person had a temporary issue in their internet connection? Does the server at least detect that the entire file has been sent over the socket? Does the server at least check that, on a TCP level, receive all the ACK packets it is meant to receive? Of course this still isn't foolproof but it's a good way towards detecting interrupted downloads.

Re: Firefox Send: Free encrypted file transfer service

#459

Earlier quoted context omitted.

You got it! The only thing you'd have to worry about is malicious JavaScript on the Firefox Send website which I believe would be highly unlikely. And of course, you must keep your link secret. Yes, such a CLI tool would help protect you against a MITM with malicious JavaScript.

Unlikely but possible. Two words: browser extensions.

Three words: My Ether Wallet.

Re: Firefox Send: Free encrypted file transfer service

#460

Earlier quoted context omitted.

Some of those points are relevant and some aren't. For logging in to a website, "just use SSL/TLS instead" makes sense, but not for this use case. There's better options nowadays for doing crypto in the browser, but I wouldn't be surprised if they were at least theoretically vulnerable to side channel attacks from JS running in another tab. The main thing is that unless you're paying really really close attention to…

Followup question: I have Signal running on my Linux computer and on my Android phone. On the Linux computer it doesn't have root access, but it does have access to its own files, so in theory there's nothing to prevent it from making a network request and updating itself. Additionally, I don't ever check Signal before installing a new update, I just blindly do it. On my Android device, I also have auto-update turned…

> On my Android device, I also have auto-update turned on, because my only option is to turn it on for every app or none of them.

Open the Signal store page and click the dots in the top right of the screen and untick Automatic Updates.

Post reply on HN