Earlier quoted context omitted.
> a "simple URL" isn't big enough to hold a full-entropy encryption key. I don’t care about that most of the time. When I do I’m unlikely to trust some random web service anyway (how do I know the author didn’t turn rogue the day before and decided to send a copy of every file to their own server?). The service could offer a choice, where picking the short link comes with a big red warning. That could even be hidden…
Just use a link shortener?
Peer-to-peer file transfers in the browser
251–260 of 272 posts
Re: Peer-to-peer file transfers in the browser
#252Earlier quoted context omitted.
If it were completed, the author should have closed/rejected every issue and pull request and removed this large warning at the top of the README: > THIS PROJECT IS STILL IN EARLY DEVELOPMENT IT USES EXPERIMENTAL CRYPTOGRAPHIC LIBRARIES AND IT HAS NOT HAD ANY KIND OF SECURITY OR CRYPTOGRAPHY REVIEW THIS SOFTWARE MIGHT BE BROKEN AND UNSAFE Plus, install instructions are outdated. As soon as I tried them, `go` complain…
Not much development can be done about experimental cryptography, you just use it and that's all. Cryptographic review can't be written either. Also you said you don't want much cryptography.
That’s not the bit that matters, it’s the “this project is still in early development” and “this software might be broken”. Those are the things which hint at the project not being done.
Re: Peer-to-peer file transfers in the browser
#253The thing that usually annoys me about these services is they tend to give you an intractably complex URL to share with the recipient. This poses a problem because every time I need such a P2P transfer, I’m communicating with someone over the phone and they need the file on a computer (which may not even be their own, so email is also cumbersome). https://file.pizza does this better than most, as the URL consists of…
> There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link. There are exceptions to this; I've been making copyparty[1], an httpd which lets you start downloading a file that is still being uploaded[2]. If you catch up with the uploader, it'll throttle the speed so the browser doesn't drop the c…
Re: Peer-to-peer file transfers in the browser
#254Earlier quoted context omitted.
https://rdrop.link gives you six characters. It's IMHO "telephoneable".
That’s a lot of red! I didn’t know about this one, thank you for the share. I suspect I still won’t use it over PairDrop because the web page is too busy, the “Check out my other projects” completely draws the eyes, and I want something that’s clean and not distracting for the receiving end.
Re: Peer-to-peer file transfers in the browser
#255Earlier quoted context omitted.
Not much development can be done about experimental cryptography, you just use it and that's all. Cryptographic review can't be written either. Also you said you don't want much cryptography.
> Not much development can be done about experimental cryptography That’s not the bit that matters, it’s the “this project is still in early development” and “this software might be broken”. Those are the things which hint at the project not being done.
Re: Peer-to-peer file transfers in the browser
#256Re: Peer-to-peer file transfers in the browser
#257The thing that usually annoys me about these services is they tend to give you an intractably complex URL to share with the recipient. This poses a problem because every time I need such a P2P transfer, I’m communicating with someone over the phone and they need the file on a computer (which may not even be their own, so email is also cumbersome). https://file.pizza does this better than most, as the URL consists of…
One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key. So your security must either come from PAKE (like magic-wormhole and friends), or from the good behavior of some intermediary. And PAKE requires a peer who knows the plaintext and will only execute the protocol once, which means it really needs to be the person you're connecting with and not an intermediate webserver.…
If you trust the server not to MITM you, then you don't need the encryption key in the URL. The URL only needs to be long enough so it cannot be guessed by an attacker, 64 bits should be plenty. Once the peers connect to the common URL, they can generate an arbitrarily large key by performing ECDH through the server. (This is where you assume that the server is not doing MITM.)
Re: Peer-to-peer file transfers in the browser
#258Earlier quoted context omitted.
Hey, our team made Blip! Glad you like the speed :)
I am intrigued by this. I read everything on your site. It looks great since it apparently allows transfer between devices using different OSes and that is always the sticking point around my place. I have several incarnations of Windows (7-11), a couple of linux distros (PopOS, CentOS7), and iOS on our phones. I see that linux is currently not supported though you would add that if people request it. That's great. M…
We set Blip to use email addresses because we wanted to make it convenient for people who are less tech savvy and for business customers who need to quickly find and know who they’re sending files to. If you sign in on another device, all your other devices and recent people are just a click away—so you don’t need to set up or sync that list by yourself.
Blip is a local-first app in the sense that it works with files on your devices, but the interactions are server-driven, letting you negotiate transfers with your devices and other people, no matter where they are. When transferring files, we try to connect devices directly over IP, but when that’s not possible (and it often is not) we relay files over our servers. We use TLS 1.3 to encrypt files in transit. When devices are connected directly, we use mTLS for an even higher level of security. We plan on adding full E2EE in the future.
We care a lot about speed! We don’t throttle transfer speeds when devices are connected directly. Sending files on home Wi-Fi should be as fast as possible, as long as devices can ping each other. Reduced speeds only apply when using our relay network. If demand is high, business customers get priority to ensure their work is delivered on time.
Our business model is still very much evolving. Our main goal was to structure it in a way where people who benefit from Blip commercially should be supporting it the most. We considered a licensing model, but Blip relies on infrastructure maintenance and continuous development, so we need everyone on the latest and most secure version. We decided to make a clear distinction between community and business users, because we learned there’s more demand for speed at work. Of course, if community users start experiencing slow speeds (in practice, this hasn’t been the case), we’d love too bring this to personal users to. One way is for one-time donations to provide high-speed data boosts. Since personal users don’t require extra support and business features, pricing can be more affordable.
All that said, it’s so good to know that speed matters! Our goal has always been to make Blip the fastest way to send files.
Thanks again for the feedback, and for the heads-up on the typo—already fixed! :)
Re: Peer-to-peer file transfers in the browser
#259The thing that usually annoys me about these services is they tend to give you an intractably complex URL to share with the recipient. This poses a problem because every time I need such a P2P transfer, I’m communicating with someone over the phone and they need the file on a computer (which may not even be their own, so email is also cumbersome). https://file.pizza does this better than most, as the URL consists of…
One tricky constraint is that a "simple URL" isn't big enough to hold a full-entropy encryption key. So your security must either come from PAKE (like magic-wormhole and friends), or from the good behavior of some intermediary. And PAKE requires a peer who knows the plaintext and will only execute the protocol once, which means it really needs to be the person you're connecting with and not an intermediate webserver.…
Basically type in encoded/crc'd ip address then some code over phone to start session
(none of this requiring someone else's servers/etc)
Re: Peer-to-peer file transfers in the browser
#260Earlier quoted context omitted.
If only IPv6 had taken off...
If only they just made a new IPv4 with a longer address field, instead of something way more complicated that also changes pre-existing addresses.
Biggest mistake ever was not to grow it organically/incrementally while maintaining backwards compatibility!